API'nizin sunduğu her HTTP isteği, çoğu geliştiricinin hiç düşünmediği bir taşıma katmanı üzerinde hareket eder. 25 yıl boyunca yanıt TCP idi. Sonra Google, TCP'nin iyileşmesini beklemekten sıkıldı, UDP üzerine QUIC protokolünü kurdu ve IETF bunu bir standarda dönüştürdü. HTTP/3, üzerinde çalışmak üzere oluşturulmuş HTTP sürümüdür.
Bu bir tesisat gibi geliyor. Çoğunlukla öyle. Ancak bu tesisat, API'nizin ne kadar hızlı bağlandığını, değişken mobil ağlarda nasıl davrandığını ve paralel isteklerin bir bağlantıyı nasıl paylaştığını değiştirir. API'ler tasarlıyor veya işletiyorsanız, neyin değiştiğini, neyin değişmediğini ve kendi uç noktalarınızın bugün ne konuştuğunu nasıl kontrol edeceğinizi bilmelisiniz.
Tüm bunlarda tek bir şey sabit kalır: istekleriniz, yanıtlarınız, durum kodlarınız ve JSON yükleriniz HTTP/1.1, HTTP/2 ve HTTP/3 üzerinde aynı görünür. Apidog gibi araçlar API katmanında test ve hata ayıklama yapar, bu nedenle bir uç noktanın davranışı hakkında doğruladığınız her şey, altyapınızın altında hangi taşıma sürümünü kullandığına bakılmaksızın geçerliliğini korur. Daha önce HTTP/2'nin ne olduğu ve HTTP/2 API'lerinin nasıl test edileceği hakkındaki açıklamalarımızı okuduysanız, bu makale kaldığı yerden devam ediyor.
QUIC protokolü nedir?
QUIC, RFC 9000'de standartlaştırılmış bir taşıma protokolüdür. TCP yerine UDP üzerinden çalışır ve TCP'nin sağladığı özellikleri (güvenilirlik, sıralama, tıkanıklık kontrolü) kullanıcı alanında, akış başına, ilk paketten itibaren şifreleme ile yeniden oluşturur.
Dört tasarım kararı onu tanımlar:
UDP üzerinde çalışır. TCP, işletim sistemi çekirdeklerinde ve internetteki ara cihazlarda (middlebox) uygulanmıştır, bu da evrimini neredeyse imkansız hale getirir. UDP, teslimat garantisi olmayan ince bir zarftır, bu nedenle QUIC kendi güvenilirlik katmanını üstüne kurar ve işletim sistemi yükseltmeleri yerine kütüphane güncellemeleri olarak iyileştirmeler sunabilir.
TLS 1.3 entegredir, sonradan eklenmez. TCP ile önce bir TCP el sıkışmasını, ardından üstüne ayrı bir TLS el sıkışmasını tamamlarsınız. QUIC bunları birleştirir. Kriptografik kurulum, taşıma el sıkışmasının içinde gerçekleşir, böylece tek bir gidiş-dönüşten sonra yeni güvenli bir bağlantı hazır olur. Şifresiz QUIC diye bir şey yoktur.
Akışlar bağımsızdır. Bir QUIC bağlantısı birçok akış taşır ve her biri bağımsız olarak teslim edilir. Kayıp bir paket yalnızca ait olduğu akışı durdurur. Bu, birazdan değineceğimiz TCP'nin baş-ucu engelleme sorununa bir çözümdür.
Bağlantılar ağ değişikliklerinden etkilenmez. TCP, bir bağlantıyı IP adresi ve bağlantı noktasıyla tanımlar. Bunlardan herhangi birini değiştirdiğinizde (Wi-Fi menzilinden çıktığınızda, 5G'ye geçtiğinizde) bağlantı kesilir. QUIC ise bağlantıları bir bağlantı kimliğiyle tanımlar, böylece bir istemci yeni bir ağa geçebilir ve aynı mantıksal bağlantıyı canlı tutabilir. Yeniden bağlanma, yeni el sıkışması yok.
HTTP/3, RFC 9114'te tanımlandığı gibi, HTTP semantiğinin QUIC akışlarına haritalanmasıdır. Aynı yöntemler, aynı başlıklar, aynı durum kodları. Farklı kablo formatı, farklı taşıma.
HTTP/3 vs HTTP/2: pratikte ne değişti
HTTP/2, HTTP/1.1'e göre büyük bir adımdı. Çoklama (multiplexing) özelliğini tanıttı, böylece birçok istek, kuyrukta beklemek veya altı paralel soket açmak yerine tek bir TCP bağlantısını paylaşabiliyordu. Ancak altında TCP'yi korudu ve bu da HTTP/2'nin kendi başına çözemeyeceği bir sorun yarattı.
TCP, tek bir bayt akışının sıralı teslimatını garanti eder. Bir paket kaybolduğunda, TCP yeniden iletim gelene kadar ondan sonraki her baytı bekletir, hatta tamamen ilgisiz HTTP/2 akışlarına ait baytları bile. Kayıp bir paket, bağlantı üzerinde çoklanan tüm 20 isteği dondurur. Bu, taşıma katmanı baş-ucu engellemesidir ve kayıplı bir ağda, HTTP/2'yi birden fazla bağlantıya sahip HTTP/1.1'den daha yavaş hale getirebilir.
HTTP/3, paylaşılan bayt akışını ortadan kaldırır. Her istek, kendi teslimat sıralamasıyla kendi QUIC akışına eşlenir. Akış 5'i taşıyan bir paketi kaybederseniz, 6'dan 24'e kadar olan akışlar akmaya devam eder. Çoklama (multiplexing) nihayet HTTP/2 diyagramlarının her zaman iddia ettiği gibi çalışır.
El sıkışma matematiği de değişti:
| HTTP/2 (TCP+TLS 1.3 Üzerinden) | HTTP/3 (QUIC Üzerinden) | |
|---|---|---|
| Yeni bağlantı kurulumu | 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 paket etkisi | Tüm akışları engeller | Bir akışı engeller |
| Ağ değişikliği (Wi-Fi'dan 5G'ye) | Bağlantı kesilir, tam yeniden bağlanma | Bağlantı taşınır, devam eder |
| Şifreleme | Teoride isteğe bağlı, ayrı katman | Zorunlu, entegre TLS 1.3 |
0-RTT satırı bir uyarıyı hak ediyor. Bir istemci, daha önce gördüğü bir sunucuya yeniden bağlandığında, QUIC, el sıkışması tamamlanmadan önce ilk pakette uygulama verilerini göndermesine izin verir. Gecikme için harika. Ancak 0-RTT verileri bir saldırgan tarafından ele geçirilip tekrar oynatılabilir, bu nedenle sunucular 0-RTT'de yalnızca idempotent istekleri kabul etmelidir. Tekrar oynatılan bir GET zararsızdır. Kredi kartı tahsil eden tekrar oynatılan bir POST ise değildir. Kenar ağınızda 0-RTT'yi etkinleştirirseniz, idempotent olmayan API çağrılarının hariç tutulduğundan emin olun veya CDN'inizin bunu sizin için yaptığını doğrulayın.
HTTP/3'ün API'larınız için anlamı
Protokol yükseltmeleri yalnızca ölçebileceğiniz bir şeyi değiştirirse önemlidir. İşte HTTP/3'ün API trafiği için neyi değiştirdiği ve neyi değiştirmediği.
Bağlantı kurulumu ucuzlar
60 ms RTT bağlantısı olan tipik bir mobil istemci, ilk API isteği cihazdan ayrılmadan önce TCP+TLS kurulumuna yaklaşık 120 ms harcar. HTTP/3 bunu yaklaşık 60 ms'ye, yeniden başlatmada ise neredeyse sıfıra indirir. Sık sık yeni bağlantılar açan (soğuk başlangıçlar, arka plan uyanmaları, kısa süreli oturumlar) bir mobil uygulamadan çağrılan bir API için, tasarruf bu ilk isteklerin her birine yansır. Sıcak bir bağlantı havuzu tutan sunucudan sunucuya entegrasyon için, el sıkışma önemsiz hale gelir ve hiçbir şey fark etmezsiniz.
Mobil istemciler bağlantı kesmeyi bırakır
Bağlantı taşıma, API ekipleri için gizli kalmış bir özelliktir. Bir kullanıcı ofis Wi-Fi'ında bir istek başlatır, asansöre yürür ve telefon hücresel ağa geçer. TCP üzerinden, bu devam eden istek başarısız olur ve istemci tarafı yeniden deneme mantığınız (yeniden deneme mantığınız var, değil mi?) tam bir yeniden bağlantı ile devreye girer. QUIC üzerinden, bağlantı cihazı yeni ağa takip eder. İstemci günlüklerinizde daha az zaman aşımı hatası, üzerinde düşünülmesi gereken daha az yarı tamamlanmış yazma işlemi.Arıza modu olmadan çoklama
REST API'leri için, HOL engelleme düzeltmesi en çok bir istemcinin birçok isteği paralel olarak gönderdiği durumlarda önemlidir: 15 bileşeni güncelleyen bir gösterge paneli, bir dizi güncellemeyi gönderen bir senkronizasyon motoru. Temiz bir ağda, HTTP/2 ve HTTP/3 yaklaşık olarak aynı performansı gösterir. %1-2 paket kaybı eklendiğinde (kalabalık konferans Wi-Fi'ı, metro hücresel ağ), HTTP/3 paralel istekleri bağımsız tutarken HTTP/2 onları eşzamanlı olarak duraksatır.
gRPC şimdilik çoğunlukla HTTP/2'de kalır
gRPC, tasarım gereği HTTP/2'ye bağlıdır; kablo sözleşmesi HTTP/2 çerçevelemesine ve kuyruklarına dayanır. gRPC ekosistemi henüz bir HTTP/3 eşlemesi standartlaştırmadı ve ana akım uygulamalar (Go, Java, Python, Node) bunu sunmuyor. .NET'in Kestrel sunucusu, deneysel bir yetenek olarak HTTP/3 üzerinden gRPC sunabilir, ancak bunu istisna olarak kabul edin. Mimariniz dahili API performansı için gRPC ve HTTP/2'ye dayanıyorsa, HTTP/3 geçişi bu yıl planlamanız gereken bir şey değildir.
Akış ve gerçek zamanlı trafik
Sunucu Tarafından Gönderilen Olaylar (Server-Sent Events), SSE sıradan, uzun ömürlü bir HTTP yanıtı olduğundan, HTTP/3 üzerinden değişmeden çalışır. WebSockets daha karmaşıktır: WebSocket yükseltmesi TCP için tasarlanmıştır ve HTTP/3 eşdeğeri (RFC 9220, artı ortaya çıkan WebTransport API'si) yetersiz desteğe sahiptir. Gerçek zamanlı bir özellik için WebSockets'ı düz HTTP'ye karşı değerlendiriyorsanız, HTTP/3'ün kullanılabilirliği henüz kararı yönlendirmemeli.
Dürüst kısım: HTTP/3 ne zaman yardımcı olmaz
Çoğu API gecikme sorununun taşıma protokolüyle ilgisi yoktur. Uç noktanız dizinlenmemiş bir veritabanı sorgusu nedeniyle 400 ms sürüyorsa, HTTP/3 bu yavaş yanıtı 60 ms daha erken teslim edecektir. Önbelleğe alma, yük tasarımı, N+1 sorguları ve bağlantı yeniden kullanımı gerçek dünya API performansına hakimdir ve taşıma hakkında düşünmeden önce bunları tüketmelisiniz. Yapılandırılmış bir API performans testi geçişi, genellikle bir protokol yükseltmesinden 10 kat daha büyük kazançlar ortaya çıkaracaktır.
HTTP/3 belirli koşullarda parlar:
- Gecikmesi yüksek bağlantılar, burada gidiş-dönüş tasarrufu sabit bir yüzde kazanç sağlar
- Kayıplı ağlar, burada HOL engellemesinin ortadan kaldırılması etkisini artırır
- Oturum ortasında ağ değiştiren mobil istemciler
- Az sayıda uzun bağlantı yerine çok sayıda kısa bağlantı
Aynı bölgedeki sunucular tarafından güvenilir ağlar üzerinden tüketilen tipik bir JSON API için, fark kıyaslamalarda ölçülebilir ancak kullanıcılara görünmezdir. Diğer iki pratik not: UDP bağlantı noktası 443 bazı kurumsal ağlarda engellenmiştir (istemciler otomatik olarak HTTP/2'ye geri döner, bu yüzden hiçbir şey bozulmaz) ve QUIC'in kullanıcı alanı kriptosu şu anda ayarlanmış çekirdek TCP'den bağlantı başına daha fazla sunucu CPU'su tüketir.
Mevcut destek: bugün kimler HTTP/3 kullanıyor
Benimseme, çoğu arka uç geliştiricisinin varsaydığından daha ileridedir:
- Tarayıcılar: Chrome, Edge, Firefox ve Safari'nin hepsi HTTP/3 varsayılan olarak etkin şekilde gelir.
- CDN'ler ve uç noktalar: Cloudflare, Fastly, Akamai ve CloudFront bunu destekler; Cloudflare'da bir anahtar ile açılır. Çoğu ekip için pratik yol budur: HTTP/3'ü uç noktada sonlandırın, uç noktadan kaynağa HTTP/1.1 veya HTTP/2 kullanın.
- Sunucular: Nginx, 1.25 sürümünde
listen 443 quic;ile deneysel HTTP/3 desteği ekledi. Caddy bunu varsayılan olarak etkinleştirir. LiteSpeed ve HAProxy bunu destekler. Apache httpd desteklemez. - Çalışma zamanları: Node.js'in kararlı yerleşik HTTP/3 sunucu desteği yoktur, bu da uç nokta sonlandırmanın yaygın dağıtım olmasının başka bir nedenidir.
- curl: HTTP/3 özellikli bir TLS yığınına karşı derlendiğinde
--http3bayrağıyla destekler; hangi yapıların içerdiğini öğrenmek için curl HTTP/3 belgelerine bakın.
API'nizin HTTP/3 sunup sunmadığını nasıl kontrol edersiniz
Keşif, Alt-Svc yanıt başlığı aracılığıyla çalışır. HTTP/3'ü duyuran bir sunucu, ilk (HTTP/2) isteğinizi şöyle bir şeyle yanıtlar:
alt-svc: h3=":443"; ma=86400
Bu, istemciye şunu söyler: aynı hizmet önümüzdeki 24 saat boyunca UDP bağlantı noktası 443 üzerinden HTTP/3 ile kullanılabilir. Curl ile kontrol edin:
curl -sI https://www.cloudflare.com | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400
İsteği doğrudan HTTP/3 üzerinden yapmak için (HTTP/3 özellikli bir curl derlemesi gerektirir):
curl --http3 -I https://cloudflare-quic.com
# HTTP/3 200
Durum satırı HTTP/2 yerine HTTP/3 raporlar. Chrome Geliştirici Araçları'nda Ağ sekmesini açın, sütun başlığına sağ tıklayın, Protokol sütununu etkinleştirin ve API çağrılarınızın yanında h3 arayın. Üretimde, anlaşılan protokolü erişim günlüklerinize ekleyin; h2 ve h3 trafiği arasındaki ayrım, kaç istemcinizin bu avantajdan yararlandığını gösterir.
Taşımayı doğrularsanız, davranışı da doğrulayın. Aynı uç noktalara Apidog'u yönlendirin ve durum kodları, yanıt şemaları ve gecikme bütçeleri üzerinde doğrulama yapın. Altındaki API sözleşmesi bozuksa taşıma düzeyindeki kazançlar değersizdir ve sözleşme kontrolleri, bir protokol değişikliğinin sizi kurtaramayacağı katmandır. Apidog'u ücretsiz indirin ve HTTP/3'ü kenar ağınızda açmadan önce ve sonra aynı test paketini çalıştırın; mobil ağlardaki yanıt sürelerindeki fark, kıyaslama başlıkları değil, gerçek dünya cevabınızdır.
SSS
HTTP/3, HTTP/2'den daha hızlı mı?
Temiz, düşük gecikmeli ağlarda: zar zor. Kayıplı veya yüksek gecikmeli ağlarda: evet, genellikle fark edilir şekilde, çünkü HTTP/3 bir el sıkışması gidiş-dönüşünü kurtarır ve tek bir kayıp paket artık her çoklu isteği durdurmaz. Kazancı iddia etmeden önce kendi trafik profilinizle ölçün. Ve unutmayın, HTTP/2 mükemmel kalmaya devam ediyor; orada bağlantı hatalarıyla karşılaşırsanız, bunlar genellikle protokol sınırlamalarından ziyade SSLV3_ALERT_HANDSHAKE_FAILURE sorunu gibi TLS katmanı sorunlarıdır.
HTTP/3 TCP kullanır mı?
Hayır. HTTP/3, genellikle 443 numaralı bağlantı noktasından UDP üzerinde çalışan QUIC üzerinde çalışır. QUIC, TCP'nin sağladığı güvenilirlik, sıralama ve tıkanıklık kontrolünü yeniden uygular, ancak akış başına ve kullanıcı alanında. Bir ağda UDP 443 engellenirse, istemciler otomatik olarak TCP üzerinden HTTP/2'ye geri döner.
HTTP/3 için API kodumu değiştirmem gerekiyor mu?
Neredeyse hiç. HTTP semantiği değişmez: aynı yöntemler, başlıklar, durum kodları ve gövdeler. İş, altyapıda (CDN'inizde, yük dengeleyicinizde veya sunucunuzda etkinleştirmek) ve bir tasarım kontrolünde yatar: 0-RTT erken verilerinin idempotent isteklere kısıtlandığından 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şımalarını sunmaz. .NET deneysel desteğe sahiptir. gRPC hizmetlerini HTTP/2'de tutun ve HTTP/3'ü ilk olarak faydalı olduğu yerlerde benimseyin: genel, tarayıcıya yönelik ve mobil cihazlara yönelik REST uç noktaları.