# HTTP/2 ve HTTP/3 (QUIC) API performansını nasıl etkiler?

> HTTP/2'yi hemen açın; çoklama ekran başına 4-5 isteği tek bağlantıya indirir, mobil kitle ağırlıktaysa HTTP/3 ekleyin ve domain sharding'i kaldırın.

- Soruldu: 2026-05-21
- Yanıtlandı: 2026-05-24
- Soran: Kerem
- Etiketler: performans, altyapi, networking
- Kaynak: https://www.muhammetsafak.com.tr/sor-bakalim/http-2-ve-http-3-quic-api-performansina-etkisi/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**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?


Kısa cevap: Tek ekrandaki 4-5 paralel istek sizin için HTTP/2'nin en güçlü olduğu senaryo — hemen açın; mobil kitle ağırlıktaysa HTTP/3 ile devam edin.

Yaşadığınız ş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. Sizin tam da derdinize 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 sizi 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ın.** TLS'i edge'de sonlandırın: Caddy'de HTTP/3 zaten varsayılan, Nginx 1.25+ ile `http2`/`http3` direktiflerini açın. `keep-alive`'ı koruyun, `OCSP stapling` ve `TLS session resumption` (session ticket) ile her bağlantıda yeniden el sıkışmayı engelleyin. Bir de: çoklamanın işe yaraması için tek origin'de toplayın — sharding'i geri sokarsanız HTTP/2'nin faydasını kendi elinizle iptal edersiniz.

**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ız. Domain sharding'i ise tamamen kaldırın; HTTP/2 dünyasında o artık bir anti-pattern.

## İlgili Yazılar

- [CDN'de asset sürümleme: hash'leme ve cache stratejisini nasıl kurarım?](https://www.muhammetsafak.com.tr/sor-bakalim/cdn-asset-surumleme-hashleme-ve-cache-stratejisi/) — Sor Bakalım
- [2-5 GB dosyaları PHP belleğini şişirmeden stream ile nasıl indirtirim?](https://www.muhammetsafak.com.tr/sor-bakalim/buyuk-dosyalari-php-bellegini-sismeden-stream-ile-indirmek/) — Sor Bakalım
- [WireGuard ile Docker ağları çakışıyor; routing'i nasıl stabilize ederim?](https://www.muhammetsafak.com.tr/sor-bakalim/wireguard-ile-docker-agi-ip-cakismasi-ve-routing/) — Sor Bakalım