Сети доставки контента (CDN)

Повысьте производительность, используя сеть доставки контента.

Кэти Хемпениус

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

Обзор

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

На высоком уровне преимущества производительности CDN обусловлены несколькими принципами: серверы CDN расположены ближе к пользователям, чем исходные серверы , и поэтому имеют более короткую задержку туда и обратно (RTT) ; сетевая оптимизация позволяет CDN доставлять контент быстрее, чем если бы контент был загружен «напрямую» с исходного сервера; наконец, кэши CDN устраняют необходимость отправки запроса на исходный сервер.

Доставка ресурсов

Хотя это может показаться неинтуитивным, использование CDN для доставки ресурсов (даже некэшируемых) обычно происходит быстрее, чем загрузка пользователем ресурса «напрямую» с ваших серверов.

Когда CDN используется для доставки ресурсов из источника, между клиентом и ближайшим сервером CDN устанавливается новое соединение. Оставшаяся часть пути (другими словами, передача данных между сервером CDN и источником) происходит через сеть CDN, которая часто включает в себя существующие постоянные соединения с источником. Преимущества этого двояки: завершение нового соединения как можно ближе к пользователю устраняет ненужные затраты на установку соединения (установление нового соединения является дорогостоящим и требует нескольких циклов); использование предварительно прогретого соединения позволяет немедленно передавать данные с максимально возможной пропускной способностью.

Некоторые CDN еще больше улучшают эту ситуацию, направляя трафик к источнику через несколько серверов CDN, разбросанных по Интернету. Соединения между серверами CDN происходят по надежным и высокооптимизированным маршрутам, а не по маршрутам, определяемым протоколом пограничного шлюза (BGP) . Хотя BGP является фактическим протоколом маршрутизации в Интернете, его решения по маршрутизации не всегда ориентированы на производительность. Таким образом, маршруты, определенные BGP, вероятно, будут менее производительными, чем точно настроенные маршруты между серверами CDN.

Кэширование

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

Добавление ресурсов в кэш

Наиболее часто используемый метод заполнения кешей CDN заключается в том, чтобы CDN «извлекала» ресурсы по мере необходимости — это известно как «извлечение из источника». При первом запросе определенного ресурса из кеша CDN запросит его у исходного сервера и кэширует ответ. Таким образом, содержимое кэша накапливается с течением времени по мере запроса дополнительных некэшированных ресурсов.

Удаление ресурсов из кэша

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

• Удаление кэша

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

• Очистка

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

  Если CDN поддерживает почти мгновенную очистку, очистку можно использовать как механизм управления кэшированием динамического контента: кэшируйте динамический контент с длинным сроком жизни, а затем очищайте ресурс при каждом его обновлении. Таким образом можно максимизировать продолжительность кэширования динамического ресурса, несмотря на то, что заранее неизвестно, когда ресурс изменится. Этот метод иногда называют «кэшированием с сохранением до сообщения».

  Когда очистка используется в большом масштабе, она обычно используется в сочетании с концепцией, известной как «теги кэша» или «суррогатные ключи кэша». Этот механизм позволяет владельцам сайтов связать один или несколько дополнительных идентификаторов (иногда называемых «тегами») с кэшированным ресурсом. Эти теги затем можно использовать для выполнения высокоточной очистки. Например, вы можете добавить тег «нижний колонтитул» ко всем ресурсам (например, /about , /blog ), содержащим нижний колонтитул вашего сайта. Когда нижний колонтитул будет обновлен, попросите вашу CDN очистить все ресурсы, связанные с тегом «нижний колонтитул».

Кэшируемые ресурсы

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

Частные и государственные ресурсы

• Частные ресурсы

  Частные ресурсы содержат данные, предназначенные для одного пользователя, и поэтому не должны кэшироваться CDN. Частные ресурсы обозначаются заголовком Cache-Control: private .

• Общественные ресурсы

  Публичные ресурсы не содержат информации, специфичной для пользователя, и поэтому кэшируются с помощью CDN. Ресурс может считаться кэшируемым CDN, если он не имеет заголовка Cache-Control: no-store или Cache-Control: private . Продолжительность времени, в течение которого общедоступный ресурс может быть кэширован, зависит от того, как часто изменяется ресурс.

Динамический и статический контент

• Динамический контент

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

• Статический контент

  Статический контент меняется редко, если вообще когда-либо меняется. Изображения, видео и библиотеки с версиями обычно являются примерами этого типа контента. Поскольку статический контент не меняется, его следует кэшировать с длительным сроком жизни (TTL) — например, 6 месяцев или 1 год.

Выбор CDN

Производительность обычно является главным фактором при выборе CDN. Однако при выборе CDN важно учитывать другие функции, которые предлагает CDN (например, функции безопасности и аналитики), а также цены, поддержку и подключение CDN.

Производительность

На высоком уровне стратегию производительности CDN можно рассматривать как компромисс между минимизацией задержки и максимизацией коэффициента попадания в кэш. CDN со многими точками присутствия (PoP) могут обеспечить меньшую задержку, но могут иметь более низкие коэффициенты попадания в кэш в результате разделения трафика на большее количество кэшей. И наоборот, CDN с меньшим количеством PoP могут быть расположены географически дальше от пользователей, но могут обеспечить более высокий коэффициент попадания в кэш.

В результате этого компромисса некоторые CDN используют многоуровневый подход к кэшированию: точки PoP, расположенные рядом с пользователями (также известные как «пограничные кэши»), дополняются центральными точками PoP, которые имеют более высокий коэффициент попадания в кеш. Когда пограничный кэш не может найти ресурс, он обращается за ресурсом к центральному PoP. Этот подход позволяет немного увеличить задержку в обмен на более высокую вероятность того, что ресурс может быть обслужен из кеша CDN, хотя и не обязательно из пограничного кеша.

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

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

Влияние на наибольшую содержательную отрисовку (LCP)

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

Хотя TTFB не является показателем производительности, ориентированным на пользователя , он является важным показателем для диагностики проблем с Largest Contentful Paint (LCP) , который является показателем, ориентированным на пользователя.

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

Дополнительные возможности

CDN обычно предлагают широкий спектр функций в дополнение к основному предложению CDN. Обычно предлагаемые функции включают в себя: балансировку нагрузки, оптимизацию изображений, потоковое видео, периферийные вычисления и продукты безопасности.

Как настроить CDN

В идеале вам следует использовать CDN для обслуживания всего вашего сайта. На высоком уровне процесс настройки для этого состоит из регистрации у провайдера CDN, а затем обновления DNS-записи CNAME, чтобы она указывала на провайдера CDN. Например, запись CNAME для www.example.com может указывать на example.my-cdn.com . В результате этого изменения DNS трафик на ваш сайт будет направляться через CDN.

Если использование CDN для обслуживания всех ресурсов невозможно, вы можете настроить CDN для обслуживания только подмножества ресурсов, например только статических ресурсов. Это можно сделать, создав отдельную запись CNAME, которая будет использоваться только для ресурсов, которые должны обслуживаться CDN. Например, вы можете создать запись CNAME static.example.com , которая указывает на example.my-cdn.com . Вам также потребуется переписать URL-адреса ресурсов, обслуживаемых CDN, чтобы они указывали на созданный вами поддомен static.example.com .

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

Улучшение коэффициента попадания в кеш

Эффективная настройка CDN будет обслуживать как можно больше ресурсов из кеша. Обычно это измеряется коэффициентом попадания в кэш (CHR). Коэффициент попадания в кэш определяется как количество попаданий в кэш, разделенное на общее количество запросов за определенный интервал времени.

Только что инициализированный кэш будет иметь CHR, равный 0, но он увеличивается по мере заполнения кэша ресурсами. CHR на уровне 90 % — хорошая цель для большинства сайтов. Ваш провайдер CDN должен предоставить вам аналитику и отчеты о вашем CHR.

При оптимизации CHR первое, что необходимо проверить, — это то, что все кэшируемые ресурсы кэшируются и кэшируются в течение правильного периода времени. Это простая оценка, которую следует провести на всех объектах.

В общих чертах, следующий уровень оптимизации CHR — это точная настройка параметров CDN, чтобы гарантировать, что логически эквивалентные ответы сервера не кэшируются отдельно. Это распространенная неэффективность, возникающая из-за влияния на кеширование таких факторов, как параметры запроса, файлы cookie и заголовки запросов.

Первоначальный аудит

Большинство CDN предоставляют аналитику кэша. Кроме того, такие инструменты, как WebPageTest и Lighthouse, также можно использовать для быстрой проверки того, что все статические ресурсы страницы кэшируются в течение правильного периода времени. Это достигается путем проверки заголовков HTTP-кэша каждого ресурса. Кэширование ресурса с использованием максимально подходящего времени жизни (TTL) позволит избежать ненужной выборки источника в будущем и, следовательно, увеличит CHR.

Как минимум, один из этих заголовков обычно необходимо установить, чтобы ресурс мог кэшироваться CDN:

• Cache-Control: max-age=
• Cache-Control: s-maxage=
• Expires

Кроме того, хотя это не влияет на то, кэшируется ли ресурс CDN и каким образом, рекомендуется также установить директиву Cache-Control: immutable . Cache-Control: immutable указывает, что ресурс «не будет обновляться в течение срока его актуальности». В результате браузер не будет повторно проверять ресурс при его обслуживании из кеша браузера, тем самым исключая ненужный запрос к серверу. К сожалению, эта директива поддерживается только Firefox и Safari и не поддерживается браузерами на базе Chromium. Эта проблема отслеживает поддержку Chromium для Cache-Control: immutable . Если вы пометите эту проблему как пометку, это поможет стимулировать поддержку этой функции.

Более подробное объяснение HTTP-кэширования см. в разделе Предотвращение ненужных сетевых запросов с помощью HTTP-кэша .

Тонкая настройка

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

Параметры запроса

По умолчанию CDN учитывают параметры запроса при кэшировании ресурса. Однако небольшие изменения в обработке параметров запроса могут оказать существенное влияние на CHR. Например:

• Ненужные параметры запроса

  По умолчанию CDN кэширует example.com/blog и example.com/blog?referral_id=2zjk отдельно, даже если они, скорее всего, являются одним и тем же базовым ресурсом. Это исправляется путем настройки конфигурации CDN для игнорирования параметра запроса referral\_id .

• Порядок параметров запроса

  CDN будет кэшировать example.com/blog?id=123&query=dogs отдельно от example.com/blog?query=dogs&id=123 . Для большинства сайтов порядок параметров запроса не имеет значения, поэтому настройка CDN для сортировки параметров запроса (тем самым нормализуя URL-адрес, используемый для кэширования ответа сервера) увеличит CHR.

Отличаться

Заголовок ответа Vary сообщает кэшам, что ответ сервера, соответствующий конкретному URL-адресу, может варьироваться в зависимости от заголовков, установленных для запроса (например, заголовков запроса Accept-Language или Accept-Encoding ). В результате он дает указание CDN кэшировать эти ответы отдельно. Заголовок Vary не поддерживается широко CDN и может привести к тому, что кэшируемый в противном случае ресурс не будет обслуживаться из кэша.

Хотя заголовок Vary может быть полезным инструментом, его неправильное использование вредит CHR. Кроме того, если вы используете Vary , нормализация заголовков запросов поможет улучшить CHR. Например, без нормализации заголовки запроса Accept-Language: en-US и Accept-Language: en-US,en;q=0.9 приведут к созданию двух отдельных записей кэша, хотя их содержимое, скорее всего, будет идентичным.

Печенье

Файлы cookie устанавливаются по запросам через заголовок Cookie ; они устанавливаются в ответах через заголовок Set-Cookie . Следует избегать ненужного использования заголовка Set-Cookie , поскольку кэши обычно не кэшируют ответы сервера, содержащие этот заголовок.

Характеристики производительности

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

Сжатие

Все текстовые ответы следует сжимать с помощью gzip или Brotli. Если у вас есть выбор, выберите Brotli вместо gzip. Brotli — это новый алгоритм сжатия, который по сравнению с gzip обеспечивает более высокую степень сжатия.

Существует два типа поддержки CDN для сжатия Brotli: «Brotli из источника» и «автоматическое сжатие Brotli».

Бротли из происхождения

Brotli from origin — это когда CDN обслуживает ресурсы, которые были сжаты Brotli источником. Хотя это может показаться функцией, которую все CDN должны поддерживать «из коробки», для этого требуется, чтобы CDN могла кэшировать несколько версий (другими словами, версии, сжатые gzip и Brotli) ресурса, соответствующего заданный URL.

Автоматическое сжатие Бротли

Автоматическое сжатие Brotli — это когда ресурсы сжимаются Brotli с помощью CDN. CDN могут сжимать как кэшируемые, так и некэшируемые ресурсы.

При первом запросе ресурса он обслуживается с использованием «достаточно хорошего» сжатия, например Brotli-5. Этот тип сжатия применим как к кэшируемым, так и к некэшируемым ресурсам.

Между тем, если ресурс кэшируется, CDN будет использовать автономную обработку для сжатия ресурса на более мощном, но гораздо более медленном уровне сжатия — например, Brotli-11. После завершения сжатия более сжатая версия будет кэширована и использована для последующих запросов.

Рекомендации по сжатию

Сайты, которые хотят максимизировать производительность, должны применять сжатие Brotli как на исходном сервере, так и на CDN. Сжатие Brotli в источнике минимизирует размер передаваемых ресурсов, которые не могут быть обслужены из кэша. Чтобы предотвратить задержки в обслуживании запросов, источник должен сжимать динамические ресурсы, используя достаточно консервативный уровень сжатия — например, Brotli-4; статические ресурсы можно сжать с помощью Brotli-11. Если источник не поддерживает Brotli, для сжатия динамических ресурсов можно использовать gzip-6; gzip-9 можно использовать для сжатия статических ресурсов.

ТЛС 1.3

TLS 1.3 — это новейшая версия Transport Layer Security (TLS) , криптографического протокола, используемого HTTPS . TLS 1.3 обеспечивает лучшую конфиденциальность и производительность по сравнению с TLS 1.2.

TLS 1.3 сокращает время подтверждения TLS с двух циклов до одного. Для соединений, использующих HTTP/1 или HTTP/2, сокращение времени подтверждения TLS до одного приема и обратно эффективно сокращает время установки соединения на 33%.

HTTP/2 и HTTP/3

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

HTTP/2

Если ваша CDN еще не включила HTTP/2 по умолчанию, вам следует рассмотреть возможность его включения. HTTP/2 обеспечивает множество преимуществ в производительности по сравнению с HTTP/1 и поддерживается всеми основными браузерами. Возможности производительности HTTP/2 включают в себя: мультиплексирование , приоритезацию потоков и сжатие заголовков .

• Мультиплексирование

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

• Приоритизация потока

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

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

Реализации CDN приоритезации ресурсов HTTP/2 сильно различаются. Чтобы определить, полностью ли и правильно ли ваш CDN поддерживает приоритезацию ресурсов HTTP/2, ознакомьтесь со статьей «Быстр ли HTTP/2?» .

Хотя переключение вашего экземпляра CDN на HTTP/2 — это во многом вопрос переключения переключателя, важно тщательно протестировать это изменение, прежде чем включать его в производство. HTTP/1 и HTTP/2 используют одни и те же соглашения для заголовков запросов и ответов, но HTTP/2 гораздо менее снисходителен, когда эти соглашения не соблюдаются. В результате неспециализированные методы, такие как включение символов, отличных от ASCII, или символов верхнего регистра в заголовки, могут начать вызывать ошибки после включения HTTP/2. В этом случае попытки браузера загрузить ресурс завершатся неудачей. Неудачная попытка загрузки будет видна на вкладке «Сеть» в DevTools. Кроме того, в консоли отобразится сообщение об ошибке «ERR_HTTP2_PROTOCOL_ERROR».

HTTP/3

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

• Устранение блокировки начала строки

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

• Сокращено время установки соединения

  HTTP/3 использует TLS 1.3 и, следовательно, разделяет его преимущества в производительности: для установления нового соединения требуется только один двусторонний обмен, а для возобновления существующего соединения не требуется никаких двусторонних обходов.

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

Оптимизация изображения

Службы оптимизации изображений CDN обычно фокусируются на оптимизации изображений, которая может применяться автоматически, чтобы уменьшить размер передаваемого изображения. Например: удаление данных EXIF , применение сжатия без потерь и преобразование изображений в новые форматы файлов (например, WebP). Изображения составляют около 50% передаваемых байтов на средней веб-странице, поэтому оптимизация изображений может значительно уменьшить размер страницы.

Минимизация

Минификация удаляет ненужные символы из JavaScript, CSS и HTML. Предпочтительно выполнять минификацию на исходном сервере, а не на CDN. Владельцы сайтов имеют больше информации о коде, подлежащем минимизации, и поэтому часто могут использовать более агрессивные методы минимизации, чем те, которые используются в CDN. Однако если минимизация кода в источнике невозможна, хорошей альтернативой является минимизация с помощью CDN.

Заключение

• Используйте CDN: CDN быстро доставляют ресурсы, снижают нагрузку на исходный сервер и помогают справляться с пиками трафика.
• Кэшируйте контент как можно более агрессивно: как статический, так и динамический контент можно и нужно кэшировать, хотя и на разную продолжительность. Периодически проверяйте свой сайт, чтобы убедиться, что вы оптимально кэшируете контент.
• Включите функции производительности CDN. Такие функции, как Brotli, TLS 1.3, HTTP/2 и HTTP/3, еще больше повышают производительность.