Производительность и эффективность: работа с HTTP/3

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

Краткий ответ: да, это важно, и вы должны быть в курсе этого. Это похоже на то, как HTTP/2 внес существенные изменения по сравнению с HTTP/1.1, переключившись с ASCII на двоичный код. HTTP/3 снова вносит существенные изменения, на этот раз путем переключения базового транспорта с TCP на UDP.

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

Но есть несколько новых дилемм, связанных с тем, как работает HTTP/3. Кроме того, в чем польза? И что должны знать сетевые инженеры, системные администраторы и разработчики?

Основная проблема: производительность и эффективность

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

100-миллисекундная задержка загрузки веб-сайта может снизить коэффициент конверсии на 7 процентов.

Отчет Akamai об эффективности интернет-магазинов: миллисекунды имеют решающее значение (2017 г.)

Иными словами, сайт электронной коммерции с объемом продаж 40 000 долларов в день будет терять миллион долларов в год из-за такой задержки.

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

Исследования также показали, что:

• 47% потребителей ожидают, что веб-страница загрузится за 2 секунды или меньше.
• 40% людей покидают веб-сайт, который загружается более 3 секунд.

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

HTTP/2? …Что это такое?

Хорошее понимание протокола HTTP/2 имеет решающее значение для понимания HTTP/3. Во-первых, зачем вообще нужен HTTP/2?

HTTP/2 начинался как проект Google под названием SPDY, результат исследования, в котором сообщалось, что самой большой проблемой производительности в Интернете была задержка . Автор пришел к выводу, что «большая пропускная способность не имеет (большого) значения»:

Если провести аналогию между водопроводом и Интернетом, то можно считать, что пропускная способность Интернета равна диаметру водопроводной трубы. Большая труба несет больший объем воды, и, следовательно, вы можете доставить больше воды между двумя точками.

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

Майк Белше

Целью исследования было сокращение времени загрузки страницы. Это показало, что сначала помогает увеличение пропускной способности, поскольку переход с 1 Мбит/с на 2 Мбит/с сокращает вдвое время загрузки страницы. Однако выгоды исчезают очень быстро.

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

HTTP HOL: проблема блокировки очереди

Основной причиной задержки в протоколе HTTP/1 является проблема блокировки заголовка строки. Веб-страницам (почти всегда) требуется несколько ресурсов: CSS, JavaScript, шрифты, изображения, AJAX/XMR и т. д. Это означает, что веб-браузеру необходимо выполнять несколько запросов к серверу. Однако не все ресурсы необходимы для того, чтобы страница стала полезной.

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

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

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

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

Интересно, что в HTTP/1.1 также появилась функция keep-alive , которая позволила браузерам избежать накладных расходов на создание нового TCP-соединения для каждого HTTP-запроса. Это была ранняя попытка решить проблему производительности, связанную с TCP. Это было настолько неэффективно, что большинство экспертов по производительности на самом деле не одобряют его, потому что он тормозит сервер из-за слишком большого количества неактивных подключений. Ниже мы более подробно рассмотрим TCP, а также то, как эта проблема была исправлена ​​в HTTP/2.

Решение HTTP/2 для блокировки HTTP HOL

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

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

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

Двоичный кадр HTTP/2

HTTP/2 переключает стандарт протокола HTTP с неэффективной удобочитаемой модели запроса-ответа ASCII на эффективную двоичную структуру . Это уже не просто запрос и ответ:

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

HTTP/2 HPACK (сжатие заголовков)

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

Cloudflare сообщает о значительной экономии полосы пропускания только благодаря HPACK:

• Сжатие 76% для входящих заголовков
• 53% сокращение общего входящего трафика
• Сжатие 69 % для выходных заголовков
• Снижение общего исходящего трафика на 1,4–15 %

Конечно, использование меньшей пропускной способности обычно означает более быстрый веб-сайт.

Приоритезация потока HTTP/2 и отправка сервера

Вот где мультиплексирование HTTP/2 действительно позволяет серверу максимизировать эффективность. Мультиплексирование действительно помогает обслуживать более быстрые ресурсы (например, кэшированный в памяти JavaScript) перед более медленными (например, большими изображениями, JSON, созданным базой данных и т. д.). Но это также позволяет дополнительно повысить производительность за счет приоритизации потоков HTTP/2.

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

Это особенно важно для прогрессивных веб-приложений (PWA). Например, предположим, что на странице есть четыре файла JavaScript. Два предназначены для функциональности страницы, а два — для рекламы. Наихудший сценарий — загрузить половину функционального JS и половину рекламного JS, а затем перейти к загрузке больших изображений перед загрузкой любого из оставшихся JS. В этом случае изначально ничего на странице не работает, потому что все должно ждать самого медленного ресурса.

Благодаря приоритезации потоков веб-браузеры могут указать серверу отправлять оба JS-файла функциональности страницы перед отправкой любого рекламного JavaScript-файла. Таким образом, пользователям не нужно ждать, пока объявления полностью загрузятся, прежде чем использовать функциональные возможности страницы. Хотя общее время загрузки не улучшилось, воспринимаемая производительность значительно увеличилась. К сожалению, такое поведение в веб-браузере по-прежнему в основном зависит от алгоритмов, а не от веб-разработчиков.

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

К сожалению, обе эти функции требуют тщательной настройки со стороны веб-разработчиков, чтобы действительно добиться успеха. Просто включить их недостаточно.

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

HTTP против принятия HTTP/2

SPDY был создан в 2009 году. HTTP/2 был стандартизирован в 2015 году. SPDY стал названием нестабильной ветки разработки кода, а HTTP/2 стал окончательной версией. В результате SPDY устарел, а HTTP/2 стал стандартом, которому все следуют.

После стандартизации использование HTTP/2 (или «h2») быстро выросло примерно до 40% из 1000 лучших веб-сайтов. В основном это было вызвано тем, что крупные хостинговые и облачные провайдеры развертывали поддержку от имени своих клиентов. К сожалению, несколько лет спустя внедрение HTTP/2 замедлилось, и большая часть Интернета по-прежнему использует HTTP/1.

Отсутствие поддержки браузером режима открытого текста HTTP/2

Было много призывов к HTTP/2, чтобы сделать шифрование обязательной частью стандарта. Вместо этого в стандарте определены режимы как зашифрованного (h2), так и открытого текста (h2c). Таким образом, HTTP/2 может полностью заменить HTTP/1.

Несмотря на стандарт, все современные веб-браузеры поддерживают только HTTP/2 через зашифрованные соединения и намеренно не реализуют режим открытого текста. Вместо этого браузеры полагаются на режим обратной совместимости HTTP/1 для доступа к небезопасным серверам. Это прямой результат идеологического стремления сделать Интернет безопасным по умолчанию.

Почему HTTP/3? И чем оно отличается?

Теперь, когда HTTP/2 решает проблему блокировки заголовка строки HTTP, разработчики протокола обратили свое внимание на следующий по величине фактор задержки: проблему блокировки заголовка строки TCP .

Протокол управления передачей (TCP)

Сети IP (интернет-протокола) основаны на идее компьютеров, отправляющих друг другу пакеты. Пакет — это просто данные с некоторой адресной информацией, прикрепленной к началу.

Но приложениям обычно приходится иметь дело с потоками данных. Для достижения этой иллюзии протокол управления передачей (TCP) представляет приложениям канал , по которому может проходить поток данных. Как и в случае с большинством каналов, существует гарантия того, что данные будут выходить из канала в том же порядке, в котором они входят, что также известно как «первым пришел — первым вышел» (FIFO). Эти характеристики сделали протокол TCP очень полезным и широко применяемым.

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

В октябре 1986 года в Интернете произошел первый из серии «коллапсов перегрузок». За этот период скорость передачи данных от LBL до Калифорнийского университета в Беркли (сайты, разделенные 400 ярдами и тремя переходами IMP) снизилась с 32 кбит/с до 40 бит/с.

В. Джейкобсон (1988)

Вот где возникает проблема блокировки заголовка TCP.

Проблема блокировки TCP HOL

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

Это означает, что данные TCP могут поступать к месту назначения не по порядку, и принимающая сторона обязана переупорядочить пакеты перед повторной сборкой их в поток. К сожалению, это означает, что один потерянный пакет может привести к приостановке всего потока TCP, пока сервер ожидает его повторной передачи. Следовательно, головка линии заблокирована.

Другой проект Google был направлен на решение этой проблемы путем внедрения протокола под названием QUIC.

Протокол QUIC построен поверх UDP вместо TCP, и QUIC формирует основу для HTTP/3.

Что такое УДП?

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

Его цель состоит в том, чтобы быть легким и предоставлять минимум функций, необходимых для обеспечения связи. Таким образом, приложение может реализовать свои собственные гарантии. Это часто очень полезно в приложениях реального времени. Например, при телефонных звонках пользователи обычно предпочитают получать 90 % данных сразу, а не 100 % данных в конечном итоге.

Решение TCP HOL для HTTP/3

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

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

Примечание. Существует множество версий QUIC, так как протокол разрабатывался и внедрялся в производственных средах в течение многих лет. Есть даже специальная версия Google под названием GQUIC. Таким образом, важно различать старые протоколы QUIC и новый стандарт HTTP/3.

Всегда зашифровано

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

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

Влияние HTTP/3 на сетевую инфраструктуру

HTTP/3 вызывает споры. Основные опасения связаны с сетевой инфраструктурой.

HTTP/3 на стороне клиента

На стороне клиента трафик UDP довольно часто жестко ограничен по скорости и/или заблокирован. Применение этих ограничений к HTTP/3 противоречит смыслу протокола.

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

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

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

HTTP/3 на стороне сервера

На стороне сервера рекомендуется блокировать любые порты и протоколы, которые не ожидают трафика, а это означает, что администраторам серверов теперь нужно открывать UDP 443 для HTTP/3, а не полагаться на свои существующие правила TCP 443.

Во-вторых, сетевая инфраструктура может сделать сеансы TCP « липкими », что означает, что они всегда будут направляться на один и тот же сервер даже при изменении приоритетов маршрутизации. Поскольку HTTP/3 работает по протоколу UDP, который является бессессионным, сетевую инфраструктуру необходимо обновить, чтобы отслеживать идентификаторы соединений, характерные для HTTP/3, которые были оставлены незашифрованными специально для обеспечения надежной маршрутизации.

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

Наконец, многие администраторы возражают против необходимости управлять еще большим количеством SSL-сертификатов, хотя теперь, когда доступны такие службы, как Let's Encrypt, это не так важно.

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

Влияние HTTP/3 на веб-разработку

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

Использование HTTP/3 прямо сейчас

Пользователи Google Chrome или браузера Chromium с открытым исходным кодом уже настроены на использование HTTP/3. До выпусков серверов HTTP/3, пригодных для промышленного использования, еще далеко — на момент написания этой статьи спецификация еще не завершена. Но между тем существует множество инструментов, с которыми можно поиграть, и Google, и Cloudflare уже внедрили поддержку в свои производственные среды.

Самый простой способ попробовать это — использовать Caddy в Docker. Для этого необходим SSL-сертификат, поэтому общедоступный IP-адрес упрощает задачу. Шаги:

1. настройка ДНС. Получите рабочее имя хоста, которое активно используется в Интернете, например, yourhostname.example.com IN A 192.0.2.1 .
2. Создание Caddyfile. Он должен содержать такие строки:

 yourhostname.example.com log stdout errors stdout ext .html .htm .md .txt browse gzip tls [email protected]

1. Запуск Caddy: docker run -v Caddyfile:/etc/Caddyfile -p 80:80 -p 443:443 abiosoft/caddy --quic — или вне Docker, caddy --quic .
2. Запуск хрома с включенным QUIC: chromium --enable-quic
3. (Необязательно) Установка расширения индикатора протокола.
4. Переход к серверу с поддержкой QUIC , где должен быть виден файловый браузер.

Разработчики также могут тестировать свои серверы с помощью следующих полезных инструментов:

• Тест Keycdn HTTP/2
• HTTP3Check от LiteSpeed
• Тест SSL-сервера Qualys

Спасибо за прочтение!