HTTP/3 ve QUIC Nedir?

Sorun HTTP'de değil, TCP'deydi

HTTP/2 onlarca isteği tek bir TCP bağlantısında paralel taşıyarak büyük bir adım attı. Ancak TCP, kendisine verilen baytları tek bir sıralı akış olarak görür. Bir paket kaybolduğunda, o paketten sonraki her şey (başka bir dosyaya ait olsa bile) yeniden gönderim tamamlanana kadar uygulamaya teslim edilmez. RFC 9114 bunu şöyle özetler: kaybolan ya da sırası karışan tek bir paket, bağlantıdaki tüm aktif işlemleri durdurur. Mobil ağlarda ve paket kaybının yüksek olduğu bağlantılarda bu tıkanma (head-of-line blocking) hissedilir bir gecikme yaratır.

İkinci maliyet bağlantı kurulumudur. TCP el sıkışmasının ardından ayrı bir TLS el sıkışması gelir; yüksek gecikmeli bir bağlantıda bu turlar ilk baytı belirgin şekilde geciktirir.

QUIC ne getiriyor?

QUIC, TCP'nin üstlendiği işleri (güvenilir teslim, akış kontrolü, tıkanıklık kontrolü) UDP üzerinde yeniden tanımlayan bir taşıma protokolüdür. UDP'nin seçilmesinin nedeni, ağdaki cihazların zaten tanıdığı bir taşıyıcı kullanarak yaygınlaşmayı kolaylaştırmaktır. Öne çıkan özellikleri:

• Akış bazında güvenilirlik: Her akış kendi sırasını tutar; bir akıştaki kayıp diğerlerini bekletmez.
• Yerleşik şifreleme: TLS 1.3, QUIC el sıkışmasının parçasıdır (RFC 9001). Şifresiz QUIC yoktur, taşıma ve şifreleme anlaşması tek turda tamamlanır.
• Bağlantı taşıma: Bağlantılar IP adresi yerine bağlantı kimlikleriyle (connection ID) tanınır. Kullanıcı Wi-Fi'dan mobil veriye geçtiğinde bağlantı sıfırdan kurulmak zorunda kalmaz.

HTTP/3 ise HTTP'nin anlamını değiştirmeden QUIC'e taşır. HTTP/2'deki HPACK'in yerini, sıralı teslim varsayımına dayanmayan QPACK (RFC 9204) alır.

0-RTT: hız ile tekrar riski arasında

Daha önce bağlandığı bir sunucuya dönen istemci, oturum devam ettirme sayesinde ilk paketiyle birlikte uygulama verisi de gönderebilir; buna 0-RTT denir. Kazanç gerçektir ama bedeli de vardır: RFC 9000'in ifadesiyle 0-RTT verisi tekrar saldırılarına (replay) karşı koruma sağlamaz. Ağdaki biri aynı paketi yeniden gönderirse sunucu isteği iki kez işleyebilir. Bu yüzden sunucular erken veriyi genellikle yalnızca GET gibi güvenli ve idempotent isteklerde kabul eder. Riskli bir isteği erken veriyle almak istemeyen sunucu, RFC 8470'te tanımlanan 425 Too Early yanıtıyla istemciden isteği el sıkışma bitince tekrarlamasını ister.

Tarayıcı HTTP/3'ü nasıl fark eder?

Tarayıcı bir siteye ilk kez bağlanırken sunucunun QUIC desteklediğini bilemez, bu yüzden ilk ziyaret genellikle TCP üzerinden HTTP/2 ile yapılır. Sunucu yanıtına eklediği Alt-Svc başlığıyla alternatif uç noktayı duyurur:

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

Bu satır “aynı içeriği 443 numaralı UDP portunda HTTP/3 ile de sunuyorum, bu bilgiyi 24 saat hatırla” anlamına gelir. Sonraki isteklerde tarayıcı QUIC'i dener. DNS'teki HTTPS kayıtları (RFC 9460) da bu bilgiyi daha ilk bağlantıdan önce verebilir. Kurumsal ağlar gibi UDP'nin engellendiği ortamlarda tarayıcı sessizce HTTP/2'ye geri döner; bu yüzden HTTP/3 açmak hiçbir kullanıcıyı dışarıda bırakmaz.

Ne zaman fark yaratır, nasıl kontrol edilir?

Chrome, Edge, Firefox ve Safari'nin güncel sürümleri HTTP/3'ü destekler. Kazanç en çok paket kaybı ve gecikmenin yüksek olduğu mobil bağlantılarda görülür; hızlı kablolu bir bağlantıda HTTP/2 ile arasındaki fark çoğu zaman küçüktür. Pek çok site HTTP/3'e kendi sunucusunu değiştirmeden, bir CDN üzerinden geçer. Kendi sunucunuzda açacaksanız güvenlik duvarında UDP 443'ün açık olması gerektiğini unutmayın.

• Chrome DevTools'ta Network panelinin Protocol sütununda h3 görünür (çoğu zaman ilk istekte değil, sonraki isteklerde).
• HTTP/3 desteğiyle derlenmiş bir curl sürümünde curl -I --http3 https://alanadi.com/ komutu çalışır.
• SEO Analiz Aracı, sunucunun döndürdüğü alt-svc başlığını yanıt başlıkları arasında gösterir.

Protokolün ayrıntıları RFC 9114'te yer alır. Spesifikasyon server push'u hâlâ tanımlar, ancak tarayıcılar bu özelliği HTTP/3'te de kullanmaz.