HTTP/3 Nedir – Hızlı Yeni UDP Tabanlı Protokolde Düşüş

TL; DR

Kasım 2018'de İnternet Mühendisliği Görev Gücü (IETF) Bangkok'ta bir araya geldi ve yeni bir İnternet Taslağı kabul edildi. Bir HTTP/2 halefi olan QUIC aktarım protokolü, HTTP/3 olarak yeniden adlandırıldı.

HTTP/3, Kullanıcı Datagram Protokolü (UDP) üzerine kuruludur ve halihazırda Google ve Facebook gibi önde gelen internet şirketleri tarafından kullanılmaktadır. Chrome kullanıyorsanız ve bir Google hizmetine bağlanıyorsanız, muhtemelen zaten QUIC kullanıyorsunuzdur.

HTTP protokolünün yeni sürümü, yalın, düşük seviyeli UDP protokolünden yararlanır ve TCP katmanında önceki HTTP sürümlerinde bulunan birçok yeni özelliği tanımlar. Bu, mevcut internet altyapısındaki kısıtlamaları çözmenin bir yolunu sağlar.

İlk sonuçlar umut verici ve Ağustos 2021'de IETF'nin İnternet Taslağı sona erdiğinde, HTTP/3'ün yeni, üçüncü nesil bir HTTP standardı olarak tanıtılmasını bekleyebiliriz.

2022'de HTTP/3 İlerlemesi

Bazıları, web endüstrisinin daha fazla hıza ve daha düşük gecikmeye olan açlığının, yalnızca Google Chrome'un daha fazla RAM'e olan açlığıyla eşleştiğini söylüyor.

Birkaç yıl önce, W3Techs'e göre artık dünya çapında yaklaşık %45 benimsenme oranına ulaşan bir standart olan HTTP/2 hakkında bir makale yayınladık. Ve Can I Use'a göre, tüm modern web tarayıcıları tarafından da desteklenmektedir. Yine de buradayız, protokolün bir sonraki sürümü olan HTTP/3 hakkında bir makale yazıyoruz.

HTTP/3, bu yazının yazıldığı tarihte, bir IETF İnternet Taslağı veya Kimliğidir; bu, şu anda, tanımlamadan sorumlu uluslararası bir internet standartları kuruluşu olan İnternet Mühendisliği Görev Gücü tarafından yaklaşmakta olan bir internet standardı için değerlendirildiği anlamına gelir. ve TCP, IPv6, VoIP, Nesnelerin İnterneti vb. gibi üzerinde anlaşmaya varılan internet protokolü standartlarını teşvik etmek.

Web endüstrisini birleştiren ve internetin yönü hakkında tartışmayı kolaylaştıran açık bir yapıdır. Şu anda, HTTP/3'ün "İnternet Taslağı" aşaması, tekliflerin, tüm niyet ve amaçlar için resmi internet protokolü tanımları olarak kabul edebileceğimiz Yorum İsteği (veya RFC'ler) düzeyine yükseltilmesinden önceki son aşamadır.

HTTP/3 henüz resmi bir İnternet protokolü olmasa da birçok şirket ve proje, ürünlerine HTTP/3 desteği eklemeye başladı bile.

HTTP/3 için Web Tarayıcı Desteği

Web tarayıcı cephesinde, Chrome v87, Firefox v88 ve Edge v87'nin hepsinde varsayılan olarak HTTP/3 etkindir. Safari kullanıcıları için, Safari Teknoloji Önizlemesi v104'e HTTP/3'ü etkinleştirme seçeneği eklendi. Ancak, HTTP/3 desteği şu anda Safari'nin kararlı sürümünde mevcut değildir.

HTTP/3 için Kitaplık Desteği

HTTP/3 teknolojilerinden yararlanmak isteyen geliştiriciler için, birçok popüler kitaplık zaten HTTP/3 desteği eklemiştir. HTTP/3 hala İnternet Taslağı aşamasında olduğundan, aşağıdaki kitaplıklardan biriyle çalışırken en son güncellemelere bağlı olduğunuzdan emin olmak isteyeceksiniz.

• Python – http3 ve aioquic
• Pas - kiş, neqo ve quinn
• C – nghttp3 ve lsquic
• git - quicgo
• JavaScript – Node.js

HTTP/3 için Altyapı Desteği

Altyapı tarafında, Cloudflare, tüm uç ağında HTTP/3 desteğiyle öncülük ediyor. Bu, Cloudflare etkinleştirilmiş sitelerin, herhangi bir ek çalışma olmaksızın HTTP/3'ün güvenlik ve performans geliştirmelerinden yararlanabileceği anlamına gelir.

Kinsta'da barındırdığımız tüm siteler ücretsiz Cloudflare entegrasyonumuz tarafından korunmaktadır. Kurumsal düzeyde güvenlik duvarı ve DDoS korumasına ek olarak, Kinsta müşterilerinin HTTP/3'e de erişimi vardır!

Sitenizin HTTP/3'ü destekleyip desteklemediğini test etmek için Geekflare'nin HTTP/3 Test Aracını kullanabilirsiniz. Etki alanınızı yazın ve "HTTP/3'ü Kontrol Et" düğmesine basın; araç, sitenizin HTTP/3'ün etkin olup olmadığını size bildirecektir.

Siteniz HTTP/3'ü destekliyorsa aşağıdaki gibi bir mesaj görmelisiniz. Kinstalife.com, Kinsta'da barındırıldığından, Cloudflare entegrasyonumuz sayesinde HTTP/3 tam olarak desteklenir.

HTTP/3 desteğini kontrol etmek için tarayıcınızın denetçisini de kullanabilirsiniz. Bu örnek için, Google Chrome'un HTTP/3'ü destekleyen en son sürümünü kullanacağız.

Denetçiyi açmak için sayfaya sağ tıklayın ve “İncele”ye tıklayın ve “Ağ” sekmesine gidin. “Protokol” sütununda bağlantı için kullanılan HTTP protokolünü görebilirsiniz. HTTP/2 bağlantıları "h2" olarak görünürken HTTP/3 bağlantıları "h3-XX" olarak görünür (XX, belirli bir HTTP/3 taslağını ifade eder). Aşağıdaki resimde de görebileceğiniz gibi kinstalife.com, “HTTP/3 Draft 29” anlamına gelen “h3-29” üzerinden bağlantıları desteklemektedir.

Artık HTTP/3'ün mevcut durumunu gözden geçirdiğimize göre, HTTP/2 ile HTTP/3 arasındaki bazı farklara derinlemesine bakalım!

Biraz Arka Plan – HTTP/2 ile Başladı

HTTP/2, temel TCP protokolünün bazı sınırlamalarının üstesinden gelmemize yardımcı olan engellemesiz indirmeler, boru hattı ve sunucu itme ile bazı ciddi iyileştirmeler getirdi. İstek-yanıt döngülerinin ve el sıkışmalarının sayısını en aza indirmemize izin verdi.

HTTP/2, birden fazla kaynağı tek bir TCP bağlantısına göndermeyi mümkün kıldı - çoğullama. Ayrıca statik indirmelerin sıralamasında daha fazla esnekliğe sahibiz ve sayfalarımız artık indirmelerin doğrusal ilerlemesiyle kısıtlanmıyor.

Pratikte bu, şu anda büyük bir javascript kaynağının, sırasını bekleyen diğer tüm statik kaynaklar için mutlaka bir boğma noktasına eşit olmadığı anlamına gelir.

Bunlara HTTP/2'nin üstbilgi HPACK sıkıştırmasını ve veri aktarımının varsayılan ikili biçimini ekleyin ve çoğu durumda önemli ölçüde daha verimli bir protokole sahibiz.

Büyük tarayıcı uygulamaları, HTTP/2'nin avantajlarından yararlanabilmek için web sitelerinin şifreleme (SSL) uygulamasını bir gereklilik haline getirdi ve bazen bu, hız iyileştirmelerini farkedilemez hale getiren bir hesaplama yüküne neden oldu. Kullanıcıların HTTP/2'ye geçtikten sonra yavaşlama bildirdiği bazı durumlar bile oldu.

Sadece bu versiyonun benimsendiği ilk günlerin zayıf kalpler için olmadığını söyleyelim.

Nginx uygulaması, bir modüle dayanan sunucu-itme özelliğinden de yoksundu. Ve Nginx modülleri, kopyalayabileceğiniz her zamanki Apache açılır modülleriniz değildir - NGINX'in bunlarla yeniden derlenmesi gerekir.

Bu sorunlardan bazıları şimdi çözülmüş olsa da, tüm protokol yığınına bakarsak, birincil kısıtlamanın HTTP/2'nin cesaret etmeye cesaret ettiğinden daha düşük bir seviyede olduğunu görürüz.

Bunu detaylandırmak için, bugünün internet protokol yığınını alt katmanından yukarıya doğru inceleyeceğiz. HTTP/2'nin arka planı hakkında daha fazla bilgi edinmek istiyorsanız, nihai HTTP/2 kılavuzumuza göz atmayı unutmayın.

İnternet Protokolü (IP)

İnternet Protokolü (IP), tüm internet topolojisinin alt kısmını tanımlar. İnternet yığınının bir parçası, güvenle söyleyebiliriz ki, yönlendiricilerden sunuculara ve hatta son kullanıcıların makinelerine kadar tüm donanım altyapısını değiştirmek de dahil olmak üzere her şeyi değiştirmeden gerçekten pazarlık edilemez.

Bu nedenle, protokol revizyonunun zamanı gelmiş olsa da, şu anda bu kadar geniş kapsamlı bir çaba ufukta görünmüyor, çünkü esas olarak uygulanabilir, çığır açan, ancak geriye dönük uyumlu bir alternatif bulamamışız.

IP protokolünün başlangıcını 1974'e, Elektrik ve Elektronik Mühendisleri Enstitüsü tarafından yayınlanan ve Vint Cerf ve Bob Cahn tarafından yazılan bir makaleye kadar takip edebiliriz. Bir ağ üzerinden gönderilen paketleri, bunları IP adresleri arasında yönlendirerek ve bir ağdaki/ağlardaki sayısal olarak tanımlanmış düğüm adreslerini ayrıntılı olarak anlatır. Protokol, bu paketlerin veya datagramların - başlıklarını ve yükünü - formatını tanımladı.

1980'deki RFC 760 tanımından sonra IETF, Request For Comments 791'de bu güne kadar yaygın olarak kullanılan tanıma yerleşti. Bu, protokolün dördüncü versiyonu ama ilk üretim versiyonu diyebiliriz.

32 bit adresler kullanır ve bu da adres sayısını yaklaşık 4 milyar olarak belirler. Bu sınırlama, ticari olmayan internet kullanıcılarının ISS'leri tarafından neden "dinamik IP adresleri" aldıklarının ve statik bir IP'nin "katma değer" olarak kabul edilmesinin ve genellikle ek ücretlere tabi olmasının gizeminin açıklamasıdır.

Karne yapıyorlar.

32-bit adreslerin yeterli olmadığı ve kıtlığın baş gösterdiği anlaşılana kadar uzun sürmedi, bununla başa çıkmaya çalışan çok sayıda RFC yayınlandı. Bu çözümler günümüzde yaygın olarak kullanılmasına ve günlük hayatımızın bir parçası olmasına rağmen, bu miktarların hack olduğunu söylemek muhtemelen güvenlidir.

Bülten için Kaydolun

Trafiğimizi nasıl %1000'in üzerine çıkardığımızı bilmek ister misiniz?

İçeriden WordPress ipuçlarıyla haftalık bültenimizi alan 20.000'den fazla kişiye katılın!

Şimdi Abone Ol

İnternet Protokolü sürüm 6 veya IPv6, önceki sürüme göre kademeli olarak benimsenmesi de dahil olmak üzere bu sınırlamaları ele almanın bir yolu olarak geldi. 1998'de IETF için Taslak Standart belgesi haline getirildi ve 2017'de bir İnternet Standardına yükseltildi.

IPv4 adres alanı 32 bitlik adres uzunluğuyla sınırlıyken, IPv6 standardına 128 bit veya 3.4 * 10 ^ 38 olası adres verildi. Bu bize uzunca bir süre yetecek kadar olmalı.

Google ve kullanıcıları arasındaki IPv6 bağlantısına göre, Haziran 2021 itibariyle IPv6'nın benimsenmesi %35'in biraz üzerinde.

IP, teslimat, veri bütünlüğü veya iletilen paketlerin sıralanması garantisi olmaksızın en temel şeyleri tanımlayan internet yığınının ilkel bir katmanıdır. Tek başına güvenilmez. IPv4'ün başlık formatı, iletim düğümlerinin başlığın bütünlüğünü doğrulamak için kullandığı başlık sağlama toplamını sağlar. Bu, onu, altındaki bağlantı katmanına dayanan ve daha hızlı olmasını sağlayan IPv6 sürümünden farklı kılar.

TCP ve UDP'nin Rolünü Anlamak

Şimdi HTTP/3'ün TCP ve UDP ile nereye uyduğunu keşfetme zamanı.

TCP

IP, bugün tüm çevrimiçi iletişimlerimizin altında yatan katman olsa da, TCP (İletim Kontrol Protokolü), internet protokol paketinin daha üst düzey bir parçasıdır ve web, posta, dosya aktarımı (FTP) için gereken güvenilirliği sağlar – internetin uygulama katmanları/protokolleri için.

Bu, el sıkışmaları, garantili paket sırası ve kayıp paketlerin yeniden iletilmesi ile çok adımlı bağlantı kurulmasını içerir. Gönderene teslimatın geri bildirimini (Acks) sağlar vb. Hataları tespit etmek için sağlama toplamı hesaplaması da vardır.

Bütün bunlar, TCP'yi güvenilir bir protokol haline getiren ve onu bugün kullandığımız en kötü şöhretli internet hizmetlerinin temeli yapan birçok adımı gösterir.

1974 (RFC 675) ve 1981'e (RFC 793) dayanan teknik özellikleri bugüne kadar önemli ölçüde değişmedi.

Bununla birlikte, TCP'nin sağladığı güvenilirlik ücretsiz değildir. El sıkışmaları, teslimat geri bildirimi, sipariş garantileri ve zayıf ve gereksiz olarak kabul edilebilecek sağlama toplamlarının gerektirdiği tüm gidiş dönüşlerin genel gideri. TCP'yi modern protokol yığınının bir darboğazı haline getirdi. HTTP/2, TCP'nin üzerinde elde edilebilecek bir hız iyileştirme platosuna ulaştı.

UDP

Kullanıcı Datagram Protokolü (UDP), aynı zamanda, 1980'e (RFC 768) dayanan spesifikasyonu ile İnternet Protokol Paketinin parçalarından biridir.

Adından da anlaşılacağı gibi, datagram tabanlı bağlantısız bir protokoldür. Bu, el sıkışma olmadığı ve sipariş veya teslimat garantisi olmadığı anlamına gelir. Bu, teslimatı, veri bütünlüğünü ve diğer şeyleri sağlamak için olası tüm adımların uygulama katmanına bırakıldığı anlamına gelir. Bu, UDP'nin üzerine inşa edilen bir uygulamanın somut duruma bağlı olarak kullanacağı stratejileri seçebileceği veya ek yükü önlemek için bağlantı katmanının sağlama toplamları gibi öğelerinden yararlanabileceği anlamına gelir.

UDP, tıpkı TCP gibi yaygın olduğu için, internete bağlı çok çeşitli cihazlarda ürün yazılımı güncellemelerine veya işletim sistemlerinde önemli değişikliklere gerek kalmadan iyileştirmeler elde etmeyi mümkün kılar.

Yeni protokollerin konuşlandırılması, birçok güvenlik duvarı, NAT, yönlendirici ve yalnızca TCP veya UDP'ye izin veren diğer orta kutular tarafından kullanıcılar ve erişmeleri gereken sunucular arasında konuşlandırılır. – HTTP/3 açıkladı

Hacker News'deki bu başlık, yeni HTTP sürümünü yeniden icat etmek yerine (bundan daha fazlası olmasına rağmen) mevcut ağ yığınının üzerine oluşturmanın ardındaki mantığı anlamaya başlamamıza yardımcı olabilir.

UDP paket formatı spesifikasyonu oldukça azdır, başlığı kaynak bağlantı noktası, hedef bağlantı noktası, bayt cinsinden uzunluk, paket başlığı ve paket verileri ve sağlama toplamından oluşur. Sağlama toplamı, paketin hem başlığı hem de veri kısmı için veri bütünlüğünü doğrulamak için kullanılabilir.

Temel protokol katmanı IPv4 olduğunda sağlama toplamı isteğe bağlıdır ve IPv6 ile zorunludur. Şimdiye kadar UDP, bilgisayar sistemleri saat senkronizasyonu (NTP), VoIP uygulamaları, video akışı, DNS sistemi ve DHCP protokolü gibi şeyler için kullanıldı.

QUIC ve HTTP/3

QUIC (Hızlı UDP İnternet Bağlantıları) ilk olarak 2012'de Google tarafından dağıtıldı. Alt düzey UDP protokolüne dayanarak ağ katmanlarının sınırlarını yeniden tanımlıyor, el sıkışmalarını, güvenilirlik özelliklerini ve "kullanıcı alanında" güvenlik özelliklerini yeniden tanımlıyor. İnternet genelindeki sistemlerin çekirdeklerini yükseltme.

Tıpkı Google'ın SPDY'sinin öncülük ettiği veya hızlı bir gelişme olan HTTP/2'de olduğu gibi, HTTP/3 de yine bu başarıların üzerine inşa edilecek.

HTTP/2 bize çoğullama sağladı ve hat başı engellemesini azalttı, ancak TCP tarafından kısıtlandı. Verileri aktarmak için birbirine çoklanmış birden çok akış için tek bir TCP bağlantısı kullanabilirsiniz, ancak bu akışlardan biri paket kaybına uğradığında, tüm bağlantı (ve tüm akışları) TCP işini yapana kadar rehin tutulur . kayıp paketi yeniden iletir).

Bu, hedef düğümün arabelleğinde zaten iletilmiş ve bekliyor olsalar bile tüm paketlerin, kayıp paket yeniden iletilinceye kadar bloke edildiği anlamına gelir. Daniel Stenberg http/3 hakkındaki kitabında buna “TCP tabanlı satır başı bloğu” diyor. %2 paket kaybıyla, kullanıcıların bu riskten korunmak için altı bağlantıyla HTTP/1 ile daha iyisini yapacağını iddia ediyor.

QUIC bununla sınırlı değildir. QUIC'in bağlantısız UDP protokolü üzerine inşa edilmesiyle, bağlantı kavramı TCP'nin sınırlamalarını taşımaz ve bir akışın arızalarının geri kalanını etkilemesi gerekmez.

Cloudflare'den Lucas Pardue'nun dediği gibi:

UDP akışlarına odaklanan QUIC, tek bir TCP bağlantısına bindirmek zorunda kalmadan çoğullamayı başarır. QUIC, bağlantısını TCP'den daha yüksek bir düzeyde kurar. QUIC bağlantıları içindeki yeni akışlar, diğerlerinin bitmesini beklemek zorunda değildir. QUIC bağlantıları, gecikmeyi azaltan TCP el sıkışma ek yükünü ortadan kaldırmanın avantajını da taşır.

Cisco'daki arkadaşlar, TCP'nin 3 yönlü tokalaşmasını açıklayan ilginç bir video yaptılar:

QUIC, TCP güvenilirlik özelliklerini ortadan kaldırırken, paketlerin yeniden iletilmesini, sipariş verilmesini vb. sağlayarak UDP katmanının üzerinde bunu telafi eder. Google Cloud Platform, 2018'de yük dengeleyicileri için QUIC desteğini kullanıma sundu ve ortalama sayfa yükleme süresinde dünya genelinde %8, gecikme süresinin daha yüksek olduğu bölgelerde ise %13'e varan bir iyileşme gördü.

Google Chrome, YouTube, Gmail, Google'ın arama ve diğer hizmetleri arasında Google, IETF'yi beklemeden QUIC'i internetin güzel bir bölümüne dağıtmayı başardı. Google mühendisleri, 2017'de internet trafiğinin %7'sinin zaten QUIC üzerinden gerçekleştirildiğini iddia ediyor.

Google'ın QUIC sürümü, HTTP/2 sözdizimini kullanarak yalnızca HTTP aktarımına odaklandı. IETF'den kişiler (QUIC'yi standartlaştırmaktan sorumlu olanlar), QUIC'in IETF sürümünün HTTP'den daha fazlasını taşıyabilmesi gerektiğine karar verdi. Ancak şimdilik, QUIC üzerinden HTTP olmayan protokoller üzerindeki herhangi bir çalışma beklemede.

IETF'nin çalışma grubunun karar verdiği bir şey daha, standart sürümün Google'ın özel çözümü yerine TLS 1.3 şifrelemesini kullanmasıdır. TLS 1.3, eski sürümlerle karşılaştırıldığında, el sıkışmaları daha az gidiş-dönüş gerektirdiğinden protokol hızına da katkıda bulunur. Kinsta, tüm sunucularımızda ve Kinsta CDN'mizde TLS 1.3'ü destekler.

Şu anda Google, geliştirme çabalarını IETF standartlarına yönlendirirken, ürününde kendi QUIC sürümünü kullanmaya devam ediyor. Diğer internet oyuncularının çoğu, IETF sürümünün üzerine inşa ediyor (ikisi, şifrelemenin yanı sıra diğer bazı yönlerden farklıdır).

Chrome Dev Tools'u açarsak ve Gmail gibi bazı Google ürünlerini Ağ sekmesinin Protokol sütununa yüklersek, Google'ın QUIC protokolünün sürümü aracılığıyla birçok kaynağın yüklendiğini görürüz. Bu aynı zamanda Google'ın Analytics, Google Etiket Yöneticisi vb. ürünleri için de geçerlidir.

Cloudflare, standardizasyon ilerlemesi hakkında çok kapsamlı bir güncelleme yayınladı.

UDP, QUIC ve HTTP/3 bazı doğal avantajlar sağlarken, bazı zorlukları da beraberinde getirir.

TCP yıllardır ana protokol olmuştur, UDP ise yoktur, bu nedenle işletim sistemleri ve bunun için yazılım yığını genel olarak optimize edilmemiştir. Sonuç olarak, QUIC ile çok daha yüksek CPU yükü/gereksinimleri vardır, bazı tahminlere göre HTTP/2'ye göre iki kat daha fazladır.

Optimizasyonlar, işletim sistemlerinin çekirdeğine, farklı yönlendiriciler ve aygıt bellenimine kadar iner. Bu Red Hat akort kılavuzu, teknik açıdan daha yatkın olanlar için konuya daha fazla ışık tutabilir.

QUIC'in TCP özelliklerini daha minimal ve daha esnek bir protokol üzerinde yeniden tasarlamaya çalıştığını söyleyebiliriz.

Daha önce bahsettiğimiz QUIC bağlantıları TLS ve transport tokalaşmalarını birleştirir. Kurulduktan sonra, benzersiz CID'ler (bağlantı kimlikleri) ile tanımlanırlar. Bu kimlikler, IP değişiklikleri boyunca kalıcıdır ve örneğin 4G'den WiFi'ye geçişte kesintisiz indirmelerin güvenliğini sağlamaya yardımcı olabilir. Bu, özellikle mobil cihazlarda giderek daha fazla internet trafiği yapıldığından önemlidir. Bu öğenin Google tarafından farklı bağlantılar ve internet sağlayıcıları arasında daha iyi kullanıcı izlemeyi kolaylaştırmak için tasarlanıp tasarlanmadığına dair sorular ortaya çıkabilir.

TLS zorunludur ve ortadaki cihazların trafiğe müdahale etmesini veya trafiği koklamasını zorlaştırmayı amaçlar. Bu nedenle, Cisco gibi güvenlik duvarı sağlayıcılarının ve satıcılarının UDP protokolünü bir sorun olarak görmeleri ve bunu devre dışı bırakmanın yollarını sunmaları nadir değildir. Aracıların QUIC trafiğini denetlemesi ve denetlemesi veya filtrelemesi daha zordur.

QUIC akışları, tek yönlü veya çift yönlü QUIC bağlantıları üzerinden gönderilir. Akışlar, başlatıcıyı ve akışın tek yönlü mü yoksa çift yönlü mü olduğunu tanımlayan kimliklere sahiptir ve ayrıca akış içi akış denetimine hizmet eder.

QUIC bir aktarım katmanı protokolü olsa da, HTTP bunun üzerindeki katmandır, bir uygulama katmanı protokolü veya uygulama protokolüdür.

Geriye dönük uyumluluk son derece önemli olduğundan, IETF HTTP/3'ün uygulanmasını destekledi ve yanıta eski sürümü (HTT1 veya HTTP/2) dahil edecek. RFC 7838'de açıklandığı gibi, bağlantı noktası/ana bilgisayar bilgileriyle birlikte istemciye HTTP/3'ün kullanılabilir olduğunu bildiren bir başlık içerecektir.

Bu, TLS el sıkışması içinde aktarımın görüşülebildiği HTTP/2'den farklıdır. Ancak IETF, bir sonraki standart olarak QUIC tabanlı HTTP/3'ü neredeyse benimsediğinden, web istemcilerinin giderek daha fazla HTTP/3 desteği beklemesini bekleyebiliriz. İstemcilerin önceki HTTP/3 bağlantılarından verileri önbelleğe alması ve aynı ana bilgisayara sonraki ziyaretlerde doğrudan (sıfır gidiş-dönüş veya 0-RTT) bağlanması mümkündür.

Özet

HTTP/2 standardının henüz tam olarak benimsenmemiş olması nedeniyle HTTP/3 için yaygın bir baskı yapmak için çok erken olabileceğini düşünenler var. Bu geçerli bir nokta, ancak bahsettiğimiz gibi, bu protokol zaten büyük ölçekli testler ve uygulamalar gördü. Google, 2015'te ve Facebook'ta 2017'de test etmeye başladı.

2022'de Google Chrome ve Brave gibi büyük tarayıcılardan HTTP/3 desteği aldık. Altyapı cephesinde, Litespeed ve Nginx gibi web sunucularının her ikisi de HTTP/3'ün çalışan uygulamalarına sahipken, Cloudflare gibi ağ sağlayıcıları HTTP/3 için tam destek dağıtmıştır.

Şu anda, HTTP/3 hala İnternet Taslağı aşamasındadır ve en son revizyonun süresi Ağustos 2021'de sona erecektir. Büyük yazılım satıcılarının yeniyi uygulamaya geçirme hareketini görmeyi bekleyebileceğimiz için bu yıl heyecan verici olacaktır. standart.