文章插图

事情的起因是最近家里买了一台60寸的智能电视 ， 支持点播（VOD）功能 ， 家里的网络带宽理论上只有4M ， 在播放的时候 ， 就会占用大量网络带宽 ， 导致我同时上网浏览网页都很困难 。
有没有办法给限制局域网内某台主机的流量？首先 ， 还是得从TCP的原理说起 。
TCP拥塞控制
TCP是个君子协议 ， 在拥塞控制的设计（RFC 2851）中包括慢开始、拥塞避免、快重传和快恢复4种算法 。

文章插图

拥塞窗口（cwnd）和接收端窗口（rwnd）二者的最小值确定了发送窗口的上限值 ， 而实际上对于现今的网卡 ， 接收端窗口的大小是可以很大的 ， 也就是说 ， 拥塞主要寄希望于拥塞窗口来控制 ， 拥塞窗口直接决定了传输的速率 。 从上面这张图可以看到：
慢开始增加到门限初始值的这段过程中 ， 拥塞窗口的增长是比较快的 。
之后的增长由指数式变成了保持线性缓慢增长 ， 直到出现网络拥塞超时 。
超时以后重新慢开始的过程 ， 但是门限值发生了改变 ， 变成了拥塞发生值的一半大小 。
为了改进上述拥塞控制算法的弊端 ， 又加入了快重传和快恢复算法 。 快重传指的是：
对于msg1和msg2 ， 接收端收到以后 ， 就分别回复ack2和ack3 ， 但是这时候msg3丢失了（或者由于网络原因很久还未到达）；
接收端又收到了msg4 ， 那就可以接收下msg4 ， 但是依然回复ack3（ack3依旧是意味着告诉发送端只收到了msg1和msg2）；
发送端继续发送msg5和msg6 ， 可是接收端依然回复ack3；
但是发送端只要发现一连3个重复的ack3 ， 就知道估计msg3丢失了 ， 得重传msg3了 。
而快恢复算法是为了解决在发生网络拥塞时 ， 拥塞窗口一下子跌到谷底（为1） ， 导致不能很快恢复网络正常通信流量状态 ， 所以做了一个改进——
在拥塞发生的时候 ， 只是把拥塞窗口置为ssthresh+n×MSS（其中n表示收到重复的ack报文的个数 ， MSS指的是最长报文段）；
同时 ， 这以后当收到新的ack报文时 ， 就将拥塞窗口置为ssthresh的值 。
TCP协议在这样的拥塞控制机制下保证了对质量较差的网络也有较好的适应性 ， 但是UDP协议就不具备这种拥塞控制机制（除非你在协议之上的应用中自己设计） ， 而流媒体往往是基于UDP来实现的 ， 因为它更快、无连接 ， 而且偶尔丢帧也可以接受 。 在这种争夺带宽的场景下 ， 君子TCP就没有办法争夺到较好的流量了 。
多端口多连接
【如何在局域网内抢带宽的图文方法介绍】这是迅雷的主要做法之一 ， 开启多个端口 ， 建立多个连接 ， 靠这种简单粗暴的方式来占取带宽 。
ARP欺骗
Google搜索局域网抢带宽以后 ， 映入眼帘的是P2P终结者这样的“杀器” ， 它的原理就是基于ARP欺骗 ， 即是说 ， 通过ARP攻击等使局域网内其它机器产生大量本地盲包 ， 减少对公用网络资源的占用 。
ARP（Address Resolution Protocol ， 地址解析协议）是获取物理地址的一个TCP/IP协议 。 某节点的IP地址的ARP请求被广播到网络上后 ， 这个节点会收到确认其物理地址的应答 ， 这样的数据包才能被传送出去 。 也就是说 ， 在这个过程中 ， 发送方用目标IP地址去换取了接收方的MAC地址 ， 之后MAC地址存放到本地的缓存中（在一定的生存期时间内） 。
由于在局域网中是使用MAC地址进行传输的 ， 因此P2P终结者就伪造这样的一个ARP应答 ， 把P2P终结者所在的机器A的MAC地址告诉目标机B（目标机B在任意时候都可以接收ARP请求的应答） ， 让目标机以为本机才是网关 ， 这样B接收后就会更新本地缓存 ， 以后所有本该走到网关去的包都会从机器A走 ， 这就是一个简单的ARP欺骗的原理 。