الخلاصة

  • يحدث الفتح المتزامن عندما يرسل الطرفان SYN ويستقبل كل منهما SYN بلا إقرار وهو في حالة SYN-SENT.
  • ينتقل الطرفان إلى SYN-RECEIVED، ويقرّ كل منهما مساحة تسلسل الآخر، ثم يصلان إلى ESTABLISHED لاتصال واحد لا اتصالين.
  • تلزم RFC 9293 تطبيقات TCP بدعم هذا المسار وتذكّر ما إذا كان SYN-RECEIVED ناتجاً عن فتح نشط أو سلبي.

المصافحة قبل الأدوار

يُدرَّس TCP غالباً بوصفه حواراً بين عميل وخادم. لكن RFC 793 تصف المصافحة أولاً بأنها مزامنة اتصال. صحيح أن طرفاً يبدأ وآخر يجيب عادة، إلا أن طرفين يمكنهما البدء في الوقت نفسه. أما أدوار العميل والخادم فهي اصطلاحات تطبيقية وليست شرطاً في النقل.

عندما تتقاطع حزم SYN

ينفذ الطرفان active OPEN، ويختار كل منهما رقم تسلسله الأولي ويرسل SYN. تتقاطع الحزمتان بينما يكون الطرفان في SYN-SENT. يستقبل كل طرف SYN الآخر بلا إقرار، ويسجل رقمه، وينتقل إلى SYN-RECEIVED ويرسل SYN+ACK. وعند وصول إقرار مقبول لـ SYN الخاص به، ينتقل إلى ESTABLISHED. هكذا يتقارب الفتحان في اتصال واحد.

يستهلك SYN رقماً واحداً من فضاء التسلسل، ولذلك يتقدم الإقرار بمقدار واحد.

التماثل يحتاج إلى ذاكرة

تطلب RFC 9293 دعم الفتح المتزامن وتسجيل ما إذا كان SYN-RECEIVED قد نتج عن active أو passive OPEN. تؤثر هذه السابقة في معالجة إعادة الضبط والأخطاء لاحقاً. الحالة متماثلة، لكن التاريخ المحلي ليس بلا أهمية.

SYN قديم يبدو كأنه طرق

قد يبدو SYN قديم ومكرر كأنه بداية فتح متزامن. لذلك تبقى مطابقة التسلسل ومعالجة إعادة الضبط ضروريتين؛ فليس كل SYN يصل في SYN-SENT مشروعاً.

ما لا يضمنه المعيار

يصف المعيار انتقالات الحالة إذا وصلت الحزم إلى طرفي TCP. ولا يثبت أن التوجيه أو الجدران النارية أو تعيينات NAT أو واجهات المقابس أو التطبيقات الحالية ستسمح بالتبادل.

المصادر