Вече повече от 20 години разглеждаме уеб страници по протокола HTTP. Повечето потребители изобщо не се замислят какво е това и как работи. Други знаят, че под HTTP се намира TLS, а под него TCP, след което IP и така нататък. А трети – еретици – смятат, че TCP е отминал век, искат нещо по-бързо, надеждно и защитено. Но в опитите си да изобретят новия идеален протокол, те се върнаха към технологиите от 80-те години и се опитват да изградят своя чудесен нов свят върху тях.
Няколко факта от историята: HTTP/1.1
През 1997 година протоколът за обмен на текстова информация HTTP версия 1.1 получи своя RFC. В този момент протоколът вече се използваше от браузърите няколко години, а новият стандарт се запази още петнадесет. Протоколът функционираше само на принципа зa запитване-отговор и беше предназначен главно за предаване на текстова информация.
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 година Jim Roskind представи на широката общественост , а вече през 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, като нестабилност при разбъркване на мрежови пакети, алчност (неравноправие) на пропускателната способност на канала и по-бавно предаване на малки (до 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.
От бекендовете HTTP/3 поддържа само и , но все пак експериментално. NGINX в края на пролетта на 2019 година , че са започнали работа по поддръжка на HTTP/3, но все още не са завършили.
Какви са проблемите
Живеем в реален свят, където нито една голяма технология не може да достигне масите, без да срещне съ opост, и QUIC не е изключение.
Най-важното е, че трябва да обясним на браузъра, че “https://” вече не е задължително да води до 443-ия TCP порт. Там изобщо може да няма TCP. За тази цел се използва заглавието Alt-Svc. То позволява на браузъра да знае, че този уебсайт е достъпен и на определен протокол на определен адрес. На теория това трябва да работи безпроблемно, но на практика можем да се сблъскаме с факта, че UDP може, например, да бъде забранен от защитната стена за избягване на DDoS атаки.
Но дори и ако UDP не е забранен, клиентът може да бъде зад NAT рутер, който е настроен да задържа TCP сесия по IP адрес, а тъй като ние използваме UDP, в който няма хардуерна сесия, NAT няма да може да поддържа връзката, и QUIC сесията .
Всички тези проблеми са свързани с факта, че UDP не е използван преди за предаване на интернет съдържание, и производителите на хардуер не можеха да предвидят, че нещо такова ще се случи. По същия начин администраторите все още не разбират добре как да конфигурират мрежите си за работа с QUIC. Тази ситуация бавно ще се променя и, в крайна сметка, такива промени ще отнемат по-малко време отколкото внедряването на нов протокол на транспортно ниво.
Освен това, както вече беше описано, QUIC значително увеличава използването на процесора. Daniel Stenberg ръст по процесора до три пъти.
Кога ще настъпи HTTP/3
Стандарт към май 2020 г., но, като се има предвид, че към момента все още не са завършени документите, планирани за юли 2019 г., може да се каже, че датата вероятно ще бъде отложена.
Но Google използва своята реализация на gQUIC от 2013 г. Ако погледнете HTTP заявката, която се изпраща до търсачката на Google, можете да видите това:
Изводи
QUIC в момента изглежда като доста неусъвършенствана, но много обещаваща технология. Имайки предвид, че последните 20 години всички оптимизации на транспортните протоколи се отнасят основно до TCP, QUIC, който в повечето случаи печели по производителност, изглежда вече сега изключително обещаващо.
Въпреки това все още остават нерешени проблеми, с които ще трябва да се справим в следващите няколко години. Процесът може да се забави заради хардуера, който никой не обича да обновява, но все пак всички проблеми изглеждат напълно решими и рано или късно всички ние ще имаме HTTP/3.
Бъдещето не е далеч!
Източник: habr.com
