HTTP/2 Nedir?

HTTP/1.1'in darboğazı: bağlantı başına tek istek

HTTP/1.1'de bir bağlantı aynı anda yalnızca bir isteğe cevap verebilir. Sıradaki istek, öncekinin yanıtı tamamen gelene kadar bekler. Pipelining bu sorunu çözmek için tanımlanmıştı ama tarayıcılarda pratikte hiç yaygınlaşmadı. Tarayıcılar da çareyi aynı sunucuya genellikle altı paralel bağlantı açmakta buldu. Onlarca CSS, JavaScript ve görsel dosyası olan bir sayfada bu sınır hızla doluyor, dosyalar sırada bekliyordu.

Geliştiriciler yıllarca bu kısıtın etrafından dolaşan teknikler kullandı: dosyaları tek pakette birleştirmek, ikonları sprite görsellerde toplamak, statik dosyaları farklı alt alan adlarına dağıtıp (domain sharding) daha fazla bağlantı açtırmak. HTTP/2 bu sorunu protokol seviyesinde ele aldı.

Çerçeveler, akışlar ve multiplexing

HTTP/2'de her istek-yanıt çifti bir akıştır (stream) ve her akış küçük ikili çerçevelere (frame) bölünür. Farklı akışların çerçeveleri aynı TCP bağlantısında iç içe geçerek gönderilebilir; karşı taraf çerçeve başlığındaki akış numarasına bakarak onları yeniden birleştirir. Böylece büyük bir JavaScript dosyası inerken küçük bir CSS dosyası arada kendi yolunu bulur ve tek bağlantı onlarca isteği aynı anda taşır.

Uygulama tarafında hiçbir şey değişmez. İstek ve yanıt mantığı, metotlar, durum kodları ve başlıklar aynıdır. Fark ağ trafiğini incelediğinizde görünür: istek satırı :method, :path, :authority gibi sözde başlıklara (pseudo-header) dönüşür ve başlık adları küçük harfle yazılır.

$ curl -sI --http2 https://example.com/
HTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: max-age=600
content-encoding: br

HPACK: aynı başlıkları tekrar tekrar göndermemek

Bir sayfa yüklenirken yapılan yüzlerce isteğin çoğu neredeyse aynı başlıkları taşır: user-agent, accept, uzun çerez değerleri. HTTP/1.1'de bunlar her istekte düz metin olarak baştan gönderilir. HTTP/2'nin başlık sıkıştırma biçimi HPACK (RFC 7541), sık kullanılan başlıklar için sabit bir tablo ve bağlantı boyunca güncellenen dinamik bir tablo tutar. Daha önce gönderilmiş bir başlık için yalnızca tablodaki sıra numarası iletilir. Bu, gövde sıkıştırmasından ayrı bir mekanizmadır; HTML, CSS ve JavaScript içeriğinin küçültülmesi hâlâ HTTP sıkıştırma (gzip, Brotli) ile yapılır.

Server push neden tarihe karıştı?

HTTP/2, sunucunun tarayıcı istemeden kaynak göndermesine izin veren server push özelliğiyle gelmişti. Teoride HTML ile birlikte kritik CSS'i de “itmek” bir gidiş-dönüş kazandıracaktı. Pratikte sunucu, tarayıcının önbelleğinde neyin zaten bulunduğunu bilemediği için çoğu zaman gereksiz veri gönderildi. Chrome bu özelliği Chrome 106'da varsayılan olarak kapattı; Firefox da 132. sürümde (Ekim 2024) aynı adımı attı. Bugün yerini, tarayıcıya hangi kaynağı erken isteyeceğini söyleyen preload ve 103 Early Hints aldı. Kararı sunucu değil tarayıcı verdiği için gereksiz indirme riski çok daha düşüktür.

HTTP/2'nin çözemediği sorun ve pratik notlar

• TCP seviyesinde tıkanma sürüyor. Tek bağlantıda kaybolan bir TCP paketi, yeniden gönderilene kadar o bağlantıdaki tüm akışları bekletir. Güncel spesifikasyon (RFC 9113) bunu açıkça kabul eder. Bu sorunu çözmek için HTTP/3 UDP tabanlı QUIC'e geçti.
• Tarayıcılarda yalnızca şifreli bağlantıda çalışır. Tarayıcılar HTTP/2'yi TLS üzerinde (h2) kullanır; protokol, TLS el sıkışması sırasında ALPN ile seçilir. Şifresiz h2c artık kullanımdan kaldırılmış sayılır.
• Eski hileler ters tepebilir. Domain sharding tek bağlantının avantajını böler. Dosya birleştirme ise artık zorunlu değil, yine de sıkıştırma ve önbellek açısından ölçülerek karar verilmeli.
• Önceliklendirme değişti. RFC 7540'taki öncelik ağacı RFC 9113'te kullanımdan kaldırıldı; yerini daha basit Extensible Priorities (RFC 9218) şeması aldı.

Sitenizin HTTP/2 kullanıp kullanmadığını Chrome DevTools'ta Network panelindeki Protocol sütununda h2 değerini görerek doğrulayabilirsiniz. SEO Analiz Aracı da TLS bağlantısında anlaşılan protokolü raporlar.