QUIC Nedir? Daha Hızlı İnternet Protokolü

QUIC, UDP üzerinde çalışan; güvenilir taşıma, TLS 1.3 şifreleme, çoklu akış ve bağlantı göçünü tek protokolde birleştiren taşıma katmanıdır. HTTP/3 bu katmanı kullanır. QUIC her siteyi otomatik hızlandırmaz; etkisi özellikle paket kaybı, yüksek gecikme ve mobil ağ değişimlerinde ölçülür.

QUIC nedir ve hangi sorunu çözer?

QUIC, uygulama katmanındaki HTTP trafiğini UDP üzerinde taşıyan, bağlantı kurulumu ile TLS 1.3 şifrelemesini birlikte tasarlayan modern bir taşıma protokolüdür. IETF’nin RFC 9000 standardına göre QUIC; akış çoklama, bağlantı kimlikleri, kayıp paket kurtarma ve bağlantı göçü gibi özellikler sunar. HTTP/3 ise HTTP semantiğini QUIC akışları üzerinde çalıştırır.

Ayrım nettir: QUIC taşıma katmanıdır; HTTP/3, bu taşıma katmanını kullanan HTTP sürümüdür. Bir web sunucusunda HTTP/3 etkinleştirildiğinde genellikle UDP 443 üzerinden QUIC, TCP 443 üzerinden de HTTP/2 veya HTTP/1.1 birlikte sunulur.

TCP yıllardır güvenilir bir temel sağlıyor. Ancak TCP bağlantısındaki paket kaybı, aynı bağlantı içindeki bütün veri akışlarını etkileyebilir. QUIC verileri bağımsız akışlara ayırır. Bir akışta paket kaybolduğunda diğer akışların verisi, kayıp paket yeniden gönderilene kadar zorunlu olarak beklemek zorunda kalmaz.

Ne yapılmalı – QUIC’i HTTP/3 ile birlikte değerlendirin; protokolün taşıma katmanı, HTTP/3’ün ise uygulama katmanı olduğunu yapılandırma sırasında ayırın.

QUIC nasıl çalışır?

Bir QUIC bağlantısı UDP kullandığı için basit görünebilir. Gerçekte güvenilirlik, sıra kontrolü, akış yönetimi, tıkanıklık kontrolü ve şifreleme gibi TCP’nin yıllar içinde kazandığı işlevlerin büyük bölümünü kullanıcı alanında yeniden kurar.

UDP üzerinde güvenilir taşıma

UDP, paketlerin teslim edileceğini veya doğru sırada ulaşacağını garanti etmez. QUIC bu eksikliği paket numaraları, onay paketleri ve kayıp kurtarma algoritmalarıyla giderir. Bu yüzden “UDP olduğu için güvenilir değil” yorumu eksiktir. Güvenilirlik UDP’den değil, QUIC katmanından gelir.

QUIC paketleri doğrudan işletim sistemi çekirdeğindeki TCP yığınına bağlı değildir. Uygulama veya kütüphane, protokol davranışını daha hızlı güncelleyebilir. Yeni bir TCP özelliği için işletim sistemi ve ağ cihazı desteği beklemek gerekebilir; QUIC’in kullanıcı alanında uygulanması bu süreci kısaltabilir.

Bağlantı kimliği ve ağ değişikliği

TCP bağlantıları çoğunlukla istemci IP’si, istemci portu, sunucu IP’si ve sunucu portundan oluşan dört parçalı tanımlayıcıya bağlıdır. İstemci Wi-Fi’dan mobil ağa geçtiğinde bu bilgiler değişir ve TCP bağlantısı kopabilir.

QUIC bağlantıları ise Connection ID adı verilen kimliklerle takip edilebilir. İstemci aynı bağlantıyı koruyarak ağ değiştirebilir. Bu özellik, özellikle mobil cihazlarda veya sık Wi-Fi geçişi yaşanan ortamlarda yeniden bağlantı maliyetini azaltabilir. Her ağ değişiminde bağlantının kesinlikle korunacağı anlamına gelmez; NAT, güvenlik duvarı ve sunucu politikaları yine belirleyicidir.

Akışlar ve head-of-line blocking

HTTP/2, tek TCP bağlantısı üzerinde birden fazla istek ve yanıtı çoklayabilir. Bu, bağlantı sayısını azaltır; fakat TCP seviyesinde kaybolan bir paket, o paketten sonraki bütün verilerin teslimini etkileyebilir. Buna head-of-line blocking denir.

QUIC çoklamayı taşıma katmanının içine alır. Bir HTTP/3 bağlantısındaki her istek kendi QUIC akışında taşınabilir. Bir görselin akışı paket kaybı nedeniyle beklerken CSS veya başka bir isteğin akışı ilerleyebilir. Kayıp paket yine yeniden gönderilmelidir; fakat bekleme alanı daha sınırlı kalır.

QUIC ile TCP ve HTTP/2 arasındaki fark nedir?

Karşılaştırmayı yalnızca “UDP daha hızlıdır” cümlesine indirmek doğru değildir. QUIC’in avantajı, UDP’nin düşük seviyeli yapısını TLS 1.3, akış yönetimi ve bağlantı kontrolüyle bir araya getirmesinden kaynaklanır.

RFC 9001, QUIC’in TLS 1.3 kullanmasını tanımlar. Bu nedenle QUIC’i eski TLS sürümleriyle çalıştırmak veya şifrelemeyi sonradan eklenen bir katman gibi düşünmek doğru değildir. Sertifika yönetimi önemini korur; HTTPS sertifikası, alan adı ve istemci doğrulaması HTTP/3 tarafında ortadan kalkmaz.

QUIC’in ilk bağlantıda her zaman büyük bir gecikme azalması sağlamadığı da hesaba katılmalı. İstemci ve sunucu arasındaki mesafe kısa, bağlantı kararlı ve TLS oturumu yeniden kullanılıyorsa TCP + HTTP/2 zaten yeterince hızlı olabilir. Kazanç; el sıkışma sayısı, paket kaybı, mobil ağ geçişi ve paralel isteklerin yapısıyla değişir.

Ne yapılmalı – TCP 443’ü kapatmadan UDP 443’ü ekleyin ve gerçek istemci davranışlarını HTTP/2 ile HTTP/3 için ayrı ayrı ölçün.

HTTP/3 ile QUIC ilişkisi nedir?

HTTP/3, RFC 9114 ile tanımlanan HTTP sürümüdür ve QUIC üzerinde çalışır. HTTP yöntemleri, durum kodları, başlıklar ve gövde mantığı büyük ölçüde tanıdıktır; değişen bölüm, bu HTTP mesajlarının tel üzerinde taşınma biçimidir.

HTTP/2’de başlıklar HPACK ile sıkıştırılır. HTTP/3 ise QPACK kullanır. QPACK, QUIC’in bağımsız akış modeline göre tasarlanmıştır; başlık sıkıştırma tablosundaki güncellemelerin diğer akışları gereksiz şekilde durdurmaması hedeflenir.

Bir tarayıcı, sunucunun HTTP/3 desteklediğini çoğunlukla Alt-Svc yanıt başlığı veya HTTPS DNS kaydı üzerinden öğrenir. İlk istek TCP ile gerçekleşebilir, sonraki isteklerde istemci UDP 443 üzerinden QUIC bağlantısını deneyebilir. UDP başarısız olursa TCP tabanlı HTTP/2’ye dönmek, geçiş dönemindeki altyapı için sağlıklı davranıştır.

HTTP/3 kullanımı uygulama kodunu otomatik olarak değiştirmez. PHP, Node.js veya Python uygulamanız HTTP isteklerini almaya devam eder; QUIC çoğu kurulumda istemci ile ters proxy arasındaki katmanda sonlandırılır. Ters proxy ile uygulama sunucusu arasındaki bağlantı HTTP/1.1 veya HTTP/2 olabilir.

Sunucuda HTTP/3 ve QUIC nasıl test edilir?

Önce alan adının doğru IP adresine çözüldüğünü ve sunucunun UDP 443’ü dinlediğini kontrol edin. DNS tarafında bir IP Adresi Nedir? kaynağındaki temel kontroller, QUIC için de geçerlidir; yalnızca TCP erişiminin çalışması UDP erişiminin de çalıştığını göstermez.

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ı, ss çıktısı UDP 443 dinleyicisini, nft çıktısı ise güvenlik duvarı kurallarını incelemeye yarar. Çıktıda yalnızca TCP 443 görünüyorsa HTTP/3 henüz dinlenmiyor olabilir.

curl sürümünüz HTTP/3 destekliyorsa basit bir istemci testi yapılabilir:

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

Komutun çalışması için curl’ün HTTP/3 destekli bir QUIC kütüphanesiyle derlenmiş olması gerekir. option --http3: the installed libcurl version doesn't support this benzeri bir hata, doğrudan sunucunun hatalı olduğunu kanıtlamaz; önce istemci yeteneğini doğrulayın.

curl -V

Çıktıdaki Features satırında HTTP3 veya ilgili HTTP/3 desteğini arayın. Dağıtım depolarındaki curl sürümü bu özelliği içermiyorsa tarayıcı geliştirici araçları, nghttp3 tabanlı istemciler veya sağlayıcının resmi test araçları kullanılabilir.

Tarayıcı tarafında geliştirici araçlarının Network sekmesindeki Protocol sütununa bakın. h3 veya h3-29 gibi bir değer HTTP/3 bağlantısını, h2 HTTP/2’yi, http/1.1 ise eski HTTP sürümünü gösterir. Tarayıcı önbelleği ve mevcut oturum ilk denemeyi etkileyebileceği için gizli pencere veya yeni profil ile de test yapın.

Ne yapılmalı – curl desteğini, DNS kayıtlarını, UDP 443 firewall kuralını ve tarayıcıdaki protokol değerini aynı test planında doğrulayın.

QUIC kullanırken hangi portlar ve firewall kuralları gerekir?

HTTP/3 için yaygın sunucu portu UDP 443’tür. TCP 443 ise HTTP/2 ve HTTP/1.1 geri dönüşü için açık tutulmalıdır. QUIC istemci tarafında sabit bir kaynak portu kullanmaz; istemci işletim sistemi genellikle geçici bir UDP portu seçer.

Bir VPS sağlayıcısının güvenlik grubu UDP 443’ü engelliyorsa Nginx veya uygulama sunucusunda QUIC’i açmak yeterli olmaz. Aynı kontrol işletim sistemi firewall’ı, bulut güvenlik grubu, edge proxy, CDN ve varsa kurumsal ağ cihazları için ayrı ayrı yapılmalıdır.

UDP trafiğini sınırsız bırakmak da iyi bir güvenlik politikası değildir. Paket hızı, bağlantı sayısı ve kaynak tüketimi izlenmelidir. QUIC bağlantılarında TLS el sıkışması ve kriptografik işlemler CPU kullanabilir. DDoS koruması gereken projelerde DDoS Saldırısı Nedir? VPS Koruma Rehberi başlığındaki genel ağ katmanı kontrolleri QUIC için UDP boyutuyla genişletilmelidir.

MTU ve parçalanma sorunları da göz ardı edilmemeli. UDP paketlerinin yol üzerinde parçalanması, TCP’dekinden farklı arızalar oluşturabilir. Özellikle tünel, VPN veya kapsülleme kullanılan ağlarda PMTU davranışını ve kayıp oranını gözlemleyin.

QUIC’in hız avantajı her sitede görülür mü?

QUIC’in en belirgin faydası yüksek gecikmeli, paket kaybı yaşayan veya mobil ağ değişiklikleri bulunan bağlantılarda ortaya çıkabilir. Çok sayıda küçük kaynağın aynı anda istendiği web sayfalarında bağımsız akışlar ve daha az el sıkışma gecikmeyi azaltabilir.

Sunucuya yakın, kayıpsız ve iyi önbelleklenen bir sayfada fark küçük kalabilir. Sayfa bir CDN’den veriliyor, HTML tek bir küçük dosyadan oluşuyor veya backend yanıtı 800 milisaniye sürüyorsa taşıma protokolündeki birkaç milisaniyelik kazanç toplam süreyi belirlemez.

Ölçüm sırasında yalnızca TTFB’ye bakmak yeterli değildir. İlk bağlantı, yeniden bağlantı, önbellekli kaynaklar, kayıp paket oranı, p95 ve p99 gecikmeleri birlikte incelenmelidir. VPS Bant Genişliği Nedir? İhtiyacınızı Hesaplayın içeriğindeki kapasite hesabı da yardımcı olur; bant genişliği ile gecikme aynı ölçüm değildir.

Bir CDN kullanılıyorsa HTTP/3 çoğu zaman origin sunucuda değil edge noktasında sonlandırılır. Bu durumda ziyaretçinin edge’e bağlantısı QUIC olabilirken edge ile origin arasındaki bağlantı TCP kalabilir. Test raporunu hazırlarken hangi bağlantı bölümünün ölçüldüğünü yazın.

Ne yapılmalı – HTTP/2 ve HTTP/3 için aynı URL, aynı içerik ve benzer istemci koşullarıyla p95 gecikmeyi karşılaştırın.

QUIC’in dezavantajları ve güvenlik sınırları nelerdir?

QUIC her altyapıda sorunsuz çalışmaz. Bazı eski güvenlik duvarları ve ağ izleme sistemleri TCP trafiğini ayrıntılı biçimde tanırken UDP trafiğini sınırlayabilir veya engelleyebilir. Böyle bir ağda HTTP/3 bağlantısı kurulamaz; TCP fallback çalışmıyorsa kullanıcı hata görebilir.

Gözlemleme tarafında da alışkanlıkları değiştirmek gerekir. TCP bağlantılarını izleyen mevcut paneller, QUIC akışlarının durumunu tam göstermeyebilir. Sunucu ve proxy’nin QUIC metrikleri, UDP paket kaybı, handshake hataları, bağlantı göçleri ve fallback oranları ayrıca toplanmalıdır.

0-RTT bağlantı yeniden kurulurken gecikmeyi düşürebilir. Fakat RFC 9001 ve TLS 1.3 modelinde 0-RTT verileri yeniden oynatma riskine açıktır. Bu nedenle para transferi, sipariş oluşturma, parola değiştirme veya başka yan etkili işlemler 0-RTT verisiyle koşulsuz kabul edilmemelidir. İdempotent GET istekleri bu özellik için daha uygun adaydır.

QUIC şifreli olduğu için ağ yöneticileri içeriği doğrudan inceleyemez; bu, kullanıcı gizliliği açısından olumlu olsa da hata ayıklama ve politika uygulama yöntemlerini etkiler. TLS anahtar günlükleme, uç nokta metrikleri ve kontrollü paket analizi kurumun güvenlik politikasına uygun tasarlanmalıdır.

HTTP/3’ü etkinleştirmek, kötü yapılandırılmış uygulamayı hızlandırmaz. Veritabanı sorgusu yavaşsa, resimler sıkıştırılmamışsa veya önbellek başlıkları hatalıysa protokol değişikliği sorunu gizlemeye çalışır. Önce 502 Bad Gateway Hatası Nedir ve Nasıl Çözülür? gibi uygulama ve proxy arızalarının temel nedenlerini ayırın.

QUIC etkinleştirmeden önce nasıl bir geçiş planı izlenir?

Üretim sisteminde doğrudan UDP 443 açıp başarı beklemek yerine kademeli geçiş daha güvenlidir. Önce sunucu yazılımının kullanılan sürümünde HTTP/3 desteğini, TLS sertifikasının durumunu ve kernel firewall kurallarını doğrulayın. Sağlayıcının yük dengeleyicisi veya CDN’i aradaysa onun QUIC desteği ayrıca kontrol edilmelidir.

1. Alan adının A ve AAAA kayıtlarını doğrulayın.
2. TCP 443 fallback erişimini koruyun.
3. UDP 443’ü güvenlik gruplarında ve nftables üzerinde kontrollü olarak açın.
4. HTTP/3 destekli sunucu veya reverse proxy yapılandırmasını test ortamında deneyin.
5. curl ve tarayıcı geliştirici araçlarıyla gerçek protokolü doğrulayın.
6. HTTP/2’ye dönen istemcilerin hata almadığını izleyin.
7. Hata, gecikme, CPU ve UDP paket kaybı metriklerini karşılaştırın.

Bir alan adında HTTP/3 çalışırken başka bir alt alan adında çalışmaması olağandır; her edge, proxy ve DNS katmanı farklı yapılandırılabilir. DNS değişikliklerini incelemek için DNS_PROBE_FINISHED_NXDOMAIN Hatası Nasıl Çözülür? içeriğindeki temel yaklaşım kullanılabilir, fakat QUIC sorunu için ayrıca UDP yolunu test etmek gerekir.

Geri dönüş planı basit olmalı: UDP 443’ü kapatmak veya HTTP/3 ilanını kaldırmak, TCP 443 üzerinden hizmeti sürdürmenize izin vermeli. QUIC’i açmadan önceki HTTP/2 ölçümlerini saklayın; aksi halde hız iddiası karşılaştırılamaz bir izlenime dönüşür.

Amaç bütün ziyaretçileri zorla QUIC’e geçirmek değildir. Uyumlu istemcilere HTTP/3 sunmak, diğerlerine HTTP/2 veya HTTP/1.1 vermek daha dayanıklı bir internet hizmeti sağlar.

Ne yapılmalı – HTTP/3’ü önce ölçülebilir bir trafik diliminde yayınlayın ve fallback ile geri dönüşü aynı gün test edin.

QUIC Kurulumundan Önce Şunları Kontrol Edin

• HTTP/3 ve QUIC desteğini kullandığınız sunucu veya CDN sürümünde doğrulayın.
• Alan adının A ve AAAA kayıtlarını test edin.
• UDP 443'ü sunucu, güvenlik grubu ve firewall katmanlarında kontrollü biçimde açın.
• TCP 443'ü HTTP/2 ve HTTP/1.1 fallback için açık tutun.
• curl sürümünün HTTP/3 desteğiyle derlendiğini curl -V çıktısından kontrol edin.
• Tarayıcı Network sekmesinde protokolün gerçekten h3 olduğunu doğrulayın.
• p95 gecikme, CPU, paket kaybı ve fallback oranlarını HTTP/2 ile karşılaştırın.

Sık Sorulan Sorular

Kaynaklar

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