HTTP/3: практические варианты развертывания (часть 3)

Здравствуйте, и добро пожаловать в заключительную часть этой серии из трех статей о новых протоколах HTTP/3 и QUIC! Если после предыдущих двух частей — истории HTTP/3 и основных концепций, а также функций производительности HTTP/3 — вы убеждены, что начать использовать новые протоколы — это хорошая идея (и так и должно быть!), то эта заключительная часть включает в себя все вам нужно знать, чтобы начать!

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

Изменения страниц и ресурсов

Начнем с хороших новостей: если вы уже используете HTTP/2, вам, вероятно, не придется ничего менять на своих страницах или ресурсах при переходе на HTTP/3! . Это связано с тем, что, как мы объясняли в частях 1 и 2, HTTP/3 действительно больше похож на HTTP/2 поверх QUIC, и высокоуровневые функции двух версий остались прежними. Таким образом, любые изменения или оптимизации, сделанные для HTTP/2, по-прежнему будут работать для HTTP/3 и наоборот.

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

Лучший универсальный источник информации по HTTP/2, который я могу порекомендовать на данный момент, — это книга Барри Полларда « HTTP/2 в действии ». Однако, поскольку это платный ресурс, и я не хочу, чтобы вы терялись в догадках, ниже я перечислил несколько основных моментов вместе с тем, как они относятся к HTTP/3:

1. Одиночное соединение

Самая большая разница между HTTP/1.1 и HTTP/2 заключалась в переключении с 6 на 30 параллельных TCP-соединений на одно базовое TCP-соединение. В части 2 мы немного обсудили, как одно соединение может быть таким же быстрым, как несколько соединений, из-за того, как управление перегрузкой может привести к большей или более ранней потере пакетов с большим количеством соединений (что сводит на нет преимущества их агрегированного более быстрого запуска). HTTP/3 продолжает этот подход, но «просто» переключается с одного соединения TCP на одно соединение QUIC. Это различие само по себе не так уж много (оно в основном снижает накладные расходы на стороне сервера), но оно приводит к большинству следующих моментов.

2. Разделение серверов и объединение соединений

На практике переключиться на настройку единого соединения было довольно сложно, потому что многие страницы были разбросаны по разным именам хостов и даже серверам (например img1.example.com и img2.example.com ). Это было связано с тем, что браузеры открывали только до шести подключений для каждого отдельного имени хоста, поэтому наличие нескольких соединений позволяло увеличить количество подключений! Без изменений в этой настройке HTTP/1.1 HTTP/2 по-прежнему будет открывать несколько соединений, снижая эффективность работы других функций, таких как расстановка приоритетов (см. ниже).

Таким образом, исходная рекомендация заключалась в том, чтобы отменить сегментирование сервера и максимально консолидировать ресурсы на одном сервере. HTTP/2 даже предоставил функцию, облегчающую переход от настройки HTTP/1.1, называемую объединением соединений. Грубо говоря, если два имени хоста разрешаются в один и тот же IP-адрес сервера (с использованием DNS) и используют одинаковый сертификат TLS, то браузер может повторно использовать одно соединение даже между двумя именами хостов .

На практике объединение соединений может оказаться сложной задачей, например, из-за нескольких тонких проблем с безопасностью, связанных с CORS. Даже если вы настроите его правильно, вы все равно можете легко получить два отдельных соединения. Дело в том, что это не всегда плохо . Во-первых, из-за плохо реализованной приоритезации и мультиплексирования (см. ниже) одно соединение может легко работать медленнее, чем при использовании двух или более. Во-вторых, использование слишком большого количества соединений может привести к преждевременной потере пакетов из-за конкурирующих контроллеров перегрузки. Однако использование всего нескольких (но все же более одного) могло бы хорошо сбалансировать рост перегрузки с повышением производительности, особенно в высокоскоростных сетях. По этим причинам я считаю, что небольшое разбиение все же является хорошей идеей (скажем, от двух до четырех подключений) даже при использовании HTTP/2. На самом деле, я думаю, что большинство современных настроек HTTP/2 работают так же хорошо, как они, потому что у них все еще есть несколько дополнительных подключений или сторонних загрузок на их критическом пути.

3. Объединение ресурсов и встраивание

В HTTP/1.1 у вас мог быть только один активный ресурс для каждого соединения, что приводило к блокировке заголовка строки (HoL) на уровне HTTP. Поскольку количество подключений было ограничено от 6 до 30, объединение ресурсов (когда меньшие подресурсы объединяются в один более крупный ресурс) долгое время было лучшей практикой. Мы все еще видим это сегодня в сборщиках, таких как Webpack. Точно так же ресурсы часто встраивались в другие ресурсы (например, важные CSS встраивались в HTML).

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

Например, вы можете снизить эффективность сжатия, потому что это лучше работает с большим количеством данных. Кроме того, каждый дополнительный запрос или файл имеют неотъемлемые накладные расходы, поскольку они должны обрабатываться браузером и сервером. Эти затраты могут составить, скажем, сотни маленьких файлов по сравнению с несколькими большими. В наших первых тестах я обнаружил серьезное снижение отдачи примерно при 40 файлах. Хотя эти цифры, вероятно, сейчас немного выше, запросы файлов в HTTP/2 все еще не так дешевы, как предполагалось изначально . Наконец, отсутствие встраивания ресурсов приводит к дополнительным затратам на задержку, поскольку файл необходимо запрашивать. Это, в сочетании с проблемами расстановки приоритетов и серверной загрузки (см. ниже), означает, что даже сегодня вам все же лучше встроить некоторые из ваших критически важных CSS. Возможно, когда-нибудь в этом поможет предложение Resource Bundles, но пока нет.

Все это, конечно, справедливо и для HTTP/3. Тем не менее, я читал, что люди утверждают, что многие небольшие файлы будут лучше, чем QUIC, потому что более одновременно активные независимые потоки означают большую прибыль от удаления блокировки HoL (как мы обсуждали в части 2). Я думаю, что в этом может быть доля правды, но, как мы также видели во второй части, это очень сложный вопрос с множеством изменяющихся параметров. Я не думаю, что преимущества перевесят другие обсуждаемые затраты, но необходимы дополнительные исследования. (Было бы возмутительной идеей иметь размер каждого файла, точно соответствующий размеру одного пакета QUIC, полностью обходя блокировку HoL. Я приму гонорары от любого стартапа, который реализует сборщик ресурсов, который делает это. ;))

4. Приоритизация

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

К сожалению, это то, с чем вы, как средний веб-разработчик, мало что можете поделать, потому что это в основном проблема самих браузеров и серверов. Однако вы можете попытаться смягчить проблему, не используя слишком много отдельных файлов (что снизит вероятность конкурирующих приоритетов) и по-прежнему используя (ограниченное) сегментирование. Другой вариант — использовать различные методы, влияющие на приоритет, такие как defer загрузка, async и отсрочка JavaScript, а также подсказки ресурсов, такие как preload загрузка. Внутри они в основном изменяют приоритеты ресурсов, чтобы они отправлялись раньше или позже. Однако эти механизмы могут (и страдают) от ошибок. Кроме того, не ожидайте preload кучи ресурсов и ускорения работы: если все внезапно становится высоким приоритетом, то ничего не становится! Даже очень легко задержать действительно важные ресурсы, используя такие вещи, как preload .

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

5. Отправка сервера и первый полет

Сервер push позволяет серверу отправлять ответные данные, не дожидаясь запроса от клиента. Опять же, в теории это звучит великолепно, и это можно использовать вместо встраивания ресурсов (см. выше). Однако, как обсуждалось в части 2, push очень сложно правильно использовать из-за проблем с контролем перегрузки, кэшированием, приоритизацией и буферизацией. В целом, лучше не использовать его для обычной загрузки веб-страниц , если вы действительно не знаете, что делаете, и даже в этом случае, вероятно, это будет микрооптимизация. Я по-прежнему считаю, что это может иметь место с (REST) ​​API, где вы можете передавать подресурсы, связанные с ответом (JSON) при прогретом соединении. Это справедливо как для HTTP/2, так и для HTTP/3.

Немного обобщая, я считаю, что аналогичные замечания можно сделать для возобновления сеанса TLS и 0-RTT, будь то через TCP + TLS или через QUIC. Как обсуждалось во второй части, 0-RTT похож на серверную проталкивание (как он обычно используется) в том, что он пытается ускорить самые первые этапы загрузки страницы. Однако это означает, что он в равной степени ограничен в своих возможностях в то время (тем более в QUIC из-за соображений безопасности). Таким образом, микрооптимизация — это, опять же, то, как вам, вероятно, нужно настроить вещи на низком уровне, чтобы действительно извлечь из этого пользу. И подумать только, я когда-то был очень взволнован, пытаясь объединить push-уведомление сервера с 0-RTT.

Что все это значит?

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

Вот некоторые конкретные моменты, которые в основном справедливы как для HTTP/2, так и для HTTP/3:

1. Разделите ресурсы примерно на одно-три соединения на критическом пути (если только ваши пользователи не работают в основном в сетях с низкой пропускной способностью), используя preconnect и dns-prefetch там, где это необходимо.
2. Логически объединяйте подресурсы по пути или функции или по частоте изменений. От пяти до десяти ресурсов JavaScript и от пяти до десяти ресурсов CSS на странице должно быть вполне достаточно. Встраивание критически важного CSS все еще может быть хорошей оптимизацией.
3. Используйте сложные функции, такие как preload , экономно.
4. Используйте сервер, который должным образом поддерживает приоритизацию HTTP/2. Для HTTP/2 я рекомендую H2O. Apache и NGINX в основном подходят (хотя могли бы работать лучше), в то время как Node.js следует избегать для HTTP/2. Для HTTP/3 в настоящее время все менее ясно (см. ниже).
5. Убедитесь, что TLS 1.3 включен на вашем веб-сервере HTTP/2.

Как видите, хотя это и далеко не просто, оптимизация страниц для HTTP/3 (и HTTP/2) не является сложной задачей. Однако сложнее будет правильно настроить HTTP/3-серверы, клиенты и инструменты.

Серверы и сети

Как вы, наверное, уже поняли, QUIC и HTTP/3 — довольно сложные протоколы. Их реализация с нуля потребует прочтения (и понимания!) сотен страниц в более чем семи документах. К счастью, несколько компаний уже более пяти лет работают над реализациями QUIC и HTTP/3 с открытым исходным кодом, поэтому у нас есть несколько проверенных и стабильных вариантов на выбор.

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

Однако многие (возможно, большинство) этих реализаций в основном заботятся о HTTP/3 и QUIC; сами по себе они не являются полноценными веб-серверами . Когда дело доходит до ваших типичных серверов (например, NGINX, Apache, Node.js), все работает немного медленнее по нескольким причинам. Во-первых, немногие из их разработчиков с самого начала были связаны с HTTP/3, и теперь им приходится играть в догонялки. Многие обходят это, используя одну из перечисленных выше реализаций внутри в качестве библиотек, но даже такая интеграция сложна.

Во-вторых, многие серверы зависят от сторонних библиотек TLS, таких как OpenSSL. Это, опять же, связано с тем, что TLS очень сложен и должен быть безопасным, поэтому лучше повторно использовать существующую проверенную работу. Однако, хотя QUIC интегрируется с TLS 1.3, он использует его способами, сильно отличающимися от того, как взаимодействуют TLS и TCP . Это означает, что библиотеки TLS должны предоставлять API-интерфейсы, специфичные для QUIC, что их разработчики долгое время делали неохотно или медленно. Проблема здесь особенно в OpenSSL, который отложил поддержку QUIC, но он также используется многими серверами. Эта проблема стала настолько серьезной, что Akamai решила запустить форк OpenSSL для QUIC, названный quictls. Хотя существуют другие варианты и обходные пути, поддержка TLS 1.3 для QUIC по-прежнему блокирует многие серверы и, как ожидается, останется таковой в течение некоторого времени.

Частичный список полных веб-серверов, которые вы должны иметь возможность использовать «из коробки», вместе с их текущей поддержкой HTTP/3, приведен ниже:

• Апачи
  Поддержка неясна в это время. Ничего не было объявлено. Вероятно, ему также нужен OpenSSL. (Обратите внимание, что существует реализация Apache Traffic Server.)
• Nginx
  Это пользовательская реализация. Это относительно новый и все еще экспериментальный метод. Ожидается, что к концу 2021 года он будет объединен с основным NGINX. Это относительно новый и все еще экспериментальный вариант. Обратите внимание, что есть патч для запуска библиотеки Cloudflare quiche на NGINX, который, вероятно, на данный момент более стабилен.
• Node.js
  Это использует внутреннюю библиотеку ngtcp2. Это заблокировано прогрессом OpenSSL, хотя они планируют переключиться на форк QUIC-TLS, чтобы что-то заработало раньше.
• ИИС
  В настоящее время поддержка неясна, и ничего не было объявлено. Однако внутри он, скорее всего, будет использовать библиотеку MsQuic.
• Гиперкорн
  Это интегрирует aioquic с экспериментальной поддержкой.
• Кэдди
  Это использует quic-go с полной поддержкой.
• Н2О
  Это используется быстро, с полной поддержкой.
• лайтспид
  При этом используется LSQUIC с полной поддержкой.

Учтите несколько важных нюансов:

• Даже «полная поддержка» означает «насколько она хороша на данный момент», не обязательно «готова к производству». Например, многие реализации еще не полностью поддерживают миграцию соединений, 0-RTT, принудительную передачу на сервер или приоритизацию HTTP/3 .
• Другие серверы, не указанные в списке, такие как Tomcat, (насколько мне известно) еще не анонсировали.
• Из перечисленных веб-серверов только Litespeed, Cloudflare's NGINX patch и H2O были созданы людьми, тесно вовлеченными в стандартизацию QUIC и HTTP/3, поэтому они, скорее всего, будут работать лучше всего на ранних этапах.
  

Как видите, серверный ландшафт еще не полностью готов, но, безусловно, уже есть варианты для настройки сервера HTTP/3. Однако просто запустить сервер — это только первый шаг. Настроить его и остальную часть вашей сети сложнее.

конфигурация сети

Как объяснялось в части 1, QUIC работает поверх протокола UDP, чтобы упростить его развертывание. Это, однако, в основном просто означает, что большинство сетевых устройств могут анализировать и понимать UDP. К сожалению, это не означает, что UDP разрешен повсеместно . Поскольку UDP часто используется для атак и не критичен для нормальной повседневной работы, кроме DNS, многие (корпоративные) сети и брандмауэры почти полностью блокируют протокол. Таким образом, UDP, вероятно, должен быть явно разрешен к/от ваших серверов HTTP/3 . QUIC может работать на любом порту UDP, но ожидается, что порт 443 (который также обычно используется для HTTPS через TCP) будет наиболее распространенным.

Однако многие сетевые администраторы не захотят просто разрешать оптовую продажу UDP. Вместо этого они специально захотят разрешить QUIC через UDP. Проблема в том, что, как мы видели, QUIC почти полностью зашифрован. Сюда входят метаданные уровня QUIC, такие как номера пакетов, а также, например, сигналы, указывающие на закрытие соединения. Для TCP брандмауэры активно отслеживают все эти метаданные, чтобы проверить ожидаемое поведение. (Видели ли мы полное рукопожатие перед пакетами, переносящими данные? Соответствуют ли пакеты ожидаемым шаблонам? Сколько существует открытых соединений?) Как мы видели в части 1, это как раз одна из причин, по которой TCP больше практически не развивается. Однако из-за шифрования QUIC брандмауэры могут гораздо меньше выполнять эту логику отслеживания на уровне подключения , а те несколько битов, которые они могут проверять, относительно сложны.

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

Все это еще больше усложняется функцией миграции соединений. Как мы видели, эта функция позволяет продолжать соединение с нового IP-адреса без необходимости выполнять новое рукопожатие, используя идентификаторы соединения (CID). Однако для брандмауэра это будет выглядеть так, как если бы новое соединение использовалось без предварительного рукопожатия, что с таким же успехом могло бы быть злоумышленником, отправляющим вредоносный трафик. Брандмауэры не могут просто использовать CID QUIC, потому что они также со временем меняются для защиты конфиденциальности пользователей! Таким образом, серверам будет необходимо сообщать брандмауэру о том, какие CID ожидаются , но ничего из этого пока не существует.

Аналогичные проблемы возникают и с балансировщиками нагрузки для крупномасштабных установок. Эти машины распределяют входящие соединения по большому количеству внутренних серверов. Трафик для одного соединения должен, конечно, всегда направляться на один и тот же внутренний сервер (другие не будут знать, что с ним делать!). Для TCP это можно просто сделать на основе 4-х кортежей, потому что они никогда не меняются. Однако с миграцией соединения QUIC это больше не вариант. Опять же, серверам и балансировщикам нагрузки нужно будет каким-то образом договориться о том, какие CID выбрать, чтобы разрешить детерминированную маршрутизацию . Однако, в отличие от конфигурации брандмауэра, уже есть предложение по его настройке (хотя это далеко не так широко реализовано).

Наконец, есть и другие соображения безопасности более высокого уровня, в основном связанные с атаками 0-RTT и распределенными атаками типа «отказ в обслуживании» (DDoS). Как обсуждалось во второй части, QUIC уже включает в себя довольно много способов устранения этих проблем, но в идеале они также будут использовать дополнительные линии защиты в сети. Например, прокси-серверы или пограничные серверы могут блокировать определенные запросы 0-RTT от доступа к фактическим внутренним серверам, чтобы предотвратить атаки повторного воспроизведения. В качестве альтернативы, чтобы предотвратить атаки с отражением или DDoS-атаки, которые отправляют только первый пакет рукопожатия, а затем перестают отвечать (называется SYN-флудом в TCP), QUIC включает функцию повтора. Это позволяет серверу удостовериться, что это клиент с хорошим поведением, без необходимости сохранять какое-либо состояние в то же время (эквивалент файлов cookie TCP SYN). Этот процесс повторной попытки лучше всего происходит, конечно, где-то перед внутренним сервером — например, на балансировщике нагрузки. Опять же, для этого требуется дополнительная настройка и связь.

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

Что все это значит?

HTTP/3 и QUIC — это сложные протоколы, использующие множество внутренних механизмов. Не все из них пока готовы к использованию в прайм-тайм , хотя у вас уже есть некоторые возможности для развертывания новых протоколов на серверной части. Однако обновление наиболее известных серверов и базовых библиотек (таких как OpenSSL), вероятно, займет от нескольких месяцев до даже лет.

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

Таким образом, особенно в первые дни, вероятно, лучше всего полагаться на крупную хостинговую компанию или CDN для установки и настройки протоколов для вас. Как обсуждалось во второй части, именно здесь QUIC, скорее всего, окупится, а использование CDN — один из ключевых способов оптимизации производительности, который вы можете сделать. Я бы лично рекомендовал использовать Cloudflare или Fastly, потому что они были тесно вовлечены в процесс стандартизации и будут иметь самые продвинутые и хорошо настроенные доступные реализации.

Клиенты и QUIC Discovery

До сих пор мы рассматривали поддержку новых протоколов на стороне сервера и в сети. Тем не менее, некоторые проблемы также должны быть преодолены на стороне клиента.

Прежде чем перейти к этому, давайте начнем с хороших новостей: большинство популярных браузеров уже имеют (экспериментальную) поддержку HTTP/3! В частности, на момент написания статьи вот статус поддержки (см. также caniuse.com):

• Google Chrome (версия 91+) : включен по умолчанию.
• Mozilla Firefox (версия 89+) : включено по умолчанию.
• Microsoft Edge (версия 90+) : включен по умолчанию (внутренне использует Chromium).
• Opera (версия 77+) : включено по умолчанию (внутренне использует Chromium).
• Apple Safari (версия 14) : за ручным флагом. Будет включен по умолчанию в версии 15, которая в настоящее время находится на стадии предварительной версии.
• Другие браузеры : пока нет сигналов, о которых мне известно (хотя другие браузеры, которые используют Chromium внутри, например Brave, теоретически могут также включить его).

Обратите внимание на некоторые нюансы:

• Большинство браузеров внедряются постепенно, поэтому не у всех пользователей поддержка HTTP/3 будет включена по умолчанию с самого начала. Это делается для ограничения риска того, что одна пропущенная ошибка может затронуть многих пользователей или что развертывание серверов станет перегруженным. Таким образом, есть небольшой шанс, что даже в последних версиях браузера вы не получите HTTP/3 по умолчанию, и вам придется включать его вручную.
• Как и в случае с серверами, поддержка HTTP/3 не означает, что в настоящее время реализованы или используются все функции. В частности, 0-RTT, миграция соединений, отправка на сервер, динамическое сжатие заголовков QPACK и приоритизация HTTP/3 могут по-прежнему отсутствовать, отключаться, использоваться экономно или плохо настроены.
• Если вы хотите использовать HTTP/3 на стороне клиента вне браузера (например, в своем собственном приложении), вам придется интегрировать одну из перечисленных выше библиотек или использовать cURL. Apple скоро добавит встроенную поддержку HTTP/3 и QUIC в свои встроенные сетевые библиотеки в macOS и iOS, а Microsoft добавляет QUIC в ядро ​​Windows и свою среду .NET, но аналогичная встроенная поддержка (насколько мне известно) еще не реализована. анонсировано для других систем, таких как Android.

Alt-Svc

Даже если вы настроили HTTP/3-совместимый сервер и используете обновленный браузер, вы можете быть удивлены, обнаружив, что HTTP/3 на самом деле не используется постоянно . Чтобы понять почему, давайте на мгновение представим себя браузером. Ваш пользователь запросил, чтобы вы перешли на example.com (веб-сайт, который вы никогда раньше не посещали), и вы использовали DNS для преобразования его в IP-адрес. Вы отправляете один или несколько пакетов рукопожатия QUIC на этот IP-адрес. Теперь несколько вещей могут пойти не так:

1. Сервер может не поддерживать QUIC.
2. Одна из промежуточных сетей или брандмауэров может полностью заблокировать QUIC и/или UDP.
3. Пакеты рукопожатия могут быть потеряны в пути.

Однако как узнать, какая из этих проблем возникла ? Во всех трех случаях вы никогда не получите ответа на свой пакет(ы) рукопожатия. Единственное, что вы можете сделать, это подождать, надеясь, что ответ все еще может прийти. Затем, после некоторого времени ожидания (тайм-аута), вы можете решить, что проблема с HTTP/3 действительно существует. В этот момент вы попытаетесь открыть TCP-соединение с сервером, надеясь, что HTTP/2 или HTTP/1.1 будут работать.

Как видите, такой подход может привести к серьезным задержкам, особенно в первые годы, когда многие серверы и сети еще не будут поддерживать QUIC. Простое, но наивное решение состояло бы в том, чтобы просто открыть соединение QUIC и TCP одновременно, а затем использовать рукопожатие, которое завершится первым . Этот метод называется «гонка соединений» или «счастливые глазные яблоки». Хотя это, безусловно, возможно, это требует значительных накладных расходов. Несмотря на то, что потерянное соединение закрывается почти сразу, оно все равно занимает некоторое количество памяти и процессорного времени как на клиенте, так и на сервере (особенно при использовании TLS). Кроме того, у этого метода есть и другие проблемы, связанные с сетями IPv4 и IPv6, а также с ранее обсуждаемыми атаками повторного воспроизведения (о которых я расскажу более подробно).

Таким образом, для QUIC и HTTP/3 браузеры предпочли бы перестраховаться и попробовать QUIC только в том случае, если они знают, что сервер его поддерживает . Таким образом, при первом обращении к новому серверу браузер будет использовать только HTTP/2 или HTTP/1.1 через TCP-соединение. Затем сервер может сообщить браузеру, что он также поддерживает HTTP/3 для последующих подключений. Это делается путем установки специального заголовка HTTP для ответов, отправляемых обратно через HTTP/2 или HTTP/1.1. Этот заголовок называется Alt-Svc , что означает «альтернативные услуги». Alt-Svc можно использовать, чтобы сообщить браузеру, что определенная служба также доступна через другой сервер (IP и/или порт), но также позволяет указать альтернативные протоколы. Это можно увидеть ниже на рисунке 1.

При получении действительного заголовка Alt-Svc , указывающего на поддержку HTTP/3, браузер кэширует его и с этого момента пытается установить соединение QUIC. Некоторые клиенты сделают это как можно скорее (даже во время начальной загрузки страницы — см. ниже), в то время как другие будут ждать закрытия существующих TCP-соединений. Это означает, что браузер будет использовать HTTP/3 только после того, как он сначала загрузит хотя бы несколько ресурсов через HTTP/2 или HTTP/1.1 . Даже тогда не все гладко. Браузер теперь знает, что сервер поддерживает HTTP/3, но это не означает, что промежуточная сеть не будет его блокировать. Таким образом, гонка соединений по-прежнему необходима на практике. Таким образом, вы все равно можете получить HTTP/2, если сеть каким-то образом достаточно задержит рукопожатие QUIC. Кроме того, если соединение QUIC не удается установить несколько раз подряд, некоторые браузеры помещают запись кэша Alt-Svc в список запрещенных на некоторое время, не пробуя HTTP/3 какое-то время. Таким образом, может быть полезно вручную очистить кеш вашего браузера, если что-то не так, потому что это также должно очистить привязки Alt-Svc . Наконец, было показано, что Alt-Svc представляет серьезную угрозу безопасности. По этой причине некоторые браузеры накладывают дополнительные ограничения, например, на то, какие порты можно использовать (в Chrome ваши серверы HTTP/2 и HTTP/3 должны быть либо на порту ниже 1024, либо на порту выше или равном на 1024, иначе Alt-Svc будет проигнорирован). Вся эта логика различается и бурно развивается в разных браузерах, а это означает, что получение согласованных HTTP/3-соединений может быть затруднено , что также усложняет тестирование новых настроек.

Продолжается работа по улучшению этого двухэтапного процесса Alt-Svc . Идея состоит в том, чтобы использовать новые записи DNS, называемые SVCB и HTTPS, которые будут содержать информацию, аналогичную той, что находится в Alt-Svc . Таким образом, клиент может обнаружить, что сервер поддерживает HTTP/3 на этапе разрешения DNS, а это означает, что он может попробовать QUIC с самой первой загрузки страницы вместо того, чтобы сначала проходить через HTTP/2 или HTTP/1.1. Для получения дополнительной информации об этом и Alt-Svc см. прошлогодний веб-альманах, главу, посвященную HTTP/2.

Как видите, Alt-Svc и процесс обнаружения HTTP/3 усложняют и без того сложное развертывание сервера QUIC, потому что:

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

Хотя это должно быть управляемым в установках производственного уровня (поскольку, например, один экземпляр Apache или NGINX, вероятно, будет поддерживать все три версии HTTP одновременно), это может быть гораздо более раздражающим в (локальном) тестовом наборе. ups (я уже вижу, как забываю добавить заголовки Alt-Svc или путаю их). Эта проблема усугубляется (текущим) отсутствием журналов ошибок браузера и индикаторов DevTools, а это означает, что выяснить, почему именно установка не работает, может быть сложно.

Дополнительные вопросы

Как будто этого было недостаточно, еще одна проблема усложнит локальное тестирование: Chrome очень затрудняет использование самозаверяющих TLS-сертификатов для QUIC . Это связано с тем, что неофициальные сертификаты TLS часто используются компаниями для расшифровки TLS-трафика своих сотрудников (чтобы они могли, например, сканировать свои брандмауэры внутри зашифрованного трафика). Однако, если бы компании начали делать это с QUIC, у нас снова были бы пользовательские реализации промежуточных блоков, которые делают свои собственные предположения о протоколе. Это может привести к тому, что они могут нарушить поддержку протокола в будущем, и именно это мы пытались предотвратить, в первую очередь, так широко зашифровав QUIC! As such, Chrome takes a very opinionated stance on this: If you're not using an official TLS certificate (signed by a certificate authority or root certificate that is trusted by Chrome, such as Let's Encrypt), then you cannot use QUIC . This, sadly, also includes self-signed certificates, which are often used for local test set-ups.

It is still possible to bypass this with some freaky command-line flags (because the common --ignore-certificate-errors doesn't work for QUIC yet), by using per-developer certificates (although setting this up can be tedious), or by setting up the real certificate on your development PC (but this is rarely an option for big teams because you would have to share the certificate's private key with each developer). Finally, while you can install a custom root certificate, you would then also need to pass both the --origin-to-force-quic-on and --ignore-certificate-errors-spki-list flags when starting Chrome (see below). Luckily, for now, only Chrome is being so strict, and hopefully, its developers will loosen their approach over time.

If you are having problems with your QUIC set-up from inside a browser, it's best to first validate it using a tool such as cURL. cURL has excellent HTTP/3 support (you can even choose between two different underlying libraries) and also makes it easier to observe Alt-Svc caching logic.

Что все это значит?

Next to the challenges involved with setting up HTTP/3 and QUIC on the server-side, there are also difficulties in getting browsers to use the new protocols consistently. This is due to a two-step discovery process involving the Alt-Svc HTTP header and the fact that HTTP/2 connections cannot simply be “upgraded” to HTTP/3, because the latter uses UDP.

Even if a server supports HTTP/3, however, clients (and website owners!) need to deal with the fact that intermediate networks might block UDP and/or QUIC traffic. As such, HTTP/3 will never completely replace HTTP/2 . In practice, keeping a well-tuned HTTP/2 set-up will remain necessary both for first-time visitors and visitors on non-permissive networks. Luckily, as we discussed, there shouldn't be many page-level changes between HTTP/2 and HTTP/3, so this shouldn't be a major headache.

What could become a problem, however, is testing and verifying whether you are using the correct configuration and whether the protocols are being used as expected. This is true in production, but especially in local set-ups. As such, I expect that most people will continue to run HTTP/2 (or even HTTP/1.1) development servers , switching only to HTTP/3 in a later deployment stage. Even then, however, validating protocol performance with the current generation of tools won't be easy.

Tools and Testing

As was the case with many major servers, the makers of the most popular web performance testing tools have not been keeping up with HTTP/3 from the start. Consequently, few tools have dedicated support for the new protocol as of July 2021, although they support it to a certain degree.

Google Маяк

First, there is the Google Lighthouse tool suite. While this is an amazing tool for web performance in general, I have always found it somewhat lacking in aspects of protocol performance. This is mostly because it simulates slow networks in a relatively unrealistic way, in the browser (the same way that Chrome's DevTools handle this). While this approach is quite usable and typically “good enough” to get an idea of the impact of a slow network, testing low-level protocol differences is not realistic enough. Because the browser doesn't have direct access to the TCP stack, it still downloads the page on your normal network, and it then artificially delays the data from reaching the necessary browser logic. This means, for example, that Lighthouse emulates only delay and bandwidth, but not packet loss (which, as we've seen, is a major point where HTTP/3 could potentially differ from HTTP/2). Alternatively, Lighthouse uses a highly advanced simulation model to guesstimate the real network impact, because, for example, Google Chrome has some complex logic that tweaks several aspects of a page load if it detects a slow network. This model has, to the best of my knowledge, not been adjusted to handle IETF QUIC or HTTP/3 yet. As such, if you use Lighthouse today for the sole purpose of comparing HTTP/2 and HTTP/3 performance, then you are likely to get erroneous or oversimplified results, which could lead you to wrong conclusions about what HTTP/3 can do for your website in practice. The silver lining is that, in theory, this can be improved massively in the future, because the browser does have full access to the QUIC stack, and thus Lighthouse could add much more advanced simulations (including packet loss!) for HTTP/3 down the line. For now, though, while Lighthouse can, in theory, load pages over HTTP/3, I would recommend against it.

WebPageTest

Secondly, there is WebPageTest. This amazing project lets you load pages over real networks from real devices across the world, and it also allows you to add packet-level network emulation on top, including aspects such as packet loss! As such, WebPageTest is conceptually in a prime position to be used to compare HTTP/2 and HTTP/3 performance. However, while it can indeed already load pages over the new protocol, HTTP/3 has not yet been properly integrated into the tooling or visualizations . For example, there are currently no easy ways to force a page load over QUIC, to easily view how Alt-Svc was actually used, or even to see QUIC handshake details. In some cases, even seeing whether a response used HTTP/3 or HTTP/2 can be challenging. Still, in April, I was able to use WebPageTest to run quite a few tests on facebook.com and see HTTP/3 in action, which I'll go over now.

First, I ran a default test for facebook.com , enabling the “repeat view” option. As explained above, I would expect the first page load to use HTTP/2, which will include the Alt-Svc response header. As such, the repeat view should use HTTP/3 from the start. In Firefox version 89, this is more or less what happens. However, when looking at individual responses, we see that even during the first page load, Firefox will switch to using HTTP/3 instead of HTTP/2 ! As you can see in figure 2, this happens from the 20th resource onwards. This means that Firefox establishes a new QUIC connection as soon as it sees the Alt-Svc header, and it switches to it once it succeeds. If you scroll down to the connection view, it also seems to show that Firefox even opened two QUIC connections: one for credentialed CORS requests and one for no-CORS requests. This would be expected because, as we discussed above, even for HTTP/2 and HTTP/3, browsers will open multiple connections due to security concerns. However, because WebPageTest doesn't provide more details in this view, it's difficult to confirm without manually digging through the data. Looking at the repeat view (second visit), it starts by directly using HTTP/3 for the first request, as expected.

Next, for Chrome, we see similar behavior for the first page load, although here Chrome already switches on the 10th resource, much earlier than Firefox. It's a bit more unclear here whether it switches as soon as possible or only when a new connection is needed (for example, for requests with different credentials), because, unlike for Firefox, the connection view also doesn't seem to show multiple QUIC connections. For the repeat view, we see some weirder things. Unexpectedly, Chrome starts off using HTTP/2 there as well , switching to HTTP/3 only after a few requests! I performed a few more tests on other pages as well, to confirm that this is indeed consistent behaviour. This could be due to several things: It might just be Chrome's current policy, it might be that Chrome “raced” a TCP and QUIC connection and TCP won initially, or it might be that the Alt-Svc cache from the first view was unused for some reason. At this point, there is, sadly, no easy way to determine what the problem really is (and whether it can even be fixed).

Another interesting thing I noticed here is the apparent connection coalescing behavior. As discussed above, both HTTP/2 and HTTP/3 can reuse connections even if they go to other hostnames, to prevent downsides from hostname sharding. However, as shown in figure 3, WebPageTest reports that, for this Facebook load, connection coalescing is used over HTTP/3 for facebook.com and fbcdn.net , but not over HTTP/2 (as Chrome opens a secondary connection for the second domain). I suspect this is a bug in WebPageTest, however, because facebook.com and fbcnd.net resolve to different IPs and, as such, can't really be coalesced.

The figure also shows that some key QUIC handshake information is missing from the current WebPageTest visualization.

Note : As we see, getting “real” HTTP/3 going can be difficult sometimes. Luckily, for Chrome specifically, we have additional options we can use to test QUIC and HTTP/3, in the form of command-line parameters.

On the bottom of WebPageTest's “Chromium” tab, I used the following command-line options:

 --enable-quic --quic-version=h3-29 --origin-to-force-quic-on=www.facebook.com:443,static.xx.fbcdn.net:443

The results from this test show that this indeed forces a QUIC connection from the start, even in the first view, thus bypassing the Alt-Svc process. Interestingly, you will notice I had to pass two hostnames to --origin-to-force-quic-on . In the version where I didn't, Chrome, of course, still first opened an HTTP/2 connection to the fbcnd.net domain, even in the repeat view. As such, you'll need to manually indicate all QUIC origins in order for this to work !

We can see even from these few examples that a lot of stuff is going on with how browsers actually use HTTP/3 in practice. It seems they even switch to the new protocol during the initial page load, abandoning HTTP/2 either as soon as possible or when a new connection is needed. As such, it's difficult not only getting a full HTTP/3 load, but also getting a pure HTTP/2 load on a set-up that supports both ! Because WebPageTest doesn't show much HTTP/3 or QUIC metadata yet, figuring out what's going on can be challenging, and you can't trust the tools and visualizations at face value either.

So, if you use WebPageTest, you'll need to double-check the results to make sure which protocols were actually used. Consequently, I think this means that it's too early to really test HTTP/3 performance at this time (and especially too early to compare it to HTTP/2). This belief is strengthened by the fact that not all servers and clients have implemented all protocol features yet. Due to the fact that WebPageTest doesn't yet have easy ways of showing whether advanced aspects such as 0-RTT were used, it will be tricky to know what you're actually measuring. This is especially true for the HTTP/3 prioritization feature, which isn't implemented properly in all browsers yet and which many servers also lack full support for. Because prioritization can be a major aspect driving web performance, it would be unfair to compare HTTP/3 to HTTP/2 without making sure that at least this feature works properly (for both protocols!). This is just one aspect, though, as my research shows how big the differences between QUIC implementations can be. If you do any comparison of this sort yourself (or if you read articles that do), make 100% sure that you've checked what's actually going on .

Finally, also note that other higher-level tools (or data sets such as the amazing HTTP Archive) are often based on WebPageTest or Lighthouse (or use similar methods), so I suspect that most of my comments here will be widely applicable to most web performance tooling. Even for those tool vendors announcing HTTP/3 support in the coming months, I would be a bit skeptical and would validate that they're actually doing it correctly. For some tools, things are probably even worse, though; for example, Google's PageSpeed Insights only got HTTP/2 support this year, so I wouldn't wait for HTTP/3 arriving anytime soon.

Wireshark, qlog и qvis

Как видно из приведенного выше обсуждения, на данном этапе может быть сложно проанализировать поведение HTTP/3, просто используя Lighthouse или WebPageTest. К счастью, для этого доступны другие инструменты более низкого уровня. Во-первых, отличный инструмент Wireshark имеет расширенную поддержку QUIC, а также может экспериментально анализировать HTTP/3. Это позволяет вам наблюдать, какие пакеты QUIC и HTTP/3 фактически передаются по сети. Однако для того, чтобы это работало, вам необходимо получить ключи расшифровки TLS для данного соединения, которые в большинстве реализаций (включая Chrome и Firefox) позволяют извлекать с помощью переменной среды SSLKEYLOGFILE . Хотя это может быть полезно для некоторых вещей, действительное выяснение того, что происходит, особенно для более длинных соединений, может потребовать много ручной работы. Вам также потребуется довольно глубокое понимание внутренней работы протоколов.

К счастью, есть второй вариант — qlog и qvis. qlog — это формат ведения журнала на основе JSON, специально предназначенный для QUIC и HTTP/3, который поддерживается большинством реализаций QUIC. Вместо просмотра пакетов, проходящих по сети, qlog собирает эту информацию напрямую на клиенте и сервере, что позволяет включать некоторую дополнительную информацию (например, сведения об управлении перегрузкой). Как правило, вывод qlog можно активировать при запуске серверов и клиентов с помощью переменной среды QLOGDIR . (Обратите внимание, что в Firefox вам необходимо установить предпочтение network.http.http3.enable_qlog . Устройства Apple и Safari вместо этого используют QUIC_LOG_DIRECTORY . Chrome пока не поддерживает qlog.)

Затем эти файлы qlog можно загрузить в набор инструментов qvis по адресу qvis.quictools.info. Там вы получите ряд расширенных интерактивных визуализаций, упрощающих интерпретацию трафика QUIC и HTTP/3 . qvis также поддерживает загрузку захватов пакетов Wireshark (файлы .pcap ) и имеет экспериментальную поддержку файлов сетевого журнала Chrome, поэтому вы также можете анализировать поведение Chrome. Полное руководство по qlog и qvis выходит за рамки этой статьи, но более подробную информацию можно найти в форме руководства, в виде статьи и даже в формате ток-шоу. Вы также можете спросить меня о них напрямую, потому что я являюсь основным разработчиком qlog и qvis. ;)

Однако я не питаю иллюзий, что большинству читателей здесь когда-либо стоит использовать Wireshark или qvis, потому что это довольно низкоуровневые инструменты. Тем не менее, поскольку на данный момент у нас мало альтернатив, я настоятельно рекомендую не проводить интенсивное тестирование производительности HTTP/3 без использования инструментов такого типа , чтобы убедиться, что вы действительно понимаете, что происходит в сети, и действительно ли то, что вы видите, объясняется внутренностями протокола, а не другими факторами.

Что все это значит?

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

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

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

Заключение и выводы

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

Резюме

Во-первых, в части 1 мы обсуждали, что HTTP/3 был необходим главным образом из-за нового базового транспортного протокола QUIC . QUIC является духовным преемником TCP и объединяет все его передовые методы, а также TLS 1.3. Это было необходимо главным образом потому, что TCP из-за его повсеместного развертывания и интеграции в промежуточные устройства стал слишком негибким для развития. Использование QUIC UDP и почти полное шифрование означает, что нам (надеюсь) нужно будет только обновить конечные точки в будущем, чтобы добавить новые функции, что должно быть проще. Однако QUIC также добавляет некоторые интересные новые возможности. Во-первых, комбинированное транспортное и криптографическое рукопожатие QUIC быстрее, чем TCP + TLS, и может эффективно использовать функцию 0-RTT. Во-вторых, QUIC знает, что он переносит несколько независимых потоков байтов, и может более разумно обрабатывать потери и задержки, смягчая проблему блокировки заголовка строки. В-третьих, соединения QUIC могут пережить переход пользователей в другую сеть (называемый миграцией соединения) путем пометки каждого пакета идентификатором соединения. Наконец, гибкая структура пакетов QUIC (с использованием фреймов) делает его более эффективным, а также более гибким и расширяемым в будущем. В заключение ясно, что QUIC — это транспортный протокол следующего поколения, который будет использоваться и расширяться в течение многих лет .

Во-вторых, во второй части мы немного критически рассмотрели эти новые функции, особенно их влияние на производительность . Во-первых, мы увидели, что использование UDP в QUIC не делает его волшебным образом быстрее (или медленнее), потому что QUIC использует механизмы контроля перегрузки, очень похожие на TCP, для предотвращения перегрузки сети. Во-вторых, более быстрое рукопожатие и 0-RTT являются в большей степени микрооптимизациями, потому что они на самом деле только на один круговой обмен быстрее, чем оптимизированный стек TCP + TLS, а истинный 0-RTT QUIC дополнительно подвержен ряду проблем безопасности, которые могут ограничить его полезность. В-третьих, миграция соединения действительно необходима только в нескольких конкретных случаях, и она по-прежнему означает сброс скорости отправки, поскольку система управления перегрузкой не знает, сколько данных может обработать новая сеть. В-четвертых, эффективность устранения блокировки очереди в QUIC сильно зависит от того, как потоковые данные мультиплексируются и распределяются по приоритетам. Подходы, оптимальные для восстановления после потери пакетов, кажутся вредными для общих случаев использования производительности загрузки веб-страниц и наоборот, хотя необходимы дополнительные исследования. В-пятых, QUIC может запросто отправлять пакеты медленнее, чем TCP + TLS, потому что API-интерфейсы UDP менее развиты, а QUIC шифрует каждый пакет по отдельности, хотя со временем это можно в значительной степени смягчить. В-шестых, HTTP/3 сам по себе на самом деле не приносит каких-либо важных новых функций производительности, а в основном перерабатывает и упрощает внутренности известных функций HTTP/2. Наконец, некоторые из самых интересных функций, связанных с производительностью, которые поддерживает QUIC (многопутевость, ненадежные данные, WebTransport, прямое исправление ошибок и т. д.), не являются частью основных стандартов QUIC и HTTP/3, а скорее являются предлагаемыми расширениями, которые еще некоторое время, чтобы быть доступным. В заключение, это означает, что QUIC, вероятно, не сильно улучшит производительность для пользователей в высокоскоростных сетях, но в основном будет важен для тех, кто работает в медленных и менее стабильных сетях .

Наконец, в этой части 3 мы рассмотрели, как на практике использовать и развертывать QUIC и HTTP/3 . Во-первых, мы увидели, что большинство лучших практик и уроков, извлеченных из HTTP/2, должны быть просто перенесены в HTTP/3. Нет необходимости менять стратегию объединения или встраивания, а также консолидировать или сегментировать ферму серверов. Серверная загрузка по-прежнему не лучшая функция для использования, и preload загрузка также может быть мощным оружием. Во-вторых, мы обсудили, что может пройти некоторое время, прежде чем готовые пакеты веб-серверов обеспечат полную поддержку HTTP/3 (частично из-за проблем с поддержкой библиотеки TLS), хотя для первых пользователей доступно множество вариантов с открытым исходным кодом и несколько крупных CDN имеют зрелое предложение. В-третьих, очевидно, что большинство основных браузеров имеют (базовую) поддержку HTTP/3, даже включенную по умолчанию. Однако существуют большие различия в том, как и когда они практически используют HTTP/3 и его новые функции, поэтому понять их поведение может быть непросто. В-четвертых, мы обсуждали, что это усугубляется отсутствием явной поддержки HTTP/3 в популярных инструментах, таких как Lighthouse и WebPageTest, что особенно затрудняет сравнение производительности HTTP/3 с HTTP/2 и HTTP/1.1 в настоящее время. В заключение, HTTP/3 и QUIC, вероятно, еще не совсем готовы к прайм-тайму, но скоро будут .

Рекомендации

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

Во-первых, как обсуждалось в конце части 2, даже если ваш «средний» пользователь может не получить значительного прироста производительности (в зависимости от вашего целевого рынка), значительная часть вашей аудитории , скорее всего, увидит впечатляющие улучшения . 0-RTT может сэкономить только одну поездку туда и обратно, но для некоторых пользователей это может означать несколько сотен миллисекунд. Миграция соединения может не поддерживать стабильно быструю загрузку, но она определенно поможет людям, пытающимся получить этот PDF-файл на скоростном поезде. Потеря пакетов в кабеле может быть скачкообразной, но беспроводные соединения могут получить больше пользы от устранения блокировки очереди в QUIC. Более того, эти пользователи обычно сталкиваются с худшей производительностью вашего продукта и, следовательно, больше всего страдают от него. Если вам интересно, почему это так важно, прочитайте знаменитый анекдот Криса Захариаса о веб-перформансе.

Во-вторых, QUIC и HTTP/3 со временем будут становиться только лучше и быстрее . Версия 1 была сосредоточена на выполнении базового протокола, оставив более продвинутые функции производительности на потом. Таким образом, я считаю, что стоит начать инвестировать в протоколы сейчас, чтобы убедиться, что вы можете использовать их и новые функции с оптимальным эффектом, когда они станут доступны в будущем. Учитывая сложность протоколов и аспекты их развертывания, было бы неплохо уделить время знакомству с их особенностями. Даже если вы пока не хотите пачкать руки, несколько крупных провайдеров CDN предлагают зрелую поддержку HTTP/3 «щелкните переключателем» (в частности, Cloudflare и Fastly). Я изо всех сил пытаюсь найти причину, чтобы не попробовать это, если вы используете CDN (что, если вы заботитесь о производительности, вам действительно нужно).

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

Дальнейшее чтение

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

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

• «Объяснение HTTP/3», Дэниел Стенберг
  Эта электронная книга, написанная создателем cURL, обобщает протокол.
• «HTTP/2 в действии», Барри Поллард
  Эта превосходная всесторонняя книга по HTTP/2 содержит многоразовые советы и раздел, посвященный HTTP/3.
• @programmingart, Твиттер
  Мои твиты в основном посвящены QUIC, HTTP/3 и веб-производительности (включая новости) в целом. См., например, мои недавние обсуждения функций QUIC.
• «Ютуб», Робин Маркс
  Мои более 10 подробных докладов охватывают различные аспекты протоколов.
• «Блог Cloudlare»
  Это основной продукт компании, которая параллельно использует CDN.
• «Быстрый блог»
  В этом блоге есть отличные обсуждения технических аспектов, встроенные в более широкий контекст.
• QUIC, собственно RFC
  Вы найдете ссылки на документы IETF QUIC и HTTP/3 RFC и другие официальные расширения.
• Блог инженеров IIJ: отличные подробные технические объяснения деталей функций QUIC.
• Научные статьи по HTTP/3 и QUIC, Робин Маркс
  Мои исследовательские работы охватывают мультиплексирование потоков и расстановку приоритетов, инструменты и различия в реализации.
• QUIPS, EPIQ 2018 и EPIQ 2020
  Эти документы академических семинаров содержат подробные исследования безопасности, производительности и расширений протоколов.

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