سؤال

نحن نقوم بتشغيل نظام دبيان بنواة 2.6.16، مع تمكين iptables.يقوم النظام بتشغيل وكيل HTTP مخصص، والذي يخضع لحمل بسيط (يعمل بشكل جيد مع نفس التحميل على المواقع الأخرى).يتكون النظام من 4 خوادم يسبقها موازن تحميل مع IP افتراضي، يسبقه مجموعة من 4 أجهزة ISA 2004، لذا فإن الهيكل الأساسي هو:

العميل -> ISA [1-4] -> موازن التحميل -> الوكيل الخاص بنا [1-4] -> الإنترنت

في بعض الأحيان، يرسل لنا ISA حزمة SYN، والتي لا يتم إرسال SYN-ACK إليها.سيحاول مرة أخرى بعد 3 ثوان، ومرة ​​ثالثة بعد 6 ثوان أخرى، وبعد ذلك سيتم الإبلاغ عن الوكيل، والتحول إلى الاتصال المباشر.خلال هذا الوقت، أي قبل، وفيما بينها، وبعد تلك SYNs الثلاثة، تأتي SYNs أخرى من نفس ISA ويتم الرد عليها بنجاح.

يتم الإبلاغ عن مشكلة مشابهة جدًا من قبل الآخرين (ولكن بدون حل):

كل ذلك يأتي من نكهة Linux تسمى CentOS.تكمن خصوصيتها في تمكين iptables افتراضيًا.

http://www.linuxhelpforum.com/showthread.php?t=931912&mode=linear http://www.centos.org/modules/newbb/viewtopic.php?topic_id=16147

غالبا نفس الشيء:ولكن مختلفة قليلا:http://www.linuxquestions.org/questions/linux-networking-3/tcp-handshake-fails-synack-ignored-by-system.-637171/

يبدو أيضًا أنه ذو صلة:http://groups.google.com/group/comp.os.linux.networking/browse_thread/thread/b1c000e2d65e0034

أظن أن iptables هو المذنب، لكن أي تعليقات إضافية ستكون موضع ترحيب.

هل كانت مفيدة؟

المحلول

انظر إلى المعلمة الثانية لمكالمة الاستماع، كما هو مذكور في الرابط الأول الذي نشرته.إنه الحد الأقصى لعدد الاتصالات المعلقة (غير المقبولة بعد).وفقًا لصفحة دليل الاستماع (2)، إذا كان البروتوكول يدعم إعادة الإرسال (TCP)، فسيتم إسقاط طلب الاتصال عندما تكون قائمة الانتظار ممتلئة (نتوقع إعادة إرسال لاحقة ستؤدي إلى إنشاء الاتصال إذا كانت هناك مساحة كافية في قائمة الانتظار مرة أخرى) ).

نصائح أخرى

في الواقع، تبين أن iptables هو المذنب، مع القاعدة التي أسقطت الحزم غير الصالحة.ما زلنا لا نعرف على وجه اليقين ما الذي جعل iptables يعتقد أن SYNs هذه غير صالحة (لا يوجد TIME_WAIT بالتأكيد، حيث لم يكن لدينا أي حركة مرور مع نفس منافذ المصدر لمدة 30 دقيقة على الأقل قبل الحذف).

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top