كل مطور شاف مصطلح HTTP/2 و HTTP/3 بإعدادات Cloudflare أو Nginx وتساءل شو الفرق الفعلي، ولو في شي لازم يسوّيه. هاد شرح عملي بعيد عن التفاصيل النظرية الزايدة.
المشكلة الأصلية: HTTP/1.1
بـ HTTP/1.1، كل طلب بينتظر رد الطلب يلي قبله على نفس الاتصال. الحل التقليدي كان المتصفح يفتح عدة اتصالات TCP موازية لتحميل صفحة فيها عشرات الملفات (CSS، JS، صور) بنفس الوقت — حل شغّال بس مكلف.
HTTP/2: نفس TCP، استخدام أذكى
HTTP/2 حل المشكلة بدون تغيير بروتوكول النقل (لسا TCP)، بس غيّر طريقة استخدامه:
- تعدد الإرسال (Multiplexing): كذا طلب ورد بنفس الوقت على اتصال TCP وحيد، مو اتصالات موازية.
- ضغط الرؤوس (HPACK): الرؤوس المتكررة بين الطلبات (زي User-Agent وCookie) بتنضغط، فبتقل البيانات المنقولة.
- أولوية للطلبات: العميل فيه يحدد أي مورد أهم فيوصل أول.
النتيجة: تحسّن ملموس بالأداء، وبمعظم الحالات المتصفحات ما بتدعم HTTP/2 إلا فوق TLS (يعني HTTPS إلزامي فعليًا للاستفادة منه، حتى لو نظريًا في نسخة غير مشفّرة).
المشكلة يلي بقيت: TCP نفسه
TCP بروتوكول تسلسلي بطبيعته. لو ضاعت حزمة وحدة بالطريق، TCP بيوقف كل البيانات (بكل الطلبات المتعددة الي بتشاركوا نفس الاتصال) لحد ما توصل الحزمة المفقودة من جديد. هاي المشكلة اسمها Head-of-Line Blocking على مستوى النقل، ومهما حسّنت HTTP فوقها، بتضل موجودة تحتها.
HTTP/3: بروتوكول نقل جديد اسمه QUIC
HTTP/3 استبدل TCP ببروتوكول جديد اسمه QUIC، مبني فوق UDP:
HTTP/1.1 → فوق TCP
HTTP/2 → فوق TCP (نفسه، استخدام أذكى)
HTTP/3 → فوق QUIC (مبني فوق UDP)
- بلا Head-of-Line Blocking على مستوى النقل: كل تدفق (stream) بـ QUIC مستقل عن غيره، فحزمة ضايعة بتأخر تدفقها بس، مو باقي الطلبات.
- اتصال أسرع: QUIC بيدمج مصافحة النقل والتشفير بخطوة وحدة تقريبًا (0-RTT أو 1-RTT)، بدل مصافحة TCP بعدها مصافحة TLS منفصلة زي بـ HTTP/2.
- هجرة الاتصال (Connection Migration): الاتصال معرّف برقم (Connection ID) مو بعنوان IP والمنفذ، فلو انتقلت من Wi-Fi لبيانات الجوال، الاتصال بيكمل بلا انقطاع — أمر TCP ما بيعرف يسويه.
جدول المقارنة
| المعيار | HTTP/2 | HTTP/3 |
|---|---|---|
| بروتوكول النقل | TCP | QUIC (فوق UDP) |
| Head-of-Line Blocking | موجود على مستوى النقل | غير موجود |
| ضغط الرؤوس | HPACK | QPACK |
| سرعة إنشاء الاتصال | مصافحة TCP + TLS منفصلتين | شبه مدمجة (0-RTT/1-RTT) |
| تبديل الشبكة (Wi-Fi ↔ جوال) | ينقطع الاتصال | يستمر بلا انقطاع |
| التشفير | فعليًا إلزامي (h2 فقط بالمتصفحات) | جزء أساسي من QUIC نفسه |
شو استفادتك كمطور فعليًا؟
بمعظم الحالات ما بتغيّر كود تطبيقك إطلاقًا. القرار مستوى بنية تحتية: هل السيرفر أو الـ CDN يلي عم تستخدمه مفعّل عنده HTTP/3؟ المتصفح والسيرفر بيتفقوا تلقائيًا على أفضل إصدار متاح أثناء مصافحة TLS، فما في تبديل يدوي بالكود.
الفرق الملموس بيظهر أكتر بموقع فيه عشرات الملفات (JS/CSS/صور) وبمستخدمين عالشبكات المتقلبة (جوال، Wi-Fi عام) — هاد بالضبط سيناريو HTTP/3 مصمم له.
الخلاصة
HTTP/2 حسّن استخدام TCP بدون تغييره، وHTTP/3 غيّر طبقة النقل نفسها (QUIC فوق UDP) عشان يحل مشكلة كانت جوّا TCP من الأساس. الاثنين موجودين اليوم بالتوازي، والمتصفح بيختار الأنسب تلقائيًا — دورك الأساسي إنك تتأكد إن سيرفرك أو استضافتك بتدعم أحدث إصدار متاح.
تعلّم أساسيات الشبكات كاملة بالعربي — من نموذج OSI لـ HTTP/2 وHTTP/3 وWebSocket.