HTTP/3.0 получи предложен стандартен статус

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 за уеб, като решава проблеми с дълга настройка на връзката и времена за преговори в TCP и елиминира закъсненията при загуба на пакети по време на пренос на данни.

HTTP/3.0 получи предложен стандартен статус

Понастоящем поддръжката на QUIC и HTTP/3.0 вече е внедрена във всички популярни уеб браузъри (в Chrome, Firefox и Edge поддръжката на HTTP/3 е активирана по подразбиране, а в Safari изисква настройката „Разширени > Експериментални функции > HTTP/3” да бъде активиран). От страна на сървъра са налични HTTP/3 реализации за nginx (в отделен клон и под формата на отделен модул), Caddy, IIS и LiteSpeed. Поддръжката на HTTP/3 също се предоставя от мрежата за доставка на съдържание Cloudflare.

Основни характеристики на QUIC:

  • Висока сигурност, подобна на TLS (всъщност QUIC предоставя възможност за използване на TLS през UDP);
  • Контрол на целостта на потока за предотвратяване на загуба на пакети;
  • Възможност за незабавно установяване на връзка (0-RTT, в приблизително 75% от случаите данните могат да бъдат предадени веднага след изпращане на пакета за настройка на връзката) и осигуряване на минимални закъснения между изпращане на заявка и получаване на отговор (RTT, Round Trip Time);
    HTTP/3.0 получи предложен стандартен статус
  • Използване на различен пореден номер при повторно предаване на пакет, което избягва двусмислието при идентифицирането на получените пакети и премахва изчакванията;
  • Загубата на пакет засяга само доставката на свързания с нея поток и не спира доставката на данни в потоци, предавани паралелно през текущата връзка;
  • Инструменти за коригиране на грешки, които минимизират закъсненията поради повторно предаване на изгубени пакети. Използване на специални кодове за коригиране на грешки на ниво пакет, за да се намалят ситуациите, които изискват повторно предаване на изгубени пакети данни.
  • Границите на криптографските блокове са подравнени с границите на QUIC пакетите, което намалява влиянието на загубата на пакети върху декодирането на съдържанието на следващите пакети;
  • Няма проблеми с блокирането на TCP опашката;
  • Поддръжка на Connection ID за намаляване на времето за повторно свързване за мобилни клиенти;
  • Възможност за свързване на усъвършенствани механизми за контрол на претоварването на връзката;
  • Използване на техники за предсказване на честотната лента във всяка посока, за да се осигури оптимална интензивност на изпращане на пакети, предотвратяване на преминаване в състояние на задръстване, при което има загуба на пакети;
  • Значително увеличение на производителността и пропускателната способност в сравнение с TCP. За видео услуги като YouTube е показано, че QUIC намалява операциите за повторно буфериране при гледане на видеоклипове с 30%.

Сред промените в спецификацията HTTP/1.1 може да се отбележи забраната за изолирано използване на знака за връщане на каретката (CR) извън тялото със съдържание, т.е. В елементите на протокола символът CR може да се използва само заедно със знака за подаване на ред (CRLF). Алгоритъмът за оформление на разкъсани заявки е подобрен, за да опрости разделянето на прикачени полета и секции със заглавки. Добавени са препоръки за обработка на двусмислено съдържание за блокиране на атаки „HTTP Request Smuggling“, които ни позволяват да се вклиним в съдържанието на заявките на други потребители в потока между фронтенда и бекенда.

Актуализацията на спецификацията HTTP/2.0 изрично дефинира поддръжка за TLS 1.3. Отхвърлена схемата за приоритизиране и свързаните полета на заглавката. Неизползваният механизъм за обновяване на връзката с HTTP/1.1 е обявен за остарял. Намалени изисквания за проверка на имена и стойности на полета. Предлагат се за използване някои предварително запазени типове рамки и параметри. По-прецизно са дефинирани забранените заглавни полета, свързани с връзката.

Източник: opennet.ru

Добавяне на нов коментар