QUIC позволяет мгновенно установить повторное соединение (0-RTT) и обеспечивает минимальную задержку между отправкой запроса и получением ответа

Google Chrome Canary стал первым браузером, в который интегрирована (очень) экспериментальная поддержка протокола HTTP/3, где вместо TCP в качестве транспортного уровня используется протокол QUIC.

HTTP/3 — это новый синтаксис HTTP, который работает на IETF QUIC, мультиплексированном и безопасном транспорте на основе UDP. Хотя некоторые разработчики называют QUIC на UDP «дичайшим экспериментом», новый протокол сулит массу преимуществ.

С момента принятия стандарта HTTP/2 прошло три с половиной года: спецификация RFC 7540 опубликована в мае 2015-го, но пока не используется повсеместно. Протокол реализован во всех браузерах ещё с конца 2015 года, а спустя три года только 40,9% из 10 млн самых популярных интернет-сайтов поддерживают HTTP/2.

Создание HTTP/3

Несмотря на принятие HTTP/2 на основе SPDY в качестве стандарта RFC 7540, инженеры Google продолжили эксперименты с ускорением транспорта. До 2015 года они выпустили новые версии SPDY v3 и v3.1, а также начали работать над протоколом gQUIC, первый черновик которого опубликовали в начале 2012 года.

В ранних версиях gQUIC использовался синтаксис HTTP SPDY v3. Такой выбор имел смысл, потому что HTTP/2 ещё не утвердили. Бинарный синтаксис SPDY упакован в пакеты QUIC, которые отправляются в датаграммах UDP. Это отход от транспорта TCP, на который традиционно полагался HTTP. Вся система в сборе выглядела так:


Слоёный пирог SPDY по gQUIC. Иллюстрация из статьи «HTTP/3: от корней до кончиков»

Затем разработку передали в IETF для стандартизации. Здесь она разделилась на две части: транспорт и HTTP. Идея была в том, что транспортный протокол можно использовать также для передачи других данных, а не только эксклюзивно для HTTP или HTTP-подобных протоколов. Однако название осталось таким же: QUIC. Разработкой транспортного протокола занималась рабочая группа QUIC Working Group в Инженерном совета интернета (IETF).

В то же время Google продолжила работу над своей собственной реализацией — и внедрила её в браузер Chrome не дожидаясь стандартизации.



Разноголосицу в версиях и именованиях QUIC объясняет Дэниель Стенберг, ведущий разработчик curl, работающий в Mozilla, который давно следит за этой историей.

По его словам, до стандартизации HTTP/3 в кругу разработчиков получили распространения неформальные названия двух версий QUIC, поскольку варианты от IETF и Google значительно различаются в деталях реализации:

• iQUIC (версия IETF)
  
• gQUIC (версия Google)

Протокол для передачи HTTP по iQUIC (версия IETF) долгое время называли “hq” (HTTP-over-QUIC).

Объединить iQUIC и gQUIC под названием HTTP/3 в сентябре 2018 года предложил Марк Ноттингем, один из самых влиятельных инженеров IETF, соавтор нескольких веб-стандартов. По его словам, это поможет устранить путаницу между QIUC-транспортом и QUIC-оболочкой для HTTP.

Таким образом, HTTP/3 — это новая версия HTTP, которая будет использовать транспорт QUIC.

Преимущества транспорта QUIC

Основные преимущества QUIC, из документа QUIC Geek FAQ (в изложении Opennet):

• Высокая безопасность, аналогичная TLS (по сути QUIC предоставляет возможность использования TLS поверх UDP).
  
• Контроль за целостностью потока, предотвращающий потерю пакетов.
  
• Возможность мгновенно установить соединение (0-RTT, примерно в 75% случаях данные можно передавать сразу после отправки пакета установки соединения) и обеспечить минимальные задержки между отправкой запроса и получением ответа (RTT, Round Trip Time).
  
• Не использование при повторной передаче пакета того же номера последовательности, что позволяет избежать двусмысленности при определении полученных пакетов и избавиться от таймаутов.
  
• Потеря пакета влияет на доставку только связанного с ним потока и не останавливает доставку данных в параллельно передаваемых через текущее соединение потоках.
  
• Средства коррекции ошибок, минимизирующие задержки из-за повторной передачи потерянных пакетов. Использование специальных кодов коррекции ошибок на уровне пакета для сокращения ситуаций, требующих повторной передачи данных потерянного пакета.
  
• Криптографические границы блоков выравнены с границами пакетов QUIC, что уменьшает влияние потерь пакетов на декодирование содержимого следующих пакетов.
  
• Отсутствие проблем с блокировкой очереди TCP.
  
• Поддержка идентификатора соединения, позволяющего сократить время на установку повторного соединения для мобильных клиентов.
  
• Возможность подключения расширенных механизмов контроля перегрузки соединения.
  
• Использование техники прогнозирования пропускной способности в каждом направлении для обеспечения оптимальной интенсивности отправки пакетов, предотвращая скатывание в состояние перегрузки, при которой наблюдается потеря пакетов.
  
• Заметный прирост производительности и пропускной способности, по сравнению с TCP. Для видеосервисов, таких как YouTube, применение QUIC показало сокращение операций повторной буферизации при просмотре видео на 30%.

По словам Марк Ноттингема, переход от устаревшего TCP на новые протоколы просто неизбежен, поскольку сейчас очевидно, что TCP страдает от проблем неэффективности: «Поскольку TCP — протокол доставки пакетов по порядку, то потеря одного пакета может помешать доставке приложению последующих пакетов из буфера. В мультиплексированном протоколе это может привести к большой потере производительности, — объясняет Марк Ноттингем. — QUIC пытается решить эту проблему с помощью эффективной перестройки семантики TCP (вместе с некоторыми аспектами потоковой модели HTTP/2) поверх UDP».

Кроме того, любая версия требует обязательного шифрования: нешифрованного QUIC не существует вообще. iQUIC использует TLS 1.3 для установки ключей сессии, а затем шифрования каждого пакета. Но поскольку он основан на UDP, значительная часть информации о сессии и метаданных, открытых в TCP, шифруется в QUIC:

В статье «Будущее интернет-протоколов» Марк Ноттингем говорит о значительных улучшениях в безопасности с переходом на QUIC: «На самом деле текущий "короткий заголовок" iQUIC — который используется для всех пакетов, кроме рукопожатия — выдаёт только номер пакета, необязательный идентификатор соединения и байт состояния, необходимый для процессов вроде смены ключей шифрования и типа пакета (который тоже может быть зашифрован). Всё остальное зашифровано — включая пакеты ACK, что значительно повышает планку для проведения атак с анализом трафика. Кроме того, становится невозможна пассивная оценка RTT и потерь пакетов путём простого наблюдения за соединением; там недостаточно информации для этого».

Некоторые специалисты считают, что принятие стандарта HTTP/3 произошло бы и раньше, если бы компания Google не поспешила внедрить свою реализацию в браузер Chrome. Тем не менее, прогресс неизбежен — и в ближайшие годы можно ожидать дальнейшего распространения HTTP/3. Поддержка протокола в Chrome Canary — только начало. У Mozilla уже есть такие планы для браузера Firefox.

Для включения HTTP/3 требуется запустить Chrome Canary с опциями --enable-quic —quic-version=h3-23. Потом зайти на тестовый сайт quic.rocks:4433 — и вы увидите соответствующее уведомление.



В инструментах для разработчиков активность HTTP/3 отображается как "http/2+quic/99".

UPD. 26 сентября 2019 года о предварительной поддержке QUIC и HTTP/3 объявил CDN-провайдер Cloudflare. Организация Mozilla тоже анонсировала поддержку HTTP/3 в браузере Firefox «в ближайшее время». «Разработка нового сетевого протокола является трудным делом, и для его правильного выполнения требуется, чтобы все работали вместе, — сказал технический директор Mozilla Эрик Рескорла (Eric Rescorla). — В последние несколько лет мы сотрудничали с Cloudflare и другими отраслевыми партнёрами для тестирования TLS 1.3, а теперь HTTP/3 и QUIC. Ранняя поддержка Cloudflare на стороне сервера для этих протоколов помогла нам решить проблемы совместимости из нашей реализации Firefox на стороне клиента. Надеемся, что наша совместная работа поможет повысить безопасность и производительность интернета».