Компьютерные сети. 6-е изд.

7.5. Доставка контента

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

Задача распространения контента существенно отличается от задачи обеспечения двухточечной связи, предъявляя совершенно другие требования к сети. Например, если Салли хочет поговорить с Джоном, она может позвонить ему на мобильный телефон с помощью IP-телефонии. Нужно установить связь с конкретным устройством — нет смысла звонить на компьютер Пола. Но если Джон хочет посмотреть последний матч своей любимой команды по крикету, он будет рад получить это видео с любого устройства, которое его предоставит. Это может быть компьютер Салли, или Пола, или, что наиболее вероятно, неизвестный сервер в интернете. Таким образом, местоположение контента не имеет значения, кроме тех случаев, когда это затрагивает производительность (и законность).

Еще одно отличие заключается в том, что некоторые веб-узлы, предоставляющие контент, стали чрезвычайно популярными. Яркий пример — YouTube. Он позволяет пользователям делиться своими видео на любую тему, которую только можно вообразить. Многие хотят это сделать, а все остальные хотят его смотреть. Сегодня на потоковое видео приходится более 70 % интернет-трафика, причем подавляющая часть данных доставляется небольшим числом поставщиков контента.

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

Методы распределения контента со временем совершенствовались. На ранних этапах развития Всемирной паутины ее популярность почти ее уничтожила. Растущее число запросов к контенту приводило к тому, что серверы и сети часто были перегружены. Люди начали расшифровывать WWW как World Wide Wait (Всемирное ожидание). Чтобы снизить бесконечные задержки, исследователи разработали ряд архитектур, позволяющих использовать пропускную способность для распределения контента.

Одной из наиболее распространенных архитектур является сеть доставки контента (Content Delivery Network, CDN), иногда ее называют сетью распространения контента (Content Distribution Network). CDN, по сути, представляет собой огромный распределенный набор кэшей, которые доставляют контент клиентам напрямую. Изначально CDN были прерогативой исключительно крупных контент-провайдеров. Провайдер популярного контента мог заплатить CDN (к примеру, Akamai) за распространение этого контента (то есть за предварительное заполнение им кэшей сети). Сегодня собственные CDN развертывают не только крупные поставщики контента (как Netflix или Google), но и многие интернет-провайдеры, предлагающие собственный контент (например, Comcast).

Еще один способ распространения контента сводится к использованию одноранговой сети (Peer-to-Peer P2P), в которой компьютеры доставляют контент друг другу, обычно без специально предусмотренных отдельных серверов или какого-либо центрального пункта управления. Эта идея вдохновляет людей, поскольку много небольших участников, объединившись, способны произвести громадный эффект.

7.5.1. Контент и интернет-трафик

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

Интернет-трафик асимметричен. Многие параметры, с которыми мы имеем дело, сгруппированы вокруг средней величины. Например, рост большинства взрослых людей близок к среднему. Есть некоторое количество высоких и низких людей, и совсем мало очень высоких или очень низких. Аналогично, романы в основном содержат несколько сотен страниц, и очень немногие — 20 или 10 000 страниц. Для таких свойств можно найти диапазон, который не слишком велик, но охватывает большую часть данных.

Интернет-трафик устроен иначе. Как известно, в интернете уже достаточно долго существует несколько сайтов с громадным трафиком (например, Google, YouTube, Facebook) и огромное количество сайтов с гораздо меньшими объемами трафика.

Опыт работы с пунктами видеопроката, библиотеками и другими подобными организациями показывает, что не все фильмы или книги одинаково популярны. Экспериментально доказано, что если в пункте проката есть N фильмов, то доля заявок на конкретный фильм, стоящий на k-м месте в списке популярности, примерно равна C/k. Здесь C — это число, дополняющее сумму долей до 1, а именно:

C = 1/(1 + 1/2 + 1/3 + 1/4 + 1/5 + ... + 1/N).

Таким образом, самый популярный фильм берут примерно в семь раз чаще, чем седьмой в списке популярности. Эта зависимость называется законом Ципфа (Zipf’s law) (Zipf, 1949), в честь Джоржа Ципфа, профессора лингвистики в Гарвардском университете. Он заметил, что частота использования слова в большом тексте инверсионно пропорциональна его рангу. Например, сороковое в списке самых частотных слов используется в два раза чаще, чем восьмидесятое, и в три раза чаще, чем сто двадцатое.

Распределение Ципфа показано на илл. 7.42 (а). Здесь иллюстрируется утверждение о том, что существует небольшое количество популярных элементов и огромное — непопулярных. Чтобы выявлять распределения такого вида, удобно размещать данные в логарифмическом масштабе по обеим осям, как показано на илл. 7.42 (б). В результате должна получаться прямая.

Илл. 7.42. Распределение Ципфа. (а) Линейная шкала. (б) Логарифмическая шкала по обеим осям

Когда ученые впервые стали изучать популярность веб-страниц, оказалось, что она тоже приблизительно соответствует закону Ципфа (Бреслау и др., Breslаu et al., 1999). Распределение Ципфа относится к семейству распределений, известных как степенные законы (power laws). Эти законы проявляются во многих сферах человеческой деятельности, например в распределении городского населения и распределении богатства. Они также описывают ситуацию, когда имеются несколько крупных и множество более мелких игроков, и здесь снова получаем распределение вдоль прямой линии на графике с логарифмической шкалой по обеим осям. Вскоре было обнаружено, что топологию интернета можно условно описать с помощью степенных законов (Сиганос и др.; Siganos et al., 2003). Затем исследователи начали изображать все мыслимые свойства интернета на логарифмической шкале и, увидев прямую линию, восклицали: «Степенной закон!»

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

Веб-прокси

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

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

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

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

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

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

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

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

Чтобы обеспечить дополнительные уровни кэширования, могут быть добавлены следующие прокси. Каждый прокси (или браузер) делает запрос к своему вышестоящему прокси (upstream proxy). Каждый вышестоящий прокси производит кэширование для нижестоящих прокси (downstream proxy) или браузеров. В результате может получиться, что браузеры компании используют ее прокси, который, в свою очередь, использует прокси интернет-провайдера, а тот контактирует с веб-серверами напрямую. Но на практике, чтобы извлечь большую часть потенциальной выгоды, часто достаточно одного уровня прокси-кэширования (см. илл. 7.44). Проблемой снова оказывается «длинный хвост» популярности. Исследования веб-трафика показали, что кэш общего доступа особенно полезен, пока число пользователей не превосходит количество сотрудников небольшой компании (скажем, 100 человек). Когда это число увеличивается, преимущества использования общего кэша становятся незначительными, поскольку для кэширования непопулярных запросов не хватает места.

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

7.5.3. Сети доставки контента

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

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

Первой применять DNS для распределения контента начала компания Akаmаi в 1998 году. Тогда, на раннем этапе своего развития, интернет едва справлялся с нагрузкой. Akаmаi была первой крупной CDN и очень быстро стала лидером отрасли. Она построила удачную бизнес-модель и систему стимулирования (возможно, еще более удачную, чем сама идея использования DNS для соединения клиентов с ближайшими узлами). Компании платят Akаmаi за доставку своего контента клиентам, чтобы получить удобные для пользователей веб-сайты с низким временем отклика. Узлы CDN должны располагаться там, где есть хорошая скорость подключения; изначально это подразумевало сети интернет-провайдера. На практике узел CDN представляет собой стандартную 19-дюймовую аппаратную стойку с компьютером и множеством дисков, из которой выходит оптоволоконный кабель для подключения к внутренней LAN интернет-провайдера.

ISP выгодно иметь узел CDN в своих сетях, поскольку это снижает величину необходимой им исходящей пропускной способности (за которую они платят). Кроме того, при наличии узла CDN контент доставляется пользователям с меньшей задержкой. Таким образом, выигрывают и интернет-провайдер, и клиенты, а CDN делает деньги. Начиная с 1998 года в этой сфере бизнеса появилось множество других компаний, включая Cloudflare, Limelight, Dyn и т.д., так что сейчас это конкурентная отрасль с большим количеством провайдеров. Как уже упоминалось, многие крупные провайдеры контента, такие как YouTube, Facebook и Netflix, используют собственные сети доставки контента.

Самые большие 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 приобрела более сложный характер. Допустим, вам нужно загрузить главную страницу сайта https://nytimes.com/. 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-адресом http://www.cdn.com/page.html. Чтобы ее загрузить, браузер использует 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 может произвести еще одно коренное изменение в распределении контента в течение ближайших нескольких лет.

В данном разделе представлено упрощенное описание работы CDN. На практике этот процесс включает в себя множество других важных деталей. К примеру, рано или поздно диски узлов CDN полностью заполняются, поэтому их нужно регулярно очищать. Была проделана большая работа по определению того, когда и какие файлы следует удалять; например, см. книгу Баcу и др. (Basu et al., 2018).

7.5.4. Одноранговые сети

Не каждый может установить CDN из 1000 узлов, расположенных в разных уголках планеты, чтобы распространять свой контент. (На самом деле арендовать 1000 виртуальных машин по всему миру не трудно — индустрия хостинга хорошо развита и конкурентна. Но это лишь первый шаг в установке CDN.) К счастью, имеется доступная альтернатива: она проста в использовании и может распространять огромное количество контента. Это одноранговая, или пиринговая, сеть (Peer-to-Peer network, P2P).

P2P-сети внезапно обрели популярность в 1999 году. Поначалу они массово применялись для нарушения закона: 50 млн пользователей сети Nаpster обменивались защищенными авторским правом песнями без разрешения правообладателей. Позже Nаpster был закрыт в судебном порядке, что вызвало большой общественный резонанс. Однако технология равноправных узлов открывает множество полезных возможностей и для законного использования. Другие системы продолжали развиваться с таким большим интересом со стороны пользователей, что P2P-трафик быстро превзошел веб-трафик. На сегодняшний день самым популярным P2P-протоколом остается BitTorrent. Он широко применяется для распространения видео (лицензионного и общедоступного), а также другого объемного контента (например, дисковые образы дистрибутивов операционных систем), что составляет значительную долю общего интернет-трафика. Мы рассмотрим этот протокол чуть позже.

Общие сведения

Основная идея файлообменных P2P-сетей состоит в том, что множество компьютеров объединяют свои ресурсы, формируя систему распределения контента. Часто это обычные домашние компьютеры; нет никакой необходимости в том, чтобы они располагались в интернет-центрах обработки данных. Эти отдельные компьютеры называются пирами (peer — «равный»); каждый из них может выступать и в роли клиента другого пира, получая его контент, и в роли сервера, предоставляя контент другим пирам. Одноранговые системы интересны отсутствием специализированной инфраструктуры в отличие от CDN. В распространении контента участвуют все узлы, часто без централизованного контроля. У этой технологии существует много областей применения (Карагианнис и др.; Karagiannis et al., 2019).

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

Первые одноранговые сети: Napster

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

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

Децентрализация каталога: Gnutella

Созданная в 2000 году, сеть Gnutella была призвана решить некоторые проблемы, свойственные централизованной службе каталогов Napster, с помощью полностью распределенной функции поиска. В сети Gnutella присоединившийся к сети пир ищет другие подключенные пиры с помощью специального процесса обнаружения. Сначала он связывается с несколькими общеизвестными пирами сети, которые он должен был обнаружить на этапе начальной загрузки. Один из механизмов здесь сводится к тому, чтобы само ПО предоставляло некоторый набор IP-адресов пиров сети Gnutella. Обнаружив этот набор, пир может отправить поисковые запросы этим соседним пирам, те, в свою очередь, передадут их своим соседям, и т.д. Этот общий метод поиска в одноранговой сети часто называют сплетнями (gossip).

Хотя метод сплетен решил некоторые проблемы полуцентрализованных сервисов (таких, как Napster), он быстро столкнулся с рядом других трудностей. Во-первых, в сети Gnutella пиры постоянно присоединялись к сети и покидали ее, ведь это были просто компьютеры других пользователей, которые то и дело подключались и отключались от сети. По сути, у пользователей не было особых причин для того, чтобы оставаться в сети после получения нужных файлов. Такое поведение, фрирайдинг (free-riding), было довольно распространено: около 70 % пользователей не предоставляли никакого собственного контента (Адар и Губерман; Adar and Huberman, 2000). Вторая проблема состояла в том, что лавинообразные методы, и в особенности протокол сплетен, трудно поддаются масштабированию. Это остро проявилось, когда Gnutella стала популярной: увеличение числа участников сети сопровождалось экспоненциальным ростом количества сообщений-сплетен. В результате для пользователей с ограниченной пропускной способностью сеть была практически непригодна. Введение так называемых ультрапиров (ultra-peers) в какой-то мере смягчило проблему, но в целом Gnutella отличалась весьма нерациональным использованием доступных сетевых ресурсов. Трудности с масштабируемостью процесса поиска в сети Gnutella подтолкнули исследователей к использованию распределенных хеш-таблиц (Distributed Hash Tables, DHT). Они направляют процесс поиска в соответствующую одноранговую сеть в зависимости от его хеш-значения. При этом каждый узел этой сети отвечает за предоставление информации, охватывающей лишь некоторое подмножество всего пространства поиска, а DHT-таблица должна направлять запрос к пиру, способному предоставить нужный результат. DHT-таблицы применяются во многих современных одноранговых сетях, включая eDonkey (где DHT-таблица используется для поиска) и BitTorrent (где DHT-таблица нужна для масштабирования процесса отслеживания пиров в сети, о котором мы поговорим в следующем разделе).

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

Это можно объяснить целым рядом причин. Например, как и любой интернет-сервис, Gnutella может подвергнуться атаке типа «отказ в обслуживании», что и произошло. Одна из самых простых DDoS-атак против сети — атака загрязнения (pollution attack). Такие атаки заполонили Gnutella поддельным контентом. В том, чтобы эти сети стали бесполезными, были крайне заинтересованы представители звукозаписывающей индустрии (в первую очередь Американская ассоциация компаний звукозаписи). Оказалось, что они засоряли подобные сети огромным количеством поддельных материалов, чтобы заставить пользователей отказаться от использования сетей для обмена авторским контентом.

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

Решение проблем масштабирования, мотивации пользователей и проверки контента: BitTorrent

Протокол BitTorrent разработан Брэмом Коэном в 2001 году, чтобы позволить набору одноранговых узлов быстро и легко обеспечивать общий доступ к файлам. Существуют десятки бесплатных поддерживающих его клиентов, аналогично тому, как множество браузеров поддерживает протокол HTTP для взаимодействия с веб-сервером. Этот протокол доступен как открытый стандарт, его описание находится на сайте bittorrent.org.

В типичной одноранговой системе, например, организованной с помощью протокола BitTorrent, каждый пользователь обладает некоторой информацией, которая может представлять для кого-то интерес (бесплатное ПО, музыка, видео, фотографии и т.д.) Чтобы предоставить контент в общий доступ, необходимо ответить на следующие три вопроса:

1. Как пир находит другие пиры с нужным ему контентом?

2. Как контент дублируется пирами, чтобы обеспечить быстрое скачивание для всех?

3. Как пиры поощряют друг друга к тому, чтобы наряду со скачиванием контента для себя они загружали его для других?

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

Торрент — это просто файл в определенном формате, содержащий два ключевых вида информации. Прежде всего, это имя трекера — сервера, который направляет пиры к содержимому торрента. Вторым видом информации является список фрагментов одинакового размера, или сегментов (chunks), из которых состоит контент. В первых версиях BitTorrent трекер был централизованным сервером. Как и в случае Napster, централизация делала трекер единственным уязвимым звеном сети. В современных версиях BitTorrent функциональность трекера в большинстве случаев децентрализуется с помощью DHT-таблицы. Для разных торрентов могут использоваться различные размеры сегментов, обычно в диапазоне от 64 до 512 Кбайт. Файл торрента содержит имя каждого сегмента, предоставленного как 160-битный SHA-1 хеш сегмента. Мы рассмотрим криптографические хеши, такие как SHA-1, в главе 8. Пока вы можете рассматривать хеш как более длинную и безопасную контрольную сумму. Торрент-файл, содержащий размер сегментов и хеши, как минимум на три порядка меньше, чем контент, поэтому он может быть передан быстро.

Чтобы загрузить контент, описанный в торренте, пир сначала контактирует с его трекером. Трекер (tracker) — это сервер (или группа серверов, организованная с помощью DHT), который поддерживает список всех остальных пиров, активно производящих скачивание и загрузку контента. Этот набор пиров называется роем (swarm). Члены роя постоянно контактируют с трекером, чтобы сообщать, что они все еще активны, либо о том, что они покидают рой. Когда новый пир связывается с трекером, чтобы присоединиться к рою, трекер сообщает ему об остальных пирах в рое. Получение торрента и контакт с трекером — это первые два шага для загрузки контента (илл. 7.47).

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

Илл. 7.47. BitTorrent

В то время как пир участвует в рое, он одновременно скачивает отсутствующие сегменты с других пиров и загружает имеющиеся у него сегменты тем пирам, которым они нужны. Этот обмен показан как последний шаг распределения контента на илл. 7.47. Какое-то время пир собирает сегменты, пока не загрузит весь контент. Пир может покинуть рой (и вернуться) в любое время. Обычно он остается в течение некоторого короткого периода после окончания своей собственной загрузки. Из-за появляющихся и исчезающих пиров «текучесть» в рое может быть довольно большой.

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

Третий вопрос касается мотивации пользователей. Узлы CDN-сетей предназначены лишь для того, чтобы предоставлять контент пользователям, но P2P-узлы работают иначе. Это компьютеры пользователей, а люди часто больше заинтересованы в том, чтобы получить нужный им фильм, чем в том, чтобы помочь в скачивании остальным. То есть у пользователей есть мотивация к тому, чтобы обмануть систему. Узлы, берущие ресурсы из системы без какого-либо ответного вклада, называют фрирайдерами (free-riders), или личерами (leechers — «пиявки»). Если их слишком много, система перестает нормально функционировать. Первые P2P-системы известны наличием таких узлов (Сарою и др.; Saroiu et al., 2003), поэтому протокол BitTorrent был призван минимизировать их количество.

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

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

Этот алгоритм заглушения иногда описывается как реализация стратегии «око за око» (tit-for-tat), поощряющей сотрудничество в повторяющихся взаимодействиях. Это широко известная стратегия из теории игр, при которой: 1) у игроков нет мотивации к обману, если они постоянно играют друг с другом (как происходит в сети BitTorrent, где пиры должны периодически обмениваться сегментами) и 2) игроки наказываются при отказе от сотрудничества (как в случае заглохших пиров). Несмотря на эту схему, клиенты BitTorrent все же могут прибегать к различным способам обмана системы (Пиатек и др.; Piatek et al., 2007). Например, поскольку алгоритм сети BitTorrent поощряет выбор редких сегментов, пиры могут предоставить ложную информацию о том, какими сегментами файла они располагают (например, они могут сообщить о наличии редких сегментов) (Лиокас и др.; Liogkas et al., 2006). Кроме того, существуют программы, позволяющие клиентам сообщать трекеру ложную информацию о соотношении между объемом скачанной и переданной информации (то есть сообщать о том, что они раздавали данные другим пирам, хотя в действительности этого не было). По этим причинам критически важно, чтобы пиры проверяли сегменты, получаемые от остальных. Это можно делать путем сравнения хеша SHA-1 каждого сегмента, указанного в торрент-файле, с соответствующим вычисленным хешем SHA-1 каждого скачиваемого сегмента.

Еще одной проблемой является мотивация пиров к тому, чтобы оставаться в рое сети BitTorrent в качестве сидера даже после скачивания нужного файла. Если они не будут этого делать, может возникнуть ситуация, когда ни у кого в рое не будет целого файла или (что еще хуже) когда в рое вообще не будет определенных сегментов, что сделает невозможным скачивание файла полностью. Это особенно остро проявляется в случае непопулярных файлов (Менаше и др.; Menasche et al., 2013). Для решения проблемы мотивации были разработаны различные методы (Рамачандран и др.; Ramachandran et al., 2007).

В ходе этого раздела вы убедились, что к теме протокола BitTorrent прилагается обширная терминология: торренты, рои, личеры, сидеры, трекеры и т.д. Чтобы узнать больше о BitTorrent, ознакомьтесь с короткой статьей Коэна (Cohen, 2003).

7.5.5. Эволюция интернета

Как было упомянуто в главе 1, интернет прошел довольно причудливый исторический путь, возникнув в ходе осуществления научно-исследовательского проекта, над которым работали несколько десятков американских университетов по договору с агентством ARPA. Трудно даже определить, когда именно он появился. Возможно, это произошло 21 ноября 1969 года, когда была установлена связь между двумя узлами ARPANET, расположенными в Калифорнийском университете в Лос-Анджелесе (UCLA) и в Исследовательском институте Стэнфорда (SRI)? Или это случилось 17 декабря 1972 года, когда к ARPANET подключилась гавайская сеть AlohaNet, образовав тем самым интерсеть? Или, быть может, интернет появился 1 января 1983 года, когда ARPA официально утвердила протокол TCP/IP? А возможно, он возник в 1989 году, когда Тим Бернерс-Ли предложил создать то, что впоследствии стало Всемирной паутиной? Сложно сказать. Однако ни у кого нет сомнений, что со времен становления сети ARPANET и первых зачатков Всемирной паутины интернет подвергся огромным изменениям, значительная часть которых была обусловлена повсеместным распространением CDN и облачных вычислений. Ниже мы кратко рассмотрим этот процесс.

На илл. 7.48 представлена базовая модель сети ARPANET и первой версии интернета. Она включает в себя три типа компонентов:

1. Хосты (компьютеры, выполняющие определенную работу для пользователей).

2. Маршрутизаторы (которые в ARPANET обозначались как «IMP»), производящие коммутацию пакетов.

Илл. 7.48. В первой версии интернета использовались главным образом двухточечные соединения

3. Линии передачи (изначально выделенные телефонные линии со скоростью 56 Кбит/с). Каждый маршрутизатор был подключен к одному или нескольким компьютерам.

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

Положение стало меняться, когда интернет вышел за рамки академической среды и приобрел коммерческий характер. Это привело к созданию магистральных сетей со сверхскоростными каналами, администрируемых такими крупными телекоммуникационными компаниями, как AT&T и Verizon. Каждая компания использовала собственную магистральную сеть, однако они связывались друг с другом через точки пирингового обмена. Появились интернет-провайдеры, взявшие на себя задачу подключения к интернету домашних пользователей и предприятий, а также региональные сети, соединявшие провайдеров с магистральными сетями (см. илл. 1.17). Следующим шагом стало появление общенациональных интернет-провайдеров и CDN (см. илл. 1.18).

В главе 1 мы отмечали, что появление облачных вычислений и сверхбольших CDN привело к новым изменениям в структуре интернета. Такие компании, как Amazon и Microsoft, сегодня используют облачные центры обработки данных, включающие сотни тысяч размещенных в одном здании компьютеров, что позволяет их пользователям (обычно это крупные компании) буквально за считаные секунды выделить для своих задач 100, 1000 или 10 000 компьютеров. Во время большой распродажи в так называемый киберпонедельник (понедельник после Дня благодарения) компания Walmart может выделить 10 000 компьютеров для обработки возросшей нагрузки, просто автоматически запросив их у своего облачного провайдера; они будут предоставлены буквально через несколько секунд. После возвращения к нормальному режиму во вторник эти мощности можно будет вернуть назад. Почти все крупные компании, имеющие дело с миллионами пользователей, используют облачные сервисы, чтобы практически мгновенно увеличивать или уменьшать свои вычислительные мощности по мере необходимости. Как мы уже говорили, дополнительным преимуществом облачных сервисов является достаточно хорошая защита от DDoS-атак. В силу огромных размеров облако может принять тысячи запросов за секунду, ответить на них и продолжить нормальное функционирование, не позволяя DDoS-атаке достигнуть своей цели.

CDN имеют иерархическую структуру, включающую основной сайт (который может быть продублирован два или три раза для надежности) и множество размещенных по всему миру кэшей для контента. Когда пользователь запрашивает контент, он доставляется из ближайшего кэша. Это позволяет снизить величину задержки и распределить рабочую нагрузку. Первая крупная коммерческая CDN от компании Akamai содержит более 200 000 узлов кэша в более чем 1500 сетях, охватывающих более 120 стран. Аналогично CDN от компании CloudFlare сегодня включает в себя кэширующее оборудование в более чем 90 странах. Поскольку обычно узлы кэша CDN находятся рядом с офисом интернет-провайдера, пересылка данных между CDN и провайдером осуществляется по сверхбыстрому оптоволоконному каналу, длина которого может составлять всего 5 м. В силу новых реалий архитектура интернета приобрела вид, показанный на илл. 7.49: основная часть трафика — это обмен данными между сетями доступа (например, региональными) и распределенной облачной инфраструктурой (CDN или облачными сервисами).

Илл. 7.49. Большую часть интернет-трафика сегодня составляет трафик облачных сервисов и CDN; при этом сети доступа и интернет-провайдеры активно обмениваются трафиком через частные линии подключения

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

1. Купить продукт в интернет-магазине.

2. Получить электронное письмо от почтового сервиса.

3. Выдать банку платежное поручение.

4. Произвести потоковую передачу песни или фильма на устройство пользователя.

5. Обновить страницу в Facebook.

6. Отобразить статью онлайн-версии газеты.

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

Магистральные сети позволяют многим облачным сервисам и CDN связываться друг с другом через точки пирингового обмена, если между ними нет частной выделенной линии подключения. Так, к точке обмена интернет-трафиком DE-CIX в Франкфурте подключено около 2000 сетей, а к точкам обмена AMS-IX в Амстердаме и LINX в Лондоне — примерно по 1000. К каждой крупной точке обмена в США подключено по несколько сотен сетей. Эти точки также соединены между собой одной или несколькими оптоволоконными линиями OC-192 (9,6 Гбит/с) и/или OC-768 (38,5 Гбит/с). Точки пирингового обмена и крупные коммуникационные сети, которые в них соединяются друг с другом, образуют магистраль интернета, к которой напрямую подключено большинство облаков и CDN.

Как уже упоминалось, CDN компании Akamai включает в себя более 200 000 серверов, большая часть которых расположена внутри сетей интернет-провайдеров. Эта тенденция продолжит менять ландшафт интернета в ближайшие годы. Все больше распространяются и другие CDN, такие как CloudFlare. Наконец, свои CDN начинают развертывать провайдеры контента и сервисов. К примеру, компания Netflix развернула CDN под названием Open Connect, которая размещает контент Netflix в узлах кэша, либо в точках обмена интернет-трафиком, либо непосредственно внутри сети доступа интернет-провайдера. Степень, в которой интернет-путь пройдет через отдельную магистральную сеть или точки обмена, зависит от множества факторов, таких как затраты, доступные возможности подключения в регионе и экономия за счет масштабирования. Если в Европе и ряде других частей мира очень популярны точки обмена интернет-трафиком, то в США чаще применяется прямое подключение посредством частных межсетевых соединений.