Оптимизируем сетевой трафик

Сшивание OCSP и снижение рисков от отзыва SSL-сертификата

Включив сшивание OCSP на своем сервере, вы можете ускорить TLS-хэндшейки. Протокол OCSP (The Online Certificate Status Protocol) был создан как альтернатива протоколу CRL. Оба протокола используются для проверки валидности SSL-сертификата, но OCSP не требует загрузки информации о сертификате

В своей статье «The Performance Cost of EV Certificates» Саймон Херн (Simon Hearne) рассказывает о том, как выбор сертификата влияет на производительность. Существует несколько типов проверки сертификатов:
  • Domain Validation (DV) удостоверяет, что запрашивающий сертификат владеет доменом.
  • Валидация организации (OV) подтверждает, что организация владеет доменом.
  • Расширенная валидация (EV) подтверждает, что организация владеет доменом, со строгой валидацией.
Все эти сертификаты одинаковы с точки зрения технологии, но отличаются информацией и свойствами, указанными в этих сертификатах.
Сертификаты EV — дорогие и трудоемкие. Такие сертификаты требуют проверки реальными людьми. Сертификаты DV часто предоставляются бесплатно. Например, с помощью программы Let’s Encrypt, которая хорошо интегрирована во многие хостинг-провайдеры и CDN. На момент написания статьи, она используется более 225 миллионами сайтов (PDF).
К сожалению, EV-сертификаты не полностью поддерживают OCSP-сшивание. При плохом соединении это может привести к заметным затратам на производительность (1000 мс+).

Сертификаты EV — не лучший выбор для повышения производительности. Они могут оказать гораздо большее влияние на производительность, чем сертификаты DV. Для оптимальной производительности всегда используйте сертификат DV с привязкой к OCSP. Они намного дешевле, чем EV-сертификаты, и их не так сложно приобрести. (пока доступен CRLite).

Сжатие имеет значение: 40–43% цепочек несжатых сертификатов слишком велики, чтобы уместиться в одинQUIC из 3 UDP-датаграм. (Источник) (Увеличить)
Примечание. Для QUIC/HTTP/3 цепочка сертификатов TLS — это единственный контент переменного размера, который определяет количество байт в QUIC Handshake. Размер варьируется от нескольких сотен байтов до более 10 КБ.
Держать TLS-сертификаты маленькими важно для QUIC/HTTP/3, так как большие размеры сертификатов могут вызвать многократные хэндшейки. Кроме того, необходимо убедиться, что сертификаты сжаты. В противном случае цепочки сертификатов будут слишком большими, чтобы уместиться в одной проверке QUIC.

Подробности вы можете найти в этих статьях:

Используйте IPv6

Поскольку IPv4 адреса уже заканчиваются, многие мобильные сети спешно переходят на IPv6 (в США почти 50%) Виталий Фридман рекомендует обновить DNS до IPv6, чтобы обеспечить надежность в будущем. Убедитесь, что в сети поддерживается двойной стек. Это позволяет использовать IPv6 и IPv4 одновременно. IPv6 не имеет обратной совместимости с IPv4. Кроме того, исследования показывают, что сайты на IPv6 работают на 10−15% быстрее за счет NDP и оптимизации роутинга.

Убедитесь, что все ресурсы раздаются HTTP/2 (или HTTP/3)

Последние несколько лет Google продвигает идею более безопасного веб с HTTPS. Поэтому переход на HTTP/2 — отличная инвестиция. Согласно WEB Almanach, 64% всех запросов уже используют HTTP/2.

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

Стоит помнить, что HTTP/2 Server Push удаляется из Chrome. Можно посмотреть на Early Hints, которые уже экспериментально поддерживаются Fastly.
Если вы все еще используете HTTP, сначала вам нужно перети на HTTPS, а затем подстроить вашу сборку для поддержки мультиплексирования и распараллеливания HTTP/2. Перенос на HTTP/2 сайта Gov.uk — фантастический пример того, как все это проделать, при этом добавив CORS, SRI и WPT.

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

Согласно Web Almanac, в конце 64% всех запросов обслуживались через HTTP/2. То есть всего через 4 года после его формальной стандартизации. (Источник: Web Almanac) (Увеличить)

Внедрение HTTP/2

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

Возможно, вам вообще не нужно объединять все ассеты. Вместо этого вы можете разбивать весь интерфейс на множество небольших модулей, сжимая их в процессе сборки и загружая параллельно. При этом изменение одного файла не требует повторной загрузки всех стилей или JavaScript. Это также уменьшает время парсинга и полезную нагрузку отдельных страниц.
Однако упаковка все еще имеет смысл. При использовании большого количества небольших скриптов общее сжатие пострадает, а стоимость извлечения объектов из кеша возрастет. Браузеры еще не оптимизированы для поддержки очень большого числа параллельных загрузок. Например, Chrome будет запускать межпроцессные взаимодействия (IPC), линейно зависящие от количества ресурсов.

Чтобы добиться наилучших результатов с HTTP/2, подумайте о постепенной загрузке CSS, по примеру Джейка Арчибальда из Chrome.
Встроенный CSS больше не блокирует рендеринг для Chrome. Но есть некоторые проблемы с приоритезацией. Здесь всё не так просто, но стоит поэкспериментировать. Например, можно обойтись без HTTP/2 connection coalescing и использовать шардинг доменов при одновременном использовании HTTP/2.

Кроме того, есть проблема HTTP/2 и целостность ресурсов. Как ее решить? Если вы используете HTTP/2, компромиссным решением будет отправка 6−10 пакетов (хорошее решение и для старых браузеров). Экспериментируйте и измеряйте, чтобы найти правильный баланс для вашего приложения.

Полезные советы по работе с протоколом HTTP/2

Одно из главных преимуществ HTTP/2 — мультипрексирование соединения. Но, если что-то настроено не так, браузер откроет новое соединение. Например, если есть проблема с CORS или неправильно настроен атрибут crossorigin. Чтобы проверить, все ли запросы используют одно соединение HTTP/2, включите столбец «Connection ID» в DevTools → Network.
Все запросы используют одно и то же соединение HTTP / 2 (286), за исключением manifest. json, который открывает отдельное соединение (451). (Источник: iamakulov). (Увеличить).
Теперь разберёмся с серверами и CDN. Разные серверы и CDN поддерживают HTTP/2 по-разному. Используйте сравнение CDN, чтобы проверить свои настройки или посмотреть, как работают ваши серверы и какие функции, скорее всего, будут поддерживаться.

Виталий Фридман рекомендует ознакомиться с исследованием Пэта Минана (Pat Meenan) о приоритетах HTTP/2 (видео) и о поддержке тестового сервера для определения приоритетов HTTP/2. Пэт рекомендует включить BBR congestion control и установить tcp_notsent_lowat в значение 16 КБ для приоритизации HTTP/2, чтобы обеспечить надежную работу с ядрами Linux 4.9 и более поздних версий. Энди Дэвис провел аналогичное исследование приоритезации HTTP/2 в браузерах, CDN и службах облачного хостинга.

Дважды проверьте, поддерживает ли ваше ядро TCP BBR и включите его, если это возможно. В настоящее время эта технология используется на Google Cloud Platform, Amazon Cloudfront, Linux (например, Ubuntu).

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

И не забывайте про безопасность! Все реализации HTTP/2 в браузере работают через TLS. Убедитесь в правильности настройки заголовков безопасности, устраните известные уязвимости и проверьте настройку HTTPS.

Также убедитесь, что все внешние плагины и внешние скрипты загружаются через HTTPS, что нет угрозы XSS и что заголовки HTTP Strict Transport Security и Content Security Policy установлены правильно.

Поддерживают ли ваши серверы и CDN HTTP/3?

HTTP/2 принес много полезного. Но здесь всё ещё есть, что улучшить — особенно head-of-line blocking in TCP, которая становится проблемой в медленных сетях. HTTP/3 решает и эти проблемы (видео).

Для решения проблем HTTP/2, IETF, вместе с Google, Akamai и другими, работает над новым протоколом, который недавно был стандартизован как HTTP/3.

Робин Маркс (Robin Marx) очень хорошо объяснил суть HTTP/3. С точки зрения возможностей HTTP/3 очень похож на HTTP/2, но под капотом он работает совсем по-другому. В HTTP/3 хэндшейки быстрее, шифрование и стриминг надёжнее и лучше. HTTP/3 использует в качестве транспорта QUIC, которые являются легковесной оберткой вокруг UDP датаграмм.

QUIC полностью интегрирует TLS 1.3 в протокол, в то время как для TCP он является отдельным слоем. По сравнению с обычным TCP-стеком, QUIC использует меньше запросов. Для обычного стека TCP и TLS используют разные хендшейки, в QUIC можно объединить TLS и TCP хендшейки и выполнить меньше запросов. С TLS 1.3 можно делать еще меньше запросов, используя 0-RTT.

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

Сильно ли переход на HTTP/3 влияет на производительность? Вероятно, да. Особенно для мобильных устройств. HTTP/2 умеет мультиплексировать соединение, также как и HTTP/3. Но вдобавок к этому HTTP/3 изолирует отдельные стримы, поэтому потеря пакетов влияет только на один стрим, а не на все сразу.

HTTP/3 всё ещё находится в стадии разработки. У Chrome, Firefox и Safari уже есть реализации. Некоторые CDN уже поддерживают QUIC и HTTP/3. В конце 2020 года Chrome начал развертывание HTTP/3 и IETF QUIC. Фактически все сервисы Google (Google Analytics, YouTube и т. д.) уже работают через HTTP/3. Веб-сервер LiteSpeed поддерживает HTTP/3. Ни Apache, ни nginx, ни IIS еще не поддерживают его, но, скорее всего, ситуация будет быстро меняться.

Итого: использовать HTTP/3 на сервере и в CDN — отличная идея. Эта область еще недостаточно исследована, но первые результаты многообещающие.

Если вы хотите подробнее ознакомиться с особенностями и преимуществами HTTP/3 протокола, Виталий Фридман советует обратиться к следующим источникам: