20 yılı aşkın süredir web sayfalarını HTTP protokolünü kullanarak görüntülüyoruz. Çoğu kullanıcı bunun ne olduğunu ve nasıl çalıştığını düşünmüyor bile. Diğerleri, HTTP'nin altında bir yerde TLS'nin olduğunu, onun altında TCP'nin, onun altında IP'nin vb. olduğunu biliyor. Ve yine de diğerleri - kafirler - TCP'nin geçmişte kaldığına inanıyorlar; daha hızlı, daha güvenilir ve güvenli bir şey istiyorlar. Ancak yeni bir ideal protokol icat etme girişimlerinde 80'lerin teknolojisine geri döndüler ve yeni cesur dünyalarını bunun üzerine kurmaya çalışıyorlar.
Küçük bir tarih: HTTP/1.1
1997 yılında, metin bilgi alışverişi protokolü HTTP sürüm 1.1 kendi RFC'sini satın aldı. O zamanlar protokol tarayıcılar tarafından birkaç yıldır kullanılıyordu ve yeni standart on beş yıl daha dayandı. Protokol yalnızca istek-yanıt ilkesine göre çalışıyordu ve öncelikle metin bilgilerinin iletilmesine yönelikti.
HTTP, paketlerin hedeflerine güvenilir bir şekilde iletilmesini sağlamak için TCP protokolünün üzerinde çalışacak şekilde tasarlanmıştır. TCP, uç noktalar arasında güvenilir bir bağlantı kurarak ve sürdürerek ve trafiği bölümlere ayırarak çalışır. Segmentlerin kendi seri numaraları ve sağlama toplamları vardır. Eğer segmentlerden biri aniden gelmezse veya yanlış bir sağlama toplamı ile ulaşırsa, kayıp segment geri yüklenene kadar iletim durdurulacaktır.
HTTP/1.0'da her istekten sonra TCP bağlantısı kapatıldı. Bu son derece israftı, çünkü... TCP bağlantısı kurmak (3 Yollu El Sıkışma) yavaş bir işlemdir. HTTP/1.1, bir bağlantıyı birden fazla istek için yeniden kullanmanıza olanak tanıyan canlı tutma mekanizmasını tanıttı. Bununla birlikte, kolayca bir darboğaz haline gelebileceğinden, HTTP/1.1'in çeşitli uygulamaları aynı ana bilgisayara birden fazla TCP bağlantısının açılmasına izin verir. Örneğin, Chrome ve Firefox'un son sürümleri altı adede kadar bağlantıya izin verir.
Şifrelemenin de diğer protokollere bırakılması gerekiyordu ve bunun için TCP üzerinden verileri güvenilir bir şekilde koruyan ancak bağlantı kurmak için gereken süreyi daha da artıran TLS protokolü kullanıldı. Sonuç olarak el sıkışma süreci şu şekilde görünmeye başladı:
Bulut parlaması illüstrasyonu
Dolayısıyla HTTP/1.1'in bir takım sorunları vardı:
- Yavaş bağlantı kurulumu.
- Veriler metin biçiminde iletilir; bu, resimlerin, videoların ve diğer metin dışı bilgilerin aktarımının etkisiz olduğu anlamına gelir.
- Bir istek için bir TCP bağlantısı kullanılır; bu, diğer isteklerin ya başka bir bağlantı bulması ya da mevcut istek onu serbest bırakana kadar beklemesi gerektiği anlamına gelir.
- Yalnızca çekme modeli desteklenir. Standartta sunucu itmeyle ilgili hiçbir şey yoktur.
- Başlıklar metin halinde aktarılır.
Sunucu itme en azından WebSocket protokolü kullanılarak uygulanıyorsa, geri kalan sorunların daha radikal bir şekilde ele alınması gerekiyordu.
Biraz modernlik: HTTP/2
2012 yılında Google, SPDY ("hızlı" olarak telaffuz edilir) protokolü üzerinde çalışmaya başladı. Protokol, HTTP/1.1'in ana sorunlarını çözmek için tasarlandı ve aynı zamanda geriye dönük uyumluluğu da sürdürmesi gerekiyordu. 2015 yılında IETF çalışma grubu SPDY protokolünü temel alan HTTP/2 spesifikasyonunu tanıttı. HTTP/2'deki farklar şunlardır:
- İkili serileştirme.
- Birden fazla HTTP isteğini tek bir TCP bağlantısına çoğullama.
- Sunucu tarafından kutudan çıkarılır (WebSocket olmadan).
Protokol ileriye doğru atılmış büyük bir adımdı. O şiddetle ve birden fazla TCP bağlantısının oluşturulmasını gerektirmez: bir ana bilgisayara yapılan tüm istekler tek bir sunucuda çoğaltılır. Yani, bir bağlantıda her biri kendi kimliğine sahip olan birkaç sözde akış vardır. Bonus, kutulu bir sunucu itişidir.
Ancak çoğullama başka bir önemli soruna yol açar. Bir sunucuya 5 isteği eşzamansız olarak yürüttüğümüzü hayal edin. HTTP/2 kullanıldığında, tüm bu istekler aynı TCP bağlantısı içinde gerçekleştirilecektir; bu, herhangi bir isteğin bölümlerinden birinin kaybolması veya yanlış alınması durumunda, kayıp bölüm tamamlanana kadar tüm istek ve yanıtların iletiminin duracağı anlamına gelir. restore edildi. Açıkçası, bağlantı kalitesi ne kadar kötü olursa HTTP/2 o kadar yavaş çalışır. Kayıp paketlerin tüm paketlerin %2'sini oluşturduğu durumlarda tarayıcıdaki HTTP/1.1, bir yerine 2 bağlantı açması nedeniyle HTTP/6'den daha iyi performans gösterir.
Bu soruna “hat başı engelleme” adı veriliyor ve ne yazık ki TCP kullanırken çözülmesi mümkün olmuyor.
Çizim: Daniel Steinberg
Sonuç olarak, HTTP/2 standardının geliştiricileri harika bir iş çıkardılar ve OSI modelinin uygulama katmanında yapılabilecek hemen hemen her şeyi yaptılar. Aktarım katmanına inip yeni bir aktarım protokolü icat etmenin zamanı geldi.
Yeni bir protokole ihtiyacımız var: UDP vs TCP
Tamamen yeni bir aktarım katmanı protokolünün uygulanmasının günümüz gerçeklerinde imkansız bir görev olduğu oldukça hızlı bir şekilde anlaşıldı. Gerçek şu ki, donanım veya orta kutular (yönlendiriciler, güvenlik duvarları, NAT sunucuları...) aktarım katmanını biliyor ve onlara yeni bir şey öğretmek son derece zor bir görev. Ek olarak, taşıma protokolleri desteği işletim sistemlerinin çekirdeğine yerleştirilmiştir ve çekirdekler de değişmeye pek istekli değildir.
Ve burada kişi ellerini kaldırıp şöyle diyebilir: "Elbette tercihler ve fahişelerle yeni bir HTTP/3 icat edeceğiz, ancak uygulanması 10-15 yıl sürecek (bu süreden sonra donanımın çoğu yenilenecek) değiştirildi)” ancak öyle olmayan bir tane daha var. Açık olan seçenek UDP protokolünü kullanmaktır. Evet, evet, doksanların sonu ve XNUMX'lerin başında dosyaları LAN üzerinden atmak için kullandığımız protokolün aynısı. Günümüzün hemen hemen tüm donanımları bununla çalışabilir.
UDP'nin TCP'ye göre avantajları nelerdir? Öncelikle donanımın bildiği bir taşıma katmanı oturumumuz yok. Bu, uç noktalardaki oturumu kendimiz belirlememize ve oradaki çatışmaları çözmemize olanak tanır. Yani (TCP'de olduğu gibi) bir veya birkaç oturumla sınırlı değiliz, ihtiyaç duyduğumuz kadar oturum oluşturabiliriz. İkincisi, UDP üzerinden veri aktarımı TCP'ye göre daha hızlıdır. Böylece teorik olarak HTTP/2'de ulaşılan mevcut hız tavanını aşabiliriz.
Ancak UDP güvenilir veri aktarımını garanti etmez. Aslında biz sadece karşı tarafın onları alacağını umarak paket gönderiyoruz. Almamış? Şansınız yok... Bu, yetişkinlere yönelik videoları aktarmak için yeterliydi, ancak daha ciddi şeyler için güvenilirliğe ihtiyacınız var, bu da UDP'nin üstüne başka bir şey sarmanız gerektiği anlamına geliyor.
HTTP/2'de olduğu gibi Google'da da yeni bir protokol oluşturma çalışmaları 2012'de, yani SPDY'nin başlamasıyla hemen hemen aynı zamanlarda başladı. 2013 yılında Jim Roskind halka sunuldu ve 2015 yılında IETF'de standardizasyon için İnternet Taslağı tanıtıldı. Zaten o zamanlar Roskind'in Google'da geliştirdiği protokol standarttan çok farklıydı, bu nedenle Google sürümü gQUIC olarak adlandırılmaya başlandı.
QUIC nedir?
İlk olarak, daha önce de belirtildiği gibi, bu UDP üzerinde bir sarmalayıcıdır. UDP'nin üzerinde, HTTP/2'ye benzer şekilde birçok akışın bulunabileceği bir QUIC bağlantısı yükselir. Bu akışlar yalnızca uç noktalarda bulunur ve bağımsız olarak sunulur. Bir akışta paket kaybı meydana gelirse, bu durum diğerlerini etkilemez.
Çizim: Daniel Steinberg
İkincisi, şifreleme artık ayrı bir düzeyde uygulanmıyor, protokole dahil ediliyor. Bu, tek bir el sıkışmayla bağlantı kurmanıza ve ortak anahtarları değiştirmenize olanak tanır ve ayrıca akıllı 0-RTT el sıkışma mekanizmasını kullanmanıza ve el sıkışma gecikmelerini tamamen önlemenize olanak tanır. Ayrıca artık bireysel veri paketlerini şifrelemek de mümkün. Bu, akıştan veri almanın tamamlanmasını beklemenize değil, alınan paketlerin şifresini bağımsız olarak çözmenize olanak tanır. Bu çalışma modu TCP'de genellikle imkansızdı çünkü TLS ve TCP birbirinden bağımsız çalışıyordu ve TLS, TCP verilerinin hangi parçalara bölüneceğini bilemiyordu. Bu nedenle segmentlerini TCP segmentlerine bire bir uyacak ve bağımsız olarak şifresi çözülebilecek şekilde hazırlayamadı. Tüm bu iyileştirmeler QUIC'in TCP'ye kıyasla gecikmeyi azaltmasına olanak tanır.
Üçüncüsü, ışık akışı kavramı, bağlantıyı müşterinin IP adresinden ayırmanıza olanak tanır. Bu, örneğin bir istemci bir Wi-Fi erişim noktasından diğerine geçip IP'sini değiştirdiğinde önemlidir. Bu durumda, TCP kullanılırken, mevcut TCP bağlantılarının zaman aşımına uğradığı ve yeni bir IP'den yeni bağlantıların oluşturulduğu uzun bir süreç meydana gelir. QUIC durumunda istemci, eski akış kimliğine sahip yeni bir IP'den sunucuya paket göndermeye devam eder. Çünkü Akış kimliği artık benzersizdir ve yeniden kullanılmaz; sunucu, istemcinin IP'sini değiştirdiğini anlar, kayıp paketleri yeniden gönderir ve yeni adreste iletişime devam eder.
Dördüncüsü, QUIC işletim sistemi düzeyinde değil uygulama düzeyinde uygulanır. Bu bir yandan protokolde hızlı bir şekilde değişiklik yapmanıza olanak tanır, çünkü Güncelleme almak için yeni bir işletim sistemi sürümünü beklemek yerine kitaplığı güncellemeniz yeterlidir. Öte yandan bu durum işlemci tüketiminde güçlü bir artışa yol açıyor.
Ve son olarak manşetler. Başlık sıkıştırması QUIC ve gQUIC arasında farklılık gösteren şeylerden biridir. Buna çok zaman ayırmanın bir anlamı yok, sadece standardizasyon için gönderilen sürümde başlık sıkıştırmasının HTTP/2'deki başlık sıkıştırmasına mümkün olduğunca benzer hale getirildiğini söyleyeceğim. Daha fazlasını okuyabilirsiniz .
Ne kadar hızlı?
Bu zor bir soru. Gerçek şu ki, bir standardımız olana kadar ölçebileceğimiz özel bir şey yok. Belki de elimizdeki tek istatistik, 2013'ten bu yana ve 2016'dan beri gQUIC'i kullanan Google'ın istatistikleridir. Chrome tarayıcısından sunucularına giden trafiğin yaklaşık %90'ının artık QUIC kullandığını söylüyor. Aynı sunumda, sayfaların gQUIC aracılığıyla yaklaşık %5 daha hızlı yüklendiğini ve video akışında TCP'ye kıyasla %30 daha az takılma olduğunu bildiriyorlar.
2017 yılında Arash Molavi Kakhki liderliğindeki bir grup araştırmacı şunları yayınladı: TCP ile karşılaştırıldığında gQUIC'in performansını incelemek.
Çalışma, ağ paketlerinin karıştırılmasındaki istikrarsızlık, kanal bant genişliği konusundaki açgözlülük (haksızlık) ve küçük (10 kb'ye kadar) nesnelerin daha yavaş aktarımı gibi gQUIC'in çeşitli zayıflıklarını ortaya çıkardı. Ancak ikincisi 0-RTT kullanılarak telafi edilebilir. İncelenen diğer tüm durumlarda gQUIC, TCP'ye kıyasla hızda bir artış gösterdi. Burada belirli rakamlardan bahsetmek zor. Daha iyi oku veya .
Burada bu verilerin özellikle gQUIC ile ilgili olduğunu ve geliştirilmekte olan standartla ilgili olmadığını söylemek gerekir. QUIC için ne olacak: Bu hâlâ bir sır, ancak gQUIC'de belirlenen zayıflıkların dikkate alınıp düzeltileceğine dair umut var.
Gelecekten bir kesit: Peki ya HTTP/3?
Ancak burada her şey çok açık: API hiçbir şekilde değişmeyecek. Her şey HTTP/2'dekiyle tamamen aynı kalacak. API aynı kalırsa, HTTP/3'e geçişin arka uçta QUIC aktarımını destekleyen yeni bir kitaplık sürümü kullanılarak çözülmesi gerekecektir. Doğru, eski HTTP sürümlerine geri dönüşü bir süre daha tutmanız gerekecek, çünkü İnternet şu anda UDP'ye tam geçişe hazır değil.
Zaten kim destekliyor
Burada mevcut QUIC uygulamaları. Bir standart olmamasına rağmen liste fena değil.
Şu anda hiçbir tarayıcı üretim sürümünde QUIC'i desteklememektedir. Son zamanlarda Chrome'da HTTP/3 desteğinin bulunduğuna dair bilgiler vardı, ancak şu ana kadar yalnızca Canary'de.
Arka uçlardan HTTP/3 yalnızca şunları destekler: и , ama yine de deneysel. NGINX 2019 baharının sonunda HTTP/3 desteği üzerinde çalışmaya başladıklarını ancak henüz bitirmediklerini söyledi.
Sorun ne?
Siz ve ben, hiçbir büyük teknolojinin direnişle karşılaşmadan kitlelere ulaşamayacağı gerçek dünyada yaşıyoruz ve QUIC de bir istisna değil.
En önemli şey, tarayıcıya "https://"nin artık bir gerçek olmadığını, TCP bağlantı noktası 443'e yönlendirdiğini bir şekilde açıklamanız gerektiğidir. Hiç TCP olmayabilir. Bunun için Alt-Svc başlığı kullanılır. Tarayıcıya, bu web sitesinin şu ve şu protokolde şu adreste de mevcut olduğunu söylemenizi sağlar. Teorik olarak bu bir cazibe gibi çalışmalıdır, ancak pratikte UDP'nin, örneğin DDoS saldırılarını önlemek için bir güvenlik duvarında yasaklanabileceği gerçeğiyle karşılaşacağız.
Ancak UDP yasaklanmamış olsa bile istemci, TCP oturumunu IP adresine göre tutacak şekilde yapılandırılmış bir NAT yönlendiricisinin arkasında olabilir ve bu nedenle donanım oturumu olmayan, NAT bağlantıyı tutmayacak ve QUIC oturumu olan UDP kullanıyoruz .
Tüm bu sorunlar, UDP'nin daha önce İnternet içeriğini iletmek için kullanılmamış olmasından kaynaklanmaktadır ve donanım üreticileri bunun olacağını öngörememektedir. Aynı şekilde, yöneticiler de QUIC'in çalışması için ağlarını nasıl doğru şekilde yapılandıracaklarını henüz tam olarak anlamıyorlar. Bu durum giderek değişecek ve her halükarda bu tür değişiklikler, yeni bir aktarım katmanı protokolünün uygulanmasından daha az zaman alacaktır.
Ek olarak, daha önce açıklandığı gibi QUIC, CPU kullanımını büyük ölçüde artırır. Daniel Stenberg üç kata kadar işlemci büyümesi.
HTTP/3 ne zaman gelecek?
Standart Mayıs 2020'ye kadar, ancak Temmuz 2019 için planlanan belgelerin şu anda tamamlanmamış olduğu göz önüne alındığında, tarihin büyük olasılıkla erteleneceğini söyleyebiliriz.
Google, 2013'ten beri gQUIC uygulamasını kullanıyor. Google arama motoruna gönderilen HTTP isteğine bakarsanız şunu göreceksiniz:
Bulgular
QUIC artık oldukça kaba ama çok umut verici bir teknolojiye benziyor. Son 20 yılda, taşıma katmanı protokollerinin tüm optimizasyonlarının çoğunlukla TCP ile ilgili olduğu göz önüne alındığında, çoğu durumda en iyi performansa sahip olan QUIC, halihazırda son derece iyi görünüyor.
Ancak önümüzdeki birkaç yıl içinde çözülmesi gereken hala çözülmemiş sorunlar var. Kimsenin güncellemeyi sevmediği donanımın söz konusu olması nedeniyle süreç gecikebilir, ancak yine de tüm sorunlar oldukça çözülebilir görünüyor ve er ya da geç hepimiz HTTP/3'e sahip olacağız.
Gelecek çok yakında!
Kaynak: habr.com
