>Ну да. Но TCP абсолютно пофиг, где именно его резать, ему важно
>лишь направление. Вот только блаародный дон упускает несколько моментов...
1) В природе есть не только TCP.
2) Предполагается что ремота кооперативна и соблюдает правила игры.Что как-то не гарантированно.Мало чтоли ли malicious фруктов на свете и прочих неожиданностей?
3) По большому счету от ВАС нихрена не зависит в каком порядке в вашу сторону выдавит пакеты провайдер в вашу соску (как максимум, можно например договориться с провайдером насчет приоретизации определенного траффа в вашу сторону, etc).Поэтому ситуация когда вам пришлют сначала 5 мегов гумна а только потом VoIP пакеты которые вы так ждали - вашим шейпингом не исключается нифига.С соответствующими последствиями для латентности VoIP, разумеется.Т.к. сначала вы будете получать по тощей соске 5 мегов гумна а только потом - "приоритетные" с вашей точки зрения пакеты.При том соска обычно сильно тоньше чем LAN и время профуканное на вот это будет на порядки больше чем время которое вы там выиграете отприоретизировав пакеты выплюнутые в сторону LAN.
Итого?Идея шейпить траффик на вход может и красива.Но достаточно своеобразно работает в типовой ситуации, когда на вход относительно тощая (по сравнению с скоростью LAN) соска вносящая основные задержки, а после шейпящего девайса - скоростная LAN.Шейпить пакеты на прием было бы намного эффективнее в совсем другом месте.Как правило нихрена вам не подконтрольном - с другой стороны соски, только это уже на совести провайдера, а вы по этому поводу сделать в общем то мало что можете.Разве что с провайдером договориться.А то что с той стороны канала соблюдают правила игры - не гарантированно.Могут например начать вдувать вам N мегабит syn-пакетов в одностороннем порядке.Не ожидая от вас ответ.И толку от вашего шейпинга при этом?Вот шейпинг и правильная приоретизация с другой стороны тощей соски могла бы иной раз и поменять картину, да (если каналов провайдера хватит а вашей тощей соски уже нет).Только это не с вашей стороны тощей соски рулится...
