1、利用滑动窗口实现流量控制

一般说来，我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失。

流量控制(flow control) 就是让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞。利用滑动窗口机制可以很方便地在TCP连接上实现流量控制。

A向B发送数据。在连接建立时，B告诉A： “我的接收窗口rwnd = 400（字节）”

可能发生死锁

B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwnd = 400的报文段。但这个报文段在传送过程中丢失了。A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据。

如果没有其他措施，这种互相等待的死锁局面将一直延续下去。为了解决这个问题，TCP为每一个连接设有一个持续计时器(persistence timer)。

TCP 为每一个连接设有一个持续计时器 (persistence timer) 。只要TCP连接的一方收到对方的零窗口通知，就启动该持续计时器。

若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1 字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。

若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器。若窗口不是零，则死锁的僵局就可以打破了。

2、考虑传输效率

可以用不同的机制来控制TCP报文段的发送时机:

第一种机制是TCP维持一个变量，它等于最大报文段长度MSS。只要缓存中存放的数据达到MSS字节时，就组装成一个TCP报文段发送出去。

第二种机制是由发送方的应用进程指明要求发送报文段，即TCP 支持的推送(push)操作。

第三种机制是发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（但长度不能超过MSS）发送出去。如何控制TCP发送报文段的时机仍然是一个较为复杂的问题。

发送方TCP每次接收到一字节的数据后就发送。这样，发送一个字节需要形成41字节长的IP数据报。若接收方确认，并且发送方要求回送这一字节，就需传送总长度为162字节共4个报文段。效率很低。解决方法：使用Nagle 算法。

若发送应用进程把要发送的数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面到达的数据字节都缓存起来。

当发送方收到对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段发送出去，同时继续对随后到达的数据进行缓存。

只有在收到对前一个报文段的确认后才继续发送下一个报文段。当数据到达较快而网络速率较慢时，用这样的方法可明显地减少所用的网络带宽。

当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。这样可提高网络的吞吐量。

当接收方的TCP缓冲区已满，接收方会向发送方发送窗口大小为0的报文。若此时接收方的应用进程以交互方式每次只读取一个字节，于是接收方又发送窗口大小为一个字节的更新报文，发送方应邀发送一个字节的数据（发送的IP数据报是41字节长），于是接收窗口又满了，如此循环往复。

解决方法：让接收方等待一段时间，使得或者接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半空闲的空间。只要出现这两种情况之一，接收方就发出确认报文，并向发送方通知当前的窗口大小。同时，发送方也不要发送太小的报文段。