İçeriğe geç
Muhammet Şafak
en
Soran: Kerem Cevaplandı:

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.

  1. 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.
  2. 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.
  3. 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-RTT ile resumption) — flaky mobil ağda asıl kazanç burada.
  4. 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/http3 direktiflerini aç. keep-alive’ı koru, OCSP stapling ve TLS 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.

Etiketler: #performans#altyapı#ağ
Paylaş:

Yorumlar

Yorum yapmak için GitHub hesabınızla giriş yapmanız yeterli. Yorumlar GitHub Discussions üzerinde saklanır.

Diğer Sorular

Tüm sorular

Sitede Ara

Yazı, proje ve sayfalarda arama yapmak için yazmaya başlayın.

Esc ile kapat Pagefind ile güçlendirildi