หากจะพูดถึงหลักการในการทำ Traffic Shaping ใน Linux แล้วนั้น หลาย ๆ ท่านคงทราบดีกว่ามี
# which tc /sbin/tc
# dpkg -l iproute ... ... +++-==============-==============-============================================ ii iproute 20090324-1 networking and traffic control tools
ที่ช่วยเราจัดการเรื่องนี้ได้ แต่ทว่า การทำ Shaping ของ tc นั้น มีความสามารถจัดการได้อย่างอิสระในฝั่ง egress (ขาส่งข้อมูลออกจาก interface) เท่านั้น ส่วนฝั่ง ingress (ขาส่งข้อมูลเข้า interface) นั้นสามารถทำได้อย่างจำกัด
ถ้ามองในมุมมองของ Clients ที่เรียกข้อมูลเข้ามาที่ Server
ซึ่งจะเห็นว่า ในส่วน Upload อยู่ที่ขา ingress ซึ่งติดข้อจำกัดของระบบ จึงได้เกิดแนวความคิด เรื่องการสร้าง Intermediate Device ขึ้นมา เริ่มต้นที่ได้ทดลอง และใช้งานคือ
ตัว Intermediate Device เหล่านั้น จะเข้ามาทำหน้าที่เป็นตัวกลาง ในการรับส่งข้อมูล ซึ่งการทำ Shaping ในฝั่งขา ingress ก็จะเปลี่ยนไป คือ จะทำการ redirect ข้อมูล ไปที่ Intermediate Device และหลังจากนั้น ก็ทำการ Shaping ที่ฝั่ง egress ของ Intermediate Device แทน โดยไม่ต้องปรับแก้ Kernel ใด ๆ ทั้งสิ้น ดังแผนภาพ
[============] [================] [ Download ]<---- (egress shaping)[ eth0 (Server) ] [============] [================] [========] [===============] [=====================] [ Upload ]--->(ingress)[ eth0 (server) ]-- redirect -->[ ifb0 (intermediate) ](egress shaping) ---> [========] [===============] [=====================]
ซึ่งเป็นดังนี้ เราก็สามารถที่จะทำ Shaping ได้ตามต้องการ ทั้ง Download และ Upload และก็เข้าตามจุดประสงค์ที่ตั้งใจไว้ของ RahuNAS ที่มีการจำกัดการถ่ายโอนข้อมูลของแต่ละ ผู้ใช้ได้อย่างอิสระ และที่สำคัญคาดว่าการเปลี่ยนมาใช้ IFB น่าจะเพิ่มเสถียรภาพให้ระบบมากขึ้นด้วย