TCP/UDP的学习总结(三)
TCP/UDP的学习总结(三)
TCP的流量控制
1.利用滑动窗口实现流量控制
所谓流量控制，就是让发送方的发送速率不要太快，要让接收方来得及接收。利用下图来说明如何利用滑动窗口机制进行流量控制：
一开始(connect后)，B告诉A: 我的接收窗口rwnd=400，TCP的窗口单位是字节，不是报文段。报文段序号初始值设为1。
接收方B进行来3次流量控制。第一次把窗口减小到rwnd=300，第二次又减到rwnd=100，最后减到rwnd=0，即不允许发送方再发送数据了。这种情况，发送方A暂停发送的状态将持续到B重新发出一个新的窗口值为止。
还应注意到，B向A发送的三个报文段都设置来ACK(报文段头部的确认位)=1，只有ACK=1时，确认号字段才有意义。小写的ack表示确认字段的值=接收到最后一个报文段+1。
考虑一种情况，在上图，B向A发送了零窗口的报文段不久后，B的接收缓存又有了一些空间，于是B发送的rwnd=400的回复确认报文段。然而在传输过程中丢失了，那么A会一直等待B发送非零窗口的通知，B也一直等待A发送数据，这样就形成来一个死锁的局面！
为了解决这个问题，TCP为每一个连接设有一个持续计时器。只要TCP连接的一方(A)收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到了，该方(A)就发送一个零窗口探测报文段(仅携带1字节的数据)，而对方(B)就在确认这个探测报文段时给出了现在的窗口值(rwnd=400)。如果窗口仍是零，那么收到这个报文段的一方(A)重新设置持续计时器。如果窗口不是零，死锁的僵局就打破了。
2. 考虑传输效率
上一章节讲到，应用进程把数据传送到TCP的发送缓存后，剩下的发送任务就由TCP来控制了。
TCP用不同的机制来控制TCP报文段的发送时机:
1. 只要缓存中存放的数据等于MSS(最大报文段长度)时，就组装成一个TCP报文段发送出去。
2. 计时器到了，就把当前已有的缓存数据装入报文段，发送出去。
3. 由发送方的应用进程指明要发送的报文段，即TCP支持的push操作。
如何控制TCP发送报文段的时机仍然是一个较为复杂的问题，TCP一般是使用的Nagle算法：
若发送应用进程要把要发数据逐个字节发送到TCP的发送缓存，则TCP发送方就把第一个数据字节发送出去(内核操作), 把后面到达的字节都缓存起来(存在发送缓存中)。当发送方收到对第一个字节确认的报文段后，再把发送缓存中的所有数据组装成一个报文段发送出去，同时继续对随后到达的数据进行缓存。
Nagle算法还规定，当到达的数据已达到发送窗口大小的一半或报文段最大长度时，就立即发送一个报文段！
糊涂窗口综合症(silly window syndrome)
设想一种情况: TCP接收方的缓存已经满了，而交互式的应用进程一次只从接收缓存中读取1个字节(这样接收缓存空间仅腾出1个字节空间)，然后发送确认，并把窗口值大小设为1个字节(但发送的数据报是40字节长)。接着发送方又发来1个字节的数据。接收方发回确认，仍然将窗口设置为1个字节。这样下去，网络的效率很低。
解决办法:
1.接收方: 等到接收缓存已经容纳了一个最长的报文段，或者等到接收缓存已有一半空闲的控制。只要有两种情况之一，接收方就发出确认报文.
2.发送方: 发送方不要发送太小的报文段，而是把数据累计成足够大的报文段，或达到接收方缓存的空间的一半大小，再发送数据。
上述两种方法配合使用，可以最大化提升信道利用率