Вече повече от 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 беше представен механизмът keep-alive, който позволява повторно използване на една връзка за няколко запитвания. Въпреки това, тъй като може лесно да стане бутилката на гърлото, в различни имплементации на HTTP/1.1 се допуска отварянето на множество TCP връзки към един хост. Например, в Chrome и в последните версии на Firefox се допуска до шест връзки.
Шифроването също бе замислено да бъде предоставено на другите протоколи и за целта над TCP се използва протокола TLS, който надеждно защитаваше данните, но още повече увеличаваше времето, необходимо за установяване на връзка. В крайна сметка процесът на ръкостискане изглеждаше така:
Илюстрация на Cloudflare
Следователно HTTP/1.1 имаше редица проблеми:
- Бавно установяване на връзка.
- Данните се предават в текстов вид, следователно предаването на снимки, видеа и друга информация, която не е текстова, е неефективно.
- Едно TCP-съединение се използва за една заявка, следователно останалите заявки трябва или да намерят друго съединение, или да изчакат текущата заявка да освободи връзката.
- Поддържа се само моделът pull. В стандарта няма нищо за server-push.
- Заглавията се предават текстово.
Ако server-push все пак се реализира до известна степен чрез протокола WebSocket, то с останалите проблеми трябваше да се справим по-радикално.
Няколко актуализации: HTTP/2
През 2012 г. в недрата на Google започна работа по протокола SPDY (произнася се «спиди»). Протоколът беше създаден да решава основните проблеми на HTTP/1.1 и в същото време трябваше да запази обратната съвместимост. През 2015 г. работната група IETF представи спецификацията HTTP/2, базирана на протокола SPDY. Ето какви бяха разликите в HTTP/2:
- Бинарна сериализация.
- Мултиплексиране на няколко HTTP-заявки в едно TCP-съединение.
- Server-push вградена (без WebSocket).
Протоколът направи голяма крачка напред. Той значително и не изисква създаването на множество TCP-съединения: всички заявки към един хост се мултиплексират в едно. Тоест в едно съединение има няколко така наречени стрима, всеки от които има свой ID. Бонусът е опцията server-push.
Все пак мултиплексирането води до друг основен проблем. Представете си, че асинхронно извършваме 5 заявки към един сървър. При използването на HTTP/2 всички тези заявки ще бъдат изпълнени в рамките на едно TCP-съединение, следователно, ако един от сегментите на която и да е заявка се загуби или дойде неправилно, предаването на всички заявки и отговори ще се спре, докато не бъде възстановен загубеният сегмент. Очевидно е, че колкото по-лошо е качеството на съединението, толкова по-бавно работи HTTP/2. , при условия, при които загубените пакети представляват 2% от всичките, HTTP/1.1 в браузъра се представя по-добре от HTTP/2, тъй като отваря 6 съединения, а не едно.
Този проблем се нарича «head-of-line blocking» и, за съжаление, решаването му при използване на TCP не изглежда възможно.
Илюстрация на Даниел Стенберг
В крайна сметка разработчиците на стандарта HTTP/2 свършиха огромна работа и направиха почти всичко, което можеше да бъде направено на приложно ниво на модела OSI. Време е да се спуснем на транспортното ниво и да изобретим нов транспортен протокол.
Нуждаем се от нов протокол: UDP срещу TCP
Става ясно, че внедряването на съвсем нов транспортен протокол – е задача, която в днешните реалности е невъзможна. Причината е, че за транспортното ниво знаят хардуерът или middle-boxes (рутери, фаеролси, NAT-сървъри…), а обучението им на нещо ново е изключително трудно. Освен това поддръжката на транспортните протоколи е вградена в ядрото на операционните системи, а ядрото също не се променя особено охотно.
И тук можеше да се откажем и да кажем 'Разбира се, ще изобретим нов HTTP/3 с преферанс и куртизанки, но внедряването му ще отнеме 10-15 години (приблизително толкова време ще отнеме заменянето на повечето устройства)', но има и едно не толкова очевидно решение: да използваме протокола UDP. Да, точно този протокол, с който си разменяхме файлове по локалката в края на деветнадесетте и началото на нулевите години. Практически всички днешни устройства могат да работят с него.
Какви са предимствата на 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, могат да съществуват няколко потока. Тези потоци съществуват само на краен уред и се обслужват независимо. Ако загуба на пакет се е случила в един поток, другите не са засегнати по никакъв начин.
Илюстрация на Даниел Стенберг
На второ място, криптирането вече не се реализира на отделен слой, а е включено в протокола. Това позволява установяване на връзка и обмен на публични ключове с едно ръкостискане, както и използването на хитър механизъм за 0-RTT handshake, което напълно избягва забавянията при ръкостискането. Освен това вече е възможно да се криптират отделни пакети от данни. Това позволява да не се чака завършването на получаването на данни от потока, а да се декриптират получените пакети независимо. Този режим на работа беше напълно невъзможен в TCP, тъй като TLS и TCP работеха независимо един от друг и TLS не можеше да знае на кои части ще бъдат разделени данните в TCP. Следователно, не можеше да подготви своите сегменти така, че те да съвпадат един към един със сегментите на TCP и да могат да бъдат декриптирани независимо. Всички тези подобрения позволяват на QUIC да намали латентността в сравнение с TCP.
На трето място, концепцията за леки потоци позволява да се отвържат свързванията от IP адреса на клиента. Това е важно, например, когато клиентът преминава от една Wi-Fi точка за достъп на друга, променяйки своя IP. В този случай, когато се използва TCP, се извършва дълъг процес, при който съществуващите TCP свързвания се разпадат поради таймаут и се създават нови свързвания с новия IP. При QUIC клиентът просто продължава да изпраща пакети до сървъра с новия IP и стария ID на потока. Понеже ID на потока вече е уникален и не се преизползва, сървърът разбира, че клиентът е сменил IP, доставя загубените пакети и продължава комуникацията по новия адрес.
Четвърто, QUIC се реализира на ниво приложение, а не на операционна система. От една страна, това позволява по-бързо да се правят промени в протокола, тъй като за актуализация е нужно само да се обнови библиотеката, а не да се изчака нова версия на ОС. От друга страна, това води до значително увеличение на потреблението на процесор.
И накрая, заглавията. Стискаването на заглавията точно попада в категорията, която се различава между QUIC и gQUIC. Нямам намерение да отделям много време за това, просто ще спомена, че в версията, предложена за стандартизация, стискањето на заглавията е направено максимално близко до стискањето в HTTP/2. Повече информация може да се прочете .
Насколько е по-бързо?
Този въпрос е сложен. Фактът е, че докато нямаме стандарт, всъщност нямаме какво да измерваме. Единствените статистически данни, с които разполагаме, са статистиката на Google, който използва gQUIC от 2013 г. и през 2016 , че около 90% от трафика, идващ към техните сървъри от браузъра Chrome, вече използва QUIC. В същата презентация те съобщават, че чрез gQUIC страниците се зареждат приблизително с 5% по-бързо, а за стрийминг видео има 30% по-малко прекъсвания в сравнение с TCP.
През 2017 г. група изследователи, ръководена от Arash Molavi Kakhki, публикува изследване на производителността на gQUIC в сравнение с TCP.
Изследването разкри няколко слабости на gQUIC, като нестабилност при смесване на мрежови пакети, жадност (unfairness) към пропускателната способност на канала и по-бавно предаване на малки (до 10 кб) обекти. Последното обаче може да се компенсира с използването на 0-RTT. Във всички останали случаи gQUIC показа увеличение на бързината в сравнение с TCP. По-конкретни цифри тук е трудно да се обсъждат. Най-добре е да се прочете или .
Тук трябва да се подчертае, че това са данни именно за gQUIC и те не са актуални за разработваната сега стандартизация. Какво ще бъде за QUIC: засега е тайна, но има надежда, че слабостите, открити в gQUIC, ще бъдат взети под внимание и оправени.
Някои бъдещи въпроси: какво става с HTTP/3?
Тук всичко е кристално ясно: API няма да се променя. Всичко ще остане така, както беше в HTTP/2. А ако API остава същият, преминаването към HTTP/3 трябва да се реши чрез използването на нова версия на библиотеката на бекенда, която поддържа транспортиране по QUIC. Вярно е, че ще трябва още дълго да поддържаме фона за старите версии на HTTP, тъй като интернетът в момента не е готов за пълен преход към UDP.
Кой вече поддържа
Ето съществуващите реализации на QUIC. Въпреки липсата на стандарт, списъкът е доста добър.
В момента нито един браузър не поддържа QUIC в производствена версия. Наскоро имаше информация, че в Chrome е включена поддръжка на HTTP/3, но засега само в Canary.
От бекендовете само и , но все още експериментално. NGINX в края на пролетта на 2019 г. , че започнаха работа по поддръжката на HTTP/3, но все още не са завършили.
Какви проблеми има
Ние живеем в реалния свят, където нито една голяма технология не може да пробие в масите, без да срещне съпротива, и QUIC не е изключение.
Най-важното е, че трябва по някакъв начин да обясним на браузъра, че “https://” вече не е факт, че води до 443-ти TCP порт. Там изобщо може и да няма 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.
Бъдещето е на прага!
Източник: habr.com
