Комитет 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 уже реализована во всех популярных web-браузерах (в Chrome, Firefox и Edge поддержка HTTP/3 включена по умолчанию, а в Safari требует включения настройки «Advanced > Experimental Features > HTTP/3»). На серверной стороне реализации HTTP/3 доступны для nginx (в отдельной ветке и в форме отдельного модуля), Caddy, IIS и LiteSpeed. Поддержку HTTP/3 также обеспечивает сеть доставки контента Cloudflare.
QUIC 的主要特點：
- 類似於 TLS 的高安全性（本質上 QUIC 提供了透過 UDP 使用 TLS 的能力）；
- 流量完整性控制，防止丟包；
- 能夠立即建立連線（0-RTT，在大約 75% 的情況下，可以在發送連線建立資料包後立即傳輸資料）並在發送請求和接收回應之間提供最小的延遲（RTT，往返時間）；
- 重傳資料包時使用不同的序號，這可以避免識別接收到的資料包時出現歧義並消除逾時；
- 資料包遺失僅影響與其關聯的流的傳送，並且不會停止透過目前連接傳輸的平行流中的資料傳送；
- 糾錯功能可最大限度地減少因重傳遺失資料包而導致的延遲。 在資料包層級使用特殊的糾錯碼可以減少需要重傳遺失的資料包資料的情況。
- 密碼塊邊界與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