HTTP/3 وIPv6

ما الذي يغيّره HTTP/3 للزائر

جعل HTTP/2 اتصال TCP واحدًا يحمل طلبات كثيرة معًا، لكنه ورث قاعدة TCP: حزمة ضائعة تعطّل كل ما خلفها. يستبدل HTTP/3 TCP بـ QUIC، وهو نقل فوق UDP مع TLS 1.3 مدمج: يتعافى كل تدفق طلب من الفقد وحده، وتحتاج المصافحة إلى جولات أقل، ويحافظ الهاتف الذي ينتقل من Wi-Fi إلى بيانات الجوال على اتصاله بدل إعادة بدئه. على اتصال سلكي جيد يكون المكسب صغيرًا؛ أما على Wi-Fi متقطع وشبكات الجوال — حيث معظم زوارك — فهو الفرق الذي يظهر في Core Web Vitals.

كيف تنقل الحافة المتصفحات وتعيدها

تحمل كل استجابة HTTPS من الحافة Alt-Svc: h3=":443". يفتح المتصفح الذي يفهمها اتصاله التالي عبر QUIC على منفذ UDP 443؛ والذي لا يفهمها يتجاهلها. إذا كان UDP 443 محجوبًا في مكان ما على المسار — جدار حماية مؤسسي أو موجّه منزلي صارم — يلاحظ المتصفح فشل محاولة QUIC ويبقى على HTTP/2 دون أي خطأ. لهذا يمكن تفعيل HTTP/3 للجميع: أسوأ حالة هي بالضبط ما كان لديك من قبل.

IPv6 دون لمس الأصل لديك

تحمل أسماء مضيفي CDN سجلات AAAA بجانب سجلات A وتستمع الحافة على عائلتي العناوين. يتصل الزائر على شبكة IPv6 فقط — شائعة لدى مشغلي الجوال — بالحافة مباشرة بدلًا من المرور بطبقة الترجمة لدى المشغل، وتحصل المناقصة أو قائمة الامتثال التي تطلب IPv6 على إجابة نعم. يُتواصل مع خادم الأصل لديك كما هو اليوم، عادة عبر IPv4، فلا يلزم تغيير أي شيء فيه ليكون موقعك قابلًا للوصول عبر IPv6.

WAF نفسه على كل بروتوكول

يفحص جدار حماية تطبيقات الويب وحدود المعدل وقواعد الدول وASN وحماية البوتات طلب HTTP/3 تمامًا كما تفحص طلب HTTP/2؛ فالبروتوكول تفصيل نقل تحتها. يحصل الطلب المحظور عبر HTTP/3 على صفحة الحظر نفسها بنفس Reference ID، فيعمل الدعم والتدقيق دون تغيير. القاعدة الوحيدة التي تحتاج انتباهك هي التي كتبتها ضد عناوين IPv4: لا يطابقها زوار IPv6 حتى تضيف صيغة IPv6.

ما الذي يكلّفك

لا شيء. لا خطة ولا إضافة ولا إعداد لأي من الميزتين، ويُحتسب عرض النطاق والطلبات كما في السابق، وسعة الحافة خلفهما شأننا — قسنا التحول عبر الشبكة ولم نرَ تغيرًا في الحمل. كلاهما تكوين مشترك للحافة ولا يمكن إيقافه لموقع واحد؛ ولا حاجة لذلك، لأن العملاء الذين لا يستطيعون استخدامهما لا يخسرون شيئًا.

أين يظهر الأثر