Ağ 10 Haziran 2026 · 7 dk okuma

HTTP/3 ve QUIC neden daha hızlı?

Tarayıcınız bir siteye bağlanırken artık çoğunlukla HTTP/3 kullanıyor; üstelik bunu fark bile etmiyorsunuz. İlginç olan şu: HTTP/3, bir önceki sürüme göre ne gönderildiğini değil, baytların nasıl taşındığını değiştirdi. Metotlar, başlıklar ve durum kodları aynı kaldı; altta TCP'nin yerini, UDP üzerine kurulu QUIC adında yeni bir taşıma aldı. Bu küçük gibi görünen değişiklik, özellikle mobil ve yüksek gecikmeli ağlarda hissedilir bir hız farkı yaratıyor. Gelin nedenini sade bir dille açalım.

Kısa cevap

HTTP/3 üç şeyi aynı anda iyileştirir: bağlantıyı daha az turda kurar, tek bir kayıp paketin tüm sayfayı bekletmesini önler ve ağ değiştiğinde (Wi-Fi'den mobile) bağlantıyı koparmaz. Bunların hepsi, TCP yerine QUIC kullanmasından gelir. Nasıl olduğunu görmek için kısaca geçmişe bakmak gerekiyor.

HTTP/1.1'in darboğazı: tek sıra, çok bağlantı

HTTP/1.1'de bir bağlantı üzerinden aynı anda yalnızca bir istek yürür; yanıt gelmeden sıradaki bekler. Tarayıcılar bunu aşmak için aynı sunucuya altı-sekiz paralel bağlantı açtı. Ama her bağlantı kendi TCP el sıkışmasını ve TLS pazarlığını ayrı ayrı ödemek zorundaydı — yani modern bir sayfanın onlarca kaynağı için bu maliyet katlanarak büyüdü.

HTTP/2: tek bağlantı, çoklama (multiplexing)

HTTP/2 bunu zarif biçimde çözdü: tek bir bağlantı üzerinde birçok isteği stream'lere bölerek paralel taşıdı (multiplexing) ve başlıkları sıkıştırdı. Sayfa başına onlarca bağlantıya gerek kalmadı. Ne var ki HTTP/2 hâlâ TCP üzerinde çalışıyordu — ve TCP'nin görünmez bir freni vardı.

TCP'nin görünmez freni: head-of-line blocking

TCP baytları sırayla teslim eder; arada bir paket kaybolursa, ondan sonra gelen her şey — başka stream'lere ait olsa bile — o paket yeniden gelene kadar bekler. HTTP/2 istekleri uygulama katmanında ayırmıştı ama altındaki TCP onları tek bir sıraya diziyordu. Sonuç: tek bir kayıp paket, paralel zannettiğiniz tüm indirmeleri aynı anda durdurabiliyordu. Buna head-of-line blocking denir ve özellikle paket kaybının yüksek olduğu mobil ağlarda canı yakar.

veri akmadan önce ödenen turlar

HTTP/2 — TCP + TLS 1.3          HTTP/3 — QUIC
─────────────────────          ─────────────
TCP SYN        ┐                QUIC Initial   ┐
TCP SYN-ACK    │ 1 RTT          + TLS 1.3       │ 1 RTT
TCP ACK        ┘                anahtar değişimi┘ # taşıma+şifre tek elde
TLS ClientHello┐
TLS sunucu     │ 1 RTT          tekrar bağlanışta: 0-RTT
TLS Finished   ┘
= 2 RTT veri öncesi            = 1 RTT veri öncesi

QUIC: UDP üzerinde yeni bir temel

HTTP/3'ün altındaki QUIC, TCP yerine UDP üzerine kuruludur ve TCP'nin onlarca yılda biriken kısıtlarını taşımak yerine sıfırdan tasarlanmıştır. Üç temel kazanımı var:

1. Bağımsız stream'ler — head-of-line blocking yok

QUIC, stream'leri taşıma katmanında da birbirinden bağımsız tutar. Bir stream'e ait paket kaybolursa yalnızca o stream bekler; diğerleri akmaya devam eder. HTTP/2'de TCP'nin dayattığı tek sıra burada ortadan kalkar.

2. Taşıma ve şifreleme tek el sıkışmada

QUIC, TLS 1.3'ü kendi içine gömer; bağlantı kurulumu ile şifreleme pazarlığı ayrı adımlar değil, tek bir adımdır. Böylece veri akmadan önce ödenen tur sayısı düşer: ilk bağlanışta tipik olarak 1-RTT, daha önce bağlanılmış bir sunucuya dönüşte ise 0-RTT mümkün olur — yani istek, ilk paketle birlikte yola çıkabilir.

3. Bağlantı taşıma (connection migration)

TCP bir bağlantıyı IP ve port çiftiyle tanımlar; ağınız değişince (Wi-Fi'den mobile geçiş gibi) bağlantı kopar ve baştan kurulur. QUIC ise bağlantıyı bir connection ID ile tanımlar, böylece IP değişse bile aynı bağlantı kaldığı yerden devam eder. Hareket hâlindeki cihazlarda bu, fark edilen kesintileri azaltır.

Yeni sürüm her koşulda daha hızlı demek değildir. HTTP/3'ün kazanımı en çok yüksek gecikmeli, paket kaybının olduğu ve çok kaynaklı sayfalarda belirginleşir. Düşük gecikmeli, kayıpsız bir bağlantıda tek küçük bir yanıt için fark ölçülemeyecek kadar küçük olabilir. Kazanç, isteğin koşullarına bağlıdır.

Pratikte ne zaman fark eder?

HTTP/3'ü açmak çoğu durumda kayıpsızdır ve düşürmez; ama nerede gerçekten kazandırdığını bilmek faydalı:

Mobil ve uzak kullanıcılar — yüksek gecikme ve paket kaybı olan ağlarda azalan tur sayısı ve head-of-line blocking'in kalkması net hissedilir.
Çok kaynaklı sayfalar — onlarca görsel, font ve script paralel akarken bağımsız stream'ler tıkanmayı azaltır.
Sık ağ değiştiren cihazlar — connection migration sayesinde Wi-Fi ile mobil arasında geçişte bağlantı kopmaz.

Kendi sitenizde nasıl açarsınız?

İyi haber: HTTP/3'e geçmek çoğunlukla kodunuzu değil, sunum katmanınızı ilgilendirir. Birkaç sade adım:

CDN ya da sunucuda etkinleştirin — çoğu CDN ve modern web sunucusu HTTP/3'ü tek bir ayarla sunar; uygulama kodunuzu değiştirmeniz gerekmez.
UDP'nin açık olduğundan emin olun — QUIC, 443/UDP üzerinde çalışır. Bazı kurumsal ağlar UDP'yi engeller; tarayıcı bu durumda sorunsuzca HTTP/2'ye düşer.
TLS'i zaten doğru kurun — HTTP/3, TLS 1.3'e dayanır; geçerli ve güncel bir sertifika ile şifreleme yapılandırması ön koşuldur.
Ölçün, varsaymayın — açmadan ve açtıktan sonra gerçek kullanıcı verisiyle (saha metrikleri) karşılaştırın; kazanç kitlenizin ağ koşullarına göre değişir.

Özetle

HTTP/3, HTTP'nin anlamını değil taşımasını yeniledi. TCP'nin tek sıraya dizen yapısını ve ayrı ayrı ödenen el sıkışmaları, UDP üzerine kurulu QUIC ile geride bıraktı: bağımsız stream'ler head-of-line blocking'i ortadan kaldırdı, taşıma ve şifreleme tek turda birleşti, connection migration ağ değişiminde bağlantıyı korudu. Bunların toplamı, özellikle mobil ve uzak kullanıcılarda daha hızlı açılan sayfalar demek.

Yine de sihirli bir düğme değil: kazanç, kullanıcılarınızın ağ koşullarına bağlı. Doğru yaklaşım, HTTP/3'ü açıp gerçek saha verisiyle ölçmek ve TLS gibi temelleri sağlam tutmak.

Konunun teknik temeline daha yakından bakmak isterseniz Bilgi Merkezi · Ağ Temelleri & Protokoller, Performans & Web Vitals ve TLS, SSL & Sertifika rehberlerine göz atabilirsiniz.

Sitenizin hızına birlikte bakalım Tüm yazılar