Чтение онлайн

Впрочем, важна не прямая линия на логарифмической шкале сама по себе, а то, как эти распределения влияют на проектирование и использование сетей. Многие виды контента подчиняются закону Ципфа или другим степенным законам, поэтому принципиально важно, что популярность веб-узлов интернета также описывается этими распределениями. Это означает, что понятие среднего сайта бесполезно. Сайты лучше делить на популярные и непопулярные; и те и другие важны. Популярные сайты, очевидно, являются значимым фактором, поскольку всего несколько таких сайтов генерируют огромную долю интернет-трафика. Возможно, это покажется удивительным, но непопулярные сайты тоже имеют значение. Их очень много, поэтому они вносят существенный вклад в общий трафик. Идея о том, что множество непопулярных решений вместе могут сыграть большую роль, изложена в книге «Длинный хвост» («The Long Tail») Криса Андерсона (Anderson, 2008a).

Чтобы эффективно работать в этом асимметричном мире, мы должны уметь строить оба вида веб-сайтов. Непопулярные сайты легки в управлении. С использованием DNS несколько различных сайтов могут фактически указывать на один и тот же компьютер в интернете, который ими управляет. С другой стороны, популярные сайты трудно поддерживать. С этим вряд ли справится один компьютер, каким бы мощным он ни был; кроме того, использование одного компьютера приведет к тому, что в случае его поломки (а это обязательно произойдет) сайт окажется недоступным для миллионов пользователей. Чтобы управлять этими сайтами, нужно построить системы распределения контента. Позже мы к этому перейдем.

7.5.2. Серверные фермы и веб-прокси

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

Мы опишем все эти методы по очереди. Однако заметим, что они не подходят для построения крупнейших популярных веб-сайтов. В этом случае нужны методы распределения контента, в которых задействованы компьютеры, расположенные в самых разных местах; эти методы мы обсудим в следующих разделах.

Серверные фермы

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

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

Илл. 7.43. Серверная ферма

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

Пожалуй, наиболее распространенное решение сводится к распределению запросов по серверам фермы 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), так как его цель сводится к равномерному распределению рабочей нагрузки между серверами. Политика балансировки бывает простая и сложная. В первом случае серверы используются один за другим по очереди или по кругу циклически. При этом интерфейс должен помнить соответствие каждого запроса, чтобы последующие пакеты одного запроса были отправлены к конкретному серверу. Кроме того, чтобы сделать сайт надежнее, чем один сервер, интерфейс должен фиксировать отказы серверов и прекращать отсылать им запросы.

Веб-прокси

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