> Рассмотрим аксиому и "следствия".
>> 1)
>> входящий ВНЕШНИЙ трафик можно ПОПЫТАТЬСЯ ограничить ТОЛЬКО используя возможности сетевых
>> протоколов. над входящим трафиком Вы никакого контроля не имеете и можете
>> только попросить передающую сторону уменьшить скорость отправки данных.
> Так какие там средства управления скоростью потока предоставляет IP-протокол?никакую
> Как в общем случае попросить уменьшить скорость отправки данных по UDP?
спросите у разработчиков uTorrent - они видимо ответ нашли)
> Какими средствами Linux, не внося задержку в прохождение сквозь роутер входящих пакетов
> потока (и, естественно, без их дропа), попросить уменьшить скорость отправки данных
> по TCP?
окно.
и не факт , что Ваше пожелание будет адекватно обработано другой стороной (примеров в моей практике - туча).
Итого:
- Linux тут вообще по боку, как любая друга ОС.
- ТСП разве не сетеовй протокол (транспорт - да, но тем не менее)?
=> с чем Вы не согласны?
>> 3)
>> шейпинг входящего трафика актуален только в пределах ограниченной (читай локальной сети).
> - Вы за всех решили, что кому актуально, а что нет?
> - Наоборот, трафик внутри локальной сети /чаще всего/ ограничивать не требуется, пусть
> всё работает на маскимальной скорости, а вот "канал в мир" много
> уже, и требуется разграничить/приоритезировать доступ.
тут не сеть - сетИ. стало быть какое-то управление по TCP имеет место быть. роутинг м/ду vlan например.
просто в локальной сети/ях как правило все подкрнтролем => при LAN->WAN можно воспользоваться п.1 при необходимости (окно работает). однако хреновый подход ИМХО шейпить на входе.
>> 4)
>> шейпить надо исходящий трафик. по Ломоносову: "Если где то убудет то в
>> другом месте прибудет". входящее на одном интерфейсе = исходящее на другом.
> Ага. А интереснее всего когда входящее идет с нескольких интерфейсов, уходит опять
> же на несколько интерфейсов, а политика распределения должна собрать всё воедино.
это Вы про что? абстракция. давайте конкретный пример или я посоветую ставить шейпер на/за/перед гейтом - получится 1 входящий - один исходящий интерфейс - дальше ТОЛЬКО проблемы настроить шейпер).
>> 2)
>> смысла рубить невалидный пришедший трафик на шейпере нет (он уже пришел =
>> канал загружен)
> п.4 - шейпить надо исходящий трафик. А на исходящем интерфейсе, при
> переполнении очереди, дропов значит не будет, да ? На одном интерфейсе
> - смысла нет, а на другом интерфейсе - волшебным образом -
> есть... Ну-ну.
дропы будут, только в канал пакеты с исходящего интерфейса уже не пойдут (и следующее устройство не нагрузят - хоть в LAN оно стоит, хоть в WAN - это хорошая политика), а на входящий уже пришли. => на исходящем интерфейсе не загружаем канал говном, а на входящем - просто дропаем, но загрузку не уменьшаем.
>> 1=аксиома, остальное следствия.
>> PS
>> все высказывания даны с точки зрения организации шлюза в инет.
без разницы.
> Хорошего дня =)
И Вам того же.
PS
1) Ломоносов мне кажется прав.
2) шейпинг входа сводится к простому дропу - пакеты УЖЕ пришли и УЖЕ канал загружен.
3) для разгрузки канала шейпинг актуален только на выходе - ибо над входящим трафиком (пропустим RFC - банально: атаки, флуд, дураки-админы, итд) у Вас контроля НЕТ.
4) все ИМХО.
Вариант для распечатки
