Pull to refresh

Смерть транзитного трафика?

Reading time 12 min
Views 16K
Original author: Geoff Huston
image

Есть ли свет в конце туннеля для провайдеров транзитного трафика?

Я был поражён на недавней встрече NANOG тем, как мало выступлений было по вопросам ISP-пространства и по проблемам, связанным с ISP-операциями, и как много — по среде дата-центров.

Если есть тема, которая является определяющей в нашем общении, то это, безусловно — среда, которая, как представляется, доминирует при проектировании дата-центров и эксплуатации сетей. И, представляется, что функция поставщика интернет-услуг (ISP-функция) и, в частности, функция поставщика транзитного трафика исчезает. Задача доставки пользователей к контенту меняется на задачу доставки контента к пользователям. Означает ли это, что транзит для интернет-пользователей теперь перестаёт действовать? Давайте посмотрим на это немного внимательнее.

Интернет состоит из нескольких десятков тысяч отдельных сетей, каждая из которых играет свою роль. Если считать систему маршрутизации интернета хорошим индикатором, то имеется 55 400 отдельных сетей (или «автономных систем» на языке системы маршрутизации).

Большинство таких сетей расположено на периферии сети и, явно, не предоставляет услугу транзита пакета в какую-либо другую сеть — в настоящее время насчитывается 47 700 таких структур. Оставшиеся 7 700 сетей работают в несколько ином качестве. Выдавая набор адресов в интернет, они также переносят сообщения других сетей — другими словами, можно сказать, что они исполняют роль провайдеров транзитного трафика.

Почему это различие было важно в прошлом? Что было такого особенного в «транзите»?

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

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

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

image

Рис. 1. Модели «провайдер/клиент» и «пиринг» в мире поставщиков интернет-услуг (ISP)

В этой среде разобраться, кто провайдер, а кто клиент, становится трудной задачей в некоторых случаях. Аналогично — понять, является ли пиринг с другим провайдером полезным вам или наоборот, также нередко проблематично. Но был один критерий, который, казалось, был в значительной степени самоочевидным: провайдеры доступа платят провайдерам транзита за свой трафик.

Общим результатом этих договорённостей было некоторое количество «уровней» (Tier), где игроки, которые вместе существовали на каком-то уровне, обычно находили некоторую форму взаимодействия, сводившуюся к пирингу, в то время как при взаимодействии нескольких уровней более низкий уровень сети становился клиентом, а более высокий — провайдером. Эти уровни не были формально определены, и не было «допуска» на любой уровень с заранее определённым результатом.

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

image

Рис. 2. Многоуровневость в ISP-среде

Довольно ясно видно, куда направлен этот процесс, потому что наверху этой иерархии находились доминирующие поставщики услуг по транзиту. На самом «верхнем» уровне были т.н. провайдеры «уровня один» (Tier I). Вместе эти провайдеры формировали неформальную «олигархию» интернета (Tier I Club).

Чтобы понять, почему транзит играл столь важную роль, достаточно было только посмотреть на сравнительно отдалённые районы мира, где расходы на транзит полностью доминировали в расходах на предоставление доступа к сети. В Австралии десять лет назад или около того примерно 75% всех данных, которые были доставлены конечным пользователям, было передано через Тихий океан (и обратно) австралийскими интернет-провайдерами, взимавшими плату за эту функцию транзита. Результатом были высокие розничные цены на доступ в Интернет, использование ограничений объёма данных и все виды усилий по кэшированию локальных данных.

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

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

В то время как модель позволяла любому пользователю воспользоваться любым сервисом, маршрут пересылки внутри сети заметно различался для пользователей при доступе к одному и тому же сервису. Это часто приводило к аномальному функционированию, при котором, чем дальше пользователь был расположен от сервера, тем медленнее происходила пересылка. Например, показанный внизу рисунок взят из презентации Фейсбука на NANOG 68 (рис. 3).

image

Рис. 3. Эксплуатационные характеристики интернета, 2011 год

Области, обслуживаемые геостационарными спутниками и области с чрезвычайно длинными маршрутами с позиции протяжённости каналов имели, конечно, намного большее время на передачу и подтверждение (RTT) для данных, которыми обмениваются пользователь и точка предоставления услуг.

Естественно, такое увеличение RTT не является разовым явлением. Если учесть, что может иметь место расширенная DNS-транзакция, затем TCP-квитирование, потенциально, с последующим TLS-квитированием, затем транзакция запроса, после чего доставка требуемого контента с медленным TCP-пуском, то средний пользователь имеет задержку транзакций как минимум 3 RTTS, а более вероятно — вдвое большую.

Транзакция, которая для пользователя, расположенного в том же городе, где находится сервер, занимает менее одной десятой секунды, может потребовать для отдалённого пользователя до 6-ти секунд.

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

Треть секунды уходит на путь пакета к геостационарному спутнику и обратно. Спутниковая задержка определяется скоростью света и расстоянием от Земли до спутника на геостационарной орбите.

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

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

Именно это и происходит в настоящее время. Мы видим, что сейчас проекты подводных кабелей ориентированы больше на обеспечение связи дата-центров крупнейших провайдеров, чем на обеспечение пользовательского трафика к удалённым дата-центрам. Google в 2008 году начал входить во владение подводными кабелями и в настоящее время имеет позиции в шести из них (см., в частности, недавнее сообщение о прокладке кабеля (рис. 4)).

image

Рис. 4. Сообщение о CDN-кабеле

Тим Строндж, вице-президент TeleGeography, как сообщал WIRED, заявил, что этот новый кабель продолжает действующий тренд:
«Крупные поставщики контента выдвигают громадные и часто непрогнозируемые требования к трафику, особенно между их собственными дата-центрами. Их требования к производительности таковы, что для них имеет смысл на самых нагруженных маршрутах прокладывать кабели, а не покупать трафик. Владение подводными оптоволоконными парами даёт также свободу манёвра при модернизации, когда они посчитают это целесообразным, снимая зависимость от стороннего оператора подводной кабельной связи.»

Этот сдвиг в технологиях доступа к контенту также изменяет роль различных интернет-обменов.

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

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

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

Желание повысить устойчивость сервиса в условиях атаки, в сочетании с требованиями пользователей по быстрому доступу порождает потребность использовать некоторую форму эникастного сервиса, при которой распределение услуг происходит по многим точкам доступа, близким к различным группам пользователей. Поэтому неудивительно, что компании, распределяющие контент, такие как Akamai и Cloudflare (назовём хотя бы эти две), имеют высокий спрос на свои услуги.

Но тогда, если контент смещается в дата-центры, располагаемые ближе к пользователям, что делать провайдерам транзитного трафика?

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

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

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

В результате изменяется также вся архитектура интернета. От одноранговой многоточечной плоской сетки интернета начала 90-х мы перешли, в основном, к архитектуре клиент/сервер, где основная часть трафика приходится на коммуникацию между клиентами и серверами, а трафик между самими клиентами почти отсутствует.

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

Сейчас вполне возможно, что мы продолжим и дальше дробить модель клиент/сервер на более мелкие части, эффективно направляя каждого клиента в сервисный «конус», определённый совокупностью локальных дата-центров (рис. 5).

image

Рис. 5. «Сервисные конусы» сетей доставки контента (CDN)

Если мир интернет-сервиса, на самом деле, определяется небольшим числом CDN-провайдеров: Google, Facebook, Amazon, Akamai, Microsoft, Apple, Netflix, Cloudflare и, возможно, ещё несколькими — а все другие поставщики услуг, в основном, встраивают свои сервисы в эти громадные облака контента, то почему клиентский трафик должен уходить на отдалённые дата-центры? В чём именно состоит остающаяся потребность в дальнем транзите? Есть ли, вообще, будущее у провайдеров услуг по транзитному трафику?

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

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

Если транзит является мало востребованной и мало используемой услугой, то в состоянии ли мы предусмотреть такую архитектуру интернета, которая устраняет транзит вообще, как сущность?

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

В этом случае, в таком собрании сервисных конусов, есть ли какая-то ценность в глобально ориентированном адресном пространстве? Если все потоки трафика ограничены рамками каждого сервисного конуса, то сохраняющееся требование адресации является, в лучшем случае, требованием различать конечные точки только в рамках конуса без какого-то конкретного требования для уникальности во всей сети (независимо от того, что «во всей сети» могло бы означать в такой системе). Если кто-либо до сих пор помнит работу IETF на RSIP (Realm-Specific IP, RFC 3102), то примерно это я имею в виду, высказывая данные соображения.

Но такое может быть реализовано лишь через несколько лет, если, вообще, может быть реализовано…

Сегодня мы видим дальнейшие изменения в продолжающейся напряжённости между передачей данных и контентом. Мы видим снижение использования модели, которая инвестирует, в основном, в передачу данных так, что пользователь «транспортируется» к двери бункера с контентом.

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

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

На более общем уровне мы видим некоторую степень сегментации или фрагментации в архитектуре интернета как результат специализации предоставления услуг. В такой среде, которая сегментирована на почти автономные сервисные конусы, что является движущей силой рынка, которая позволила бы видеть все возможные сервисы, загруженные в каждую точку распределения сервисов? Кто будет платить за такое многократно продублированное обеспечение сервисов? И если никто не будет готов пойти на эту модель «универсального» контента, то в какой мере «интернет» будет разным для разных мест планеты? Будут ли все доменные имена согласованно доступны и единообразно преобразовываться в этой сегментированной среде?

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

Как долго будет действовать эта ориентированная на распределение контента модель предоставления услуг, можно только гадать. Вполне может быть, что это только некоторая фаза, которую мы проходим, а имеющееся представление, ориентированное на дата-центры, является просто промежуточным этапом, а не тем, где мы могли бы быть, в конечном итоге. Так что, возможно, сейчас всё же не совсем правильное время полностью отказаться от традиционной концепции об универсальной связываемости и всеохватывающем транзитном сервисе, несмотря на то, что, вроде бы похоже, сегодняшний интернет делает уже довольно большой шаг в совсем другом направлении!
Tags:
Hubs:
+24
Comments 8
Comments Comments 8

Articles