一般来说。我们总是希望数据传输的更快一些。但如果发送发把数据发送的过快,接收方就可能来不及接收,这就会造成数据的丢失。因此,需要利用滑动窗口实现流量控制~-~
**流量控制:让发送方发送速率不要太快,要让接收方来得及接收
利用滑动窗口实现流量控制,告诉对方下一次我能接收的最大数据长度
发送方的发送窗口不能超过接收方给出的接收窗口的数值。
TCP的窗口单位是字节,不是报文段。
流量控制中常出现的问题:
1、B向A发送了零窗口的报文段后不久,B的接收缓存又有了一些存储空间。于是B向A发送了非零窗口的报文段。然而这个报文段在传送过程中丢失了。A一直等待收到B发送的非零窗口的通知,而B也一直等待A发送的数据。如果不采取措施,将进入死锁状态。
解决方法:TCP为每一个连接设有一个持续计时器。只要TCP连接的一方收到对方的零窗口通知,就启动持续计时器。若持续计时器设置的时间到期,就发送一个零窗口探测报文段(1字节的数据),而对方就在确认这个探测报文段时给出现在的窗口值。如果窗口仍然是零,那么收到这个报文段的一方就重新设置持续计时器。如果窗口不是零,那么死锁的僵局就可以打破了。
2、必须考虑传输效率,控制TCP报文段的发送时机。
第一种机制:TCP维持一个变量,它等于最大报文段MSS。只要缓存中存放的数据达到MSS字节时,就组装一个TCP报文段发送出去。
第二种机制:有发送方的应用进程指明要求发送报文段,即TCP支持的推送(push)操作。
第三种机制:发送方的一个计时器期限到了,这时就把当前已有的缓存数据装入报文段(长度不能超过MSS)发送出去
3、在线路带宽不富裕时,如何有效地提高网络吞吐量
-
适当的推迟发回确认报文,并尽量使用捎带确认的方法
-
使用Nagle算法:若发送应用进程把要发送的数据逐个字节的送到TCP的发送缓存,则发送方就把第一个数据字节先发送出去,把后面到达的数据字节都缓存起来。当发送方收到对第一个数据字节的确认后,再把发送缓存中的所有数据组装成一个报文段发送出去,同时继续对随后到达的数据进行缓存。只有在收到对前一个报文段的确认后才继续发送下一个报文段。算法还规定,当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时,就立即发送一个报文段
-
-
4、糊涂窗口综合症(Silly Window Syndrome):TCP接收方的缓存已满,而应用进程一次只从接收缓存中读取1个字节,然后向发送方发送确认并把窗口设置为1个字节。接着,发送方又发来一个字节的数据。接收方发回确认,仍然将窗口设置为1个字节。如此下去,网络效率非常低
-
- 解决方法:让接收方等待一段时间,使接收缓存已有足够空间容纳一个最长的报文段或等到接收缓存已有一半空闲的空间,此时接收方就发出确认报文,并向发送方通知当前的窗口大小。此外,发送方也不要发送太小的报文段,而是把数据积累成足够大的报文段或达到接收方缓存的空间的一半大小
-