В нашем примере MASK=0xFC и SHIFT=2.

Возвращаемое значение будет соответствовать фильтру внутренней qdisc (в примере, идентификатор 2:0). Если фильтр с заданным идентификатором найден, то условия фильтра будут проверены (в случае, если фильтр включает в себя эти условия) и будет возвращен classid (в нашем примере classid 2:1), который далее будет записан в skb->tc_index. Если фильтр не будет найден, то результат будет зависеть от объявления флага fall_through. Если объявление fall_through присутствует, то его значение будет воспринято как classid. В противном случае продолжится просмотр остальных фильтров. Будьте предельно внимательны, при использовании флага fall_through — его использование рекомендуется только в том случае, когда значение skb->tc_index и идентификаторы классов ссвязаны простыми (в смысле несложными) отношениями.

И последние два параметра, которые мы опишем, это hash и pass_on. Первый из них определяет размер хеш-таблицы. Pass_on — означает, что если не будет найден classid, равный результату этого фильтра, то необходимо попробовать применить следующий фильтр. Действие по-умолчанию — fall_through (см. следующую таблицу).

В заключение посмотрим — какие значения параметров TCINDEX допустимы:

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

Я настоятельно рекомендую вам внимательно просмотреть все примеры DiffServ, включаемые в дистрибутив iproute2. Со своей стороны я обещаю, что дополню этот текст, как только найду время. Все, что я здесь описал — есть результат длительных экспериментов. Я буду весьма признателен, если вы сообщите мне об обнаруженных ошибках.

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

Поскольку tc-фильтры имеют полную реализацию Token Bucket Filter, то они так же могут ограничивать входящий трафик на основе "функций оценки" (estimators). Это позволяет выстраивать эффективную политику обслуживания входящего трафика, до того как он попадет "в руки" стека протоколов IP.

Входные дисциплины, сами по себе не требуют каких-либо параметров. Пример создания входной дисциплины:

Кроме входящей дисциплины вы можете добавлять к устройству и исходящие дисциплины.

Примеры использования входящей дисциплины вы найдете в главе Решебник.

Этот раздел служит в качестве введения в организацию очередей в магистральных сетях, которые зачастую имеют полосу пропускания более 100 мегабит, что требует иного подхода чем в случае с домашним ADSL-модемом.

Нередко на маршрутизаторах в Интернет возникает так называемая проблема tail drops – отсечения конца очереди. Когда очередь полна, ни один вновь поступивший пакет туда уже не помещается, а потому отбрасывается. Такое управление очередью приводит к повторной синхронизации параметров соединения. После синхронизации TCP сразу посылает столько пакетов, сколько допускает размер окна подтверждения. Подобный всплеск нагрузки опять приводит к отсечению конца очереди, что опять порождает необходимость повторной синхронизации… Такое хождение по кругу может продолжаться довольно долго.

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

Проблема отсечения хвоста очереди с каждым днем становится все более неприятной. Для предотвращения перегрузок, ядро Linux предоставляет в наше распоряжение механизм RED, сокращенно от Random Early Detect (Случайное Раннее Обнаружение), которое иногда называется как Random Early Drop (Случайное Раннее Отсечение), последнее определение более точно описывает принцип работы.

RED — это не панацея от всех бед, но позволяет более "справедливо" разделить канал между TCP-соединениями.

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