# 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://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.

## Kısa cevap

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. Aynı "kullanıcıya en yakın yerden hızlı dön" hedefinin önbellek tarafını [edge cache ve invalidation kaydında](/tr/sor-bakalim/cloudflare-workers-kv-ile-edge-cache-ve-invalidation/) ele almıştım.

## Neden

1. **HTTP/2 çoklamayı tek bağlantıya indirir.** 4-5 isteğin tamamı tek TCP+TLS bağlantısı üzerinden eşzamanlı akar; "host başına 6 bağlantı" limiti kalkar, domain sharding'e 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.

2. **HTTP/2'nin kör noktası TCP seviyesinde HOL blocking'dir.** Çoklama HTTP katmanında; 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; paket kaybının yüksek olduğu mobil ağda 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. Bağlantı kurulumu da daha hızlıdır (TLS handshake'i QUIC'e gömülü, `0-RTT` ile resumption).

## Ne yapmalı

1. **Önce HTTP/2'yi açın.** Ucuz, geriye dönük uyumlu, mevcut darboğazın çoğunu hemen çözer. Caddy'de hazır; Nginx'te 1.25.1'den beri ayrı bir `http2 on;` direktifi var (varsayılan kapalı).

2. **Mobil kitle ağırlıktaysa HTTP/3'ü ekleyin.** Caddy'de varsayılan; Nginx'te HTTP/3 modülü 1.25.0'dan beri var ama **deneysel** ve varsayılan derlemede yok — `--with-http_v3_module` ile derlenmiş bir binary gerekiyor, sonra `listen 443 quic;` ile açılıyor.

3. **Handshake'i ucuzlatın.** TLS'i edge'de sonlandırın, `keep-alive`'ı koruyun, `OCSP stapling` ve TLS session resumption (session ticket) ile her bağlantıda yeniden el sıkışmayı engelleyin.

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

## İlgili Yazılar

- [CDN'de asset sürümleme: hash'leme ve cache stratejisini nasıl kurarım?](https://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://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://muhammetsafak.com/tr/sor-bakalim/wireguard-ile-docker-agi-ip-cakismasi-ve-routing/) — Sor Bakalım