HTTP/3 ve QUIC: Web İletim Katmanını Değiştirdi
Web trafiğinin internet üzerindeki akış biçimi, HTTP/3 ve onun temelindeki iletim protokolü olan QUIC'in gelişiyle köklü bir değişim geçirdi.
HTTP/3 ve QUIC: Web'in İletim Katmanı Nasıl Değişti ve Bu Neden Önemli
Web trafiğinin internet üzerindeki akış biçimi, HTTP/3 ve onun temelindeki iletim protokolü olan QUIC'in gelişiyle köklü bir değişim geçirdi. Bu değişimi tetikleyen şey HTTP/2'deki kritik bir sorundu: tek bir kayıp paketin bağlantıdaki her akışı durdurduğu ve ciddi gecikmelere yol açtığı hat başı engellemesi (head-of-line blocking). Kullanıcı Veribloğu Protokolü (UDP) üzerine kurulan QUIC, bağımsız akışlar ve bağlantı geçişi (connection migration) sunarak bu sorunu çözer ve internetin iletim katmanını web'de gezinme için daha sağlam ve dirençli bir temele dönüştürür.
HTTP/1 ve HTTP/2'den HTTP/3'e: İletim Neden Değişmek Zorundaydı
[TO VERIFY: HTTP/2'nin modern tarayıcılar için varsayılan olduğu yıllar, o dönemdeki bazı büyük tarayıcıların adları ve QUIC'in bazı sağlayıcılarca benimsendiği belirli bir yıl]
HTTP/3, web tarayıcıları ve sunucularının nasıl iletişim kurduğunu tanımlayan protokolün en son sürümüdür. Önceki sürüm olan HTTP/2'deki eksiklikleri gidermek amacıyla İnternet Mühendisliği Görev Gücü (IETF) tarafından geliştirilmiştir. HTTP/2 web sitelerinin yüklenme biçimine büyük iyileştirmeler getirmiş olsa da gizli bir kusuru vardı: hat başı (HOL) engellemesi.
HTTP/2'de birden fazla akış (bunları bir web sayfasının farklı kısımları için ayrı yollar olarak düşünebilirsiniz), tek bir İletim Kontrol Protokolü (TCP) bağlantısı üzerinden çoğullanır. Bu çoğullama veri akışını dengelemeye yardımcı olsa da önemli bir dezavantajla birlikte gelmişti: TCP'nin temel davranışı, tüm bağlantı boyunca her baytın sırayla teslim edilmesini zorunlu kılar. Dolayısıyla, bir akışa ait bir paket kaybolduğunda veya sırası bozulduğunda, yalnızca o akışı değil, onun arkasındaki diğer tüm akışları da durdurur. Bu, bayram tatilinde trafikte sıkışıp kalmaya benzer: solunuzdaki şeritler aksa bile sıranızı beklemek zorundasınızdır.
Bu HOL engelleme sorunu, bağlantı bir ağdan diğerine geçtiğinde, örneğin bir mobil cihaz Wi-Fi ile hücresel veri arasında geçiş yaptığında özellikle sorun yaratıyordu. Tüm bağlantı kopar, bu da web sayfalarının donmasına veya çökmesine neden olurdu. Bunu düzeltmek için IETF, web'in iletim katmanını kökten değiştirmeye karar verdi.
Verileri internet üzerinden taşımanın daha verimli ve güvenilir bir yolunu sunmak üzere tasarlanmış bir iletim protokolü olan QUIC tam da burada devreye girer. Google tarafından geliştirilen ve daha sonra IETF tarafından RFC 9000'de standartlaştırılan QUIC, TCP yerine UDP üzerinden çalışır. Bu da kendi tıkanıklık kontrolünü, el değiştirmesini ve şifrelemesini doğrudan uygulamasına olanak tanıyarak TCP'nin kısıtlamalarını aşmasını sağlar.
Hat Başı Engellemesi: Nedir ve QUIC Bunu Nasıl Çözer
HOL engellemesi sorunu, tüm veri paketlerini taşıyan tek bir boru benzetmesiyle açıklanabilir. Bir paket kaybolur ya da gecikirse, arkasındaki her şey beklemek zorunda kalır ve bu da birden fazla akış için ciddi gecikmelere veya zaman aşımlarına yol açar. TCP'nin baytları birbiri ardına sıralı teslim etmesi, bir site kritik bir anda durakladığında gecikmeyi, hayal kırıklığını ve can sıkıntısını artırmaya mahkûmdu.
QUIC ise interneti daha çok her şeridin (veya akışın) bağımsız hareket edebildiği çok şeritli bir otoyol gibi görür. Bir şeritte yavaşlama olsa bile diğer şeritler akmaya devam eder. Bu, akışın farkında olan bir protokol inşa edilerek başarılır. QUIC her akışa benzersiz bir tanımlayıcı atayarak bir akıştaki paket kaybının diğerlerini etkilememesini sağlar.
Sonuç mu? Kayıp tek bir paket yalnızca ait olduğu akışı etkilerken, diğer akışlar uygulamaya veri iletmeye devam eder; buna bağımsız akışlar denir. Böylece HOL engellemesinden kaynaklanan gecikmeler savuşturulur, daha akıcı ve daha hızlı bir gezinme deneyimi sağlanır. QUIC, tüm akışları akıllıca takip eder.
QUIC Neden TCP Yerine UDP Üzerinde Çalışır
QUIC'in TCP yerine UDP üzerinden çalışma yönündeki tasarım tercihi, iletim katmanındaki HOL engellemesini çözebilme becerisinin merkezinde yer alır. TCP güvenilirliği ve sıralı teslimatıyla bilinse de HTTP/2'deki HOL engellemesi sorununun asıl nedeni tam da bu özelliklerdir.
UDP ise tam aksine, sıra veya güvenilirlik garantisi olmaksızın en iyi çaba teslimat hizmeti sunar. Bu da QUIC'in kendi özel ihtiyaçlarına göre uyarlanmış güvenilirlik ve sıralama mekanizmalarını inşa etmesine olanak tanır. QUIC gerekirse bir akış için paketleri sırayla teslim etmeyi seçebilir, ancak akışların bağımsızlığından yararlanarak etkilenmeyen akışları öne de alabilir.
Pratikte bu, QUIC'in TCP'nin tekli ve sıralı bayt akışı ile bunun sonucunda ortaya çıkan HOL engellemesine takılmadan HTTP/3 için güvenilir bir iletim sağlayabilmesi anlamına gelir. QUIC'in UDP üzerinden çalışmasının bir diğer büyük faydası da bütünleşik güvenliğidir. QUIC, protokolüne TLS 1.3 şifrelemesini dahil ederek ayrı bir TLS el sıkışması ihtiyacını ortadan kaldırır. Bu durum gecikmeyi azaltır ve bağlantı sürecini basitleştirerek performansı daha da artırır.
Bağlantı Geçişi: Ağ Değişikliklerinde Oturumları Canlı Tutmak
QUIC'in bir diğer önemli özelliği de ağ yolu değiştiğinde bağlantıları sorunsuzca taşıyabilme yeteneğidir. Bu, cihazların Wi-Fi ile hücresel ağlar arasında sık sık geçiş yaptığı modern mobil gezinmede kritik bir öneme sahiptir.
QUIC bunu, geleneksel IP/port 4'lüsü yerine bağlantıları Bağlantı Kimlikleri (CID) aracılığıyla tanımlayarak başarır. Bir cihaz yeni bir ağa geçtiğinde, QUIC bağlantısı aynı CID'yi kullanmaya devam edebilir ve bu sayede bu değişiklikten etkilenmeden kalabilir. Buna karşılık TCP yeni bir ağı yeni bir bağlantı olarak görür; bu da tam bir el sıkışma ve verilerin yeniden iletilmesini gerektirir.
Bağlantı geçiş süreci, taraflardan birinin yeni ağ yoluna bağlanmadan önce PATH_CHALLENGE ve PATH_RESPONSE çerçevelerini kullanarak bu yolu doğrulamasını içerir. Bu, yeni yolun meşru olmasını ve QUIC bağlantısını kesintisiz sürdürebilmesini garanti eder. Akışlar yola değil bağlantıya bağlıdır, bu da yol değişikliklerini sorunsuzca atlatmalarını sağlar.
Kullanıcıların Gerçekte Fark Ettiği Şey: Daha Az Donma ve Daha Kararlı Gezinme
HTTP/3 ve QUIC'teki teknik iyileştirmeler doğrudan daha iyi bir kullanıcı deneyimine dönüşür. TCP üzerinden çalışan HTTP/2'de kaybolan tek bir paket, konuyla ilgisi olmayan bir web sitesi ögesinin eksik parçayı bekleyerek donmasına yol açabiliyordu. Buna karşılık, QUIC'in bağımsız akışları etkilenmeyen kaynakların sorunsuzca yüklenmeye devam etmesini sağlar.
Kullanıcılar, özellikle yüksek paket kaybı olan ağlarda daha az "her şey dondu" anı ve sayfa yükleme sürelerinde hissedilir bir azalma bekleyebilir. QUIC'in bağlantı geçişi ayrıca ağlar arasında geçiş yaparken bile web'de gezinmenin kararlı kalmasını sağlar, bağlantıyı koparmadan korur ve sessizce kesintisiz erişim sunar.
Sınırlar ve Kalan Hat Başı Engellemeleri
QUIC'in iletim katmanındaki HOL engellemesini ortadan kaldırırken, engellemenin her biçimini yok etmediğini belirtmek önemlidir. Bir akıştaki kayıp bir paketin aynı akıştaki sonraki paketleri engelleyebildiği akış içi HOL engellemesi hâlâ meydana gelebilir. Ayrıca, uygulamanın kendisi katı bir sıralama zorunluluğu getiriyorsa uygulama katmanında da HOL engellemesi yaşanabilir.
Yine de geriye kalan bu engelleme biçimleri, genel olarak QUIC'in ortadan kaldırdığı iletim katmanı HOL engellemesinden çok daha az etkilidir. QUIC'in bağımsız akışları ve akıllı kayıp kurtarma mekanizması, web performansı ve güvenilirliğinde genel olarak belirgin bir iyileşme sağlar.
Sonuç olarak, TCP üzerinden HTTP/2'den QUIC üzerinden HTTP/3'e geçiş, web iletiminin verimliliği ve güvenilirliğinde ileriye doğru atılmış önemli bir adımı temsil eder. İletim katmanındaki HOL engellemesini ortadan kaldırarak ve bağlantı geçişini mümkün kılarak QUIC, web iletişimi için daha sağlam bir temel sunar ve kullanıcılar için daha hızlı, daha akıcı ve daha kararlı gezinme deneyimleriyle sonuçlanır.
Bu geçişin faydalı etkilerinin uzun ömürlü olması ve verilerin internet üzerinde nasıl taşındığı konusunda kalıcı bir yapısal iyileşme sağlaması beklenmektedir. HTTP/3 ve QUIC'in benimsenme oranı artmaya devam ettikçe, kullanıcılar yalnızca daha hızlı değil, aynı zamanda ağ değişiklikleri ve paket kayıpları karşısında daha dirençli bir web'i sabırsızlıkla bekleyebilir.
Kaynaklar
- IETF, RFC 9114
- IETF, RFC 9000
- Wikipedia, "HTTP/3"
- Document Server @ UHasselt, "Paving the way for end-to-end HTTP/3", 2020
- TMA Conference paper, "Analyzing the Influence of Resource Prioritization on HTTP/3 HOL Blocking", 2022
- HTTP.DEV, "QUIC explained"
- KBY Technologies, "QUIC Connection Migration | The KBY Lexicon"
- Technical University of Munich, "RFC 9000 and its Siblings: An Overview of QUIC Standards", NET-2024-04-1_02.pdf, 2024