تعظم البروتوكول

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

يُعدّ التصلب مشكلة رئيسية في تصميم بروتوكولات الإنترنت ونشرها، إذ قد يمنع نشر بروتوكولات أو امتدادات جديدة على الإنترنت، أو يفرض قيودًا على تصميمها؛ فقد يُضطر المستخدم إلى تضمين بروتوكولات جديدة ضمن بروتوكول مُستخدم بالفعل أو محاكاة بنية بروتوكول آخر. وبسبب هذا التصلب، يُعدّ بروتوكول التحكم بالنقل (TCP) وبروتوكول بيانات المستخدم (UDP) الخيارين العمليين الوحيدين لبروتوكولات النقل على الإنترنت، وقد وصل بروتوكول TCP نفسه إلى درجة عالية من التصلب، مما يجعل توسيعه أو تعديله أمرًا صعبًا.

تشمل الطرق الموصى بها لمنع التصلب تشفير بيانات تعريف البروتوكول، وضمان تفعيل نقاط التوسعة، وعرض تباين صورة الشبكة السلكية بأكبر قدر ممكن؛ ويتطلب معالجة التصلب القائم تنسيقًا بين المشاركين في البروتوكول. يُعدّ QUIC أول بروتوكول نقل من IETF مصمم بخصائص مضادة للتصلب بشكل مقصود.

بحلول عام 2005، بدأ التصلب الملحوظ يظهر على الإنترنت ، ونُشرت تحليلات لهذه المشكلة في ذلك العام أيضاً؛ ^{[ 1 ]} ويشير عمار (2018) إلى أن هذا التصلب كان نتيجة لوصول الإنترنت إلى نطاق عالمي وتحوله إلى شبكة الاتصالات الرئيسية. ^{[ 2 ]}

كان بروتوكول TCP متعدد المسارات أول امتداد لبروتوكول إنترنت أساسي لمواجهة جمود البروتوكول بشكل عميق أثناء تصميمه. ^{[ 3 ]}

أنشأت فرقة عمل هندسة الإنترنت (IETF) فريق عمل خدمات النقل (taps) في عام 2014. ^{[ 4 ]} وتتمثل مهمته في التخفيف من جمود طبقة بروتوكول النقل . ^{[ 5 ]}

يُعد بروتوكول QUIC أول بروتوكول نقل تابع لـ IETF يعمل على تقليل حجم بياناته السلكية عمدًا لتجنب التصلب. ^{[ 6 ]}

حدد مجلس هندسة الإنترنت اعتبارات التصميم المتعلقة بعرض معلومات البروتوكول لعناصر الشبكة باعتبارها "مجالًا ناميًا" في عام 2023. ^{[ 7 ]}

السبب الرئيسي لتصلب البروتوكولات هو تدخل أجهزة الوسيطة ، ^{[ 8 ]} مما يُبطل مبدأ الاتصال من طرف إلى طرف . ^{[ 9 ]} قد تحجب أجهزة الوسيطة البروتوكولات غير المعروفة أو الامتدادات غير المعترف بها للبروتوكولات المعروفة بشكل كامل، أو تتدخل في مفاوضات الامتدادات أو الميزات، أو تُجري تعديلات أكثر توغلاً على بيانات البروتوكول الوصفية. ^{[ 10 ]} ليست كل تعديلات أجهزة الوسيطة مُسببة للتصلب بالضرورة؛ ومن بين التعديلات التي يُحتمل أن تكون ضارة، فإنها تتركز بشكل غير متناسب على حافة الشبكة . ^{[ 11 ]} يقوم مُشغلو الشبكات بنشر أجهزة الوسيطة بشكل أحادي لحل مشاكل مُحددة، ^{[ 12 ]} بما في ذلك تحسين الأداء، ومتطلبات الأمان (مثل جدران الحماية)، وترجمة عناوين الشبكة ، أو تعزيز التحكم في الشبكات. ^{[ 13 ]} توفر عمليات نشر أجهزة الوسيطة هذه فائدة محلية قصيرة الأجل، ولكنها تُضعف قابلية تطور الإنترنت على المدى الطويل عالميًا، في مظهر من مظاهر مأساة المشاعات . ^{[ 12 ]}

يجب أن يتقبل جميع الوسطاء على مسار الاتصال التغييرات التي تطرأ على البروتوكول؛ وإذا رُغِبَ في نشر التغيير على نطاق واسع عبر الإنترنت، فإن ذلك يشمل شريحة كبيرة من الوسطاء على الإنترنت. يجب أن يتقبل جهاز الوسيط البروتوكولات الشائعة الاستخدام كما كانت عليه وقت نشره، ولكنه قد لا يتقبل البروتوكولات الجديدة أو التغييرات التي تطرأ على البروتوكولات الحالية، مما يخلق حلقة مفرغة حيث لا يمكن لصور الأسلاك الجديدة أن تنتشر على نطاق واسع بما يكفي لجعل أجهزة الوسيط تتقبلها عبر الإنترنت بأكمله. ^{[ 9 ]} وحتى تقبل جميع المشاركين للبروتوكول لا يضمن استخدامه: ففي غياب آلية للتفاوض أو الاكتشاف، قد تلجأ نقاط النهاية إلى بروتوكول يُعتبر أكثر موثوقية. ^{[ 14 ]}

إلى جانب أجهزة الوسيط، قد ينتج التصلب أيضًا عن عدم كفاية المرونة في تنفيذ نقطة النهاية. فنوى أنظمة التشغيل بطيئة التغيير والنشر، ^{[ 14 ]} وقد تُصلح البروتوكولات المُنفذة في الأجهزة تفاصيل البروتوكول بشكل غير مناسب. ^{[ 15 ]} كما أن واجهة برمجة التطبيقات (API) الشائعة الاستخدام ، والتي تفترض افتراضات حول تشغيل البروتوكولات الأساسية، قد تعيق نشر البروتوكولات التي لا تشترك في هذه الافتراضات. ^{[ 9 ]}

أوصى مجلس هندسة الإنترنت في عام 2019 باستبدال الإشارات الضمنية الموجهة للمراقبين بإشارات مُخصصة لهم، مع حجب الإشارات غير المُخصصة لهم (مثل التشفير)؛ كما أوصى بحماية سلامة بيانات البروتوكول الوصفية لمنع تعديلها بواسطة أجهزة الوسيط. ^{[ 16 ]} مع ذلك، حتى البيانات الوصفية المُشفرة بالكامل قد لا تمنع تمامًا ظاهرة التصلب في الشبكة، إذ قد تُظهر صورة البروتوكول أنماطًا يُعتمد عليها. ^{[ 17 ]} يستخدم مُشغلو الشبكات البيانات الوصفية لأغراض إدارية متنوعة، ^{[ 18 ]} كما تستفيد أبحاث الإنترنت من البيانات المُجمعة من بيانات البروتوكول الوصفية؛ ^{[ 19 ]} ويجب على مُصمم البروتوكول الموازنة بين مقاومة التصلب وإمكانية المراقبة لتلبية الاحتياجات التشغيلية أو البحثية. ^{[ 17 ]} أركو وآخرون. (2023) يقدم إرشادات إضافية بشأن هذه الاعتبارات: ينبغي أن يكون الكشف عن المعلومات من قِبل بروتوكول للشبكة مقصودًا، ^{[ 20 ]} وأن يتم بموافقة كل من المُرسِل والمُستقبِل، ^{[ 21 ]} وأن يتم التحقق من صحتها بالقدر الممكن والضروري، ^{[ 22 ]} وأن يُعمل بها فقط في حدود موثوقيتها، ^{[ 23 ]} وأن يتم تقليلها إلى الحد الأدنى وتوفيرها لأقل عدد ممكن من الكيانات. ^{[ 24 ] [ 25 ]}

يُعدّ الاستخدام الفعّال لنقاط التوسعة ضروريًا لتجنب جمودها. ^{[ 26 ]} ويمكن أن يُسهم تقليل عدد نقاط التوسعة، وتوثيق الثوابت التي يمكن للمشاركين في البروتوكول الاعتماد عليها بدلًا من التفاصيل العرضية التي لا يجب الاعتماد عليها، والكشف الفوري عن المشكلات في الأنظمة المنشورة، في ضمان الاستخدام الفعّال. ^{[ 27 ]} ومع ذلك، حتى الاستخدام الفعّال قد لا يُفعّل سوى جزء ضيق من البروتوكول، وقد يحدث الجمود في الأجزاء التي تبقى ثابتة عمليًا على الرغم من التباين النظري. ^{[ 28 ] [ 29 ]} ويمكن لـ"تسهيل" نقطة التوسعة، حيث تُشير بعض التطبيقات إلى دعم امتدادات غير موجودة، أن يضمن التسامح مع الامتدادات الموجودة فعليًا ولكن غير المُعترف بها (انظر هندسة الفوضى ). ^{[ 30 ]} تُعدّ رؤوس HTTP مثالًا على نقطة توسعة نجحت في تجنب الجمود الكبير، حيث يتجاهل المشاركون عمومًا الرؤوس غير المُعترف بها. ^{[ 31 ]}

قد يُصمَّم بروتوكول جديد لمحاكاة بنية بروتوكول قائم ومُعتمد؛ ^{[ 32 ]} أو بدلاً من ذلك، يمكن تغليف بروتوكول جديد ضمن بروتوكول قائم ومقبول. من عيوب التغليف وجود عبء إضافي وعمل زائد (مثلًا، تُصبح مجاميع التحقق الخارجية زائدة عن الحاجة بسبب عمليات التحقق الداخلية من سلامة البيانات). ^{[ 33 ]}

إلى جانب أجهزة الوسيط، يمكن مقاومة مصادر التصلب الأخرى. قد يؤدي تطبيق البروتوكولات في مساحة المستخدم إلى تطور أسرع. إذا تم تغليف البروتوكول الجديد في بروتوكول UDP، يصبح تطبيقه في مساحة المستخدم ممكنًا. ^{[ 34 ] [ 35 ]} في حال عدم اليقين بشأن دعم البروتوكولات، قد يجرب المشاركون بروتوكولات بديلة في الوقت نفسه، على حساب زيادة حجم البيانات المرسلة. ^{[ 36 ]}

ببذل الجهد الكافي والتنسيق اللازم، يمكن عكس الجمود مباشرةً. ويمكن ليومٍ مُحدد ، حيث يُجري المشاركون في البروتوكول تغييراتٍ بالتنسيق فيما بينهم، أن يكسر الحلقة المفرغة ويُرسّخ الاستخدام الفعال. وقد استُخدم هذا النهج لنشر نظام أسماء النطاقات الأوروبي (EDNS) ، الذي لم يكن مقبولاً سابقاً من قِبل الخوادم. ^{[ 37 ]}

عانى بروتوكول التحكم بالنقل (TCP) من التصلب. [ 38 ^{] وقد أظهرت} إحدى الدراسات أن ثلث المسارات عبر الإنترنت تواجه وسيطًا واحدًا على الأقل يُعدّل بيانات TCP الوصفية، وأن 6.5% من المسارات تواجه آثارًا ضارة للتصلب من الوسطاء. ^{[ 39 ]} وقد تأثرت امتدادات TCP: فقد قُيّد تصميم MPTCP بسلوك الوسيط، ^{[ 3 ] [ 40 ]} كما تعرقل نشر TCP Fast Open بالمثل. ^{[ 41 ] [ 38 ]}

لم يُستخدم بروتوكول نقل التحكم في التدفق (TCP) على نطاق واسع في الإنترنت بسبب عدم توافقه مع أجهزة الوسيطة، [ 9 ^{] وأيضًا بسبب} عدم ملاءمة واجهة برمجة تطبيقات مقابس BSD واسعة الانتشار لقدراته. ^{[ 42 ]} عمليًا، يُعدّ كل من TCP وUDP بروتوكولي نقل البيانات الوحيدين القابلين للاستخدام على الإنترنت . ^{[ 43 ]}

شهد بروتوكول أمان طبقة النقل (TLS) جمودًا. كان TLS السياق الأصلي لإدخال نقاط توسيع التسهيل. أثبت الإصدار 1.3 من TLS ، بتصميمه الأصلي، عدم قابليته للتطبيق على الإنترنت: فقد جمّدت أجهزة الوسيطة معيار إصدار البروتوكول. اكتُشف هذا في وقت متأخر من عملية تصميم البروتوكول، أثناء عمليات النشر التجريبية بواسطة متصفحات الويب . ونتيجة لذلك، يُحاكي الإصدار 1.3 صورة الشبكة للإصدار 1.2. ^{[ 44 ]}

صُمم بروتوكول QUIC خصيصًا ليكون قابلاً للنشر والتطوير، وليتمتع بخصائص مقاومة التصلب؛ ^{[ 45 ]} وهو أول بروتوكول نقل من IETF يُقلل حجم بياناته السلكية عمدًا لهذه الأغراض. ^{[ 6 ]} وهو مُحسّن، ^{[ 30 ]} وله ثوابت بروتوكولية محددة بوضوح، ^{[ 46 ]} ومُغلف في UDP، وبياناته الوصفية مُشفرة. ^{[ 45 ]} ومع ذلك، يجب أن تكون التطبيقات التي تستخدم QUIC مستعدة للرجوع إلى بروتوكولات أخرى، لأن بعض أجهزة الوسيطة تحظر UDP. ^{[ 47 ]}

• التوافق مع الإصدارات السابقة
• مشكلة العمل الجماعي
• المعيار الفعلي
• التوافق مع الإصدارات اللاحقة
• قابلية التشغيل البيني
• قانون هيروم
• تأثير الشبكة
• مبدأ المتانة
• احتكار المورد

• تراميل، برايان؛ كوهلويند، ميرجا (أبريل 2019). صورة سلكية لبروتوكول شبكة . IETF . doi : 10.17487/RFC8546 . RFC 8546 .
• هاردي، تيد، محرر. (أبريل 2019). إشارات مسار بروتوكول النقل . IETF . doi : 10.17487/RFC8558 . RFC 8558 .
• طومسون ، مارتن (مايو 2021). خصائص الإصدار المستقل لـ QUIC . فريق عمل الإنترنت . دوى : 10.17487/RFC8999 . آر إف سي 8999 .
• فيرهيرست، غوري؛ بيركنز، كولين (يوليو 2021). اعتبارات حول سرية رأس النقل، وعمليات الشبكة، وتطور بروتوكولات نقل الإنترنت . IETF . doi : 10.17487/RFC9065 . RFC 9065 .
• تومسون، مارتن؛ باولي، تومي (ديسمبر 2021). جدوى آليات توسيع البروتوكول على المدى الطويل . IETF . doi : 10.17487/RFC9170 . RFC 9170 .
• كوليويند، ميرجا؛ تراميل، برايان (سبتمبر 2022). قابلية تطبيق بروتوكول نقل QUIC . IETF . doi : 10.17487/RFC9308 . RFC 9308 .
• أركو، جاري؛ هاردي، تيد؛ باولي، تومي؛ كوليويند، ميرجا (يوليو 2023). اعتبارات حول التعاون الشبكي التطبيقي باستخدام إشارات المسار . IETF . doi : 10.17487/RFC9419 . RFC 9419 .
• هوندا، ميتشيو؛ نيشيدا، يوشيفومي؛ رايسيو، كوستين؛ غرينهاغ، آدم؛ هاندلي، مارك ؛ توكودا، هيديوكي (2011). هل لا يزال من الممكن توسيع بروتوكول TCP؟ مؤتمر ACM SIGCOMM لعام 2011 حول قياس الإنترنت. doi : 10.1145/2068816.2068834 .
• رايسيو، كوستين؛ باش، كريستوف؛ بار، سيباستيان؛ فورد، آلان؛ هوندا، ميتشيو؛ دوشين، فابيان؛ بونافنتور، أوليفييه؛ هاندلي، مارك (2012). ما مدى صعوبة ذلك؟ تصميم وتنفيذ بروتوكول TCP متعدد المسارات قابل للنشر . ندوة USENIX التاسعة حول تصميم وتنفيذ الأنظمة الشبكية (NSDI 12).
• هيسمانز، بنيامين؛ دوشين، فابيان؛ باش، كريستوف؛ ديتال، غريغوري؛ بونافنتور، أوليفييه (2013). هل امتدادات بروتوكول TCP مقاومة لهجمات الوسيط؟ . HotMiddlebox '13. CiteSeerX 10.1.1.679.6364 . doi : 10.1145/2535828.2535830 . 
• كوربيت، جوناثان (8 ديسمبر 2015). "تفريغ التحقق من المجموع الاختباري وتصلب البروتوكول" . LWN.net .
• كوربيت، جوناثان (20 يونيو 2016). "بروتوكولات مستوى النقل في مساحة المستخدم" . LWN.net .
• ماكويستين، ستيفن؛ بيركنز، كولين؛ فايد، مروان (يوليو 2016). تطبيق خدمات النقل في الوقت الحقيقي عبر شبكة جامدة . ورشة عمل أبحاث الشبكات التطبيقية 2016. doi : 10.1145/2959424.2959443 . hdl : 1893/26111 .
• باباستيرجيو، جيورجوس؛ فيرهيرست، جوري؛ روس، ديفيد؛ برونستروم، آنا؛ جرينيمو، كارل يوهان؛ هورتيج، بير؛ خادمي، نعيم؛ توكسن، مايكل؛ ويلزل، مايكل؛ داميانوفيتش، دراغانا؛ مانجيانتي، سيمون (2017). "تبسيط طبقة نقل الإنترنت: دراسة استقصائية وآفاق مستقبلية". مجلة IEEE للبحوث والدراسات في مجال الاتصالات . 19 : 619-639 . doi : 10.1109/COMST.2016.2626780 . hdl : 2164/8317 . S2CID 1846371 . 
• سوليفان، نيك (26 ديسمبر 2017). "لماذا لم يتم تضمين بروتوكول TLS 1.3 في المتصفحات حتى الآن؟" . مدونة كلاود فلير . تم الاطلاع عليه بتاريخ 14 مارس 2020 .
• عمار، مصطفى (يناير 2018). "من وحدة متعددة: دورة البنية التحتية للخدمات، والتصلب، وتجزئة الإنترنت". مجلة ACM SIGCOMM لمراجعات اتصالات الحاسوب. doi : 10.1145/3211852.3211861 . S2CID 12169344 . 
• كوربيت ، جوناثان (29 يناير 2018). "QUIC كحل لتعظم البروتوكول" . LWN.net .
• إيدلين، كوريان؛ دونيه، بينوا (2019). دراسة من الأسفل إلى الأعلى لتصلب طبقة النقل . مؤتمر قياس وتحليل حركة مرور الشبكة لعام 2019 (TMA). doi : 10.23919/TMA.2019.8784690 .
• ريبتشينسكا، مارتا (13 مارس 2020). "نظرة سريعة على بروتوكول HTTP/3 باستخدام QUIC" . LWN.net .

• تراميل، برايان؛ كوهلويند، ميرجا، محرران. (أكتوبر 2015). تقرير من ورشة عمل IAB حول تطور المكدس في إنترنت الوسيط (SEMI) . IETF . doi : 10.17487/RFC7663 . RFC 7663 .