الخلاصة

  • تسمح RFC 7413 لعميل يحتفظ بملف ارتباط أصدره الخادم بإرسال بيانات التطبيق داخل SYN، وللخادم بتسليمها قبل اكتمال المصافحة الثلاثية.
  • يمكن توفير رحلة ذهاب وإياب كاملة، لكن بيانات SYN قد تصل إلى التطبيق أكثر من مرة؛ لذلك لا يصلح الأسلوب لعملية لا تتحمل إعادة التنفيذ.
  • يعتمد المسار السريع على تدوير مفاتيح منضبط، وحد للعمل غير المؤكد، وذاكرة سلبية لكل مسار، ورجوع موثوق إلى مصافحة TCP العادية.

في TCP التقليدي تحمل الحزمة الأولى طلباً ببدء الاتصال. أما TCP Fast Open فيسمح لها بأن تحمل أيضاً أول طلب للتطبيق. إذا تعرّف الخادم على ملف ارتباط صالح، يستطيع تمرير البيانات إلى التطبيق قبل وصول الحزمة الثالثة من المصافحة. لم تصبح الشبكة أقصر؛ الذي تغيّر هو ترتيب الانتظار.

نُشرت RFC 7413 في ديسمبر 2014 بوصفها مواصفة تجريبية وليست وثيقة في مسار معايير الإنترنت. وهذا يمنع تحويل التصميم إلى ادعاء عن الانتشار أو النجاح الحالي. فالوثيقة تحدد آلية قابلة للاختبار: عميل سبق أن حصل على ملف ارتباط، ووحدة تطبيق أولى صغيرة بما يكفي، ومسار يقبل SYN المحتوية على بيانات. عند اجتماع هذه الشروط يمكن توفير ما يصل إلى RTT واحد.

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

هذا الوسم دليل على إمكانية الوصول السابقة إلى عنوان المصدر، وليس هوية مستخدم أو تفويض معاملة. تحدد RFC طولاً بين 4 و16 بايت، وتصف عادة وسم MAC مرتبطاً بعنوان IP للعميل. لا يفسر العميل محتواه. يتحكم الخادم في الإنشاء والتحقق والانتهاء، ويمكنه إبطال الملفات القديمة بتغيير المفتاح أو قبول أكثر من مفتاح خلال الانتقال. لذلك يؤثر عمر المفتاح وفترة التداخل في توافر الخدمة.

الثمن الدلالي الأهم هو احتمال إعادة التنفيذ. تساعد المصافحة الثلاثية TCP على التمييز بين اتصال جديد وحزمة SYN قديمة أو مكررة. عندما تُسلّم بيانات SYN قبل اكتمال هذا الحد، قد تُسلّم الرسالة الأولى مرة أخرى بعد زوال الحالة الأصلية. ولهذا تمنع RFC تشغيل TFO افتراضياً، وتشترط أن يطلبه التطبيق صراحة لكل منفذ خدمة.

تصبح خاصية عدم تغيير النتيجة عند التكرار شرطاً لاستخدام التحسين. غالباً ما يمكن تكرار القراءة بأمان، أما إنشاء مورد أو تحصيل دفعة أو POST غير محمي فلا يستطيع افتراض تنفيذ وحيد. يمكن لمعرّف معاملة في طبقة التطبيق كشف النسخة المكررة، لكن ملف ارتباط Fast Open لا يقدم ضمان exactly-once. تقديم البيانات في الزمن لا يقدم اليقين معها.

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

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

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

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

القيمة التاريخية لـ TCP Fast Open أنه أظهر حساب الزمن بدقة. توفير RTT واحد ينشئ حالة جديدة: أي عناوين كانت قابلة للوصول، وأي ملفات ارتباط ما زالت صالحة، وأي عمليات تتحمل التكرار، وكم عملاً يمكن قبوله قبل التأكيد، وأي مسارات تستوجب التراجع. لا يصبح الطلب المبكر أسرع فعلاً إلا إذا كانت هذه الحالة قابلة للرصد والحد والعكس.

Sources