İçeriğe geç
Yeni yazı çıkınca e-posta · 4.812 abone 242 rehber · 78 ipucu · 58 komut RSS GitHub LinkedIn İletişim
Ara Ctrl K Bültene katıl
Tüm arşiv · 242 rehber →
Tüm araçlar · 75 üreteç →
Web Sunucu

HTTP/2 ve HTTP/3: ne değişti, gerçekte ne kazandırır

Baş bloklama sorununun iki katmandaki hâli, çoğullama, HTTP/3'ün TCP'yi bırakma nedeni, eski iyileştirmelerin neden zarara dönüştüğü ve geçiş kararı.

Mustafa Çelik 27 Ağustos 2026 · 6 dk okuma

HTTP’nin yeni sürümleri, tarayıcı ile sunucu arasındaki konuşmanın taşınma biçimini değiştirir; ne konuşulduğunu değil. Aynı adresler, aynı başlıklar, aynı durum kodları geçerlidir — değişen şey verimliliktir.

Çözmeye çalıştıkları sorun

Eski sürümde bir bağlantı üzerinden aynı anda tek bir istek işlenebilirdi. Yanıt gelmeden sıradaki gönderilemezdi.

Modern bir sayfa onlarca kaynak ister. Tarayıcılar bu sınırı aşmak için aynı sunucuya birkaç bağlantı birden açtı — ama her bağlantı ayrı bir kurulum maliyeti demektir.

Geliştiriciler de kendi yöntemlerini geliştirdi: dosyaları tek bir büyük dosyada birleştirmek, görselleri tek bir görsele toplamak, kaynakları farklı alan adlarına dağıtmak.

Bu çözümlerin tamamı, artık gereksiz olmakla kalmayıp zarar verir hâle geldi. Nedeni aşağıda.

HTTP/2: tek bağlantı, çok akış

Getirdiği asıl yenilik çoğullamadır: tek bir bağlantı üzerinden aynı anda çok sayıda istek ve yanıt taşınır. Yanıtlar sırayı beklemez.

İkinci kazanç başlık sıkıştırmasıdır. Her istek benzer başlıkları tekrar taşır; bunların sıkıştırılması, çok sayıda küçük istekte belirgin fark yaratır.

Pratik sonucu şudur: küçük dosyalar artık bir sorun değildir. Bu yüzden eski birleştirme teknikleri ters etki yapar — tek bir büyük dosya, içindeki tek bir satır değiştiğinde tamamen yeniden indirilir. Ayrı dosyalar ise yalnızca değişen parçanın yeniden indirilmesini sağlar.

Kaynakları farklı alan adlarına dağıtmak da artık zarardır: her yeni alan adı, yeni bir bağlantı ve yeni bir ad çözümlemesi demektir. Maliyeti DNS nasıl çalışır yazısındaki adımlardan görülebilir.

TCP katmanındaki bloklama

HTTP/2 uygulama katmanındaki sıra sorununu çözdü — ama bir katman altta aynı sorun kaldı.

TCP, verinin sırayla teslim edilmesini garanti eder. Bir paket kaybolduğunda, arkasından gelen paketler ulaşmış olsa bile uygulamaya verilmez; kayıp paket yeniden gelene kadar beklerler.

Tek bağlantıda çoğullama yapıldığı için, tek bir kayıp paket tüm akışları birden durdurur. Kayıp oranı yüksek ağlarda — mobil bağlantılar, zayıf kablosuz — HTTP/2 bazen eski sürümden daha kötü davranır.

HTTP/3: TCP’yi bırakmak

Çözüm, taşıma katmanını değiştirmekti. HTTP/3, TCP yerine UDP üzerine kurulu yeni bir taşıma protokolü kullanır.

Üç somut kazanç sağlar.

Akışlar birbirinden bağımsızdır. Bir akıştaki kayıp, diğerlerini durdurmaz.

Bağlantı kurulumu kısadır. Şifreleme taşımanın içine gömülüdür; ayrı bir el sıkışma turu gerekmez.

Bağlantı ağ değişikliğinden sağ çıkar. Bağlantı, IP adresine değil bir kimliğe bağlıdır. Telefon kablosuzdan mobil veriye geçtiğinde bağlantı kopmaz — bu, mobil kullanıcılar için en görünür kazançtır.

Şifrelemenin isteğe bağlı olmaması da bir tercihtir: HTTP/3 her zaman şifrelidir. Sertifika tarafı TLS sertifikası nasıl çalışır ve otomasyon sertifikayı otomatik yenilemek yazılarında.

Kurulum tarafındaki sonuçlar

Geçiş genelde öndeki katmanda yapılır ve arka uçları değiştirmez.

İki ayrıntı atlanır.

UDP trafiğinin geçmesi gerekir. Kurumsal güvenlik duvarlarının bir bölümü, 443 numaralı port üzerindeki UDP trafiğini öntanımlı olarak engeller. Bu durumda istemci sessizce eski sürüme döner; sorun görünmez ama kazanç da yoktur.

Günlükler ve araçlar uyumlu olmalıdır. Paket düzeyinde inceleme yapan araçların bir bölümü yeni protokolü çözemez; paket yakalama ne zaman gerekir yazısındaki yöntemler bu trafikte sınırlı kalır.

Öndeki katmanın rolü ters vekil nedir yazısında.

Kazanç ne kadar

Beklenti gerçekçi tutulmalıdır.

Hızlı ve düşük gecikmeli bir bağlantıdan bağlanan bir kullanıcı için fark küçüktür. Kazanç, kötü koşullarda ortaya çıkar: yüksek gecikme, paket kaybı, mobil ağ.

Bu yüzden ölçümü de laboratuvarda değil gerçek kullanıcı verisiyle yapmak gerekir. Ortalamaya değil yüzdelik dilimlere bakılmalıdır; en kötü yüzde beşteki kullanıcı, ortalamanın gizlediği kullanıcıdır.

Ve tek başına protokol sürümü, yavaş bir arka ucu hızlandırmaz. Sunucu tarafındaki süre neyse odur; teşhis yolu erişim günlüğü okumak yazısında.

Sürüm anlaşması nasıl olur

İstemci ile sunucu, hangi sürümü konuşacaklarına bağlantı kurulurken karar verir.

HTTP/2 için bu, şifreli el sıkışmanın içinde yapılır; ek bir tur gerekmez. HTTP/3 içinse farklı çalışır: sunucu, yanıtında “beni şu adresten yeni protokolle de bulabilirsin” bilgisini gönderir ve tarayıcı sonraki isteklerde onu dener.

Bunun pratik sonucu, ilk isteğin genelde eski protokolle gitmesidir. Yani tek bir sayfa açılışında ölçüm yaparken, beklenen sürümü görmemek bir arıza değil normal davranış olabilir.

Kısaca

HTTP/2 tek bağlantı üzerinde çoğullama getirdi; HTTP/3 ise altındaki TCP bloklamasını kaldırmak için taşıma katmanını değiştirdi.

Geçişten sonra eski iyileştirmeleri geri alın — dosya birleştirme ve alan adı dağıtma artık zarar veriyor. Ve kazancı ölçerken ortalamaya değil, kötü bağlantıdaki kullanıcılara bakın; fark orada ortaya çıkar.

Mustafa Çelik

Altyapı ve Operasyon Müdürü, İstanbul. 25 yıldır BT altyapısı, sistem yönetimi ve ağ altyapısıyla uğraşıyor; öğrendiklerini bu blogda üretim ortamında denenmiş rehberlere çeviriyor.

Hakkımda

Bu rehber işinize yaradıysa, sonrakini kaçırmayın.

Yeni yazı yayınlandığında tek e-posta. Takvim yok, dilediğiniz an çıkabilirsiniz.

Bülten sağlayıcısı henüz bağlanmadı. Bağlanana kadar e-posta ile yazabilirsiniz ya da RSS akışını takip edebilirsiniz.