QUIC Protokolü
QUIC, Google'ın web'i daha hızlı hale getirmek için oluşturduğu, ardından IETF'ye devredilen ve ardından HTTP/3 adı altında İnternet'in yarısına yayılan aktarım protokolüdür. TCP yerine UDP üzerinde çalışır, ilk paketteki şifrelemeyi entegre eder ve tek bir tasarımda onlarca yıldır TCP döneminde yaşanan sıkıntıları ortadan kaldırır.
Makalenin tam metni aşağıda İngilizce olarak verilmektedir.
QUIC (başlangıçta "Hızlı UDP İnternet Bağlantıları"), 2012 civarında Google tarafından tasarlanan ve 2021'de IETF tarafından RFC 9000 olarak standartlaştırılan genel amaçlı bir aktarım protokolüdür. UDP üzerinde çalışır, veri akışlarını taşır, kendi şifrelemesini ve tıkanıklık kontrolünü yönetir ve HTTP/3'ün temeli olarak hizmet eder. 2025'in sonları itibarıyla QUIC, büyük ağlarda hacim olarak İnternet trafiğinin %30'undan fazlasını taşıyor.
TCP neden yeterli değildi
TCP 1981'de tasarlandı ve o zamandan beri özünde değişmedi. Üç sorun giderek acı verici hale geldi:
- Hat başı engelleme. Düşen tek bir paket, kayıp paket bir akışa ait olsa ve diğer akışlar iyi olsa bile, aynı TCP bağlantısındaki tüm verileri arkasında durdurur. HTTP/2, tek bir TCP bağlantısı üzerinden birçok akışı çoğulladı, bu da hat başı engellemeyi daha iyi değil daha da kötü hale getirdi.
- Yavaş el sıkışma. TCP'nin herhangi bir veri akışından önce 1,5 gidiş dönüşe ihtiyacı vardır; üstüne TLS eklemek onu 2,5'tan fazla gidiş-dönüş yapar. Mobil bağlantılarda bu gecikme kullanıcılar tarafından görüldü.
- Bağlantı geçişi. TCP bağlantıları, 5'li grup (kaynak IP, kaynak bağlantı noktası, hedef IP, hedef bağlantı noktası, protokol) tarafından tanımlanır. Telefonunuz Wi-Fi'den hücresel bağlantıya geçtiğinde IP değişir ve her TCP bağlantısı kesilir.
QUIC, üçünü de düzeltmek için tasarlanmıştır.
Hat başı engellemesi olmayan akışlar
QUIC, tek bir bağlantı içinde birden fazla bağımsız akış taşır. Her akışın kendi düzeni ve güvenilirliği vardır. Bir paket kaybolursa yalnızca etkilenen akış durur; diğer akışlar devam eder. Bu, başlık özelliğidir ve kayıplı bağlantılarda HTTP/3'ü HTTP/2'den fark edilir derecede daha hızlı hale getiren özelliktir.
'te oluşturulan şifreleme
İlk el sıkışmadan sonraki her QUIC paketi, aktarım düzeyi başlıkları da dahil olmak üzere TLS 1.3 anahtarlarıyla şifrelenir. TCP, sıra numaralarını ve bayrakları orta kutulara gösterdiğinde, QUIC bunları şifreler. El sıkışma bir gidiş-dönüşte tamamlanır veya istemci oturum durumunu önbelleğe almışsa sıfırlanır (0-RTT, yeniden yürütme koruması için uyarılarla).
Bunun önemli bir yan etkisi vardır: DPI sistemleri, şeffaf proxy'ler ve kurumsal güvenlik duvarları dahil olmak üzere orta kutular artık QUIC trafiğini TCP'de yaptıkları gibi değiştiremez. 'in QUIC trafiğinin aktığını görebilirler ancak kodunu çözemezler. Ağ operatörleri için bu durum yıkıcı oldu; son kullanıcılar için bu açık bir gizlilik kazancıdır.
Bağlantı geçişi
HIZLI bağlantı, ağ 5'li tuple tarafından değil, her pakete katıştırılmış 64 bit Bağlantı Kimliği ile tanımlanır. IP'niz değiştiğinde (telefon hücreler arasında hareket ederken, dizüstü bilgisayar ağlar arasında geçiş yaparken, NAT yeniden bağlanırken) QUIC bağlantısı sorunsuz bir şekilde devam eder. Kitaplık, küçük bir doğrulama el sıkışmasını tamamlayarak sunucuya yeni IP/bağlantı noktasının hala aynı istemci olduğunu kanıtlar ve trafik devam eder.
Banliyö trenleri ve uçak Wi-Fi'sindeki mobil kullanıcılar için bu, "bir köşeyi döndüğüm için video çağrım kesildi" hatalarının tamamını ortadan kaldırır.
Tıkışıklık kontrolü
QUIC uygulamaları kendi tıkanıklık kontrolünü gönderir — tipik olarak Reno, Kübik veya BBR. QUIC bir kullanıcı alanı protokolü olduğundan (TCP gibi işletim sistemi çekirdeğinde değil), tıkanıklık kontrolü iyileştirmeleri işletim sistemi yükseltmeleri yerine uygulama güncellemeleri olarak dağıtılır. Google bunu, BBRv2'yi Chrome+QUIC bağlantılarında aynı algoritmanın işletim sistemi yükseltmeleri yoluyla dağıtılabileceğinden daha hızlı bir şekilde sunmak için kullandı.
QUIC'nin kullanıldığı ve kullanılmadığı yerlerde
QUIC, HTTP/3 özellikli hedefler için tarayıcıdan sunucuya trafiğe hakimdir: Google, Meta, Cloudflare, Fastly, Akamai. QUIC başarısız olursa tarayıcılar TCP üzerinden HTTP/2'ye geri döner (bazı ağlar UDP/443'ü engeller, bazı güvenlik duvarları bilinmeyen UDP'yi bırakır ve TCP için ayarlanmış ağlarda QUIC paket kaybı son derece yüksek olabilir).
HTTP'nin ötesinde QUIC, Google'ın RPC trafiğini, Apple'ın iCloud'unun bazı kısımlarını, bazı kullanıcılar için QUIC üzerinden gRPC'yi ve giderek daha fazla QUIC üzerinden DNS'yi taşır. QUIC, tarayıcının QUIC üzerinden çift yönlü akış yapması için düşük seviyeli bir API olan WebTransport'un temelini oluşturur. Uzun vadede, daha fazla uygulama protokolünün QUIC'e taşınmasını bekliyoruz.
Operasyonel uyarılar
QUIC, ağ işlemlerini karmaşık hale getirir:
- DPI tabanlı trafik şekillendirme aynı şekilde çalışmaz. DPI aracılığıyla YouTube'a hız sınırı koyan İSS'ler, QUIC trafiğinin opak olduğunu tespit eder.
- NAT zaman aşımı davranışı farklıdır — UDP NAT'lar genellikle TCP'nin dakikalarına kıyasla 30 saniyelik zaman aşımlarına sahiptir, bu nedenle QUIC canlı tutmaları daha agresif bir şekilde gönderir.
- Bazı güvenlik duvarları QUIC'yi doğrudan bırakır; müşterilerin bunu tespit etmesi ve geri çekilmesi gerekir. Geri dönüş gecikmesi sınırlıdır ancak görünürdür.
- QUIC hata ayıklama, tcpdump'tan farklı araçlar gerektirir;
qlogçıkışı ve TLS anahtarlarına sahip Wireshark modern kurulumdur.
Sık sorulan sorular
- QUIC TCP'den daha mı hızlı?
- Gerçek iş yükleri için genellikle evet; mobil ve kayıplı ağlarda genellikle %10-30 daha hızlı, temiz kablolu bağlantılardan daha az fayda. Bu gelişme, hat başı engellemesi olmadan çoğullama, daha hızlı el sıkışmalar ve bağlantı geçişinden kaynaklanmaktadır. Kayıpsız mükemmel bir ağda boşluk küçülür.
- QUIC trafiği şifreliyor mu?
- Evet, zorunlu ve uçtan uca. El sıkışmadan sonraki her QUIC paketi TLS 1.3 anahtarlarıyla şifrelenir. "Düz QUIC" modu yoktur. Ağ gözlemcileri QUIC'in bağlantı kimliğiyle şifrelenmiş UDP'yi görür; içerideki akışları okuyamazlar.
- QUIC neden kendi IP protokolü yerine UDP üzerinde çalışıyor?
- Konuşlandırılabilirlik. Yeni bir IP protokolü, İnternet'teki her NAT, güvenlik duvarı ve ISP yönlendiricisinin güncellenmesini gerektirecektir; bu onlarca yıllık bir çalışmadır. UDP zaten evrensel olarak desteklenmektedir. QUIC, UDP'nin en iyi çaba gerektiren datagramlarının üzerinde kendi güvenilirliğini, tıkanıklık kontrolünü ve sıralamasını uygular.
- Bir VPN QUIC'de tünel açabilir mi?
- Evet — QUIC, VPN'e gönderilen ve diğer trafiklerde olduğu gibi bunları kendi tünelinde kapsülleyen UDP paketlerinden ibarettir. WireGuard bunu temiz bir şekilde halleder; OpenVPN de gayet iyi. Tünel içindeki QUIC trafiği, küçük bir ek yük ile çift şifrelidir (QUIC katmanı + VPN katmanı).
- HTTP/3 QUIC gerektiriyor mu?
- Evet, tanımı gereği. HTTP/3, QUIC üzerinden HTTP'dir; HTTP/3-over-TCP yoktur. Adlandırma biraz kafa karıştırıcı çünkü HTTP/2'de "over QUIC" prototipleri (gQUIC) de var, ancak HTTP/3'ün IETF sürümü 2021'de piyasaya sürülecek.