الخلاصة

  • في الفتح المتزامن ينفّذ الطرفان OPEN نشطاً نحو زوج المقابس نفسه. تتقاطع حزمتا SYN من دون ACK، وينتقل الطرفان إلى SYN-RECEIVED، ثم تنشئ حزمتا SYN-ACK المتقاطعتان وصلة واحدة لا وصلتين.
  • لا يحتاج البروتوكول إلى تعيين عميل أولاً؛ فكل طرف يتحقق محلياً من رقم البدء البعيد، ويتلقى إقراراً بوصول رقم البدء الخاص به.
  • حفظت أجهزة NAT غالباً نمط «SYN خارج ثم SYN-ACK داخل» وحده. لذلك ألزم RFC 5382 المترجم الذي سمحت سياسته بالوصلة أن يقبل أيضاً SYN الداخل في المسار المتزامن.

الرسم البسيط منح الأدوار سلطة زائدة

ثلاثة أسهم تكفي لشرح المسار المعتاد: SYN ثم SYN-ACK ثم ACK. غير أن RFC 793 نصّ كذلك على أن عمليتين تفتحان اتصالاً نشطاً إحداهما نحو الأخرى في الوقت نفسه ستتصلان بصورة صحيحة. كانت هذه المرونة مهمة لمكوّنات الحوسبة الموزعة التي تعمل من دون توقيت مركزي.

العميل والخادم وظيفتان نافعتان على مستوى التطبيق، لكنهما ليسا رتبتين تمنحان صحة TCP. ما يعرّف الوصلة هو زوج المقابس وتزامن فضاءَي التسلسل.

ولذلك لم يكن الفتح المتزامن علاجاً متأخراً لحادث نادر. كان طريقاً أصلياً في آلة الحالات، فيما كان الرسم الأشهر مجرد طريق شائع داخلها.

تقاطع SYN قاد إلى حالة مشتركة

يختار الطرف A رقم بدء 100 ويختار B الرقم 300. يرسل كل منهما SYN ويدخل SYN-SENT. عندما يستقبل A حزمة SYN الخالصة من B، لا يرفضها لأنه أرسل واحدة من قبل. يسجل 300، وينتقل إلى SYN-RECEIVED، ويرسل SYN-ACK بإقرار 301. ويؤدي B العملية المعكوسة ويقر 101.

بعد وصول SYN-ACK إلى الجانبين، يعرف كل طرف أصل تسلسل الآخر ويعرف أن أصله الخاص قد وصل. يحتفظ RFC 9293 بهذا المسار المصحح: CLOSED ثم SYN-SENT ثم SYN-RECEIVED ثم ESTABLISHED لدى الاثنين.

يختلف شكل تبادل الرزم عن مشهد المبادر والمستجيب، لكن البرهان واحد: إعلان رقمَي البدء، استلامهما، ثم الإقرار بهما.

الزيادة واحد كانت دليلاً

تستهلك SYN موضعاً واحداً في فضاء التسلسل. لذلك يُقرّ رقم 300 بالرقم 301. لا يقول ACK إن «رزمة ما وصلت» فحسب، بل يثبت أن المتلقي تجاوز عنصر التحكم ذي الرقم المحدد. أما ACK الخالي فلا يستهلك رقماً، وإلا لاحتجنا إلى إقرارات لا تنتهي.

يظل فضاء إرسال كل طرف مستقلاً. تناظر المبادرة لا يعني أرقاماً مشتركة. عزز RFC 6528 لاحقاً اختيار أرقام البدء بمكوّن شبه عشوائي سري مرتبط برباعية العناوين والمنافذ.

تكفي هذه الوقائع التي يمكن التحقق منها محلياً: هوية الزوج، ورقم الطرف الآخر، وإقرار الرقم الذاتي. لا حاجة إلى حكم مركزي يقرر من كان المتصل الشرعي.

مكالمتان محليتان لم تصنعا وصلتين

قد يفترض المنفّذ أن استدعاءَي اتصال نشطين يجب أن ينتجا كائنين. عالج RFC 1122 هذا الالتباس صراحة: تنتج محاولة الفتح المتزامن وصلة واحدة، وكان ذلك قراراً مقصوداً لا ينبغي «إصلاحه».

يرى A مقبسه المحلي مع مقبس B البعيد، ويرى B الزوج نفسه بالعكس. الرباعية واحدة من منظورين. نسخها إلى وصلتين لا يحفظ واقعاً إضافياً؛ بل يخلق سؤالاً مصطنعاً عن أيهما يحمل البيانات.

عدد الإجراءات المحلية ليس عدد الحقائق المشتركة. يمكن لطلبين أن يلتقيا في ارتباط واحد متزامن.

كان على الحالة أن تتذكر طريق الوصول إليها

قد يصل TCP إلى SYN-RECEIVED بعد OPEN سلبي، أو بعد OPEN نشط تلقى SYN بعيداً. يوجب RFC 1122 وRFC 9293 حفظ هذا الأصل لأن التعامل مع RST والعودة المحتملة إلى LISTEN يختلفان.

وحذّر RFC 793 أيضاً من أن SYN قديمة مكررة قد تبدو كفتح متزامن جديد. لا يحل TCP الالتباس بحظر الطريق الصحيح؛ بل يستخدم أرقام التسلسل المتوقعة والإقرارات والتحقق من RST لتمييز اللقاء الحالي من بقايا تجسيد سابق للوصلة.

اسم الحالة وحده ليس حالة كاملة. حذف تاريخ الدخول يبسّط الرسم، لكنه يحرم التنفيذ من الدليل الذي يحتاجه عند التعافي.

تعلّم NAT القصة الأكثر شيوعاً فقط

في اتصال العميل والخادم المعتاد، تنشئ SYN الخارجة تعييناً، وتأتي بعدها SYN-ACK داخلة. أما في الفتح المتزامن فتأتي SYN أخرى. وثّق RFC 5382 أجهزة NAT أسقطت الحزمة باعتبارها غير مطلوبة، وأخرى أخطأت في ترجمة SYN-ACK الخارجة اللاحقة.

كان الطرفان يطبقان TCP، وربما كان المترجم قد أنشأ حالته بالفعل بسبب SYN المحلية. لكن التنفيذ حوّل ترتيباً شائعاً إلى قانون كامل.

يجوز لسياسة الترشيح أن تمنع الوصلة. أما إذا سمحت بها، فعلى تعقب الحالة أن يفهم انتقالاتها الصحيحة. لهذا يطلب RFC 5382 معالجة جميع تتابعات TCP الصحيحة للوصلات المسموح بها، ومنها الفتح المتزامن. تبقى سلطة المنع، ولا تتحول بساطة المحلل إلى تضييق خفي للبروتوكول.

ست ثوانٍ جعلت ثمن الجهل ظاهراً

قد تصل SYN البعيدة إلى NAT قبل SYN المحلية التي ستنشئ التعيين. تبدو الحزمة عندها غير مطلوبة فعلاً. يعيد RST أو خطأ ICMP الفوري نتيجة سريعة، لكنه يجبر الطرف البعيد على إنهاء محاولة كان من الممكن أن تنجح بعد وصول SYN المحلية المتأخرة.

اختار RFC 5382 انتظار ست ثوانٍ على الأقل. إذا ظهرت SYN الخارجة المطابقة، تُسقط الحزمة المبكرة بصمت، وتصل إعادة الإرسال بعد تجهيز التعيين. وإذا لم تظهر، يمكن إرسال الخطأ وفق سياسة الأمن.

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

أعاد الند للند استخدام التناظر القديم

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

عرّف RFC 6544 مرشح S-O في ICE TCP إلى جانب المرشحين النشط والسلبي. وأوصى أيضاً ببدائل متعددة ومرحلات، لأن أنظمة التشغيل وأجهزة NAT والسياسات لا توفر دعماً موحداً.

الصحة في مواصفة TCP لا تساوي الإتاحة في كل شبكة. الفتح المتزامن قدرة عند الطرف، لكن صلاحية استعمالها خاصية للمسار كله.

صمد التناظر لأنه قائم على البرهان

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

لم تكن مشكلة NAT حرية زائدة عند الحواف، بل ترقية العادة الأكثر انتشاراً إلى إلزام خفي. أعاد RFC 5382 فصل القرارين: يقرر الوسيط ما يسمح به، لكنه يقرأ TCP المسموح به بأمانة.

حين اتصل الطرفان معاً، لم ينتخب TCP فائزاً. جعل كل طرف يبرهن ما أرسله وما استلمه. نشأت وصلة واحدة من حالة مشتركة قابلة للتحقق، لا من أدوار مسبقة.

المصادر وحدود الأدلة

تستند المقالة إلى RFC 793 وRFC 1122 وRFC 5382 وRFC 6528 وRFC 6544 وRFC 9293. لا تقيس هذه الوثائق الانتشار الحالي أو كل واجهات الأنظمة أو امتثال كل NAT، وقد تغير إعادة الإرسال ترتيب الرصد من دون تغيير المنطق.