[Перевод] HTTP/3: Истоки

задняя часть Программа перевода самородков HTTP3
[Перевод] HTTP/3: Истоки

HTTP — это протокол прикладного уровня, обеспечивающий правильное функционирование веб-приложений. В 1991 году был официально выпущен HTTP/0.9, а к 1999 году он превратился в стандартизированный протокол HTTP/1.1 IETF (International Internet Engineering Task Force). Долгое время HTTP/1.1 работал очень хорошо, но перед лицом постоянно меняющихся потребностей Интернета становится ясно, что необходим более подходящий протокол. В 2015 году появился HTTP/2. Недавно стало известно, что IETF, как ожидается, выпустит новую версию — HTTP/3. Для некоторых это стало неожиданностью и вызвало бурные дискуссии в отрасли. Если вы не обращаете особого внимания на IETF, вам может показаться, что HTTP/3 появился очень внезапно. Но правда в том, что мы можем проследить его происхождение через серию реализаций HTTP и эволюцию веб-протоколов, особенно транспортного протокола QUIC.

Если вы новичок в QUIC, ознакомьтесь с некоторыми высококачественными сообщениями в блогах от моих коллег. ДжонаблогОбсуждает некоторые проблемы современного HTTP с разных точек зрения.блогОбъясняя суть транспортного уровня, НикблогУчаствует в методе обработки сопутствующих тестов. Мы собрали и систематизировали этот связанный контент, если вы хотите увидеть больше контента, вы можете перейти наcloudflare-quic.com. Если вам интересно, не забудьте проверить нашу собственную реализацию QUIC с открытым исходным кодом, написанную на Rust —quiche.

HTTP/3 — это сопоставление приложения HTTP для транспортного уровня QUIC. Название было официально предложено в 17-й версии недавнего (конец октября 2018 г.) проекта (draft-ietf-quic-http-17), обсуждались и достигли предварительного консенсуса на собрании IETF 103 в ноябре. HTTP/3 ранее был известен как QUIC (ранее HTTP/2). До этого у нас был gQUIC, а еще раньше у нас был SPDY. Правда в том, что HTTP/3 — это просто новый синтаксис HTTP для IETF QUIC — мультиплексирование и безопасный транспорт на основе UDP.

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

Многоуровневая модель HTTP/3 (модель торта)

установить фон

Прежде чем мы сосредоточимся на HTTP, стоит напомнить, что они оба имеют общее имя QUIC. как мыДоКак объяснялось, gQUIC обычно относится к Google QUIC (исходный протокол), который часто используется для обозначения другого стандарта IETF (версия в разработке), отличного от gQUIC.

В начале 1990-х требования к Интернету изменились. У нас есть новая версия HTTP, которая усиливает безопасность пользователей в форме безопасности транспортного уровня (TLS). В этой статье мы рассмотрим TLS. Если вы хотите узнать больше об этой области, вы можете обратиться к нашим другим высококачественнымСообщение блога.

Чтобы помочь нам понять историю HTTP и TLS, я собрал воедино спецификацию протокола и детали дат. Эта информация обычно представлена ​​в текстовом виде, например, в виде списка символических точек, описывающих название документа, отсортированных по дате. Однако перекрывающиеся времена и простые списки не отражают должным образом сложные отношения из-за критериев ветвления. В HTTP параллельная работа привела к рефакторингу определения базового протокола, мы расширили содержание протокола для новых вариантов поведения для упрощения использования, и мы даже переопределили, как протокол обменивается данными через Интернет для повышения производительности. Когда вы пытаетесь понять почти 30-летнюю историю Интернета в различных разветвленных рабочих процессах, вам необходимо визуализировать ее. Поэтому я создал безопасную веб-хронологию Cloudflare (примечание: технически этоЭволюционное дерево, но термин временная шкала более известен).

При его создании после долгих размышлений я решил сосредоточиться на успешных ответвлениях IETF. Контент, не описанный в этой статье, включая W3CHTTP-NGРабота рабочей группы и некоторые причудливые мысли авторов, которые хотят объяснить, как это произносится:ХМУРР (произносится как «молоток»)иВАКА (произносится как «ва-ках»).

Чтобы дать вам лучшее представление о контексте этой статьи, в следующих разделах я объясню ключевые моменты истории HTTP на этой временной шкале. Узнайте о стандартизации и о том, как к ней относится IETF. Итак, прежде чем вернуться к временной шкале, мы сначала дадим краткий обзор этой темы. Если вы уже хорошо знакомы с IETF, вы можете пропустить этот раздел.

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

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

Ранняя сеть использовала определения протоколов HTTP и SSL, опубликованные за пределами IETF, которые отмечены на шкале времени безопасного Интернета какКрасная линия. Компрометация этих протоколов клиентами и службами позволила им стать стандартами де-факто.

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

Интернет-стандарты IETF часто называют RFC. Это сложная область для объяснения, поэтому я рекомендую прочитать этот пост в блоге председателя рабочей группы QUIC Марка Ноттингема».Как читать RFC". Рабочая группа или WG, более или менее просто список рассылки.

IETF собирается три раза в год и предоставляет время и возможности для личного присутствия всех рабочих групп, если они того пожелают. Эти недели путешествий были насыщенными, требуя углубленного обсуждения передовых технических областей в условиях ограниченного времени. Чтобы решить эту проблему, некоторые рабочие группы даже решили проводить специальные встречи во время общих собраний IETF. Это помогает сохранить уверенность в разработке спецификации. С 2017 года рабочая группа QUIC провела несколько специальных совещаний, которые можноСтраница сайта конференцииОзнакомьтесь с полным списком.

Эти собрания IETF также предоставляют возможности группам, связанным с IETF, таким какСовет по архитектуре ИнтернетаилиЦелевая группа по исследованиям в Интернете. В последние годы, за несколько недель до встречи IETF,IETF Hackathon. Это дает сообществу возможность разрабатывать работающий код и, что более важно, тестировать совместимость с другими. Это помогает выявить проблемы в спецификации и обсудить их на предстоящей встрече.

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

I-D отображаются на шкале времени Secure Web какФиолетовый. Каждая строка имеет форматdraft-{author name}-{working group}-{topic}-{version}уникальное имя. Поле рабочей группы является необязательным, и оно предсказывает, работает ли здесь рабочая группа IETF, это переменный параметр, если выбран I-D, или если I-D запускается непосредственно в IETF, имяdraft-ietf-{working group}-{topic}-{version}. I-D могут разветвляться, сливаться или умирать. +1 каждый раз, когда выходит новый черновик, начиная с версии 00. Например, четвертый черновик I-D имеет номер версии 03. Всякий раз, когда I-D меняет свое имя, его номер версии сбрасывается на 00.

Важно отметить, что любой может отправить идентификатор в IETF; вы не должны рассматривать их как стандарты. Но если процесс стандартизации I-D IETF будет единогласно подтвержден и пройдет окончательную проверку документа, мы получим RFC. На этом этапе имя будет снова изменено. Каждый RFC имеет уникальный номер. Например,RFC 7230. Они отображаются на защищенной веб-хронологии каксиний.

RFC являются неизменяемыми документами. Это означает, что изменения в RFC приводят к совершенно новому номеру. Изменения могут быть внесены, чтобы включить исправленные ошибки (отредактированные и зарегистрированные редакционные или технические ошибки) или просто реорганизовать спецификацию для улучшения макета. RFC можетустарелстарая версия или простовозобновитьОни (существенно меняются).

Все документы IETF находятся в открытом доступе по адресуtools.ietf.orgВверх. Поскольку он обеспечивает визуализацию хода документа от I-D до RFC, я лично считаюIETF DatatrackerДружественный интерфейс.

Отображается следующееRFC 1945- Пример разработки HTTP/1.0, который служит явным источником вдохновения для Secure Web Timeline.

Представление IETF RFC 1945 Datatracker

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

Исследуйте безопасную веб-хронологию

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

HTTP начался с протокола HTTP/0.9 в 1991 г., I-D в 1994 г.draft-fielding-http-spec-00выпуск. Он был быстро принят IETF, в результате чегоdraft-ietf-http-v10-spec-00имя было изменено. существуетRFC 1945- Перед выпуском HTTP/1.0 в 1996 году I-D претерпел 6 черновых изменений.

Еще до того, как HTTP/1.0 был завершен, HTTP/1.1 запустил отдельный форк. Я БЫdraft-ietf-http-v11-spec-00Выпущен в ноябре 1995 г., официально выпущен в 1997 г. какRFC 2068форма опубликована. Тщательное понимание приведет вас к открытию того, что Secure Web Timeline не фиксирует последовательность событий, что является нежелательным побочным эффектом инструментов, используемых для создания визуализаций. Я постараюсь максимально уменьшить количество таких проблем.

Изменения HTTP/1.1 были внесены в середине 1997 г.draft-ietf-http-v11-spec-rev-00начинается форма. опубликовано в 1999 г.RFC 2616знаменует завершение этого плана. Лишь в 2007 году в мире HTTP IETF установился мир. Мы скоро вернемся к этому.

История SSL и TLS

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

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

В 1995 и 1999 годах протоколы SSL и TLS использовались для защиты HTTP-соединений в Интернете. Как стандарт де-факто, это не слишком большая проблема. Только в январе 1998 года формальный процесс стандартизации HTTPS последовал за I-D.draft-ietf-tls-https-00началось с публикации . Эта работа была завершена в мае 2000 г.RFC 2616- HTTP через TLS.

TLS продолжал развиваться с 2000 по 2007 год со стандартизацией TLS 1.1 и 1.2. До разработки следующей версии TLS еще 7 лет, и она была выпущена в апреле 2014 года.draft-ietf-tls-tls13-00прошел в 28 драфтах,RFC 8446- TLS 1.3 завершен в августе 2018 г.

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

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

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

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

Каждая организация по разработке стандартов имеет свой собственный процесс стандартизации, в основном в соответствующей области и среди участников. Объяснение всех рабочих деталей того, как работает IETF, выходит далеко за рамки этого блога. IETF"Как мы работаем" – это хорошая отправная точка, и она охватывает многое. Да, лучший способ понять – принять участие самостоятельно. Так же просто, как присоединиться к списку адресов электронной почты или добавить обсуждение в соответствующий репозиторий GitHub.

Рабочий код Cloudflare

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

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

Тестирование новых функций — не единственный приоритет. Как новатор, вы должны знать, когда двигаться вперед и отказываться от старых инноваций. Иногда это связано с протоколами, ориентированными на безопасность, например, сбой Cloudflare из-за уязвимости POODLE.SSLv3 отключен по умолчанию. В некоторых случаях протоколы заменены на более продвинутые; Cloudflareустаревший SPDY, который, в свою очередь, поддерживает HTTP/2.

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

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

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

Короче говоря, HTTPbis решил провести рефакторингRFC 2616. Он будет включать в себя исправления опечаток, включая часть содержания других спецификаций, опубликованных в промежуточный период. Документ будет разделен на несколько разделов, что привело к выдаче 6 удостоверений личности в декабре 2017 года:

  • 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 is Dead", чтобы отпраздновать это достижение. Если это недостаточно ясно, эти новые документы устареваютRFC 2616.

Как это связано с HTTP/3?

Несмотря на напряженную работу над серией RFC 723x IETF, технический прогресс не остановился. Люди продолжают улучшать, расширять и тестировать HTTP в Интернете. А Google первой разработала технологию под названием SPDY (произносится как Speedy). Протокол утверждает, что улучшает производительность просмотра веб-страниц, вариант использования, который использует принципы HTTP. В конце 2009 года был выпущен SPDY v1, а в 2010 году — SPDY v2.

Я не хочу вдаваться в технические детали SPDY. Потому что это другая тема. Важно понимать, что SPDY использует базовую парадигму HTTP, улучшая технологию за счет модификаций формата обмена. Мы видим, что HTTP имеет четкое разделение семантики и синтаксиса. Семантика описывает концепции запросов и ответов, включая: методы, коды состояния, поля заголовков (метаданные) и части тела (полезная нагрузка). Синтаксис описывает, как отображать семантику на байты проводов.

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

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

Увидев некоторые положительные результаты, IETF решила рассмотреть HTTP/2.0.Из конференции HTTPbis, состоявшейся во время IETF 83 в марте 2012 г.slidesОтображаются запрос, цель и критерии успеха. В нем также прямо указано, что «HTTP/2.0 несовместим с форматом проводов HTTP/1.x».

Сообществу предлагается поделиться предложениями во время этой встречи. I-D, представленные на рассмотрение, включаютdraft-mbelshe-httpbis-spdy-00,draft-montenegro-httpbis-speed-mobility-00иdraft-tarreau-httpbis-network-friendly-00. В конце концов, проект SPDY был принят, начиная с ноября 2012 г.draft-ietf-httpbis-http2-00. Завершил 18 драфтов за 2 года,RFC 7540- HTTP/2 был выпущен в 2015 году. Во время этой спецификации различия в точном синтаксисе HTTP/2 сделали HTTP/2 и SPDY несовместимыми.

В последние годы работа IETF, связанная с HTTP, была тяжелой, и рефакторинг HTTP/1.1 и стандартизация HTTP/2 идут рука об руку. Разительный контраст со спокойствием начала 2000-х. Вы можете проверить полное расписание, чтобы увидеть тяжелую работу.

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

Веб-клиенты, использующие протоколы SPDY и HTTP/2, поддерживают предпочтительный вариант безопасности с использованием TLS. Представлен в сентябре 2014 г.Universal SSLПомогите убедиться, что все сайты, зарегистрированные в Cloudflare, могут использовать преимущества этих новых протоколов.

gQUIC

В период с 2012 по 2015 год Google продолжал экспериментировать и выпустил SPDY v3 и v3.1. Они также начали работу над gQUIC (в то время это произносилось как quick) и в начале 2012 года выпустили первоначальную общедоступную спецификацию.

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

Многоуровневая модель gQUIC в стиле SPDY (модель пирога)

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

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

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

Могу я рассказать вам, что такое HTTP/3 сейчас?

Конечно.

К настоящему времени вы должны понимать, как работает нормализация, и gQUIC ничем не отличается. Возможно, вас также заинтересует спецификация Google, написанная в формате I-D. в июне 2015 г.draft-tsvwg-quic-protocol-00, который гласит: «QUIC: безопасный и надежный транспорт HTTP/2 по UDP». Помните, что я упоминал ранее, это почти весь синтаксис HTTP/2.

Google объявитьКонференция Bar BoF IETF 93 пройдет в Праге. Если сомневаетесь, см.RFC 6771. Подсказка: BoF — это сокращение от Birds of a Feather.

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

Примерно через год, в 2016 году, был представлен новый набор коллекций I-D:

Вот еще один источник путаницы в отношении HTTP и QUIC.draft-shade-quic-http2-mapping-00Под названием «HTTP/2 с использованием семантики транспортного протокола QUIC» он описывает себя как «Другое семантическое отображение QUIC в стиле HTTP/2». Но это объяснение неверно. HTTP/2 изменяет синтаксис, сохраняя при этом семантику. Кроме того, как я уже давно сказал, «gQUIC в стиле HTTP/2» никогда не имел точного описания синтаксиса, имейте это в виду.

Эта версия IETF QUIC должна стать новым протоколом транспортного уровня. Из-за масштабности задачи IETF оценивает фактический уровень интереса среди оценщиков перед первоначальным подтверждением. Поэтому в 2016 году во время встречи IETF 96 в Берлине было официальноBirds of a FeatherВстреча. Я имею честь участвовать в этой встрече,слайд-шоуСправедливой оценки не дали. как у Адама РоучарисунокКак видно, на встрече присутствовали сотни человек. В конце встречи был достигнут консенсус: QUIC будет принят и стандартизирован IETF.

Первый IETF QUIC I-D для сопоставления HTTP с QUIC -draft-ietf-quic-http-00, использует подход Ronseal для упрощения именования — «HTTP через QUIC». К сожалению, это не сработало, как ожидалось, и во всем контенте остались экземпляры терминологии HTTP/2. Майк Бишоп — новый редактор в I-D, нашел и исправил неправильные имена HTTP/2. В черновике 01 измените описание на «сопоставление семантики HTTP с QUIC».

Использование «HTTP/2» постепенно уменьшалось с течением времени и версий, и раздел примеров предназначен только дляRFC 7540часть справки. I-D сейчас находится в 16-м издании, считая два года назад с октября 2018 года. Хотя HTTP через QUIC имеет сходство с HTTP/2, он всегда независим (синтаксис HTTP без обратной совместимости). Однако те, кто не уделяет пристального внимания развитию IETF (в большом количестве), не находят каких-то тонких отличий в названии. Одним из направлений стандартизации является помощь в общении и функциональной совместимости. Но простые события, такие как присвоение имени, являются основной причиной относительной путаницы в сообществе.

Еще в 2012 году «HTTP/2.0 означает, что проводной формат несовместим с форматом HTTP/1.x». IETF следует за существующими лидерами. IETF 103 был окончательно согласован после долгих размышлений, а именно: «HTTP через QUIC» под названием HTTP/3. Интернет делает мир лучше, и мы можем продолжать вести более важные дискуссии.

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

Название документа иногда может сбивать с толку. Что сегодня описывает синтаксис и семантику HTTP-документов:

  • RFC 7230- Протокол передачи гипертекста (HTTP/1.1): синтаксис и маршрутизация сообщений.
  • RFC 7231- Протокол передачи гипертекста (HTTP/1.1): синтаксис и контекст

Чрезмерная интерпретация этих имен может привести к мысли, что основная семантика версии HTTP специфична. Например, HTTP/1.1. Но это побочный эффект генеалогического древа HTTP. Хорошая новость заключается в том, что рабочая группа HTTPbis пытается решить эту проблему. Несколько бесстрашных членов работают над очередным раундом пересмотра документа, как сказал Рой Филдинг: «Еще раз!». В настоящее время эта работа выполняется в качестве основных задач HTTP (возможно, вы также слышали о прозвищах HTTPtre или HTTPter; работа по именованию сложна). Это объединит шесть черновиков в три:

  • Семантика HTTP (draft-ietf-httpbis-semantics)
  • Кэширование HTTP (draft-ietf-httpbis-caching)
  • Синтаксис и маршрутизация сообщений HTTP/1.1 (draft-ietf-httpbis-messaging)

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

Суммировать

В этой статье представлен обзор того, как IETF стандартизировала HTTP за последние три десятилетия. Не вдаваясь в технические подробности, я попытаюсь объяснить историю HTTP/3. Если вы пропустили важные части в середине и хотели получить общее представление о нем, суть такова: HTTP/3 — это просто новый синтаксис HTTP для IETF QUIC — безопасный транспорт через UDP-мультиплексирование Floor. Есть еще много интересных областей, которые необходимо тщательно изучить, но нужно будет подождать до следующей возможности, чтобы представить их.

В повествовании этой статьи мы исследуем важные главы разработки HTTP и TLS, но все они рассматриваются отдельно. Ближе к концу статьи мы объединим их все в полную хронологию безопасного Интернета, представленную ниже. Вы можете использовать его для изучения подробной истории. Для супер сыщиков обязательно ознакомьтесьПолная версия, включая черновой номер.

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

Если вы обнаружите ошибки в переводе или в других областях, требующих доработки, добро пожаловать наПрограмма перевода самородковВы также можете получить соответствующие бонусные баллы за доработку перевода и PR. начало статьиПостоянная ссылка на эту статьюЭто ссылка MarkDown этой статьи на GitHub.

Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из Интернета сНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,продукт,дизайн,искусственный интеллекти другие поля, если вы хотите видеть больше качественных переводов, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.

Категории