Управление трафиком: очереди и шейпинг
Почти все приложения, использующие Интернет, работают через TCP (RFC 793) поверх IP. Протокол IP всего лишь передает пакеты, не заботясь о том, что они могут быть поврежденными, идти в неправильном порядке и т.д. К тому же IP не позволяет адресовать пакет какой-либо конкретной программе. Все эти недостатки устраняются уровнем выше – в TCP. Его характеристики следующие:
Потоковый интерфейс: Все байты информации, отправляемые одним приложением с одной стороны, придут к приложению-получателю с другой стороны в той же последовательности, в какой были посланы. Нет никакого ограничения на размер сообщенния: TCP сам разбивает по своему усмотрению информацию на пакеты.
Достоверность и надежность: Для каждого сегмента (пакета) TCP вычисляет контрольную сумму и отбрасывает его, если она неправильная. Он повторяет пересылку до тех пор, пока не получит подтверждение от получателя о правильном приеме или пока не убедится в том, что канал невозможно использовать и не выйдет время ожидания.
Мультиплексирование: TCP использует механизм портов для осуществления мультиплексирования, тем самым позволяя приложениям-отправителям адресовать данные конкретным приложениям-получателям. Например, веб-серверы, как правило, используют порт 80. Когда браузер соединяется с сервером, он также указывает и порт источника. При этом веб-страница отсылается именно ему. Обычно серверные порты имеют значение меньше 1024 (хотя и не всегда); клиентские порты обычно находятся в диапазоне от 1024 и выше.
Предотвращение перегрузки канала: Наконец, TCP имеет контроль загрузки линии, который позволяет ему определить, не теряются ли ресурсы из-за посылки большего объема трафика, чем может передавать канал.
предотвращение перегрузки канала в TCP
Кроме встроенного простого механизма самосинхронизации, основанного на «окне», ограничивающем количество пересылаемой информации, TCP имеет еще четыре дополнительных механизма, осуществляющих регулировку загрузки канала: медленный старт, предотвращение перегрузки, быстрая перепосылка и быстрое восстановление. Алгоритмы этих механизмов описаны в RFC 2001.
медленный старт
После инициализации соединения, другая сторона сообщает TCP объем данных, приготовленных в буфере. Это значение называется «предложенным размером окна». На установление соединения уходит 3 пакета: инициализирующий пакет с установленным SYN-битом, ответ от хоста-получателя с установленными битами SYN/ACK и финальный пакет от хоста-инициатора с установленным битом ACK.
После вышеописанной процедуры установления соединения локальный (и удаленный) TCP может передавать данные до тех пор, пока окно не заполнится. После этого он должен подождать подтверждений о приеме некоторой части информации. Только после их получения он может продолжить передачу. При получении от удаленного TCP слишком большого значения размера предложенного окна, локальный TCP не начинает сразу же использовать окно полностью. Это необходимо потому что на пути может встретится низкоскоростное соединение, и маршрутизатор, подключенный к нему не сможет буферизировать все накапливающиеся данные пока они не будут переданы через соединение. Таким образом, передающая сторона использует окно предотвращения перегрузки в дополнение к предложенному окну. Окно предотвращения перегрузки сначала имеет размер, равный максимальному размеру сегмента. После получения каждого уведомления о приеме данных, размер этого окна удваивается. Если размер сегмента равен 1460 байтам (что соответствует 1500-байтному пакету Ethernet минус IP- и TCP-заголовки), и приемник предлагает 8192-байтное окно, передатчик установит размер окна предотвращения перегрузки в 1460 байт, передаст первый пакет и будет ждать подтверждения. После получения первого подтверждения, размер окна увеличится до 2920 байт, и предадутся 2 пакета. После получения следующего подтверждения размер окна становится равным 5840 байтам, позволяя пересылать 4 пакета. Один пакет еще не подтвержден, поэтому пересылаются 3 пакета. После получения подтверждения, размер окна увеличится до предложенного.
защита от перегрузки
Защита от перегрузки предлагает другую переменную: границу медленного старта (slow start threshold size (ssthresh)). При инициализации соединения значение ssthresh устанавливается равным 65535 байтам (максимально возможное предложенное окно). Если информация не теряется, алгоритм затяжного пуска будет увеличивать размер окна до тех пор, пока он не станет максимальным. Если же TCP получает пришедшее не по порядку подтверждение, в силу вступает механизм предотвращения перегрузки. В данном случае под пришедшим не по порядку подтверждением подразумевается подтверждение о приеме информации, которая уже была передана, и подтверждение о ее приеме было получено. Это происходит при потере пакета: принимающий TCP отправляет передающему подтверждение на информацию до потерянного пакета, говоря примерно следующее: « Я все еще жду информацию, следующую за тем, что я сейчас подтверждаю» Такая схема необходима из-за того, что подтверждения TCP кумулятивны, т.е. нельзя сказать: «Я получил байты 1000-1499, но потерял 500-999»
После получения повторяющегося подтверждения, передающий TCP принимает неподтвержденную информацию за трагически погибшую из-за перегрузки канала. При этом ssthresh и размер окна предотвращения перегрузки устанавливаются равными половине текущего размера окна до тех пор, пока он равен как минимум двум максимальным размерам сегмента. После этого, окну разрешается увеличиваться очень медленно, чтобы сразу же не вернуться к состоянию перегрузки. Если передающий TCP длительное время не получает никаких подтверждений, он определяет эту ситуацию как массивную перегрузку и инициирует механизм затяжного пуска, понижая при этом значение ssthresh. Таким образом, до тех пор, пока размер окна предотвращения перегрузки меньше или равен значению ssthresh, используется затяжной пуск (окно удваивается после каждого подтверждения), а после него – предотвращение перегрузки (окно медленно увеличивается).
быстрая перепослылка и восстановление
Если TCP получает подряд три идущих не по порядку подтверждения, он решает, что один пакет был потерян (одно или два неправильных подтверждения воспринимаются им как изменение очередности передачи пакетов в сети). После этого он пересылает пакет заново, не дожидаясь тайм-аута. Значение ssthresh устанавливается так же, как и при защите от перегрузки, но размер «перегрузочного» окна принимается равным ssthresh плюс три максимальных сегмента (размер равен количеству информации, успешно полученной приемником, определенному по идущим не по порядку подтверждениям). В результате TCP замедляется, но не сильно, так как при этом через него все еще проходит достаточно большой объем данных.
влияние потери пакетов и задержек на работу TCP
В результате работы вышеописанных механизмов TCP сильно замедляется при потере большого числа пакетов. Ситуация ухудшается, когда время прохождения пакетов туда и обратно (RTT) большое из-за того, что использование окон ограничивает пропускную способность TCP до размера окна, деленного на время прохождения пакетов туда и обратно. Это означает, что даже с максимальным размером окна в 64 кб (без включения высокопроизводительных расширений TCP), производительность TCP на трансконтинентальной линии с задержкой прохождения пакетов туда и обратно в 70 мс не превысит 900 кбит/с. При потере пакета это значение уменьшается вдвое и возвращается к назад только после сотен успешных подтверждений. Таким образом, даже случайная потеря пакета может существенно снизить эффективность использования пропускной способности территориально протяженного соединения TCP-сессией.
Поведение двух основных категорий не-TCP приложений в условиях потери пакетов различно. К первой категории можно отнести мультимедиа (потоковое аудио и видео), ко второй – приложения, основанные на небольших транзакциях, не требующих большого количества служебной информации вроде DNS. Как правило, потоковые аудио и видео не слишком чувствительны к потере пакетов, тем не менее, от нее несколько пострадает качество. Что же касается вещей вроде разрешения имен DNS, то потеря пакетов существенно замедлит индивидуальные транзакции (для них наступает тайм-аут и требуется повторение). Из-за того, что не-TCP приложения не имеют адекватной реакции на потерю пакетов, часто бывает так, что они увеличивают перегрузку канала, продолжая посылать больший объем трафика, чем может передавать соединение.
Несмотря на то, что некоторые потерянные пакеты – результат ошибок в битах на физическом уровне или временных проблем с маршрутизацией, основная причина потерь – перегрузка канала чрезмерным трафиком. Рассмотрим ситуацию, когда, например, скорость подключения маршрутизатора к популярному направлению равна 155 Мбит/с, а для этого направления со скоростью 200 Мбит/с приходит трафик. Первое, что сделает маршрутизатор – поставит пакеты, которые невозможно переслать немедленно, в очередь. IP-трафику свойственны кратковременные вспышки активности длительностью от секунды до нескольких секунд. Очередь сглаживает подобные неоднородности. Ценой этого являются некоторые дополнительные задержки пакетов, но, по крайней мере, пакеты не теряются. Тем не менее, если чрезмерно интенсивный трафик передается длительное время, очередь может переполниться. При этом маршрутизатору ничего не остается, кроме как отбрасывать все входящие пакеты, до тех пор, пока очередь переполнена. Это называется «отбрасывать хвост» («tail drop»). Механизмы защиты от перегрузки разработаны именно для этой ситуации, таким образом, в данном случае все TCP-сессии замедлятся, при этом перегрузка должна исчезнуть. Однако может возникнуть более сложный случай перегрузки, когда трафик представляет собой множество коротких TCP-сессий (например, web или email). В этом случае количества инициализирующих пакетов (в это время TCP еще находится режиме затяжного пуска) может хватить, чтобы вызвать перегрузку. Не-TCP приложения также легко могут вызвать перегрузку, так как они не обладают механизмами защиты от нее.
образование очередей
Образование очередей происходит только в случае, когда интерфейс слишком занят. Если же он свободен, то пакеты передаются без всякой дополнительной обработки. Все стандартные очереди работают по принципу FIFO (first in, first out): пакет, который пришел раньше всех, будет передан первым и т.д. Если очередь заполнена до отказа и приходят новые пакеты, то происходит «отброс хвоста». Более изощренные способы организации очередей часто используют несколько очередей. Пакеты классифицируются в соответствии с потребностями пользователя и затем сортируются по соответствующим очередям. Затем, при освобождении интерфейса, с помощью специального алгоритма выбирается очередь, пакет из которой будет отправлен. Например, маршрутизаторы Cisco поддерживают несколько стратегий организации очередей: FIFO, WQF, RED, по приоритету, произвольные. Следует отметить, что все специальные методики организации очередей дают эффект только в случаях, когда невозможно немедленно отправить пакет через интерфейс. Если же интерфейс свободен и в очереди не находится пакетов, то новый пакет пересылается сразу же.
FIFO
Стратегия FIFO – самая простая. При ее использовании пакеты передаются в том же порядке, в каком приходят. Как правило, ее применяют на быстрых интерфейсах. Чтобы ее включить, необходимо отключить все остальные механизмы организации очередей:
!
interface Serial0
no fair-queue
!
взвешенные очереди (Weighted fair queuing, WQF)
Механизмы, использующие очереди с весами, пытаются разделить пропускную способность между несколькими потоками данных (обычно это TCP-сессии), таким образом, чтобы потоки с большой активностью не захватывали монопольно соединение. Как правило, WQF применяется для низкоскоростных интерфейсов. Включить WQF можно следующим образом:
!
interface Serial0
fair-queue
!
опознание перегрузки (Random early detect, RED)
При переполнении очереди RED начинает отбрасывать пакеты для предотвращения перегрузки канала. Больше всего RED обращает внимания на сессии с наибольшим объемом трафика, поэтому именно они замедляются в первую очередь. При использовании опознания перегрузки с весами (Weighted random early detect), в первую очередь будут отбрасываться пакеты с наименьшим приоритетом. В отличие от WFQ, очередей с приоритетами и произвольных очередей, RED не требовательна к процессорному времени и может применяться на высокоскоростных интерфейсах. Она нуждается в размере очереди на передачу большем, чем стандартные 40 пакетов, чтобы иметь возможность начать отброс пакетов заранее и избежать «отброса хвоста».
!
interface Ethernet0
random-detect
hold-queue 200 out
!
Кстати, в RFC 2309 проблемная группа проектирования Интернет (IETF) рекомендует использовать RED в Интернет-маршрутизаторах.
очереди с приоритетами
При использовании этой методики, трафик классифицируется по приоритетам. Приоритет может быть высоким, нормальным, средним и низким. Если в потоке имеется высокоприоритетный трафик, то он передается в первую очередь, затем передается трафик со средним приоритетом и т.д. Это может замедлить низкоприоритетный трафик или даже совсем остановить его в случае, когда высокоприоритетный трафик забирает всю пропускную способность канала. В нижеописанном примере показано, как включить очереди с приоритетами и установить средний приоритет для DNS и низкий для FTP.
!
interface Serial0
priority-group 1
!
priority-list 1 protocol ip medium udp domain
priority-list 1 protocol ip low tcp ftp
priority-list 1 protocol ip low tcp ftp-data
!
произвольные очереди
В данном случае применяются несколько очередей. Для каждой очереди можно задать количество информации, которое должно быть передано из нее перед тем, как начнется передача из следующей очереди. Эта методика позволяет гарантировать некоторое минимальное значение пропускной способности, отводимое под каждый вид трафика. В то же время, незадействованная пропускная способность доступна другим видам трафика. В следующем примере под WWW-трафик отводится 75% пропускной способности, 5%-- DNS и 20% -- остальным.
!
interface Serial0
custom-queue-list 1
!
queue-list 1 protocol ip 1 tcp www
queue-list 1 protocol ip 2 udp domain
queue-list 1 default 3
queue-list 1 queue 1 byte-count 7500
queue-list 1 queue 2 byte-count 500
queue-list 1 queue 3 byte-count 2000
!
В данном случае если, например, WWW-трафику маловато 75% пропускной способности и остальные виды не-WWW/DNS -трафика потребляют только 5%, то оставшиеся 15% пропускной способности отдаются WWW. Таким образом, пропускная способность не тратится зря.
шейпинг и ограничение скорости трафика
При применении шейпинга, происходит подсчет трафика для конкретного интерфейса. Шейпинг может применяться ко всему трафику или же только к тому, который удовлетворяет какому-либо списку. Это происходит не зависимо от того, свободен ли интерфейс, или в очереди находятся пакеты. Когда трафик достигает некоторого заданного пользователем значения, следующие поступающие пакеты становятся в очередь и задерживаются. Таким образом, потребляемая пропускная способность ограничивается на настраиваемое значение.
Ограничение скорости, иногда называемое также ограничением трафика похоже на шейпинг. Отличие заключается в том, что чрезмерный трафик обрабатывается отдельно от обычного, по правилам, настраиваемым пользователем. Наиболее распространенный способ обработки лишнего трафика – отброс его, но существуют и другие способы, например, уменьшение значения поля приоритета в IP-заголовке. В следующем примере включается шейпинг для одного интерфейса и ограничение скорости для другого.
!
interface Serial0
traffic-shape rate 128000 8000 8000 1000
!
interface Serial1
rate-limit output 128000 8000 8000 conform-action transmit exceed-action drop
!
Шейпинг и ограничение скорости обычно применяются, когда необходимо ограничить доступную клиенту пропускную способность, если, например, оплачена низкая, а подключение производится по интерфейсу, имеющему высокую пропускную способность. Однако в данном случае лучше не применять ограничение скорости, так как оно отбрасывает много пакетов, заставляя TCP думать, что линия перегружена. Посему он замедляется, но спустя некоторое время опять пытается ускорить темп, вызывая тем самым очередную потерю пакетов. Шейпинг же всего лишь замедляет пакеты, так что через некоторое время TCP адаптируется к доступной пропускной способности. В следующем примере показана производительность FTP на соединении с применением ограничения скорости до 128к.
ftp>put testfile
local: testfile remote: testfile
150 Opening BINARY mode data connection for 'testfile'.
100% |**********************************| 373 KB 00:00 ETA
226 Transfer complete.
382332 bytes sent in 35.61 seconds (10.48 KB/s)
Как видно, пропускная способность для FTP составила 84 кбит/с, т.е. примерно две трети от доступной. Как будет вести себя та же передача, на том же соединении, но с применением шейпинга, показано ниже:
ftp>put testfile
local: testfile remote: testfile
150 Opening BINARY mode data connection for 'testfile'.
100% |**********************************| 373 KB 00:00 ETA
226 Transfer complete.
382332 bytes sent in 24.73 seconds (15.10 KB/s)
На сей раз производительность составила 121 кбит/с, что всего лишь на несколько процентов меньше доступной, учитывая служебную информацию TCP, IP и соединения.
Кроме отбивания атак типа «отказ в обслуживании», ограничение скорости имеет еще одно потенциальное применение, так как в отличие от шейпинга и других механизмов организации очередей может быть применено и к входящему трафику. Когда провайдер договаривается с клиентом о некоторой пропускной способности, он может использовать шейпинг для ограничения доступной клиенту входящей пропускной способности. Но так как невозможно применить шейпинг к входящим в интерфейс пакетам, на клиента возлагается задача шейпинга его исходящего трафика. Для того чтобы убедиться, что клиент не превышает оговоренный лимит трафика, провайдер может дополнительно применить ограничение скорости на входящий трафик.
Iljitsch van Beijnum, перевод Дмитрия Герусса.
Сетевые решения. Статья была опубликована в номере 01 за 2003 год в рубрике технологии
