>Благородный дон, если бы весь трафик состоял из атак то может быть ты бы и был прав, а
>когда бОлшая часть трафа составляют tcp-сессии то проблем нет.Проблем нет ... ровно до тех пор пока удача улыбается вам лицом.А если повернется попой (траффик окажется "не тот" или кто-то будет гавнюком и не будет с той стороны провода кооперативен с вашими потугами что-то этакое изобразить) - проблемы у вас будут.Посему это именно недо-шейпинг.Шейпинг исходящего траффа в узкий канал дает кой-какие гарантии и приоритеты там не липовые а реальные - наиболее приоритетные пакеты первыми полетят в медленный канал, остальные подождут, а при нужде и выкинутся в нужном количестве.Сие позволяет достичь какой-то предсказуемости и гарантий и там пофиг - UDP, TCP, ICMP или что там еще - не принципиально.В отличие от довольно халтурных потуг что-то там поиметь довольно левыми методами требущие весьма вольных допущений о природе траффа и кооперативности ремотных систем насчет потуг это регулировать.Эрзац - получается.А вот честно и гарантированно как с исходящим - фиг!Только если кто-то с другой стороны канала зашейпит и отполисует ДО впихивания это в медленный канал к вам.А после - уже поздно что-то там полисовать в общем случае.
>Когда у тебя весь канал забит флудом то тебе не то что шейпер не поможет,
>тебе ничего не поможет кроме как помощь провайдера.
У провайдера как правило суммарная емкость каналов на порядки превышает скорость типового канала до пользователя.Посему грамотный шейпинг и полисовка с той стороны канала может в принципе решить эту проблему - путем отстрела или придерживания "неправильных" пакетов в пользу "правильных".Чем собственно и занимаются при шейпинге и полисовке траффа по нормальному.При этом в нормальном исполнении (2 железки с обоих сторон медленного канала честно шейпят и полисуют свое исходящее направление) все будет так как надо.С какими-никакими предсказуемыми параметрами и возможностью что-то гарантировать и реально доставить одни пакеты, частично пожертвовав другими.С одной стороны - не получится нормально.Получится эрзац который никому ничего не гарантирует по большому счету.И если в вас прилетит 5 мегов левых пакетов в 20 мбит канал - может так получиться что вы пару секунд будете левак выгребать а только потом "приоритетные" VoIP пакетики получите.А вот реальное время ждать вас разумеется при этом не станет.
> И не надо говорить что шейпить tcp-трафик невозможно только потому что ты это не осилил.
Ха-ха, мне нравится такая аргументация :).Ну, знаете, если я пришлю вам эн мегабит SYN пакетов (или любых иных пакетов протокола TCP) - это тоже с формальной точки зрения TCP траффик.А вот отполисовать его вы обломаетесь если я буду некооперативен на этот счет и положу на ваши потуги болт.А, собственно, что мне запретит просто кидать в вашу сторону пакеты?Отказаться от их получения вы в общем случае не сможете.Канал оно займет точно так же как и любой иной траффик, не факт что менее приоритетно чем нужные вам пакеты(если пров не подыграет с его стороны).Полисовка получается весьма лажовая.А теперь вы пробуете сделать то же самое с честной полисовкой исходящего траффа и понимаете разницу :).При этом более приоритетные пакеты (например VoIP) будут отправлены раньше.А общая скорость потока может быть реально огранчена - отбросом "лишнего", если его продолжают валить быстрее чем разрешено :)
> Прекращай свои интелектуальные способности на весь инет демонстрировать.
Так это... а конструктивные аргументы будут? :D
