Протокол прикладного уровня HTTP лежит в основе интернета. Он начал свою жизнь в 1991 году как HTTP/0.9, а к 1999 году превратился в HTTP/1.1, который был стандартизирован Инженерным советом Интернета (IETF).

HTTP/1.1 долго всех удовлетворял, но растущие потребности Сети потребовали апгрейда — и в 2015 году приняли HTTP/2. На этом история не закончилась: совсем недавно IETF анонсировал новую версию HTTP/3. Для некоторых это стало неожиданностью и вызвало некоторое замешательство. Если вы не отслеживаете работу IETF, может показаться, что HTTP/3 появился из ниоткуда. Тем не менее, мы можем отследить его происхождение по истории экспериментов и эволюции веб-протоколов, в частности, транспортного протокола QUIC.

Если вы не знакомы с QUIC, мои коллеги по Cloudflare довольно подробно осветили разные аспекты: например, см. статьи о реальных недостатках современного HTTP ^[1] и подробности о протоколе транспортного уровня ^[2]. Мы собрали эти и другие материалы на сайте cloudflare-quic.com ^[3]. А если интересно, обязательно ознакомьтесь с quiche ^[4]: это наша собственная реализация QUIC, написанная на Rust с открытым исходным кодом.

HTTP/3 — трансляция транспортного протокола QUIC для прикладного уровня. Название HTTP/3 официально утвердили лишь недавно, в 17-й версии черновика (draft-ietf-quic-http-17 ^[5]). Его предложили в конце октября 2018 года, а консенсус был достигнут на встрече IETF 103 в Бангкоке в ноябре.

Раньше НТТР/3 был известен как HTTP по QUIC, а до этого — как HTTP/2 по gQUIC, а ещё раньше — SPDY по gQUIC. Но суть в том, что HTTP/3 — просто новый синтаксис HTTP, который работает на протоколе IETF QUIC, мультиплексированном и безопасном транспорте на основе UDP.

В этой статье рассмотрим историю некоторых из предыдущих названий HTTP/3 и представим мотивацию последнего изменения имени. Вернёмся к первым дням HTTP и всему, что произошло за это время. Если хотите получить полную картину, можете сразу перейти к концу статьи или открыть эту очень подробную версию SVG ^[6].

Слоёный пирог HTTP/3

Обстановка

Непосредственно перед тем, как сосредоточиться на HTTP, стоит напомнить, что существует два протокола с названием QUIC. Как мы уже объясняли ^[2], gQUIC обычно используется как сокращение от Google QUIC (исходный протокол), и QUIC — как версия IETF, которая отличается от gQUIC.

С начала 90-х потребности интернета изменились. У нас появились новые версии HTTP и новый уровень безопасности в виде протокола TLS (Transport Layer Security). В этой статье затронем только TLS, а в других статьях ^[7] нашего блога можно более подробно изучить тему.

Историю HTTP и TLS невозможно выразить простым списком дат, поскольку некоторые ветви развивались параллельно и перекрывались во времени. Когда вы пытаетесь соединить все точки за почти 30 лет истории интернета, не обойтись без визуализации. Поэтому я сделал такой график: Cloudflare Secure Web Timeline. (примечание: технически это кладограмма ^[8], хотя людям более привычно слово «график»).

^[9]

Ради красоты я отбросил часть информации, сосредоточившись только на успешных ветвях в пространстве IETF. Например, здесь не показаны усилия рабочей группы HTTP-NG консорциума W3, а также некоторые экзотические технологии, произношение которых до сих пор пытаютс объяснить авторы: HMURR ^[10] (произносится «hummer») и WAKA ^[11] (произносится «wah-kah»).

В следующих разделах пройдёмся по этой кладограмме и рассмотрим некоторые переломные моменты в истории HTTP. Надеюсь, это поможет понять, почему стандартизация выгодна всем, и как к этому вопросу подходит IETF. Поэтому начнём с очень краткого обзора темы, прежде чем вернуться к самому гарфику. Смело пропустите следующий раздел, если вы уже знакомы с IETF.

Типы интернет-стандарта

Обычно стандарты определяют общую компетенцию, сферу применения, ограничения, применимость и другие соображения. Стандарты существуют разных форм и размеров. Они могут быть неформальными (стандарт де-факто) или формальными (согласованными/опубликованными организацией, определяющей стандарты, такой как IETF, ISO или MPEG). Стандарты используются во многих областях, существует даже формальный британский стандарт приготовления чая — BS 6008.

Первые определения протоколов HTTP и SSL были опубликованы за пределами IETF: на графике они отмечены красными линиями. Но повсеместное использование сделало их стандартами де-факто.

В какой-то момент приняли решение формализовать эти протоколы (некоторые причины описаны ниже). Стандарты интернета обычно определяются в IETF, который руководствуется неофициальным принципом «примерного консенсуса и действующего кодекса» на основе реальных приложений в интернете. Это отличается от подхода «чистой комнаты», когда некто пытается разработать идеальные протоколы в вакууме.

Стандарты IETF широко известны как RFC. Это сложно объяснить вкратце, поэтому рекомендую статью «Как читать RFC» ^[12] от сопредседателя рабочей группы QUIC Марка Ноттингема. Рабочая группа или WG — это, по сути, просто список рассылки.

Каждый год проходит три собрания для личных встреч членов всех рабочих групп, если они того пожелают. Повестка дня на эти недели может быть очень насыщенной, времени не хватает для углубленного обсуждения технических вопросов. Поэтому некоторые предпочитают устраивать ещё промежуточные совещания между общими совещаниями IETF. Рабочая группа по QUIC с 2017 года провела несколько промежуточных заседаний, полный список доступен на странице встреч ^[13].

На этих совещаниях есть возможность встретиться со специалистами из других организаций, таких как Совет по архитектуре интернета ^[14] (IAB) или Исследовательская группа Интернет-технологий ^[15] (IRTF). В последние годы в выходные перед заседанием IETF традиционно проводится хакатон IETF ^[16]. Здесь разрабатывается реальный код и, что важно, проходят тесты совместимости. Это помогает найти проблемы в спецификациях, которые можно обсудить непосредственно на встрече.

Важно понимать, что RFC не возникают из ниоткуда. Они проходят целый процесс. Обычно он начинается с черновика IETF Internet Draft (I-D), который представляют на рассмотрение. В случае, когда уже опубликована спецификация, подготовка I-D станет простым переформатированием. Срок службы I-D составляет 6 месяцев с даты публикации. Чтобы он оставался активным, необходимо публиковать новые версии. На практике нет ничего страшного в том, что срок I-D истекает. Такое происходит довольно часто. Документы по-прежнему хранятся на веб-сайте IETF и открыты для всех.

На кладограмме черновики представлены фиолетовым цветом. У каждого своё название в формате draft-{автор}-{рабочая группа}-{тема}-{версия}. Поле WG необязательно, оно может указывать на будущую рабочую группу IETF и иногда меняется. Если I-D утверждён IETF или инициирован непосредственно внутри IETF, то черновик называется draft-ietf-{рабочая группа}-{тема}-{версия}. I-D могут разветвляться, сливаться или затухать. Версия начинается с 00 и с каждым новым проектом увеличивается на единицу. Например, четвёртый черновик получит номер версии 03. Каждый раз при изменении названия I-D его версия сбрасывается до 00.

Важно отметить, что любой желающий может представить в IETF свой черновик: их нельзя рассматривать в качестве стандартов. Но если процесс стандартизации достигнет консенсуса и итоговый документ пройдёт проверку, мы получим RFC. На этом этапе имя снова изменяется. Каждый RFC получает уникальный номер, например, RFC 7230 ^[17]. Документы с таким статусом представлены в виде синих линий.

RFC запрещено изменять. То есть изменения в RFC требуют принятия документа с новым номером. Изменения разрешены только для исправления редакционных или технических ошибок или для простой оптимизации вёрстки. Новые RFC могут полностью заменить старые или дополнить их.

Все документы IETF находятся в открытом доступе на сайте http://tools.ietf.org ^[18]. Лично мне кажется немного удобнее IETF Datatracker ^[19], потому что там визуально отображается путь документа от I-D до RFC.

Ниже пример, который показывает развитие стандарта RFC 1945 ^[20], то есть HTTP/1.0.

История RFC 1945 в интерфейсе IETF Datatracker

Интересно, что в ходе работы я обнаружил, что вышеприведенная визуализация неверна. По какой-то причине отсутствует draft-ietf-http-v10-spec-05 ^[21]. Поскольку срок жизни I-D составляет 6 месяцев, вероятно, он истёк до принятия RFC, хотя в реальности черновик был активен до августа 1996 года.

Изучение кладограммы

После небольшого теоретического вступления можем приступить к изучению кладограммы. В этом разделе представлены некоторые выдержки с наиболее важными частями. Каждая точка обозначает дату предоставления документа или функции. Для ясности у документов IETF опущены номера проектов, но все они есть в полной версии ^[6].

HTTP появился в 1991 году как протокол HTTP/0.9, а в 1994 году был опубликован черновик draft-fielding-http-spec-00 ^[22]. Вскоре его принял IETF, в результате чего название изменилось на draft-ietf-http-v10-spec-00 ^[23]. После шести редакций черновика в 1996 году был принят стандарт RFC 1945 ^[20] — HTTP/1.0.

Однако ещё до завершения работы над HTTP/1.0 был запущен отдельный проект HTTP/1.1. Версию черновика draft-ietf-http-v11-spec-00 ^[24] опубликовали в ноябре 1995-го, а официально приняли как RFC 2068 ^[25] в 1997 году. Острый глаз заметит, что кладограмма не совсем отражает эту последовательность событий — неудачный глюк инструмента визуализации. Я старался по возможности минимизировать такие проблемы.

В середине 1997 года начался пересмотр HTTP/1.1 как draft-ietf-http-v11-spec-rev-00 ^[26]. Он завершился в 1999 году с публикацией RFC 2616 ^[27]. До 2007 года в мире IETF HTTP всё было тихо. Вернёмся к этому чуть позже.

История SSL и TLS

Переключим внимание на траекторию SSL. Мы видим, что спецификация SSL 2.0 вышла примерно в 1995 году, а SSL 3.0 — в ноябре 1996 года. Интересно, что SSL 3.0 утверждён в стандарте RFC 6101 ^[28], который появился только в августе 2011 года. Он находится в исторической секции. Согласно IETF ^[29], она создана «для документирования идей, которые рассмотрены и отброшены, или протоколов, которые уже существовали к тому времени, когда принято решение их задокументировать». В данном случае был нужен документ IETF с описанием SSL 3.0, чтобы повсеместно использовать его в качестве канонической ссылки.

Нас больше интересует, как SSL вдохновил инженеров на разработку TLS, которая началась с черновика draft-ietf-tls-protocol-00 ^[30] в ноябре 1996 года. Он прошёл через 6 черновых версий и был опубликован как RFC 2246 ^[31] — TLS 1.0 в начале 1999 года.

В 1995-1999 годах протоколы SSL и TLS использовались для защиты HTTP-соединений в интернете. Это прекрасно работало как стандарт де-факто. Только в январе 1998 года с публикации черновика draft-ietf-tls-https-00 ^[32] начался процесс официальной стандартизации HTTPS. Работа завершилась в мае 2000 года публикацией RFC 2616 ^[27] — HTTP по TLS.

TLS продолжал развиваться с 2000 по 2007 год, с принятием стандартов TLS 1.1 и 1.2. Потом случилась семилетняя пауза, прежде чем начались работы над следующей версией протокола TLS, которую опубликуют в виде draft-ietf-tls-tls13-00 ^[33] в апреле 2014 года, а после 28 черновиков утвердят как RFC 8446 ^[34] — TLS 1.3 в августе 2018 года.

Процесс стандартизации интернета

После небольшого знакомства с кладограммой, надеюсь, стало лучше понятно, как работает IETF. При создании стандартов исследователи или инженеры разрабатывают экспериментальные протоколы для конкретных случаев использования. На различных уровнях они экспериментируют с публичными или частными протоколами. Полученная информация позволяет выявить проблемы или улучшить протокол. Публикация работы помогает объяснить эксперимент, собрание мнение более широкого круга специалистов или найти помощь лице других исполнителей. Если другие участники примут эту работу на ранней стадии, то она станет стандартом де-факто, а в конечном счёте возникнет достаточный импульс для официальной стандартизации.

Официальный статус протокола — важный фактор для организаций, которые думают о его использовании. Формальный процесс стандартизации повышает привлекательность стандарта де-факто, поскольку обычно обеспечивает стабильность. Управление и руководство берёт на себя авторитетная организация, такая как IETF, которая отражает интересы и опыт многих участников. Но следует отметить, что не все формальные стандарты становятся успешными.

Процесс создания стандарта почти так же важен, как и сам стандарт. Обработка первоначальной идеи, приглашение к обсуждению людей с более широкими знаниями, опытом и вариантами использования — всё это помогает создать что-то более полезное для широкой аудитории. Однако процесс стандартизации не всегда лёгок. Есть подводные камни и препятствия. Иногда процесс занимает так много времени, что результат уже не актуален.

В каждой организации, определяющей стандарты, обычно есть собственный процесс, ориентированный на её сферу деятельности и участников. Объяснение всех подробностей, как работает IETF, выходит далеко за рамки этой статьи. Если вам это интересно, отличной отправной точкой станет страница «Как мы работаем» ^[35] на сайте IETF. Как обычно, лучший способ во всём разобраться — принять участие самому. Достаточно присоединиться к списку рассылки или к обсуждению в соответствующем репозитории GitHub.

Рабочий код Cloudflare

Cloudflare гордится тем, что одной из первых внедряет новые протоколы, как было с HTTP/2 ^[36] и другими технологиями. Мы также тестируем экспериментальные и ещё не утверждённые функции, такие как TLS 1.3 ^[37] и SPDY ^[38].

Запуск реального кода помогает понять, насколько хорошо протокол будет работать на практике. Мы объединяем экспертные знания с экспериментальной информацией, чтобы помочь улучшить код и, где это имеет смысл, сообщаем о проблемах или улучшениях в рабочую группу, которая стандартизирует протокол.

Тестирование новшеств — не единственный приоритет. Настоящий инноватор всегда знает, когда следует отложить инновацию до лучших времён. Иногда это относится к протоколам, ориентированным на безопасность: например, Cloudflare отключил SSLv3 по умолчанию ^[39] из-за уязвимости POODLE. В других случаях протоколы заменяются более технологически продвинутыми: например, мы заменили SPDY на HTTP/2 ^[40].

Введение и отключение протоколов на Cloudflare представлено оранжевыми линиями. Вертикальные ориентиры помогают соотносить события Cloudflare с соответствующими документами IETF. Например, Cloudflare представила поддержку TLS 1.3 в сентябре 2016 года, а окончательный документ RFC 8446 ^[34] был опубликован почти два года спустя, в августе 2018 года.

Рефакторинг: HTTPbis

HTTP/1.1 — очень успешный протокол. График не показывает особой активности IETF после 1999 года. Но в реальности годы активного использования протокола дали опыт и проявили скрытые проблемы RFC 2616, в том числе некоторые проблемы совместимости. Кроме того, протокол расширился другими RFC, такими как 2817 и 2818. В итоге, в 2007 году было принято решение начать деятельность по улучшению спецификации HTTP. Она получила название HTTPbis (где «bis» происходит от латинского слова «два», «дважды» или «повтор»). Первоначальный устав ^[41] новой рабочей группы хорошо описывает проблемы, которые она пыталась решить.

В общем, в HTTPbis начался рефакторинг RFC 2616 ^[27]. Он включает в себя исправления ошибок и внедрение некоторых аспектов из других спецификаций, которые опубликованы в то же время. Было принято решение разделить документ на части. В результате, в декабре 2007 года было опубликовано шесть черновиков:

• draft-ietf-httpbis-p1-messaging
• draft-ietf-httpbis-p2-semantics
• draft-ietf-httpbis-p4-conditional
• draft-ietf-httpbis-p5-range
• draft-ietf-httpbis-p6-cache
• draft-ietf-httpbis-p7-auth

На диаграмме показано, как продвигалась работа в течение длительного семилетнего процесса разработки. До окончательной стандартизации было принято 27 черновиков. В июне 2014 года вышла так называемая серия RFC 723x (где x колеблется от 0 до 5). Председатель рабочей группы по HTTPbis отметил это достижение фразой «RFC2616 мёртв» ^[42]. Если кто не понял, новые документы отправили в архив старый RFC 2616 ^[27].

Какое отношение это имеет к HTTP/3?

Пока IETF занимался доработкой RFC 723x, мир не стоял на месте. Люди продолжали расширять и дополнять HTTP. Среди них и инженеры Google, которые стали экспериментировать с собственным протоколом под названием SPDY (произносится “speedy”). Они заявили, что этот протокол ускоряет загрузку веб-страниц, что является важнейшей функцией HTTP. В конце 2009 года анонсировали первую версию, а в 2010 году быстро появился SPDY v2.

Не хочу вдаваться в технические подробности SPDY, но важно понимать, что SPDY взял основные парадигмы HTTP и немного изменил формат обмена для оптимизации. Оглядываясь назад, мы видим, что у HTTP чётко разграничены семантика и синтаксис. Семантика описывает концепцию обмена запросами и ответами, в том числе методы, коды состояния, поля заголовка (метаданные) и тела (полезные данные). Синтаксис описывает, как сопоставить семантику с байтами в сети.

У HTTP/0.9, 1.0 и 1.1 много общей семантики. Они также используют общий синтаксис в виде символьных строк, отправляемых через TCP-подключения. SPDY взял семантику HTTP/1.1 и изменил синтаксис на двоичный. Это действительно интересная тема, но сегодня мы не будем углубляться в эту кроличью нору.

Эксперименты со SPDY показали, что изменение синтаксиса HTTP действительно приносит эффект. В то же время важно сохранить существующую семантику. Например, сохранение формата URL для использования https:// позволило избежать многих проблем, которые могли повлиять на внедрение HTTPS.

Увидев некоторые положительные результаты, IETF решил, что пришло время рассмотреть варианты для HTTP/2.0. На слайдах ^[43] с сессии HTTPbis, состоявшейся во время заседания IETF 83 в марте 2012 года, обозначены требования и цели, которые поставили перед собой разработчики. Там же чётко заявлено: «HTTP/2.0 только означает, что транспортный протокол (wire format) не совместим с HTTP/1.x»

В ходе этой встречи сообществу предложили высказать свои идеи. Среди поданных на рассмотрение черновиков были draft-mbelshe-httpbis-spdy-00 ^[44], draft-montenegro-httpbis-speed-mobility-00 ^[45] и draft-tarreau-httpbis-network-friendly-00 ^[46]. В конечном итоге черновик SPDY приняли, а в ноябре 2012 года началась работа над draft-ietf-httpbis-http2-00 ^[47]. После 18 черновиков в течение чуть более двух лет появился RFC 7540 ^[48] — HTTP/2. К 2015 году синтаксис HTTP/2 ушёл ровно настолько, чтобы сделать HTTP/2 и SPDY несовместимыми.

Эти годы стали очень напряжённым периодом для рабочих групп, которые параллельно проводили рефакторинг HTTP/1.1 и принимали HTTP/2. Это резко контрастирует с многолетним спокойствием в начале 2000-х годов. Обязательно ознакомьтесь с полной кладограммой, чтобы по-настоящему оценить объём проделанной работы.

Несмотря на стандартизацию HTTP/2, эксперименты с SPDY приносят пользу до сих пор. Cloudflare представила поддержку SPDY в августе 2012 года и убрала только в феврале 2018 года, когда наша статистика показала, что её запрашивает менее 4% веб-клиентов. Между тем, вскоре после публикации RFC в декабре 2015 года мы ввели поддержку HTTP/2, когда анализ показал заметную поддержку веб-клиентов.

Протоколы SPDY и HTTP/2 по умолчанию используют TLS. Внедрение универсального SSL ^[49] в сентябре 2014 года позволило гарантировать, что все пользователи Cloudflare воспользуются новыми протоколами по мере их внедрения.

gQUIC

Google продолжал экспериментировать и до 2015 года выпустил ещё версии SPDY v3 и v3.1. Они также начали работать над протоколом gQUIC, первый черновик которого опубликовали в начале 2012 года.

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

Слоёный пирог SPDY по gQUIC

Для повышения производительности gQUIC применили хитрые трюки. Один из них — размыть чёткую границу между приложением и транспортом. На практике это означало, что gQUIC поддерживает только HTTP. Эта связь была настолько прочной, что gQUIC, который в то время называли QUIC, стал рассматриваться как кандидат на следующую версию HTTP. Хотя в дальнейшем в QUIC внесли много изменений, по сей день многие считают, что он поддерживает только HTTP. К сожалению, это приводит к постоянной путанице при обсуждении протокола.

gQUIC продолжал развиваться и в конце концов переключился на синтаксис, гораздо более близкий к HTTP/2. Настолько близкий, что большинство людей стали называть его «HTTP/2 по QUIC». Но из-за технических ограничений проявились некоторые очень тонкие различия. Один из примеров связан с сериализацией и обменом заголовками HTTP. Это незначительное различие, но на практике оно означает, что HTTP/2 по gQUIC несовместим с HTTP/2 от IETF.

Последнее, но не менее важное: всегда следует учитывать аспекты безопасности интернет-протоколов. А разработчики gQUIC решили отказаться от TLS в пользу другого подхода под названием QUIC Crypto. Одно из интересных нововведений там — новый метод ускорения рукопожатий. После установки безопасного сеанса с сервером клиент может повторно использовать информацию и зафиксировать «нулевое» время рукопожатия, то есть 0-RTT. Эту хитрость позже включили в протокол TLS 1.3.

Можно наконец узнать, что такое HTTP/3?

Почти.

Теперь мы поняли, как работает стандартизация. Так вот, рассмотрение gQUIC шло по тому же сценарию. В июне 2015 года был представлен первый черновик draft-tsvwg-quic-protocol-00 ^[50], озаглавленный «QUIC: безопасный и надёжный транспорт на основе UDP для HTTP/2». Но не забывайте, что в конце концов синтаксис протокола почти довели до совместимости с HTTP/2.

Компания Google объявила ^[51], что «BoF пройдёт на встрече IETF 93 в Праге». Если вам интересно, что такое BoF, пожалуйста, обратитесь к RFC 6771 ^[52]. Если вкратце, то BoF (Birds of a Feather ^[53]) — это неформальная встреча на конференции.

По итогу обсуждения с IETF было решено, что у QUIC много преимуществ на транспортном уровне, следует отделить этот протокол от HTTP и вновь ввести чёткое разделение между слоями. Кроме того, для этого протокола решили вернуть рукопожатие на основе TLS (что не так уж плохо, ведь к этому моменту уже разработали TLS 1.3 со схемой 0-RTT).

Примерно через год, в 2016 году, вышел новый набор черновиков:

• draft-hamilton-quic-transport-protocol-00 ^[54]
• draft-thomson-quic-tls-00 ^[55]
• draft-iyengar-quic-loss-recovery-00 ^[56]
• draft-shade-quic-http2-mapping-00 ^[57]

Вот где снова возникла путаница: draft-shade-quic-http2-mapping-00 ^[57] называется «Семантика HTTP/2 с использованием транспортного протокола QUIC» и описывает «отображение семантики HTTP/2 по QUIC». Однако это неправильное название. Суть HTTP/2 в изменении синтаксиса при сохранении семантики. Кроме того, «HTTP/2 по gQUIC» никогда не был точным описанием синтаксиса, по причинам, которые я изложил ранее. Имейте это в виду при знакомстве с дальнейшими событиями.

Данная версия QUIC от IETF должна стать совершенно новым транспортным протоколом. Это серьёзное предприятие, поэтому IETF постаралась оценить интерес к проекту со стороны своих членов. Для этого на встрече IETF 96 в Берлине в 2016 году состоялась сессия BoF (слайды ^[58]). Мне посчастливилось лично присутствовать на том собрании, которое привлекло сотни участников, о чём свидетельствует фотография Адама Роуча ^[59]. В итоге был достигнут консенсус: QUIC будет принят и стандартизирован в IETF.

Первый черновик IETF QUIC draft-ietf-quic-http-00 ^[60] для трансляции HTTP на транспорт QUIC логично упростил название протокола до «HTTP по QUIC» (HTTP over QUIC). К сожалению, работу не довели до конца, поэтому по всей организации использовались разные термины HTTP/2. Новый редактор хранилища черновиков стандартов Майк Бишоп увидел проблему и начал исправлять неправильные упоминания HTTP/2. В следующей версии протокола описание изменилось на «сопоставление семантики HTTP на QUIC» (mapping of HTTP semantics over QUIC).

Постепенно, с течением времени и новыми версиями, термин «HTTP/2» стали использовать реже, при необходимости просто указывая ссылки на RFC 7540 ^[48]. Спустя два года в октябре 2018 года вышла семнадцатая по счёту версия черновика (номер 16). Хотя у протокола HTTP over QUIC есть сходство с HTTP/2, по сути это независимый и не совместимый синтаксис HTTP. Тем не менее, для людей, которые не слишком пристально следят за работой IETF (а это очень большой процент населения Земли), название документа не отражает эту разницу. Одна из главных задач стандартизации — содействие коммуникации и оперативной совместимости. А такая простая вещь, как именование, стала главной причиной путаницы в сообществе.

Вспомните, что было сказано в 2012 году: «HTTP/2.0 означает только то, что формат не совместим по транспорту с HTTP/1.х». IETF последовал этому прецеденту. После долгих обсуждений перед и во время конференции IETF 103 всё-таки был достигнут консенсус о переименовании «HTTP over QUIC» в HTTP/3.

Мир стал лучше, и мы можем перейти к более важным дискуссиям.

Но RFC 7230 и 7231 не согласны с вашим определением семантики и синтаксиса!

Иногда названия документов могут сбивать с толку. Вот документы HTTP, описывающие синтаксис и семантику:

• RFC 7230 ^[17] — Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
• RFC 7231 ^[61] — Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

По таким названиям можно предположить, что фундаментальная семантика HTTP специфична для конкретной версии HTTP, то есть HTTP/1.1. Но это случайный побочный эффект семейного дерева HTTP. Хорошая новость в том, что рабочая группа HTTPbis пытается решить проблему. Некоторые отважные члены WG начали ещё один раунд пересмотра документа. Эта работа ведётся прямо сейчас и известна как работа HTTP Core (возможно, вы слышали об этой рабочей группе под названиями HTTPtre или HTTPter: здесь тоже всё неоднозначно)Их усилия позволят сжать шесть черновиков до трёх:

• HTTP Semantics (draft-ietf-httpbis-semantics)
• HTTP Caching (draft-ietf-httpbis-caching)
• HTTP/1.1 Message Syntax and Routing (draft-ietf-httpbis-messaging)

В рамках этой новой структуры становится более очевидным, что HTTP/2 и HTTP/3 являются синтаксическими определениями для общей семантики HTTP. Это не означает, что у них нет собственных функций за пределами синтаксиса, но это должно помочь в дальнейшем обсуждении.

Собирая все воедино

Эта статья поверхностно описала процесс стандартизации HTTP в IETF за последние три десятилетия. Особо не касаясь технических деталей, я попытался объяснить, как мы сейчас пришли к HTTP/3. Если вы пропустили середину и ищете суть в одной фразе, то вот она: HTTP/3 — это просто новый синтаксис HTTP, который работает на IETF QUIC, мультиплексированном и безопасном транспорте на основе UDP. Здесь много интересных технических нюансов, но придётся отложить их на другой раз.

Мы рассмотрели важные этапы в разработке HTTP и TLS, но отдельно друг от друга. Сейчас в конце статьи ещё раз публикуем полную кладограмму. Вы можете спокойно и тщательно изучить её в комфортной обстановке. И для суперсыщиков: вот абсолютно полная версия, включая черновики ^[6].

Автор: m1rko

Источник ^[62]