HTTP/2 مقابل HTTP/3: ما الذي تغيّر فعلًا وماذا يعني لموقعك

لماذا كان لا بد أن يرحل HTTP/1.1

الصفحة الحديثة تحتاج عشرات الموارد — HTML وCSS وسكربتات وصور وخطوط. كان HTTP/1.1 يعالج طلبًا واحدًا في كل مرة لكل اتصال، فتفتح المتصفحات نحو ستة اتصالات متوازية لكل مضيف وتصفّ الباقي. كل اتصال يدفع مصافحته الخاصة من TCP وTLS، واستجابة بطيئة واحدة تعطّل كل ما اصطف خلفها على ذلك الاتصال. وحيل تلك الحقبة — لوحات السبرايت وتقسيم النطاقات والتضمين — كانت كلها ألاعيب لتهريب موارد أكثر عبر أنابيب أقل من اللازم.

ما الذي أصلحه HTTP/2

استبدل HTTP/2 ‏(2015) بالأنابيب أنبوبًا واحدًا: اتصال واحد يحمل تدفقات متوازية كثيرة. أي عدد من الطلبات والاستجابات يتداخل دون اصطفاف خلف بعضه في طبقة HTTP؛ وتُضغط الترويسات بدل تكرارها كاملة مع كل طلب؛ وتُدفع كلفة المصافحة مرة واحدة.

للمواقع الحقيقية كانت هذه هي القفزة الكبرى — اختفت بهلوانية الاتصالات الستة، وصارت الصفحات كثيرة الموارد الصغيرة أسرع بشكل درامي. وهو البروتوكول الذي يقدّمه معظم الويب، ومعظم شبكات CDN، اليوم. حاشية صادقة واحدة: نقل HTTP/2 مشكلة رأس الطابور طبقةً إلى الأسفل بدل إزالتها. فكل تلك التدفقات المتوازية تركب اتصال TCP واحدًا، وTCP يصرّ على تسليم البايتات بالترتيب — فحزمة مفقودة واحدة توقف *كل* التدفقات حتى تُعاد. على الشبكات النظيفة هذا نادر؛ وعلى إشارة جوال ضعيفة هو الضريبة التي تدفعها.

ما الذي يغيّره HTTP/3 في الأسفل

يهاجم HTTP/3 ‏(2022) تلك الضريبة المتبقية باستبدال TCP بـ QUIC، وهو نقل مبني على UDP مدمج فيه TLS 1.3. ثلاثة أشياء تتغير فعلًا. تصبح المصافحات أرخص: يُتفاوض على النقل والتشفير معًا، فيكلّف الاتصال الجديد جولة ذهاب وإياب واحدة بدل اثنتين أو ثلاث — وإعادة الاتصال بخادم معروف قد تكلّف صفرًا. ويكفّ فقد الحزم عن العدوى: يتتبّع QUIC التدفقات باستقلال، فالحزمة المفقودة توقف تدفقها وحده لا كل ما في الطريق. وتنجو الاتصالات من تغيّر الشبكة: الانتقال من Wi-Fi إلى بيانات الجوال يرحّل الاتصال بدل قتله.

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

التقدير الصادق: كم تساوي كل خطوة

على اتصال جيد قريب من الخادم، يمثّل HTTP/3 فوق HTTP/2 عادةً تحسّنًا صغيرًا بنسبة أحادية الخانة — حقيقي وقابل للقياس وغير مرئي لإنسان. وعلى وصلة جوال فاقدة للحزم وعن بعد، قد يكون فرقًا كبيرًا محسوسًا. أما القفزة من HTTP/1.1 إلى HTTP/2 فكانت، بالمقابل، كبيرة للجميع تقريبًا. إن كانت حركتك جوّالة بكثافة أو بعيدة الانتشار، فإن HTTP/3 يهم كموناتك الطرفية؛ وإن كانت غالبًا سطح مكتب على شبكات لائقة، فهو صقل.

في الأثناء لم تتحرك الأشياء المهيمنة على زمن التحميل: كم المحتوى قريب (كاش الحافة)، وكم هو ثقيل (الصور والضغط)، وكم منه يحجب العرض. صفحة مخزّنة ومضغوطة بـ Brotli ومحسّنة الصور عبر HTTP/2 تهزم صفحة غير محسّنة عبر HTTP/3 في كل مرة — البروتوكولات تحسم ميلي الثواني، والتوصيل يحسم الثواني. حافتنا تقدّم HTTP/2 اليوم، وهناك يسكن المكسب البروتوكولي الحاسم؛ وروافع التوصيل فوقه هي حيث تذهب بقية ميزانية سرعتك.

افحص ما يتحدثه موقعك فعلًا

لا حاجة للتخمين. في المتصفح افتح DevTools ← Network وفعّل عمود Protocol واقرأه: h2 يعني HTTP/2 وh3 يعني HTTP/3. ومن الطرفية يجيب curl في سطر واحد. وما دمت هناك، انظر أيضًا في ترويسات الاستجابة إلى حالة الكاش — فترقية بروتوكول على جولة أصل غير مخزّنة تلميعٌ للطبقة الخطأ.

افحص البروتوكول المتفاوَض عليه عبر curl

# which protocol does the server negotiate?
curl -sI --http2 https://www.example.com -o /dev/null -w 'protocol: %{http_version}\n'

# full picture: protocol + timing + cache status
curl -sI https://www.example.com -w 'protocol: %{http_version}  ttfb: %{time_starttransfer}s\n' | grep -i -E 'HTTP/|cache|protocol|ttfb'

ترتيب عمل عاقل

عامل البروتوكول كرافعة واحدة على اللوحة، لا اللوحة كلها. احصد المكاسب الحاسمة أولًا: قدّم عبر كاش الحافة ليكون المحتوى قريبًا، واضغط النصوص بـ Brotli، وحوّل الصور إلى WebP/AVIF بأبعاد صادقة — هذه تحرّك ثوانيَ ويستفيد منها كل زائر. تعدد الإرسال في HTTP/2 صار من البديهيات وهو يحمل طلباتك بالتوازي أصلًا. ثم، إن أظهرت بياناتك الميدانية أن كمونات الجوال الطرفية هي موضع ألمك، فترقيات البروتوكول تستحق الانتباه — مقيسةً على أرقامك أنت، لا على معيار مورّد.

الحقيقة غير المريحة في نقاشات البروتوكولات أنها ممتعة ومحسومة في معظمها، بينما وزن الصور ومعدل إصابة الكاش مملّان وحاسمان. حسّن بهذا الترتيب.