Alter.Org.UA
 << Back Home EN en   Donate Donate

Пробки в интернет или немного об управлении трафиком

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

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

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

  • чтобы 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-аттак, т.к. трафик в направлении сети-жертвы будет ограничиваться еще на выходе из сетей-источников.

2012.11.13

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

MS PowerPoint: net-mgmt-v3.ppt.rar/tgz (48.5 Kb/49.8 Kb)
OpenOffice net-mgmt.odp

См. также



FB or mail alterX@alter.org.ua (remove X)   Share
<< Back Автор: Alter (Александр А. Телятников) Сервер: Apache+PHP под FBSD © 2002-2024