HTTP/2 vs HTTP/3: ne değişti, siteniz için ne anlama geliyor?

HTTP/1.1 neden gitmek zorundaydı

Modern bir sayfa onlarca kaynak ister — HTML, CSS, script'ler, görseller, fontlar. HTTP/1.1 bağlantı başına aynı anda tek isteği taşıyabildiğinden tarayıcılar host başına altı civarı paralel bağlantı açar, kalanı kuyruğa dizerdi. Her bağlantı kendi TCP ve TLS el sıkışmasını öderdi ve yavaş tek bir yanıt, o bağlantının arkasında kuyruğa girmiş her şeyi bekletirdi. O dönemin hilelerinin hepsi — sprite'lar, domain sharding, inlining — az sayıda borudan daha çok kaynak kaçırma numarasıydı.

HTTP/2 neyi düzeltti

HTTP/2 (2015) boruları tek boruyla değiştirdi: çok sayıda paralel akış taşıyan tek bağlantı. İstek ve yanıtlar HTTP katmanında birbirinin arkasında kuyruğa girmeden iç içe akar; başlıklar her istekte tam tekrarlanmak yerine sıkıştırılır; el sıkışma maliyeti bir kez ödenir.

Gerçek siteler için büyük sıçrama buydu — altı bağlantılık cambazlık ortadan kalktı ve çok sayıda küçük kaynaklı sayfalar ciddi hızlandı. Bugün web'in ve CDN'lerin çoğunun servis ettiği protokol budur. Dürüst bir dipnot: HTTP/2, kuyruk problemini yok etmedi, bir katman aşağı taşıdı. Bütün o paralel akışlar hâlâ tek TCP bağlantısında gider ve TCP baytları sırayla teslim etmekte ısrar eder — kaybolan tek paket, yeniden gönderilene kadar *bütün* akışları duraklatır. Temiz ağda bu nadirdir; zayıf mobil sinyalde ödediğiniz vergidir.

HTTP/3 altta neyi değiştiriyor

HTTP/3 (2022) kalan bu vergiye, TCP'yi QUIC ile değiştirerek saldırır: UDP üstüne kurulu, TLS 1.3'ü içine katlanmış bir taşıma katmanı. Gerçekte üç şey değişir. El sıkışma ucuzlar: taşıma ve şifreleme birlikte pazarlıklandığından yeni bağlantı iki-üç tur yerine tek tura mal olur — bilinen bir sunucuya yeniden bağlanmak sıfıra bile inebilir. Paket kaybı bulaşıcı olmaktan çıkar: QUIC akışları bağımsız izler; kaybolan paket yalnızca ait olduğu akışı bekletir, uçuştaki diğer her şeyi değil. Ve bağlantılar ağ değişimine dayanır: Wi-Fi'dan mobil veriye geçiş bağlantıyı öldürmek yerine taşır.

Desene dikkat edin — bu kazanımların her biri kusurlu ağlarla ilgilidir. HTTP/3'ün parladığı yer tam orasıdır: yüksek gecikmeli hatlar, kayıplı Wi-Fi, hareket hâlindeki mobil kullanıcılar, sunucuya uzun mesafeler.

Dürüst boyutlandırma: her adım ne kadar eder

Sunucuya yakın, iyi bir bağlantıda HTTP/3'ün HTTP/2'ye karşı kazancı tipik olarak düşük tek haneli yüzdedir — gerçek, ölçülebilir ve insana görünmez. Uzak mesafede kayıplı bir mobil hatta ise büyük ve hissedilir bir fark olabilir. Buna karşılık HTTP/1.1'den HTTP/2'ye sıçrama neredeyse herkes için büyüktü. Trafiğiniz ağırlıkla mobil ya da uzak coğrafyadaysa HTTP/3 kuyruk gecikmeleriniz için önemlidir; çoğunlukla düzgün ağlarda masaüstüyse bir rafinmandır.

Bu arada yükleme süresini belirleyen şeyler yerinden oynamadı: içerik ne kadar yakın (edge cache), ne kadar ağır (görseller, sıkıştırma) ve ne kadarı render'ı blokluyor. Cache'lenmiş, Brotli ile sıkıştırılmış, görselleri optimize edilmiş bir sayfa HTTP/2 üzerinde, optimize edilmemiş bir sayfayı HTTP/3 üzerinde her seferinde geçer — protokol milisaniyelere, dağıtım saniyelere karar verir. Edge'imiz bugün HTTP/2 servis ediyor; belirleyici protokol kazancı zaten orada yaşıyor, hız bütçenizin kalanı onun üstündeki dağıtım kollarına gidiyor.

Sitenizin gerçekte ne konuştuğunu kontrol edin

Tahmine gerek yok. Tarayıcıda DevTools → Network açın, Protocol sütununu etkinleştirin ve okuyun: h2 = HTTP/2, h3 = HTTP/3. Terminalden curl tek satırda cevaplar. Hazır bakmışken yanıt başlıklarında cache durumuna da bakın — cache'lenmemiş bir origin turunda protokol yükseltmek yanlış katmanı cilalamaktır.

Pazarlıklanan protokolü curl ile inceleyin

# which protocol does the server negotiate?
curl -sI --http2 https://www.example.com -o /dev/null -w 'protocol: %{http_version}\n'

# full picture: protocol + timing + cache status
curl -sI https://www.example.com -w 'protocol: %{http_version}  ttfb: %{time_starttransfer}s\n' | grep -i -E 'HTTP/|cache|protocol|ttfb'

Aklı başında bir işlem sırası

Protokolü panodaki tek kol değil, kollardan biri olarak görün. Önce belirleyici kazançları alın: içerik yakın olsun diye edge cache'ten servis edin, metni Brotli ile sıkıştırın, görselleri dürüst boyutlarda WebP/AVIF'e çevirin — bunlar saniyeleri oynatır ve her ziyaretçiye yarar. HTTP/2 multiplexing masa bahsidir ve isteklerinizi zaten paralel taşıyor. Sonra, saha veriniz acının mobil kuyruk gecikmelerinde olduğunu gösteriyorsa protokol rafinmanları ilgiyi hak eder — satıcı benchmark'ına karşı değil, kendi sayılarınıza karşı ölçülerek.

Protokol tartışmalarının rahatsız edici gerçeği şudur: eğlencelidirler ve büyük ölçüde sonuçlanmışlardır; görsel ağırlığı ve cache isabet oranı ise sıkıcı ve belirleyicidir. Bu sırayla optimize edin.