HTTP/3 و QUIC: ماذا تغير فعليًا تحت صفحة الويب؟

HTTP/3 يستخدم QUIC بدل TCP كطبقة نقل، و QUIC يعمل فوق UDP ويجمع إنشاء الاتصال والتشفير والتعدد في بروتوكول مصمم للويب الحديث. الفكرة ليست «UDP أسرع من TCP» ببساطة، بل تقليل بعض تكلفة الاتصال وتحسين سلوك عدة streams خاصة عند وجود packet loss أو تغير الشبكة. ومع ذلك، أداء الصفحة يعتمد أيضًا على الخادم وال ـCDN وحجم الموارد و JavaScript و Cache، لذلك لا يوجد ضمان أن تغيير البروتوكول وحده سيحل بطء التطبيق.

QUIC يدمج الاتصال والتشفير

في HTTP/2 فوق TCP تحتاج طبقات اتصال وتشفير، بينما QUIC يدمج TLS 1.3 في handshake الخاص به. الاتصالات المعروفة سابقًا يمكن أن تستفيد من استئناف أسرع في بعض الحالات. هذا يقلل latency في بداية الاتصال خصوصًا عبر مسافات كبيرة.

حل مشكلة head-of-line على مستوى streams

HTTP/2 يسمح بتعدد streams داخل اتصال TCP واحد، لكن فقد packet في TCP يمكن أن يؤخر البيانات اللاحقة على الاتصال كله حتى الاستعادة. QUIC يدير streams بصورة أكثر استقلالًا، فيقل تأثير فقد packet على streams الأخرى.

تغير الشبكة يمكن أن يكون أكثر سلاسة

QUIC يستخدم Connection IDs بدل الاعتماد فقط على tuple الشبكة التقليدي، ما يسمح باستمرار الاتصال في بعض سيناريوهات الانتقال بين شبكات مثل Wi-Fi و Mobile. لكن هذا لا يعني أن كل تطبيق سيحافظ على كل sessions؛ طبقات التطبيق ما زالت لها منطقها.

لماذا قد لا ترى فرقًا كبيرًا؟

إذا كان الموقع قريبًا جدًا أو Cache قوية أو bottleneck في JavaScript أو Backend، مكاسب النقل قد تكون صغيرة. كذلك بعض الشبكات قد تقيد UDP أو تجبر fallback.

استخدم القياس الواقعي

قارن percentiles عبر مستخدمين حقيقيين أو lab tests متعددة، لا request واحدة. بروتوكول النقل جزء من الأداء، لكنه لا يعوض تطبيقًا يحمّل JavaScript ضخمًا أو API بطيئة.

0-RTT يحتاج فهمًا قبل الاستخدام

استئناف QUIC قد يسمح بإرسال بعض البيانات مبكرًا، لكن 0-RTT قابلة لإعادة الإرسال على مستوى البروتوكول ولا تناسب أي request لها أثر غير idempotent. لذلك يجب أن يقرر التطبيق أو الخادم ما الذي يمكن قبوله في هذه المرحلة. لا تجعل مكسب latency صغيرًا يفتح احتمال تنفيذ عملية حساسة أكثر من مرة.