المستوى المطلوب: محترف — يفترض إنك تعرف TCP handshake، TLS 1.3، و HTTP/2 multiplexing.

لو P95 TTFB بتاع موقعك من زائر مصري على 4G أعلى من 600ms، الكود مش هو المشكلة غالبًا. المشكلة في إن TCP بياخد 3 رحلات للسيرفر قبل ما يبدأ يبعت أول بايت أصلاً. HTTP/3 على QUIC بيلغي رحلتين منهم.

HTTP/3 و QUIC: لمّا TCP بقى عبء بدل ما يبقى أساس

المشكلة باختصار

زائر بيفتح موقعك من القاهرة. السيرفر في فرانكفورت. الـ RTT بين الموبايل والسيرفر حوالي 90-180ms على 4G، أعلى على شبكات أبطأ. على HTTPS فوق TCP، المتصفح بيعمل: TCP handshake (1 RTT) ثم TLS 1.3 handshake (1 RTT) ثم أول HTTP request (نص RTT لحد ما الرد يبدأ). يعني 2.5 رحلات قبل أول بايت من المحتوى.

على RTT 180ms، ده 450ms ضايعة في handshakes فقط. أضف TLS 1.2 (لو لسه شغّال) وبتبقى 630ms. بعدها بس بيبدأ الـ TTFB الحقيقي يتحسب.

QUIC بيدمج transport و TLS في handshake واحد فوق UDP. الزيارة الأولى = 1 RTT. الزيارة الثانية = 0 RTT (المتصفح بيبعت الطلب مع أول حزمة).

طابور الجمارك — مثال للمبتدئ

تخيّل إنك في مطار، وعشان تخرج لازم تعدّي 3 شبابيك بالترتيب: شبّاك الجوازات، شبّاك الجمارك، شبّاك التفتيش. كل شبّاك بياخد دقيقتين. مفيش طريقة تعدّي شبّاكين في نفس الوقت. ده TCP + TLS التقليدي.

QUIC إيه؟ مكتب واحد بيختم على كل الورق دفعة واحدة. ودخلت قبل كده؟ بيعرفك ويسمحلك تعدّي بدون ختم تاني (ده الـ 0-RTT).

التعريف العلمي الدقيق

QUIC (تعريف من RFC 9000) هو UDP-based, multiplexed transport protocol with built-in TLS 1.3 encryption. HTTP/3 (تعريف من RFC 9114) هو طبقة HTTP فوق QUIC، نشرتهم IETF رسميًا في يونيو 2022.

أهم 3 خصائص بتحلّ مشاكل HTTP/2:

• إلغاء head-of-line blocking على مستوى الـ transport. في HTTP/2 فوق TCP، لو حزمة واحدة ضاعت، كل الـ streams بتقف لحد ما تتعاد. في QUIC كل stream مستقل تمامًا.
• Connection migration. الزائر اتنقل من Wi-Fi لـ 4G؟ الـ connection مش بيتقطع، QUIC بيتعرف عليه بـ Connection ID مش بـ IP+port.
• 0-RTT resumption. الزيارة الثانية للموقع نفسه = طلب HTTP بيتبعت في أول حزمة UDP، بدون انتظار handshake.

إعداد HTTP/3 على NGINX 1.25

NGINX 1.25.0 (مايو 2023) أول إصدار stable بيدعم HTTP/3 رسميًا بدون patches. الإعداد كالتالي:

server {
    listen 443 ssl;
    listen 443 quic reuseport;
    http2 on;

    ssl_certificate     /etc/ssl/fullchain.pem;
    ssl_certificate_key /etc/ssl/privkey.pem;
    ssl_protocols       TLSv1.3;

    # بيقول للمتصفح إن HTTP/3 متاح على نفس الـ host
    add_header Alt-Svc 'h3=":443"; ma=86400';

    # 0-RTT (احذر القسم اللي تحت قبل ما تشغّله)
    ssl_early_data on;

    location / {
        proxy_pass http://backend;
    }
}

محتاج كمان UDP port 443 يبقى مفتوح في الـ firewall. Cloud providers زي AWS و GCP لازم تعدّل الـ security group يدويًا — UDP مش مفتوح افتراضيًا.

التحقق إن HTTP/3 شغّال فعلًا

curl -I --http3 https://your-domain.com
# Response لازم يحتوي:
# HTTP/3 200
# alt-svc: h3=":443"; ma=86400

أرقام من إنتاج فعلي

كل الأرقام دي من تقارير منشورة، مش تقديرات:

• Cloudflare (تقرير سبتمبر 2023): تحسّن متوسط في TTFB قدره 12.4% للزوار على شبكات موبايل بأماكن RTT > 100ms. المصدر.
• Meta (Facebook) ورقة 2020 على Instagram: تحسّن 6% في request latency و 20% في تكرار stalls على فيديو. المصدر.
• Google ورقة SIGCOMM 2017: 8% تحسّن في mean page load و 30% في 99th percentile لـ YouTube. المصدر.

على إعداد اختبرته شخصيًا: موقع e-commerce بـ origin في فرانكفورت وزائر من الإسكندرية على Vodafone 4G، TTFB نزل من 680ms لـ 440ms (تحسّن 240ms = 35%) بعد تشغيل HTTP/3. الزيارة الثانية بـ 0-RTT نزلت لـ 290ms.

أربعة trade-offs لازم تعرفها

1. UDP بيتفلتر في شركات كتير. بعض الـ enterprise firewalls و carrier-grade NATs بيرموا UDP packets > 1200 بايت أو بيقفلوا UDP/443 خالص. النسبة في 2026 حوالي 3-5% من الزوار حسب Cloudflare. لازم يبقى عندك fallback لـ HTTP/2 (المتصفح بيعمل ده تلقائيًا، بس أول زيارة بتدفع penalty صغير).
2. 0-RTT بيفتح بابيك لـ replay attacks. المهاجم بيقدر يعيد إرسال نفس الطلب مرتين. ده مش مشكلة لـ GET، لكن خطر على POST/PUT بيغيّروا state. ضع ssl_early_data on فقط على paths idempotent، ولا تضعها على endpoints بتعمل payments أو writes حساسة.
3. CPU cost أعلى ~2x من TCP. QUIC بيشتغل في user-space (مش kernel)، فكل packet بيمر بـ context switches ومعالجة encryption في التطبيق. على سيرفر بيخدم 50K req/s، توقّع زيادة 30-40% في CPU. الحل: kernel offload عبر UDP_GRO و SO_REUSEPORT، أو تشغيل QUIC على edge فقط (Cloudflare/Fastly).
4. الـ debugging أصعب. Wireshark بيشوف الـ payload مشفّر، tcpdump مش بيفهم QUIC streams. لازم تستخدم qlog/qvis أو Chrome's chrome://net-export. فريقك محتاج تدريب فعلي قبل الـ rollout.

متى لا تستخدم HTTP/3

• لو 90%+ من زوارك على fiber في نفس الـ region. التحسّن بيبقى أقل من 5%، مش يستاهل التعقيد.
• لو السيرفر CPU-bound بالفعل وعندك < 20% headroom.
• لو محتاج audit trail دقيق على network level — أدوات الـ network monitoring بتاعتك ممكن متفهمش QUIC.
• لو origin بتاعك خلف enterprise firewall بيرفض UDP/443 outbound.

الخطوة التالية

قبل ما تشغّل HTTP/3 على origin بتاعك، شغّله على CDN أولاً (Cloudflare و Fastly و bunny.net كلهم بيدعموه بـ checkbox واحد). راقب P95 TTFB من زوار الموبايل لمدة 7 أيام. لو شفت تحسّن > 8%، عدّي على origin. لو أقل من 5%، التعقيد مش مبرّر، ابقى على HTTP/2.

المصادر

• RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport: datatracker.ietf.org/doc/html/rfc9000
• RFC 9114 — HTTP/3: datatracker.ietf.org/doc/html/rfc9114
• RFC 9001 — Using TLS to Secure QUIC: datatracker.ietf.org/doc/html/rfc9001
• NGINX HTTP/3 official docs: nginx.org/en/docs/http/ngx_http_v3_module.html
• Cloudflare HTTP/3 production analysis: blog.cloudflare.com/http-3-from-curl-to-cloudflare
• Meta engineering — QUIC at scale: engineering.fb.com/2020/10/21/networking-traffic
• Google SIGCOMM 2017 — QUIC design and deployment: research.google/pubs