لماذا لا يوجد maxThreads يُضبط في WebLogic؟

لأن WebLogic استبدل منذ سنوات نموذج طوابير التنفيذ الثابتة بمجمّع خيوط واحد يضبط نفسه ذاتياً. وبدل تحديد الخيوط مباشرةً، تشكّل كيفية توزيع المجمّع لها عبر Work Manager. يحدّ max-threads-constraint عدد الخيوط التي يستهلكها صنف عمل، ويضمن min-threads-constraint حدّاً أدنى، ويحدّ قيد capacity مجموع الطلبات في الطابور وقيد التنفيذ قبل أن يرفض WebLogic برمز 503. والتحوّل الذهني من «حدّ المجمّع» إلى «حدّ العمل». وفي مواجهة DDoS فإن قيد capacity هو الذي يحدّ كم يستطيع فيضان من نوع طلب واحد أن يستهلك.

أي ضبط هو دفاع Slowloris في WebLogic؟

Complete Message Timeout أولاً. يحدّ الوقت الكلي الذي ينتظره WebLogic لتلقّي رسالة طلب كاملة بعد فتح الاتصال، فالعميل الذي يرسل طلبه بايتاً بايتاً يُسقَط عند المهلة بدل أن يحتجز مقبساً إلى ما لا نهاية. وهو قيمة افتراضية على مستوى الخادم مع تجاوز على مستوى Web Server. اقرنه بمهلة Idle Connection Timeout التي تغلق اتصالاً يُفتح ثم يبقى خاملاً، وبمهلة Post Timeout معقولة لجسم الطلب. ولا يكون أيٌّ من هذه صارماً افتراضياً على نطاق قديم.

ماذا تفعل Overload Protection فعلاً؟

تحدّد سلوك WebLogic حين يستنفد مورداً، كي يفشل الخادم فشلاً متوقَّعاً لا أن ينهار. تضبط Shared Capacity لمديري العمل (مجموع الطلبات في الطابور على مستوى الخادم قبل رفض الجديد)، وMax Stuck Thread Time وعدد الخيوط العالقة الذي يطلق Failure Action، وPanic Action عند نفاد الذاكرة. وتحت DDoS يحوّل هذا «الخادم يعلَق فيعيد أحدهم تشغيله» إلى «الخادم يطرح الحمل برمز 503 ويبقى مُدارًا». وهذا هو الفرق بين حادثة محدودة وانقطاع.

WLST أم Administration Console؟

WLST لكل ما تريده قابلاً للتكرار والمراجعة. الوحدة الرسومية جيدة للاستكشاف، لكن أوامر WLST في هذا الدليل قابلة للبرمجة، وتُطبَّق بالطريقة نفسها على الخوادم المُدارة في النطاق، وتخضع لضبط الإصدارات. وتحرير config.xml يدوياً غير مدعوم لنطاق قيد التشغيل ويُكتب فوقه من Admin Server. اعتبر WLST نظير الـ CLI المدعوم في الخوادم الأخرى: الواجهة المعتمَدة لا طريقاً التفافياً.

هل يظل WebLogic بحاجة إلى طبقة أمامية؟

نعم. يُنهي التصميم القياسي من Oracle اتصال الإنترنت عند Oracle HTTP Server أو وكيل مصلَّب آخر يحمل TLS والمحتوى الساكن والخط الأول من تحديد المعدّل وطرد الاتصالات البطيئة، ثم يمرّر إلى WebLogic عبر الشبكة الداخلية. وأدوات WebLogic هنا هي الخط الثاني خلف تلك الطبقة. تهمّ لأن الطبقة الأمامية قد تُلتَف داخلياً أو تمرّر هجوماً لم تلتقطه، لكنها لا تحلّ محلّ وضع WebLogic خلف واحدة.

هل توقف هذه الإعدادات هجوماً حجمياً؟

لا. إن ملأ الهجوم الوصلة أمام الخوادم فلا تتلقّى الطبقة الأمامية ولا WebLogic الطلبات، ولا ينطبق أي ضبط MBean. كل ما هنا يدافع عن طبقة التطبيقات ضد إشباع العمل واستنزاف الاتصالات. والحجم فوق الوصلة مسألة الطبقة الشبكية ولا يُحلّ في نطاق WebLogic.

تحليل تقني معمّق

تصليب WebLogic ضد DDoS: مديرو العمل ومهل الرسائل وحماية الحمل الزائد

آخر تحديث: أغسطس 2026 · قيود Work Manager ومهل الرسائل وحماية الحمل الزائد · زمن القراءة ~15 دقيقة

محطة وزن عند بوابة تُدخل كل قادم بحسب الأولوية وتردّ الفائض؛ وحين تبلغ القاعة خلفها سعتها يميل الميزان وتُغلق البوابة بنظافة بدل أن تدع القاعة تنهار.

لا يوجد في WebLogic مجمّع خيوط ثابت لتحدّه؛ فهو يضبط نفسه ذاتياً. تبني الدفاع بقيود Work Manager وبمهلة Complete Message Timeout وبإجراءات Overload Protection، لا برقم maxThreads. مهلة الرسالة تردّ الطلب البطيء، وقيد capacity يحدّ العمل، وحماية الحمل الزائد تقرّر ما يفعله الخادم حين يمتلئ.

يصلّب هذا الدليل خادم Oracle WebLogic نفسه ضد الجزء الذي يستنزف العمل والاتصالات من هجوم DDoS. يغيّر WebLogic المقاربة عن سائر خوادم التطبيقات في نقطة مهمة: لا يوجد مجمّع خيوط ثابت لتحدّه. يضبط WebLogic مجمّعاً واحداً ذاتياً، فالدفاع ليس رقم maxThreads بل مجموعة قيود Work Manager ومهل رسائل وإجراءات Overload Protection تقرّر ما يفعله الخادم حين يستنفد مورداً.

وكما في Tomcat وJBoss، فإن WebLogic خادم تطبيقات ويقف خلف طبقة أمامية مصلَّبة (Oracle HTTP Server أو وكيل آخر). والأدوات أدناه هي الخط الثاني. وكل ضبط يأتي مع الـ MBean الخاص به وأمر WLST والعدّاد الذي يظهر عمله.

أشكال الهجوم وأدوات WebLogic التي تردّها

الجهاز	شكل الهجوم	أداة WebLogic
ترويسة بطيئة / جسم بطيء	Complete Message Timeout; Idle Connection Timeout	WebServer / Server MBean
فيضان اتصالات	Accept Backlog; Maximum Open Sockets	Server MBean
إشباع العمل	Work Manager max-threads-constraint, capacity	self-tuning work managers
إساءة الطلبات الكبيرة	Max Post Size, Max Message Size, Post Timeout	WebServer MBean
حمل زائد على الخادم	Overload Protection: shared capacity, panic action	Overload MBean

يضبط WebLogic مجمّع خيوطه ذاتياً، فالدفاع قيود وإجراءات حمل زائد لا حدّ maxThreads. وكما في Tomcat وJBoss يأتي أولاً طبقة أمامية مصلَّبة؛ وهذه هي الخط الثاني. ولا ينفع أيٌّ منها حين يملأ الهجوم الوصلة.

0. أولاً القياس الأساسي: عدّادات الخيوط والاتصالات

يكشف WebLogic حالة التشغيل عبر MBean تُقرأ في WLST. سجّل أرقام المجمّع والطابور والاتصالات لأسبوع عادي:

# WLST — اتصل واقرأ المجمّع ذاتي الضبط وقناة الخادم
connect('weblogic', 'password', 't3://localhost:7001')
serverRuntime()

# المجمّع ذاتي الضبط: قيد التنفيذ، خامل، طول الطابور، throughput
cd('/ThreadPoolRuntime/ThreadPoolRuntime')
ls()   # ExecuteThreadTotalCount, HoggingThreadCount, PendingUserRequestCount, Throughput

# المقابس المفتوحة على القناة الافتراضية
cd('/ServerChannelRuntimes')

PendingUserRequestCount وHoggingThreadCount قياساً على أساس أسبوع عادي، مع عدد المقابس المفتوحة، هي القياسات الأساسية التي تُضبط عليها كل قيمة أدناه.

1. أولاً الطبقة الأمامية

تأكّد أن عنوان استماع WebLogic داخلي، وأمامه Oracle HTTP Server أو وكيل:

# عنوان الاستماع يجب أن يكون واجهة داخلية لا عامة
ss -ltnp | grep 7001

إن كان عاماً فاربطه بعنوان داخلي وأنهِ اتصال الإنترنت عند الطبقة الأمامية التي يتناولها دليلا nginx وApache. وOracle HTTP Server مشتقّ من Apache، فدليل Apache ينطبق عن قرب.

2. مهل الرسائل والاتصالات

Complete Message Timeout هو دفاع Slowloris الأساسي. اضبطه واضبط حدود الاتصال عبر WLST:

edit()
startEdit()

# Slowloris: أقصى وقت لتلقّي رسالة طلب كاملة (ثوانٍ)
cd('/Servers/myserver')
cmo.setCompleteMessageTimeout(60)

# مهلة اتصال خامل (ثوانٍ) — تغلق اتصالاً يُفتح ثم يبقى خاملاً
cmo.setIdleConnectionTimeout(30)

# backlog الاتصال وسقف المقابس المفتوحة
cmo.setAcceptBacklog(300)
cmo.setMaxOpenSockCount(8192)

save()
activate()

Complete Message Timeout قيمة افتراضية على مستوى الخادم مع تجاوز على مستوى Web Server. وعلى نطاق قديم تكون غالباً عند قيمة متساهلة، وخفضها إلى بضع عشرات من الثواني هو أنجع علاج للطلب البطيء هنا.

3. قيود Work Manager: تحديد العمل لا المجمّع

لأن المجمّع يضبط نفسه، تحدّ أصناف العمل. وقيد capacity هو الذي يحدّ كم يستطيع فيضان طلبات أن يصطفّ قبل أن يرفض WebLogic برمز 503:

edit()
startEdit()

# قيد max-threads يحدّ خيوط صنف عمل
cd('/SelfTuning/mydomain')
cmo.createMaxThreadsConstraint('MaxThreadsForApp')
cd('/SelfTuning/mydomain/MaxThreadsConstraints/MaxThreadsForApp')
cmo.setCount(128)

# قيد capacity يحدّ مجموع «الطابور + التنفيذ» قبل الرفض (503)
cd('/SelfTuning/mydomain')
cmo.createCapacity('AppCapacity')
cd('/SelfTuning/mydomain/Capacities/AppCapacity')
cmo.setCount(4096)

save()
activate()

قيد capacity هو المتعلّق بـ DDoS. يحوّل طابوراً بلا حدّ تحت الفيضان إلى رفض نظيف، ويحمي العمل الجاري أصلاً.

4. Overload Protection: الفشل المتوقَّع

تقرّر Overload Protection ما يفعله WebLogic حين يستنفد مورداً، كي يطرح الحمل بدل أن يعلَق:

edit()
startEdit()

cd('/Servers/myserver/OverloadProtection/myserver')
# مجموع الطلبات في الطابور على مستوى الخادم قبل رفض الجديد
cmo.setSharedCapacityForWorkManagers(65536)
# معالجة الخيوط العالقة: كم يعمل الخيط قبل أن يُعدّ عالقاً
cd('/Servers/myserver')
cmo.setStuckThreadMaxTime(600)
cmo.setStuckThreadTimerInterval(60)
# الإجراء عند بلوغ عتبة الفشل
cd('/Servers/myserver/OverloadProtection/myserver')
cmo.setFailureAction('force-shutdown')   # أو 'administrative' للحجر
cmo.setPanicAction('system-exit')        # عند نفاد الذاكرة، خروج نظيف ليعيد المشرف التشغيل

save()
activate()

تحت DDoS يدفع الخادم نحو الاستنفاد، هذا هو الفرق بين «الخادم يعلَق ويُعاد تشغيله يدوياً» و«الخادم يطرح الحمل برمز 503 ويبقى مُدارًا»: حادثة محدودة بدل انقطاع.

5. حدود حجم الطلب

أغلق سطح الطلبات الكبيرة على MBean الخاص بـ Web Server:

edit()
startEdit()
cd('/Servers/myserver/WebServer/myserver')
cmo.setMaxPostSize(10485760)       # 10 ميغابايت
cmo.setMaxPostTimeoutSecs(30)      # الوقت المسموح لقراءة جسم POST
cmo.setPostTimeoutSecs(30)
save()
activate()

MaxPostSize ومهل POST تغلقان صنف الهجوم الذي يفتح طلباً ويرسل الجسم ببطء أو بحجم ضخم. وحجم POST غير المحدود افتراضياً خيار خاطئ لأي نطاق مجاور للإنترنت.

6. عنوان العميل خلف الطبقة الأمامية

مع Oracle HTTP Server أو وكيل في الأمام، على WebLogic أن يستخدم الترويسات التي يمرّرها ملحق WebLogic (WLProxyPassThrough وقيمة WL-Proxy-Client-IP من الملحق) كي ترى السجلات والقواعد العميل الحقيقي لا الوكيل. تأكّد أن الملحق مضبوط لتمرير عنوان العميل وأن WebLogic مضبوط للثقة به. وإلا نُسب كل طلب إلى الوكيل، وهو عطل عنوان الوكيل المتكرّر في هذه السلسلة كلها.

الإشارات التي تُوصَل بالمراقبة

# في WLST serverRuntime()، من ThreadPoolRuntime:
#   1. PendingUserRequestCount — العمل في الطابور (توقيع الفيضان)
#   2. HoggingThreadCount — خيوط مُحتجَزة طويلاً (طلب بطيء أو عالق)
#   3. ExecuteThreadTotalCount مقابل throughput — إشباع المجمّع
#   4. عدد المقابس المفتوحة مقابل MaxOpenSockCount
cd('/ThreadPoolRuntime/ThreadPoolRuntime')
cmo.getPendingUserRequestCount()
cmo.getHoggingThreadCount()

PendingUserRequestCount متصاعد مع HoggingThreadCount متصاعد هو توقيع أن معدّل الطلبات فاق ما يستطيع WebLogic معالجته. وهي النقطة التي على الطبقة الأمامية أو طبقة عليا أن تمتصّ الفائض فيها.

الحدّ الصادق لتصليب WebLogic

كل ما هنا يدافع عن طبقة التطبيقات خلف طبقة أمامية ينبغي أن تلتقط معظمه أولاً. حالتان تقعان خارج ذلك.

الأولى إشباع الوصلة: الحجم الذي يملأ الأنبوب لا يبلغ الطبقة الأمامية ولا WebLogic.

تحت الوصلة لأدوات WebLogic نصيب؛ وفوقها لا معنى لأي قيمة MBean.

والثانية طبقة نظام التشغيل تحت الخوادم، ويتناولها دليلا Linux و Windows. ويفترض تصليب WebLogic أن الطبقة الأمامية وطبقة نظام التشغيل كلتيهما في مكانهما. وفوق الوصلة الجواب هو الطبقة الشبكية.

ترتيب التطبيق

تأكّد أن عنوان الاستماع داخلي؛ وضع أمامه Oracle HTTP Server أو وكيلاً.
سجّل القياس الأساسي: الطلبات في الطابور، الخيوط المحتجَزة، المقابس المفتوحة.
اضبط Complete Message Timeout وحدود الاتصال عبر WLST.
أضف قيد capacity لتحدّ العمل في الطابور.
اضبط Overload Protection كي يطرح الخادم الحمل بدل أن يعلَق.
اضبط حدود حجم POST ومهله؛ وتأكّد أن الملحق يمرّر عنوان العميل.
صِل عدّادات التشغيل بالمراقبة.

الخطوة الأولى، مرة أخرى، هي القرار الأكثر تغييراً للنتيجة. أدوات WebLogic هي الخط الثاني، ولا تنفع إلا خلف الخط الأول الذي تقف وراءه.

أسئلة متكررة

لماذا لا يوجد maxThreads يُضبط في WebLogic؟: لأن WebLogic استبدل منذ سنوات نموذج طوابير التنفيذ الثابتة بمجمّع خيوط واحد يضبط نفسه ذاتياً. وبدل تحديد الخيوط مباشرةً، تشكّل كيفية توزيع المجمّع لها عبر Work Manager. يحدّ max-threads-constraint عدد الخيوط التي يستهلكها صنف عمل، ويضمن min-threads-constraint حدّاً أدنى، ويحدّ قيد capacity مجموع الطلبات في الطابور وقيد التنفيذ قبل أن يرفض WebLogic برمز 503. والتحوّل الذهني من «حدّ المجمّع» إلى «حدّ العمل». وفي مواجهة DDoS فإن قيد capacity هو الذي يحدّ كم يستطيع فيضان من نوع طلب واحد أن يستهلك.
أي ضبط هو دفاع Slowloris في WebLogic؟: Complete Message Timeout أولاً. يحدّ الوقت الكلي الذي ينتظره WebLogic لتلقّي رسالة طلب كاملة بعد فتح الاتصال، فالعميل الذي يرسل طلبه بايتاً بايتاً يُسقَط عند المهلة بدل أن يحتجز مقبساً إلى ما لا نهاية. وهو قيمة افتراضية على مستوى الخادم مع تجاوز على مستوى Web Server. اقرنه بمهلة Idle Connection Timeout التي تغلق اتصالاً يُفتح ثم يبقى خاملاً، وبمهلة Post Timeout معقولة لجسم الطلب. ولا يكون أيٌّ من هذه صارماً افتراضياً على نطاق قديم.
ماذا تفعل Overload Protection فعلاً؟: تحدّد سلوك WebLogic حين يستنفد مورداً، كي يفشل الخادم فشلاً متوقَّعاً لا أن ينهار. تضبط Shared Capacity لمديري العمل (مجموع الطلبات في الطابور على مستوى الخادم قبل رفض الجديد)، وMax Stuck Thread Time وعدد الخيوط العالقة الذي يطلق Failure Action، وPanic Action عند نفاد الذاكرة. وتحت DDoS يحوّل هذا «الخادم يعلَق فيعيد أحدهم تشغيله» إلى «الخادم يطرح الحمل برمز 503 ويبقى مُدارًا». وهذا هو الفرق بين حادثة محدودة وانقطاع.
WLST أم Administration Console؟: WLST لكل ما تريده قابلاً للتكرار والمراجعة. الوحدة الرسومية جيدة للاستكشاف، لكن أوامر WLST في هذا الدليل قابلة للبرمجة، وتُطبَّق بالطريقة نفسها على الخوادم المُدارة في النطاق، وتخضع لضبط الإصدارات. وتحرير config.xml يدوياً غير مدعوم لنطاق قيد التشغيل ويُكتب فوقه من Admin Server. اعتبر WLST نظير الـ CLI المدعوم في الخوادم الأخرى: الواجهة المعتمَدة لا طريقاً التفافياً.
هل يظل WebLogic بحاجة إلى طبقة أمامية؟: نعم. يُنهي التصميم القياسي من Oracle اتصال الإنترنت عند Oracle HTTP Server أو وكيل مصلَّب آخر يحمل TLS والمحتوى الساكن والخط الأول من تحديد المعدّل وطرد الاتصالات البطيئة، ثم يمرّر إلى WebLogic عبر الشبكة الداخلية. وأدوات WebLogic هنا هي الخط الثاني خلف تلك الطبقة. تهمّ لأن الطبقة الأمامية قد تُلتَف داخلياً أو تمرّر هجوماً لم تلتقطه، لكنها لا تحلّ محلّ وضع WebLogic خلف واحدة.
هل توقف هذه الإعدادات هجوماً حجمياً؟: لا. إن ملأ الهجوم الوصلة أمام الخوادم فلا تتلقّى الطبقة الأمامية ولا WebLogic الطلبات، ولا ينطبق أي ضبط MBean. كل ما هنا يدافع عن طبقة التطبيقات ضد إشباع العمل واستنزاف الاتصالات. والحجم فوق الوصلة مسألة الطبقة الشبكية ولا يُحلّ في نطاق WebLogic.

النشر: أغسطس 2026

يُحدَّث هذا الدليل كلما طرح المصنّعون طرازات وشروط ترخيص جديدة. كيف نقارن بين المصنّعين