 |
|
|
|
Доставку гарантируем: качество обслуживания в пакетных сетях
Доставку гарантируем: качество обслуживания в пакетных сетях Если вы частенько работаете по ssh удаленно, слушаете интернет-радио или просто играете в online-игры, то наверняка замечали, что получаемое от этого удовольствие прямо пропорционально нагрузке на вашу сеть. Будь то Windows Update с вашей же машины, или FlashGet с соседней, все равно приложениям надо будет «поделиться». Вот вам и «изюминка» совместного использования интернет-канала – постоянные скачки, рывки и задержки. Иными словами, ваши данные не получают соответствующего качества обслуживания (Quality of Service, QoS). И к несчастью, это так же неизбежно, как налоги… Задержки отдельных дейтаграмм на пути от отправителя к получателю являются принципиальной особенностью сетей с коммутацией пакетов (таких, как сети TCP/IP), из которых собственно и состоит Интернет. Но где есть спрос – там всегда есть предложение, и на сегодняшний день существует целый ряд технологий, позволяющих свести к минимуму влияние «врожденных» недостатков этого метода передачи данных. О них и пойдет речь в этой статье. Качество обслуживания – какой же этот «серверный» олень? Под «качественным обслуживанием» обычно понимают выполнение неких требований, предъявляемых приложением к сети, для удовлетворительной его работы. Что это за требования, зависит от типа задач, решаемых приложением. Одним важна скорость, другим – время доставки данных, третьим – и то, и другое. В общем случае, основными критериями понятия «качества обслуживания» являются:
Самый простой способ гарантировать их выполнение – избыточность, то есть если сеть будет быстрее и надежнее «чем надо», проблем наверняка не будет. Если же это невозможно, необходимо на всем пути пакетов, из конца в конец, обеспечить соответствующее качество обслуживания «вручную». Коммутация каналов – светлое прошлое QoS Строго говоря, гарантировать постоянство характеристик качества обслуживания некоего потока данных можно только в сетях с коммутацией каналов (аналоговых или ISDN). В таких сетях выделенный канал обычно используется монопольно, а его параметры известны заранее и неизменны на протяжении всего сеанса связи. Но как ни странно, это же является и основным недостатком такой техники передачи данных. Невозможность перераспределения неиспользуемых ресурсов абонентов приводит к неэффективному использованию сети в целом и значительно сказывается на ее стоимости. Таким образом, метод коммутации каналов хоть и позволяет удовлетворить требования к качеству обслуживания, но не имеет будущего в гетерогенных сетях. Сети с коммутацией пакетов лишены этого недостатка, причем лишены настолько, что в принципе не дают возможности что-либо гарантировать – качество обслуживания отдельных пакетов зависит от общей загруженности сети, которая может варьироваться в довольно больших пределах. Когда-то давно, во времена магнитных лент и бородатых инженеров, это всех устраивало, но сейчас требования приложений к качеству обслуживания существенно возросли и продолжают увеличиваться. Разумеется, тенденция не осталась незамеченной – решений, соответствующих требованиям, хватает. Вот только работают они разными способами и с разной эффективностью. Frame Relay, ATM и MPLS – дорого, но сердито Все три технологии используют метод коммутации виртуальных каналов для передачи данных и работают по принципу предварительного резервирования полосы пропускания. Но при этом используя технику коммутации пакетов, что делает их более эффективными и менее дорогостоящими в сравнении с классическими сетями коммутации каналов. Технология Frame Relay основывается на передаче кадров, но возникла как служба в сетях ISDN. За счет предварительного резервирования пропускной способности на всем пути следования дейтаграмм технология Frame Relay позволяет гарантировать основные показатели качества обслуживания – среднюю скорость передачи данных при допустимых пульсациях трафика, просто отбрасывая пакеты, поступающие слишком быстро. Правда, технология Frame Relay не очень подходит для передачи интерактивных данных, поскольку не гарантирует отсутствия задержек. Еще одним недостатком Frame Relay является низкая пропускная способность – всего 2 Мбит/с. ATM – технология асинхронного доступа (Asynchronous Transfer Mode) была создана с учетом все возрастающих потребностей приложений в пропускной способности сети, требуемом качестве обслуживания и недостатков уже существующих технологий. ATM подходит для передачи любых видов трафика, обладает мощными средствами обеспечения QoS, а диапазон поддерживаемых скоростей очень широк – от десятков мегабит до нескольких гигабит. Но универсальность этой технологии ее и погубила, сделав ее слишком сложной, дорогостоящей и… неэффективной на практике. Владельцы уже существующих сетей не спешили переходить на новое дорогое оборудование. А тем временем появились методы обеспечения QoS в (уже популярных) сетях TCP/IP и дешевый Gigabit Ethernet, способный удовлетворить даже очень серьезные требования к пропускной способности. Самая новая из рассматриваемых технологий – Multi-Protocol Label Switching (MPLS, RFC-3031) благодаря своей гибкости может использоваться для целого ряда задач. В основе ее лежит использование меток – дополнительного заголовка, которым снабжаются поступающие в сеть пакеты. Метка содержит всю необходимую MPLS-маршрутизаторам информацию для передачи пакетов, данные IP-заголовка для выбора пути дейтаграмм внутри сети не используются. Это позволяет сократить накладные расходы на анализ заголовков пакетов, сокращая таким образом задержки их продвижения и нагрузку на оборудование. Кроме того, использование техники виртуальных каналов позволяет конструировать пути прохождения пакета оптимальным образом (Traffic Engineering) и предварительно заказывать требуемую пропускную способность. Сфера применения MPLS не ограничивается задачами управления трафиком, но имеет необычайно богатые возможности для их решения. Gigabit Ethernet и стандарт 802.1Q/p – сила есть... и остальное тоже Классический Ethernet не имеет средств управления трафиком. Его наследники – FastEthernet и GigabitEthernet также не получили таких возможностей поскольку разработчики сочли усложнение этих технологий излишним ввиду больших скоростей передачи данных, им присущих. Стандарт IEEE 802.1Q, который был разработан относительно недавно и определяет основные правила построения виртуальных локальных сетей, расширяет заголовок Ethernet-кадра на 4 байта (путем уменьшения размера поля пользовательских данных), из которых три бита отводятся под приоритет кадра (802.1p). Таким образом, появляется возможность «поделить» трафик на восемь классов, с последующей соответствующей обработкой (коммутаторы и мосты, не поддерживающие 802.1p, должны «не замечать» эти биты). Ну а для настоящих любителей «быстрой езды», да еще и по «бездорожью», сегодня существует Gigabit Ethernet, работающий даже на кабеле UTP пятой категории, что делает эту технологию необычайно недорогой и эффективной. Забавно – она обладает всеми недостатками ее предшественников, но это совершенно не сказывается на темпах ее распространения. Основные причины тому – скорость и стоимость, которые покрывают и отсутствие средств обеспечения качества обслуживания, и другие недостатки технологии, такие как невозможность построения сетей с избыточными связями. Качество обслуживания в сетях TCP/IP – мечтать не вредно Стек протоколов TCP/IP до недавнего времени практически не имел средств управления трафиком. Более того, при разработке основных протоколов стека главный упор делался на максимально возможную утилизацию каналов, в результате чего даже нескольким потокам одного приложения приходится «бороться» между собой за право отправить пакет, а уж о качестве обслуживания не может идти и речи... Поле Тип Сервиса (Type Of Service, TOS) IP-пакета и является меткой, позволяющей указать желаемое качество доставки пакета, но только в общих чертах. По RFC-1349, оно состоит из трех битов IP Precedence и четырех битов, собственно указывающих на тип сервиса (последние два бита не используются и должны быть нулями). Восемь двоичных значений IP Precedence (от 000 – обычный трафик, до 111 – служебная информация маршрутизаторов) означают, что на границе сети при необходимости (высокой загруженности каналов, например) из всего потока данных дейтаграммы с меньшим значением Precedence могут быть сброшены без повторных попыток доставки по назначению. А биты типа сервиса – Low Delay, High Throughput, High Reliability и Minimize Monetary Const, – указывают на необходимость отправить пакет по каналу с наименьшей задержкой, наибольшей пропускной способностью, надежностью и наименьшей стоимостью (с финансовой точки зрения) соответственно. Использование поля TOS хотя и позволяет в некотором роде приоритезировать трафик, но не является достаточно гибким. Например, если администратору надо повысить приоритет каким-то двум видам трафика над остальными, то это в принципе возможно. Но указать при этом, что при серьезной загруженности каналов можно одним из них пожертвовать в пользу второго – уже нельзя. Кроме того, не стоит ожидать, что простая установка его в нужное значение что-либо гарантирует. Это связано с тем, что на сегодняшний день поле TOS чаще игнорируется, чем используется, а маршрутизаторы имеют право его менять по своему усмотрению. Хотя в пределах вашей сети вы вольны использовать поле TOS как считаете нужным. IntServ и DiffServ – две стороны одной медали Чтобы удовлетворить все возрастающие требования к качеству обслуживания данных в сетях TCP/IP, организацией Internet Engineering Task Force (IETF), были разработаны две модели предоставления QoS – IntServ и DiffServ. Модель IntServ (RFC-1633, RFC-2212, RFC2215) с помощью протокола сигнализации RSVP (ReSerVation Protocol, RFC-2205) позволяет «заказывать» желаемую пропускную способность на всем пути продвижения пакета, за счет чего и гарантирует качество доставки данных. Это похоже на принцип работы Frame Relay, за тем исключением, что речь идет не о виртуальном канале (ввиду его отсутствия), а о потоке данных между двумя приложениями (однозначно идентифицируемом IPадресами источника/назначения, портами и транспортным протоколом). Разумеется, все оборудование, через которое пойдут данные, должно поддерживать такую модель обслуживания. IntServ хорошо справляется со своими обязанностями (гарантируя пропускную способность), но сложность реализации и цена поддерживающего RSVP-оборудования ограничивают его применение крупными корпоративными сетями. Принципом работы DiffServ (RFC-2474, RFC-2475) является распределение трафика на классы, называемые Class of Service (CoS) и применение к этим классам неких параметров QoS. Для этого пакеты маркируются по полю TOS-заголовка IP-пакета, а затем обрабатываются желаемым образом. В технологии DiffServ поле TOS называется DS (Differentiated Services), в котором первые 6 бит используются для задания до 64 (26) классов трафика (и называются Differentiated Services Code Point, DSCP), а два последних пока не используются. Одной из ключевых особенностей DiffServ является то, что трафик маркируется в классы оборудованием по всей сети, а маршрутизаторам, осуществляющим обработку трафика, достаточно лишь распределить доступные ресурсы между ними, что обеспечивает хорошую производительность. Классификация данных – что, где, куда? Эталонная модель OSI определяет семь уровней взаимодействия систем в сетях с коммутацией пакетов, которым должны соответствовать уровни стеков коммутационных протоколов. Но поскольку многие протоколы (например, TCP/IP) были разработаны до появления модели OSI (начало 80-х годов), они соответствуют ей не полностью. Стек протоколов TCP/IP, получивший на сегодняшний день наибольшее распространение, имеет 4 уровня: прикладной, транспортный, уровень межсетевого взаимодействия и уровень сетевых интерфейсов. В принципе, классифицировать трафик для последующей обработки можно на всех четырех уровнях стека, начиная с маркировки данных на основе MAC-адресов и вплоть до попыток доставки пользователям html-страниц со словом «трафик» с наименьшей задержкой. Но первый подход не очень гибок, поскольку не позволяет «творчески» подойти к разграничению трафика, а второй – слишком требователен к системным ресурсам и не дает никаких гарантий по определению. Таким образом, самые популярные и эффективные методы классификации трафика основываются на анализе адресов источника/назначения IPпакетов и TCP-, UDP-портов. То есть речь идет о транспортном и уровне межсетевого взаимодействия. Очень важно при выборе политики обслуживания данных учитывать принципы работы транспортного протокола, доставляющего эти данные. Например, протокол TCP постоянно следит за качеством передачи данных, и потеря пакетов для него – сигнал к уменьшению скорости их передачи. Таким образом, преднамеренно уничтожая слишком быстро поступающие TCPпакеты, можно «заставить» отправителя снизить интенсивность их отправки. Это довольно грубый метод управления скоростью потока – корректнее было бы манипулировать значением поля Window TCP-пакета, или, в крайнем случае, преднамеренно задерживать квитанции о получении (ACK). Но простота реализации и неприхотливость к системным ресурсам сделали такой метод управления трафиком довольно популярным. Например, принцип умышленного уничтожения пакетов лежит в основе всех разновидностей RED (Random Early Detection) – механизма предварительного обнаружения перегрузок, который в случае превышения заданной (но еще не критичной) скорости поступления данных уничтожает пакеты, случайным образом выбранные из потока. Дальнейшим развитием этой идеи является задержка пакетов вместо уничтожения, что позволяет избежать их повторной передачи, но требует больших накладных расходов. А вот преднамеренно уничтожать пакеты протоколов, не осуществляющих контроль передачи данных (таких, как UDP) ни в коем случае нельзя, поскольку это приведет только к увеличению их потока (из-за повторной передачи), если приложение само следит за их доставкой. Исходя из этого крайне не желательно определять в один класс TCP- и UDP-потоки, ведь при «недостатке» скорости, TCP-протокол будет постоянно уменьшать интенсивность передачи, а UDP – «подгребать» под себя освободившиеся ресурсы, образовывая замкнутый круг. Средства узла для обеспечения QoS – для тех, кто на такси в булочную не ездит Все рассмотренные выше средства обеспечения качества обслуживания подразумевают использование единой технологии передачи данных на всем пути следования пакета. Более того, вы обязаны либо быть владельцем сетей, по которым передаются ваши данные, либо арендовать их – как минимум на время их использования. А что же делать, если вы – всего лишь администратор частной сети, пользователи которой, видимо, ощущая жгучий информационный голод, так и ломятся в ваш и без того узкий канал Интернет? Вася из бухгалтерии сутками напролет мультики качает, начальник в трубку жалуется, что у него «почта тормозит», а вам – так вообще давно пора «мифриловые перчи» покупать, но так «лагает», что играть невозможно… Можно ли что-то сделать в этом случае? В принципе, да, но насколько хорошо это у вас получится, зависит от нескольких факторов. Самые важные из них – является ли ваш шлюз в Интернет самым узким местом на всем пути следования пакетов, какой именно шлюз используется в вашей сети, и насколько хорошо вы себе представляете, как он работает. Если коротко – у каждого сетевого интерфейса вашего маршрутизатора есть очередь устройства (queue of a device), в которую попадают все пакеты перед отправкой их непосредственно в «железяку». Это область памяти, откуда драйвер устройства выбирает пакеты по одному и обрабатывает. Размещением пакетов в очереди занимается так называемая «дисциплина обработки очереди». И по умолчанию, это скорее всего разновидность FIFO (First In First Out, «первым пришел – первым ушел») – самый простой способ обработки пакетов, достоинствами которого являются простота и скорость, а недостатками – собственно, отсутствие методов обеспечения QoS. Все дисциплины, работающие по принципу FIFO, просто помещают приходящие пакеты в некий буфер (очередь), постепенно выводя из него пакеты, пришедшие раньше, а при его заполнении – отбрасывают новые (безвозвратно), пока под них не освободится место. Но поскольку скорость обработки данных системой обычно значительно выше, чем скорость их передачи в сеть, становится возможным использовать другие, довольно сложные алгоритмы обработки очереди, которые будут не просто помещать пакеты в очередь по одному, но и выстраивать их в определенной последовательности, отбрасывать или совершать иные действия. В результате всего этого становится возможным управлять потоками трафика по своему усмотрению (в разумных пределах). Подобно технологии DiffServ вы можете попытаться менять приоритет некоторых потоков трафика таким образом, чтобы дать преимущество тем пакетам, которым оно действительно необходимо. При этом совсем не обязательно маркировать пакеты «по порту» на коммутаторах или использовать еще какое-то дополнительное оборудование – все действия будут производиться на вашем шлюзе. Например, пакеты приложений, не требовательных к задержке (первый кандидат – smtp-данные) могут «меняться местами» в очередях устройств с пакетами более интерактивных приложений, чтобы уменьшить задержку их прохождения. Но все это реализуемо, только если ваш шлюз – действительно единственное место, где эти задержки вносятся. Если до того, как пакеты поступят на маршрутизатор (где-то в вашей сети), или после того, как покинут его (на каналах провайдера или выше), они не будут получать требуемую пропускную способность, пользы от приоритизации «на месте», конечно, не будет. Самый простой способ предотвратить это – использовать высокоскоростные технологии локальных сетей (такие как FastEthernet) и не забыть про пунктик в договоре с ISP, о гарантированной полосе пропускания. Доступные вам средства управления трафиком зависят от используемого оборудования. Смею предположить, что если вы все еще читаете эту статью, то явно не сидя на ящике от какого-то магистрального маршрутизатора, но это вовсе и не обязательно. Даже обычная машина, под управлением ОС Linux, имеет довольно богатые возможности по управлению трафиком. Другое дело – что настроить их оптимальным образом бывает довольно сложно (хотя это относится не только к Linux. SLA – доверяй, но проверяй Когда речь заходит о предоставлении услуг гарантированного качества, очень важно сначала определиться с тем, что собственно подразумевается под словами «качество» и «гарантии». Соглашение об уровне обслуживания (Service Level Agreement, SLA) как раз и является тем документом, на основании которого потребитель и провайдер заключают договор о предоставлении услуг. В нем описываются параметры QoS, методы проверки и санкции за нарушение обязательств (как поставщика услуг, так и пользователя), всяческие дополнительные услуги и соглашения. В общем случае, обычно говорится об усредненных значениях неких показателей за определенный период времени и их допустимых пульсациях. SLA может быть составлен как в индивидуальном порядке, с учетом специфики работы конкретного абонента, так и быть типовым договором, подписываемым с любым клиентом при подключении. Заключение Так или иначе, на сегодняшний день средства управления трафиком играют большую роль в качественном предоставлении телекоммуникационных услуг. Даже если сейчас вы не испытываете необходимости в приоритизации голосового трафика например, или мощностей вашей сети и оборудования достаточно для обработки всех поступающих данных, рано или поздно это изменится. Не пренебрегайте возможностью оптимизировать использование ваших каналов, и они отплатят вам сторицей. Но эффективно управлять трафиком, не имея понятия об особенностях используемых технологий и протоколов, конечно, нельзя. Поэтому, если хотите побольше узнать об управлении трафиком и качестве обслуживания, начните не с руководства по вашему маршрутизатору и попыток понять синтаксис соответствующих команд, а ознакомьтесь с форматами кадров, принципами работы основных протоколов и т. д. Удачи. Источники информации Общие сведения:
|
Сергей СикорскийКомментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
