Пробки в интернет или немного об управлении трафиком Контент бывает разный - зеленый, синий, красный... Конечные пользователи платят за возможность получать качественный доступ к любимому контенту через интернет. Телятников Александр Netassist

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

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

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

Менее очевидные проблемные места * временные перегрузки и/или нарушение связности. * потери пакетов в техническом трафике (в 1-ю очередь DNS) * невозможность/отсутствие кеширования на стороне клиента. * использование шифрования без необходимости * наличие большого количества подгружаемых из сети объектов (картинки, скрипты, доп. запросы к серверу), необходимых для отображения одной страницы. * медленный DNS * технологические ограничения скорости передачи. Да, GPRS и DSL еще живы.

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

# невозможность кеширования на стороне клиента. * явная, обусловленна директивами управления кешем в HTTP-заголовках. Ряд контент-провайдеров объявляют контент некешируемым, хотя де-факто, данные всегда отдаются одни и те же. Сюда же можно отнести вариант короткого времени жизни объекта. В этом случае получаем запросы revalidate, занимающие не столько канал, сколько время. refresh_pattern vec.*\.maps\.yandex\.net\/tiles\? %20080 ignore-no-cache override-expire override-lastmod ignore-reload ignore-auth refresh_pattern youtube.*videoplay % ignore-no-cache override- expire override-lastmod ignore-reload ignore-private refresh_pattern (mt|kh|pap).*\.google\.com % ignore-no-cache override-expire override-lastmod ignore-reload ignore-private ignore-auth

* неявная. При использовании CDN/mirror технологий часто (как правило) при повторной загрузки страницы ссылки на объекты генерируются уже другие. Таким образом один и тот же объект многократно загружается под разными именами. A A

Эффективность "Склеивания" URL'ов

Эффективность "Склеивания" URL'ов (rewrite.pl)

Главные потребители трафика, они же наиболее эффективно кешируемые (только принудительно!):

Другие знакомые ресурсы

Другие знакомые ресурсы (графики)

В общем объеме на HTTP приходится около 10-30%. Из них на web-серфинг - тоже ~10%. Т.е. ради экономии 1-2% трафика строить что-то специальное смысла нет. А для улучшения качества сервиса - смысл есть. В случае перегрузки канала или самого ресурса - тоже. Отдельный момент - процент запросов, обработанных proxy без обращения к внешним серверам, в т.ч. без REFRESH_HIT. Чем больше время жизни картинки в кеше тем более счастлив будет клиент. А для самих контент-провайдеров есть, наверное, повод задуматься. Если принудительный кеш экономит от 30% до 95% полосы и вычислительных ресурсов, может это повод таки позволить клиентам кешировать данные ?

# наличие большого количества подгружаемых из сети объектов (картинки, скрипты, доп. запросы к серверу), необходимых для отображения одной страницы. Тут есть сразу несколько моментов: * время ответа DNS * время ответа сервера * (не)способность браузера выполнять параллельную загрузку. * (не)использование параллельного исполнения внутри самой страницы (jquery) или приложения

Классические решения * Расширить канал. Можно, дорого и как правило, только свой. * Пиринг, альтернативные каналы и включение в точки обмена. Вопрос оптимального распределения трафика между каналами остается открытым. * Кеширование контента. Копия хранится как можно ближе к клиенту (а то и у него самого). Но как показало наше исследование вопросов много. * Использование jumbo-фреймов. В теории это позволяет снизить нагрузку по pps за счет увеличения MTU. На практике получается, что большинство клиентов использует MTU

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

Что можно делать прямо сейчас * "правильный" шейпер/QoS с очередью пакетов на исходящем канале. Полезно всем участникам при достижении нагрузки на канал ~70%. К примеру для клиента- домосетки это может выглядеть так: o 1% под DNS, SSH, ICMP o 5% под игрушки, Skype, o еще 5% - web запросы и доступ к БД o еще 5% - доступ к online video o Остальное - как придется.

* "правильный" шейпер/QoS с очередью пакетов на входящем канале, чтобы протоколы, контролирующие скорость передачи, притормозились. Полезно на уровне ISP и транспорта, тоже при достижении ~70% нагрузки. Для клиента-домосетки это может выглядеть так: o 1% под DNS, SSH, ICMP ответы o 5% под игрушки, Skype, o еще 10% - web ответы и доступ к БД o еще 20% - online video сервера o Остальное - как придется.

* CDN. * Сделать возможным эффективное кеширование контента. * оптимизация формата (объема) контента в соответствии с каналом пользователя (GPRS, DSL, FastEthernet, etc.) * использование p2p контент-провайдерами. * локальный torrent ретрекер и torrent peer policy (retracker.local, peerpolicy.local) внутри ISP * кеширование HTTP, DNS. Возможно, кеширование/ретрекинг torrent * использовать, где это возможно, протоколы маршрутизации, позволяющие быстро реагировать на изменения маршрутов.

Чего не хватает ? # нет механизма ограничения входящего трафика и способа получения актуальной информации о загруженности промежуточных каналов и канала принимающей стороны. Это мог бы быть спец. network load discovery протокол. В этом случае необходимо будет обеспечить прозрачное прохождение через сети, не поддерживающие данный протокол. # нет способа эффективно и автоматизированно отделять критический трафик, нужны access-list'ы и списки ресурсов. Была бы полезна общедоступная база серверов и сервисов (tcp/udp + ip + port range) для построения acl'ов. Либо стандартизация номеров портов (наиболее легко реализуемо).

Чего не хватает ? # нет способа эффективно отделять кешируемый (условно статический) HTTP контент от динамического, часто используемый от редкого. При наличии такой информации ISP и транспортные операторы имели бы возможность сократить время отклика ресурсов и сэкономить каналы. А больше всех выиграют поставщики контента, поскольку работа по оптимизации доставки данных будет распределена по всей цепочке. # не хватает технологии объединения мелких пакетов, следующих в одном направлении в jumbo-фреймы. Это можно делать как по MAC-адресу следующего узла, так и по MPLS route ID.

Чего не хватает ? # не хватает интеграции p2p-протокола(ов). Это позволило бы частично переложить задачу кеширования контента на локальную сеть, и тем самым значительно ускорить скорость загрузки. Кроме того, p2p существенно менее чувствителен к потерям пакетов в сети. # а может даже отдельного CDN сервиса на уровне крупных сетей передачи данных, ISP и IX # клиентского набора ПО, работающего из коробки

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