HTTP/2 ve HTTP/3 (QUIC) API performansını nasıl etkiler?
Soru
Mobil uygulamamız tek ekranda profil, bildirim, sepet ve önerileri çekmek için API'ya 4-5 isteği aynı anda atıyor. HTTP/1.1'de bağlantı limitleri ve head-of-line blocking yüzünden ekran geç doluyor; domain sharding ile uğraşıyoruz. Altyapıyı HTTP/2 ya da HTTP/3'e taşımanın mimari faydası ne olur? Nginx/Caddy katmanında TLS handshake'ini nasıl optimize ederim?
Cevap
Kısa cevap: Tek ekrandaki 4-5 paralel istek senin için HTTP/2’nin en güçlü olduğu senaryo — hemen aç; mobil kitle ağırlıktaysa HTTP/3 ile devam et.
Yaşadığın şey protokol seviyesinde bir darboğaz: HTTP/1.1 her host’a sınırlı sayıda bağlantı açar ve aynı bağlantıdaki bir istek ötekini bekletir (head-of-line blocking). Domain sharding bunu kapatmak için uydurulmuş bir hile; çözüm değil, semptom.
- HTTP/2 çoklamayı (multiplexing) tek bağlantıya indirir. 4-5 isteğin tamamı tek TCP+TLS bağlantısı üzerinden eşzamanlı akar; artık “host başına 6 bağlantı” limiti yok, domain sharding’e de gerek kalmaz. Üstüne HPACK header sıkıştırması var — “ekran başına çok sayıda küçük istek” deseninde tekrar eden header’lar neredeyse bedavaya gelir. Senin tam da derdine birebir.
- HTTP/2’nin kör noktası: TCP seviyesinde HOL blocking. Çoklama HTTP katmanında; ama altta tek bir TCP akışı var. Bir paket düşerse o paket yeniden gelene kadar TÜM stream’ler bekler. Sağlam Wi-Fi’da fark etmez; ama paket kaybının yüksek olduğu mobil/hücresel ağlarda bu seni geri vurur.
- HTTP/3 (QUIC) bu kör noktayı kapatır. QUIC, UDP üzerinde çalışır ve her stream’i bağımsız taşır; bir paket kaybı sadece o stream’i etkiler, ötekiler akmaya devam eder. Ayrıca bağlantı kurulumu daha hızlı (TLS handshake’i QUIC’e gömülü,
0-RTTile resumption) — flaky mobil ağda asıl kazanç burada. - Nginx/Caddy katmanında handshake’i ucuzlat. TLS’i edge’de sonlandır: Caddy’de HTTP/3 zaten varsayılan, Nginx 1.25+ ile
http2/http3direktiflerini aç.keep-alive’ı koru,OCSP staplingveTLS session resumption(session ticket) ile her bağlantıda yeniden el sıkışmayı engelle. Bir de: çoklamanın işe yaraması için tek origin’de topla — sharding’i geri sokarsan HTTP/2’nin faydasını kendi elinle iptal edersin.
Sonuç: Ben olsam önce HTTP/2’yi açardım — ucuz, geriye dönük uyumlu, mevcut darboğazının çoğunu hemen çözer. Sonra mobil kitle için HTTP/3’ü eklerdim; QUIC’in stream-bazlı bağımsızlığı ve hızlı kurulumu, kötü ağda kullanıcının hissettiği farktır. Tek origin, açık keep-alive, stapling ve session resumption — handshake maliyetini buradan kısarsın. Domain sharding’i ise tamamen kaldır; HTTP/2 dünyasında o artık bir anti-pattern.
Yorumlar
Yorum yapmak için GitHub hesabınızla giriş yapmanız yeterli. Yorumlar GitHub Discussions üzerinde saklanır.