Значи ако условно наречем UDP трафика от даден хост/порт към някой порт на клиентска машина - *конекция*
*Не можеш да ограничиш броя на *конекциите*, за съжаление
*Можеш да ограничиш скоростта на трафика от *конекции* установени от твои клиенти към външни хостове (voip трафика носещ гласа на 8твоите клиенти)
* Можеш да ограничиш скоростта с която минава voip трафика от рутера ти до твоите клиенти, но не и скоростта на същия трафик идващ от модема към рутера ти . (т.е voip трафика представляващ гласа на събеседника на клиентите ти, в пътя и от твоят рутер до конкретния твой клиент)
* С ingress шейпинг правиш горе долу същото, малко по-грубо, само че там ограничаваш скоростта малко преди това,т.е, скоростта с която целият трафик минава между момента в който влиза от входящия интерфейс до момента в който бъде минат през рутинг и нат алгоритмите , след което важат ограниченията, които налагаш от горния параграф (бахмалоумното обяснение, съжалявам, но ми е малко трудно да го обясня без да начертая глупостите)
Така стоят нещата, грубо казано не можеш да контролираш това което влиза в мрежата ти от интернет. Можеш единствено да ограничаваш *надеждно* изходящият трафик. Понеже няма как да ти знам изискванията и ип адресите на клиентите въобще няма как да ти приготвя скрипта дето ще ти свърши работа. И все пак, прочети linux advanced routing & traffic control,
http://www.lartc.orgЗащо можеш да ограничаваш по-ефективно TCP трафик отколкото UDP такъв: все пак при TCP за всеки изпратен пакет се изискват потвърждения че е получен под формата на "потвърждаващ" TCP пакет. Колкото по-бавно се връщат тези потвърждения, толкова по-бавно ще бъде изпратен следващият пакет информация...докато при UDP никой не му дреме потвърждава ли се всеки изпратен пакет...и така