HTTP/1.1, HTTP/2 ve HTTP/3: Web neden hızlandı ve sitenizde hangisi açık?

Tarayıcınız bir web sayfasını açtığında yalnızca HTML'i değil; stil dosyalarını, script'leri, fontları ve görselleri de indirir. Ortalama bir sayfa bugün 50 ile 100 arasında ayrı istek yapıyor. Bu isteklerin sunucuya nasıl taşındığı, HTTP protokolünün sürümüne bağlıdır.

HTTP/1.1: Tek şerit, sıra bekleyen istekler

1997'den bu yana kullanılan HTTP/1.1'de bir bağlantı üzerinden aynı anda yalnızca bir istek gönderilebilir. İstek gider, cevap gelir, sonra sıradaki istek gider. Yavaş bir dosya, arkasındaki bütün dosyaları bekletir. Buna head-of-line blocking (sıra başı tıkanması) denir.

Tarayıcılar bu sorunu her alan adı için altı kadar paralel bağlantı açarak hafifletmeye çalıştı. Web geliştiriciler de bir dizi teknik geliştirdi:

• Dosya birleştirme: Bütün CSS'leri tek dosyada, bütün JavaScript'i tek dosyada toplamak.
• CSS sprite'ları: Onlarca küçük simgeyi tek bir büyük görselde birleştirmek.
• Alan adı bölme (domain sharding): Dosyaları static1.ornek.com, static2.ornek.com gibi farklı alan adlarından sunarak paralel bağlantı sayısını artırmak.

HTTP/2: Tek bağlantı, çok sayıda eşzamanlı akış

2015'te standartlaşan HTTP/2'nin en önemli yeniliği çoğullama (multiplexing) oldu. Tek bir TCP bağlantısı üzerinden onlarca istek ve cevap aynı anda, birbirini beklemeden taşınabiliyor. Bunlara ek olarak:

• Başlık sıkıştırma (HPACK): Her istekte tekrar eden çerez ve başlıklar sıkıştırılıyor.
• İkili (binary) protokol: Metin yerine ikili çerçeveler kullanıldığı için ayrıştırma daha hızlı ve daha az hataya açık.
• Öncelik bilgisi: Tarayıcı hangi dosyanın daha önemli olduğunu sunucuya bildirebiliyor.

HTTP/2 pratikte yalnızca HTTPS üzerinden kullanılıyor. Tarayıcıların hiçbiri şifresiz HTTP/2'yi desteklemiyor.

Eski teknikler artık zararlı olabilir

HTTP/2 ile birlikte yukarıdaki optimizasyonların bir kısmı gereksiz, hatta zararlı hâle geldi:

• Alan adı bölme artık hız kazandırmıyor; tersine her alan adı için ayrı DNS sorgusu ve TLS el sıkışması gerektirdiği için yavaşlatıyor.
• Her şeyi tek dosyada birleştirmek, tek bir satır değiştiğinde bütün dosyanın önbellekten düşmesine yol açıyor. Mantıklı büyüklükte birkaç dosyaya bölmek önbellek açısından daha verimli.

HTTP/3: TCP yerine QUIC

HTTP/2 uygulama seviyesindeki tıkanmayı çözdü, ama altta yatan TCP'nin kendi tıkanma sorunu sürüyordu. TCP'de tek bir paket kaybolduğunda, o bağlantıdaki bütün akışlar kayıp paket yeniden gönderilene kadar bekler. Kayıplı mobil ağlarda bu ciddi bir sorundur.

2022'de standartlaşan HTTP/3, TCP yerine UDP üzerine kurulu QUIC protokolünü kullanır:

• Akışlar birbirinden bağımsız: Bir akıştaki paket kaybı diğerlerini etkilemez.
• Daha hızlı bağlantı kurulumu: TLS 1.3 el sıkışması QUIC'in içine gömülü. Yeni bir bağlantı genellikle tek bir gidiş-dönüşte kurulur. Daha önce bağlanılmış bir sunucuya, belirli koşullarda, sıfır gidiş-dönüşle (0-RTT) veri gönderilebilir.
• Bağlantı taşıma: Telefonunuz Wi-Fi'den mobil veriye geçtiğinde IP adresiniz değişir. TCP'de bu, bağlantının kopması demektir. QUIC ise bağlantıyı bir kimlikle tanımladığı için kesintisiz devam edebilir.

HTTP/3'ün faydası en çok yüksek gecikmeli ve kayıplı ağlarda, yani mobil bağlantılarda hissedilir. Hızlı ve kararlı bir fiber bağlantıda fark daha küçüktür.

Sitenizde hangisi açık?

curl -sI --http2 https://ornek.com | head -1

Çıktı HTTP/2 200 ise HTTP/2 açık. HTTP/3 desteğini görmek için cevap başlıklarında alt-svc satırına bakın:

curl -sI https://ornek.com | grep -i alt-svc

alt-svc: h3=":443"; ma=86400

Bu satır, tarayıcıya "Bu sunucuya HTTP/3 ile de bağlanabilirsin" der. Tarayıcının geliştirici araçlarında, Ağ (Network) sekmesine "Protocol" sütununu ekleyerek her dosyanın hangi protokolle geldiğini de görebilirsiniz: http/1.1, h2 ya da h3.

Nasıl açılır?

Nginx: HTTP/2 için listen satırında ya da http2 on; yönergesiyle açılır. Güncel Nginx sürümleri HTTP/3'ü de destekler (listen 443 quic;). Bunun için güvenlik duvarında UDP 443 portunun da açılması gerekir.

Apache: mod_http2 modülü ve Protocols h2 http/1.1 satırıyla açılır. Apache'nin prefork MPM'i HTTP/2 ile verimli çalışmaz; event MPM kullanın. Apache'nin kendisi HTTP/3'ü yerleşik olarak sunmaz. HTTP/3 için genellikle önüne bir CDN ya da Nginx, Caddy, LiteSpeed gibi HTTP/3 destekleyen bir sunucu konur.

CDN: Cloudflare gibi CDN'lerin çoğu HTTP/2 ve HTTP/3'ü sizin sunucunuzda hiçbir ayar gerektirmeden, ziyaretçi tarafında sunar.

Sonuç

Sitenizde en az HTTP/2'nin açık olduğundan emin olun; bugün bunun için hiçbir mazeret kalmadı. HTTP/3 ise özellikle mobil ziyaretçisi yoğun siteler için değerli bir ek kazanç. Ama unutmayın: Hiçbir protokol, 5 MB'lık bir kapak görselini ya da yirmi farklı izleme script'ini telafi edemez. Protokol yolu genişletir; yükü azaltmak yine sizin işiniz.