HTTP/3 (QUIC) Nedir, Nasıl Etkinleştirilir

HTTP/2'yi açtınız, sıkıştırmayı ayarladınız, görselleri optimize ettiniz; ama mobil kullanıcılarınızın sayfa açılış süresi hâlâ masaüstünden belirgin biçimde kötü. Bunun sebebi çoğu zaman sunucunuzun yavaşlığı değil, altta çalışan TCP'nin zayıf bir bağlantıda nasıl davrandığıdır. HTTP/3, tam olarak bu noktaya müdahale eden protokol sürümüdür: TCP'yi tamamen bırakır, QUIC adında UDP üzerine kurulmuş yeni bir taşıma katmanı kullanır ve TLS el sıkışmasını da bu katmanın içine gömer.

Bu rehberde HTTP/3'ün HTTP/2'den nerede ayrıldığını, QUIC'in paket kaybı olan bağlantılarda neden bu kadar avantajlı olduğunu, Nginx ve Cloudflare üzerinde nasıl etkinleştirileceğini, Alt-Svc başlığının ne işe yaradığını ve protokolün gerçekten devrede olup olmadığını nasıl doğrulayacağınızı anlatacağım. Ayrıca UDP 443 portunun kapalı olması gibi, yapılandırma doğru olsa bile HTTP/3'ün sessizce hiç çalışmamasına yol açan tuzaklara da değineceğim.

HTTP/2 Neyi Çözemedi#

HTTP/2 tek bir TCP bağlantısı üzerinde onlarca isteği paralel taşıyabiliyor; buna multiplexing diyoruz ve HTTP/1.1'e göre büyük bir kazanç. Ancak bu paralellik yalnızca HTTP katmanında geçerli. Altta hâlâ tek bir TCP bağlantısı var ve TCP, verinin sıraya uygun teslim edilmesini garanti eder. Yani ağda tek bir paket kaybolduğunda, TCP o paketin tekrar gelmesini bekler ve arkasındaki tüm veriyi uygulamaya teslim etmez. On farklı isteğin verisi aynı bağlantıda taşındığı için, tek bir kayıp paket dokuz sağlıklı isteği de bekletir. Buna taşıma katmanı head-of-line blocking denir ve HTTP/2 bunu çözemez, çünkü sorun HTTP'de değil TCP'dedir.

Bu, fiber bağlantıdaki bir masaüstü kullanıcısı için pratikte görünmez. Ama mobil şebekede, kalabalık bir kafenin Wi-Fi'ında ya da uzun mesafeli bir bağlantıda paket kaybı %1-2 seviyesine çıktığında etkisi ciddi biçimde hissedilir. HTTP/2'nin genel mantığını ve multiplexing'in nasıl çalıştığını henüz incelemediyseniz, devam etmeden önce HTTP/2 nedir yazısı bu rehberin zeminini oturtur.

İkinci bir sorun bağlantı kurma maliyetidir. HTTPS bir bağlantı açarken önce TCP üç yollu el sıkışması, ardından TLS el sıkışması yapılır; bu iki ayrı gidiş-dönüş demektir. Gecikmesi 80 ms olan bir bağlantıda ilk baytı almadan önce yüz milisaniyelerce zaman harcanır ve bu süre tamamen ağ gecikmesinden gelir; sunucunuz ne kadar hızlı olursa olsun kısalmaz.

QUIC Ne Yapıyor#

QUIC, TCP'nin yerine geçen bir taşıma protokolüdür ve UDP üzerine kurulmuştur. UDP seçilmesinin sebebi UDP'nin "daha hızlı" olması değil; internetteki ara cihazların (NAT, güvenlik duvarı, operatör ekipmanı) yeni bir taşıma protokolünü tanımayıp düşürmesi. UDP zaten her yerde geçtiği için QUIC, kendi güvenilirlik, sıralama ve tıkanıklık kontrolü mekanizmalarını UDP paketlerinin içinde kurar. Yani QUIC "güvenilir olmayan" bir protokol değildir; TCP'nin yaptığı işi kullanıcı alanında, daha esnek biçimde yeniden yapar.

Bu yeniden yazımın getirdiği üç somut fark var:

Son satır mobil için özellikle değerli. TCP'de bir bağlantı kaynak IP + port + hedef IP + port dörtlüsüyle tanımlanır; telefonunuz Wi-Fi'dan mobil veriye geçtiğinde IP değişir ve bağlantı ölür, her şey baştan kurulur. QUIC'te bağlantıyı tanımlayan şey IP değil, bağlantı kimliğidir (Connection ID). Ağ değişse bile aynı oturum kaldığı yerden devam eder — asansöre binen bir kullanıcının video akışının donmaması bu sayededir.

HTTP/3 Size Ne Kazandırır, Kime Kazandırmaz#

Dürüst olmak gerekirse HTTP/3, iyi bir bağlantıdan giren masaüstü kullanıcısı için ölçülebilir bir fark yaratmayabilir. Paket kaybı sıfıra yakınsa TCP'nin head-of-line blocking sorunu zaten ortaya çıkmaz ve HTTP/2 ile HTTP/3 arasındaki fark ölçüm gürültüsünün içinde kaybolur. HTTP/3'ün gerçek kazancı kötü koşullarda görünür: mobil şebeke, yüksek gecikme, coğrafi uzaklık, kayıplı Wi-Fi.

Buna göre kabaca şöyle bir öncelik listesi çıkarabilirsiniz. Trafiğinizin çoğu mobilse ve ziyaretçilerinizin bir kısmı sunucunuzdan uzaktaysa HTTP/3 doğrudan kullanıcı deneyimini iyileştirir. Trafiğiniz ağırlıklı olarak yurt içi, kablolu ve sunucunuza yakınsa kazanç mütevazıdır ama zarar da yoktur; protokol geriye dönük uyumludur, desteklemeyen istemci sorunsuzca HTTP/2'ye düşer. Yani "açmalı mıyım" sorusunun cevabı neredeyse her zaman evettir; beklentiyi doğru kurmak yeterlidir.

Şunu da net söyleyeyim: HTTP/3 yavaş bir sunucuyu hızlandırmaz. Veritabanı sorgunuz 800 ms sürüyorsa protokol değişikliği bunu kurtarmaz. Önce sunucu yanıt süresini düşürmek gerekir; LCP nasıl iyileştirilir yazısındaki öncelik sırası bu konuda iyi bir çerçeve sunar.

Nginx Üzerinde HTTP/3 Etkinleştirme#

Nginx, HTTP/3 desteğini 1.25.0 sürümüyle birlikte deneysel etiketi olmadan sunmaya başladı ve yapılandırması oldukça sadedir. Önce sürümünüzü ve QUIC desteğinin derlenmiş olup olmadığını kontrol edin:

# Sürüm ve derleme parametrelerini gör
nginx -V 2>&1 | tr ' ' '\n' | grep -E "nginx/|http_v3"
# Beklenen çıktı satırları:
# nginx/1.27.x
# --with-http_v3_module

--with-http_v3_module görünmüyorsa dağıtımınızın paketi HTTP/3 olmadan derlenmiş demektir; resmî Nginx deposundan kurmanız gerekir. Modül varsa sunucu bloğu şöyle görünür:

server {
    # TCP üzerinde HTTP/1.1 ve HTTP/2
    listen 443 ssl;
    http2 on;

    # UDP üzerinde HTTP/3 (QUIC)
    listen 443 quic reuseport;
    http3 on;

    server_name firmaniz.com;

    ssl_certificate     /etc/letsencrypt/live/firmaniz.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/firmaniz.com/privkey.pem;

    # QUIC, TLS 1.3'ü zorunlu kılar
    ssl_protocols TLSv1.2 TLSv1.3;

    # Tarayıcıya "bu adres HTTP/3 de konuşuyor" bilgisini ver
    add_header Alt-Svc 'h3=":443"; ma=86400' always;
}

Değişikliği uygulamadan önce mutlaka söz dizimini test edin, sonra yeniden yükleyin:

nginx -t && systemctl reload nginx

Buradaki en sık hata reuseport parametresidir. Bu parametre aynı adres ve port için yalnızca bir kez yazılabilir. Aynı sunucuda birden çok sanal host varsa ve her birine listen 443 quic reuseport; yazarsanız Nginx duplicate listen options hatasıyla açılmaz. Çözüm basit: reuseport yalnızca ilk sunucu bloğunda kalsın, diğerlerinde listen 443 quic; yeterlidir.

UDP 443'ü Açmayı Unutmayın#

HTTP/3 yapılandırmasının sessizce hiç çalışmamasının bir numaralı sebebi budur: güvenlik duvarınız TCP 443'e izin verir ama UDP 443'e vermez. Site normal açılmaya devam eder — çünkü tarayıcı HTTP/2'ye düşer — ve hiçbir hata mesajı görmezsiniz. Kontrol ve açma komutları şöyle:

# Nginx gerçekten UDP 443'ü dinliyor mu
ss -ulnp | grep :443

# UFW kullanıyorsanız
sudo ufw allow 443/udp
sudo ufw status | grep 443

# firewalld kullanıyorsanız
sudo firewall-cmd --permanent --add-port=443/udp
sudo firewall-cmd --reload

Bunun da ötesinde, sunucunuz bir bulut sağlayıcısının güvenlik grubu (security group) arkasındaysa oradaki kuralı da ayrıca açmanız gerekir; işletim sistemi güvenlik duvarını açmanız tek başına yetmez. Kurumsal ağlarda ise UDP 443'ün dış çıkışta engellendiği durumlar vardır; o ağdaki kullanıcılar HTTP/2 ile devam eder ve bu tamamen normaldir.

Alt-Svc Başlığı ve İlk İstek Meselesi#

Burada anlaşılması gereken önemli bir davranış var: bir tarayıcı sitenize ilk kez bağlandığında HTTP/3 kullanmaz. Çünkü bir adresin HTTP/3 konuştuğunu önceden bilemez; bunu ancak sunucunun gönderdiği Alt-Svc (Alternative Services) başlığından öğrenir. Yani akış şöyle işler:

1. Tarayıcı TCP üzerinden HTTP/2 ile bağlanır ve sayfayı alır.
2. Yanıtta Alt-Svc: h3=":443"; ma=86400 başlığını görür.
3. Bu bilgiyi ma (max-age) süresince, yani 86400 saniye boyunca hatırlar.
4. Sonraki ziyaretlerde doğrudan QUIC ile bağlanmayı dener.

Bu yüzden HTTP/3'ü açtıktan hemen sonra yaptığınız ilk testte tarayıcının h2 göstermesi bir hata değildir; sayfayı bir kez yenilediğinizde h3e geçer. Başlığı always parametresiyle yazmak da önemlidir, aksi halde 304 gibi bazı yanıt kodlarında başlık eklenmez ve öğrenme süreci aksar.

Cloudflare veya Bir CDN Kullanıyorsanız#

Sitenizin önünde Cloudflare gibi bir CDN varsa işiniz çok daha kolay: HTTP/3'ü açmak için sunucunuza hiç dokunmanız gerekmez. Tarayıcı ile CDN arasındaki bacak HTTP/3 konuşurken, CDN ile sunucunuz arasındaki bacak HTTP/2 ya da HTTP/1.1 olarak kalır — ve kullanıcı deneyimini belirleyen bacak zaten birincisidir, çünkü uzun mesafeli ve kayıplı olan odur.

Cloudflare panelinde bu ayar Speed → Optimization → Protocol Optimization altında "HTTP/3 (with QUIC)" anahtarıdır ve ücretsiz planda dahil gelir. Turuncu bulut aktif değilse, yani alan adı yalnızca DNS olarak barındırılıyorsa bu anahtar hiçbir işe yaramaz; trafiğin gerçekten Cloudflare üzerinden geçmesi gerekir. Bu ayrımı turuncu bulut mu gri bulut mu yazısında ayrıntısıyla bulabilirsiniz. Cloudflare'ı DNS ve CDN olarak kurmadıysanız Cloudflare DNS ve CDN rehberi başlangıç noktanız olsun.

Bir CDN katmanının genel olarak ne kazandırdığını, kendi sunucunuzu güçlendirmekle nasıl kıyaslandığını merak ediyorsanız CDN mi daha iyi hosting mi yazısı bu kararı sayısallaştırmanıza yardım eder.

HTTP/3'ün Gerçekten Çalıştığını Doğrulama#

Yapılandırma bittiğinde "açtım" demek yetmez; ölçmek gerekir. En hızlı yöntem tarayıcının geliştirici araçlarıdır: Network sekmesinde sütun başlıklarına sağ tıklayıp Protocol sütununu açın. h3 yazıyorsa HTTP/3 devrededir; h2 yazıyorsa ya Alt-Svc henüz öğrenilmemiştir ya da UDP yolu kapalıdır.

Komut satırından doğrulamak isterseniz HTTP/3 destekli bir curl gerekir:

# curl'ünüz HTTP/3 destekliyor mu
curl --version | grep -o HTTP3

# Destekliyorsa doğrudan HTTP/3 ile iste
curl --http3 -sI https://firmaniz.com | head -n 1
# Beklenen: HTTP/3 200

# Desteklemiyorsa en azından Alt-Svc başlığını kontrol edin
curl -sI https://firmaniz.com | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400

Alt-Svc başlığı görünüyor ama tarayıcı hâlâ h2 diyorsa sıradaki şüpheli neredeyse her zaman UDP 443'tür. Sunucuda ss -ulnp | grep :443 çıktısı boşsa Nginx QUIC soketini hiç açmamıştır; çıktı doluysa sorun ağ tarafındadır.

Sık Yapılan Hatalar#

TLS 1.3 devre dışı bırakılmış olması. QUIC, şifrelemeyi protokolün içine gömer ve yalnızca TLS 1.3 ile çalışır. ssl_protocols satırınızda TLS 1.3 yoksa HTTP/3 hiç kurulmaz. Eski istemciler için TLS 1.2'yi listede tutabilirsiniz ama 1.3 mutlaka olmalı.

Sertifikanın yalnızca bir isim için geçerli olması. QUIC bağlantısı da aynı sertifikayı kullanır; www ve kök alan adı için sertifikanız eksikse HTTP/3 tarafında da aynı hata alınır. Sertifika sorunlarını ayıklarken Cloudflare 525 ve 526 SSL el sıkışma hataları yazısındaki teşhis sırası CDN'siz kurulumlarda da işe yarar.

Yük dengeleyicide UDP'nin unutulması. Önünüzde bir yük dengeleyici varsa TCP 443 için tanımlı kural UDP'yi kapsamaz; ayrı bir dinleyici tanımlamanız gerekir. Aksi halde sunucularınız QUIC konuşmaya hazırdır ama trafik onlara hiç ulaşmaz.

0-RTT'yi düşünmeden açmak. QUIC, daha önce bağlanmış bir istemciye sıfır gidiş-dönüşle veri gönderme imkânı tanır. Hızlıdır ama bu ilk veri tekrar oynatma (replay) saldırısına açıktır. Bu yüzden 0-RTT yalnızca yan etkisi olmayan istekler için uygundur; form gönderimi gibi durum değiştiren isteklerde kullanılmamalıdır. Emin değilseniz varsayılan davranışı değiştirmeyin.

Ölçümü tek bir hız testi aracına bağlamak. Bazı test araçları HTTP/3'ü hiç denemez ve raporlarında protokolü h2 gösterir. GTmetrix ile hız testi gibi araçlar sayfa performansı için değerlidir ama protokol doğrulaması için tarayıcı geliştirici araçları ya da curl --http3 daha güvenilirdir.

Sıkça Sorulan Sorular#

HTTP/3 siteyi ne kadar hızlandırır#

Beklenen kazanç bağlantı kalitesine göre değişir. Kablolu, düşük gecikmeli bir bağlantıda fark genellikle ölçüm gürültüsü seviyesindedir. Buna karşılık paket kaybının olduğu mobil şebekelerde ve sunucuya uzak coğrafyalarda sayfa yükleme süresinde belirgin iyileşme görülür, çünkü tek bir kayıp paket artık diğer isteklerin verisini bekletmez. Trafiğinizin mobil oranı yüksekse kazanç da yüksek olur.

HTTP/3 için ayrı bir SSL sertifikası almam gerekir mi#

Hayır. QUIC, mevcut TLS sertifikanızı aynen kullanır; ek bir sertifika, ek bir ücret ya da farklı bir sertifika tipi gerekmez. Tek şart TLS 1.3'ün etkin olmasıdır, çünkü QUIC şifrelemeyi protokole gömer ve yalnızca 1.3 ile çalışır. Let's Encrypt ile aldığınız ücretsiz bir sertifika bu iş için tamamen yeterlidir.

HTTP/2'yi kapatmalı mıyım#

Kesinlikle hayır. HTTP/3 desteklemeyen istemciler, UDP'nin engellendiği kurumsal ağlar ve bazı eski tarayıcılar hâlâ HTTP/2 ya da HTTP/1.1 kullanır. İkisini birlikte dinlemek doğru yapılandırmadır: listen 443 ssl; ile http2 on; TCP tarafını, listen 443 quic; ile http3 on; UDP tarafını karşılar. HTTP/2'yi kapatırsanız bir kısım ziyaretçi siteye hiç ulaşamaz.

Paylaşımlı hostingte HTTP/3 açabilir miyim#

Paylaşımlı hostingte web sunucusu yapılandırmasına doğrudan erişiminiz olmadığı için bunu kendiniz açamazsınız; sağlayıcının sunucu genelinde etkinleştirmiş olması gerekir. Pratik çözüm, alan adınızı Cloudflare gibi bir CDN üzerinden yayınlamaktır: ziyaretçi ile CDN arasındaki bacak HTTP/3 olur ve kullanıcı deneyimini belirleyen bacak da zaten odur. Kendi yapılandırmanızı yönetmek istiyorsanız root erişimli bir sunucuya geçmeniz gerekir.

HTTP/3'ün açık olup olmadığını nasıl kontrol ederim#

En pratik yöntem tarayıcı geliştirici araçlarında Network sekmesine Protocol sütununu eklemektir; istek satırında h3 görüyorsanız protokol devrededir. İlk ziyarette h2 görmeniz normaldir, sayfayı bir kez yenileyin. Komut satırında curl --http3 -sI https://firmaniz.com ilk satırda HTTP/3 200 dönmelidir; curl'ünüz desteklemiyorsa en azından curl -sI çıktısında alt-svc başlığını arayın.

QUIC ile HTTP/3 aynı şey mi#

Tam olarak aynı şey değil, iç içe iki katman. QUIC bir taşıma protokolüdür ve TCP'nin yerini alır; güvenilirlik, sıralama, tıkanıklık kontrolü ve şifreleme onun sorumluluğundadır. HTTP/3 ise HTTP semantiğinin QUIC üzerinde nasıl taşınacağını tanımlayan uygulama katmanı protokolüdür. Günlük konuşmada ikisi birbirinin yerine kullanılır çünkü pratikte hep birlikte gelirler, ama teknik olarak QUIC alt katman, HTTP/3 üst katmandır.

Kapanış#

HTTP/3, sihirli bir hızlandırıcı değil; TCP'nin yapısal bir sınırını ortadan kaldıran bir taşıma katmanı değişikliği. Kazancı en çok mobil ve kayıplı bağlantılarda görünür, iyi bağlantılarda ise fark küçüktür ama zarar da yoktur. Aklınızda kalması gereken dört pratik alışkanlık şunlar: HTTP/2'yi kapatmadan HTTP/3'ü yanına ekleyin, Alt-Svc başlığını always ile gönderin, UDP 443'ü hem sunucu güvenlik duvarında hem bulut güvenlik grubunda açın ve sonucu tarayıcı geliştirici araçlarındaki Protocol sütunundan doğrulayın. Protokolü açmadan önce sunucu yanıt sürenizi düzeltmeyi de ihmal etmeyin; yavaş bir arka ucu hiçbir protokol kurtarmaz.

Kendi Nginx yapılandırmanızı yönetmek ve HTTP/3'ü uçtan uca kendiniz kurmak isterseniz tam root erişimi sunan VDS ve sanal sunucu paketlerimiz bu iş için uygundur. Yapılandırmayla uğraşmak istemiyorsanız sunucu yönetimi hizmetimiz protokol, TLS ve güvenlik duvarı ayarlarını sizin yerinize üstlenir; sertifika tarafında ise SSL sayfamızdan TLS 1.3 destekli seçeneklere bakabilirsiniz.