HTTP/3 neyi hızlandırır? Çoklu Akış (Multiplexing) için Pratik Rehber

Web siteniz HTTP/2 üzerinde, ancak TTFB hâlâ yüksek

Sayfayı açıyorsunuz, yükleyici dönüyor ve iki saniye sonra içerik geliyor. Tarayıcı konsolunu açıp protokolü kontrol ediyorsunuz ve h2 yazdığını görüyorsunuz. Peki sorun nerede? HTTP/2'nin hız demek olduğunu düşünüyorsunuz, ancak gerçek şu ki HTTP/2 yolun sadece yarısını kat etmiş durumda.

HTTP/3 işte bu ikinci yarı. Ama herkes için değil. Bu iki protokol arasındaki fark belirli koşullarda hissedilir ve bu koşulları bilmezseniz, geçiş maliyetini öder ve hiçbir sonuç göremezsiniz. Bu makale tam olarak bunu netleştiriyor: HTTP/3 nerede kazanır, nerede bir fark yaratmaz ve sunucunuzda nasıl etkinleştirilir.

HTTP/2'de çoklu akış (multiplexing) nasıl çalışır ve nerede kırılır

HTTP/1.1 her istek için ayrı bir TCP bağlantısı açardı. Tarayıcılar 6 paralel bağlantı kurmak zorundaydı ve her bağlantı aynı anda tek bir dosyayı aktarıyordu. HTTP/2 bunu çoklu akış ile çözdü: tek bir TCP bağlantısı, birden fazla eşzamanlı akış. Şu resmi hayal edin: içinden aynı anda birçok küçük paketi geçirdiğiniz büyük bir boru.

Bu çözümün bir kırılma noktası var. TCP, paketlerin sırayla ulaşmasını garanti eder. 3 numaralı paket kaybolursa, ulaşmış olan 4, 5 ve 6 numaralı paketler, 3 numaralı paket yeniden gönderilene kadar arabellekte bekler. Şimdi aynı boruda, CSS'inize ait akışın ve hero görseline ait akışın ikisinin de kayıp paketin arkasında beklediğini düşünün. İşte bu head-of-line blocking'dir ve HTTP/2'yi dengesiz ağlarda yavaşlatan tam olarak budur.

Önemli not: Paket kaybı sıfıra yakın olan kararlı ağlarda bu nadiren olur. Veri merkezinde veya kaliteli şehir fiberinde HTTP/2 ve HTTP/3 neredeyse aynı hızdadır. Sorun, kullanıcı zayıf Wi-Fi veya dalgalı mobil ağ ile mobil cihazdan girdiğinde başlar.

İşte burada hata yapıyorlar: Kararlı ağ üzerinde test

Geliştirici HTTP/3'ü sunucuda etkinleştirir, ofis fiberine bağlı dizüstü bilgisayarla test eder ve sonucu "değişiklik yok" olarak görür. Ardından HTTP/3'ün işe yaramadığı sonucuna varır ve devre dışı bırakır. Bu yaygın bir hatadır. Test, zayıf sinyalli bir mobil ağdan veya clumsy ya da tc netem gibi gerçek paket kaybı ve gecikmeyi simüle eden bir ağ simülatörü ile yapılmalıdır. Aşağıdaki komut Linux'ta %5 paket kaybı ve 100ms gecikme ekler:

sudo tc qdisc add dev eth0 root netem loss 5% delay 100ms

Testten sonra kaldırın:

sudo tc qdisc del dev eth0 root

HTTP/3 neyi farklı yapıyor

HTTP/3, TCP üzerinde değil UDP üzerinde çalışır. Altındaki protokol, Google tarafından tasarlanan ve artık RFC 9000 olan QUIC'tir. QUIC, TCP'nin yapamadığı üç temel şeyi yapar:

• Bağlantı düzeyinde head-of-line blocking'in ortadan kaldırılması: QUIC'te her akış bağımsızdır. 1 numaralı akışta bir paket kaybolursa, 2 ve 3 numaralı akışlar beklemeden devam eder.
• İlk bağlantı süresinin azaltılması: TCP, el sıkışma için bir round-trip gerektirir ve TLS de bir round-trip daha ekler. QUIC ikisini tek bir round-trip'te birleştirir. Yeni bağlantılarda bu, bir RTT tasarrufu demektir; oturum sürdürme (session resumption) ile tekrarlanan bağlantılarda bu sayı sıfıra iner.
• Bağlantı kesilmeden IP adresi değişimi: Telefonunuz Wi-Fi'den 4G'ye geçtiğinde, QUIC bağlantısı Connection ID ile devam eder. TCP bunu yapamaz; bağlantı kopar ve yeniden el sıkışmanız gerekir.

Bu üçünün sonucu belirli bir sayıdır: %2 paket kaybı olan bir ağda, sayfa yükleme HTTP/3 ile genellikle HTTP/2'den %15 ila %30 daha hızlıdır. Kararlı bir ağda bu sayı %2 ila %5'e düşer. Bunu Cloudflare ve Fastly raporlarında görürsünüz ve kendi testinizde de görmelisiniz.

HTTP/3 farkı ne zaman hissedilir

Tüm siteler HTTP/3'ten faydalanmaz. Üç koşulun sağlanması gerekir:

1. Kullanıcılarınız mobil ağlar kullanıyor. Analitikleriniz trafiğin %40'ından fazlasının mobil olduğunu gösteriyorsa, HTTP/3 sizin için önemlidir.
2. Sayfanızda 50'den fazla ayrı istek var. Eşzamanlı akış ne kadar çoksa, head-of-line blocking ile karşılaşma olasılığı o kadar yüksektir.
3. Dosyalarınız birden fazla alan adından veya ayrı CDN'lerden sunuluyor. Her ayrı alan adı, ayrı bir TCP bağlantısı ve engelleme için ayrı bir fırsat demektir.

Siteniz 10 istekli basit bir sayfaysa ve kullanıcılarınız şehir fiberinden geliyorsa, HTTP/3 gözle görülür bir fark yaratmaz. Bunu dürüstçe söyleyelim. Etkinleştirme maliyeti düşüktür, ancak mucize beklemeyin.

Doğrudan karşılaştırma: HTTP/2'ye karşı HTTP/3

Bir başka teknik not: QUIC, TLS 1.3'ü dahili olarak kullanır ve daha eski bir sürüme izin vermez. Sunucunuzda TLS 1.2 varsa, HTTP/3 çalışmaz. Önce TLS 1.3'ü etkinleştirin.

NGINX üzerinde HTTP/3 etkinleştirme

1.25.0 sürümünden itibaren NGINX, HTTP/3 için resmi destek sunar. Dağıtımınız eski bir sürüme sahipse, resmi NGINX deposunu kullanmalısınız. Adımlar şu şekildedir:

# server bloğunuza şu satırları ekleyin
listen 443 quic reuseport;
listen 443 ssl;
http2 on;
ssl_protocols TLSv1.3;
add_header Alt-Svc 'h3=":443"; ma=86400' always;

Alt-Svc satırı tarayıcıya HTTP/3'ün kullanılabilir olduğunu söyler. Bu başlık olmadan, tarayıcı sunucu QUIC'i desteklese bile ona yönelmez. Ayarları uyguladıktan sonra şu komutla test edin:

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

Çıktı alt-svc: h3=":443" içermelidir. --http3 is experimental hatası görürseniz, curl sürümünüzü yükseltin. 8.0 ve üzeri sürümler tam destek sunar.

UDP hakkında önemli bir not: Bazı güvenlik duvarları ve veri merkezleri 443/UDP portunu kapalı tutar. Etkinleştirmeden önce açık olduğundan emin olun:

nc -u -vz your-server-ip 443

Port kapalıysa, tarayıcı otomatik olarak HTTP/2'ye döner, ancak kullanıcılarınız ek bir RTT yaşar çünkü tarayıcı önce QUIC denemesini yapar ve zaman aşımından sonra TCP'ye döner. Bu senaryo, HTTP/3'ün olmamasından daha kötüdür.

HTTP/3'ü ne zaman etkinleştirmemeli

HTTP/3 etkinleştirmeyi önermediğim bir durum var: Altyapınız QUIC'i iletmeyen eski bir yük dengeleyici kullanıyorsa. Bu durumda, UDP trafiği yük dengeleyiciye ulaşır ve hiçbir yanıt alamaz. Tarayıcı birkaç saniye sonra TCP'ye döner ve kullanıcınız normalden daha fazla gecikme yaşar.

Ara çözüm: Alt-Svc başlığını ma=86400 değeriyle ayarlayın ve 24 saat sonra günlüklerde bir hata görmezseniz kalıcı hale getirin. Bu güvenli bir kademeli geçiştir.

Ayrıca, NGINX kontrolüne sahip olmadığınız paylaşımlı barındırma hizmetleri kullanıyorsanız, HTTP/3 genellikle mevcut değildir. Bu durumda, web sunucusu ayarlarına tam erişim sağlayan bir İran sanal sunucusuna yükseltmek ilk pratik adımdır. Sunucu yapılandırmasına erişim olmadan, HTTP/3 tartışması tamamen teorik kalır.

HTTP/3'ün SEO ve Core Web Vitals üzerindeki etkisi

Google resmi olarak HTTP/3'ün bir sıralama sinyali olmadığını açıkladı. Ancak bu, etkisiz olduğu anlamına gelmez. Core Web Vitals'ın ana metriği olan LCP (Largest Contentful Paint), doğrudan sayfadaki en büyük öğenin teslim hızına bağlıdır. Bu öğe ayrı bir akıştan sunuluyorsa ve başka bir akış paket kaybettişse, LCP'niz yükselir. HTTP/3 bu bağımlılığı keser.

Pratikte, HTTP/3'e geçen siteler LCP'de %5 ila %15 iyileşme bildirmektedir. Bu sayı, mobil sıralamayı dolaylı olarak etkileyecek düzeydedir, çünkü Google kullanıcı etkileşimini sinyal olarak kullanır ve daha hızlı kullanıcı daha iyi etkileşim sağlar.

Ölçüm ve izleme araçları

Etkinleştirdikten sonra farkı ölçmelisiniz. Üç kullanışlı araç:

• KeyCDN'den HTTP/3 Check: Site adresinizi alan ve HTTP/3'ün etkin olup olmadığını söyleyen basit bir sayfa.
• WebPageTest: Test ayarlarında HTTP/3 seçeneğini seçin ve sonucu normal durumla karşılaştırın.
• Chrome DevTools: Network sekmesinde Protocol sütununu etkinleştirin. h3 değeri, isteğin QUIC üzerinden gittiği anlamına gelir.

Sürekli izleme için NGINX stub_status'te quic_connections metriğini etkinleştirin. Bu sayı sıfır kalırsa, tarayıcılar HTTP/3'e bağlanmıyor demektir ve sorun Alt-Svc başlığında veya güvenlik duvarındadır.

Sık sorulan sorular

HTTP/3 tüm tarayıcılarda çalışır mı?

Hayır. Safari, 16.4 sürümünden itibaren HTTP/3'ü destekler. Eski tarayıcılar otomatik olarak HTTP/2'ye döner, bu nedenle eski tarayıcılı kullanıcılar için endişelenmeyin. Önemli olan, modern tarayıcıların HTTP/3'ün varlığını fark etmesi için Alt-Svc başlığını mutlaka eklemenizdir.

HTTP/3, HTTP/2'den daha mı az güvenli?

Hayır. QUIC zorunlu olarak TLS 1.3 kullanır ve TLS 1.2 veya altına izin vermez. Pratikte HTTP/3, en zayıf TLS sürümünü ortadan kaldırdığı için HTTP/2'den daha güvenlidir. Tek güvenlik endişesi, bazı güvenlik duvarlarının düzgün şekilde incelemediği UDP trafiğidir.

Sitemin şu anda HTTP/3 üzerinde olduğunu nasıl anlarım?

En kolay yol: Chrome konsolunu açın (F12), Network sekmesine gidin, tablo başlığına sağ tıklayın ve Protocol seçeneğini etkinleştirin. h3 değerini görüyorsanız, siteniz HTTP/3 üzerinden sunuluyor demektir. h2 görüyorsanız, hâlâ HTTP/2 üzerindesiniz.

HTTP/3 daha fazla bant genişliği mi tüketir?

Evet, yaklaşık %5 ila %10 daha fazla. QUIC, TCP'den daha büyük başlıklara sahiptir ve her akış için ayrı onay (acknowledgment) paketleri gönderir. Bant genişliğiniz sınırlıysa ve trafik maliyeti sizin için önemliyse, bu sayıyı hesaplamalarınıza dahil edin. Sınırsız planlarda bu fark ihmal edilebilir düzeydedir.