TLS Performansı: QUIC ve HTTP/3

HTTP/2, birden çok akışı tek bir TCP bağlantısı üzerinden çoğullayarak HTTP/1.1'de bağlantı başına oluşan sıra başında bloklanma sorununu çözer. Ancak TCP'nin kendisi, taşıma katmanında sıra başında bloklanmaya neden olur: bir TCP bölümü kaybolursa kuyruktaki arkasındaki tüm veriler yeniden iletim için bekler ve tüm HTTP/2 akışlarını aynı anda engeller. Paketlerin %1'inin kaybı, birden çok bağlantı kullanıldığında HTTP/2 performansını HTTP/1.1'in altına düşürebilir. QUIC (Hızlı UDP İnternet Bağlantıları), UDP üzerinden çoğullanan akışlar uygulayarak bu sorunu çözer; akış düzeyindeki kayıp kurtarma diğer akışları engellemez.

QUIC, UDP üzerine kurulmuş bir taşıma protokolüdür; Google tarafından 2012-2015 yılları arasında geliştirilmiş ve IETF tarafından 2021'de RFC 9000 olarak standartlaştırılmıştır. QUIC, TLS 1.3'ü taşıma katmanına entegre eder; QUIC'in üzerinde ayrıca bir TLS el sıkışması yoktur, TLS doğrudan QUIC el sıkışmasının içine işlenmiştir. QUIC şunları sağlar: sıra başında bloklanma olmadan çoğullanan akışlar, bağlantı geçişi (örneğin WiFi'den LTE'ye geçerken bağlantıyı sürdürme), tekrarlanan bağlantılar için 0-RTT ile bağlantı kurulumu ve yerleşik kayıp algılama ile tıkanıklık denetimi. HTTP/3 (RFC 9114), QUIC akışları üzerindeki HTTP semantiğidir.

QUIC el sıkışması, bağlantı kurulumunu ve TLS anlaşmasını birleştirir. İlk gönderimde (QUIC terminolojisinde 0 RTT) istemci, TLS ClientHello içeren İlk paketlerini gönderir. Sunucu, kendi İlk paketleriyle (ServerHello) birlikte El Sıkışması paketlerini (şifrelenmiş uzantılar, sertifika, Tamamlandı) göndererek yanıt verir. İstemci, El Sıkışması Tamamlandı iletisini gönderir ve ardından uygulama verilerini göndermeye hazır olur; bu aşama 1-RTT'dir. 0-RTT bağlantılarında istemci, önceki oturumun devam ettirme sırrından türetilen bir anahtar kullanarak ClientHello ile birlikte 0-RTT paketlerini (uygulama verilerini) gönderir ve önbelleğe alınmış oturumlar için ek gidiş-dönüş gereksinimini sıfıra indirir.

QUIC, TLS anahtar zamanlamasının aşamalarına karşılık gelen dört farklı şifreleme düzeyi kullanır: İlk (bilinen bir sabit anahtar kullanan QUIC türevi AEAD; bütünlük sağlar, ancak gelişmiş saldırganlara karşı gizlilik sağlamaz), El Sıkışması (TLS handshake_secret değerinden türetilir; TLS el sıkışması iletileri için gizlilik sağlar), 0-RTT (önceki oturumun early_secret değerinden türetilir; 0-RTT uygulama verilerini şifreler) ve 1-RTT (TLS master_secret değerinden türetilir; tüm uygulama verilerini şifreler). QUIC üst bilgileri kısmen şifrelenir: paket numarası ve yük şifrelenir, ancak bazı yönlendirme bilgileri (Bağlantı Kimliği) yük dengeleyiciler için görünür kalır.

QUIC bağlantıları, 4'lü bir gruplama (kaynak IP, kaynak bağlantı noktası, hedef IP, hedef bağlantı noktası) yerine bir Bağlantı Kimliği (CID) ile tanımlanır. Bu sayede bağlantılar ağ değişikliklerinden etkilenmeden sürdürülebilir: mobil istemci WiFi'den LTE'ye geçtiğinde IP adresi değişir, ancak CID aynı kalır. İstemci yeni yol üzerinden bir PATH_CHALLENGE çerçevesi gönderir; sunucu PATH_RESPONSE ile yanıt vererek yeni adresi doğrular. Bağlantı, yeniden anlaşma yapılmadan kesintisiz biçimde devam eder. TCP bunu destekleyemez; bir TCP bağlantısı 4'lü gruplamaya bağlıdır ve ağ değiştiğinde yeniden kurulmalıdır, bu da yeni bir TLS el sıkışması gerektirir. QUIC geçişi, mobil kullanıcıların algıladığı performansı önemli ölçüde iyileştirir.

HTTP/3, HTTP semantiğini QUIC akışlarıyla eşleştirir. Her HTTP istek-yanıt çifti, ayrı bir çift yönlü QUIC akışında yer alır. QUIC akışları bağımsızdır: 3 numaralı akıştaki kayıp, 7 numaralı akışı engellemez. HTTP/3, üst bilgi sıkıştırması için QPACK kullanır (HTTP/2'nin HPACK'inin yerini alır); QPACK, sıralı teslim gerektirmeden çalışacak şekilde yeniden tasarlanmıştır. Ayarları ve kod çözücü/kodlayıcı yönergelerini taşıyan iki özel tek yönlü denetim akışı bulunur. HTTP/3'te sunucu gönderimi, gönderme akışlarını (tek yönlü) kullanır. Genel sonuç şudur: HTTP/3, TCP'deki sıra başında bloklanmanın en zararlı olduğu paket kaybı koşullarında (mobil ağlar, tıkanık yollar) HTTP/2'den özellikle daha iyi performans gösterir.

QUIC ve HTTP/3 performansının gerçek dünyadaki ölçümleri, ağ koşullarına bağlı olarak farklı sonuçlar gösterir. Yüksek kaliteli ağlarda (düşük gecikme, düşük paket kaybı) HTTP/3 ve HTTP/2 benzer performans gösterir; QUIC'in ek yükü (daha büyük üst bilgiler, UDP işleme ek yükü) HTTP/3'ü biraz daha yavaş bile yapabilir. Kayıplı ağlarda (%1'den fazla paket kaybı; mobil ve uydu ağlarında yaygındır) HTTP/3, HTTP/2'den önemli ölçüde daha iyi performans gösterir. Google, QUIC'e geçildiğinde YouTube'da yeniden arabelleğe alma oranında %7-8 azalma bildirildi. Facebook (Meta), QUIC üzerinden Instagram akışlarında istek gecikmesinde %7-15 iyileşme bildirdi. Kazanımlar en çok, TCP yeniden iletimlerinin duraklamalarının en etkili olduğu kuyruk gecikmesinde (p95, p99) görülür.

QUIC yük dengelemesi, QUIC UDP tabanlı olduğu ve durum bilgisi tutmayan UDP yük dengeleyicileri bağlantı bağlılığı sağlayamadığı için TCP'ye göre daha karmaşıktır. IETF draft-ietf-quic-load-balancers taslağı bir yaklaşım tanımlar: sunucular, yönlendirme bilgilerini Bağlantı Kimliğine kodlar; böylece yük dengeleyicileri bağlantı başına durum izlemeden aynı bağlantıdan gelen paketleri aynı sunucuya yönlendirebilir. Bağlantı Kimliği, yük dengeleyici ile sunucular arasında paylaşılan bir anahtarla şifrelenmiş sunucu ID'sini taşır. Cloudflare, Fastly ve Nginx bu yaklaşımın çeşitli biçimlerini uygular. NAT geçişi de başka bir sorundur: QUIC bağlantılarının, bağlantı geçişi mekanizmasıyla ele alınan NAT yeniden bağlamasından sağ çıkması gerekir.

Büyük CDN'ler, QUIC ve HTTP/3'ü büyük ölçekte kullanıma sunmuştur. Cloudflare, 2019'dan beri HTTP/3 sunuyor ve hem istemci hem de sunucu tarafından desteklendiği yerlerde trafiğin yaklaşık %20'sinin QUIC kullandığını bildiriyor. Fastly, Akamai ve AWS CloudFront, uç noktalarında HTTP/3'ü destekler. Google'ın kendi altyapısı (Search, YouTube, Gmail), QUIC'i 2013'ten beri dahili olarak kullanıyor ve HTTP/3'ü herkese açık şekilde sunuyor. CDN dağıtımları QUIC'in 0-RTT ile devam ettirme özelliğinden yararlanır: tekrar gelen ziyaretçiler bağlantıları daha hızlı kurar ve bağlantı geçişi, içerik dağıtımı sırasında erişim noktaları arasında dolaşan mobil kullanıcıların performansını iyileştirir.

QUIC'in UDP tabanlı tasarımı, kendine özgü bazı güvenlik hususlarını beraberinde getirir. Büyütme saldırıları: saldırgan bir kaynak IP'sini sahteleyip küçük İlk paketleri gönderebilir ve sunucunun kurbana büyük El Sıkışması yanıtları göndermesine neden olabilir; QUIC, adres doğrulaması RETRY mekanizmasıyla tamamlanana kadar sunucu yanıtlarını alınan verinin 3 katıyla sınırlandırarak bu saldırıları azaltır. Bağlantı taşması: QUIC sunucuları, aynı IP'den gelen yeni bağlantı kurma girişimlerine hız sınırı uygulamalıdır. Sürüm anlaşması saldırıları, sürümün kriptografik olarak korunan el sıkışmasına dahil edilmesiyle önlenir. QUIC'in yerleşik şifrelemesi, inceleme cihazlarının QUIC yükünü sunucunun sertifikasıyla yol üzerinde bulunmadıkça çözümleyememesini sağlar; bu da incelenebilen TCP trafiğine kıyasla gizliliği artırır.

HTTP/3'ü dağıtmak için şunlar gerekir: (1) QUIC destekli bir sunucu (nginx 1.25+, Caddy, HAProxy 2.6+, LiteSpeed veya quic-go, aioquic, ngtcp2 kütüphaneleri aracılığıyla uygulama düzeyinde destek). (2) Güvenlik duvarlarında UDP 443 bağlantı noktasının açık olması gerekir; birçok kurumsal güvenlik duvarı UDP 443'ü engeller ve QUIC'in TCP/TLS'ye geri dönmesine neden olur. (3) HTTP/3 desteğinin Alt-Svc yanıt üst bilgisiyle duyurulması gerekir: Alt-Svc: h3=":443"; ma=86400. Bu, HTTP/2 istemcilerini yükseltmeye yönlendirir. (4) QUIC farkındalıklı yük dengeleyiciler veya L4 UDP geçişi. (5) QUIC'e özgü ölçümlerin izlenmesi: bağlantı geçişi olayları, 0-RTT kabul oranı ve protokol geri dönüş oranı. HTTPS'ye geri dönüş içeren kademeli kullanıma sunma, QUIC'i desteklemeyen istemciler için görünmezdir.

QUIC, HTTP/2'yi TCP üzerinden etkileyen sıra başında bloklanma sorununu nasıl çözer?

QUIC, TLS 1.3'ü UDP üzerinden taşıma katmanına entegre eder ve akış başına bağımsız kayıp kurtarma kullanarak TCP'deki sıra başında bloklanmayı ortadan kaldırır. Bağlantı Kimlikleri, yeniden anlaşma yapmadan ağ değişiklikleri arasında geçiş yapılmasını sağlar. HTTP/3, QPACK üst bilgi sıkıştırmasını kullanarak HTTP'yi QUIC akışlarıyla eşleştirir. 0-RTT ile bağlantı devam ettirme, TLS oturum sırlarını yeniden kullanır. QUIC, paket kaybı olduğunda (mobil ve tıkanık ağlarda) HTTP/2'den özellikle daha iyi performans gösterir. QUIC yük dengelemesi, sunucu yönlendirmesinin Bağlantı Kimliklerine kodlanmasını gerektirir. Dağıtım için UDP 443, QUIC destekli sunucular ve protokol duyurusu amacıyla Alt-Svc üst bilgileri gerekir.