Artıq 20 ildən çoxdur ki, HTTP protokolu ilə veb-səhifələrə baxırıq. Çoxsaylı istifadəçi bunun nə olduğunu və necə işlədiyini düşünmür. Bəziləri bilirlər ki, HTTP-nin altında TLS, onun altında TCP, onun altında isə IP var. Bəziləri, yəni burada əhəmiyyətli olanlar, TCP-nin artıq keçmişdə qaldığını düşünür, daha sürətli, etibarlı və təhlükəsiz bir şey axtarırlar. Lakin yeni ideal protokolu icad etmək cəhdlərində 80-ci illərin texnologiyalarına qayıdırlar və bu texnologiyalardan öz yeni dünyalarını qurmağa çalışırlar.
Bir az tarix: HTTP/1.1
1997-ci ildə HTTP-nin 1.1 versiyası üçün mətn mübadiləsi protokolu RFC almışdır. O zaman protokol, artıq bir neçə ildir ki, brauzerlərdə istifadə olunurdu və yeni standart daha 15 il davam etdi. Protokol yalnız sorğu-cavab prinsipi ilə işləyirdi və əsasən mətn məlumatlarının ötürülməsi üçün nəzərdə tutulmuşdu.
HTTP TCP protokolu üzərində işləmək üçün hazırlanmışdır ki, bu da paketlərin qəbul olunmasını etibarlı şəkildə təmin edir. TCP-nin işi, son nöqtələr arasında etibarlı bir əlaqə yaradılması və trafiklərin seqmentlərə bölünməsidir. Hər bir seqmentin ardıcıl nömrəsi və yoxlama cəmi var. Əgər təsadüfən seqmentlərdən biri gəlməsə və ya səhv yoxlama cəmi ilə gəlsə, ötürmə dayanacaq və itirilmiş seqment bərpa olunana qədər gözləniləcək.
HTTP/1.0-da TCP əlaqəsi hər sorğudan sonra bağlanırdı. Bu, son dərəcə resurs israfıdır, çünki TCP bağlantısının qurulması (3-Way-Handshake) sürətli bir proses deyil. HTTP/1.1-də keep-alive mexanizmi təqdim edildi, hansı ki, bir əlaqəni bir neçə sorğu üçün yenidən istifadə etməyə imkan tanıyır. Lakin bu, asanlıqla dar bir yerdə çərrəngə çevrilə bilər, fərqli HTTP/1.1 imlementasiyalarında bir hosta bir neçə TCP əlaqəsinin açılması icazə verilir. Məsələn, Chrome və son Firefox versiyalarında altı əlaqəyə qədər icazə verilir.
Şifrələmə də başqa protokollara tapşırılmalı idi və bunun üçün TCP-nin üzərində TLS protokolu istifadə olunmağa başladı, hansı ki, məlumatları kifayət qədər etibarlı şəkildə qoruyur, lakin əlaqənin qurulması üçün lazım olan vaxtı daha da artırır. Nəticədə, əl sıxışmaq prosesi belə görünməyə başladı:
Cloudflare İllüstrasiyası
Beləliklə, HTTP/1.1 bir sıra problemlərlə üzləşirdi:
- Yavaş əlaqə qurma prosesi.
- Məlumatlar mətn formasında ötürülür, bu da şəkillər, videolar və digər qeyri-mətn məlumatlarının effektiv ötürülməməsi deməkdir.
- Bir TCP əlaqəsi bir sorğu üçün istifadə edilir, yəni digər sorğular ya başqa bir əlaqə tapmalı, ya da cari sorğunun buraxılmasını gözləməlidir.
- Yalnız pull modelini dəstəkləyir. Standartda server-yetirmə ilə bağlı bir şey yoxdur.
- Başlıqlar mətn şəklində ötürülür.
Server-push, on the other hand, is partially implemented using the WebSocket protocol, but other issues needed to be addressed more radically.
A touch of modernity: HTTP/2
In 2012, Google started work on the SPDY protocol (pronounced 'speedy'). This protocol aimed to solve the main issues of HTTP/1.1 while maintaining backward compatibility. In 2015, the IETF working group presented the HTTP/2 specification, based on the SPDY protocol. Here are the differences in HTTP/2:
- Binary serialization.
- Multiplexing multiple HTTP requests over a single TCP connection.
- Server-push out of the box (without WebSocket).
The protocol marked a significant step forward. It dramatically and doesn't require the creation of multiple TCP connections: all requests to a single host are multiplexed into one. This means that within one connection, there are several streams, each with its own ID. Additionally, you get built-in server-push.
However, multiplexing leads to another critical issue. Imagine we're asynchronously sending 5 requests to a single server. When using HTTP/2, all these requests will be executed within a single TCP connection. This means that if one segment of any request gets lost or arrives incorrectly, the transmission of all requests and responses will halt until the lost segment is recovered. It's clear that the worse the connection quality, the slower HTTP/2 performs. , if 2% of packets are lost, HTTP/1.1 performs better in the browser than HTTP/2 because it opens 6 connections instead of one.
This issue is called 'head-of-line blocking,' and unfortunately, it's not possible to solve it when using TCP.
Illustration by Daniel Steinberg
As a result, the developers of the HTTP/2 standard did immense work and accomplished nearly everything that could be done at the application layer of the OSI model. It’s time to descend to the transport layer and invent a new transport protocol.
We need a new protocol: UDP vs TCP
It quickly became clear that implementing a completely new transport layer protocol is a daunting task in today's realities. The thing is, transport layer devices like routers, firewalls, and NAT servers understand a lot about it, and teaching them anything new is a rather complicated task. Moreover, transport protocol support is embedded in the core of operating systems, and those cores are not eager to change either.
Burada əllərimizi buraxıb "Biz, əlbəttə ki, yeni HTTP/3-ü lüzumsuz şəkildə icad edəcəyik, amma bu, 10-15 il ərzində tətbiq olunacaq (bu müddət ərzində əksər avadanlıqlar dəyişdiriləcək)" demək olardı, amma daha az aşkar bir variant var: UDP protokolundan istifadə etmək. Bəli, bəli, 90-cı illərin sonlarında, 2000-ci illərin əvvəllərində yerli şəbəkədə faylları atdığımız protokol. Hazırda mövcud olan əksər avadanlıqlar bu protokolla işləməyə qabildir.
UDP-nin TCP-ya nisbətən üstünlükləri nələrdir? İlk növbədə, bizdə avadanlıq tərəfindən tanınan bir nəqliyyat səviyyəsi sessiyası yoxdur. Bu, bizə nəticə nöqtələrində sessiyaları özümüz müəyyənləşdirmək və meydana gələn münaqişələri orada idarə etməyə imkan verir. Yəni, TCP-dən fərqli olaraq, bir və ya bir neçə sessiya ilə məhdudlaşmırıq, ehtiyacımız olan qədər çox sessiya yarada bilərik. İkinci, UDP vasitəsilə məlumatların ötürülməsi TCP-dən daha sürətlidir. Beləliklə, nəzəri cəhətdən, biz bu gün HTTP/2-də əldə olunmuş sürət limitini qıra bilərik.
Ancaq UDP məlumatların ötürülməsinin etibarlılığını təmin etmir. Əslində, biz sadəcə paketləri göndəririk, ümid edərək ki, onların digər tərəfində qəbul ediləcək. Əgər qəbul olunmayıb? Yaxşı, başımız bəxtə düşmədi… Bu, yetərlidir böyüklər üçün video ötürmək üçün, amma daha ciddi şeylər üçün etibarlılıq lazımdır, bu da deməkdir ki, UDP-nin üstündə əlavə bir şey düzəltmək lazım olacaq.
HTTP/2 ilə olduğu kimi, yeni protokolun yaradılması üzərində iş 2012-ci ildən Google-da başlayıb, yəni SPDY-yə iş başlandığı vaxtla eyni dövrdə. 2013-cü ildə Jim Roskind geniş ictimaiyyətə təqdim etdi. , artıq 2015-ci ildə IETF-də standartlaşdırma üçün Internet Draft təqdim olundu. O dövrdə Roskind tərəfindən Google-də hazırlanmış protokol standartlaşdırmağa təqdim edilən variantdan çox fərqlənirdi, buna görə də Google versiyası gQUIC adını aldı.
QUIC nədir
Birincisi, artıq qeyd olunduğu kimi, UDP-nin üstündəki bir örtükdür. UDP-nin üstündə QUIC əlaqəsi qurulur, burada HTTP/2-yə bənzər bir neçə axın ola bilər. Bu axınlar yalnız nəticə nöqtələrində mövcuddur və müstəqil şəkildə xidmət edilir. Əgər bir axında paket itirildiyi halda, digər axınlardan heç biri bundan təsirlənmir.
Illustration by Daniel Steinberg
İkincisi, şifreleme artık ayrı bir katman olarak değil, protokolün içine entegre edilmiştir. Bu, bağlantı kurmayı ve genel anahtar alışverişini tek bir el sıkışmasıyla yapmayı mümkün kılar ve ayrıca hileli bir 0-RTT el sıkışma mekanizmasını kullanarak el sıkışma sırasında gecikmelerden tamamen kaçınmayı sağlar. Ayrıca, artık ayrı veri paketlerini şifrelemek mümkündür. Bu, veri akışından veri alma işleminde bitiş beklemek istemeden alınan paketleri bağımsız olarak şifrelemeye olanak tanır. Bu çalışma modu TCP'de aslında mümkün değildi çünkü TLS ve TCP bağımsız olarak çalışıyordu ve TLS, TCP'nin hangi parçalara ayrılacağını bilemediği için kendi segmentlerini, TCP segmentleriyle birebir örtüşecek şekilde hazırlayamazdı ve bağımsız olarak şifrelenemezdi. Tüm bu iyileştirmeler, QUIC'in gecikmeyi TCP'ye kıyasla azaltmasını sağlar.
Üçüncüsü, hafif akışlar kavramı, bağlantıyı istemcinin IP adresinden bağımsız hale getirmektedir. Bu, örneğin, bir istemcinin bir Wi-Fi erişim noktasından diğerine geçerken IP'sinin değişmesi durumunda önemlidir. Bu durumda, TCP kullanıldığında mevcut TCP bağlantıları zaman aşımına uğrayarak kopar ve yeni bağlantılar yeni IP ile oluşturulur. QUIC kullanıldığında ise, istemci sadece eski akış ID'siyle yeni IP'den sunucuya paketler göndermeye devam eder. Artık akış ID'si benzersiz ve yeniden kullanılmadığı için, sunucu istemcinin IP değişikliğini anlar, kaybolan paketleri tekrar gönderir ve yeni adres üzerinden iletişime devam eder.
Dördüncüsü, QUIC uygulama katmanında uygulanır, işletim sistemi seviyesinde değil. Bu, bir yandan protokollerde daha hızlı değişiklikler yapılmasını sağlar çünkü güncellemeyi almak için yapmanız gereken tek şey kütüphaneyi güncellemektir, yeni bir işletim sistemi sürümünü beklemekten kaynaklanan gecikme yoktur. Diğer yandan, bu işlemci tüketiminde önemli bir artışa yol açar.
Ve son olarak, başlıklar. Başlıkların sıkıştırılması, QUIC ve gQUIC arasındaki farklılıklara ilişkin konulara bir örnek teşkil eder. Bu konuya çok fazla zaman ayırmanın anlamı yok, sadece şunu söyleyebilirim ki, standartlaştırma için sunulan versiyonda başlık sıkıştırması, HTTP/2'deki başlık sıkıştırmasına mümkün olduğunca benzeyecek şekilde yapılmıştır. Daha detaylı bilgi için .
Ne kadar hızlıdır?
Bu zor bir soru. Gerçek şu ki, henüz bir standart olmadığından, ölçebileceğimiz pek bir şey yok. Muhtemelen elimizdeki tek istatistiksel veri, 2013 yılından beri gQUIC kullanan Google'ın istatistikleridir ve 2016 yılında , Chrome tarayıcısından gelen sunucularına giden trafiğin yaklaşık 'ının artık QUIC kullandığını belirtti. Aynı sunumda gQUIC üzerinden sayfaların TCP'ye göre yaklaşık %5 daha hızlı yüklendiğini ve akış videolarında daha az kesinti yaşandığını bildirdiler.
2017 yılında Arash Molavi Kakhki liderliğindeki bir araştırmacı grubu yayımladı. gQUIC-in TCP ilə müqayisədə performansını öyrənmə üzrə.
Tədqiqat gQUIC-in bir neçə zəif tərəfini ortaya çıxartdı, məsələn, şəbəkə paketlərinin qarışmasına qarşı davamlı olmama, kanalın bant genişliyinə qarşı ədalətsizlik (unfairness) və kiçik (10 kB-ə qədər) obyektlərin daha yavaş ötürülməsi. Sonuncunun, bununla birlikdə, 0-RTT vasitəsilə kompensasiya oluna biləcəyini qeyd etmək lazımdır. Təhlil edilən digər hallarda gQUIC TCP ilə müqayisədə sürət artımı göstərmişdir. Konkret rəqəmlər haqqında danışmaq çətindir. Daha yaxşıdır ki, və .
Burada demək lazımdır ki, bu gQUIC ilə bağlı məlumatdır və onların mövcud standart üçün aktual olduğunu söyləmək olmaz. QUIC üçün nələrin olacağı: hələ də sirr olaraq qalır, amma gQUIC-də aşkarlanan zəif tərəflərin nəzərə alınacağı və düzəldiləcəyi ümid edilir.
Bir az gələcək: HTTP/3 ilə nə olacaq?
Burada hər şey aydındır: API heç bir şəkildə dəyişməyəcək. Hər şey əvvəlki kimi, HTTP/2-də olduğu kimi qalacaq. Əgər API dəyişməzsə, HTTP/3-ə keçid arxa planda QUIC-i dəstəkləyən yeni versiya kitabxanasının istifadəsi ilə həyata keçirilməlidir. Ancaq hələ bir müddət köhnə HTTP versiyalarına dəstək saxlamaq lazım olacaq, çünki internet hazırda tam olaraq UDP-yə keçməyə hazır deyil.
Kimlər artıq dəstəkləyir
Burada mövcud QUIC reallıqlarını. Standartın olmamasına baxmayaraq, yaxşı bir siyahıdır.
Hal-hazırda heç bir brauzer QUIC-i istehsal versiyasında dəstəkləmir. Yaxınlarda Chrome-da HTTP/3 dəstəyinin aktivləşdirildiyinə dair məlumat var, amma indiki vaxtda yalnız Canary-də.
HTTP/3-ü dəstəkləyən arxa planda yalnız və , amma hələlik eksperimental. NGINX 2019-cu ilin yazının sonunda , HTTP/3 dəstəyi ilə işləməyə başladığını bildirdi, amma hələ tamamlamayıb.
Hansı problemlər var
Biz real dünyada yaşayırıq, burada heç bir böyük texnologiya kütləyə keçmədən əvvəl müqavimətlə qarşılaşmır, QUIC də istisna deyil.
Ən vacib məsələ, brauzerə “https://”-nin artıq 443 TCP portuna yönəlmədiyini necə izah etməkdir. Orada TCP olmaya da bilər. Bunun üçün Alt-Svc başlığı istifadə edilir. Bu, brauzerə bu veb saytının belə bir protokoldan belə bir ünvanda da mövcud olduğunu bildirməyə imkan verir. Nəzəriyyə baxımından bunun asan işləməsi lazım olsa da, praktikada UDP-nin DDoS hücumlarından qaçmaq üçün firewall-da qadağan edildiyi ilə qarşılaşa bilərik.
Ancaq UDP qadağan edilməsə belə, müştəri NAT router arxasında ola bilər ki, bu da TCP sessiyasını IP ünvanı vasitəsilə saxlamışdır, və UDP istifadə etdiyimiz üçün, burada heç bir avadanlıq sessiyası olmadığı üçün NAT əlaqəni saxlamayacaq və QUIC sessiyası .
Bütün bu problemlərin səbəbi, UDP-nin əvvəllər internet məzmununun ötürülməsi üçün istifadə edilməməsi və avadanlıq istehsalçılarının bunun bir gün baş verəcəyini gözləməməsi idi. Eynilə, administratorlar da QUIC-in işlədilməsi üçün şəbəkələrinin düzgün şəkildə necə qurulacağına hələ də tam əmin deyillər. Bu vəziyyət yavaş-yavaş dəyişəcək, hər halda, bu cür dəyişikliklər yeni nəqliyyat protokolunun tətbiqindən daha az vaxt alacaq.
Bundan başqa, artıq qeyd edildiyi kimi, QUIC-in prosessor istifadəsini ciddi şəkildə artırır. Daniel Stenberg prosessorun üç dəfə artımını.
HTTP/3 nə vaxt gələcək
Standart 2020-ci ilin mayına qədər, amma, hazırda iyul 2019-a planlaşdırılan sənədlərin henüz tamamlanmamış olması nəzərə alınarsa, tarixın çox güman ki, ertələnəcəyini demək olar.
Google isə 2013-cü ildən etibarən öz gQUIC implementasiyasını istifadə edir. Google axtarış motoruna göndərilən HTTP sorğusuna baxdıqda, bunu görə bilərsiniz:
Sonuçlar
Hal-hazırda QUIC, olduqca xam, amma çox perspektivli bir texnologiya kimi görünür. Son 20 ildə bütün nəqliyyat protokollarının optimizasiyaları əsasən TCP-yə yönəldilib, QUIC isə əksər hallarda performans baxımından üstün olduğundan, artıq olduqca yaxşı görünür.
Ancaq hələ də həll edilməli məsələlər var ki, onların öhdəsindən gəlmək önümüzdəki bir neçə il ərzində lazım olacaq. Prosesi uzada bilər ki, heç kimin sevmədiyi avadanlıq mövcuddur, amma bütün problemlər tamamilə həll edilə bilər görünür və tezliklə hamımızın HTTP/3-ümüz olacaq.
Gələcək uzaqda deyil!
Mənbə: habr.com
