HTTP/2 ve HTTP/3 Arasındaki Farklar

Sesli Dinle — Makale

Web istemcileri ile sunucular arasında istek ve yanıtları taşıyan HTTP protokolünün HTTP/2 ve HTTP/3 sürümleri aynı istek yöntemlerini, durum kodlarını, önbellek kurallarını ve URL’leri kullanır. Temel fark, bu istek ve yanıtların ağda nasıl taşındığıdır.

HTTP/2, TCP üzerinde çalışır. HTTP/3 ise UDP üzerinde çalışan QUIC taşıma protokolünü kullanır. QUIC; güvenilir teslimi, akış kontrolünü, kayıp kurtarmayı ve tıkanıklık kontrolünü UDP’nin üzerinde kendi içinde sağlar.

Taşıma protokolünün değişmesi, bağlantı kurulumunu ve aynı bağlantıda birden fazla isteğin eş zamanlı taşınmasını, yani multiplexing’i etkiler. Paket kaybının diğer isteklere etkisi ve ağ değişiminde bağlantının sürdürülmesi de farklılaşır. HTTP/3, TLS handshake işlemini QUIC bağlantı kurulumuna bütünleştirir. HTTP’nin TLS ile korunan biçimi HTTPS olarak adlandırılır. Yine de hiçbir protokol sürümü tek başına hız garantisi değildir; sonuç istemci, sunucu, ağ yolu, içerik ve yapılandırmayla birlikte ölçülmelidir.

HTTP/2 ve HTTP/3 Karşılaştırması

Aşağıdaki tablo, iki sürümü taşıma protokolünden dağıtım gereksinimlerine kadar aynı başlıklar üzerinden karşılaştırır. Gerçek sonuçlar istemciye, sunucuya, ağ yoluna ve yapılandırmaya bağlıdır.

HTTP/2 ve HTTP/3 Bağlantılarının Kurulumu

Bir web isteğinin gecikmesi yalnız dosyanın büyüklüğünden kaynaklanmaz. İstemci ile sunucunun bağlantı kurmak, şifreleme anahtarlarını belirlemek ve kullanılacak uygulama protokolünü seçmek için yaptığı görüşmeler de ilk veri aktarımından önce süre tüketir.

HTTP/2'de TCP ve TLS Aşamaları

HTTP/2, bağlantı yönelimli ve sıralı teslim sağlayan TCP üzerinde çalışır. HTTPS bağlantısında istemci önce TCP bağlantısını kurar. Ardından TLS el sıkışmasındaki ALPN görüşmesinde istemci desteklediği protokolleri bildirir; sunucu da ortak desteklenen seçenekler arasından h2 protokolünü seçebilir. İstek ve yanıtların bölündüğü HTTP/2 çerçeveleri aynı TCP bağlantısı üzerinden taşınır.

TCP'nin yaygınlığı önemli bir dağıtım avantajıdır. Güvenlik duvarları, NAT cihazları, istemci adına bağlantı kuran kurumsal proxy sunucuları ve yük dengeleyiciler TCP trafiğini uzun süredir işlediği için HTTP/2 çoğu ağda ek bir taşıma protokolü açılmadan çalışabilir.

HTTP/3'te QUIC ve TLS Birlikte Çalışır

HTTP/3, HTTP verisini QUIC akışları üzerinde taşır. QUIC paketleri UDP datagramları içinde gönderilir; ancak bu durum HTTP/3'ün güvenilir olmayan bir aktarım kullandığı anlamına gelmez. QUIC, kayıp algılama, yeniden iletim, sıralı akış teslimi, akış kontrolü ve tıkanıklık kontrolü gibi işlevleri kendi taşıma katmanında uygular.

QUIC, taşıma parametreleriyle TLS 1.3 el sıkışmasını aynı bağlantı kurulumunda birleştirir. Böylece TLS görüşmesinden önce ayrı bir TCP bağlantısı kurmak gerekmez. Önceki oturumun bilgileri yeniden kullanılabiliyorsa bağlantı kurma gecikmesi daha da azalabilir.

Ağ Değiştiğinde HTTP Bağlantısına Ne Olur?

QUIC, bağlantıyı IP adresi ve porttan bağımsız bağlantı kimlikleriyle izleyebilir. İstemci mobil veri ile Wi-Fi arasında geçtiğinde uygulama ve ağ koşulları izin verirse mevcut bağlantı yeni ağ üzerinden sürdürülebilir. Uç noktalar yeni yolun kullanılabilirliğini doğrular; bu sırada henüz doğrulanmamış adrese gönderilen veri için güvenlik kısıtları uygulanır.

Standart TCP bağlantısı ise iki ucun IP adresi ve portuyla tanımlanır. Mobil veri ile Wi-Fi arasında geçerken bu değerler değişirse HTTP/2 için genellikle yeni bir TCP bağlantısı gerekir. Yalnız paketlerin geçtiği rotanın değişmesi, IP adresleri ve portlar aynı kaldığı sürece bağlantıyı yeniden kurmayı gerektirmez.

0-RTT Erken Veri Ne Zaman Güvenlidir?

Daha önce kurulmuş bir QUIC bağlantısından geçerli oturum bilgisi kalan istemci, 0-RTT erken veri göndermeyi deneyebilir. Buradaki RTT (Round-Trip Time), bir iletinin karşıya gidip yanıtının dönmesi için geçen süredir. 0-RTT, yeni el sıkışmanın yanıtını beklemeden veri göndermeyi anlatır. İstemci bu yolla tam el sıkışma tamamlanmadan HTTP isteği iletebilir; ancak sunucu erken veriyi kabul etmek zorunda değildir. Sunucu isteği erken veri olarak kabul etmezse istemci normal bağlantı kurulduktan sonra yeniden gönderebilir.

0-RTT verisi yeniden oynatma saldırılarına karşı el sıkışma sonrasında gönderilen normal veriyle aynı güvenceyi vermez. Sunucu, yinelenmesi güvenli olmayan para transferi, sipariş oluşturma veya tek kullanımlık işlem gibi istekleri erken veride kabul etmemelidir. Yalnız güvenle tekrarlanabilen istekler için açık uygulama politikası oluşturulmalı; 0-RTT, her sayfayı otomatik hızlandıran genel bir özellik olarak görülmemelidir. Erken veri yalnız HTTP/3’e özgü değildir; TLS 1.3 üzerinden çalışan HTTP/2 de uygun istemci ve sunucu desteğiyle 0-RTT kullanabilir.

Akış Çoklama ve Paket Kaybı Davranışı

Modern bir web sayfası, yapısını tanımlayan HTML belgesinin yanında stil dosyaları, betikler, yazı tipleri ve medya kaynakları ister. HTTP/2 ve HTTP/3 bu istekleri tek bağlantı içinde ayrı akışlara yerleştirerek birden fazla aktarımın eş zamanlı ilerlemesini sağlar; ayrım, alttaki taşıma protokolünün bu akışları nasıl gördüğünde ortaya çıkar.

HTTP/2'de Tek TCP Bayt Akışının Etkisi

HTTP/2, istek ve yanıtları ikili çerçevelere böler ve farklı akışlara ait çerçeveleri aynı bağlantıda iç içe taşıyabilir. Uygulama düzeyinde yavaşlayan bir HTTP/2 akışı diğer akışların çerçevelerini doğrudan engellemez.

Buna karşılık TCP, bütün bağlantıyı tek ve sıralı bir bayt akışı olarak teslim eder. Bir TCP paketi kaybolduğunda sonraki baytlar alınmış olsa bile eksik bölüm yeniden gelene kadar uygulamaya sıralı teslim yapılamaz. Bu taşıma katmanı beklemesi, kayıp paketle doğrudan ilgisi olmayan HTTP/2 akışlarını da geçici olarak durdurabilir.

HTTP/3'te Akışların Taşıma Katmanında Ayrılması

QUIC, bir bağlantı içinde birden fazla bağımsız ve sıralı akış sağlar. Bir QUIC paketi kaybolduğunda o pakette verisi bulunan akışların sıralı teslimi yeniden iletimi bekleyebilir. Diğer akışlar, kendi verileri eksiksizse ve başka bir bağımlılık yoksa ilerleyebilir; TCP’deki gibi bütün bağlantıyı kapsayan tek bir bayt sırasını beklemek zorunda değildir.

Bu ayrım paket kaybını etkisiz hale getirmez. QUIC akışları aynı bağlantının tıkanıklık kontrolünü ve ağ kapasitesini paylaşır; yoğun kayıp genel gönderim hızını azaltabilir. Bağlantı düzeyindeki akış kontrolü ve aşağıda açıklanan QPACK başlık bağımlılıkları da birden fazla isteği bekletebilir. HTTP/3'ün avantajı, her kaybın bütün akışları zorunlu olarak aynı sırada bekletmemesidir.

HPACK ve QPACK Başlık Sıkıştırması

HTTP istek ve yanıt alanları çok sayıda tekrar eden ad ve değer içerir. HTTP/2 bunları HPACK ile, HTTP/3 ise QUIC’in bağımsız akış yapısına uyarlanmış QPACK ile sıkıştırır. Tekrar kullanılan başlık adları ve değerleri dinamik tabloda saklanabilir; her seferinde tam metin yerine bu girdilere başvurulur. QPACK’in kodlayıcı akışı tablo güncellemelerini, kod çözücü akışı ise bunlarla ilgili onay ve bildirimleri istek akışlarından ayrı taşır.

Bu tasarım başlık sıkıştırmasından doğabilecek bağlantı genelindeki sıra başı beklemesini azaltır; ancak tamamen ortadan kaldırmaz. Bir başlık bloğu henüz ulaşmamış bir dinamik tablo girdisine başvuruyorsa ilgili akış bekleyebilir. Uygulama verisinin QUIC akışlarında bağımsız ilerlemesi ile QPACK bağımlılıkları ayrı değerlendirilmelidir.

HTTP/2 ve HTTP/3'te TLS Kullanımı

Herkese açık web hizmetlerinde HTTP/2 çoğunlukla TLS üzerinden kullanılır ve h2 protokolü TLS el sıkışmasındaki ALPN seçimiyle belirlenir. HTTP/2, açık metinli bağlantılarda sunucu desteği önceden biliniyorsa teknik olarak kurulabilir. Ancak yaygınlaşmayan eski HTTP/1.1 yükseltme mekanizması güncel HTTP/2 standardında artık tanımlanmaz.

HTTP/3'te şifreleme sonradan eklenen ayrı bir katman değildir. QUIC sürüm 1, TLS 1.3 el sıkışmasını taşıma protokolüne dahil eder; HTTP/3 verisinin gizliliği, bütünlüğü ve sunucu kimliğinin doğrulanması bu yapı üzerinden sağlanır. Alan adı için güvenilir sertifika doğrulaması yine gerekir ve HTTP/3 kullanmak için ayrı bir sertifika türü satın alınmaz.

QUIC'in daha fazla taşıma bilgisini şifrelemesi, ara cihazların trafiği TCP kadar ayrıntılı incelemesini zorlaştırabilir. Bu yapı gizliliği güçlendirir ve ara cihazların protokolü değiştirmesini zorlaştırır; buna karşılık kurumsal görünürlük, hata ayıklama ve güvenlik izleme araçlarının QUIC'i desteklemesini gerektirebilir. HTTP/3, hatalı sertifika yönetimini, güvensiz uygulama kodunu veya yanlış erişim kontrolünü kendiliğinden düzeltmez.

HTTP/3 İçin Sunucu ve Ağ Gereksinimleri

HTTP/2 dağıtımında web sunucusu, sunucu adına ziyaretçi bağlantılarını karşılayan ters proxy veya CDN’in h2 desteği ve doğru TLS yapılandırması genellikle yeterlidir. HTTP/3 dağıtımında ise ziyaretçi bağlantısını karşılayan uç noktanın QUIC bağlantılarını kabul etmesi, UDP trafiğine izin vermesi ve yük dengeleme ile güvenlik katmanlarının bu bağlantıları doğru işlemesi gerekir.

Bir CDN veya uç proxy HTTP/3 bağlantısını kullanıcı tarafında sonlandırıp kaynak sunucuya HTTP/2 ile bağlanabilir. Bu nedenle kaynak sunucunun QUIC desteklememesi, sitenin uçta HTTP/3 sunamayacağı anlamına gelmez. Buna karşılık HTTP/3'ün kullandığı UDP portu (çoğunlukla 443) güvenlik duvarında kapalıysa, NAT zaman aşımı çok kısaysa veya ağ işletmecisi QUIC trafiğini sınırlıyorsa bağlantı kurulamayabilir.

Site yöneticisi, HTTP/3 kullanıma açılırken erişim kayıtlarından bağlantı hatalarını ve TCP’ye geri dönüş oranını izleyebilmelidir. İstek hızını sınırlayan kuralların, DDoS önlemlerinin ve izleme araçlarının QUIC trafiğini de kapsaması gerekir.

HTTP/3 Keşfi ve TCP’ye Geri Dönüş

Bir web hizmeti, HTTP/3 uç noktasını Alt-Svc yanıt alanıyla veya DNS’teki HTTPS kaynak kaydıyla duyurabilir. Bu duyuru tek başına bağlantının kurulabileceğini kanıtlamaz. İstemcinin hedef UDP portuna ulaşması, sunucu sertifikasını web adresindeki asıl sitenin alan adı için doğrulaması ve TLS içindeki ALPN görüşmesinde h3 seçilmesi gerekir.

UDP engellenirse veya QUIC el sıkışması tamamlanamazsa istemcinin TCP tabanlı HTTP/2 ya da HTTP/1.1 ile yeniden bağlanabilmesi gerekir. Bu nedenle HTTP/3 etkinleştirildiğinde TCP tabanlı HTTP desteği de açık tutulmalıdır. Site yöneticisi Alt-Svc hedefini ve geçerlilik süresini hizmetin durumuna göre güncellemelidir; kapatılan uç nokta istemcilere duyurulmaya devam etmemelidir.

Gerçekte hangi protokolün kullanıldığını tarayıcının geliştirici araçlarındaki Ağ bölümünden kontrol edebilirsiniz. Farklı internet servis sağlayıcısı ağlarından ve mobil bağlantılardan alınan sonuçları da karşılaştırmak gerekir.

HTTP/3 Performansı Neden Her Sitede Aynı Değildir?

HTTP/3'ün en belirgin olası kazancı yüksek gecikme, değişken mobil bağlantı, paket kaybı ve ağ değişimi gibi TCP bağlantısını daha fazla zorlayan koşullarda ortaya çıkar. Bağımsız akışlar, kayıp nedeniyle ilgisiz isteklerin beklemesini azaltabilir; QUIC ile TLS bağlantı kurulumunun birlikte yürütülmesi de yeni bağlantıdaki bekleme süresini kısaltabilir.

Düşük gecikmeli ve kayıpsız bir ağda, iyi önbelleklenmiş bir sayfa mevcut HTTP/2 bağlantısı üzerinden sunuluyorsa fark küçük kalabilir. HTTP/3 uç noktasının ilk ziyarette geç keşfedilmesi, UDP denemesinin başarısız olup TCP'ye dönülmesi, sunucunun QUIC'i verimsiz işlemesi, yüksek işlemci yükü veya yanlış tıkanıklık kontrolü seçimi beklenen kazancı azaltabilir.

Sayfanın toplam boyutu, sıkıştırma, önbellekleme, sunucu yanıt süresi, CDN konumu ve kritik kaynakların sırası çoğu zaman protokol sürümünden daha büyük etki yaratır. Bu nedenle HTTP/3'ü etkinleştirmek, gereksiz betikleri azaltma veya yavaş uygulama sorgularını düzeltme gibi temel performans çalışmalarının yerine geçmez.

Karşılaştırmada HTTP/2 ve HTTP/3 için ilk yanıt süresini, kaynakların aktarım süresini, sayfanın yüklenme süresini ve sunucunun işlemci yükünü aynı içerik ve benzer ağ koşullarında ölçmek gerekir.