HTTP/3 ve QUIC Nedir? Gerçek Hız Kazancı Nerede Başlar

Metroda telefonunuzda sinyal çubukları dolu görünür, sayfa yarıya kadar açılır ve orada asılı kalır. Yazılar gelmiştir, görsellerin yeri boştur, döner ikon çalışmaya devam eder. Bant genişliğiniz yeterlidir, sunucu ayaktadır, hat kopmamıştır. Bu tablonun arkasında çoğu zaman tek bir kayıp veri paketi vardır ve o paket, kendisinden sonra gelen her şeyi sırada bekletir.

HTTP/3'ün çözmeye çalıştığı problem tam olarak budur. HTTP/3, web trafiğinin TCP yerine QUIC adlı taşıma protokolü üzerinden gitmesidir. QUIC ise UDP üzerine kurulmuş, şifrelemesi varsayılan olarak açık, aynı bağlantı içinde birbirinden bağımsız veri akışları taşıyan bir taşıma protokolüdür. İkisi de IETF standardı olarak tanımlanmıştır: QUIC için RFC 9000, HTTP/3 için RFC 9114.

Kötü sinyalde sayfanın yarıda kalmasının asıl sebebi

TCP, veriyi sıralı tek bir bayt akışı olarak teslim eder. Bu tasarımın bedeli şudur: akışın ortasındaki bir paket kaybolduğunda, ondan sonra gelen paketler hedefe ulaşmış olsa bile uygulamaya teslim edilmez. Kayıp paket yeniden gönderilip yerine oturana kadar sıra bekler. Buna sıra başı tıkanması (head-of-line blocking) denir.

HTTP/2 bu sorunu kısmen çözdü. Aynı bağlantı üzerinde onlarca isteği paralel taşıyabiliyor, yani HTTP katmanında sıra beklemesini ortadan kaldırıyordu. Ancak HTTP/2 tek bir TCP bağlantısı üzerinde çalışır ve paket kaybı TCP katmanında yaşandığında o bağlantıdaki bütün akışlar birlikte bekler. Sayfanın CSS dosyası ile bir arka plan görselinin parçası aynı boruda gider; görsel paketi düştüğünde CSS de bekler.

QUIC'in yaptığı ayrım burada devreye girer. QUIC birden fazla akışı UDP üzerinde taşır ve paket kaybı tespiti ile yeniden gönderimi her akış için ayrı ayrı yürütür. Bir görselin paketi kaybolduğunda yalnızca o görsel bekler, sayfanın metni ve stil dosyası akmaya devam eder. Fark, kaybın olmadığı temiz bir bağlantıda neredeyse görünmezdir. Fark, paketin gerçekten düştüğü yerde ortaya çıkar: kalabalık bir baz istasyonunda, zayıf otel wifisinde, hareket halindeki bir araçta.

HTTP/1.1'den HTTP/3'e giden yol

Üç sürüm arasındaki farkı tek cümleyle özetlemek gerekirse: HTTP/1.1 aynı anda kaç bağlantı kurabildiğinizle sınırlıydı, HTTP/2 tek bağlantıda paralelliği çözdü ama TCP'ye bağımlı kaldı, HTTP/3 ise taşıma katmanının kendisini değiştirdi.

Metinsel bir protokolden ikili (binary) bir protokole geçiş, başlık sıkıştırması ve çoklama gibi kazanımlar HTTP/2 ile gelmişti. HTTP/3 bunların hiçbirini geri almaz; aynı HTTP anlamını korur, yalnızca o anlamı taşıyan borunun cinsini değiştirir.

QUIC neden TCP yerine UDP üzerine kuruldu

Türkçe kaynaklarda sık tekrarlanan bir yanlış var: "UDP hızlıdır çünkü paketleri doğrulamaz." QUIC için bu açıklama doğru değildir. QUIC güvenilir teslimi, sıralamayı, yeniden gönderimi ve tıkanıklık kontrolünü bırakmaz; bunları kendi içinde yeniden kurar. Yani QUIC üzerinden giden bir sayfa "doğrulama yapılmadığı için" hızlanmaz.

UDP'nin seçilme nedeni başkadır ve iki başlıkta toplanır. Birincisi, TCP'yi değiştirmek pratikte imkansıza yakındır. TCP işletim sistemi çekirdeğinde yaşar ve aradaki güvenlik duvarları, NAT cihazları, operatör ekipmanları onun davranışına göre yazılmıştır. Yeni bir TCP özelliğinin dünyaya yayılması yılları bulur. QUIC ise uygulama seviyesinde çalışır, yani tarayıcı ve sunucu yazılımıyla birlikte güncellenebilir. İkincisi, UDP ince bir datagram katmanıdır ve aradaki cihazlar içeriğine karışmadan geçirme eğilimindedir.

Buna ek olarak QUIC'te şifreleme opsiyonel değildir. Taşıma el sıkışması ile TLS el sıkışması ayrı ayrı yürütülmez, tek bir birleşik süreç halinde yapılır. Bu yapı, protokol kardeşi sayılabilecek diğer aktarım katmanı konularıyla birlikte değerlendirilmelidir; sertifika ve başlık tarafındaki kontrol listesi için SSL, TLS ve HSTS header kontrolü yazısı aynı zeminin devamıdır.

Gerçek kazanç nerede başlar nerede biter

HTTP/3'ün somut olarak üç şey kazandırdığını söyleyebiliriz ve üçünün de sınırı vardır.

Bağlantı kurulumunda daha az gidiş geliş

Klasik kurulumda tarayıcı önce TCP el sıkışmasını tamamlar, sonra TLS el sıkışmasına başlar. QUIC bu ikisini birleştirir, böylece ilk veriye kadar geçen tur sayısı azalır. Daha önce bağlanılmış bir sunucuya dönüşte 0-RTT adı verilen bir kısayol da mümkündür, ancak bu kısayolun bilinen bir maliyeti vardır: 0-RTT ile gönderilen veri tekrar oynatma (replay) saldırısına açıktır ve bu nedenle yan etkisi olabilecek isteklerde kullanılmaması gerekir. Pratikte birçok kurulum 0-RTT'yi ya kapalı tutar ya da yalnızca güvenli isteklerle sınırlar. Yani "HTTP/3 sıfır gecikmeyle açılır" cümlesi gerçeği fazlaca sadeleştirir.

Bu kazancın büyüklüğü doğrudan gecikme süresine bağlıdır. Sunucunuz ziyaretçinize coğrafi olarak yakınsa tasarruf milisaniyelerle ölçülür. Ziyaretçileriniz başka kıtadaysa aynı tasarruf gözle görülür hale gelir.

Paket kaybında bağımsız akışlar

Yukarıda anlatılan asıl kazanç budur ve tam olarak kayıp oranıyla ölçeklenir. Kaybın sıfıra yakın olduğu bir fiber bağlantıda HTTP/2 ile HTTP/3 arasındaki farkı ölçmekte zorlanırsınız. Kaybın yüzdelerle ifade edildiği bir mobil hücrede fark, sayfanın açılmasıyla asılı kalması arasındaki fark olabilir.

Ağ değiştiğinde bağlantının hayatta kalması

QUIC bağlantıları IP adresi ve porta değil, bağlantı kimliğine (connection ID) bağlıdır. Bu sayede bir uç noktanın adresi değiştiğinde bağlantı ayakta kalabilir. Kullanıcı evden çıkıp wifi'dan mobil veriye geçtiğinde TCP bağlantısı kopar ve her şey baştan kurulur; QUIC'te aynı oturum devam edebilir. Uzun süren indirmelerde ve hareket halindeki kullanımda bu davranışın karşılığı vardır.

HTTP/3 bir sıralama faktörü mü

Hayır. HTTP/3 belgelenmiş bir sıralama sinyali değildir ve öyleymiş gibi anlatan içeriklerin dayandığı bir kaynak yoktur.

Google'ın sayfa deneyimi dokümantasyonunda iki şey açıkça yazılıdır: tek bir "sayfa deneyimi sinyali" yoktur ve sıralama sistemlerinin kullandığı ölçüler Core Web Vitals metrikleridir. Bu listede hiçbir protokol sürümü geçmez. Yani Google'ın baktığı şey sitenizin HTTP/3 konuşup konuşmadığı değil, kullanıcının ekranında ne olduğudur.

Bağ tam olarak şuradan kurulur: HTTP/3 gerçek kullanıcılarınızın saha verisinde LCP veya INP değerini iyileştiriyorsa, sayılan şey protokolün adı değil o metriktir. İyileştirmiyorsa arada hiçbir SEO etkisi kalmaz. Bu yüzden doğru sıralama şudur: önce ölçün, sonra açın, sonra tekrar ölçün. Metriğin kendisini hedefleyen çalışma için Core Web Vitals rehberindeki adımlar HTTP/3'ten çok daha belirleyicidir.

Tarama tarafında da benzer bir düzeltme gerekir. Google'ın tarama kapasitesi dokümantasyonu, kapasitenin sunucunun yanıt süresine, gecikmesine ve istikrarına göre yukarı veya aşağı gittiğini söyler. Ölçülen şey yanıt davranışıdır, protokol sürümü değil. HTTP/3 sunucunuzun yanıt sürelerini gerçekten düşürüyorsa dolaylı bir etki doğabilir; tek başına "HTTP/3 açtık, tarama bütçemiz artar" cümlesi savunulabilir değildir.

Sitenizin HTTP/3 kullanıp kullanmadığını nasıl anlarsınız

En hızlı yöntem tarayıcının kendi geliştirici araçlarıdır. Üçüncü parti bir test servisine ihtiyacınız yoktur.

1. Sitenizi Chrome'da açın ve geliştirici araçlarını başlatın.
2. Network (Ağ) sekmesine geçin.
3. İstek tablosunun başlık satırına sağ tıklayın ve Protocol kolonunu görünür yapın.
4. Sayfayı yenileyin ve kolondaki değerlere bakın: h3 HTTP/3, h2 HTTP/2, http/1.1 eski sürüm anlamına gelir.

Burada çoğu kişiyi yanıltan bir ayrıntı var. İlk yüklemede h3 göremeyebilirsiniz ve bu bir arıza değildir. Tarayıcı bir sunucunun HTTP/3 konuştuğunu genellikle önce TCP üzerinden gelen Alt-Svc yanıt başlığından öğrenir. Yani ilk bağlantı HTTP/2 ile kurulur, sunucu "beni QUIC üzerinden de bulabilirsin" der, sonraki ziyaretler HTTP/3'e geçer. Bu yüzden testi sayfayı bir kez yeniledikten sonra yapın.

Sunucu tarafını doğrudan görmek isterseniz yanıt başlıklarında Alt-Svc satırını arayın. Şuna benzer bir değer görmelisiniz:

Alt-Svc: h3=":443"; ma=86400

Nasıl etkinleştirilir

CDN üzerinden: çoğu site için doğru yol

Siteniz bir CDN arkasındaysa HTTP/3 sizin için bir sunucu projesi değil, bir ayar anahtarıdır. Cloudflare örneğinde yol şudur: panele girin, hesabınızı ve alan adınızı seçin, Speed > Settings bölümüne gidin, Protocol Optimization başlığı altındaki HTTP/3 anahtarını açın. Ayar tüm planlarda kullanılabilir ve uç noktada geçerli bir SSL sertifikanızın bulunmasını gerektirir.

Burada gözden kaçan kritik bir sınır var: bu ayar yalnızca kullanıcı ile CDN arasındaki bağlantıyı kapsar. Cloudflare kendi dokümantasyonunda origin sunucuya HTTP/3 ile bağlanmanın desteklenmediğini belirtir. Yani CDN ile kendi sunucunuz arasındaki hat TCP üzerinden yürümeye devam eder. Ziyaretçi deneyimi açısından belirleyici olan kısım zaten ilk bacaktır, ancak "her yerde HTTP/3 var" varsayımıyla hareket etmeyin. CDN katmanının bütününü nasıl kuracağınız ayrı bir konudur ve CDN ve agresif cache ayarları yazısında ele alınmıştır.

Kendi sunucunuzda

Nginx tarafında HTTP/3, ayrı bir modülle gelir ve kullandığınız derlemede bu modülün bulunması gerekir. Yapılandırma iki parçadan oluşur: QUIC dinleyicisini açmak ve tarayıcıya HTTP/3'ün var olduğunu duyurmak.

server {
    # uyumluluk için HTTP/3 ve HTTPS aynı portta tutulur
    listen 443 quic reuseport;
    listen 443 ssl;

    ssl_certificate     /etc/ssl/ornek.com.crt;
    ssl_certificate_key /etc/ssl/ornek.com.key;

    location / {
        # HTTP/3 desteğini tarayıcıya duyurur
        add_header Alt-Svc 'h3=":443"; ma=86400';
    }
}

Paylaşımlı hosting veya hazır panel kullanıyorsanız bu iş çoğunlukla sizde değildir. LiteSpeed tabanlı kurulumlarda HTTP/3 desteği sunucu yazılımıyla birlikte gelir ve genellikle panel üzerinden yönetilir; hosting sağlayıcınıza doğrudan sorabileceğiniz soru şudur: "Sunucumda QUIC dinleyicisi açık mı ve UDP 443 dışarıya kapalı mı?"

Kimsenin atlamaması gereken adım: UDP 443

HTTP/3 kurulumlarının sessizce çalışmamasının en yaygın nedeni budur. HTTPS trafiği alışkanlıkla TCP 443 üzerinden düşünülür ve güvenlik duvarı kuralları da öyle yazılır. QUIC ise UDP üzerinde çalışır. Sunucunuzun güvenlik duvarında UDP 443 açık değilse yapılandırma doğru olsa bile hiçbir tarayıcı HTTP/3'e geçemez, sessizce TCP'de kalır. Kurulumdan sonra ilk kontrol edilecek şey bu kuraldır.

ERR_QUIC_PROTOCOL_ERROR ve QUIC'in engellendiği durumlar

Türkiye'de QUIC ile ilgili arama talebinin en büyük kısmı, protokolü öğrenmek isteyenlerden değil hata ekranıyla karşılaşanlardan gelir. Bu hata mesajı, tarayıcının QUIC üzerinden bağlanmayı denediğini ve bağlantının başarısız olduğunu söyler. Kaynağı çoğu zaman ziyaret edilen site değildir.

Tipik nedenler şunlardır:

• Kurumsal ağ, kampüs ağı veya operatör tarafında UDP 443 trafiğinin filtrelenmesi ya da düşürülmesi.
• Araya giren güvenlik yazılımı, kurumsal proxy veya VPN istemcisinin şifreli trafiği açıp yeniden paketlemesi.
• QUIC'i tam olarak tanımayan bir ara ağ cihazının paketleri bozması.
• Sunucu veya CDN tarafında yarım kalmış bir yapılandırma; örneğin Alt-Svc başlığının HTTP/3'ü duyurduğu ancak dinleyicinin gerçekte erişilebilir olmadığı durumlar.

Hatayı gören bir ziyaretçi için tarayıcıdaki QUIC ayarını kapatmak işe yarayabilir, ancak bunu bir çözüm değil teşhis aracı olarak görmek gerekir. Ayar kapatıldığında sayfa açılıyorsa sorunun QUIC yolunda olduğu anlaşılır; asıl düzeltme aradaki ağda veya sunucudadır.

Site sahibi tarafında bakılacak sıra nettir. Önce hatanın yaygın mı yoksa tek bir ağa mı özgü olduğunu belirleyin: farklı bir bağlantıdan aynı sayfayı açın. Yaygın değilse sorun büyük ihtimalle o kurumun ağındadır ve sizin tarafınızdan kapatılamaz. Yaygınsa Alt-Svc başlığınızı, QUIC dinleyicinizin gerçekten yanıt verip vermediğini ve UDP 443 kuralınızı kontrol edin. Sağlıklı bir kurulumda tarayıcı QUIC'e ulaşamadığında sessizce TCP'ye döner; kullanıcıların düz bir hata ekranı görmesi, bu geri dönüşün bir yerde kırıldığına işaret eder.

Kimin gerçekten önemsemesi gerekir

HTTP/3'ün getirisi her sitede aynı değildir ve bunu dürüstçe söylemek gerekir.

Önceliklendirmeye değer: ziyaretçilerinin büyük bölümü mobil veriden gelen siteler, farklı ülkelere hizmet veren ve yüksek gecikmeli bağlantılarla karşılaşan projeler, sayfa başına çok sayıda kaynak isteği yapan medya ağırlıklı siteler, yüksek trafikli e-ticaret ve haber siteleri. Bu profillerde paket kaybı ve gecikme günlük gerçektir, dolayısıyla QUIC'in çözdüğü problem gerçekten yaşanır.

Öncelik listenizin başında olmamalı: yerel hizmet veren, ziyaretçilerinin çoğu iyi bağlantılardan gelen küçük siteler. Böyle bir sitede LCP değerini bozan şey genellikle protokol değil, 3 MB'lık sıkıştırılmamış bir kapak görseli, gereğinden ağır bir tema, yüklenmeyi geciktiren üçüncü parti scriptler veya paylaşımlı hostingten gelen 1,5 saniyelik ilk yanıt süresidir. HTTP/3 bunların hiçbirini düzeltmez. Bu sorunlar dururken protokol değiştirmek, ölçülebilir bir kazanç üretmeden zaman harcamak olur.

Maliyet tarafında ise ayrım şudur. CDN kullanıyorsanız HTTP/3 açmak tek bir anahtardır, riski düşüktür ve kapatmanız gerekirse aynı kolaylıkla geri alınır; bu durumda açmamak için özel bir sebebiniz yoksa açın. Kendi sunucunuzu yönetiyorsanız bu bir yapılandırma işidir, test gerektirir ve güvenlik duvarı tarafında bozulabilecek şeyler vardır; bu durumda sıraya koymadan önce yukarıdaki profil sorusunu cevaplayın.

Sık sorulan sorular

HTTP/3, HTTP/2'nin yerini tamamen alır mı?

Almaz, yanında çalışır. HTTP/3'ün varlığı zaten TCP üzerinden gelen bir başlıkla duyurulduğu için eski yol açık kalmak zorundadır. QUIC konuşamayan istemciler ve QUIC'in engellendiği ağlar HTTP/2 veya HTTP/1.1 üzerinden hizmet almaya devam eder. Doğru kurgu "geçiş" değil, iki yolun birlikte açık olmasıdır.

HTTP/3 için yeni bir SSL sertifikası almam gerekir mi?

Hayır. QUIC şifreleme için TLS kullanır ve mevcut sertifikanız geçerlidir. Yeni bir sertifika satın almanız gerekmez; yalnızca uç noktada geçerli ve doğru kurulmuş bir sertifikanız olması gerekir.

HTTP/3 açmak siteme zarar verebilir mi?

Doğru kurulmuş bir sistemde tarayıcı QUIC'e ulaşamazsa TCP'ye döner, yani beklenen davranış bozulma değil geri çekilmedir. Pratikte sorun çıkan yerler, yarım yapılandırmalar ve UDP 443'ün filtrelendiği ağlardır. Bu yüzden açtıktan sonra farklı ağlardan birkaç kontrol yapmak, ayarı açık bırakmadan önceki tek makul adımdır.

HTTP/3 açınca Core Web Vitals skorlarım kendiliğinden düzelir mi?

Düzelmesi garanti değildir. Saha verisi ziyaretçilerinizin gerçek bağlantılarından toplanır; kazanç da o bağlantıların ne kadar kayıplı ve gecikmeli olduğuna bağlıdır. Doğru yöntem, açmadan önceki saha verisini not etmek ve birkaç hafta sonra aynı metrikleri karşılaştırmaktır. Fark yoksa sorununuz protokolde değildi ve enerjinizi görsel, script ve sunucu yanıt süresi tarafına aktarmanız gerekir.

Bu hafta yapılabilecekler

Geliştirici araçlarında Protocol kolonunu açıp sitenizin bugün hangi protokolü konuştuğuna bakmak beş dakika sürer. CDN kullanıyorsanız ayarı açmak bir dakika daha alır ve ardından UDP 443 kuralınızı doğrularsınız. Asıl iş bundan sonra başlar: saha verinizde LCP ve INP değerlerinin gerçekten oynayıp oynamadığını izlemek. Protokol değişikliğini bir SEO kazanımı olarak değil, kötü ağlardaki kullanıcılarınıza verdiğiniz bir tolerans payı olarak görmek, beklentiyi de sonucu da doğru yere oturtur.