تبني HTTP/3 يتوقف عند 21% — إليك الفيزياء وراء الركود

عندما قامت IETF بتوحيد HTTP/3 في 2022، كان الوعد واضحًا: بروتوكول مبني على QUIC، يلغي حظر رأس الخط في TCP، مع إنشاء اتصال أسرع وأداء أفضل على الشبكات غير الموثوقة. بعد أربع سنوات، 39.5% من المواقع تدعم HTTP/3 — ولكن 21.11% فقط من الطلبات الفعلية تستخدمه، انخفاضًا من ذروة 22.16% في يناير 2026. منحنى التبني أصبح مسطحًا.

هذه ليست قصة عن بطء المطورين في الترقية. إنها قصة عن الفيزياء.

مفارقة الشبكة السريعة

على الاتصالات عالية النطاق الترددي ومنخفضة زمن الوصول — النوع الذي يستخدمه معظم مستخدمي المؤسسات وحركة مرور مراكز البيانات — يعمل HTTP/3 بشكل أسوأ من HTTP/2. ورقة بحثية في 2024 قُدمت في مؤتمر ACM Web Conference قاست انخفاضًا بنسبة 45.2% في معدل البيانات لـ QUIC مقارنة بـ HTTP/2 على شبكات تتجاوز 500 ميغابت في الثانية. السبب: خوارزميات التحكم في الازدحام في QUIC صُممت للشبكات المتنقلة غير الموثوقة وذات الفقد العالي. على الألياف الضوئية، تصبح متحفظة بطرق لا تفعلها خوارزميات TCP القديمة.

كما أن QUIC يعمل فوق UDP، مما يعني أنه لا يمكنه الاستفادة من تحميل المهام على الأجهزة المدمجة في بطاقات الشبكات الحديثة لـ TCP. كل حزمة QUIC تتطلب دورات CPU لا تحتاجها حزم TCP. على نطاق واسع، في مراكز البيانات التي تعالج ملايين الطلبات في الثانية، يكون هذا العبء كبيرًا.

أين يفوز HTTP/3 حقًا

قصة الأداء مختلفة على الشبكات المتنقلة وفي الأسواق الناشئة. تقرير أداء Akamai لعام 2025 وجد تقليلًا بنسبة 30% في زمن الوصول على الاتصالات التي تفوق نسبة فقدان الحزم 2% — وهي حالة شائعة على الشبكات الخلوية في أفريقيا وجنوب آسيا وأوروبا الريفية. للمستخدمين على شبكات Wi-Fi مزدحمة أو الذين يتحولون بين الأبراج الخلوية أثناء الجلسة، فإن ترحيل الاتصال في HTTP/3 (الذي يحافظ على الجلسة حتى عندما يتغير عنوان IP للعميل) هو تحسين حقيقي مقارنة بمتطلب TCP لإعادة إنشاء الاتصالات.

هذا يخلق انقسامًا محرجًا: HTTP/3 يساعد المستخدمين الذين يحتاجونه أكثر — أولئك على الاتصالات الضعيفة — ولكنه يجعله أسوأ قليلاً للمستخدمين على الاتصالات السريعة التي تحمل معظم الحركة المرورية من حيث الحجم.

تبني CDN مقابل واقع الحركة المرورية

مزودو CDN الرئيسيون — Cloudflare وFastly وAkamai — يدعمون جميعًا HTTP/3 بشكل أصلي. سوق خدمات الحافة الممكّنة بـ QUIC ينمو من 2.84 مليار دولار في 2025 إلى 3.79 مليار دولار في 2026 بمعدل نمو سنوي مركب 33%. لكن دعم البروتوكول وتوجيه الحركة المرورية عبره قراران مختلفان. تقدم CDN بشكل متزايد تفعيل HTTP/3 انتقائيًا بناءً على خصائص العميل: العملاء المتنقلون ذوو زمن الوصول العالي المقاس يحصلون على QUIC، بينما عملاء سطح المكتب على الألياف يحصلون على HTTP/2.

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

هضبة الـ21% ليست فشلاً

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

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

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

ماذا بعد

فريق عمل QUIC في IETF على علم بفجوة الأداء على النطاق الترددي العالي. العمل جارٍ على خوارزميات تحكم في الازدحام لـ QUIC تستغل النطاق الترددي بشكل أفضل على الشبكات الموثوقة، وعلى دعم تحميل UDP على مستوى الأجهزة الذي قد يقلل فجوة تكلفة CPU مع TCP. هذه التحسينات ستستغرق وقتًا لتعميمها في النظام البيئي.

في غضون ذلك، حصة استخدام HTTP/3 البالغة 21% ليست سقفًا — بل هو المكان الذي استقر فيه البروتوكول بشكل طبيعي نظرًا لنطاق أدائه. ما إذا سينمو أكثر يعتمد أقل على دعم المتصفح (وهو عالمي) وأكثر على ما إذا كانت خصائص أداء البروتوكول تتحسن على أنواع الشبكات التي تحمل معظم الحركة المرورية.