أداء TLS: ‏QUIC وHTTP/3

يُعدِّد HTTP/2 تدفقات متعددة عبر اتصال TCP واحد، مما يحل مشكلة حجب رأس الصف لكل اتصال في HTTP/1.1. إلا أن TCP نفسه يسبب حجب رأس الصف في طبقة النقل: فإذا فُقد مقطع TCP واحد، تنتظر جميع البيانات التي تليه في قائمة الانتظار إعادة الإرسال، مما يحجب جميع تدفقات HTTP/2 في الوقت نفسه. ويمكن لفقدان 1% من الحزم أن يخفض أداء HTTP/2 إلى ما دون أداء HTTP/1.1 الذي يستخدم اتصالات متعددة. ويحل QUIC ‏(Quick UDP Internet Connections) هذه المشكلة من خلال تنفيذ تدفقات متعددة عبر UDP، بحيث لا يؤدي استرداد الحزم المفقودة على مستوى تدفق واحد إلى حجب التدفقات الأخرى.

QUIC هو بروتوكول نقل مبني على UDP، طوّرته Google بين عامَي 2012 و2015، ووحّدته IETF في RFC 9000 عام 2021. يدمج QUIC بروتوكول TLS 1.3 في طبقة النقل؛ فلا توجد مصافحة TLS منفصلة فوق QUIC، بل إن TLS مدمج في مصافحة QUIC نفسها. ويوفر QUIC: تدفقات متعددة دون حجب رأس الصف، وترحيل الاتصال (الحفاظ على الاتصال عند التبديل بين الشبكات، مثل الانتقال من WiFi إلى LTE)، وإنشاء الاتصالات بزمن 0-RTT للاتصالات المتكررة، واكتشاف الفقدان والتحكم في الازدحام مدمجين. أما HTTP/3 ‏(RFC 9114) فهو دلالات HTTP عبر تدفقات QUIC.

تجمع مصافحة QUIC بين إنشاء الاتصال والتفاوض على TLS. في الدفعة الأولى (0 RTT وفقًا لمصطلحات QUIC)، يرسل العميل حزم Initial التي تتضمن TLS ClientHello. ويرد الخادم بحزم Initial الخاصة به (ServerHello)، إلى جانب حزم Handshake التي تتضمن الامتدادات المشفَّرة والشهادة وFinished. ويرسل العميل Handshake Finished، ويصبح بعدها جاهزًا لإرسال بيانات التطبيق؛ وهذا هو 1-RTT. وفي اتصالات 0-RTT، يرسل العميل حزم 0-RTT (بيانات التطبيق) إلى جانب ClientHello، باستخدام مفتاح مشتق من سر استئناف الجلسة السابقة، محققًا عدم الحاجة إلى أي رحلات إضافية للاتصالات المخزنة مؤقتًا.

يستخدم QUIC أربعة مستويات تشفير متميزة تقابل مراحل جدولة مفاتيح TLS: Initial (تشفير AEAD مشتق من QUIC باستخدام مفتاح ثابت معروف؛ يوفر التكامل، لكنه لا يوفر السرية أمام المهاجمين المتقدمين)، وHandshake (مشتق من TLS handshake_secret؛ يوفر سرية رسائل مصافحة TLS)، و0-RTT (مشتق من early_secret للجلسة السابقة؛ يشفر بيانات تطبيق 0-RTT)، و1-RTT (مشتق من TLS master_secret؛ يشفر جميع بيانات التطبيق). وتُشفَّر رؤوس QUIC جزئيًا: إذ يُشفَّر رقم الحزمة والحمولة، بينما تظل بعض معلومات التوجيه (معرّف الاتصال) ظاهرة لموازِنات الحمل.

تُحدَّد اتصالات QUIC بواسطة معرّف اتصال (CID) بدلًا من رباعية (عنوان IP المصدر، ومنفذ المصدر، وعنوان IP الوجهة، ومنفذ الوجهة). ويسمح ذلك للاتصالات بالاستمرار عند تغيّر الشبكة: فعندما ينتقل عميل محمول من WiFi إلى LTE، يتغير عنوان IP، بينما يظل CID نفسه. ويرسل العميل إطار PATH_CHALLENGE عبر المسار الجديد، ويرد الخادم بإطار PATH_RESPONSE للتحقق من العنوان الجديد. ويستمر الاتصال بسلاسة دون إعادة التفاوض. ولا يستطيع TCP دعم ذلك؛ إذ يرتبط اتصال TCP برباعيته، ويجب إنشاؤه من جديد عند تغيّر الشبكة، مما يتطلب مصافحة TLS جديدة. ويحسّن ترحيل QUIC الأداء المتصوَّر للمستخدمين على الأجهزة المحمولة بدرجة ملحوظة.

يعيّن HTTP/3 دلالات HTTP إلى تدفقات QUIC. ويشغل كل زوج من طلب واستجابة HTTP تدفق QUIC ثنائي الاتجاه منفصلًا. وتكون تدفقات QUIC مستقلة؛ ففقدان البيانات في التدفق 3 لا يحجب التدفق 7. ويستخدم HTTP/3 بروتوكول QPACK لضغط الرؤوس (ليحل محل HPACK المستخدم في HTTP/2)، وقد أُعيد تصميم QPACK ليعمل دون اشتراط التسليم بالترتيب. ويحمل تدفقان مخصصان أحاديَا الاتجاه إعدادات الاتصال وتعليمات وحدة فك الترميز/الترميز. ويستخدم دفع الخادم في HTTP/3 تدفقات الدفع (أحادية الاتجاه). والنتيجة الإجمالية هي أن HTTP/3 يتفوق على HTTP/2 بدرجة أكبر، خصوصًا في ظروف فقدان الحزم (الشبكات المحمولة والمسارات المزدحمة) التي يكون فيها حجب رأس الصف في TCP أكثر ضررًا.

تُظهر القياسات الواقعية لأداء QUIC وHTTP/3 نتائج متفاوتة بحسب ظروف الشبكة. ففي الشبكات عالية الجودة (زمن استجابة منخفض وفقدان حزم منخفض)، يتقارب أداء HTTP/3 وHTTP/2؛ بل إن الحمل الإضافي في QUIC (الرؤوس الأكبر وحمل معالجة UDP) قد يجعل HTTP/3 أبطأ قليلًا. أما في الشبكات التي تعاني من فقدان الحزم (أكثر من 1%، وهو أمر شائع في شبكات الهاتف المحمول والأقمار الصناعية)، فيتفوق HTTP/3 على HTTP/2 بدرجة ملحوظة. وقد أفادت Google بانخفاض إعادة التخزين المؤقت في YouTube بنسبة 7-8% عند الانتقال إلى QUIC. كما أفادت Facebook ‏(Meta) بتحسن زمن استجابة الطلبات في خلاصات Instagram بنسبة 7-15% عبر QUIC. وتظهر المكاسب بوضوح أكبر في زمن الاستجابة في الذيل (p95 وp99)، حيث يكون توقف TCP بسبب إعادة الإرسال أكثر تأثيرًا.

تُعد موازنة حمل QUIC أكثر تعقيدًا من TCP لأن QUIC يعتمد على UDP، ولا تستطيع موازِنات حمل UDP عديمة الحالة الحفاظ على ارتباط الاتصال. ويحدد مسودّة IETF ‏draft-ietf-quic-load-balancers نهجًا لذلك: إذ يشفّر الخادم معلومات التوجيه داخل معرّف الاتصال، بحيث تتمكن موازِنات الحمل من توجيه حزم الاتصال نفسه إلى الخادم نفسه دون تتبع حالة كل اتصال. ويحمل معرّف الاتصال معرّف خادم مشفّرًا باستخدام مفتاح مشترك بين موازِن الحمل والخوادم. وتنفذ Cloudflare وFastly وNginx أشكالًا مختلفة من هذا النهج. ويُعد اجتياز NAT مصدر قلق آخر؛ إذ يجب أن تصمد اتصالات QUIC أمام إعادة ربط NAT، ويتولى ذلك نظام ترحيل الاتصال.

نشرت شبكات CDN الكبرى بروتوكولي QUIC وHTTP/3 على نطاق واسع. وتقدم Cloudflare خدمة HTTP/3 منذ عام 2019، وتفيد بأن نحو 20% من الحركة تستخدم QUIC عندما يدعمه كل من العميل والخادم. وتدعم Fastly وAkamai وAWS CloudFront بروتوكول HTTP/3 على نقاط الحافة الخاصة بها. وقد استخدمت البنية التحتية الخاصة بـ Google (Search وYouTube وGmail) بروتوكول QUIC داخليًا منذ عام 2013، كما تتيح HTTP/3 للعامة. تستفيد عمليات نشر CDN من استئناف QUIC بزمن 0-RTT؛ إذ ينشئ الزوار المتكررون الاتصالات بسرعة أكبر، كما يحسن ترحيل الاتصال أداء المستخدمين على الأجهزة المحمولة الذين يتنقلون بين نقاط الوصول أثناء توصيل المحتوى.

يفرض تصميم QUIC القائم على UDP اعتبارات أمنية محددة. هجمات التضخيم: يستطيع مهاجم انتحال عنوان IP المصدر وإرسال حزم Initial صغيرة، مما يدفع الخادم إلى إرسال استجابات Handshake كبيرة إلى الضحية. ويخفف QUIC من ذلك عبر تقييد استجابات الخادم إلى ثلاثة أضعاف البيانات المستلمة حتى يكتمل التحقق من العنوان (عبر آلية RETRY). أما إغراق الاتصالات، فيتطلب من خوادم QUIC تحديد معدل محاولات إنشاء الاتصالات الجديدة من عنوان IP نفسه. ويُمنع هجوم تفاوض الإصدارات من خلال تضمين الإصدار في المصافحة المحمية تشفيريًا. ويعني التشفير المدمج في QUIC أن أجهزة الفحص لا تستطيع تحليل حمولة QUIC دون أن تكون على المسار مع شهادة الخادم، مما يحسن الخصوصية مقارنة بحركة TCP القابلة للفحص.

يتطلب نشر HTTP/3 ما يلي: (1) خادمًا يدعم QUIC (nginx 1.25+ أو Caddy أو HAProxy 2.6+ أو LiteSpeed، أو على مستوى التطبيق عبر مكتبات quic-go أو aioquic أو ngtcp2). (2) فتح منفذ UDP 443 في جدران الحماية؛ إذ تحظر العديد من جدران الحماية المؤسسية منفذ UDP 443، مما يؤدي إلى رجوع QUIC إلى TCP/TLS. (3) الإعلان عن دعم HTTP/3 عبر رأس الاستجابة Alt-Svc: Alt-Svc: h3=":443"; ma=86400، لحث عملاء HTTP/2 على الترقية. (4) موازِنات حمل مدركة لـ QUIC أو تمرير UDP على الطبقة الرابعة L4. (5) مراقبة المقاييس الخاصة بـ QUIC، مثل أحداث ترحيل الاتصال، ومعدل قبول 0-RTT، ومعدل الرجوع إلى البروتوكول البديل. ويكون النشر التدريجي مع الرجوع إلى HTTPS شفافًا للعملاء الذين لا يدعمون QUIC.

كيف يحل QUIC مشكلة حجب رأس الصف التي تؤثر في HTTP/2 عبر TCP؟

يدمج QUIC بروتوكول TLS 1.3 في طبقة النقل عبر UDP، مما يلغي حجب رأس الصف في TCP بفضل استرداد الفقدان بشكل مستقل لكل تدفق. وتتيح معرّفات الاتصال ترحيل الاتصال عبر تغيّرات الشبكة دون إعادة التفاوض. ويعيّن HTTP/3 بروتوكول HTTP إلى تدفقات QUIC باستخدام ضغط رؤوس QPACK. ويعيد استئناف الاتصال بزمن 0-RTT استخدام أسرار جلسة TLS. ويتفوق QUIC على HTTP/2 بدرجة أكبر، خصوصًا عند فقدان الحزم (في شبكات الهاتف المحمول والشبكات المزدحمة). وتتطلب موازنة حمل QUIC ترميز معلومات توجيه الخادم داخل معرّفات الاتصال. ويتطلب النشر استخدام UDP 443، وخوادم تدعم QUIC، ورؤوس Alt-Svc للإعلان عن البروتوكول.