منذ أكثر من 20 عامًا ، كنا نعرض صفحات الويب باستخدام بروتوكول HTTP. معظم المستخدمين لا يفكرون مطلقًا في ماهية هذه الطريقة وكيف تعمل. يعلم الآخرون أنه في مكان ما ضمن HTTP ، يوجد بروتوكول TLS ، وتحته يوجد بروتوكول TCP (بروتوكول التحكم في الإرسال) ، وبموجبه بروتوكول الإنترنت (IP) وما إلى ذلك. أما الثالث - الهراطقة - فيعتقد أن TCP هو القرن الماضي ، فهم يريدون شيئًا أسرع وأكثر موثوقية وأكثر أمانًا. لكن في محاولاتهم لابتكار بروتوكول مثالي جديد ، عادوا إلى تقنيات الثمانينات ويحاولون بناء عالمهم الجديد الشجاع عليهم.
قليلا من التاريخ: HTTP / 1.1
في عام 1997 ، اكتسب بروتوكول تبادل نص HTTP الإصدار 1.1 RFC الخاص به. في ذلك الوقت ، تم استخدام البروتوكول بواسطة المتصفحات لعدة سنوات ، واستمر المعيار الجديد خمسة عشر أخرى. كان البروتوكول يعمل فقط على أساس الاستجابة للطلب وكان الغرض منه في المقام الأول إرسال المعلومات النصية.
تم تصميم HTTP للعمل على رأس بروتوكول TCP ، والذي يضمن تسليم موثوق للحزم إلى الوجهة. يعتمد TCP على إنشاء والحفاظ على اتصال موثوق بين نقاط النهاية وحركة التجزئة. القطاعات لها رقم التسلسل والاختبار الخاص بها. إذا لم يأت أحد القطاعات فجأة أو جاء مع المجموع الاختباري الخاطئ ، فسيتوقف ناقل الحركة حتى تتم استعادة الجزء المفقود.
في HTTP / 1.0 ، تم إغلاق اتصال TCP بعد كل طلب. كان مضيعة للغاية منذ ذلك الحين لا يعتبر إنشاء اتصال TCP (المصافحة الثلاثية) عملية سريعة. قدم HTTP / 1.1 آلية المحافظة على الحياة ، والتي تتيح لك إعادة استخدام اتصال واحد لطلبات متعددة. ومع ذلك ، نظرًا لأنه يمكن أن يصبح عنق الزجاجة بسهولة ، يُسمح بعدة اتصالات TCP / IP لنفس المضيف في تطبيقات HTTP / 1.1 مختلفة. على سبيل المثال ، في Chrome والإصدارات الأخيرة من Firefox ، يُسمح بحد أقصى ستة اتصالات.
كان من المفترض أيضًا ترك التشفير لبروتوكولات أخرى ، ولهذا ، تم استخدام بروتوكول TLS عبر TCP ، والذي يحمي البيانات بشكل موثوق ، ولكنه زاد من الوقت اللازم لإنشاء اتصال. نتيجة لذلك ، بدأت عملية المصافحة لتبدو كما يلي:
Cloudflare، تصويروبالتالي ، واجه HTTP / 1.1 عددًا من المشكلات:
- إعداد اتصال بطيء.
- يتم استخدام اتصال TCP واحد لطلب واحد ، مما يعني أن بقية الطلبات يجب إما العثور على اتصال آخر ، أو الانتظار حتى يصدر الطلب الحالي.
- فقط نموذج السحب مدعوم. لا يوجد شيء في المعيار حول خادم دفع.
- تنتقل العناوين في النص.
إذا تم تطبيق خادم الدفع بطريقة أو بأخرى باستخدام بروتوكول WebSocket ، فيجب التعامل مع بقية المشكلات بشكل جذري.
قليلا من الحداثة: HTTP / 2
في عام 2012 ، بدأ العمل على بروتوكول SPDY (المعروف بـ "السرعة") في أحشاء Google. تم تصميم البروتوكول لحل المشكلات الأساسية لـ HTTP / 1.1 وفي نفس الوقت كان عليه الحفاظ على التوافق مع الإصدارات السابقة. في عام 2015 ، قدمت مجموعة عمل IETF مواصفات HTTP / 2 استنادًا إلى بروتوكول SPDY. فيما يلي الاختلافات في HTTP / 2:
- التسلسل الثنائي.
- مضاعفة طلبات HTTP متعددة في اتصال TCP واحد.
- خادم دفع خارج الصندوق (بدون WebSocket).
كان البروتوكول خطوة كبيرة إلى الأمام.
يتفوق هذا بشكل كبير
على الإصدار الأول ولا يتطلب إنشاء عدة اتصالات TCP: يتم مضاعفة جميع الطلبات إلى مضيف واحد في واحد. وهذا يعني ، في اتصال واحد ، العديد من التدفقات المزعومة ، لكل منها معرفها الخاص. المكافأة هي دفع خادم محاصر.
ومع ذلك ، يؤدي الضرب إلى مشكلة حجر الزاوية الأخرى. تخيل أننا ننفذ بشكل غير متزامن 5 طلبات لخادم واحد. عند استخدام HTTP / 2 ، سيتم تنفيذ جميع هذه الطلبات ضمن نفس اتصال TCP ، مما يعني أنه في حالة فقد أحد شرائح أي طلب أو وصوله بشكل غير صحيح ، سيتوقف نقل جميع الطلبات والاستجابات حتى تتم استعادة الجزء المفقود. من الواضح أنه كلما كانت جودة الاتصال أسوأ ، يعمل HTTP / 2 الأبطأ.
وفقًا لدانييل ستينبرج ، في حالة تشكل الحزم المفقودة فيها 2٪ من كل شيء ، فإن أداء HTTP / 1.1 في متصفح أفضل من HTTP / 2 نظرًا لحقيقة أنه يفتح 6 اتصالات وليس واحدًا.
تسمى هذه المشكلة "حظر رأس الخط" ، وللأسف ، لا يمكن حلها باستخدام TCP.
دانيال شتاينبرغنتيجةً لذلك ، قام مطورو معيار HTTP / 2 بعمل رائع وفعلوا كل ما يمكن فعله تقريبًا على مستوى التطبيق في نموذج OSI. حان الوقت للنزول إلى مستوى النقل وابتكار بروتوكول نقل جديد.
نحن بحاجة إلى بروتوكول جديد: UDP مقابل TCP
بسرعة كبيرة أصبح من الواضح أن إدخال بروتوكول طبقة نقل جديد تمامًا هو مهمة غير قابلة للحل في حقائق اليوم. والحقيقة هي أن الغدد أو الصناديق المتوسطة (أجهزة التوجيه ، والجدران النارية ، وخوادم NAT ...) تعرف مستوى النقل ، وتعليمهم شيء جديد مهمة صعبة للغاية. بالإضافة إلى ذلك ، يتم دعم بروتوكولات النقل في نواة أنظمة التشغيل ، كما أن النوى لا تتغير أيضًا عن طيب خاطر.
وهنا يمكن للمرء أن يستسلم ويقول "نحن ، بالطبع ، سنخترع HTTP / 3 جديدًا مع التفضيل والمحظيات ، ولكن سيتم تنفيذه في غضون 10-15 سنة (بعد هذا الوقت تقريبًا سيتم استبدال معظم الغدد)" ، ولكن لا يوجد واحد آخر أكثر خيار واضح: استخدام بروتوكول UDP. نعم ، نعم ، نفس البروتوكول الذي ألقينا به الملفات على شبكة LAN في نهاية التسعينات وبداية الصفر. تقريبا كل قطع الحديد اليوم تعرف كيف تتعامل معها.
ما هي مزايا UDP عبر TCP؟ بادئ ذي بدء ، ليس لدينا جلسة مستوى نقل يعرفها الحديد. هذا يتيح لنا تحديد الجلسة على نقاط النهاية بأنفسنا وحل النزاعات التي تنشأ هناك. أي أننا لا نقتصر على جلسة واحدة أو عدة جلسات (كما هو الحال في TCP) ، ولكن يمكننا إنشاءها بقدر ما نحتاج. ثانياً ، نقل البيانات عبر UDP أسرع من TCP. وبالتالي ، من الناحية النظرية ، يمكننا اختراق سقف السرعة اليوم الذي تحقق في HTTP / 2.
ومع ذلك ، لا يضمن UDP نقل البيانات بشكل موثوق. في الواقع ، نحن ببساطة نرسل الحزم ، على أمل أن يتم استلامها في الطرف الآخر. لم تتلقى؟ حسنًا ، لا حظ ... لقد كان هذا كافيًا لنقل الفيديو للبالغين ، ولكن بالنسبة للأشياء الأكثر خطورة ، فأنت بحاجة إلى الموثوقية ، مما يعني أنه يجب عليك تعليق شيء آخر أعلى UDP.
كما هو الحال مع HTTP / 2 ، بدأ العمل على إنشاء بروتوكول جديد في Google في عام 2012 ، أي في نفس وقت بدء العمل على SPDY. في عام 2013 ، قدم Jim Roskind
بروتوكول QUIC (اتصالات الإنترنت السريعة UDP) لعامة الناس ، وتم بالفعل تقديم مسودة الإنترنت في عام 2015 لتوحيد IETF. بالفعل في ذلك الوقت ، كان البروتوكول الذي طورته روسكيند على Google مختلفًا تمامًا عن البروتوكول القياسي ، لذلك سمي إصدار Google باسم gQUIC.
ما هو سريع
أولاً ، كما ذكرنا سابقًا ، هذا ملف مجمّع على UDP. يرتفع الاتصال السريع فوق UDP ، والذي من خلال القياس مع HTTP / 2 ، قد توجد عدة تدفقات. هذه التدفقات موجودة فقط في نقاط النهاية ويتم تقديمها بشكل مستقل. إذا حدث فقدان الحزمة في دفق واحد ، فلن يؤثر ذلك على البتات الأخرى بأي طريقة.
دانيال شتاينبرغثانياً ، يتم تنفيذ التشفير الآن ليس على مستوى منفصل ، ولكن يتم تضمينه في البروتوكول. يتيح لك ذلك إنشاء اتصال وتبادل المفاتيح العامة في مصافحة واحدة ، كما يتيح لك استخدام آلية مصافحة 0-RTT الصعبة وتجنب التأخير في المصافحة عمومًا. بالإضافة إلى ذلك ، يمكن الآن تشفير حزم البيانات الفردية. يتيح لك هذا عدم انتظار استكمال تلقي البيانات من الدفق ، ولكن فك تشفير الحزم المستلمة بشكل مستقل. لم يكن وضع التشغيل هذا ممكنًا على الإطلاق في TCP ، لأن عمل TLS و TCP بشكل مستقل عن بعضهما البعض ، ولم يتمكن TLS من معرفة الأجزاء التي ستقطعها بيانات TCP. وبالتالي ، لم أتمكن من إعداد مقاطعي بحيث تنسجم مع شرائح TCP من واحد إلى واحد ويمكن فك تشفيرها بشكل مستقل. كل هذه التحسينات تسمح لجهاز QUIC بتقليل زمن الانتقال مقارنةً بـ TCP.
ثالثًا ، يتيح لك مفهوم التدفقات السهلة فك الارتباط من عنوان IP الخاص بالعميل. هذا مهم ، على سبيل المثال ، عندما ينتقل العميل من نقطة وصول Wi-Fi إلى أخرى ، ويغير عنوان IP الخاص به. في هذه الحالة ، عند استخدام TCP ، تحدث عملية طويلة تحدث خلالها اتصالات TCP الحالية في المهلة ويتم إنشاء اتصالات جديدة من IP الجديد. في حالة QUIC ، يواصل العميل ببساطة إرسال الحزم من IP الجديد إلى الخادم بمعرف الدفق القديم. لأن يعد Stream ID فريدًا ولا يتم إعادة استخدامه ، ويدرك الخادم أن العميل قام بتغيير IP ، ويرسل الحزم المفقودة ويواصل الاتصال إلى العنوان الجديد.
رابعا ، يتم تطبيق QUIC على مستوى التطبيق ، وليس على نظام التشغيل. هذا ، من ناحية ، يسمح بإجراء تغييرات أسرع على البروتوكول ، مثل للحصول على تحديث ، ما عليك سوى تحديث المكتبة ، بدلاً من الانتظار للحصول على إصدار جديد من نظام التشغيل. من ناحية أخرى ، يؤدي هذا إلى زيادة قوية في استهلاك المعالج.
وأخيرا ، عناوين الصحف. يشير ضغط الرأس فقط إلى النقاط التي تختلف في QUIC و gQUIC. لا أرى أي سبب لتخصيص الكثير من الوقت لذلك ، لا يمكنني إلا أن أقول أنه في الإصدار المقدم للتوحيد القياسي ، تم ضغط الضغط على رأس الصفحة بشكل مشابه قدر الإمكان لضغط الرأس في HTTP / 2. يمكن قراءة المزيد من التفاصيل
هنا .
كم هو أسرع؟
هذا سؤال صعب. الحقيقة هي أنه بينما ليس لدينا معيار ، لا يوجد شيء خاص للقياس. ربما تكون الإحصائيات الوحيدة المتوفرة لدينا هي إحصائيات Google ، والتي تستخدم gQUIC منذ عام 2013 وفي عام 2016
أبلغت IETF أن حوالي 90٪ من حركة المرور التي تذهب إلى خوادمهم من متصفح Chrome تستخدم الآن QUIC. في نفس العرض التقديمي ، ذكروا أنه من خلال gQUIC ، يتم تحميل الصفحات بمعدل أسرع بنحو 5٪ ، كما يتدفق بث الفيديو بنسبة 30٪ مقارنةً بـ TCP.
في عام 2017 ، نشرت مجموعة من الباحثين بقيادة أراش مولوي كاخكي عملاً
كبيراً في دراسة أداء GQUIC مقارنةً بـ TCP.
كشفت الدراسة عن العديد من نقاط ضعف gQUIC ، مثل عدم الاستقرار في خلط حزم الشبكة ، والظلم في سعة القناة ونقل أبطأ للأشياء الصغيرة (حتى 10 كيلو بايت). ومع ذلك ، يمكن تعويض الأخير لاستخدام 0 RTT. في جميع الحالات الأخرى التي تم التحقيق فيها ، أظهرت gQUIC زيادة في السرعة مقارنة بـ TCP. من الصعب التحدث عن أرقام محددة. من الأفضل قراءة
الدراسة نفسها أو
وظيفة قصيرة .
يجب أن يقال هنا أن هذه البيانات تتعلق بالتحديد بـ gQUIC ، وأنها ليست ذات صلة بالمعيار الجاري تطويره. ماذا سيحدث لـ QUIC: حتى الآن ، يكمن اللغز وراء سبعة أختام ، ولكن هناك أمل في أن تؤخذ نقاط الضعف التي حددتها GQUIC في الاعتبار وتصحيحها.
مستقبل قليل: ماذا عن HTTP / 3؟
وهنا كل شيء واضح تمامًا: لن يتغير API بأي طريقة. سيبقى كل شيء كما كان في HTTP / 2 تمامًا. حسنًا ، إذا ظلت واجهة برمجة التطبيقات كما هي ، فسيتم تحديد الانتقال إلى HTTP / 3 باستخدام أحدث إصدار من المكتبة التي تدعم النقل عبر QUIC على الواجهة الخلفية. صحيح ، لفترة طويلة لا يزال يتعين عليك الاحتفاظ بالرجوع إلى الإصدارات القديمة من HTTP ، لأن الإنترنت الآن غير جاهز للتبديل الكامل إلى UDP.
الذي يدعم بالفعل
فيما يلي
قائمة بالتطبيقات الحالية السريعة. على الرغم من عدم وجود معيار ، فإن القائمة ليست سيئة.
لا يوجد متصفح يدعم حاليا QUIC في الإصدار. في الآونة الأخيرة ، كانت هناك معلومات شملت Chrome دعم HTTP / 3 ، ولكن حتى الآن فقط في Canary.
من الخلفية ، يدعم HTTP / 3 فقط
Caddy و
Cloudflare ، ولكن حتى الآن تجريبيًا.
أعلنت NGINX في أواخر ربيع عام 2019 أنها بدأت العمل على دعم HTTP / 3 ، لكنها لم تكمله بعد.
ما هي المشاكل
نحن نعيش في العالم الحقيقي ، حيث لا يمكن لأي تقنية كبيرة أن تذهب إلى الجماهير دون مواجهة المقاومة ، والجودة ليست استثناء.
الأهم من ذلك ، تحتاج إلى أن تشرح للمتصفح بطريقة أو بأخرى أن "https: //" لم يعد حقيقة تؤدي إلى منفذ TCP 443rd. قد لا يكون هناك TCP على الإطلاق. للقيام بذلك ، استخدم رأس Alt-Svc. إنها تتيح للمتصفح أن يكون على علم بأن هذا الموقع متاح أيضًا على مثل هذا البروتوكول وعلى هذا العنوان وعلى هذا العنوان. من الناحية النظرية ، يجب أن يعمل هذا كأنه ساعة ، لكن في الممارسة العملية ، نتعثر من حقيقة أن UDP ، على سبيل المثال ، يمكن تعطيلها على جدار الحماية لتجنب هجمات DDoS.
ولكن حتى إذا لم يتم حظر UDP ، فقد يكون العميل وراء جهاز توجيه NAT تم تكوينه لعقد جلسة TCP عبر عنوان IP ، كما نستخدم UDP ، حيث لا توجد جلسة أجهزة ، ولن تعقد NAT الاتصال ،
وسيتم دائمًا إنهاء جلسة QUIC.
ترتبط كل هذه المشكلات بحقيقة أن UDP لم يتم استخدامه سابقًا لنقل محتوى الإنترنت ، ولم يكن من المتوقع لمصنعي الأجهزة توقع حدوث ذلك على الإطلاق. بنفس الطريقة ، لا يفهم المسؤولون بعد كيفية تكوين شبكاتهم بشكل صحيح لـ QUIC. سوف يتغير هذا الموقف ببطء ، وفي أي حال ، سوف تستغرق هذه التغييرات وقتًا أقل من إدخال بروتوكول طبقة النقل الجديد.
بالإضافة إلى ذلك ، كما هو موضح بالفعل ، تزيد QUIC بشكل كبير من استخدام المعالج. قام دانيال ستينبرج
بتصنيف النمو على المعالج ثلاث مرات.
عندما يأتي HTTP / 3
إنهم
يريدون تبني المعيار بحلول مايو 2020 ، ولكن بالنظر إلى أن الوثائق المقرر إجراؤها في يوليو 2019 لم تكتمل بعد ، فيمكننا القول إنه من المرجح أن يتم تأجيل الموعد.
حسنًا ، تستخدم Google تطبيق gQUIC منذ عام 2013. إذا نظرت إلى طلب HTTP الذي تم إرساله إلى محرك بحث Google ، يمكنك رؤية هذا:
النتائج
QUIC الآن تبدو وكأنها تقنية خام ، لكنها واعدة للغاية. بالنظر إلى أنه على مدار العشرين عامًا الماضية ، أصبحت جميع عمليات تحسين بروتوكولات طبقة النقل المتعلقة بشكل أساسي بـ TCP و QUIC ، والتي تفوق في الأداء في معظم الحالات ، جيدة للغاية الآن.
ومع ذلك ، لا تزال هناك مشاكل لم يتم حلها والتي يجب معالجتها في السنوات القليلة المقبلة. قد تتأخر العملية نظرًا لحقيقة أن الأجهزة متورطة ، والتي لا يحب أحد تحديثها ، ولكن مع ذلك تبدو جميع المشكلات قابلة للحل ، وسنحصل جميعًا على HTTP / 3 عاجلاً أم آجلاً.
المستقبل ليس بعيدًا!