الخلاصة

  • يشفّر SYN Cookie حالة TCP مؤقتة قابلة للتحقق في رقم التسلسل الأولي للخادم، فيستطيع انتظار ACK الثالث قبل تخصيص سجل صريح في SYN-RECEIVED.
  • يثبت الإيصال العائد أن جهة ما وصلت حديثاً إلى مسار الرد الخاص بالرباعي المرصود. لا يثبت هوية شخص، ولا يمنح إذن التطبيق، ولا يحجز قدرة الخدمة اللاحقة.
  • لا يحمل حقل 32 بت معلومات بلا حد. لذلك يجب إثبات عتبة التشغيل، والخيارات القابلة للاستعادة، وسلوك الفقد، والاختناقات الباقية على المكدس المنشور فعلاً.

في الفتح السلبي التقليدي يقدم الخادم المورد أولاً. تصل حزمة SYN، فيدخل SYN-RECEIVED، ويختار رقم تسلسله، ويرسل SYN-ACK، ويحفظ ما يكفي لتمييز الإقرار الأخير. لم يبرهن المرسل بعد أنه يستقبل الرد عند العنوان الذي ادعاه، لكنه احتل موضعاً في قائمة انتظار محدودة.

يستثمر فيضان SYN هذا الالتزام المبكر. تبدأ محاولات كثيرة ولا تكتمل، فتظل السجلات تنتظر إعادة الإرسال وانتهاء المهلة. وعندما تمتلئ قائمة الاتصالات الجنينية، قد يُرفض العميل المشروع مع أن الوصلة والتطبيق والاتصالات القائمة لم تستنفد مواردها كلها. يحصر RFC 4987 النموذج الكلاسيكي في حالة إنشاء الاتصال؛ ولا يجعله دليلاً تلقائياً على استهلاك كل عرض النطاق أو قدرة المعالجة.

توزع وسائل التخفيف الخسارة بطرق مختلفة. تكبير backlog يشتري وقتاً لكنه يعرض ذاكرة أكبر. تقصير مهلة SYN-RECEIVED يسترجع السجلات سريعاً ويضر المسارات البطيئة أو كثيرة الفقد. إعادة استخدام أقدم سجل تجعل العمر، لا الصحة، معيار الإقصاء. يحتفظ SYN cache بملف أصغر. أما الوكيل فيكمل المصافحة على جهاز آخر وينقل إليه المعنى والتكلفة معاً.

يتخلى SYN Cookie عن الملف المؤقت كله. يصوغ الخادم رقم تسلسله الأولي بحيث يحمل وصفاً مضغوطاً للمحاولة وفحصاً يعتمد على سر محلي. تجمع التصاميم التاريخية بين عنواني الاتصال ومنفذيه، ورقم العميل الأولي، وعداد زمني بطيء، وفئة MSS، وأسرار الخادم. يوثق RFC 4987 بدائل ومقايضات، ولا يفرض خوارزمية واحدة على كل تطبيق.

لا يحتاج العميل إلى فهم الترميز. يستقبل SYN-ACK عادية ويرد بإقرار يساوي رقم الخادم زائد واحد. عند وصول الحزمة الثالثة يستعيد الخادم القيمة، ويفحص نوافذ الزمن المقبولة، ويعيد حساب الدالة السرية على الرباعي الذي يراه. إذا تطابقت النتيجة أعاد بناء ما يكفي من الحالة ودخل ESTABLISHED. وإذا فشلت أسقط الحزمة من غير البحث عن سجل لم يُنشأ أصلاً.

الإيصال هو الاستعارة الأدق، لا جواز السفر. يكتب الخادم ورقة لا يستطيع التحقق منها إلا هو، ثم يحملها الطالب بدلاً منه. عودتها تعني أن جهة ما تلقت SYN-ACK الحديثة المرسلة إلى ذلك المسار، أو راقبتها، أو عرفتها بطريقة أخرى. يكفي ذلك لاتخاذ قرار محلي بتخصيص الذاكرة، لكنه لا يسمي المستخدم ولا المؤسسة ولا النية ولا كلفة العمل التالي.

يصعّب السر التخمين من خارج المسار، لكنه لا يحول TCP إلى بروتوكول هوية. يستطيع مراقب على المسار رؤية التبادل، وتستطيع أجهزة حقيقية كثيرة إعادة Cookies صحيحة. وبعد القبول يمكن للاتصال أن يستهلك ذاكرة socket، ومصافحة TLS، وعمال التطبيق، وقاعدة البيانات، وحصص العمل. تؤخر الآلية التزاماً واحداً؛ ولا تلغي الالتزامات التي تأتي بعده.

ثمن عدم التذكر هو ضغط المعلومات. يحتوي رقم التسلسل على 32 بت ويظل مطالباً بأداء دوره الأصلي في TCP. يستطيع سجل تقليدي حفظ كل خيارات SYN الأول. أما Cookie الأساسي فيقسم المجال نفسه بين الحداثة، والتحقق، والمعلمات الضرورية. استخدمت مخططات تاريخية، مثلاً، فهرساً صغيراً لفئات MSS الشائعة. وما لم يُشفّر ولا يمكن استنتاجه من ACK يختفي عند إعادة البناء.

يكشف Window Scale أثر ذلك بوضوح. ينص RFC 7323 على أن الخيار لا يُتفاوض عليه إلا في المقاطع التي تحمل SYN، وأن عامل كل اتجاه يثبت عند فتح الاتصال. إذا نسي الخادم عرض العميل ولم يملك امتداد Cookie يعيده، فلن يستطيع التفاوض عليه بعد الحزمة الثالثة. لذلك سجل RFC 4987 قيوداً تاريخية على Window Scale وSACK وحالات أخرى، ووصف أيضاً أسلوب FreeBSD استخدم بتات Timestamp التي يعيدها الطرف المقابل لحمل حالة إضافية.

لا يجوز تحويل مثال إلى قاعدة عامة. ليست كل تطبيقات SYN Cookie تفقد الخيارات نفسها؛ فترميزات لاحقة تستعيد معلومات أكثر. وليس صحيحاً أن كل خيار يبقى لأن تطبيقاً واحداً وجد مساحة إضافية. العقد الفعلي هو النواة والإصدار وNIC offload وموازن الحمل والوكيل والمستمع الموجودون على مسار الإنتاج.

يظهر حد آخر عندما تضيع حزمة ACK الثالثة في بروتوكول يتكلم فيه الخادم أولاً. يورد RFC 4987 مثال SMTP: يرسل العميل الإقرار الأخير، ويظن أن الاتصال اكتمل، ثم ينتظر التحية. إذا ضاع الإقرار، فلا يملك الخادم عديم الحالة سجلاً يعيد منه قراره، ولم يُخطر التطبيق بعد. يعتمد التعافي على إعادة الإرسال وعلى التطبيق المحدد. حماية الذاكرة تغيّر أي الطرفين يلاحظ الصمت أولاً.

التشغيل الهجين أكثر انضباطاً من شعار دائم. في الحمل الطبيعي تحتفظ القائمة المعتادة أو SYN cache بحالة تفاوض أغنى وبسلوك إعادة الإرسال المعروف. وعند تجاوز عتبة محلية فقط تنتقل النواة إلى Cookies بدلاً من طرد محاولة محفوظة. يصبح الوضع سياسة طوارئ لها دخول وخروج وأثر قابل للقياس، لا بديلاً دائماً عن فتح TCP.

ترسم وثائق Linux الحالية هذا الحد صراحةً. تصف tcp_syncookies بأنه وضع احتياطي عند امتلاء SYN backlog الخاص بالمقبس، وتحذر من استخدامه لجعل خادم مثقل يتحمل معدل اتصالات مشروعة يفوق قدرته. وتصف tcp_max_syn_backlog بصورة منفصلة عدد طلبات SYN_RECV التي يتذكرها كل مستمع. إذا أبقى الطلب العادي الوضع الاحتياطي نشطاً، فالمشكلة في السعة أو الطوابير أو الخدمة، لا في غياب مفتاح سحري.

حتى Cookie مثالي يترك ميزانيات كثيرة معرضة. ما زال المضيف يستقبل SYN ويفككها، ويحسب الرد، ويرسل SYN-ACK، ويفحص ACK العائد. قد تتشبع الوصلة والمقاطعات والطوابير والمعالج. وبعد الإنشاء قد تمتلئ accept queue والاتصالات القائمة والتشفير والعمال والاعتمادات. نقل الاختناق إلى الطبقة التالية قد يكون نجاحاً محلياً؛ أما إبقاؤه بلا رؤية ولا مالك ففشل تشغيلي.

التحقق من عنوان المصدر مكمل لا بديل. يقلل BCP 38 وBCP 84 قدرة الشبكات على تصدير حزم بعناوين مزورة، ومن ثم الردود المرسلة إلى وجهات مختلقة. لكنه لا يوقف أجهزة حقيقية تكمل المصافحة ولا ذروة مشروعة. تحدد شبكة المصدر ما تسمح بخروجه، ويحدد الطرف متى يخصص حالته. لكل سطح سلطة مختلفة.

يجب أن تعوض المراقبة الدليل الذي أزالته اللامركزية عن الجدول. يفرق RFC 4898 بين أحداث القائمة الجنينية، وتخصيص الموارد الكاملة، وقبول التطبيق، ويلاحظ أن نظام SYN Cookie لا يملك تمثيلاً صريحاً لحالة SYN-RCVD المشفرة. قد تعني شاشة تعرض صفراً من الاتصالات النصفية هدوءاً، وقد تعني أن الخادم توقف عن التذكر.

ينبغي جمع معدل SYN، وSYN-ACK وإعاداتها، وإشغال القائمة وفائضها، وCookies الصادرة، والقيم العائدة الصحيحة والخاطئة والمنتهية، والاتصالات المنشأة، وضغط accept queue، وقبول التطبيق في سلسلة واحدة. ويجب مقارنة MSS وWindow Scale وSACK وTimestamp وECN وFast Open بين الوضع العادي ووضع Cookie. إذا غاب عداد التحول، اختفى الإنذار مع الحالة.

يسمح TCP Fast Open ببيانات تطبيق داخل SYN وفق Cookie آخر وافتراضات إعادة مختلفة. لا يضمن RFC 7413 أن fallback تقليدياً لـSYN Cookie يحفظ تلك البيانات. يجب اختبار الواجهة والموازن وoffload والنواة على المسار نفسه. اشتراك آليتين في كلمة Cookie لا يمنحهما عقداً واحداً.

يقدم SCTP مقارنة مع بروتوكول حجز وعاءً صريحاً للحالة المؤجلة. يحمل إنشاء RFC 9260 الرباعي State Cookie متغير الطول، وفيه معلومات الارتباط وMAC ووقت وعمر. ليس متوافقاً مع TCP ولا مطابقاً لخوارزميته المضغوطة. لكنه يوضح أن الحفاظ على معنى التفاوض أسهل عندما يخصص البروتوكول حاوية، بدلاً من ضغط مستقبل التفاوض داخل حقل قديم.

تستطيع المواصفات المشتركة وصف ثوابت المصافحة ومقايضاتها، لكنها لا تعرف ذاكرة كل مستمع وزمنه وخياراته الضرورية وكلفة التطبيق خلفه. يترك مبدأ Heng Lu للمواصفات الأولية الدنيا عتبة التشغيل والخسارة المقبولة للمشغل المحلي. ثم تضع أولوية الكود الجاري الاختبار النهائي: قيمة الإعداد نية، والاتصالات التي بقيت بخياراتها وخدمتها هي الواقع.

المصادر