HTTP/3 (QUIC) Nedir ve API'lar İçin Önemi

HTTP/3 ve API'ler: QUIC ile pratik farklar

API'nizin gönderdiği her HTTP isteği, çoğu geliştiricinin nadiren düşündüğü bir taşıma katmanı üzerinden ilerler. 25 yıl boyunca bu katman TCP'ydi. Google, TCP'nin gelişmesini beklemek yerine UDP üzerine QUIC'i kurdu; IETF de bu protokolü standartlaştırdı. HTTP/3, QUIC üzerinde çalışan HTTP sürümüdür.

Apidog'u bugün deneyin

Bu değişiklik yalnızca altyapı ayrıntısı değildir. API'nizin ne kadar hızlı bağlandığını, değişken mobil ağlarda nasıl davrandığını ve paralel isteklerin aynı bağlantıyı nasıl paylaştığını etkiler. API tasarlıyor veya işletiyorsanız, neyin değiştiğini, neyin aynı kaldığını ve uç noktalarınızın hangi protokolü kullandığını doğrulayabilmelisiniz.

Değişmeyen kısım şudur: istekleriniz, yanıtlarınız, durum kodlarınız ve JSON gövdeleriniz HTTP/1.1, HTTP/2 ve HTTP/3 üzerinde aynı kalır. Apidog gibi araçlar API katmanını test eder ve hata ayıklar. Bu nedenle doğruladığınız uç nokta davranışı, alttaki taşıma sürümünden bağımsız olarak geçerlidir. HTTP/2 hakkında temel bilgi için HTTP/2 nedir ve HTTP/2 API'leri nasıl test edilir? yazımıza da bakabilirsiniz.

QUIC protokolü nedir?

QUIC, RFC 9000'de standartlaştırılmış bir taşıma protokolüdür. TCP yerine UDP üzerinde çalışır ve TCP'nin sunduğu güvenilirlik, sıralama ve tıkanıklık kontrolünü kullanıcı alanında yeniden uygular. Şifreleme ise ilk paketten itibaren protokolün parçasıdır.

QUIC'i tanımlayan dört karar vardır:

• UDP üzerinde çalışır. TCP, işletim sistemi çekirdeklerine ve internet üzerindeki middlebox'lara gömülüdür. UDP ise daha ince bir katman olduğundan QUIC, güvenilirlik özelliklerini kendi içinde sunabilir ve iyileştirmeleri işletim sistemi yerine kütüphane güncellemeleriyle dağıtabilir.
• TLS 1.3 entegredir. TCP'de önce TCP, ardından ayrı bir TLS el sıkışması yapılır. QUIC bu süreçleri birleştirir. Şifresiz QUIC yoktur.
• Akışlar bağımsızdır. Bir QUIC bağlantısı birden fazla akış taşıyabilir. Kayıp paket yalnızca ait olduğu akışı etkiler.
• Bağlantılar ağ değişikliklerine dayanıklıdır. TCP bağlantıları IP adresi ve bağlantı noktasıyla tanımlanır. QUIC ise bağlantı kimliği kullanır. Böylece istemci Wi-Fi'dan 5G'ye geçerken aynı mantıksal bağlantıyı sürdürebilir; yeni bir el sıkışma gerekmez.

HTTP/3, RFC 9114'te tanımlandığı üzere HTTP semantiğini QUIC akışlarına eşler. Yöntemler, başlıklar ve durum kodları aynıdır; değişen kablo formatı ve taşıma katmanıdır.

HTTP/3 ve HTTP/2: pratik farklar

HTTP/2, HTTP/1.1'e çoklama (multiplexing) özelliğini getirdi. Böylece birçok istek tek bir TCP bağlantısını paylaşabildi. Ancak TCP'nin sıralı bayt akışı, HTTP/2'nin çözemediği bir sorun oluşturdu.

Bir paket kaybolduğunda TCP, yeniden iletim gelene kadar sonraki tüm baytları bekletir. Bu baytlar farklı HTTP/2 akışlarına ait olsa bile bağlantıdaki tüm akışlar durur. Örneğin tek bir kayıp paket, aynı bağlantıda çoklanan 20 isteği etkileyebilir. Buna taşıma katmanı baş-ucu engellemesi (HOL blocking) denir.

HTTP/3'te her istek kendi QUIC akışına eşlenir. Akış 5'teki bir paket kaybolduğunda 6–24 arasındaki akışlar devam edebilir. Çoklama, HTTP/2'de hedeflenen bağımsızlığa bu şekilde yaklaşır.

Özellik	HTTP/2 (TCP + TLS 1.3)	HTTP/3 (QUIC)
Yeni bağlantı	2 gidiş-dönüş (TCP + TLS)	1 gidiş-dönüş
Yeniden başlatılan bağlantı	1 gidiş-dönüş	0 gidiş-dönüş (0-RTT)
Kayıp paketin etkisi	Tüm akışları engeller	Yalnızca bir akışı engeller
Wi-Fi'dan 5G'ye geçiş	Bağlantı kesilir, yeniden bağlanılır	Bağlantı taşınır ve devam eder
Şifreleme	Ayrı katman, teorik olarak isteğe bağlı	Entegre ve zorunlu TLS 1.3

0-RTT uyarısı

Daha önce görülen bir sunucuya yeniden bağlanan istemci, el sıkışma tamamlanmadan uygulama verisi gönderebilir. Bu, gecikmeyi azaltır; ancak 0-RTT verisi ele geçirilip yeniden oynatılabilir.

Bu yüzden sunucular 0-RTT üzerinden yalnızca idempotent istekleri kabul etmelidir:

• Yeniden oynatılan GET genellikle zararsızdır.
• Yeniden oynatılan ve ödeme alan bir POST tehlikelidir.

Kenar ağınızda 0-RTT'yi etkinleştiriyorsanız idempotent olmayan çağrıları hariç tutun veya CDN'inizin bunu doğru şekilde yönettiğini doğrulayın.

HTTP/3 API'leriniz için ne ifade ediyor?

HTTP/3 ancak ölçülebilir bir problemi çözdüğünde önemlidir. API trafiği açısından başlıca etkileri şunlardır.

Daha düşük bağlantı kurulum maliyeti

60 ms RTT'ye sahip tipik bir mobil istemci, ilk API isteği gönderilmeden önce TCP + TLS kurulumu için yaklaşık 120 ms harcayabilir. HTTP/3 bu süreyi yaklaşık 60 ms'ye, yeniden bağlanmalarda ise neredeyse sıfıra indirebilir.

Bu fark özellikle şu senaryolarda önemlidir:

• Soğuk başlangıçlar
• Arka plan uyanmaları
• Kısa ömürlü oturumlar
• Sık sık yeni bağlantı açan mobil uygulamalar

Sunucudan sunucuya entegrasyonlarda sıcak bağlantı havuzu kullanılıyorsa el sıkışma maliyeti zaten küçük olduğundan farkı görmeyebilirsiniz.

Mobil ağ geçişlerinde daha az kopma

Bir kullanıcı Wi-Fi üzerinden istek başlatıp hücresel ağa geçtiğinde TCP bağlantısı genellikle kesilir. İstemcinin yeniden deneme mantığı tam bir bağlantı kurulumu başlatır.

QUIC, bağlantıyı bağlantı kimliğiyle takip ettiği için cihaz yeni ağa geçtiğinde aynı mantıksal bağlantıyı sürdürebilir. Sonuç olarak:

• Daha az zaman aşımı hatası
• Daha az yarım kalmış yazma işlemi
• Daha az istemci tarafı yeniden deneme

Paket kaybında bağımsız çoklama

HOL düzeltmesi, bir istemcinin birçok isteği paralel gönderdiği durumlarda önemlidir:

• Birden fazla bileşeni güncelleyen panolar
• Toplu güncellemeler gönderen senkronizasyon motorları
• Aynı anda yüklenen REST kaynakları

Temiz bir ağda HTTP/2 ve HTTP/3 benzer performans gösterir. Ancak %1–2 paket kaybı olan konferans Wi-Fi'ı veya metro hücresel ağı gibi ortamlarda HTTP/3 paralel istekleri bağımsız tutarken HTTP/2 istekleri birlikte duraklatabilir.

gRPC çoğunlukla HTTP/2'de kalıyor

gRPC ve HTTP/2 tasarım gereği HTTP/2 çerçeveleme ve kuyruklarına dayanır. gRPC ekosisteminde henüz yaygın bir HTTP/3 eşlemesi bulunmuyor; Go, Java, Python ve Node.js uygulamaları bunu genel olarak sunmuyor.

.NET Kestrel, HTTP/3 üzerinden gRPC için deneysel destek sağlayabilir. Yine de gRPC ve HTTP/2'ye dayanan dahili API'ler için HTTP/3 geçişi şu an öncelikli bir iş değildir.

Akış ve gerçek zamanlı trafik

Server-Sent Events (SSE), uzun ömürlü bir HTTP yanıtı olduğu için HTTP/3 üzerinde değişmeden çalışır.

WebSocket ve HTTP karşılaştırması daha karmaşıktır. WebSocket yükseltmesi TCP için tasarlanmıştır. HTTP/3 karşılığı olan RFC 9220 ve gelişmekte olan WebTransport API'si henüz yeterli desteğe sahip değildir. Bu nedenle gerçek zamanlı bir özellik için WebSocket ile düz HTTP arasında karar verirken HTTP/3 kullanılabilirliği henüz belirleyici olmamalıdır.

HTTP/3 ne zaman yardımcı olmaz?

Çoğu API gecikmesinin nedeni taşıma protokolü değildir. Uç noktanız dizinlenmemiş bir veritabanı sorgusu nedeniyle 400 ms sürüyorsa HTTP/3 yalnızca yanıtın size yaklaşık 60 ms daha erken ulaşmasını sağlar.

Öncelikle şu alanları iyileştirin:

• Veritabanı indeksleri
• Önbellekleme
• Yük tasarımı
• N+1 sorguları
• Bağlantı yeniden kullanımı
• API performans testi

HTTP/3 özellikle şu koşullarda öne çıkar:

• Yüksek gecikmeli bağlantılar
• Paket kaybı yaşanan ağlar
• Oturum sırasında ağ değiştiren mobil istemciler
• Çok sayıda kısa bağlantı

Aynı bölgedeki sunucuların güvenilir ağlar üzerinden tükettiği tipik bir JSON API'de fark kıyaslamalarda ölçülebilir, ancak kullanıcı tarafından fark edilmeyebilir.

İki pratik sınırlamayı da unutmayın:

1. UDP 443 bazı kurumsal ağlarda engellenebilir. İstemciler genellikle otomatik olarak HTTP/2'ye geri döner.
2. QUIC'in kullanıcı alanındaki şifreleme işlemleri, ayarlanmış çekirdek TCP'ye kıyasla bağlantı başına daha fazla sunucu CPU'su tüketebilir.

Bugün HTTP/3 kimler tarafından destekleniyor?

• Tarayıcılar: Chrome, Edge, Firefox ve Safari'de HTTP/3 varsayılan olarak etkindir.
• CDN'ler ve edge platformları: Cloudflare, Fastly, Akamai ve CloudFront destekler. Cloudflare'ın HTTP/3 dokümantasyonu pratik bir başlangıç noktasıdır.
• Sunucular: Nginx 1.25 ile listen 443 quic; kullanarak deneysel HTTP/3 desteği sunar. Caddy'de varsayılan olarak etkindir. LiteSpeed ve HAProxy de destekler. Apache httpd desteklemez.
• Çalışma zamanları: Node.js'in kararlı, yerleşik HTTP/3 sunucu desteği yoktur. Bu nedenle HTTP/3'ü CDN veya yük dengeleyicide sonlandırmak yaygın bir yaklaşımdır.
• curl: HTTP/3 destekli bir TLS yığınına karşı derlendiğinde --http3 seçeneğini destekler. Derlemenizin HTTP/3 içerip içermediğini curl HTTP/3 belgelerinden kontrol edin.

Çoğu ekip için uygulanabilir mimari şudur:

İstemci ──HTTP/3──> CDN / Edge ──HTTP/2 veya HTTP/1.1──> Kaynak sunucu

API'nizin HTTP/3 sunup sunmadığını kontrol etme

HTTP/3 keşfi genellikle Alt-Svc yanıt başlığıyla yapılır. Sunucu, ilk HTTP/2 isteğine şu başlıkla yanıt verebilir:

alt-svc: h3=":443"; ma=86400

Bu başlık istemciye, aynı hizmetin UDP 443 üzerinden 24 saat boyunca HTTP/3 ile kullanılabileceğini bildirir.

curl ile keşif

curl -sI https://www.cloudflare.com | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400

İsteği doğrudan HTTP/3 üzerinden göndermek için HTTP/3 destekli bir curl derlemesi gerekir:

curl --http3 -I https://cloudflare-quic.com
# HTTP/3 200

Durum satırının HTTP/3 olduğunu görmelisiniz.

Chrome DevTools ile kontrol

1. Chrome Geliştirici Araçları'nı açın.
2. Network sekmesine geçin.
3. Sütun başlığına sağ tıklayın.
4. Protocol sütununu etkinleştirin.
5. API çağrılarının yanında h3 değerini arayın.

Üretimde anlaşılan protokolü erişim günlüklerine ekleyin. h2 ve h3 trafiğini ayırmak, istemcilerinizin HTTP/3 avantajlarından ne kadar yararlandığını gösterir.

Taşıma protokolünü doğruladıktan sonra API davranışını da doğrulayın. Aynı uç noktaları Apidog ile test edin; durum kodlarını, yanıt şemalarını ve gecikme bütçelerini karşılaştırın. Apidog'u ücretsiz indirin ve HTTP/3'ü edge ağınızda etkinleştirmeden önce ve sonra aynı test paketini çalıştırın.

SSS

HTTP/3, HTTP/2'den daha hızlı mı?

Temiz ve düşük gecikmeli ağlarda fark genellikle küçüktür. Kayıplı veya yüksek gecikmeli ağlarda HTTP/3 daha belirgin avantaj sağlar; bir el sıkışma gidiş-dönüşünü azaltır ve tek bir kayıp paket tüm çoklanmış istekleri durdurmaz.

Kendi trafik profilinizle ölçüm yapmadan performans artışı varsaymayın. HTTP/2 hâlâ güçlü bir seçenektir. HTTP/2 bağlantılarında sorun yaşıyorsanız neden çoğu zaman protokol değil, SSLV3_ALERT_HANDSHAKE_FAILURE gibi TLS katmanı sorunlarıdır.

HTTP/3 TCP kullanır mı?

Hayır. HTTP/3, genellikle UDP 443 üzerinde çalışan QUIC'i kullanır. QUIC, TCP'nin güvenilirlik, sıralama ve tıkanıklık kontrolü özelliklerini akış başına ve kullanıcı alanında yeniden uygular.

UDP 443 engellenirse istemciler genellikle TCP üzerinden HTTP/2'ye geri döner.

HTTP/3 için API kodumu değiştirmem gerekir mi?

Neredeyse hiç. HTTP semantiği aynı kalır:

• Yöntemler
• Başlıklar
• Durum kodları
• İstek ve yanıt gövdeleri

Değişiklik çoğunlukla CDN, yük dengeleyici veya sunucu yapılandırmasındadır. Ayrıca 0-RTT erken verilerinin yalnızca idempotent isteklere izin verdiğinden emin olun.

HTTP/3 üzerinden gRPC kullanabilir miyim?

Şimdilik çoğunlukla hayır. gRPC'nin kablo formatı HTTP/2'ye bağlıdır ve ana akım gRPC kütüphaneleri HTTP/3 taşımasını yaygın olarak sunmaz. .NET deneysel destek sağlar.

gRPC hizmetlerini HTTP/2'de tutun. HTTP/3'ü önce genel, tarayıcıya yönelik ve mobil istemcilerin kullandığı REST uç noktalarında değerlendirin.