IETF (Internet Engineering Task Force), отговорен за развитието на протоколите и архитектурата на интернет, завърши формирането на RFC за протокол HTTP/3.0 и публикува свързаните с него спецификации с идентификатори RFC 9114 (протокол) и RFC 9204 (технология за компресиране на заглавия QPACK за HTTP/3). Спецификация HTTP/3.0 получи статус „Предложен стандарт“, след което ще започне работа по предоставянето на RFC статуса черновен стандарт (Draft Standard), което фактически означава пълна стабилизация на протокола и отчитане на всички направени забележки. Веднага бяха публикувани и обновените варианти на спецификациите за протоколите HTTP/1.1 (RFC 9112) и HTTP/2.0 (RFC 9113), както и документи, определящи семантиката на HTTP заявките (RFC 9110) и HTTP заглавията за управление на кеширането (RFC 9111).
Протокол HTTP/3 определя използването на протокола QUIC (Quick UDP Internet Connections) като транспорт за HTTP/2. QUIC представлява надстройка на протокола UDP, която поддържа мултиплексиране на няколко връзки и осигурява методи за криптиране, еквивалентни на TLS/SSL. Протоколът е създаден през 2013 година от Google като алтернатива на комбинацията TCP+TLS за Web, решаваща проблемите с голямото време за установяване и съгласуване на връзките в TCP и елиминираща забавянията при загуба на пакети по време на предаване на данни.
В момента поддръжката на QUIC и HTTP/3.0 вече е реализирана във всички популярни уеб браузъри (в Chrome, Firefox и Edge поддръжката на HTTP/3 е активирана по подразбиране, а в Safari изисква включване на настройката „Advanced > Experimental Features > HTTP/3“). От сървърна страна, реализации на HTTP/3 са налични за nginx (в отделна клонка и под формата на отделен модул), Caddy, IIS и LiteSpeed. Поддръжката на HTTP/3 също е осигурена от мрежата за доставка на съдържание Cloudflare.
Основни характеристики на QUIC:
- Висока сигурност, подобна на TLS (по същество QUIC предоставя възможност за използване на TLS над UDP);
- Контрол за целостта на потока, предотвратяващ загуба на пакети;
- Възможността за мигновено установяване на връзка (0-RTT, в около 75% от случаите данните могат да се предават веднага след изпращане на пакета за установяване на връзка) и осигуряване на минимални закъснения между изпращането на заявка и получаването на отговор (RTT, Round Trip Time);
- Използването на друг номер на последователност за повторно предаване на пакета, което позволява да се избегне двусмисленост при определяне на получените пакети и да се премахнат тайм-аутите;
- Загубата на пакет влияе само на доставката на свързания с него поток и не спира доставката на данни в паралелно предавани през текущото съединение потоци;
- Средства за корекция на грешки, минимизиращи забавянията поради повторно предаване на изгубени пакети. Използване на специални кодове за корекция на грешки на ниво пакет, за да се намалят ситуациите, изискващи повторно предаване на данни от изгубения пакет.
- Границите на криптографските блокове са подравнени с границите на QUIC пакетите, което намалява влиянието на загубите на пакети върху декодирането на съдържанието на следващите пакети;
- Липса на проблеми с блокиране на опашката TCP;
- Поддръжка на идентификатор на съединение, позволяваща да се съкрати времето за установяване на повторно съединение за мобилни клиенти;
- Възможност за свързване на разширени механизми за контрол на претоварването на съединението;
- Използване на техника за прогнозиране на пропускната способност във всяка посока за осигуряване на оптимална интензивност на изпращане на пакети, предотвратявайки свличането в състояние на претоварване, при което се наблюдава загуба на пакети;
- Забележимо увеличение на производителността и капацитета в сравнение с TCP. За видеосервизи като YouTube, прилагането на QUIC показа 30% намаление на операциите по повторно буфериране при гледане на видео.
От измененията в спецификацията на HTTP/1.1 може да се отбележи забраната за изолирано използване на символа за връщане на каретката (CR) извън тялото на съдържанието, т.е. в елементите на протокола символ CR може да се използва само заедно със символа за нов ред (CRLF). Алгоритъмът за компониране на chunked заявки е подсилен за улесняване на разделянето на прикрепените полета и секцията с заглавия. Добавени са препоръки за обработка на нееднозначно съдържание за блокиране на атаки от тип „HTTP Request Smuggling“, позволяващи вмешателство в съдържанието на заявките на други потребители в потока между фронтенда и бекенда.
В обновлението на спецификацията HTTP/2.0 е ясно определена поддръжката на TLS 1.3. Прехвърлен е в категорията на остарелите схеми за определяне на приоритети и свързаните с тях полета в заглавките. Остарял е механизмът за обновяване на съединения с HTTP/1.1, който не е получил разпространение. Намалени са изискванията за проверка на имената на полетата и стойностите. Предложени са за употреба някои от преди запазените типове кадри и параметри. По-точно са определени забранените полета в заглавките, свързани със съединението.
Източник: opennet.ru
