流量控制（flow control）:就是让发送方的发送速率不要太快，要让接收方来得及接收。
利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。
利用滑动窗口实现流量控制
发送方的发送窗口不能超过接收方给出的接收窗口的数值。
TCP的窗口单位是字节，不是报文段。
B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送rwnd = 400的报文段，但是这个报文段在传输过程中丢失了。因此，会陷入相互等待的死锁局面，怎么办？
TCP为每一个连接设有一个持续计时器（persistence timer），只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。如果窗口仍然是零，那么收到这个报文段的一方就重新设置持续计时器。如果窗口不是零，那么死锁的僵局就可以打破了。
必须考虑传输效率
应用进程把数据传送到TCP的发送缓存后，剩下的发送任务就由TCP来控制了。
Nagle算法
1.若应用进程把要发送的数据逐个字节的送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面到达的数据字节都缓存起来。
2.当发送方收到对第一个字符的确认后，再把发送缓存中的所有数据组装成一个报文段发送出去，同时继续对随后到达的数据进行缓存。
3.只有在收到对前一个报文段的确认后才继续发送下一个报文段。
当数据到达较快而网络速率较慢时，用这样的方法可明显的减少所用的网络带宽。
糊涂窗口综合征（silly window syndrome）
TCP接收方的缓存已满，而交互式的应用进程一次只从接收缓存中读取1个字节，然后向发送方发送确认，并把窗口设置为1个字节（但发送的数据报是40个字节）。接着，发送方又发来1个字节的数据（发送方发送的IP数据报是41字节）。这样持续下去，使网络的效率很低。
解决方法：
可以让接收方等待一段时间，使得或者接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半空闲的空间。只要出现这两种情况之一，接收方就发出确认报文，并向发送方通知当前的窗口大小。
