В сфере коммуникаций контроль трафика — это процесс мониторинга сетевого трафика на предмет соответствия контракту по трафику и принятия мер по обеспечению соблюдения этого контракта. Источники трафика, которым известно о контракте по трафику, могут применять формирование трафика , чтобы гарантировать, что их выход остается в рамках контракта и, таким образом, не отбрасывается. Трафик, превышающий контракт по трафику, может быть немедленно отброшен, помечен как несоответствующий или оставлен как есть, в зависимости от административной политики и характеристик избыточного трафика.
Получатель трафика, который был подвергнут политике, будет наблюдать потерю пакетов , распределенную по периодам, когда входящий трафик превышал контракт. Если источник не ограничивает свою скорость отправки (например, с помощью механизма обратной связи), это будет продолжаться и может показаться получателю, что ошибки соединения или какое-либо другое нарушение вызывают случайную потерю пакетов. Полученный трафик, который подвергся политике в пути, обычно будет соответствовать контракту, хотя элементы в сети ниже по потоку от политики могут вносить джиттер .
При использовании надежных протоколов, таких как TCP , в отличие от UDP , отброшенные пакеты не будут подтверждены получателем и, следовательно, будут повторно отправлены отправителем, тем самым генерируя больший трафик.
Источники с механизмами управления перегрузкой на основе обратной связи (например, TCP ) обычно быстро адаптируются к статическому контролю, сходясь к скорости чуть ниже контролируемой постоянной скорости. [ необходима ссылка ]
Механизмы кооперативного контроля, такие как отбрасывание на основе пакетов [1], способствуют более быстрой конвергенции, более высокой стабильности и более эффективному разделению ресурсов. В результате конечным точкам может быть сложно отличить трафик TCP, который был просто отрегулирован, от трафика TCP, который был сформирован .
Когда принудительное отбрасывание на уровне ячеек (в отличие от того, которое достигается посредством пакетной политики) воздействие особенно сильно на более длинные пакеты. Поскольку ячейки обычно намного короче максимального размера пакета, обычные ограничители отбрасывают ячейки, которые не соблюдают границы пакетов, и, следовательно, общий объем отброшенного трафика обычно распределяется по нескольким пакетам. Почти все известные механизмы повторной сборки пакетов будут реагировать на отсутствующую ячейку, полностью отбрасывая пакет, и, следовательно, очень большое количество потерь пакетов может быть результатом умеренного превышения контролируемого контракта.
RFC 2475 описывает элементы контроля трафика, такие как счетчик и дропер . [2] Они также могут опционально включать маркер . Счетчик измеряет трафик и определяет, превышает ли он контракт (например, по GCRA ). Если он превышает контракт, некоторая политика определяет, будет ли отброшен какой-либо заданный PDU или будет ли реализована маркировка, следует ли ее маркировать и как именно. Маркировка может включать установку флага перегрузки (например, флага ECN TCP или бита CLP ATM ) или установку агрегированного показателя трафика (например, точки кода дифференцированных услуг IP ).
В простых реализациях трафик классифицируется по двум категориям или «цветам»: соответствующий (зеленый) и избыточный (красный). RFC 2697 предлагает более точную классификацию с тремя «цветами». [3] В этом документе контракт описывается с помощью трех параметров: гарантированная скорость передачи информации (CIR), гарантированный размер пакета (CBS) и избыточный размер пакета (EBS). Пакет является «зеленым», если он не превышает CBS, «желтым», если он превышает CBS, но не EBS, и «красным» в противном случае.
«Односкоростной трехцветный маркер», описанный в RFC 2697, допускает временные всплески. Всплески допускаются, когда линия была недогружена до их появления. Более предсказуемый алгоритм описан в RFC 2698, который предлагает «двухскоростной трехцветный маркер». [4] RFC 2698 определяет новый параметр, пиковую скорость передачи данных (PIR). RFC 2859 описывает «трехцветный маркер скользящего окна времени», который измеряет поток трафика и маркирует пакеты на основе измеренной пропускной способности относительно двух указанных скоростей: гарантированной целевой скорости (CTR) и пиковой целевой скорости (PTR). [5]
На оборудовании Cisco как контроль трафика, так и формирование трафика реализуются с помощью алгоритма Token Bucket . [6]
Контроль трафика в сетях ATM известен как контроль параметров использования/сети . [7] Сеть также может отбрасывать несоответствующий трафик в сети (используя контроль приоритетов). Справочным материалом для контроля трафика и формирования трафика в ATM (предоставленным Форумом ATM и ITU-T ) является алгоритм Generic Cell Rate Algorithm ( GCRA ), который описывается как версия алгоритма дырявого ведра . [8] [9]
Однако сравнение алгоритмов leaky bucket и token bucket показывает, что они просто зеркальные отражения друг друга, один добавляет содержимое bucket, когда другой его забирает, и забирает содержимое bucket, когда третий его добавляет. Следовательно, при эквивалентных параметрах реализации обоих алгоритмов будут видеть совершенно одинаковый трафик как соответствующий и не соответствующий.
Полиция трафика требует ведения числовой статистики и мер для каждого контролируемого потока трафика, но не требует внедрения или управления значительными объемами буфера пакетов. Следовательно, ее значительно проще внедрить, чем формирование трафика .
Сети, ориентированные на соединение (например, системы ATM), могут выполнять управление приемом соединения (CAC) на основе контрактов на трафик. В контексте Voice over IP (VoIP) это также известно как управление приемом вызова (CAC). [10]
Приложение, которое хочет использовать сеть с установлением соединения для передачи трафика, должно сначала запросить соединение (через сигнализацию, например Q.2931 ), что подразумевает информирование сети о характеристиках трафика и качестве обслуживания (QoS), требуемом приложением. [11] Эта информация сопоставляется с контрактом на трафик. Если запрос на соединение принят, приложению разрешается использовать сеть для передачи трафика.
Эта функция защищает сетевые ресурсы от вредоносных подключений и обеспечивает соответствие каждого подключения согласованному контракту на трафик.
Разница между CAC и контролем дорожного движения заключается в том, что CAC — это априорная проверка (до того, как произойдет передача), тогда как контроль дорожного движения — это апостериорная проверка (во время передачи).