HTTP/2 ve HTTP/3 ile Performans İyileştirmeleri

HTTP/2 ve HTTP/3 ile Performans İyileştirmeleri

Web performansı denince akla ilk gelenler genellikle kod optimizasyonu, CDN ve önbellekleme olur. Ancak altta yatan taşıma katmanı protokolü, tüm bu iyileştirmelerin ne kadar etkili olacağını belirler. HTTP/1.1'den HTTP/2'ye ve oradan HTTP/3'e geçiş, sadece bir sürüm atlaması değil; gecikme, güvenilirlik ve mobilite açısından temel bir paradigma değişimidir.

1. HTTP/2: TCP Üzerinde Çoklama ve Sıkıştırma

HTTP/2, HTTP/1.1'in en büyük sorununu çözmek için tasarlandı: her istek için ayrı bağlantı kurma maliyeti. Tek bir TCP bağlantısı üzerinden birden fazla isteği eşzamanlı olarak iletebilir (multiplexing) . Ayrıca HPACK başlık sıkıştırması ile her istekte tekrarlanan başlıkları (User-Agent, Cookie vb.) sıkıştırarak bant genişliği tasarrufu sağlar .

Sağladığı Kazançlar:

Bağlantı Kurulum Maliyetinin Azalması: Tek bağlantı, birçok isteği taşır; TLS el sıkışması bir kez yapılır .
Başlık Yükünün Azalması: HPACK, tekrarlayan başlıkları kompakt hale getirir .

HTTP/2'nin Çözemediği Sorun: TCP Baş-Engelleme (HOL)

HTTP/2'nin tüm çoklama yeteneğine rağmen, altında hala TCP vardır. TCP, paketleri sıralı teslim etmek zorundadır. Tek bir paket kaybolduğunda, o paketin arkasındaki tüm veriler (diğer isteklere ait olsa bile) bekletilir. Buna TCP head-of-line (HOL) blocking denir. Yani, HTTP/2 çoklama kazancı, paket kaybı olan ağlarda önemli ölçüde buharlaşır .

2. HTTP/3: QUIC Üzerinde HOL'u Ortadan Kaldırma

HTTP/3, taşıma katmanında TCP yerine QUIC kullanır. QUIC, UDP üzerine inşa edilmiş, güvenilirlik ve sıkıştırmayı kendi içinde barındıran yeni bir protokoldür.

HTTP/3'ün Getirdiği Temel İyileştirmeler:

Özellik	HTTP/2 (TCP)	HTTP/3 (QUIC)
HOL Engelleme	Var (paket kaybında tüm istekler etkilenir)	Yok (kayıp, yalnızca ilgili akışı etkiler)
Bağlantı Kurulumu	TCP + TLS = 2-3 RTT	QUIC + TLS 1.3 = 1 RTT (veya 0-RTT)
Ağ Değişimi	Bağlantı kopar, yeniden kurulur	Bağlantı kimliği korunur, kesintisiz devam eder
İlk Bayt Süresi (TTFB)	Daha yüksek	0-RTT ile önemli ölçüde düşük

QUIC'in Sihri: Akış Bazlı Kurtarma
QUIC'te her istek bağımsız bir akış (stream) olarak taşınır. Bir paket kaybolduğunda, yalnızca o pakete ait akış etkilenir; diğer akışlar veri almaya devam eder. Bu, özellikle kayıplı ağlarda HTTP/3'ü HTTP/2'den belirgin şekilde üstün kılar .

3. Gerçek Dünya Ölçümleri: HTTP/3 Her Zaman Kazanır mı?

Akademik ölçümler, HTTP/3'ün avantajlarının ağ koşullarına ve iş yüküne sıkı sıkıya bağlı olduğunu gösteriyor.

HTTP/3'ün Öne Çıktığı Durumlar:

Paket Kaybı ve Gecikme: 2025 tarihli bir çalışma, HTTP/3'ün yüksek paket kaybı koşullarında HTTP/2'yi sürekli olarak geçtiğini, gecikme odaklı senaryolarda ise daha kararlı bir verim sunduğunu göstermiştir .
0-RTT ile TTFB: Ticari bir 5G ağında yapılan ölçümde, QUIC'in 0-RTT özelliği, TCP'nin 3 yönlü el sıkışmasına kıyasla medyan TTFB'yi %70 azaltmıştır .

HTTP/3'ün Geri Kaldığı Durumlar:

Yoğun Eşzamanlı İş Yükleri: 360° video akışı üzerine 2026 tarihli bir IEEE çalışması, HTTP/3'ün verim, TTFB ve enerji verimliliğinde HTTP/2'nin gerisinde kaldığını bulmuştur. Nedeni: Çok sayıda eşzamanlı tile isteği, QUIC'te TLS işleme ve bağlantı kurulumu sırasında CPU darboğazı yaratmaktadır .
Karmaşık Ağ Yolları: 2026'da Çin'de yapılan bir vaka çalışması, farklı ISS'ler arası (cross-ISP) yollarda HTTP/3'ün 20MB yük aktarımında %24 başarı oranına düştüğünü (HTTP/2'de %70), bunun el sıkışma hatası değil, aktarım ortasında takılma olduğunu göstermiştir .
SOHO Ağlarında: 2026 tarihli kapsamlı bir ölçüm çalışması, ev/ofis ağlarında HTTP/3 performansının büyük ölçüde kuyruk yönetimi, bağlantı çekişmesi ve yukarı bağlantı doygunluğu tarafından şekillendiğini, protokol tasarımının tek başına belirleyici olmadığını vurgulamıştır .

4. .NET'te HTTP/3 Kullanımı

.NET, Kestrel üzerinde HTTP/3 desteği sunar. Ancak dikkat edilmesi gereken noktalar vardır.

Kestrel'de HTTP/3 Etkinleştirme:

csharp

builder.WebHost.ConfigureKestrel(kestrel =>
{
    kestrel.ListenAnyIP(443, portOptions =>
    {
        portOptions.Protocols = HttpProtocols.Http1AndHttp2AndHttp3;
        portOptions.UseHttps(); // HTTP/3 için HTTPS zorunlu
    });
});

HTTP/3'ü HTTP/1.1 ve HTTP/2 ile birlikte yapılandırmak gerekir; çünkü tüm router, firewall ve proxyler HTTP/3'ü desteklemez .

Alt-svc ile Keşif: HTTP/3, alt-svc başlığı üzerinden keşfedilir. İlk istek HTTP/1.1 veya HTTP/2 ile gider, ardından bağlantı HTTP/3'e yükseltilir. Kestrel, HTTP/3 etkinleştirildiğinde bu başlığı otomatik ekler .

HttpClient ile HTTP/3:

csharp

var client = new HttpClient();
client.DefaultRequestVersion = HttpVersion.Version30;
client.DefaultVersionPolicy = HttpVersionPolicy.RequestVersionOrHigher;

YARP (Reverse Proxy) Desteği: YARP 1.1, hem gelen hem giden bağlantılarda HTTP/3'ü destekler. Gelen bağlantılar için Kestrel, giden bağlantılar için HttpClient yapılandırılır .

Kritik Uyarı: localhost üzerinde HTTP/3 testi yaparken tarayıcılar, Kestrel'in geliştirme sertifikası gibi öz imzalı sertifikaları kabul etmez. Test için HttpClient kullanılmalıdır .

5. Ne Zaman HTTP/2, Ne Zaman HTTP/3?

Senaryo	Öneri
Kayıplı, gecikmeli mobil ağlar	HTTP/3 (HOL yok, 0-RTT kazancı)
Sık ağ değiştiren mobil cihazlar	HTTP/3 (bağlantı taşıma)
Yoğun eşzamanlı istekler (360° video, tile tabanlı)	HTTP/2 (QUIC CPU maliyeti yüksek)
Farklı ISS'ler arası, istikrarsız yollar	Dikkatli test; HTTP/3 her zaman kazanmaz
Genel web uygulamaları, API'ler	HTTP/2 yeterli; HTTP/3 kademeli etkinleştirilebilir

6. En İyi Pratikler

Pratik	Açıklama
HTTP/2'yi varsayılan yapın	Geniş destek, düşük CPU maliyeti, olgun araçlar
HTTP/3'ü kademeli etkinleştirin	Alt-svc ile keşif; sorun çıkarsa HTTP/2'ye dönüş kolay
0-RTT'yi idempotent isteklerle sınırlayın	0-RTT yeniden oynatma (replay) riski taşır; yalnızca GET gibi güvenli metotlarda kullanın
Kendi iş yükünüzü ölçün	Genel benchmark'lar yanıltıcı olabilir; gerçek trafik deseninizle test edin
CPU ve bellek maliyetini izleyin	Özellikle yoğun eşzamanlı iş yüklerinde QUIC ek yük getirebilir

Sonuç

HTTP/2, TCP üzerinde çoklama ve başlık sıkıştırması ile önemli kazançlar sağlar, ancak TCP'nin doğasında olan baş-engelleme sorununu çözemez. HTTP/3 ve QUIC, bu sorunu ortadan kaldırır ve özellikle kayıplı, gecikmeli ve mobil ağlarda belirgin avantajlar sunar. Ancak HTTP/3 her derde deva değildir: yoğun eşzamanlı iş yüklerinde CPU maliyeti nedeniyle HTTP/2'nin gerisinde kalabilir ve karmaşık ağ yollarında performans düşüşleri yaşanabilir. Doğru strateji, HTTP/2'yi sağlam bir temel olarak korumak, HTTP/3'ü kademeli olarak etkinleştirmek ve kendi iş yükünüzü ölçerek karar vermektir. Unutmayın: Protokol seçimi, ağ koşullarınız ve iş yükü deseninizle şekillenir; "en yeni" her zaman "en hızlı" değildir.