Повече от 20 години преглеждаме уеб страници, използвайки HTTP протокола. Повечето потребители дори не се замислят какво представлява и как работи. Други знаят, че някъде под HTTP има TLS, а под него е TCP, под който е IP и т.н. А трети - еретици - вярват, че TCP е нещо от миналото; искат нещо по-бързо, по-надеждно и сигурно. Но в опитите си да измислят нов идеален протокол, те се върнаха към технологията от 80-те и се опитват да изградят своя смел нов свят върху нея.
Малко история: HTTP/1.1
През 1997 г. протоколът за обмен на текстова информация HTTP версия 1.1 придобива собствен RFC. По това време протоколът се използва от браузърите от няколко години, а новият стандарт продължи още петнадесет. Протоколът работеше само на принципа заявка-отговор и беше предназначен главно за предаване на текстова информация.
HTTP е проектиран да работи върху TCP протокола, като гарантира, че пакетите се доставят надеждно до местоназначението си. TCP работи, като установява и поддържа надеждна връзка между крайните точки и разделя трафика на сегменти. Сегментите имат собствен сериен номер и контролна сума. Ако внезапно един от сегментите не пристигне или пристигне с неправилна контролна сума, тогава предаването ще спре, докато изгубеният сегмент не бъде възстановен.
В HTTP/1.0 TCP връзката се затваряше след всяка заявка. Това беше изключително разточително, защото... установяването на TCP връзка (3-Way-Handshake) е бавен процес. HTTP/1.1 въведе механизма за поддържане на активност, който ви позволява да използвате повторно една връзка за множество заявки. Въпреки това, тъй като лесно може да се превърне в пречка, различните реализации на HTTP/1.1 позволяват отварянето на множество TCP връзки към един и същи хост. Например Chrome и последните версии на Firefox позволяват до шест връзки.
Криптирането също трябваше да бъде оставено на други протоколи и за това беше използван TLS протоколът над TCP, който надеждно защити данните, но допълнително увеличи времето, необходимо за установяване на връзка. В резултат на това процесът на ръкостискане започна да изглежда така:
Илюстрация на Cloudflare
Така HTTP/1.1 имаше редица проблеми:
- Настройка на бавна връзка.
- Данните се предават в текстова форма, което означава, че предаването на снимки, видеоклипове и друга нетекстова информация е неефективно.
- Една TCP връзка се използва за една заявка, което означава, че другите заявки трябва или да намерят друга връзка, или да изчакат, докато текущата заявка я освободи.
- Поддържа се само моделът за изтегляне. В стандарта няма нищо за натискане на сървъра.
- Заглавията се предават в текст.
Ако натискането на сървъра се реализира поне с помощта на протокола WebSocket, тогава останалите проблеми трябваше да бъдат решени по-радикално.
Малко модерност: HTTP/2
През 2012 г. Google започна да работи по протокола SPDY (произнася се „бърз“). Протоколът е предназначен да разреши основните проблеми на HTTP/1.1 и в същото време трябваше да поддържа обратна съвместимост. През 2015 г. работната група на IETF въведе спецификацията HTTP/2, базирана на протокола SPDY. Ето разликите в HTTP/2:
- Двоична сериализация.
- Мултиплексиране на множество HTTP заявки в една TCP връзка.
- Сървърно изтласкване от кутията (без WebSocket).
Протоколът беше голяма крачка напред. Той силно и не изисква създаване на множество TCP връзки: всички заявки към един хост се мултиплексират в една. Тоест в една връзка има няколко така наречени потока, всеки от които има свой собствен идентификатор. Бонусът е натискане на сървър в кутия.
Мултиплексирането обаче води до друг ключов проблем. Представете си, че асинхронно изпълняваме 5 заявки към един сървър. Когато използвате HTTP/2, всички тези заявки ще бъдат извършени в рамките на една и съща TCP връзка, което означава, че ако един от сегментите на която и да е заявка бъде загубен или получен неправилно, предаването на всички заявки и отговори ще спре, докато изгубеният сегмент бъде изгубен възстановен. Очевидно, колкото по-лошо е качеството на връзката, толкова по-бавно работи HTTP/2. , в условия, при които изгубените пакети представляват 2% от всички пакети, HTTP/1.1 в браузъра се представя по-добре от HTTP/2 поради факта, че отваря 6 връзки, а не една.
Този проблем се нарича „блокиране на начален ред“ и, за съжаление, не е възможно да бъде решен при използване на TCP.
Илюстрация от Daniel Steinberg
В резултат на това разработчиците на стандарта HTTP/2 свършиха страхотна работа и направиха почти всичко, което можеше да се направи на приложния слой на OSI модела. Време е да слезем на транспортния слой и да измислим нов транспортен протокол.
Имаме нужда от нов протокол: UDP срещу TCP
Доста бързо стана ясно, че внедряването на напълно нов протокол на транспортния слой е невъзможна задача в днешните реалности. Факт е, че хардуерът или средните кутии (рутери, защитни стени, NAT сървъри...) знаят за транспортния слой и обучението им на нещо ново е изключително трудна задача. В допълнение, поддръжката на транспортни протоколи е вградена в ядрото на операционните системи, а ядрата също не са много склонни да се променят.
И тук човек може да вдигне ръце и да каже: „Ние, разбира се, ще измислим нов HTTP/3 с преференции и куртизанки, но ще отнеме 10-15 години, за да бъде внедрен (след горе-долу по-голямата част от хардуера ще бъде заменен), но има още един не толкова. Очевидният вариант е да използвате UDP протокола. Да, да, същият протокол, който използвахме за хвърляне на файлове през LAN в края на XNUMX-те и началото на XNUMX-те. Почти целият съвременен хардуер може да работи с него.
Какви са предимствата на UDP пред TCP? Първо, нямаме сесия на транспортен слой, за която хардуерът да знае. Това ни позволява сами да определяме сесията на крайните точки и да разрешаваме конфликти там. Тоест ние не сме ограничени до една или няколко сесии (както е в TCP), а можем да създадем толкова от тях, колкото са ни необходими. Второ, предаването на данни чрез UDP е по-бързо, отколкото чрез TCP. Така на теория можем да пробием текущия таван на скоростта, постигнат в HTTP/2.
UDP обаче не гарантира надеждно предаване на данни. Всъщност ние просто изпращаме пакети, надявайки се, че другият край ще ги получи. Не сте получили? Е, няма късмет... Това беше достатъчно за предаване на видео за възрастни, но за по-сериозни неща трябва надеждност, което означава, че трябва да опаковате нещо друго върху UDP.
Както при HTTP/2, работата по създаването на нов протокол започна в Google през 2012 г., тоест приблизително по същото време, когато започна работата по SPDY. През 2013 г. Джим Роскинд представи на широката публика , а още през 2015 г. беше въведен Internet Draft за стандартизация в IETF. Още по това време протоколът, разработен от Роскинд в Google, беше много различен от стандарта, така че версията на Google започна да се нарича gQUIC.
Какво е QUIC
Първо, както вече споменахме, това е обвивка над UDP. Върху UDP се издига QUIC връзка, в която, по аналогия с HTTP/2, могат да съществуват няколко потока. Тези потоци съществуват само в крайните точки и се обслужват независимо. Ако възникне загуба на пакет в един поток, това няма да засегне други.
Илюстрация от Daniel Steinberg
Второ, криптирането вече не се прилага на отделно ниво, а е включено в протокола. Това ви позволява да установите връзка и да обмените публични ключове с едно ръкостискане, а също така ви позволява да използвате интелигентния механизъм за ръкостискане 0-RTT и да избегнете напълно забавянето на ръкостискането. Освен това вече е възможно да се криптират отделни пакети данни. Това ви позволява да не чакате завършването на получаването на данни от потока, а да дешифрирате получените пакети независимо. Този режим на работа като цяло беше невъзможен в TCP, т.к TLS и TCP работеха независимо един от друг и TLS не можеше да знае на какви части TCP данните ще бъдат нарязани. И следователно той не можа да подготви сегментите си така, че да се поберат в TCP сегменти едно към едно и да могат да бъдат дешифрирани независимо. Всички тези подобрения позволяват на QUIC да намали латентността в сравнение с TCP.
Трето, концепцията за светлинно поточно предаване ви позволява да отделите връзката от IP адреса на клиента. Това е важно, например, когато клиент превключва от една Wi-Fi точка за достъп към друга, променяйки своя IP. В този случай, когато се използва TCP, възниква дълъг процес, по време на който съществуващите TCP връзки изтекат и се създават нови връзки от нов IP. В случай на QUIC, клиентът просто продължава да изпраща пакети към сървъра от нов IP адрес със стария идентификатор на потока. защото Идентификационният номер на потока вече е уникален и не се използва повторно; сървърът разбира, че клиентът е променил IP, изпраща повторно изгубени пакети и продължава комуникацията на новия адрес.
Четвърто, QUIC се прилага на ниво приложение, а не на ниво операционна система. Това, от една страна, ви позволява бързо да правите промени в протокола, т.к За да получите актуализация, просто трябва да актуализирате библиотеката, вместо да чакате нова версия на ОС. От друга страна, това води до силно увеличение на консумацията на процесори.
И накрая, заглавията. Компресията на заглавието е едно от нещата, които се различават между QUIC и gQUIC. Не виждам смисъл да отделям много време за това, просто ще кажа, че във версията, изпратена за стандартизация, компресията на заглавката беше направена възможно най-подобна на компресията на заглавката в HTTP/2. Можете да прочетете повече .
Колко по-бързо е?
Това е труден въпрос. Факт е, че докато нямаме стандарт, няма какво специално да измерваме. Може би единствената статистика, която имаме, е статистика от Google, която използва gQUIC от 2013 г. и през 2016 г. че около 90% от трафика, отиващ към техните сървъри от браузъра Chrome, сега използва QUIC. В същата презентация те съобщават, че страниците се зареждат с около 5% по-бързо чрез gQUIC и има 30% по-малко заеквания при поточно предаване на видео в сравнение с TCP.
През 2017 г. група изследователи, ръководени от Араш Молави Какки, публикуваха за изследване на ефективността на gQUIC в сравнение с TCP.
Проучването разкрива няколко слабости на gQUIC, като нестабилност при смесването на мрежови пакети, алчност (несправедливост) към честотната лента на канала и по-бавен трансфер на малки (до 10 kb) обекти. Последното обаче може да бъде компенсирано чрез използване на 0-RTT. Във всички други проучени случаи gQUIC показа увеличение на скоростта в сравнение с TCP. Тук е трудно да се говори за конкретни числа. По-добре прочетете или .
Тук трябва да се каже, че тези данни са конкретно за gQUIC и не са от значение за разработвания стандарт. Какво ще се случи с QUIC: все още е тайна, но има надежда, че слабостите, идентифицирани в gQUIC, ще бъдат взети под внимание и коригирани.
Малко от бъдещето: какво ще кажете за HTTP/3?
Но тук всичко е кристално ясно: API няма да се промени по никакъв начин. Всичко ще остане абсолютно същото, както беше в HTTP/2. Е, ако API остане същият, преходът към HTTP/3 ще трябва да бъде решен чрез използване на нова версия на библиотеката в бекенда, която поддържа QUIC транспорт. Вярно е, че ще трябва да запазите резервната версия на старите версии на HTTP за известно време, защото В момента интернет не е готов за пълен преход към UDP.
Който вече подкрепя
тук е съществуващи реализации на QUIC. Въпреки липсата на стандарт, списъкът не е лош.
Понастоящем нито един браузър не поддържа QUIC в производствена версия. Наскоро имаше информация, че поддръжката на HTTP/3 е включена в Chrome, но засега само в Canary.
От бекенда поддържа само HTTP/3 и , но все още е експериментален. NGINX в края на пролетта на 2019 г , че са започнали работа по поддръжката на HTTP/3, но все още не са я завършили.
Какви са проблемите?
Вие и аз живеем в реалния свят, където нито една голяма технология не може да достигне до масите, без да срещне съпротива, и QUIC не е изключение.
Най-важното е, че трябва по някакъв начин да обясните на браузъра, че „https://“ вече не е факт, че води до TCP порт 443. Може изобщо да няма TCP. За това се използва заглавката Alt-Svc. Позволява ви да кажете на браузъра, че този уебсайт също е достъпен по такъв и такъв протокол на такъв и такъв адрес. На теория това трябва да работи като чар, но на практика ще се натъкнем на факта, че UDP може например да бъде забранен на защитна стена, за да се избегнат DDoS атаки.
Но дори ако UDP не е забранен, клиентът може да е зад NAT рутер, който е конфигуриран да поддържа TCP сесия чрез IP адрес, и тъй като използваме UDP, който няма хардуерна сесия, NAT няма да задържи връзката и QUIC сесия .
Всички тези проблеми се дължат на факта, че UDP не е бил използван преди това за предаване на интернет съдържание и производителите на хардуер не са могли да предвидят, че това някога ще се случи. По същия начин администраторите все още не разбират как правилно да конфигурират своите мрежи, за да работи QUIC. Тази ситуация постепенно ще се промени и във всеки случай такива промени ще отнемат по-малко време от внедряването на нов протокол на транспортния слой.
Освен това, както вече беше описано, QUIC значително увеличава използването на процесора. Даниел Стенберг растеж на процесора до три пъти.
Кога ще пристигне HTTP/3?
Стандарт до май 2020 г., но като се има предвид, че документите, планирани за юли 2019 г., остават незавършени в момента, можем да кажем, че датата най-вероятно ще бъде отложена.
Е, Google използва внедряването на gQUIC от 2013 г. Ако погледнете HTTP заявката, която е изпратена до търсачката на Google, ще видите това:
Данни
QUIC сега изглежда като доста груба, но много обещаваща технология. Като се има предвид, че през последните 20 години всички оптимизации на протоколите на транспортния слой се отнасят основно до TCP, QUIC, който в повечето случаи има най-добра производителност, вече изглежда изключително добре.
Все още обаче има нерешени проблеми, които ще трябва да бъдат решени през следващите няколко години. Процесът може да се забави поради факта, че има включен хардуер, който никой не обича да актуализира, но въпреки това всички проблеми изглеждат доста разрешими и рано или късно всички ще имаме HTTP/3.
Бъдещето е точно зад ъгъла!
Източник: www.habr.com