一---导读
首先我们来看实际生活中这样一个实例，大人喂小孩子吃饭，如果孩子嘴里还有饭，孩子表示不想吃了，但大人还是继续喂。喂多了。这样就会给孩子留下一个完整的不愉快童年。
那么在使用TCP协议的双方端系统中，发送方就像喂饭的大人，而接收方就是孩子，发送方发送的量应该由接收方来决定或者说来调节。
二---TCP流量控制（flow control）的产生原因以及控制手段
让发送方不要太快，以免接收方接收不过来。滑动窗口就是控制手段。
上图即为滑动窗口，图示滑动窗口大小为400，滑动窗口由接收方调节。
三---实例说明
在看下图之前，我们首先必须搞清楚这样几个专有名词的含义
1---seq(顺序;序号;初始序号;序列号;排列机)：是TCP报文段首部中的序号字段，取值为1则表示TCP报文段数据载荷的第一个字节的序号为1，取值为101表示TCP报文段数据载荷的第一个字节的序号为101；
2---DATA：表示TCP报文段；
3---ACK(Acknowledge character 接收字符)：表示TCP报文段首部中的标识位，取值为1表示是一个确认报文段，为0表示报文中不包含确认信息，忽略确认号字段。
4---ack:表示TCP报文段中的确认号字段，取值为x表示发送方发送的x部分的字节已经确认收到；
5---rwnd(receive window):滑动窗口的英文名；滑动窗口也可理解为接收窗口。
四---死锁的产生和解决
思考这样一个问题，当接收方发送给发送方的确认报文段丢失，而它一直傻傻的以为报文段成功被接收方接收，满怀期待的等着接收方发送新的报文段给它。然而另一边，发送方一直等待着接收方发送的确认报文段，好继续发送新的报文段给接收方，然而确认报文段在路上的时候就走丢了。于是双方陷入千年的等待。这就是死锁（死锁在计算机操作系统中也出现了这个概念，思想和计算机网路的大致相同）。这个时候就需要一个来解决问题的调解员。持续计时器就是这样一个调解员，若超时了，发送方发送一个大小为1字节的0窗口探测报文段。如果接收方回答为当前的接收窗口为0，则发送方继续等待，等待一会后，如果接收方的接收缓存有了空闲，则发送能接受多大的接收窗口（rwnd）给发送方，发送方按照接收方回答的值调整滑动窗口继续去发送报文段。
朋友们可能会有这样一个疑问，既然接收方的接收窗口都为0了，那就应该什么都收不到才对，为什么能收到发送发送的0窗口探测报文段并且返回确认呢？ 这是因为TCP规定，即使接收窗口为0，接收方必须无条件的接收0窗口探测报文段，携带紧急数据的报文段，确认报文段。
继续思考这样一个问题：如果0窗口检测报文段丢失了，会出现什么问题？还能打破死锁的局面吗？回答是肯定的，因为0窗口探测报文段本身带有重传计时器，如果重传计时器超时，则重新发送0窗口探测报文段
