Самые большие CDN включают в себя сотни тысяч серверов, расположенных в разных странах по всему миру. Столь большая емкость CDN часто помогает сайтам в защите от DDoS-атак. Если злоумышленнику удается обеспечить отправку сотен или тысяч запросов в секунду на сайт, использующий CDN, то CDN зачастую способна ответить на все эти запросы. Таким образом, атакованному сайту удается выдержать лавинообразное увеличение числа запросов. То есть CDN позволяет быстро повысить объем передаваемых сайтом данных. Некоторые CDN-провайдеры даже рекламируют свою способность справляться с крупными DDoS-атаками как отдельное преимущество для привлечения клиентов.

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

Заполнение узлов кэша CDN

На илл. 7.45 показан пример пути следования данных в случае их распространения CDN-сетью. Этот путь представляет собой дерево. Исходный сервер в CDN рассылает копию контента по другим узлам в сети, расположенным в Сиднее, Бостоне и Амстердаме (пунктирные линии). Затем клиенты забирают страницы с ближайших узлов CDN (сплошные линии). Таким образом, оба клиента в Сиднее берут копию страницы, расположенную в этом же городе; они не достают страницу с исходного сервера, который, возможно, находится в Европе.

Использование древовидной структуры имеет три преимущества. Во-первых, распространение контента может масштабироваться до любого необходимого числа клиентов при увеличении количества узлов CDN (и уровней дерева, когда распределение среди узлов CDN станет узким местом). Древовидная структура эффективна независимо от количества клиентов. Исходный сервер не перегружен, ведь он взаимодействует с клиентами через дерево узлов CDN; ему не придется самому отвечать на каждый запрос страницы. Во-вторых, каждый клиент получает хорошую производительность за счет доставки страницы с ближайшего, а не отдаленного сервера. Это связано с тем, что соединение устанавливается быстрее, из-за чего медленный старт TCP ускоряется, при этом более короткий сетевой путь с меньшей вероятностью проходит через области перегрузки в интернете. Наконец, общая загруженность сети также сведена к минимуму. Если узлы CDN удачно расположены, то любая страница передается в каждом участке сети только один раз. Это важно, поскольку в конечном счете кто-то платит за полосу пропускания.

Илл. 7.45. Дерево распределения CDN

С ростом применения шифрования в интернете, в частности, использования протокола HTTPS для распространения веб-контента, доставка контента из CDN приобрела более сложный характер. Допустим, вам нужно загрузить главную страницу сайтаDNS-поиск для этого домена выдает ссылку на сервер имен компании Dyn, например ns1.p24.dynect.net, который, в свою очередь, перенаправляет вас на IP-адрес, размещенный в CDN этой компании. Но теперь этот сервер должен доставить вам контент, аутентифицированный New York Times. Для этого он, вероятно, должен располагать закрытыми ключами шифрования для сайта New York Times или сертификатом для сайта nytimes.com (или и тем и другим). Таким образом, CDN придется доверить конфиденциальную информацию провайдера контента, а сервер потребуется настроить так, чтобы он фактически выступал в роли агента сайта nytimes.com. Альтернативный подход состоит в том, чтобы направлять все запросы клиента обратно на исходный сервер, который сможет доставлять сертификаты и контент по протоколу HTTPS, но это сведет на нет практически все преимущества CDN в плане производительности. Решение обычно представляет собой компромисс: CDN генерирует сертификат от имени контент-провайдера и доставляет контент из CDN с помощью этого сертификата, выступая в роли организации. Это позволяет достичь основных целей: шифрования контента, идущего от CDN к пользователю, и его аутентификации для пользователя. Более сложные решения, которые требуют развертывания сертификатов на исходном сервере, также позволяют шифровать трафик между клиентом и узлами кэша. Компания Cloudflare предлагает хороший обзор таких решений на своем сайте по адресу https://cloudflare.com/ssl/.

Переадресация DNS и сопоставление клиентов

Идея использования дерева распределения проста. Гораздо сложнее понять, как сопоставлять клиентов с нужными узлами кэша в этом дереве. Как представляется, эту проблему можно решить с помощью прокси-серверов. Если бы каждый клиент на илл. 7.45 был настроен на использование одного из узлов CDN — в Сиднее, Бостоне или Амстердаме — в качестве кэширующего веб-прокси, распределение было бы древовидным.

Как упоминалось выше, самым распространенным способом сопоставления или направления клиентов к ближайшим узлам кэша CDN является переадресация DNS (DNS redirection). Рассмотрим этот подход более подробно. Предположим, клиент хочет попасть на страницу с URL-адресомЧтобы ее загрузить, браузер использует DNS для получения IP-адреса, соответствующего имени www.cdn.com. Этот DNS-поиск осуществляется как обычно. Используя протокол DNS, браузер узнает IP-адрес сервера имен для домена cdn.com, после чего связывается с сервером имен и просит его разрешить имя www.cdn.com. Но поскольку сервер имен запускается CDN-сетью, вместо выдачи одного IP-адреса на все запросы он выясняет IP-адрес клиента и возвращает ответ в зависимости от его местоположения. Ответом будет IP-адрес ближайшего к клиенту узла CDN. Так, если клиент в Сиднее обращается к серверу имен CDN с запросом IP-адреса www.cdn.com, он получит IP-адрес сиднейского узла CDN, а на тот же запрос от клиента в Амстердаме будет выдан IP-адрес амстердамского узла.

Это вполне допустимая стратегия согласно семантике DNS. Мы уже видели, что серверы имен могут возвращать меняющиеся списки IP-адресов. После анализа имени клиент в Сиднее получает страницу от сиднейского узла CDN. Дальнейшие страницы с того же «сервера» будут также взяты непосредственно от этого узла благодаря кэшированию DNS. Весь процесс показан на илл. 7.46.

Сложный вопрос в этом процессе — что значит ближайший узел CDN и как его найти. Это задача сопоставления клиентов (client mapping), которую мы уже упоминали выше. Здесь нужно принять во внимание минимум два фактора. Первый — сетевое расстояние. Сетевой путь клиента к узлу CDN должен быть коротким и иметь высокую пропускную способность (таким образом, загрузка ускоряется). Чтобы определить сетевое местоположение клиента по его IP-адресу, CDN используют заранее вычисленное соответствие. Расстояние до выбранного узла может не быть кратчайшим — значение имеет комбинация длины сетевого пути и его максимальной емкости.

Илл. 7.46. Направление клиентов к ближайшим узлам CDN с использованием DNS

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

Способность авторитетного DNS-сервера CDN сопоставлять клиента с ближайшим узлом кэша CDN зависит от того, может ли он определить местоположение клиента. Как уже упоминалось в разделе, посвященном DNS, современные расширения протокола DNS (например, механизм клиентской подсети EDNS) позволяют авторитетному серверу имен выяснить IP-адрес клиента. Возможный переход на протокол DoH порождает новые сложности, поскольку IP-адрес локального рекурсивного распознавателя может находиться очень далеко от клиента. Если локальный рекурсивный DNS-распознаватель не передает IP-адрес клиента (что обычно и происходит, поскольку весь смысл состоит в защите его личных данных), то CDN-сетям, не выполняющим DNS-разрешение для своих клиентов, очень сложно осуществить сопоставление. С другой стороны, CDN, также использующие DoH-совместимый распознаватель (например, CloudFlare и Google), могут получить значительные преимущества, так как они смогут напрямую выяснять IP-адреса клиентов, отправивших DNS-запросы. При этом запрашиваемый контент зачастую будет находиться непосредственно в данной CDN. Такая централизация службы DNS может произвести еще одно коренное изменение в распределении контента в течение ближайших нескольких лет.