HTTP/3 الآن يحمل ثلث الويب — وQUIC بدأت لتوها | IRCNF - Intelligent Reliable Custom Next-gen Frameworks

ما يقرب من 30% من كل حركة مرور الويب تتدفق الآن عبر HTTP/3، وفقًا لبيانات من HTTP Archive والمراجعة السنوية لـ Cloudflare. تخدم Google أكثر من 90% من طلباتها — بحث، يوتيوب، جيميل — عبر QUIC. وتقوم Meta بتوجيه غالبية حركة مرور CDN الخاصة بها بنفس الطريقة. لقد قامت Fastly وCloudflare وAWS CloudFront بتمكين HTTP/3 افتراضيًا. لم يعد هذا بروتوكولًا تجريبيًا. إنه النقل الافتراضي لأكبر خصائص الويب، وحصة حركة المرور التي يحملها تنمو بنحو 3-5 نقاط مئوية سنويًا.

المشكلة التي تركها HTTP/2 دون حل

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

لكن HTTP/2 أبقى TCP كطبقة نقل له، وTCP لديه مشكلة انسداد الخط الأمامي الخاصة به والتي لا يمكن للإرسال المتعدد إصلاحها. يضمن TCP التسليم المرتب: إذا فقد جزء واحد، فإن جميع الأجزاء اللاحقة — حتى تلك التي تنتمي إلى تدفقات HTTP/2 المستقلة تمامًا — يجب أن تنتظر حتى يتم إعادة إرسال الجزء المفقود قبل أن يسلمها TCP إلى التطبيق. على اتصال مع 1% فقدان للحزم، يمكن أن يؤدي ذلك إلى توقف تدفقات موارد مستقلة متعددة في وقت واحد. على شبكة محمول مع 2-3% فقدان للحزم (نموذجي لـ LTE على حافة التغطية)، يتضاعف تأثير الكمون بشدة.

كانت مصافحات TLS هي المشكلة الثانية. تطلب HTTP/2 عبر TLS 1.2 رحلتي ذهاب وإياب (RTT) قبل أن تتدفق أي بيانات تطبيق — واحدة لـ TCP SYN/SYN-ACK/ACK، وواحدة لمفاوضة TLS. على اتصال محمول مع RTT 80ms، هذا يعني 160ms من النفقات العامة للإعداد قبل أول بايت من المحتوى. قلل TLS 1.3 ذلك إلى 1-RTT، لكن مصافحة TCP الثلاثية ظلت حتمية. كان ترحيل الاتصال — ما يحدث عندما تنتقل من Wi-Fi إلى الخلوي — يعني أن اتصالات TCP تنقطع ويجب أن تبدأ من الصفر.

ما هو QUIC فعليًا

QUIC هو بروتوكول نقل يعمل فوق UDP. صممته Google في عام 2012، وتم نشره داخليًا حوالي عام 2013، وتم توحيده بواسطة IETF كـ RFC 9000 في مايو 2021. HTTP/3 (RFC 9114) هو ببساطة دلالات HTTP مكدسة فوق QUIC بدلاً من TCP.

القرارات المعمارية الرئيسية في QUIC:

الإرسال المتعدد القائم على UDP مع تدفقات مستقلة: ينفذ QUIC الإرسال المتعدد للتدفق في طبقة النقل وليس طبقة التطبيق. كل تدفق له التحكم في التدفق واستعادة الفقد الخاص به. الحزمة المفقودة تؤثر فقط على التدفق الذي تنتمي إليه — تستمر التدفقات الأخرى في تسليم البيانات دون انقطاع. هذا يزيل انسداد الخط الأمامي لـ TCP على مستوى النقل.
TLS 1.3 مدمج: لا يقوم QUIC بطبقة TLS فوق النقل؛ TLS 1.3 جزء لا يتجزأ من البروتوكول. تحدث المصافحة ومفاوضة التشفير في وقت واحد مع إنشاء الاتصال. يتطلب اتصال QUIC الجديد 1-RTT قبل تدفق بيانات التطبيق — رحلة ذهاب وإياب أقل من TLS 1.2 فوق TCP.
استئناف الاتصال 0-RTT: عندما يعيد العميل الاتصال بخادم تحدث معه من قبل، يمكن لـ QUIC إرسال بيانات التطبيق مع أول حزمة باستخدام وضع 0-RTT. يستخدم العميل بيانات تذكرة الجلسة من الاتصال السابق لتشفير الطلب فورًا. في إعادة الاتصال المحمول النموذجية — التبديل بين Wi-Fi والخلوي — هذا يعني أن أول طلب HTTP يمكن أن يخرج قبل اكتمال المصافحة، مما يقلل الكمون المدرك إلى الصفر تقريبًا للزيارات المتكررة.
ترحيل الاتصال: يحدد QUIC الاتصالات باستخدام معرف اتصال 64 بت، وليس رباعيًا من عناوين IP والمنافذ. عندما يغير جهازك عنوان IP — الانتقال من Wi-Fi إلى 5G، أو التبديل بين أبراج الخلوي — يستمر اتصال QUIC دون انقطاع. لا إعادة تعيين TCP، لا مصافحة جديدة، لا تدفقات مسقطة. يتلقى الخادم حزمًا من عنوان IP الجديد تشير إلى نفس معرف الاتصال ويستمر بسلاسة.

دليل الأداء: ماذا تظهر الأرقام

تكون مكاسب الأداء من QUIC أكثر وضوحًا في شرطين: فقدان الحزم العالي والتحولات المتكررة للشبكة. نشرت Google نتائج اختبار A/B داخلية تظهر أن QUIC قلل كمون البحث بنسبة 8% عند الوسيط وبنسبة تصل إلى 28% عند المئين 99 (كمون الذيل) مقارنة بـ HTTPS فوق TCP. أظهرت بيانات QUIC ليوتيوب انخفاضًا بنسبة 15% في أحداث إعادة التخزين المؤقت.

أظهرت معايير Cloudflare لعام 2023 لـ HTTP/3 مقابل HTTP/2 على شبكة محاكاة مع 1% فقدان للحزم تحسينات في وقت تحميل الصفحة الوسيط بنسبة 12-18% للصفحات كثيفة الموارد. عند 3% فقدان للحزم — واقعي للشبكات المحمولة المزدحمة — نما التحسن إلى 25-35%. على اتصال نظيف منخفض الكمون مع 0% فقدان للحزم، يكون فرق الأداء بين HTTP/2 وHTTP/3 صغيرًا (أقل من 5%)، لأن انسداد الخط الأمامي لـ TCP يظهر فقط عند فقد الأجزاء.

من الصعب عزل فائدة استئناف 0-RTT ولكنها قابلة للقياس. أبلغت Meta أن تمكين 0-RTT للزوار العائدين على CDN الخاص بها قلل الوقت حتى أول بايت (TTFB) بمقدار 30-60ms على اتصالات المحمول، مما يترجم مباشرة إلى درجات أسرع لـ Largest Contentful Paint (LCP) — Core Web Vital الأكثر ارتباطًا بتجربة المستخدم وتصنيف بحث Google.

ملاحظة واحدة: يحمل 0-RTT ضعف إعادة التشغيل. يمكن للمهاجم الذي يلتقط بيانات 0-RTT إعادة تشغيلها لإرسال طلبات مكررة. لهذا السبب يعتبر 0-RTT آمنًا للطلبات غير المؤثرة (GET, HEAD) ولكن يجب تعطيله أو التعامل معه بحذر للعمليات التي تغير الحالة (POST, المدفوعات). تتعامل تطبيقات الخادم الحديثة مع هذا تلقائيًا، لكن من الجيد معرفة وجود القيد.

من يقوم بتشغيل HTTP/3 اليوم

مشهد التبني حتى منتصف عام 2026 كبير:

Cloudflare: تم تمكين HTTP/3 افتراضيًا لجميع العملاء منذ 2020. تدير Cloudflare أيضًا أحد أكثر تطبيقات QUIC استخدامًا (quiche)، وهو مفتوح المصدر ويستخدمه Firefox ومشاريع أخرى.
Google: تقوم بتشغيل QUIC داخليًا للبحث ويوتيوب وجيميل وجوجل درايف وخرائط. قام متصفح Chrome بشحن دعم QUIC منذ 2015. تطبيق QUIC من Google (quic-go و cronet C++) هو التطبيق المرجعي لمعظم النظام البيئي.
Meta: تقوم بتشغيل HTTP/3 لحركة مرور CDN الخاصة بـ Facebook وInstagram وWhatsApp. تحتفظ Meta بتطبيق QUIC الخاص بها (mvfst)، تم فتح مصدره في 2019، ويستخدم في الإنتاج على نطاق مليارات المستخدمين.
Fastly, Akamai, AWS CloudFront: جميعها تقدم HTTP/3 كخيار CDN، مع Fastly تمكينه افتراضيًا منذ 2022.

على جانب برمجيات الخادم: أضاف nginx دعم QUIC/HTTP/3 في الإصدار v1.25.0 (صدر في يونيو 2023) كميزة مستقرة. قام Caddy بشحن HTTP/3 ممكّنًا افتراضيًا منذ v2.4. لدى LiteSpeed ونسخته مفتوحة المصدر OpenLiteSpeed دعم HTTP/3 منذ 2020. يقدم Apache httpd HTTP/3 عبر وحدة mod_quic، لا تزال تجريبية حتى Apache 2.4.55. خادم H2O لديه دعم QUIC. Node.js لديه واجهة برمجة تطبيقات QUIC تجريبية. يدعم وقت تشغيل Deno HTTP/3 أصليًا.

ما يحتاج مطورو الويب إلى فعله

بالنسبة لمعظم المطورين الذين يستخدمون CDN أو موازن تحميل سحابي، فإن HTTP/3 قيد التشغيل بالفعل — تحقق منه، لا تقم بتمكينه. إذا كنت تدير البنية التحتية للخادم الخاص بك، فإليك المسار العملي:

تحقق من أن HTTP/3 نشط:

استخدم curl --http3 https://yourdomain.com -I وتحقق من HTTP/3 في سطر الاستجابة. يتطلب curl مبنيًا مع دعم QUIC (curl --version | grep HTTP3).
في Chrome DevTools: افتح لوحة Network، انقر بزر الماوس الأيمن على رؤوس الأعمدة، قم بتمكين "Protocol". تظهر اتصالات HTTP/3 كـ h3. تظهر HTTP/2 كـ h2.
يظهر Firefox DevTools نفس الشيء في عمود Protocol بلوحة Network.
يوفر فاحص quic.cloud من Cloudflare وأداة http3check.net تحققًا خارجيًا سريعًا.

تمكين HTTP/3 على nginx (1.25+): أضف listen 443 quic reuseport; بجانب توجيه listen 443 ssl; الموجود، ثم أضف add_header Alt-Svc 'h3=":443"; ma=86400'; للإعلان عن QUIC للمتصفحات. رأس Alt-Svc هو كيفية اكتشاف العملاء أن HTTP/3 متاح — سيستخدم الاتصال الأول HTTP/2، وستقوم الاتصالات اللاحقة بالترقية إلى HTTP/3.

تمكين HTTP/3 على Caddy: لا شيء لتكوينه — يقوم Caddy بتمكين HTTP/3 افتراضيًا عندما يكون TLS نشطًا. تأكد عبر عمود Protocol في DevTools.

تكوين جدار الحماية هو عائق شائع: يعمل QUIC على منفذ UDP 443. تحظر العديد من جدران الحماية المؤسسية حركة مرور UDP أو تحد من معدلها. إذا فشل HTTP/3 في التفاوض، تعود المتصفحات تلقائيًا إلى HTTP/2 — لا يرى المستخدمون النهائيون أي أخطاء، لكنهم لا يحصلون على QUIC أيضًا. إذا كنت تقوم بتصحيح عدم استخدام HTTP/3 على شبكة معينة، تحقق مما إذا كان UDP/443 مفتوحًا.

لا تقم بضبط التحكم في الازدحام يدويًا لـ QUIC بعد. تستخدم تطبيقات QUIC التحكم في الازدحام BBR (عرض النطاق الترددي للاختناق وRTT) افتراضيًا، والذي يتفوق على CUBIC (افتراضي TCP) في معظم الشبكات الحديثة. ما لم تكن لديك مشاكل أداء محددة مقاسة، فإن الإعدادات الافتراضية صحيحة.

0-RTT: تقوم معظم تطبيقات الخادم بتمكين 0-RTT لطلبات GET تلقائيًا. إذا أصدر تطبيقك عمليات تغيير حالة على تحميل الصفحة (غير معتاد لكن ممكن)، قم بتدقيق أنواع الطلبات تلك. الإرشاد القياسي هو معاملة بيانات 0-RTT على أنها قابلة لإعادة التشغيل والتصميم وفقًا لذلك — استخدم رموزًا غير مؤثرة أو تحقق من حالة طبقة التطبيق.

الطريق إلى الأمام

لم ينته تطور HTTP/3 وQUIC. يضيف QUIC الإصدار 2 (RFC 9369، المنشور في 2023) تحسينات لترحيل الاتصال ويقدم آلية جديدة للتفاوض على الإصدار. WebTransport — واجهة برمجة تطبيقات متصفح تعرض تدفقات QUIC ورسائل البيانات (datagrams) مباشرة لجافا سكريبت — يتم شحنها في Chrome وFirefox، مما يتيح اتصالًا ثنائي الاتجاه منخفض الكمون دون نفقات WebSocket. يقوم MASQUE (القاعدة الفرعية للتطبيقات المتعددة عبر تشفير QUIC)، وهو بروتوكول مجموعة عمل IETF، ببناء نفق يشبه VPN على QUIC وهو منشور بالفعل في iCloud Private Relay.

بالنسبة لمطور الويب الذي يفهم TCP وHTTP، فإن QUIC هو نفس المشكلة التي تم حلها بشكل صحيح: تسليم موثوق ومرتب حيثما يكون مطلوبًا (لكل تدفق)، دون قيد الترتيب العالمي الذي يجعل TCP مرضيًا على الوصلات عالية الفقد. البروتوكول مستقر، الأدوات موجودة، والأدلة على الأداء لا لبس فيها. إذا كانت حركة المرور الخاصة بك تمر عبر CDN حديث، فإن مستخدميك يستفيدون بالفعل. إذا لم تكن كذلك، فإن مسار الترقية هو سطر تكوين nginx واحد.