[Перевод] Часто задаваемые вопросы по HTTP/2

задняя часть HTTP

Ниже приведены ответы на часто задаваемые вопросы о HTTP/2.

Основные вопросы

Зачем изменять HTTP?

HTTP/1.1 используется в Интернете более пятнадцати лет, но его недостатки начинают проявляться.

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

В прошлом браузеры использовали несколько TCP-соединений для выполнения параллельных запросов. Однако этот подход имеет ограничения. Если используется слишком много подключений, это будет иметь противоположный эффект (управление перегрузкой TCP будет отключено, что приведет к перегрузке, которая повлияет на производительность и сеть). А еще это в корне несправедливо по отношению к другим программам (потому что браузер занимает много ресурсов, которые ему не должны принадлежать).

В то же время большое количество запросов означает много дублирующихся данных «на проводе».

Оба эти фактора означают, что запросы HTTP/1.1 связаны с большими накладными расходами; если запросов слишком много, это может повлиять на производительность.

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

Кто разработал HTTP/2?

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

Стоит отметить, что хотяСписок рассылки рабочей группыРазмещено на веб-сайте W3C, хотя и не в честь W3C. Тем не менее, Тим Бернерс-Ли и W3C TAG не отставали от прогресса рабочей группы.

Многие люди внесли свой вклад в эту работу, особенно некоторые инженеры из «больших» проектов, таких как Firefox, Chrome, Twitter, стек Microsoft HTTP, Curl и Akamai. И несколько реализаторов HTTP для Python, Ruby и NodeJS.

Для получения более подробной информации о IETF вы можете посетитьTao of the IETF; вы также можетеГрафик участников на GithubПосмотрите, кто внес свой вклад в проект наimplementation listчтобы увидеть, кто работает над проектом.

Как HTTP/2 связан с SPDY?

Когда HTTP/2 впервые появился и обсуждался, SPDY завоевывает расположение и поддержку поставщиков (таких как Mozilla и nginx) и рассматривается как значительное улучшение по сравнению с HTTP/1.x.

После постоянного запроса предложений и вариантов голосования,SPDY/2Выбран в качестве основы для HTTP/2. С тех пор он сильно изменился, основываясь на обсуждениях в рабочих группах и отзывах пользователей.

На протяжении всего процесса в разработке HTTP/2 участвовали основные разработчики SPDY, в том числе Майк Белше и Роберто Пеон.

Февраль 2015 г., Googleобъявить о планахПрекратить поддержку SPDY в пользу HTTP/2.

Это HTTP/2.0 или HTTP/2?

Рабочая группа решила удалить второстепенную версию (".0"), потому что она вызывала много путаницы в HTTP/1.x. То есть версия HTTP представляет только его совместимость, а не его особенности и «изюминки».

Каковы основные различия между HTTP/2 и HTTP/1.x?

В более поздних версиях HTTP/2:

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

Почему HTTP/2 двоичный?

По сравнению с текстовыми протоколами, такими как HTTP/1.x, бинарные протоколы более эффективны для синтаксического анализа, более компактны «по сети» и, что наиболее важно, имеют меньше ошибок. Потому что они полезны для обработки таких вещей, как пробелы, заглавные буквы, окончания строк, пустые ссылки и т. д.

Например 🌰, HTTP/1.1 определяетЧетыре разных способа разбора сообщения; тогда как в HTTP/2 требуется только один путь кода.

HTTP/2 недоступен в telnet, но у нас уже есть некоторые инструменты для его поддержки, например.Wireshark plugin.

Зачем HTTP/2 мультиплексирование?

У HTTP/1.x есть проблема, называемая «блокировкой заголовка строки», что означает, что в соединении более эффективно отправлять только один запрос, и он будет замедляться, если их слишком много.

HTTP/1.1 пытается использовать конвейерную обработку для решения этой проблемы, но эффект не идеален (для больших данных или медленных ответов он все равно будет блокировать запросы за собой). Кроме того, многие сетевые посредники и серверы плохо поддерживают конвейерную обработку, что затрудняет развертывание.

Это также вынуждает клиента использовать некоторые эвристики (в основном догадки), чтобы решить, какие запросы отправлять по каким соединениям; поскольку объем данных, загружаемых на страницу, часто более чем в 10 раз превышает объем данных, которые могут обработать доступные соединения, производительность имеет огромное негативное влияние, часто приводящее к водопаду заблокированных запросов.

И мультиплексирование может очень хорошо решить эти проблемы, потому что оно может одновременно обрабатывать запрос и ответ нескольких сообщений; оно может даже смешивать одно сообщение с другим в процессе передачи.

Таким образом, в этом случае клиенту требуется только одно соединение для загрузки страницы.

Почему требуется только одно TCP-соединение?

При использовании HTTP/1 браузеру требуется от 4 до 8 соединений для каждого источника. Сегодня многие веб-сайты используют несколько источников, а это означает, что просто загрузка веб-страницы открывает более 30 подключений.

Приложение открывает так много соединений одновременно, что выходит далеко за рамки первоначального дизайна TCP; в то же время, поскольку каждое соединение будет отвечать на большой объем данных, это может вызвать риск переполнения сетевого буфера, который может привести к перегрузке сети и перегрузке данных.

Кроме того, использование такого количества подключений может привести к перегрузке многих сетевых ресурсов. Эти ресурсы «украдены» у «законопослушных» приложений (хороший пример — VoIP).

Каковы преимущества сервера push?

Когда браузер запрашивает страницу, сервер отправляет HTML в ответ, а затем ему нужно дождаться, пока браузер проанализирует HTML и сделает запросы для всех встроенных ресурсов, прежде чем он сможет начать отправлять JavaScript, изображения и CSS.

Служба push-уведомлений сервера позволяет избежать задержек при передаче туда и обратно, «заталкивая» содержимое в кэш клиента, которое, по ее мнению, понадобится клиенту.

Однако push-ответы не являются панацеей и могут снизить производительность при неправильном использовании. Надлежащее использование push-уведомлений сервера — это давняя область экспериментов и исследований.

Почему заголовки сообщений должны быть сжаты?

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

Предположим, что страница имеет 80 ресурсов для загрузки (консервативное количество для сегодняшней сети), и каждый запрос имеет 1400-байтовый заголовок (что также не редкость, поскольку присутствуют такие вещи, как файлы cookie и ссылки), это занимает не менее 7-8 раундов. поездки, чтобы получить эти заголовки "на проводе". Это не включает время отклика — это просто время, необходимое для их получения от клиента.

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

Напротив, даже незначительное сжатие заголовка может сделать эти запросы просто двусторонними, а иногда даже пакетными.

Эти дополнительные накладные расходы значительны, особенно если учесть влияние на мобильные клиенты. Задержка этих циклов даже в хороших сетевых условиях может составлять сотни миллисекунд.

Почему стоит выбрать HPACK?

SPDY/2 предлагает использовать отдельный контекст GZIP для сжатия заголовков с каждой стороны, что легко и эффективно реализовать.

С тех пор важным методом атакиCRIMEСоздан для атаки на сжатые потоки (например, GZIP), используемые внутри зашифрованных файлов.

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

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

Может ли HTTP/2 улучшить файлы cookie (или другие заголовки)?

Эта попытка лицензирована для работы с пересмотренной версией веб-протокола — например, как заголовки, методы и т. д. HTTP могут быть размещены «в Интернете» без изменения семантики HTTP.

Это связано с тем, что HTTP широко используется. Если бы мы использовали эту версию HTTP, она ввела бы новый механизм состояния (как в примере, рассмотренном ранее) или изменила свои основные методы (к счастью, этого еще не произошло), что могло бы означать новый протокол. совместимость с существующим веб-контентом.

В частности, мы хотим иметь возможность перейти с HTTP/1 на HTTP/2 без потери информации. Если мы начнем «очищать» заголовки (большинство людей сегодня думают, что заголовки HTTP — это беспорядок), нам придется столкнуться с множеством проблем с существующей сетью.

Это только создаст проблемы для популярности нового протокола.

в конце концов,рабочая группаБудет отвечать за все HTTP, а не только за HTTP/2. Таким образом, мы можем работать с новыми механизмами, не зависящими от версии, если они обратно совместимы с существующими сетями.

Как выглядит HTTP для пользователей, не использующих браузер?

Если небраузерные приложения уже используют HTTP, они также должны иметь возможность использовать HTTP/2.

Ранее уже были получены отзывы о том, что HTTP-"API" хорошо работают в HTTP/2 и т. д., и это потому, что API-интерфейсы не предназначены для учета таких вещей, как накладные расходы на запросы.

Сказав это, улучшения, которые мы рассматриваем, сосредоточены на типичном сценарии использования браузера, поскольку это основной вариант использования протокола.

В нашем уставе сказано следующее:

Организуемая спецификация должна соответствовать функциональным требованиям HTTP, поскольку он сейчас широко используется; в частности, для просмотра веб-страниц (настольных и мобильных), без браузера (в форме «HTTP API»), веб-служб (широко распространенные) и различные сетевые посредники (через прокси, корпоративные брандмауэры, обратные прокси и сети доставки контента). Аналогично, в новом протоколе должны поддерживаться текущие и будущие семантические расширения HTTP/1.x (например, заголовки, методы, коды состояния, директивы кэширования).

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

Требует ли HTTP/2 шифрования?

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

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

Как HTTP/2 повышает безопасность?

HTTP/2 определяет необходимые документы TLS, включая версии, черные списки наборов шифров и используемые расширения.

Смотрите подробностиСвязанные характеристики.

Также обсуждаются дополнительные механизмы, такие как использование TLS для URL-адресов HTTP:// (так называемое «уступающее шифрование»); см.RFC 8164.

Могу ли я сейчас использовать HTTP/2?

Среди браузеров последние версии Edge, Safari, Firefox и Chrome поддерживают HTTP/2. Другие браузеры на базе Blink также будут поддерживать HTTP/2 (например, браузеры Opera и Yandex). смотрите подробностиcaniuse.

Также доступно несколько серверов (в том числе отAkamai,GoogleиTwitterбета-поддержка с основного сайта), а также множество реализаций с открытым исходным кодом, которые можно развернуть и протестировать.

Для получения дополнительной информации см.Список реализации.

Заменит ли HTTP/2 HTTP/1.x?

Цель рабочей группы — дать возможность тем, кто использует HTTP/1.x, использовать HTTP/2 и воспользоваться преимуществами HTTP/2. Они сказали, что мы не можем заставить весь мир мигрировать из-за того, как люди развертывают прокси и серверы, поэтому HTTP/1.x, скорее всего, еще какое-то время будет существовать.

Появится ли HTTP/3?

Если механизмы связи и совместной работы, представленные в HTTP/2, будут работать хорошо, поддержка новых версий HTTP будет проще, чем когда-либо.

Проблемы реализации

Почему правило вращается вокруг соединения данных кадра заголовка?

Подключение к данным существует, потому что значение (например, файл cookie) может превышать 16 КБ, что означает, что оно не может полностью поместиться во фрейм.

Поэтому было решено передавать все данные заголовка кадр за кадром наименее подверженным ошибкам способом, что упрощает декодирование заголовков и управление буфером.

Каков минимальный и максимальный размер состояния HPACK?

Приемник всегда будет контролировать использование памяти в HPACK, и минимальное значение может быть установлено на 0, а максимальное значение зависит от максимального целого числа, которое может быть представлено во фрейме SETTING, в настоящее время 2^32 - 1.

Как избежать сохранения состояния HPACK?

Отправьте кадр SETTINGS, установите размер состояния (SETTINGS_HEADER_TABLE_SIZE) в 0, затем RST все потоки, пока не будет получен кадр SETTINGS с установленным битом ACT.

Почему существует отдельный контекст управления сжатием/потоком?

Кратко.

В исходном предложении упоминалась концепция группировки потоков, которая может совместно использовать контекст, выполнять управление потоком и многое другое. Хотя это хорошо для прокси-сервера (и взаимодействия с пользователем), это также добавляет немного сложности. Поэтому мы решили начать с чего-то простого, чтобы увидеть, насколько это может быть плохо, и решить эти проблемы (если они есть) в будущих версиях протокола.

Почему в HPACK есть обозначение EOS?

Из соображений эффективности и безопасности ЦП кодировка Хаффмана для HPACK заполняет границу следующего байта строки, закодированной по Хаффману. Таким образом, для любой конкретной строки может потребоваться от 0 до 7 бит заполнения.

Если вы рассматриваете только декодирование Хаффмана, любые символы длиннее требуемого заполнения будут работать нормально. Однако HPACK предназначен для побайтового сравнения строк в кодировке Хаффмана. Добавляя биты, необходимые для символов EOS, мы гарантируем, что пользователи равны при сравнении на уровне байтов строк, закодированных Хаффманом. И наоборот, многие заголовки могут быть проанализированы без декодирования Хаффмана.

Могу ли я внедрить HTTP/2 без реализации HTTP/1.1?

Обычно/большую часть времени да.

Для запуска TLS (h2) поверх HTTP/2, если вы не реализуетеhttp1.1ALPN, то вам не нужно поддерживать какие-либо функции HTTP/1.1.

Для работы по TCP (h2c) поверх HTTP/2 необходимо реализовать первоначальный запрос на обновление.

только поддержкаh2cклиентов необходимо сгенерировать запрос для OPTIONS, потому что“*”Или запрос HEAD для «/», они также достаточно безопасны и просты в построении. Клиенты, которые хотят реализовать только HTTP/2, должны рассматривать ответы HTTP/1.1 без кода состояния 101 как обработку ошибок.

только поддержкаh2cСервер может получить запрос, содержащий поле заголовка Upgrade с фиксированным ответом 101. нетh2cЗапрос токена обновления может быть отклонен с кодом состояния 505 (версия HTTP не поддерживается), который включает поле заголовка Upgrade. Серверы, которые не хотят обрабатывать ответы HTTP/1.1, ДОЛЖНЫ отклонить первый поток запроса с кодом ошибки REFUSED_STREAM сразу после отправки преамбулы соединения, которая побуждает пользователей повторить попытку обновленных соединений HTTP/2.

Верен ли пример приоритета в Разделе 5.3.2?

Нет, это правильно. Поток B имеет вес 4, а поток C имеет вес 12. Чтобы определить долю доступных ресурсов, полученных каждым потоком, просуммируйте все веса (16) и разделите вес каждого потока на общий вес. Следовательно, поток B получает четверть доступных ресурсов, а поток C — три четверти. Итак, как говорится в спецификации:Поток B в идеале получает одну треть ресурсов, выделенных потоку C..

Требуется ли TCP_NODELAY для соединений HTTP/2?

Да, это возможно. Даже для клиентов, которые загружают большие объемы данных, используя только один поток, некоторые пакеты по-прежнему необходимо отправлять обратно в противоположном направлении для обеспечения максимальной скорости передачи. Без установки TCP_NODELAY (которая по-прежнему разрешает алгоритм Нэгла) пакеты, которые могут быть переданы, будут задержаны на период времени, чтобы их можно было объединить с последующими пакетами.

Например, если такой пакет сообщает узлу, что для отправки данных доступно дополнительное окно, задержка его отправки на миллисекунды (или более) может серьезно повлиять на высокоскоростные соединения.

Проблемы с развертыванием

Как я могу отлаживать зашифрованный HTTP/2?

Есть много способов получить доступ к данным приложения, самый простой способ — использоватьNSS keyloggingПоставляется с плагином Wireshark (включен в последнюю версию разработки). Этот метод работает как для Firefox, так и для Chrome.

Как я могу использовать push на стороне сервера с HTTP/2?

Сервер HTTP/2 push позволяет серверам предоставлять контент клиентам, не дожидаясь запросов. Это может сократить время извлечения ресурсов, особенно для тех, у кого большиеПродукты задержки полосы пропусканиясоединений, где на время обращения по сети приходится большая часть времени, затрачиваемого на ресурсы.

Может быть неразумно продвигать ресурсы, которые различаются в зависимости от содержимого запроса. В настоящее время браузеры будут только отправлять запросы, а если они этого не делают, они будут делать соответствующие запросы (см.Section 4 of RFC 7234).

Некоторые кэши не учитывают изменения всех полей заголовка запроса, даже если они перечислены вVaryв поле заголовка. Согласование контента — лучший вариант для максимизации вероятности того, что отправленный ресурс будет получен. на основеaccept-encodingСогласование содержимого для полей заголовков широко используется кэш-памятью, но другие поля заголовков могут не поддерживаться.

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

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

Категории