HTTP/2 ve HTTP/3, bağlantı katmanındaki verimliliği köklü biçimde dönüştürür. Ancak bu verimlilik, belirli altyapısal koşullar sağlanmadan ekran kartı olmayan bir bilgisayara takılı güçlü bir CPU kadar etkisiz kalabilir. Protokol değişikliğinin performans üzerinde anlamlı iz bırakabilmesi için öncelikle neyin iyileştiğini, neyin iyileşmediğini ve hangi ölçüm yönteminin farkı gerçekten gösterebileceğini anlamak gerekir.

"HTTP/2 her zaman daha hızlıdır" öncülünden değil, "HTTP/2 hangi koşullarda hızlanma üretir?" sorusundan başlamak çok daha doğru bir çerçeve kurar. Bu ayrım hem geçiş kararını hem de geçiş sonrası ölçüm yaklaşımını doğrudan etkiler.

Multiplexing bant genişliğini değil, bağlantı verimliliğini artırır

HTTP/1.1'de bir tarayıcı, tek bir domain için eş zamanlı olarak en fazla 6 bağlantı açabilir. Her bağlantı sırayla kaynak ister ve yanıt bekler; birden fazla istek aynı bağlantıda aynı anda gerçekleşemez. Bu kısıtlamayı aşmak için geliştiriciler domain sharding gibi geçici çözümlere başvurmuş, kaynak URL'lerini birden fazla alt alan adına dağıtmıştır. Her alt alan yeni bir TLS el sıkışması, yeni bir DNS çözümlemesi ve yeni bir bağlantı kurulumu demektir; dolayısıyla bu teknik kendi başına önemli bir ek yük taşır.

HTTP/2, bu modeli kökünden değiştirir. Tek bir TCP bağlantısı üzerinde yüzlerce istek eş zamanlı akış olarak taşınabilir. Tarayıcının 6 ayrı bağlantı kurmak yerine tek bir bağlantı üzerinden tüm kaynakları talep etmesi, bağlantı kurulum maliyetini ve TLS el sıkışma süresini önemli ölçüde düşürür. Pratikte 20 veya daha fazla küçük kaynak içeren sayfalarda bu tasarruf ölçülebilir bir yükleme süresi iyileşmesine dönüşebilir.

Bununla birlikte, multiplexing'in bant genişliğini artırmadığını vurgulamak gerekir. Sunucu ile istemci arasındaki fiziksel kapasite değişmez. Tek büyük bir dosya —örneğin 800 KB'lık bir video ön izlemesi— indirirken HTTP/2 ile HTTP/1.1 arasında anlamlı bir hız farkı oluşmaz; bant genişliği zaten tam kullanımdadır. Kazanım, küçük ve çok sayıda isteğin bir arada yapıldığı senaryolarda ortaya çıkar. SPA mimarileri, ikondan CSS parçalarına onlarca bağımsız kaynaktan oluşan sayfalar ve API çağrılarına yoğun bağımlı uygulamalar bu kategoriye girer.

Head-of-line blocking: TCP katmanında kalan sorun

HTTP/2'nin çözdüğü sorun, uygulama katmanındaki sıra kilididir. HTTP/1.1'de bir bağlantıda ilk yanıt gelmeden ikincisi işlenemez; bu kilidi HTTP/2 akış mekanizmasıyla ortadan kaldırır. Ancak taşıma katmanında —yani TCP'de— bu sorun varlığını sürdürür ve koşullar kötüleştiğinde oldukça belirgin bir etki yaratır.

TCP, paketleri sıralı ve kayıpsız teslim etmeyi garanti eder. Bir paket kaybolduğunda alıcı, kaybolan paketi yeniden talep eder ve o paket gelene dek sonraki tüm paketler bellekte bekler. HTTP/2 tek bir bağlantı üzerinde tüm akışları taşıdığı için, bu bekleyiş bağlantıdaki her akışı eş zamanlı olarak dondurur. HTTP/1.1'de ise 6 bağlantı bulunduğundan, bir bağlantıdaki kayıp diğer 5 bağlantıyı etkilemez; kaba da olsa bir yedeklilik mevcuttur.

Ağ kalitesi düşük olduğunda —özellikle yüzde 2–3 ve üzeri paket kaybı oranlarında— HTTP/2'nin çok akışlı yapısı bu bekleme süresinden orantısız biçimde etkilenir. Yüksek kaliteli sabit bağlantılarda bu tablo pek sorun üretmez. Ancak mobil kullanıcılar, değişken sinyal kalitesi olan bölgeler veya kötü hat koşullarındaki uç noktalar söz konusu olduğunda, iki protokol arasındaki fark beklenenden çok daha küçük çıkabilir. Gerçek kullanıcı trafiğini temsil eden saha verisi olmadan alınan protokol kararları bu nedenle yetersiz kalır.

QUIC, paket kaybını akış bazında izole eder

HTTP/3, taşıma katmanını UDP üzerine taşıyarak TCP'nin sıra kilidi sorununu doğrudan çözer. QUIC protokolü, her akışı bağımsız bir hata-telafi mekanizmasıyla donatır; bir akıştaki paket kaybı diğer akışları durdurmaz. Bu fark, kayıplı ağlarda —özellikle mobil bağlantılarda— somut bir gecikme avantajı üretir.

Büyük ölçekli CDN ağlarının yayımladığı gerçek kullanıcı verisi, yüksek paket kaybı ortamlarında HTTP/3'ün HTTP/2'ye kıyasla yüzde 10–30 aralığında daha düşük gecikme sağlayabildiğini göstermektedir. Ancak bu aralık son derece değişken bir yapıdadır; kazanım ağ koşuluna, coğrafi konuma ve içerik türüne göre dramatik biçimde farklılaşır. Güçlü fiber bağlantılarda iki protokol arasındaki fark çoğunlukla ölçüm gürültüsünün içinde kaybolur.

QUIC'in bağlantı göçü (connection migration) özelliği ayrıca değer taşır. Wi-Fi'dan mobil ağa geçiş gibi IP adresi değişikliklerinde QUIC, bağlantıyı kesmeksizin sürdürebilir. TCP tabanlı bağlantılar bu geçişte yeniden el sıkışmak zorunda kalır. Video akışı veya uzun süreli API oturumları için bu fark, kullanıcı deneyimini doğrudan etkileyen bir sonuç üretebilir.

0-RTT bağlantı kurulumu ve beraberindeki denge

HTTP/3'ün QUIC üzerindeki bir diğer avantajı, tekrar eden ziyaretçiler için bağlantı kurulum turunu sıfıra indirgeme kapasitesidir. Geleneksel TLS 1.3 el sıkışması 1-RTT gerektirir; yeni bir bağlantı açılmadan önce sunucu ile istemci arasında en az bir tam gidiş-dönüş yaşanmak zorundadır. 0-RTT ise önceki oturumdan saklanan anahtar bilgisiyle bu turu atlar ve ilk paketle birlikte veriyi göndermeye başlar. Yüksek gecikmeli bağlantılarda bu tur atlanması, ilk bayt süresini kayda değer biçimde kısaltabilir.

Ancak 0-RTT beraberinde bir güvenlik değiş tokuşu getirir: replay saldırısı riski. 0-RTT ile gönderilen veriler, ağdaki bir saldırgan tarafından yakalanıp tekrar sunucuya gönderilebilir. Bu nedenle 0-RTT yalnızca idempotent istekler —GET gibi yan etkisi olmayan sorgular— için kullanılması güvenlidir. POST, ödeme işlemi veya oturum değişikliği gibi durum değiştiren istekler 0-RTT ile gönderilmemelidir.

Sunucu tarafında 0-RTT'yi dikkatsizce etkinleştirmek hem güvenlik açığı hem de beklenmedik davranış üretebilir. Kazanımın anlamlı olduğu nokta, statik kaynak sunumu ve önbelleğe alınmış yanıtlardır. Dinamik içerik için yapılandırmanın dikkatli ele alınması, 0-RTT'nin getirdiği avantajdan gerçekten yararlanmanın ön koşuludur.

Sunucu yapılandırması protokol kazancının zeminidir

HTTP/2 desteği bugün çoğu web sunucusunda varsayılan olarak açık değildir. Nginx'te listen 443 ssl http2; direktifinin açıkça eklenmesi, Apache'de mod_http2 modülünün etkinleştirilmesi gerekir. Protokol müzakeresi ALPN (Application-Layer Protocol Negotiation) mekanizmasıyla TLS el sıkışması sırasında gerçekleşir. Bu el sıkışmanın kendisi TLS 1.3 üzerinden yapılmıyorsa, ek tur maliyeti multiplexing'den elde edilen kazanımın büyük bölümünü geri atar.

HTTP/3 için yapılandırma daha karmaşıktır. QUIC, UDP üzerinde çalıştığından güvenlik duvarı ve yük dengeleyici kuralları çoğunlukla UDP 443 portuna izin vermez. CDN olmadan HTTP/3 sunmak isteyen bir yapılandırmada bu portun açılması, Alt-Svc başlığının doğru tanımlanması ve QUIC için uygun bir kütüphanenin derlenmesi gerekir. Çoğu küçük ve orta ölçekli kurulum için HTTP/3 kazanımının en pratik yolu, bu desteği şeffaf biçimde sağlayan CDN hizmetlerinden yararlanmaktır.

Server push özelliği hakkında da bir not: HTTP/2 server push, teoride istemci istemeden kritik kaynakları önceden iletme kapasitesi sunar. Ancak gerçek dünya testleri, push'un önbellek uyumsuzluğu ve gereksiz veri transferi nedeniyle çoğu durumda zarar verdiğini ortaya koymuştur. Chrome 106 itibarıyla server push desteği tarayıcıdan kaldırılmıştır; bu özelliğe dayanan stratejiler artık geçerliliğini yitirmiştir.

TTFB ve LCP üzerindeki izi okumak

Protokol değişikliğinin etkisini somut biçimde görmek için Chrome DevTools'ta Network sekmesinde "Protocol" sütununu etkinleştirmek yeterlidir. Her kaynak için kullanılan protokol görünür hale gelir. "Connection ID" sütunu açıldığında, aynı ID altındaki kaynakların aynı TCP bağlantısını paylaştığı doğrulanabilir; bu da multiplexing'in gerçekten çalışıp çalışmadığını kontrol etmenin en hızlı yoludur.

LCP üzerindeki etkiyi değerlendirirken protokolün doğrudan bir katkı yapıp yapmadığına dikkat etmek gerekir. Büyük bir hero görseli veya LCP adayı tek bir büyük kaynak ise, multiplexing bu transferi hızlandırmaz; bant genişliği sabit kaldığından görsel aynı sürede indirilir. Ancak LCP öğesinin önünde render-blocking bir kaynak kuyruğu varsa ve bu kuyruğun çözülmesi multiplexing'den yararlanabiliyorsa, protokol değişikliği dolaylı olarak LCP süresini düşürebilir.

Sıkıştırma algoritmasını da bu tabloya dahil etmek gerekir. HTTP/2 veya HTTP/3'e geçişle birlikte Brotli sıkıştırması etkinleştirildiğinde transfer boyutu düşer ve protokol kazanımıyla birleşik bir iyileşme sağlanır. Tek başına protokol değişikliğinin etkisini izole etmek için iki test ortamında da aynı sıkıştırma ayarlarını kullanmak, ölçümü güvenilir kılan en önemli adımdır. WebPageTest'in bağlantı simülasyonu seçenekleriyle aynı sayfayı farklı ağ koşullarında ve farklı protokollerle test etmek, kazanımın hangi senaryoda anlamlı olduğunu net biçimde ortaya koyar.

HTTP/2 ve HTTP/3, belirli koşullar altında gerçek kazanım üretir. Bu koşulların başında çok sayıda küçük kaynak içeren sayfa yapısı, yüksek gecikmeli veya paket kaybına eğilimli ağ ortamı ve doğru yapılandırılmış TLS altyapısı gelir. Bu koşulların hiçbiri karşılanmadan yalnızca protokol yükseltmesi yapıldığında, ölçüm araçları beklenen iyileşmeyi göstermez çünkü gerçekte iyileşecek bir darboğaz mevcut değildir.

Modern CDN'lerin büyük çoğunluğu HTTP/3'ü zaten şeffaf biçimde etkin kılar; kullanıcılarınızın bir bölümü siz farkında olmadan QUIC üzerinden bağlanıyor olabilir. CDN kullanmayan yapılandırmalar için bu fayda ancak açık bir QUIC kurulumu ile elde edilebilir ve kurulum maliyeti kazanımla birlikte değerlendirilmelidir. Protokol optimizasyonu, zincirin en zayıf halkasını bulmakla başlar. TTFB yüksekse sunucu tarafında bir sorun vardır; protokol bunu gidermez. LCP geç yükleniyorsa büyük olasılıkla görsel boyutu, preload eksikliği veya başka bir darboğaz sorumludur. HTTP/2 ya da HTTP/3'e geçiş bu sorunların hiçbirini ortadan kaldırmaz; ancak doğru zemin hazırlandığında, özellikle kaynak sayısı fazla ve ağ koşulları değişken yapılar için, somut bir kazanım katmanı ekler.