Пожалуй, наиболее распространенное решение сводится к распределению запросов по серверам фермы c помощью DNS. Когда выполняется DNS-запрос для получения URL-адреса домена, возвращаемый DNS-сервером ответ перенаправляет клиента к CDN-сервису (обычно используя NS-запись со ссылкой на авторитетный для этого домена сервер имен). CDN-сервис стремится вернуть клиенту IP-адрес ближайшей к клиенту реплики сервера. Если в качестве ответа возвращается несколько IP-адресов, обычно клиент пытается подключиться к первому из них. Таким образом, как и задумывалось, для посещения одного и того же сайта разные клиенты связываются с разными серверами, которые должны располагаться поблизости от них. Этот процесс иногда называют сопоставлением клиентов (client mapping). Обратите внимание, что он опирается на сведения авторитетного сервера имен о топологическом или географическом положении клиента. Мы подробно обсудим сопоставление клиентов с использованием DNS после того, как рассмотрим сети доставки контента.

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

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

Простая схема интерфейсной части — передавать все входящие запросы всем серверам. Каждый сервер отвечает только на часть запросов по предварительному соглашению. Допустим, 16 серверов проверяют IP-адрес источника и отвечают на запрос, только если последние 4 бита IP-адреса совпадают с их настроенными селекторами. Остальные пакеты отбрасываются. Хотя это и расточительно с точки зрения входящей пропускной способности, но поскольку ответы зачастую намного длиннее запросов, этот подход эффективнее, чем кажется.

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

Веб-прокси

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

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

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

Чтобы обеспечить пользователям общий доступ к кэшу, используется веб-прокси (Web proxy). Прокси — это агент, который действует от чужого имени, например другого пользователя. Есть много видов прокси. Например, ARP-прокси отвечает на ARP-запросы от имени пользователя, который находится где-то в другом месте (и не может ответить сам). Веб-прокси выполняет веб-запросы от имени его пользователей. Обычно он кэширует веб-ответы, и так как он находится в совместном доступе, его кэш значительно больше, чем у браузера.

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

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

Илл. 7.44. Прокси-кэш между веб-браузерами и веб-серверами

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

Чтобы обеспечить дополнительные уровни кэширования, могут быть добавлены следующие прокси. Каждый прокси (или браузер) делает запрос к своему вышестоящему прокси (upstream proxy). Каждый вышестоящий прокси производит кэширование для нижестоящих прокси (downstream proxy) или браузеров. В результате может получиться,