ToS

Насколько я понимаю, ToS в ssh используется, чтобы шейперы могли отличать sftp и scp от обычного удаленного шелла (ибо соединение шифрованное, и его никакой l7-filter не возьмет).

Что касается всех остальных прог - у вас есть iptables. Например,
# Запросы DNS
iptables -t mangle -A POSTROUTING -p udp --sport 53 -j TOS --set-tos Minimize-Delay
iptables -t mangle -A POSTROUTING -p tcp --sport 53 -j TOS --set-tos Minimize-Delay
# Исходящие пакеты FTP control
iptables -t mangle -A POSTROUTING -p tcp --sport 21 -j TOS --set-tos Minimize-Delay
# FTP data active mode
iptables -t mangle -A POSTROUTING -p tcp --sport 20 -j TOS --set-tos Maximize-Throughput
# FTP data passive mode
iptables -t mangle -A POSTROUTING -m helper --helper ftp -j TOS --set-tos Maximize-Throughput
и т.д.

Но обычно для этого используются возможности MARK/CONNMARK и tc, ибо они дают бОльшую гибкость настройки.

> Я просто удивлён! Зачем тогда все эти эдвансед роутинг и т.п. если базовые приложения не маркируют свои же пакеты должным образом

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

ИМХО, когда задумывался интернет, считалось, что host может указывать маршрутизатору что делать, для этого ввели ToS и Record Route. А сейчас считается, что маршрутизатор сам во всём разберётся. Выставленные приложением биты ToS либо игнорируются, либо изменяются (перекрашеваются).

винда-то всё равно выставляет себе высший tos, поэтому его придерживаться бессмысленно

> винда-то всё равно выставляет себе высший tos, поэтому его придерживаться бессмысленно

Вы это на форуме где-то прочитали или сами проверили? См. первый пост. В сети были и виндавс машины.

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

Вообще-то имеют. Идея такова, что основываясь на метках ToS разумно маршрутизировать через быстрый-дорогой/медленный дешевый каналы? Как отлавливать трафик VoIP, например, если приложение не маркирует эти пакеты самостоятельно?

voip отлавливается на основе well known ports и анализа пакетов.
это происходит на пограничным маршрутизаторах, такое решение более масштабируемое и управляемое, нежели маркировка на конечных устройствах.

Не понятно, почему вы считаете, что роутеры должны выполнять подобные задачи? Чем проще будет конфигурация роутера - тем лучше. Ведь для VoIP трафика крайне желательны минимальные задеркжи прохождения пакетов и большая надежность их доставки. Чтоб это хорошо прошло через облако под названием internet было бы замечательно поставить соответствующие метки ToS в пакетах (которые по-умолчанию linux-системами учитываются дисциплиной pfifo_fast). А по-вашему пограничный роутер уже должен выполнять не свою работу для обеспечения т.н. triple play.

Метки ToS в пакетах разве как-то уменьнают масштабируемость и управляемость?

все просто - большинство программистов игнорируют проблемы сети, они часто и разнизу между tcp и udp знают как "тцп сложнее, но дает гарантию доставки". дырявые абстракции. а сетевики к этому привыкли, и решают проблемы как могут, тоесть на маршрутизаторе. это продолжается уже столько лет, что все как-то и забыли, какова была изначальная идея. ну и да, в современном мире сложно доверять пакетам, которые пришли незнамо от кого.

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

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

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

Провайдер, ИМХО, всегда игнорирует ToS приходящих к нему пакетов, ведь обработка ToS это загрузка маршрутизатора, а зачем она ему, если денег ему за это не заплатят.

>Чем проще будет конфигурация роутера - тем лучше.

Простых конфигураций не бывает. С VoIP там вобще все сложно, напрмер, есть канал 128 кБит. Если под каждый VoIP я даю 4 кБит, так по хорошему нужно следить за количеством соединений и не давать установится больше 30 соединений, а то они будут мешать друг-другу и по всем будет плохое качество...

> Провайдер, ИМХО, всегда игнорирует ToS приходящих к нему пакетов, ведь обработка ToS это загрузка маршрутизатора, а зачем она ему, если денег ему за это не заплатят.

Думается, что не столько поэтому, сколько потому, что это может привести к головной боли из-за того, что кто-то

> себе накрутит, начитавшись шурналов типа ксакеп.

Я проверил, от домашнего компа до рабочего биты тос по ссш не доходят. Где-то по пути обнуляются (от дома к работе) или еще интересней - выставляется старший бит, а остальные обнуляются (от работы домой). Ну, это уже неплохо, хотя это и не заказывали. В общем, хлам. Реально в интернете на данный момент (во всяком случае, в украинском) говорить о т.н. triple play - нет смысла. Голосовые данные будут перебиваться www и торрент трафиком, потому что стрёмно доверять пакетам неизвестного происхождения.

>Думается, что не столько поэтому, сколько потому, что это может привести к головной боли

Да, это на первом месте, что насколько я знаю, часто и провайдера Cisco достаточно сильно загружены, и там не все шоколадно, когда нагрузка большая. И ещё её увеличивать обычно желания нет.