ما هو HTTP / 3 - معلومات داخلية على البروتوكول السريع الجديد المستند إلى UDP

TL ؛ DR

في نوفمبر 2018 ، اجتمع فريق عمل هندسة الإنترنت (IETF) في بانكوك ، وتم اعتماد مسودة إنترنت جديدة. تمت إعادة تسمية بروتوكول النقل QUIC ، وهو HTTP / 2 الوريث ، إلى HTTP / 3.

يعتمد HTTP / 3 على بروتوكول مخطط بيانات المستخدم (UDP) ، ويتم استخدامه بالفعل من قبل شركات الإنترنت البارزة مثل Google و Facebook. إذا كنت تستخدم Chrome وتتصل بإحدى خدمات Google ، فمن المحتمل أنك تستخدم QUIC بالفعل.

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

النتائج الأولى واعدة ، وعندما تنتهي مسودة الإنترنت من قبل IETF ، في أغسطس 2021 ، يمكننا أن نتوقع ترقية HTTP / 3 كمعيار HTTP جديد من الجيل الثالث.

تقدم HTTP / 3 في عام 2022

يقول البعض إن تعطش صناعة الويب إلى مزيد من السرعة ووقت استجابة أقل لا يقابله سوى تعطش Google Chrome لمزيد من ذاكرة الوصول العشوائي.

قبل بضع سنوات ، نشرنا مقالًا حول HTTP / 2 ، وهو معيار وصل الآن ، وفقًا لشركة W3Techs ، إلى حوالي 45٪ من معدل التبني العالمي. ووفقًا لـ Can I Use ، فهي مدعومة أيضًا من قبل جميع متصفحات الويب الحديثة. وها نحن نكتب مقالاً عن الإصدار التالي من البروتوكول HTTP / 3.

كان HTTP / 3 ، في وقت كتابة هذه السطور ، مسودة أو معرّف إنترنت IETF ، مما يعني أنه قيد الدراسة حاليًا لمعيار الإنترنت القادم من قبل فريق هندسة الإنترنت - هيئة معايير الإنترنت الدولية ، المسؤولة عن تحديد وتعزيز معايير بروتوكول الإنترنت المتفق عليها ، مثل TCP و IPv6 و VoIP وإنترنت الأشياء وما إلى ذلك.

إنها هيئة مفتوحة توحد صناعة الويب وتسهل المناقشة حول اتجاه الإنترنت. حاليًا ، تعد مرحلة "مسودة الإنترنت" الخاصة بـ HTTP / 3 هي المرحلة الأخيرة قبل ترقية المقترحات إلى مستوى طلب التعليقات (أو RFCs) ، والتي يمكننا اعتبارها ، لجميع المقاصد والأغراض ، تعريفات بروتوكول الإنترنت الرسمية.

على الرغم من أن HTTP / 3 ليس بروتوكول إنترنت رسميًا حتى الآن ، فقد بدأت العديد من الشركات والمشاريع بالفعل في إضافة دعم HTTP / 3 إلى منتجاتها.

دعم مستعرض الويب لـ HTTP / 3

على واجهة متصفح الويب ، تم تمكين HTTP / 3 افتراضيًا في كل من Chrome v87 و Firefox v88 و Edge v87. لمستخدمي Safari ، تمت إضافة خيار تمكين HTTP / 3 إلى Safari Technology Preview v104. ومع ذلك ، لا يتوفر دعم HTTP / 3 حاليًا في الإصدار الثابت من Safari.

دعم المكتبة لـ HTTP / 3

للمطورين الذين يتطلعون إلى الاستفادة من تقنيات HTTP / 3 ، أضافت العديد من المكتبات الشائعة بالفعل دعمًا لـ HTTP / 3. نظرًا لأن HTTP / 3 لا يزال في مرحلة "مسودة الإنترنت" ، فستحتاج إلى التأكد من مواكبة آخر التحديثات عند العمل مع إحدى المكتبات أدناه.

• بايثون - HTp3 و aioquic
• الصدأ - كيشي ، ونيكو ، وكوين
• ج - nghttp3 و lsquic
• اذهب - quicgo
• جافا سكريبت - Node.js

دعم البنية التحتية لـ HTTP / 3

على جانب البنية التحتية ، كانت Cloudflare رائدة في دعمها لـ HTTP / 3 عبر شبكتها الطرفية بالكامل. هذا يعني أن المواقع التي تم تمكين Cloudflare لها يمكنها الاستفادة من تحسينات الأمان والأداء لـ HTTP / 3 دون أي عمل إضافي.

في Kinsta ، جميع المواقع التي نستضيفها محمية بواسطة تكامل Cloudflare المجاني. بالإضافة إلى جدار الحماية على مستوى المؤسسة وحماية DDoS ، يمكن لعملاء Kinsta أيضًا الوصول إلى HTTP / 3!

لاختبار ما إذا كان موقعك يدعم HTTP / 3 ، يمكنك استخدام أداة اختبار HTTP / 3 الخاصة بـ Geekflare. ما عليك سوى كتابة المجال الخاص بك والضغط على الزر "التحقق من HTTP / 3" ، وستتيح لك الأداة معرفة ما إذا كان موقعك ممكّنًا لـ HTTP / 3.

إذا كان موقعك يدعم HTTP / 3 ، فمن المفترض أن ترى رسالة مثل تلك الموجودة أدناه. نظرًا لاستضافة kinstalife.com على Kinsta ، يتم دعم HTTP / 3 بالكامل بفضل تكامل Cloudflare.

يمكنك أيضًا استخدام فاحص المستعرض الخاص بك للتحقق من دعم HTTP / 3. في هذا المثال ، سنستخدم أحدث إصدار من Google Chrome والذي يدعم HTTP / 3.

لفتح المفتش ، انقر بزر الماوس الأيمن على الصفحة وانقر على "فحص" وانتقل إلى علامة التبويب "الشبكة". في عمود "البروتوكول" ، يمكنك رؤية بروتوكول HTTP المستخدم للاتصال. تظهر اتصالات HTTP / 2 كـ "h2" ، بينما تظهر اتصالات HTTP / 3 كـ "h3-XX" (XX تشير إلى مسودة HTTP / 3 محددة). كما ترى في الصورة أدناه ، يدعم kinstalife.com الاتصالات عبر "h3-29" ، وهو ما يعني "HTTP / 3 Draft 29".

الآن بعد أن تجاوزنا الحالة الحالية لـ HTTP / 3 ، دعنا نلقي نظرة عميقة على بعض الاختلافات بين HTTP / 2 مقابل HTTP / 3!

القليل من الخلفية - بدأت بـ HTTP / 2

جلب HTTP / 2 بعض التحسينات الجادة من خلال التنزيلات غير المحظورة وتوصيل الأنابيب ودفع الخادم ، الأمر الذي ساعدنا في التغلب على بعض قيود بروتوكول TCP الأساسي. لقد سمح لنا بتقليل عدد دورات الطلب والاستجابة والمصافحات.

أتاح HTTP / 2 إمكانية دفع أكثر من مورد في اتصال TCP واحد - مضاعفة الإرسال. لقد حصلنا أيضًا على مزيد من المرونة في ترتيب التنزيلات الثابتة ، ولم تعد صفحاتنا الآن مقيدة بالتقدم الخطي للتنزيلات.

من الناحية العملية ، هذا يعني أن مورد جافا سكريبت كبير لا يساوي بالضرورة نقطة الاختناق لجميع الموارد الثابتة الأخرى التي تنتظر دورها.

أضف إلى هذه الأشياء ضغط HPACK الخاص برأس HTTP / 2 والتنسيق الثنائي الافتراضي لنقل البيانات ، ولدينا ، في كثير من الحالات ، بروتوكول أكثر كفاءة بشكل ملحوظ.

جعلت تطبيقات المستعرض الرئيسية من متطلبات مواقع الويب تنفيذ التشفير - SSL - لتكون قادرة على جني فوائد HTTP / 2 - وفي بعض الأحيان تكبد هذا الأمر عبئًا في الحساب جعل تحسينات السرعة غير ملحوظة. كانت هناك بعض الحالات التي أبلغ فيها المستخدمون عن حدوث تباطؤ بعد الانتقال إلى HTTP / 2.

دعنا نقول فقط أن الأيام الأولى لاعتماد هذا الإصدار لم تكن لضعاف القلوب.

افتقر تطبيق Nginx أيضًا إلى ميزة دفع الخادم ، والتي تعتمد على الوحدة النمطية. ووحدات Nginx ليست وحدات Apache المعتادة التي يمكنك نسخها فقط - يجب إعادة تجميع NGINX مع هذه الوحدات.

بينما يتم حل بعض هذه المشكلات الآن ، إذا نظرنا إلى حزمة البروتوكولات بأكملها ، فإننا نرى أن القيد الأساسي يكمن في مستوى أقل من HTTP / 2 الذي تجرأ على المغامرة.

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

بروتوكول الإنترنت (IP)

يحدد بروتوكول الإنترنت (IP) الجزء السفلي من هيكل الإنترنت بالكامل. إنه جزء من مكدس الإنترنت الذي يمكننا القول بأمان أنه غير قابل للتفاوض دون تغيير كل شيء ، بما في ذلك استبدال البنية التحتية للأجهزة بالكامل ، من أجهزة التوجيه إلى الخوادم وحتى أجهزة المستخدمين النهائيين.

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

يمكننا تتبع بدايات بروتوكول IP منذ عام 1974 ، إلى ورقة بحثية نشرها معهد مهندسي الكهرباء والإلكترونيات وقام بتأليفها فينت سيرف وبوب كان. إنه يفصل الحزم التي يتم إرسالها عبر الشبكة ، وتوجيهها عبر عناوين IP ، والعناوين المحددة رقميًا للعقد في الشبكة / الشبكات. حدد البروتوكول تنسيق هذه الحزم ، أو مخططات البيانات - رؤوسها وحمولتها.

بعد تعريف RFC 760 من عام 1980 ، استقرت IETF مع التعريف المستخدم على نطاق واسع حتى يومنا هذا ، في طلب التعليقات 791. هذا هو الإصدار الرابع من البروتوكول ، ولكن يمكننا القول إنه أول إصدار إنتاج.

يستخدم عناوين 32 بت ، مما يضع قيدًا على عدد العناوين لحوالي 4 مليارات. هذا القيد هو تفسير الغموض الذي يجعل مستخدمي الإنترنت غير التجاريين يحصلون على "عناوين IP ديناميكية" من قبل مزودي خدمة الإنترنت ، ويعتبر IP الثابت "قيمة مضافة" وغالبًا ما يخضع لرسوم إضافية.

هم يقنين.

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

اشترك في النشرة الإخبارية

تريد أن تعرف كيف قمنا بزيادة حركة المرور لدينا أكثر من 1000٪؟

انضم إلى أكثر من 20000 آخرين ممن يتلقون رسائلنا الإخبارية الأسبوعية مع نصائح من الداخل حول WordPress!

إشترك الآن

جاء الإصدار 6 من بروتوكول الإنترنت أو IPv6 كوسيلة لمعالجة هذه القيود ، بما في ذلك اعتماده تدريجياً على الإصدار السابق. تم إعداده كمسودة وثيقة قياسية لـ IETF في عام 1998 ، وتم رفعه إلى معيار الإنترنت في عام 2017.

بينما كانت مساحة عنوان IPv4 محدودة بطول عنوان 32 بت ، تم إعطاء معيار IPv6 128 بت ، أو 3.4 * 10 ^ 38 عناوين محتملة. يجب أن يكون هذا كافياً لنا لبعض الوقت.

وفقًا لاتصال Google و IPv6 بين مستخدميها ، فإن اعتماد IPv6 يزيد قليلاً عن 35٪ اعتبارًا من يونيو 2021.

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

فهم دور TCP و UDP

حان الوقت الآن لاستكشاف أين يتناسب HTTP / 3 مع TCP و UDP.

TCP

في حين أن IP هو الطبقة الأساسية لجميع اتصالاتنا عبر الإنترنت اليوم ، فإن TCP (بروتوكول التحكم في الإرسال) هو جزء عالي المستوى من مجموعة بروتوكولات الإنترنت ، مما يوفر الموثوقية اللازمة للويب والبريد ونقل الملفات (FTP) - لطبقات التطبيق / بروتوكولات الإنترنت.

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

تشير كل هذه الأشياء إلى الكثير من الخطوات التي تجعل TCP بروتوكولًا موثوقًا به ، مما يجعله أساسًا لخدمات الإنترنت الأكثر شهرة التي نستخدمها اليوم.

مواصفاته التي يعود تاريخها إلى 1974 (RFC 675) و 1981 (RFC 793) لم تتغير بشكل كبير حتى يومنا هذا.

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

UDP

يعد بروتوكول مخطط بيانات المستخدم (UDP) أيضًا أحد أجزاء Internet Protocol Suite ، حيث تعود مواصفاته إلى عام 1980 (RFC 768).

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

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

يتم إعاقة نشر البروتوكولات الجديدة بواسطة العديد من جدران الحماية ، و NATs ، وأجهزة التوجيه والصناديق الوسطى الأخرى التي تسمح فقط بنشر TCP أو UDP بين المستخدمين والخوادم التي يحتاجون للوصول إليها. - شرح HTTP / 3

يمكن أن يساعدنا هذا الموضوع على Hacker News في البدء في فهم الأسباب الكامنة وراء إنشاء إصدار HTTP الجديد أعلى مكدس الشبكة الحالي ، بدلاً من إعادة اختراعه (على الرغم من وجود ما هو أكثر من ذلك).

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

يكون المجموع الاختباري اختياريًا عندما تكون طبقة البروتوكول الأساسية هي IPv4 ، وتكون إلزامية مع IPv6. حتى الآن ، تم استخدام UDP لأشياء مثل مزامنة ساعة أنظمة الكمبيوتر (NTP) وتطبيقات VoIP وتدفق الفيديو ونظام DNS وبروتوكول DHCP.

QUIC و HTTP / 3

تم نشر QUIC (اتصالات إنترنت UDP السريعة) لأول مرة بواسطة Google في عام 2012. وهي تعيد تعريف حدود طبقات الشبكة ، بالاعتماد على بروتوكول UDP ذي المستوى الأدنى ، وإعادة تعريف المصافحة ، وميزات الموثوقية ، وميزات الأمان في "مساحة المستخدم" ، وتجنب الحاجة إلى ترقية نوى أنظمة الإنترنت.

تمامًا كما هو الحال مع HTTP / 2 ، وهو تقدم قاده SPDY من Google أو سريع ، سيعتمد HTTP / 3 مرة أخرى على هذه الإنجازات.

في حين أن HTTP / 2 أعطانا تعدد إرسال ، وخفف من حظر رأس الخط ، إلا أنه مقيد بواسطة TCP. يمكنك استخدام اتصال TCP واحد لتدفقات متعددة متعددة الإرسال معًا لنقل البيانات ، ولكن عندما يعاني أحد هذه التدفقات من فقدان الحزمة ، يظل الاتصال بأكمله (وجميع تدفقاته) رهينة ، على سبيل المثال ، حتى يقوم TCP بعمله ( يعيد إرسال الحزمة المفقودة).

هذا يعني أنه يتم حظر جميع الحزم ، حتى لو تم إرسالها بالفعل وانتظارها ، في المخزن المؤقت لعقدة الوجهة ، حتى يتم إعادة إرسال الحزمة المفقودة. دانيال ستينبيرج في كتابه على http / 3 يسمي هذا "رأس كتلة سطر قائم على بروتوكول TCP". وهو يدعي أنه مع فقدان الحزمة بنسبة 2٪ ، فإن المستخدمين سيكونون أفضل مع HTTP / 1 ، مع ستة اتصالات للتحوط من هذه المخاطر.

QUIC غير مقيد بهذا. مع بناء QUIC على بروتوكول UDP بدون اتصال ، لا يحمل مفهوم الاتصال قيود TCP ولا يجب أن تؤثر حالات فشل تيار واحد على الباقي.

كما قال لوكاس باردو من Cloudflare:

مع التركيز على تدفقات UDP ، يحقق QUIC مضاعفة الإرسال دون الحاجة إلى الرجوع إلى اتصال TCP واحد. يبني QUIC اتصاله على مستوى أعلى من TCP. التدفقات الجديدة ضمن اتصالات QUIC ليست مضطرة إلى انتظار انتهاء الآخرين. تستفيد اتصالات QUIC أيضًا من التخلص من مصافحة TCP ، مما يقلل من زمن الوصول.

قام الأشخاص في Cisco بعمل فيديو مثير للاهتمام يشرح مصافحة TCP ثلاثية الاتجاهات:

بينما يلغي QUIC ميزات موثوقية TCP ، فإنه يعوض عنها فوق طبقة UDP ، مما يوفر إعادة إرسال الحزم والطلب وما إلى ذلك. قدمت Google Cloud Platform دعم QUIC لموازنات التحميل الخاصة بهم في 2018 وشهدت تحسنًا في متوسط ​​وقت تحميل الصفحة بنسبة 8٪ على مستوى العالم ، وما يصل إلى 13٪ في المناطق التي يكون فيها زمن الانتقال أعلى.

بين Google Chrome و YouTube و Gmail وبحث Google والخدمات الأخرى ، تمكنت Google من نشر QUIC على جزء كبير من الإنترنت ، دون انتظار IETF. يزعم مهندسو Google أنه في عام 2017 ، تم بالفعل تنفيذ 7٪ من حركة مرور الإنترنت عبر QUIC.

ركز إصدار Google من QUIC على نقل HTTP فقط ، باستخدام بناء جملة HTTP / 2. قرر الأشخاص من IETF (المسؤولون عن توحيد QUIC) أن إصدار IETF من QUIC يجب أن يكون قادرًا على نقل أكثر من HTTP فقط. ومع ذلك ، في الوقت الحالي ، يتم تعليق أي عمل على بروتوكولات بخلاف HTTP عبر QUIC.

هناك أمر آخر قررت مجموعة عمل IETF أن الإصدار القياسي سيستخدم تشفير TLS 1.3 بدلاً من حل Google المخصص. يساهم TLS 1.3 ، مقارنة بالإصدارات الأقدم ، في سرعة البروتوكول ، حيث تتطلب مصافحاته عددًا أقل من الرحلات ذهابًا وإيابًا. يدعم Kinsta TLS 1.3 على جميع خوادمنا و Kinsta CDN الخاص بنا.

في الوقت الحالي ، تواصل Google استخدام نسختها الخاصة من QUIC في منتجها ، مع توجيه جهودها التطويرية نحو معايير IETF. يعتمد معظم مشغلي الإنترنت الآخرين على إصدار IETF (يختلف الاثنان في بعض الجوانب الأخرى إلى جانب التشفير).

إذا فتحنا Chrome Dev Tools ، وقمنا بتحميل بعض منتجات Google ، مثل Gmail ، في عمود البروتوكول في علامة تبويب الشبكة ، فسنرى تحميل الكثير من الموارد عبر إصدار Google من بروتوكول QUIC. هذا هو الحال أيضًا بالنسبة لمنتجات Google مثل Analytics و Google Tag Manager وما إلى ذلك.

نشرت Cloudflare تحديثًا شاملاً للغاية حول تقدم التقييس.

بينما يوفر UDP بعض المزايا المتأصلة QUIC و HTTP / 3 ، فإنه يجلب أيضًا بعض التحديات.

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

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

يمكننا القول أن QUIC يحاول إعادة هندسة ميزات TCP بالإضافة إلى بروتوكول أقل حدًا وأكثر مرونة.

تجمع اتصالات QUIC ، التي ذكرناها سابقًا ، بين TLS ومصافحة النقل. بمجرد إنشائها ، يتم تحديدها بواسطة معرفات CID الفريدة (معرفات الاتصال). تستمر هذه المعرفات عبر تغييرات IP ويمكن أن تساعد في تأمين التنزيلات غير المنقطعة ، على سبيل المثال ، التبديل من 4G إلى WiFi. هذا مهم ، خاصة لأنه يتم إجراء المزيد والمزيد من حركة المرور على الإنترنت على الأجهزة المحمولة. قد تظهر أسئلة حول ما إذا كان هذا العنصر قد تم تصميمه بواسطة Google لتسهيل تتبع المستخدم بشكل أفضل عبر مختلف الاتصالات وموفري الإنترنت.

TLS إلزامي ، ويهدف إلى جعل من الصعب على الأجهزة الموجودة في الوسط التلاعب بحركة المرور أو شمها. هذا هو السبب في أنه ليس من النادر رؤية موفري جدار الحماية والموردين مثل Cisco ينظرون إلى بروتوكول UDP على أنه مشكلة ، ويقدمون طرقًا لتعطيله. يصعب على الوسطاء فحص حركة مرور QUIC والإشراف عليها أو تصفيتها.

يتم إرسال تدفقات QUIC عبر اتصالات QUIC ، أحادي الاتجاه أو ثنائي الاتجاه. تحتوي التدفقات على معرفات تحدد البادئ ، وما إذا كان الدفق أحادي الاتجاه أو ثنائي الاتجاه ، كما أنه يخدم التحكم في التدفق أثناء التدفق.

بينما QUIC هو بروتوكول طبقة النقل ، HTTP هو الطبقة فوق ذلك ، بروتوكول طبقة التطبيق ، أو بروتوكول التطبيق.

نظرًا لأن التوافق مع الإصدارات السابقة له أهمية قصوى ، فقد شجعت IETF على تنفيذ HTTP / 3 ، وستتضمن الإصدار القديم (HTT1 أو HTTP / 2) في الاستجابة. سيتضمن رأسًا يخبر العميل أن HTTP / 3 متاح ، جنبًا إلى جنب مع معلومات المنفذ / المضيف ، كما هو موضح في RFC 7838.

هذا يختلف عن HTTP / 2 ، حيث يمكن التفاوض على النقل ضمن مصافحة TLS. ولكن نظرًا لأن IETF قد اعتمدت بروتوكول HTTP / 3 المستند إلى QUIC كمعيار تالٍ ، يمكننا أن نتوقع من عملاء الويب توقع دعم HTTP / 3 أكثر وأكثر. من الممكن للعملاء تخزين البيانات مؤقتًا من اتصالات HTTP / 3 السابقة ، والاتصال مباشرة (صفر رحلة ذهابًا وإيابًا ، أو 0-RTT) في زيارات لاحقة لنفس المضيف.

ملخص

هناك من يعتقد أنه مع عدم اعتماد معيار HTTP / 2 بالكامل بعد ، فقد يكون من السابق لأوانه القيام بدفع واسع النطاق لـ HTTP / 3. هذه نقطة صحيحة ، ولكن ، كما ذكرنا ، شهد هذا البروتوكول بالفعل اختبارات وتنفيذ على نطاق واسع. بدأت Google في اختباره في وقت مبكر من عام 2015 ، وكذلك Facebook في عام 2017.

في عام 2022 ، لدينا دعم HTTP / 3 من المتصفحات الرئيسية مثل Google Chrome و Brave. على جبهة البنية التحتية ، تمتلك كل من خوادم الويب مثل Litespeed و Nginx تطبيقات فعالة لـ HTTP / 3 ، بينما قام موفرو الشبكات مثل Cloudflare بنشر الدعم الكامل لـ HTTP / 3.

في هذا الوقت ، لا يزال HTTP / 3 في مرحلة مسودة الإنترنت ، ومن المقرر أن تنتهي صلاحية أحدث مراجعة في أغسطس 2021. سيكون هذا العام مثيرًا ، حيث يمكننا أن نتوقع أن نرى تحرك بائعي البرامج الرئيسيين لتنفيذ الإصدار الجديد اساسي.