Включить HTTP 2.0

Включить HTTP 2.0

Включить HTTP 2.0, нельзя пропустить?

Протокол http/2 (Н2), преемник в http/1.x (H1), начал получать значительную поддержку основных поставщиков услуг, таких как CDNs в течение 2016 года. Основная цель разработки Н2, это улучшенная производительность за счет оптимизации:

  • Сжатие заголовков HTTP (через HPACK) – уменьшает объем передаваемых данных
  • Двоичный (не текстовый) протокол — быстрее и проще, чтобы точно интерпретировать
  • Мультиплексирование запросов-позволяет более эффективно использовать и повторно использовать соединения для многих запросов
  • (Необязательно) push-активы могут быть перемещены с сервера на клиента без необходимости запрашивать актив сначала, сохраняя круговую поездку
  • Объединение соединений – запросы на активы(assets)/ресурсы между различными именами узлов могут быть сделаны через одно соединение H2. Это гарантирует меньшее количество TCP-соединений и “рукопожатий” TLS, что снижает общую задержку

Расширяясь в последней точке, объединение соединений может (необязательно) использоваться клиентом только в том случае, если одно и то же соединение TCP / TLS может быть повторно использовано. Повторное использование соединений TCP / TLS логически требует:

  • Каждое имя хоста решает один и тот же IP-адрес – то есть удаленная конечная точка одинакова
  • Имена хостов URL-адресов покрываются / присутствуют в одном сертификате TLS (через общие имена или записи SAN (Subject Alternative Name), либо напрямую, либо в результате подстановочных имен хостов) – то есть соединение TLS будет действительным для каждого имени хоста

Таким образом, запросы, например, a.example .com, b.example .com и c.example .com могут быть сделаны по одному и тому же соединению h2 при условии, что запись DNS для a.example .com, b.example .com и c.example .com в конечном итоге идет на один и тот же IP-адрес, и все приложения a.example .com, b.example .com и c.example .com рассматриваются (либо с помощью записей SAN, либо с помощью подстановочного знака) в том же сертификате TLS, который представлен конечной точкой. Это отличается от h1, когда будет открыто выделенное соединение для имени хоста (фактически, как правило, браузер откроет до 6 соединений для имени хоста для разрешения параллельных запросов), хотя это может быть повторно использовано для нескольких последовательных запросов, если включен режим keep-alive
Из популярной (в Великобритании – нашей главной аудитории) настольных / мобильных веб-браузеров Chrome и Firefox, в частности, предлагают h2-соединение (на момент написания), тогда как, например, Safari, Internet Explorer и Edge этого не делают. Chrome и Firefox составляют значительную долю (около 45%) онлайн-клиентской базы BBC, поэтому необходимо тщательно учитывать объединение соединений, чтобы гарантировать, что HTTP-запросы отправляются на правильный сервер (ы) / службы и что эти серверы / службы являются h2-поддерживаемыми.
Кстати об поддержке, даю ссылку на топик Яндекса, где Елена Першина отвечает на вопрос, поддерживает ли яндекс бот http 2 или нет (не поддерживает, боту яндекса надо отдавать h1 заголовок, но клиенты могут ловить http 2)

Преимущества http2

Оптимизация в h2 делает его привлекательным предложением для BBC Online, поэтому мы провели несколько простых испытаний на веб-сайте BBC, чтобы установить вероятные выгоды для нашей аудитории. В наших внутренних испытаниях обслуживание наших веб-страниц по сетям с высокой задержкой (т. e. Сотнями миллисекунд) оказалось на 40% быстрее, чем в течение 1 года, с небольшим снижением производительности (обычно 0-2%) по очень быстрой, низкой задержке сетей. Небольшое снижение производительности в более быстрых сетях не имеет особого значения (поскольку абсолютная величина задержки введена, очень низкая, а дальнейшая оптимизация в h2, скорее всего, приведет к ее сглаживанию), но улучшение соединений с высокой задержкой явно привлекательно, что должно дать некоторые существенные например, для пользователей в мобильных сетях.
Использование мобильных устройств становится все более распространенным, и BBC Online не является исключением из этой тенденции. Некоторые из наших веб-сайтов продуктов особенно популярны в странах, в которых мобильные сети часто относительно низкого качества; низкой пропускной способностью и высокой задержкой. Аудиториям в таких географических регионах, безусловно, может быть полезно улучшение h2 в производительности и сокращение использования данных (и, следовательно, стоимость). Кроме того, вполне вероятно, что пользователи h2 в плохих сетях могут столкнуться с сокращением использования батареи на мобильных устройствах из-за снижения использования радиоэлектроники в своих устройствах.

Стоит отметить, что h2 имеет определенную известную проблему с блокировкой Head Of Line (HOL) в условиях высоких потерь пакетов. Это было понято во время написания спецификации h2, но было принято как «известная проблема»; были сделаны улучшения для решения этой проблемы в потенциальном преемнике h2, QUIC. Некоторые клиенты прилагают усилия для обнаружения и смягчения блокировки HOL различными способами.

Миграция на http 2

h2 требует поддержки как на стороне клиента, так и на стороне сервера. Помимо небольшого количества заметных исключений, таких как популярное программное обеспечение сервера кэширования HTTP Varnish, для большинства реализаций h2 требуется HTTPS (а не HTTP) соединение. BBC Online начала работать как внутри, так и со сторонними поставщиками, чтобы сделать контент доступным через HTTPS еще в середине / конце 2014 года (наше последнее промежуточное обновление по HTTPS было в блоге Пола Твиди), и именно эта работа выполнила HTTPS предпосылка для широкого распространения h2 для BBC Online.
По дизайну h2 в большинстве случаев можно рассматривать как замену на h1, но есть 2 потенциально важных, но тонких отличия:
Имена заголовков HTTP принудительно строятся с помощью h2-кодеров. Спецификация h1 по контрасту позволяет использовать имена заголовков в смешанном случае, но требует сопоставления / обработки без учета регистра. Таким образом, запросы h1, например, обычно включают заголовок HTTP с именем «Accept-Encoding», который будет представлен как «accept-encoding» в h2.
Коды статуса HTTP содержат только числовой компонент в h2. h1 коды состояния также включают необязательное текстовое поле. Поэтому, если h1, например, вернет код состояния «200 OK», h2 вернется просто «200». Это может иметь значение для, например, прокси / CDN и / или интерфейсный код, который опирается на компонент строки.

Во время нашего первоначального внутреннего тестирования прежнее различие (имена заголовков с принудительной заменой) привело к по меньшей мере одной проблеме для приложения в нашем стеке, которое не справлялось с именами заголовков HTTP без учета регистра – ожидалось типовое поведение h1.

Большинство прокси-подобных приложений и сервисов (таких как CDN), которые предлагают h2, делают это только во входящих соединениях. Первичная связь с источником обычно остается h1 (Сaddyserver – заметное исключение, которое может совмещать https и http/2 подключения).
Во время тестирования мы обнаружили, что один из наших CDN повторно капитализирует «общие» заголовки HTTP-запросов, которые клиентский h2-кодер имеет силовое ограничение. Это кажется немного странным при первой проверке, но я предполагаю, что они пытаются сделать принятие h2 максимально простым, даже для служб происхождения, не соответствующих стандартам.
Вооружившись некоторыми положительными результатами тестов и опытом вышеперечисленных проблем, мы решили включить h2 для BBC Online, сначала в нашу предварительную стадию, затем в производство.

Выбор места для включения H2

Способ, которым BBC доставляет веб-страницы (tl; dr: мы используем маршрутную маршрутизацию), означает, что включение h2 на www. bbc.co.uk и / или www .bbc .com требует от нас подтверждения того, что все отдельные веб-сайты которые находятся на этих общих именах хостов, совместимы с h2 (по крайней мере, как только веб-сайты доступны через HTTPS), так как мы должны включить h2 на основе имени хоста. h2 – включение самих веб-страниц, поэтому потребуется немного времени, чтобы все наши приложения проверялись и проверялись.
Статические активы для наших веб-страниц, однако, являются отличным кандидатом на h2, так как часто существует 80-120 статических активов для типичной веб-страницы BBC, и в основном они обслуживаются одним и тем же CDN через один и тот же слот CDN (слот «Представляет собой выделенный набор IP-адресов с соответствующим сертификатом TLS и конфигурацией) по нескольким именам хостов. Это означает, что пользовательский агент, поддерживающий h2, может использовать объединение соединений h2 и потенциально сделать все эти 80-120 запросов по одному соединению h2, сохраняя значительное количество раундов и “рукопожатий” TLS. Статические активы также крайне маловероятны, что проблемы будут обслуживаться через h2, поскольку динамическая обработка заголовков и т. д. приняты. Шаг 1 будет состоять в статических активах веб-страницы CDN’d.
Включение H2 на нашем CDN
CDN, который мы используем для статических активов нашего веб-сайта, указывает, что при включении h2 мы указываем фильтр имени хоста (либо «is», либо «is not» == ). Это на самом деле очень полезно, потому что нам необходим подробный контроль над тем, какие имена хостов обслуживаются через h2, поскольку, как отмечалось выше, некоторые из наших приложений могут потребовать некоторой работы, чтобы обеспечить правильную работу над h2.
Конфигурация CDN обсуждалась, согласовывалась, объявлялась нашим командам, контролировалась, контролировалась и развертывалась с помощью наших обычных процессов – сначала предварительных условий. Новая конфигурация CDN включала h2 во всех типах активов, за исключением тех, которые могли пострадать от проблем, связанных с заголовками нижнего регистра h2, или еще не были протестированы в течение h2.
Все выглядело хорошо, пока несколько раз не перезагрузили некоторые затронутые страницы, мы заметили, что некоторые имена хостов, которые мы специально запретили h2, использовались в контексте совместного использования h2. Время выполнения отката конфигурации CDN и исследование!
Как только у нас было время посмотреть, что происходит, мы обнаружили проблему. Обратите внимание, что:
Браузер (пользовательский агент), используемый при тестировании, поддерживает h2 и поддерживает объединение соединений
Имя хоста, используемое для всех ресурсов BBC, может отличаться (например, .bbc [i] .co.uk), но большинство из них приводит к соединению с той же конечной точкой CDN
Сертификат TLS, представленный для соединений с конечными точками активов, действителен для всех соответствующих имен хостов

При загрузке веб-страницы BBC браузер, естественно, будет запрашивать наши CDN для ресурсов страницы, как указано в HTML, и загружается скриптами, SVG и т. п. Как только один запрос для актива на имя хоста с включенным h2 случился, все последующие запросы на ресурсы (поскольку они имеют один и тот же слот CDN и сертификат TLS и, следовательно, подходят для объединения соединений) также будут выполняться над h2, независимо от того, запрашиваемое имя хоста включено для h2 или нет!

Почему соединения h2 неожиданно делятся?

CDN «знает», что мы отключили h2 на некоторых именах хостов, а спецификация h2 позволяет сообщать клиенту, что он не должен обслуживать контент через h2, через новый код статуса HTTP – 421 «неверно направленный запрос», , Здесь подробно спецификация важна и, похоже, ввела круговую проблему. Элемент на стороне сервера спецификации h2 указывает:
“Код состояния 421 (Misdirected Request) указывает, что запрос был направлен на сервер, который не может дать ответ. Это может быть отправлено сервером, который не настроен для получения ответов на комбинацию схемы и полномочий, которые включены в URI запроса.”
Проблема в том, что обслуживание 421 не определяется как обязательное поведение. К сожалению, отсутствие жестких требований к возврату 421 усугубляется элементом клиентской стороны спецификации, который гласит:
“Клиенты, получающие ответ от 421 (Misdirected Request) от сервера, МОГУТ повторить запрос – независимо от того, является ли метод запроса идемпотентным или нет – по другому соединению. Это возможно, если соединение повторно используется (раздел 9.1.1) или если выбрана альтернативная услуга [ALT-SVC]”
Проблема в том, что обращение с клиентом 421 также не является обязательным (так как оно указано как «MAY»). В идеале для решения проблемы этот «MAY» будет «SHOULD», поскольку «SHOULD» обычно приводит к большинству реализаций спецификации, включая функцию. Вероятно, нереально изменить этот «MAY» на «MUST», так как возможно, что клиент может, например, иметь ограничения сетевого подключения, которые предотвращают повторную попытку.
Насколько я знаю, Firefox пытается обработать ответ HTTP 421 через повторную попытку, но Chrome в настоящее время этого не делает, хотя работа по его внедрению в Chromium (то есть выше по течению от Chrome) завершена. Большинство других «основных» браузеров, IE, Edge, Safari и др. Не реализуют h2-соединение, но это не относится к ним. Наш поставщик CDN решил не отправлять 421, потому что они не могут полагаться на то, что он обрабатывается клиентом.

Временное решение

После того, как мы обсудили проблему объединения соединений с нашим поставщиком CDN, мы разработали обходное решение, которое призвано нарушить условия, при которых h2-соединения разрешены для совместного использования, и, таким образом, гарантировать, что наши еще не одобренные h2-приложения не будут подаваться через h2.
Поскольку условия объединения соединений являются «одной и той же конечной точкой» и «одним и тем же сертификатом TLS» (т. Е. Одним TLS-соединением), нам нужно сломать хотя бы одно из этих условий, чтобы избежать объединения соединений. Миграция имен хостов между сертификатами оперативно негибкая; у нас есть время подачи сертификата, чтобы рассмотреть в случае, если инцидент означает, что нам нужно отключить / включить h2 для определенных имен хостов, так что это не реалистичный вариант. Теоретически, наш CDN может автоматически обслуживать все конфигурации h2 с поддержкой своих клиентов на выделенных IP-адресах только для h2, но для этого потребуются значительные инженерные работы для нашего поставщика CDN и, следовательно, также нецелесообразно. Поэтому мы решили создать и использовать новый TLS-слот в CDN для проблемных имен хостов, поскольку это приводит к другой группе IP-адресов для этих имен хостов.

Это обходное решение не является идеальным; к сожалению, на практике это довольно хрупкое, но это самое эффективное решение, которое мы имели. Рассмотрим следующий сценарий:

  • В нашей конфигурации CDN требуется новое имя хоста с поддержкой h2.
  • При добавлении нового имени хоста в нашу конфигурацию CDN мы случайно выбираем неправильный «слот» (слот h1-only); это очень легко сделать, учитывая, что нет реальной разницы между конфигурацией слотов
  • Новое имя хоста начинает использоваться на живых веб-страницах, на которых есть только h1-активы
  • Пользователь посещает веб-страницу, содержащую активы под новым именем хоста
  • Когда браузер подключится к новому имени хоста с поддержкой h2, он автоматически сделает запросы h2 одним и тем же соединением для всех имен хостов только для h1 на этой странице, поскольку все они разрешают один и тот же IP-адрес и покрываются сертификатом TLS

Поскольку (как описано выше) протокол h2 не дает надежного способа сообщить браузеру сделать недопустимый запрос, CDN будет обслуживать только h1 активы за h2

Это может показаться не огромной проблемой, но у нас есть около 150 имен хостов по 10 конфигурациям CDN для управления на данный момент (мы будем рушиться вниз по мере консолидации на h2), и это нестандартная практика, так что это очень очень уязвимы для человеческой ошибки. Неплохо, но, по крайней мере, это короткий срок.
Original Frame
Origin Frame – это черновик для расширения спецификации h2, который обеспечивает дополнительный уровень конфигурации при h2-соединении. Использование этого расширения может позволить нам указывать в соответствии со стандартами (то есть не специфично для CDN, описанного в этом случае) наши предпочтения для h2-соединения объединяются по имени host-by-hostname. Использование стандартного метода было бы очень предпочтительным в течение обходного пути, который нам пришлось использовать.

Включение h2 – наконец!

Наше начальное развертывание h2 в нашей конфигурации CDN имело наши h2-совместимые приложения / службы (подавляющее большинство) на одном (только h2) слоте и еще не одобренных h2 приложениях / сервисах на другом (h1-only) слоте. Затем мы перенесли оставшуюся часть наших приложений в слот h2, как только они были подтверждены как h2-совместимые. Теперь мы включили h2 в подавляющее большинство наших услуг, ориентированных на общественность, например, если вы посетите https: //www. bbc.co.uk/ (если вы в Великобритании) или https: // www. bbc .com /pidgin (из любой точки мира) с удобным клиентом (например, Chrome, Firefox, Edge и т. д.), вам будет подана практически вся страница за h2.

> Автор оригинала: Ведущий технический архитектор на BBC. Сноубордист, скейтбордист, муж и отец. Оксфорд, Великобритания.
>  Оригинал статьи на английском
Отставить отзыв

Ваш e-mail не будет опубликован. Обязательные поля помечены *