Базы данныхИнтернетКомпьютерыОперационные системыПрограммированиеСетиСвязьРазное
Поиск по сайту:
Подпишись на рассылку:

Назад в раздел

Сети передачи данных: управление скоростью

div.main {margin-left: 20pt; margin-right: 20pt} Сети передачи данных: управление скоростью Максим КУЛЬГИН В прошлом году наш журнал опубликовал (см. N 10) целый ряд материалов, посвященных широко обсуждаемой теме передачи голоса в сетях IP (voice over IP, VoIP). Насколько успешной окажется технология VoIP? Все зависит от того, до какой степени удастся обеспечить управление потоками трафика, а в первую очередь — насколько эффективными окажутся механизмы обеспечения качества обслуживания в сетях IP. В предлагаемой вашему вниманию статье подробно описываются возможные подходы к управлению скоростью передачи данных в таких сетях. Рассказывается как о сути самой проблемы, связанной с характером используемых протоколов, так и о существующих путях ее решения.

Качеству обслуживания (QoS — Quality of Service) сегодня по праву отводится все более значимая роль в многофункциональных сетях. Эта технология призвана обеспечить платформу, необходимую для работы современных приложений, которые предъявляют гораздо более жесткие требования к ширине полосы пропускания и времени задержек прохождения информации по сети. Кроме того, без QoS невозможна разработка соглашений об уровне сервиса (SLA, Service Level Agreement), определяющих стоимость различных услуг сети передачи данных.

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

Следующим шагом на пути к реализации QoS стала разработка механизма явного управления скоростью трафика (ECR, Explicit Rate Control), который в течение ряда лет довольно активно используется в сетях ATM. В последнее время все чаще высказывается мнение, что ECR можно применять также со стеком протоколов TCP/IP. Этот механизм способен работать автономно либо совместно с существующими алгоритмами организации очередей. Основные задачи, которые он позволяет решать, — рост производительности каналов связи, уменьшение времени ожидания реакции сети и увеличение степени детализации сетевого управления за счет контроля за отдельными потоками трафика.

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

Именно поэтому задача реализации ECR в реальных сетях представляется весьма актуальной. Первыми "кандидатами" на его внедрение являются сети, транспортирующие критически важную информацию в условиях ограничения полосы пропускания, а также информационные системы, использующие для передачи такого трафика внешние сети ATM, frame relay или IP.

Актуальность QoS

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

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

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

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

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

Трафик приложений

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

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

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

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

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

Проблемы протоколов TCP и UDP

Проблемы, связанные с применением протоколов, обусловлены главным образом тем, что во времена их разработки разброс скоростей сетевых каналов, встречающихся при передаче трафика от одного конца маршрута до другого, был не столь велик, как сегодня. Например, просто не могли возникнуть такие проблемы, как буферизация трафика при переходе между сетями 100 Мбит/с Fast Ethernet через канал связи со скоростью 56 кбит/с. Протоколы обычно разрабатывались для удовлетворения требований какого-либо потока данных без учета условий работы сети в целом.

TCP

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

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

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

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

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

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

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

Одно из дополнений TCP — алгоритм "Медленный старт" (Slow Start). Он предусматривает постепенное повышение скорости передачи до возникновения перегрузки сети, которая определяется либо по началу потерь пакетов, либо по достижению оборудованием адресата максимальной скорости работы. Такая схема работы снижает вероятность потерь пакетов в перегруженных сетях, но не разрешает основную проблему протокола TCP, т. е. не устраняет тенденцию к захвату максимума возможной полосы пропускания.

Другой алгоритм, "Предотвращение перегрузки" (Congestion Avoidance), который работает вместе с алгоритмом "Медленный старт", обеспечивает прохождение пакетов к получателю без потерь. В случае использования этого алгоритма при потере пакетов протокол TCP сразу снижает скорость передачи; затем скорость медленно увеличивается до тех пор, пока вновь не начнутся потери (снижение скорости передачи не предусмотрено). Хотя модифицированный протокол TCP по-прежнему пытается "взять" от ширины пропускания все что можно, "захват" осуществляется более мягко по отношению к другим приложениям.

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

UDP

Протокол UDP предназначен для доставки дейтаграмм поверх IP. Он не предусматривает предварительной установки виртуального соединения, повторной передачи и переупорядочивания пакетов; отсутствуют и встроенные функции управления потоком данных. Выполнение всех перечисленных действий возлагается на приложения.

Протокол UDP обычно применяют приложения, работающие с мультимедийной информацией в масштабе реального времени. Поскольку такие приложения не могут тратить время на повторные передачи, они используют функцию восстановления ошибок протокола TCP. Это вызывает дополнительные трудности, поскольку в таком случае не может быть обработан многоадресный трафик, а алгоритмы "Медленный старт" и "Предотвращение перегрузки" становятся ощутимым препятствием для работы трафика в масштабе реального времени. Поэтому для передачи мультимедийной информации под управлением протокола UDP обычно служит протокол RTP, который не исправляет ошибок и не участвует в управлении потоком данных (хотя и имеет механизм обратной связи на базе протокола RTCP, необходимый для уменьшения скорости передачи при обнаружении ошибок).

Зависимость протокола UDP от протоколов более высокого уровня типа RTP/RTCP иногда приводит к нежелательным последствиям. Дело в том, что эти протоколы часто ведут себя как протокол TCP, т. е. "поглощают" всю наличествующую полосу пропускания.

Протоколы управления потоком данных

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

Трафик, проходящий от высокоскоростной к низкоскоростной зоне сети, должен быть обработан устройством, расположенным на границе этих зон. Если трафик прибывает слишком быстро, граничное устройство сообщает источнику, что скорость велика и ее необходимо уменьшить. Данная идея и была заложена в сообщение "подавление отправителя" (Source Quench) протокола ICMP, которое теперь практически не применяется (такая схема оказалась слишком грубой и неэффективной). Без использования специальных механизмов сигнализации в IP-сети маршрутизаторы и коммутаторы вынуждены или отказываться от трафика, который "не вписывается" в канал с малым быстродействием, или пытаться временно буферизировать его.

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

Появились новые методы, реализуемые, например, протоколом резервирования ресурсов (RSVP), которые были разработаны для того, чтобы заранее запрашивать необходимые объем буферной памяти и ширину полосы пропускания, за счет чего для определенных потоков трафика уменьшается вероятность переполнения буферного пространства и потерь пакетов. Однако такие методы не нашли применения в крупномасштабных сетях, поскольку имеют довольно много ограничений. В сентябре 1997 г. вышел документ RFC (ftp://ds.internic.net/rfc/rfc2208.txt), где, в частности, говорится: "...проблемы с масштабируемостью делают невозможным в настоящее время развертывание протокола RSVP в широкополосных сетях".

Организация очередей

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

Самый простой из таких алгоритмов — "первым пришел — первым ушел" (FIFO, first in — first out). Однако с ним связаны и самые большие сложности. Здесь используется только одна выходная очередь для каждого порта, в связи с чем возникают две основные проблемы: первоочередной интерактивный трафик легко блокируется идущими следом данными большого объема, а переполнение очереди может вызвать потерю пакетов всего трафика, а не только "виновного" в возникновении этой ситуации.

Вторая проблема обуславливает появление "волн трафика". При переполнении очереди пакеты всех потоков могут теряться (происходит так называемый "отброс хвоста"). Это приводит к одновременному повторению передачи всех проходящих потоков ТСР, а поскольку такая передача инициируется различными потоками трафика, алгоритмы "Медленный старт" и "Предотвращение перегрузки" не помогают. Возникают синхронизированные волны трафика, усугубляющие переполнение очереди в маршрутизаторе.

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

Очереди с приоритетами (потоки трафика с разными приоритетами помещаются в разные выходные очереди) были разработаны для того, чтобы преодолеть первую из основных проблем с очередями FIFO. При этом первоочередные потоки трафика должно быть специально обозначены, например с помощью поля "Тип сервиса" в заголовке дейтаграммы IPv4. Кроме того, сетевой администратор может задать приоритет трафика, идущего к определенным сетевым адресам или портам. Ни один пакет из обычной очереди не может быть передан, если есть более приоритетные очереди (рис. 1).


Рис. 1. Приоритеты пакетов в очередях маршрутизатора

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

Очереди с приоритетами совершенствовались с помощью методов, направленных на получение всеми очередями определенной доли полосы пропускания. Метод справедливой организации очереди (Fair Queuing — FQ) гарантирует, например, что трафик может своевременно проходить через маршрутизаторы, не блокируя полосу пропускания для других пользователей.

Метод взвешенной справедливой организации очереди (Weighted Fair Queuing — WFQ) является усовершенствованием FQ. Потоки в рамках одного приоритета подразделяются на потоки с высокой и низкой потребностью в ширине полосы пропускания. Потоки с низкой потребностью в ширине полосы пропускания получают более высокий приоритет, при этом время ответа для них значительно сокращается.

Проблему "отброса хвоста" помогает решить RED (Random Early Detection), алгоритм случайного раннего обнаружения (см.: Сети, 1998, N 9, с. 28). Он контролирует размер выходной очереди и отбрасывает пакеты в заранее оговоренных потоках трафика, прежде чем произойдет переполнение очереди. Такая "потеря" пакетов приводит к срабатыванию механизмов определения перегрузки протокола TCP, вследствие чего интенсивность потока временно уменьшается. Несколько потоков, вынужденных производить повторную передачу и "включать" алгоритм "Медленный старт", приносятся в жертву, зато удается избежать возникновения глобальных волн синхронизации.

Следует отметить, что организация очереди только частично решает вопрос обеспечения QoS в IP-сетях. Управлять такими очередями бывает очень трудно, если существуют сегменты сети, недоступные для прямого управления.

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

Явное управление скоростью

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

ERC первоначально использовался в старых протоколах, которые поддерживали передачу критически важного трафика по сложным сетям (например, IBM SNA). Технология АТМ — более современный пример успешной реализации метода явного управления скоростью. В службе ABR, которая, например, используется для поддержки работы стека протоколов TCP/IP, предусматривается реализация механизма ERC с помощью посылки специальных RM-ячеек.

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

В случае протокола TCP метод ECR может применяться для поддержания уровня QoS, гарантирующего определенные скорости. При этом снижается острота проблемы "захвата" всей доступной полосы пропускания потоками данных под ТСР. Метод ECR также помогает управлять трафиком UDP (хотя и не столь эффективно, как TCP), "приглаживая" его и не позволяя низкоприоритетному трафику TCP мешать прохождению первоочередного UDP-трафика при совместном использовании канала связи.

Управление скоростью передачи под TCP основано на том, что первоначально установленное окно TCP можно увеличивать или уменьшать в любое время. Необходимая для корректировки информация включается в каждое сообщение подтверждения TCP (ack-nowledgement — ACK).

Промежуточный сетевой узел точно измеряет время прохождения пакета в обоих направлениях и вычисляет оптимальную непрерывную скорость трафика из конца в конец соединения. Этот узел корректирует информацию о размере окна в TCP-подтверждениях и тщательно выбирает интервалы между данными подтверждения для управления потоком трафика. Если, например, приемная станция указала размер буферной памяти 8000 байт, то промежуточный узел способен разложить его на четыре 2000-байтных окна, сгенерировав три дополнительных TCP-подтверждения. Разбиение предназначено для снижения объема информации, единовременно посылаемой отправителем и, соответственно, для снижения нагрузки на сеть.


Рис. 2. Корректировка размера буферной памяти

Затем промежуточный узел замеряет промежуток времени между моментом отправления информации и моментом получения подтверждения. Полученная информация используется в целях поддержания оптимальной скорости трафика (рис. 2). Такая схема работы совместима со всеми реализациями протоколов TCP и не требует использования алгоритмов "Медленный старт" и "Предотвращение перегрузки".

Алгоритм ECR способен значительно повысить эффективность работы под TCP, поскольку он фактически устраняет нерациональное использование пропускной способности при повторных передачах, вызванных буферным переполнением. Кроме того, устраняются непредсказуемые задержки трафика и возможность неэффективной работы сети, вызванные применением алгоритмов "Медленный старт" и "Предотвращение перегрузки". Благодаря стабилизации потока трафика, управляемого по всему пути его следования, уменьшается длина очередей и упрощается задача управления очередями в маршрутизаторе.

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

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

И все же механизм управления скоростью в состоянии помочь и в этом случае. Промежуточный узел, в котором реализован алгоритм ECR для протокола UDP, может корректировать скорость передачи данных для выравнивания потока трафика, используя одну из реализаций стандартного алгоритма буферизации "дырявое ведро", который применяется в технологии АТМ.

Данный алгоритм выполняется следующим образом. Промежуточный узел имеет область памяти с организованной "утечкой"; по мере поступления пакетов они постоянно добавляются в эту область, но величина "утечки" остается неизменной. Алгоритм ECR для протокола UDP улучшает работу существующих схем буферизации в маршрутизаторах точно так же, как это происходит для протокола ТСР: "приглаженный" поток намного более прост в управлении, очереди в маршрутизаторах короче, и буферная память обычно не переполняется.



  • Главная
  • Новости
  • Новинки
  • Скрипты
  • Форум
  • Ссылки
  • О сайте




  • Emanual.ru – это сайт, посвящённый всем значимым событиям в IT-индустрии: новейшие разработки, уникальные методы и горячие новости! Тонны информации, полезной как для обычных пользователей, так и для самых продвинутых программистов! Интересные обсуждения на актуальные темы и огромная аудитория, которая может быть интересна широкому кругу рекламодателей. У нас вы узнаете всё о компьютерах, базах данных, операционных системах, сетях, инфраструктурах, связях и программированию на популярных языках!
     Copyright © 2001-2024
    Реклама на сайте