What Is QUIC? A Guide to the Faster Internet Protocol

QUIC, UDP üzerinde çalışan güvenli bir taşıma protokolüdür; TCP'den beklediğiniz güvenilirlik, akış yönetimi ve tıkanıklık kontrolünü kendi katmanında sağlar. HTTP/3, bağımsız akışlar ve TLS 1.3 entegrasyonu sayesinde bazı ağlarda taşıma gecikmesini azaltabilir; ancak ölçüm ve TCP geri dönüşü hâlâ şarttır.

QUIC nedir, hangi sorunu çözer?

QUIC, uygulama trafiğini UDP üzerinden taşıyan ve bağlantı kurulumu ile TLS 1.3 şifrelemesini birlikte tasarlayan modern bir taşıma protokolüdür. IETF’nin yayımladığı RFC 9000; akışların çoklanması, bağlantı kimlikleri, paket kaybı kurtarma ve bağlantı taşınması gibi özellikleri tanımlar. HTTP/3 ise QUIC üzerinde çalışan HTTP sürümüdür.

Bu ayrım pratikte önemlidir. QUIC taşıma katmanıdır; HTTP/3 bu taşıma katmanını kullanan HTTP protokolüdür. Bir web sunucusunda HTTP/3’ü etkinleştirdiğinizde genellikle UDP 443 üzerinden QUIC’i, TCP 443 üzerinden de HTTP/2 veya HTTP/1.1’i birlikte sunarsınız.

TCP onlarca yıldır güvenilir bir temel sağlıyor. Fakat TCP bağlantısı içindeki tek bir kayıp paket, aynı bağlantıdaki bütün veri akışlarını etkileyebilir. QUIC veriyi bağımsız akışlara böler. Bir akışta paket kaybı olduğunda diğer akışların bu paketin yeniden gönderilmesini beklemesi gerekmez.

Ne yapmalı? QUIC’i HTTP/3 ile birlikte değerlendirin ve sunucu yapılandırırken taşıma katmanı ile HTTP katmanının görevlerini birbirine karıştırmayın.

QUIC nasıl çalışır?

QUIC dışarıdan basit görünebilir; sonuçta UDP kullanır. İçeride ise TCP’nin yıllar içinde biriktirdiği güvenilirlik, sıralama, akış yönetimi, tıkanıklık kontrolü ve kayıp kurtarma işlerinin önemli bölümünü kullanıcı alanında yeniden uygular. TLS 1.3 de bağlantı el sıkışmasına doğrudan dahil edilir.

Kulağa uzun geliyor. Mantığı aslında net.

UDP üzerinde güvenilir taşıma

UDP teslimat veya paket sıralaması garantisi vermez. QUIC bu boşluğu paket numaraları, onaylar ve kayıp kurtarma algoritmalarıyla doldurur. Bu yüzden “UDP kullandığı için QUIC güvenilir değildir” cümlesi eksiktir: güvenilirliği UDP değil, QUIC sağlar.

QUIC paketleri işletim sisteminin çekirdek TCP yığınına doğrudan bağlı değildir. Bir uygulama veya kütüphane, her işletim sisteminin ve ağ cihazının yeni bir TCP özelliğini desteklemesini beklemeden protokol davranışını güncelleyebilir. Bu, her güncellemenin kolay olacağı anlamına gelmez; geliştiricilere daha geniş bir hareket alanı verir.

Bağlantı kimlikleri ve ağ değişiklikleri

TCP bağlantıları genellikle istemci IP adresi, istemci portu, sunucu IP adresi ve sunucu portundan oluşan dört öğeyle tanımlanır. Bir cihaz Wi-Fi’dan mobil ağa geçtiğinde bu bilgiler değişebilir ve TCP bağlantısı kopabilir.

QUIC bağlantıları bunun yerine Connection ID değerleriyle takip edilebilir. İstemci ağ değiştirirken aynı bağlantıyı koruyabilir; bu da mobil cihazlarda veya Wi-Fi kapsamasının sık değiştiği yerlerde yeniden bağlanma maliyetini azaltabilir. Bu bir garanti değildir. NAT, güvenlik duvarları ve sunucu politikası hâlâ sonucu belirler.

Ben bunu özellikle hareket halindeyken anlamlı buluyorum. Ancak protokolün adı tek başına kopan bir mobil bağlantıyı iyileştirmez.

Akışlar ve head-of-line blocking

HTTP/2, tek bir TCP bağlantısı üzerinde birden fazla istek ve yanıtı çoklar. Bu bağlantı sayısını azaltır; fakat kayıp bir TCP paketi, ondan sonraki verilerin paket yeniden gönderilene kadar beklemesine yol açabilir. Buna head-of-line blocking denir.

QUIC çoklamayı taşıma katmanına taşır. HTTP/3 bağlantısındaki her istek kendi QUIC akışını kullanabilir. Bir görsel akışı paket kaybı nedeniyle beklerken CSS veya API akışı ilerleyebilir. Kayıp paket yine yeniden gönderilir; gecikme daha çok etkilenen akışla sınırlı kalır.

QUIC, TCP ve HTTP/2 karşılaştırması

Karşılaştırmayı “UDP daha hızlıdır” cümlesine indirgemek doğru olmaz. QUIC’in olası avantajı; UDP’nin datagram modelini TLS 1.3, akış yönetimi, bağlantı kontrolü ve kayıp kurtarmayla birlikte kullanmasından gelir.

RFC 9001, QUIC’in TLS 1.3’ü nasıl kullandığını tanımlar. QUIC eski bir TLS sürümüyle çalışacak veya şifreleme sonradan eklenecek şekilde tasarlanmamıştır. Sertifika yönetimi yine önemlidir: HTTPS sertifikaları, alan adları ve istemci kimlik doğrulaması HTTP/3 kullandığınızda ortadan kalkmaz.

İlk bağlantının her zaman dramatik biçimde hızlanacağını varsaymayın. İstemci sunucuya yakınsa, ağ yolu sağlamsa ve TLS oturum yeniden kullanımı çalışıyorsa TCP ile HTTP/2 zaten yeterince hızlı olabilir. Sonuç; el sıkışma maliyetine, paket kaybına, ağ değişikliklerine ve paralel isteklerin yapısına bağlıdır.

Ne yapmalı? UDP 443’ü eklerken TCP 443’ü açık bırakın ve gerçek HTTP/2 ile HTTP/3 istemci davranışını ayrı ayrı ölçün.

HTTP/3 ile QUIC arasındaki ilişki nedir?

HTTP/3, RFC 9114 ile tanımlanan ve QUIC üzerinde çalışan HTTP sürümüdür. HTTP metotları, durum kodları, başlıklar ve istek gövdeleri tanıdık kalır; asıl değişiklik bu mesajların ağ üzerinde nasıl taşındığıdır.

HTTP/2, başlıkları HPACK ile sıkıştırır. HTTP/3 ise QUIC’in bağımsız akış modeline göre tasarlanan QPACK’i kullanır. Amaç, başlık sıkıştırma tablosundaki bir güncellemenin ilgisiz akışları gereksiz yere durdurmasını önlemektir.

Tarayıcılar bir sunucunun HTTP/3 desteklediğini çoğunlukla Alt-Svc yanıt başlığı veya HTTPS DNS kaydı üzerinden öğrenir. İlk istek TCP ile gidebilir; ardından istemci UDP 443 üzerinden QUIC bağlantısını deneyebilir. UDP çalışmıyorsa TCP tabanlı HTTP/2’ye dönmek, geçiş sürecindeki altyapı için sağlıklı davranıştır.

HTTP/3 kullanmak uygulamada otomatik olarak değişiklik yapmanızı gerektirmez. PHP, Node.js veya Python uygulamanız HTTP isteklerini almaya devam edebilir. Pek çok kurulumda QUIC, ziyaretçiye bakan reverse proxy’de sonlandırılır; proxy ile uygulama sunucusu arasındaki bağlantı HTTP/1.1 veya HTTP/2 olarak kalabilir.

Sunucuda HTTP/3 ve QUIC testi

Önce alan adının doğru adrese çözümlendiğini ve sunucunun UDP 443 üzerinde dinlediğini kontrol edin. What Is an IP Address and How Does It Work? yazısındaki temel kontroller burada da işinize yarar; yalnız çalışan TCP erişimi, UDP erişiminin çalıştığını kanıtlamaz.

dig +short A example.com
dig +short AAAA example.com
ss -lunp | grep ':443'
sudo nft list ruleset

İlk iki komut IPv4 ve IPv6 kayıtlarını gösterir. ss çıktısı UDP 443 üzerinde bir sürecin dinleyip dinlemediğini, nft ise güvenlik duvarı kurallarını gösterir. Yalnızca TCP 443 görüyorsanız HTTP/3 henüz dinlemiyor olabilir.

Benim OptiPlex üzerindeki Proxmox laboratuvarımda bu kontrolleri özellikle ayrı çalıştırıyorum. Bir keresinde hizmetin çalıştığını görünce ağ yolunu tamamlanmış sandım; istemci testinde UDP kuralının eksik olduğunu fark ettim. Dinleyen soket, çalışan erişim yolu demek değil.

curl derlemeniz HTTP/3 destekliyorsa basit bir istemci isteği deneyin:

curl -I --http3 https://example.com

Bu komutun çalışması, curl’ün HTTP/3 destekleyen bir QUIC kütüphanesiyle derlenmiş olmasını gerektirir. option --http3: the installed libcurl version doesn't support this benzeri bir hata sunucunun bozuk olduğunu kanıtlamaz. Önce istemci yeteneğini kontrol edin.

curl -V

Features satırında HTTP3 veya HTTP/3 desteğiyle ilişkili bir özellik arayın. Dağıtımınızın curl paketi bunu içermiyorsa tarayıcı geliştirici araçlarını, nghttp3 tabanlı bir istemciyi veya sağlayıcınızın resmi test aracını kullanabilirsiniz.

Tarayıcıda Network panelindeki Protocol sütununa bakın. h3 veya h3-29 HTTP/3’ü, h2 HTTP/2’yi, http/1.1 ise eski protokolü gösterir. Önbellek ve mevcut oturum ilk testi etkileyebilir; özel pencere veya yeni profil ile de deneyin.

Ne yapmalı? curl desteğini, DNS kayıtlarını, UDP 443 güvenlik duvarı kuralını ve tarayıcının anlaşılmış protokolünü tek bir test planının parçaları olarak doğrulayın.

QUIC için portlar ve güvenlik duvarı kuralları

HTTP/3 için kullanılan standart sunucu portu genellikle UDP 443’tür. HTTP/2 ve HTTP/1.1 geri dönüşü için TCP 443 açık kalmalıdır. QUIC istemcileri tek bir sabit kaynak portu kullanmaz; işletim sistemi normalde geçici bir UDP portu seçer.

VPS sağlayıcısının security group’u UDP 443’ü engelliyorsa Nginx’te veya uygulama sunucusunda QUIC’i açmak yetmez. İşletim sistemi güvenlik duvarını, bulut güvenlik grubunu, edge proxy’yi, CDN’i ve kurumsal ağ cihazlarını ayrı ayrı kontrol edin.

UDP’yi sınırsız bırakmak da güvenlik politikası değildir. Paket hızını, bağlantı sayısını ve kaynak tüketimini izleyin. QUIC el sıkışmaları ve şifreleme işlemleri CPU kullanabilir. DDoS korumasına ihtiyaç duyan projelerde What Is a DDoS Attack? A Practical VPS Protection Guide yazısındaki ağ kontrollerine UDP tarafını da eklemek gerekir.

MTU ve parçalanmayı da göz ardı etmeyin. Parçalanmış UDP paketleri, TCP’deki arızalardan farklı şekilde başarısız olabilir. Tünel, VPN veya başka bir encapsulation kullanıyorsanız yol MTU davranışını ve paket kaybını gözlemleyin.

Küçük bir kural değişikliği bile sonuç verir. Önce staging’de deneyin.

QUIC bir siteyi ne zaman gerçekten hızlandırır?

QUIC’in en belirgin faydaları yüksek gecikmeli veya paket kayıplı bağlantılarda ve istemcilerin Wi-Fi ile mobil veri arasında sık geçiş yaptığı ağlarda görülebilir. Aynı anda çok sayıda küçük kaynak isteyen sayfalar, bağımsız akışlardan ve daha az el sıkışma gecikmesinden yararlanabilir.

Yakındaki, paket kaybı olmayan bir sunucuda iyi önbelleğe alınmış bir sayfada fark küçük kalabilir. CDN sayfayı sunuyorsa, HTML tek ve küçük bir dosyaysa veya backend yanıtı üretmek için 800 milisaniye harcıyorsa taşıma katmanındaki birkaç milisaniye toplam süreyi belirlemez.

Yalnızca TTFB’yi ölçmeyin. İlk bağlantıları, yeniden kullanılan bağlantıları, önbelleğe alınmış kaynakları, paket kaybını ve p95 ile p99 gecikmeyi karşılaştırın. VPS Bandwidth Explained: How Much Do You Need? kapasite planlaması için yararlı; fakat bant genişliği ile gecikme aynı ölçüm değildir.

CDN varsa HTTP/3 çoğu zaman origin sunucuda değil edge noktasında sonlandırılır. Ziyaretçi ile edge arasındaki bölüm QUIC kullanırken edge ile origin arasındaki bölüm TCP olabilir. Hangi ölçümün yolun hangi kısmını kapsadığını kaydedin.

Ne yapmalı? Aynı URL ve içerik için, benzer istemci koşullarında HTTP/2 ile HTTP/3 p95 gecikmesini ayrı ayrı karşılaştırın.

QUIC sınırlamaları ve güvenlik noktaları

QUIC her ağda kusursuz çalışmaz. Eski bazı güvenlik duvarları ve izleme sistemleri TCP’yi ayrıntılı biçimde tanırken UDP’yi kısıtlayabilir veya tamamen engelleyebilir. Böyle bir durumda HTTP/3 bağlanamaz; TCP geri dönüşü de yoksa kullanıcı hata görür.

İzleme sisteminin de değişmesi gerekir. TCP bağlantıları etrafında hazırlanmış dashboard’lar QUIC akış durumunu doğru göstermeyebilir. Sunucudan veya proxy’den QUIC metriklerini, UDP paket kaybını, el sıkışma hatalarını, bağlantı taşınmalarını ve geri dönüş oranlarını toplayın.

0-RTT, yeniden kurulan bağlantılarda gecikmeyi azaltabilir. Fakat RFC 9001’de açıklanan TLS 1.3 modeli içinde 0-RTT verisi yeniden oynatma riskine açıktır. Para transferi, sipariş oluşturma, parola değiştirme veya başka yan etki üreten işlemleri 0-RTT verisi olarak koşulsuz kabul etmeyin. İdempotent GET istekleri daha uygun adaylardır.

QUIC trafiği şifreli olduğu için ağ yöneticileri içeriği doğrudan inceleyemez. Bu gizlilik için olumludur; ancak sorun giderme ve politika uygulama biçimini değiştirir. TLS anahtar günlüğü, uç nokta metrikleri ve kontrollü paket analizi kurumun güvenlik politikasına göre tasarlanmalıdır.

HTTP/3’ü açmak kötü yapılandırılmış bir uygulamayı düzeltmez. Yavaş bir veritabanı sorgusu, sıkıştırılmamış bir görsel veya hatalı cache başlığı yine yavaştır. Taşıma katmanını suçlamadan önce uygulama ve proxy hatalarını, örneğin How to Fix a 502 Bad Gateway Error yazısında anlatılan 502 durumlarını, ayırın.

Şifreli olması izleme ihtiyacını ortadan kaldırmaz. Sadece izlenecek sinyalleri değiştirir.

Uygulanabilir bir QUIC geçiş planı

Üretimde UDP 443’ü açıp beklemek bir geçiş planı değildir. Önce gerçekten çalıştırdığınız sunucu sürümünde HTTP/3 desteğini, TLS sertifikasını ve çekirdek güvenlik duvarı kurallarını doğrulayın. Önünüzde load balancer veya CDN varsa onun QUIC desteğini ayrıca kontrol edin.

1. Alan adının A ve AAAA kayıtlarını doğrulayın.
2. Geri dönüş için TCP 443’ü açık tutun.
3. Security group ve nftables üzerinde UDP 443’ü kontrollü bir değişiklikle açın.
4. HTTP/3 destekli sunucuyu veya reverse proxy’yi ana üretim yolunun dışında test edin.
5. curl ve tarayıcı geliştirici araçlarıyla anlaşılmış protokolü doğrulayın.
6. HTTP/2’de kalan istemcilerden gelen hataları izleyin.
7. Hata, gecikme, CPU kullanımı ve UDP paket kaybını karşılaştırın.

HTTP/3’ün bir hostname üzerinde çalışıp diğerinde çalışmaması normaldir; her edge, proxy ve DNS katmanının ayarı farklı olabilir. How to Fix DNS_PROBE_FINISHED_NXDOMAIN Error yazısındaki temel yaklaşım DNS kontrollerinde yardımcı olur; fakat QUIC incelemesi UDP yolunu da test etmelidir.

Geri dönüşünüz basit olmalı: UDP 443’ü kapatmak veya HTTP/3 duyurusunu kaldırmak TCP 443 üzerinden kullanıcı sunumunu bırakmamalı. Değişiklikten önce HTTP/2 ölçümlerini saklayın; aksi halde hız artışı iddianızın güvenilir bir başlangıç noktası olmaz.

Amaç her ziyaretçiyi QUIC’e zorlamak değil. Uyumlu istemcilere HTTP/3, diğerlerine HTTP/2 veya HTTP/1.1 sunmak daha toleranslı bir servis oluşturur.

Ne yapmalı? HTTP/3’ü önce ölçülebilir bir trafik dilimine açın; aynı gün içinde hem geri dönüşü hem de rollback’i test edin.

HTTP/3'ü Açmadan Önce Bunları Kontrol Edin

• Hostname için A ve AAAA kayıtlarını doğrulayın.
• HTTP/2 ve HTTP/1.1 geri dönüşü için TCP 443'ü açık tutun.
• Sağlayıcı security group'unda ve host güvenlik duvarında UDP 443'e izin verin.
• Proxy, CDN veya web sunucunuzun HTTP/3 desteklediğini doğrulayın.
• Sunucuyu incelemeden önce curl -V ile istemci desteğini kontrol edin.
• Tarayıcı geliştirici araçlarında anlaşılmış protokolü kontrol edin.
• Gecikme, hatalar, CPU kullanımı, paket kaybı ve geri dönüş oranlarını karşılaştırın.

Frequently Asked Questions

Sources

• RFC 9000 – QUIC: A UDP-Based Multiplexed and Secure Transport — rfc-editor.org
• RFC 9001 – Using TLS to Secure QUIC — rfc-editor.org
• RFC 9114 – HTTP/3 — rfc-editor.org