Контент бывает разный - зеленый, синий, красный...

Конечные пользователи платят за возможность получать качественный доступ к любому контенту через интернет.

Что значит "качественный" ?

• чтобы web-странички, в т.ч. с картинками открывались быстро
• интерактивные странички обновлялись за комфортное время и не задумывались на несколько минут
• online-аудиопотоки не квакали
• online-видео не залипало и не квадратило
• в игрушках ping был ровный, лежал в допустимых пределах и не терялись пакеты
• чтобы работали Skype и ICQ
• файлы выкачивались на заявленной скорости
• и все это происходило одновременно :)

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

Первая сложность в обеспечении качества доставки - отсутствие информации о состоянии каналов за пределами зоны ответственности отправителя и отсутствие политики приоритезации трафика в случае перегрузки. Маршрут выбирается просто по "карте" AS-path, без учета фактического времени отклика и уровня потерь пакетов. Пора создавать Yandex-пробки для интернет ?

Вторая - сложность классификации данных. Далеко не всегда можно определить тип трафика простым анализом пакетов.

Третья - ограничение скорости коммутации. На больших объемах (10GE и выше) стало заметно сказываться ограничение на к-во пакетов в секунду, которое может обработать оборудование. Так, при большом к-ве мелких пакетов потери могут начаться уже при 50% загрузке порта.

Кто отвечает за доставку ?

Много кто. Трасса от клиента до контента может выглядеть так:

• - провайдер - транспорт - точка обмена - транспорт - провайдер - (hosting, PtP)
• - провайдер - транспорт - точка обмена - транспорт - (hosting, CDN, PtP)
• - провайдер - транспорт/пиринг - провайдер - (CDN, PtP)
• - провайдер - пиринг - (CDN)
• - провайдер - (local PtP)

Очевидные проблемные места

• нехватка полосы клиента (полисер провайдера в соответствии с тарифным планом)
• нехватка пропускной способности внутренней сети провайдера
• нехватка пропускной способности транспорта
• нехватка пропускной способности точки обмена

Менее очевидные проблемные места

• перегрузка отдельных каналов в результате нарушения работы одного из узлов сети.
• временное нарушение связности в период перестройки маршрутов.
• потери пакетов в техническом трафике (в 1ю очередь DNS)
• дополнительная перегрузка каналов retransmit'ами, вызванными потерей пакетов, в т.ч. в результате нехватки канала
• невозможность кеширования на стороне клиента.
  • явная, обусловленная директивами управления кешем в HTTP-заголовках. Ряд контент-провайдеров объявляют контент некешируемым, хотя де-факто, данные всегда отдаются одни и те же.
  • неявная. При использовании CDN/mirror тежнологий часто (как правило) при повторной загрузки страницы ссылки на объекты генерируются уже другие. Таким образом один и тот же объект многократно загружется под разными именами.
• наличие большого количества подгружаемых из сети объектов (картинки, скрипты, доп. запросы к серверу), необходимых для отображения одной страницы. Тут есть сразу несколько моментов:
  • время ответа сервера
  • (не)способность браузера выполнять параллельную загрузку.
  • (не)использование параллельного исполнения внутри самой сраницы (jquery) или приложения
• технологические ограничения скорости коммутации.
• технологические ограничения скорости передачи.

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

Как показала практика, при ограничении потока данных шейпером с буферизацией уровень поторь пакетов остается приемлемым даже при кратковременных перегруках. При ограничении на уровне L2 (скоростью порта) или полисером без буферизации потери начинаются уже при достижении 70-80% загрузки канала из-за кратковременных всплесков трафика.

Классические решения

• Расширить канал. На первый взгляд логично, но не всегда экономически и технически возможно. Расширить можно только свой канал. Каналы других участников сети останутся неизменными. Получается, что где-то в чужой зоне ответственности могуть быть узкие места. Кроме того, расширение не всегда повышает надежность.
• Пиринг, альтернативные каналы и включение в разные точки обмена. Все это существенно улучшает ситуацию, повышает надежность в целом. А также порождает вопрос оптимального распределения трафика между каналами, и вопрос прозрачной для конечного пользователя отработки аварийных ситуаций на одном или нескольких каналах. Риск нарваться на узкий канал в чужой зоне ответственности уменьшается, но т.н.м. остается ненулевым.
• Кеширование контента. Может быть на стороне клиента (browser cache), ISP (transparent proxy) и на стороне поставщика контента (CDN). В обоих случаях копия контента хранится как можно ближе к клиенту. За счет этого разгружаются каналы и уменьшается время ответа. Transparent proxy пропускает через себя весь трафик, в т.ч. тот, который не нуждается в кешировании, это требует доп. ресурсов для анализа протокола и бессмысленной деятельности. Подход CDN требует от каждого поставщика контента размещения своего оборудования в локальных датацентрах. Использование протокола torrent контент-провайдерами можно считать механизмом локального кеширования средствами клиентов. Еще одно узкое место - генерация имен объектов. Зачастую поставщик контента совершенно не заботится о том, чтобы загружаемые объекты эффективно кешировались на стороне клиента.
• Использование jumbo-фреймов. В теории это позволяет снизить нагрузку по pps за счет увеличения MTU. На практике получается, что большинство клиентов использует оборудование FastEthernet или более медленное с MTU <= 1500. Промежуточные маршрутизаторы не производят пересборку пакетов, поэтому ощутимого эффекта от использования этой технологии на магистралях ожидать пока не приходится.

Что вообще нужно сделать ?

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

Как ?

Что можно делать прямо сейчас

• "правильный" шейпер/QoS с очередью пакетов на исходящем канале. Полезно всем участникам при достижении нагрузки на канал ~70%. К примеру для клиента-домосетки это может выглядеть так:
  • 1% под DNS, SSH, ICMP
  • 5% под игрушки, Skype,
  • еще 5% - web запросы и доступ к БД
  • еще 5% - доступ к online video
  • Остальное - как придется.
  объем приоритетного трафика от клиента стоит ограничить, во избежание нецелевого использования полосы.
• "правильный" шейпер/QoS с очередью пакетов на входящем канале, чтобы протоколы, контролирующие скорость передачи, притормозились. Полезно на уровне ISP и транспорта, тоже при достижении ~70% нагрузки. Для клиента-домосетки это может выглядеть так:
  • 1% под DNS, SSH, ICMP ответы
  • 5% под игрушки, Skype,
  • еще 10% - web ответы и доступ к БД
  • еще 20% - online video сервера
  • Остальное - как придется.
• CDN.
• Сделать возможным эффективное кеширование контента. Как минимум клиент, а в идеале - все клиенты одного ISP (или хотя бы блок /24) должны получать одинаковые URL для одинаковых ресурсов. Такжэе обратить внимание на директивы управления кешированием.
• оптимизация формата (объема) контента в соответствии с каналом пользователя (GPRS, DSL, FastEthernet, etc.)
• использование torrent контент-провайдерами.
• локальный torrent ретрекер и torrent peer policy (retracker.local, peerpolicy.local) внутри ISP
• кеширование HTTP, DNS. Возможно, кеширование/ретрекинг torrent
• использовать, где это возможно, протоколы маршрутизации, позволяющие быстро реагировать на изменения маршрутов.

Чего не хватает ?

• нет механизма ограничения входящего трафика и способа получения актуальной информации о загруженности промежуточных каналов и канала принимающей стороны. Это мог бы быть спец. network load discovery протокол. В этом случае необходимо будет обеспечить прозрачное прохождение через сети, не поддерживающие данный протокол.
• нет способа эффективно и автоматизированно отделять критический трафик, нужны access-list'ы и списки ресурсов. Была бы полезна общедоступная база серверов и сервисов (tcp/udp + ip + port range) для построения acl'ов. Либо стандартизация номеров портов (наиболее легко реализуемо).
• нет способа эффективно отделять кешируемый (условно статический) HTTP контент от динамического на уровне L3. Варианты - общедоступная база либо использование др. номера TCP порта или др. IP для контента, подлежащего кешированию. При наличии такой информации ISP и транспортные операторы имели бы возможность сократить время отклика ресурсов и сэкономить каналы. Также помогла бы стандартизация.
• не хватает интеграции torrent-протокола в браузеры. Это позволило бы переложить задачу кеширования контента на локальную сеть, и тем самым значительно ускорить скорость загрузки. Кроме того, torrent существенно менее чувствителен к потерям пакетов в сети.
• не хватает технологии объединения мелких пакетов, следующих в одном направлении в jumbo-фреймы. Это можно делать как по MAC-адресу следующего узла, так и по MPLS route ID.

Кому это вообще нужно и зачем ?

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

PS. На ENOG 6 был доклад на эту тему в моем исполнении. Кому интересно - вот презентация:

См. также

• HTTP caching
• Local Proxy
• Squid url_rewrite for Windows
• ENOG 6 presentations

FB