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

一般来说：我们总是希望数据传输的更快一些。但如果发送方把数据发送的过快，接收方就可能来不及接收，这样就会造成数据的丢失。所谓的流量控制（flow control）就是让发送方的发送速率不要太快，要让接受方来得及接收。

对ACK的再认识：
ACK表示首部中的确认位ACK，而小写的ack表示确认字段的值;
在ACK为1的情况下：小写的ack才会起作用
TCP规定：在建立连接后，所有传送的报文段都必须把ACK置为1。
举个例子，假如接收端收到1-1024字节，它会发送一个确认号为1025的ack（ACK为1）,但是接下来收到的是2049-3072，它是不会发送确认号为3072的ack,而依旧发送1025的ack（ACK为1）。

设A向B发送数据。在建立连接时：B告诉A，“我的接收窗口rwnd = 400”（rwnd 表示receiver window）。因此：发送方的发送窗口不能超过接收方给出的接收窗口的数值。TCP的窗口单位是字节，而不是报文段，因此：设每一个报文段为100字节长，而数据报文段序号的初始值设为1（seq = 1）

我们可以看到：接受方B进行了三次流量控制。

第一次把窗口减小到rwnd = 300，（应该是应用程序此时从B的接收缓存中拿走了一个报文段（100个字节），缓存中还剩余1个报文段（100个字节），还可以容纳3个报文段，所以rwnd减小到了300）（而至于上面提到的：A发送了序号301到400，还能在发送100字节新数据，这句话的意思是，此时201-300这段数据我还没有收到，我必须给它留够足够的存储空间，然后就还剩下100字节的空间，也就是一个报文段，所以，此刻：我还能接收的就是401-500这个数据了）

第二次减小到100，（是因为B中的接收缓存中有3个报文段（200-500），rwnd = 100）

第三次减小到0，（B的接收缓存满了，没有可用的缓存空间了）

rwnd = 0，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。、

当然：还有另外一种情况：B向A发送了窗口为0的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwnd = 400的报文段。然而这个报文段在传送过程中丢失了。A一直在等待B发送的非0窗口的通知，而B也一直等待A发送的数据。如果没有其他的措施，这种互相等待的死锁局面将一直延续下去。

为了解决这个问题：TCP为每一个连接设有一个持续计时器。只要TCP连续的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到了，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在窗口的值。如果仍然是0，那么收到这个报文段的一方就重新设置持续计时器，就可以了

那么tcp是什么时候将字节流打包成一个报文段然后给发送出去的呢？？？

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

2，由发送方的应用进程指明要求发送报文段，即TCP中的PSH操作，尽快的将数据发送过去

3，设置一个计时器，这时就把当前已有的缓存数据装入报文段（但长度不能超过MSS）发送出去

到底要发送多少的呢？？？

假如只发送了一个字符呢？？？加上TCP的20字节的首部，得到21字节长的TCP报文段。再加上20字节的IP首部，形成了41字节长的IP数据包，然后接受方再次返回确认。又是40字节（不携带数据），也就是说：用户发送一个字符并且要收到确认，那么81个字节，只有一个是有效的，其利用率及其低下，因此应当适当的推迟发回确认报文，

在TCP的实现中广泛使用Nagle算法：

若发送方应用进程把要发送的数据逐个字节的送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面到达的数据字节都缓存起来，当发送方收到对第一个数据字符的确认后，再把发送缓存中所有数据组装成一个报文段发送出去，同时继续对随后到达的数据进行缓存。只有在收到对前一个报文段的确认后才继续发送下一个报文段。当数据到达较快而网络速率较慢时，这样的方式可以明显的减少所用的网络带宽。

Nagle：当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段

可以让接受方等待一段时间，使得接收缓存已有足够空间容纳一个更长的报文段，或者等到接收缓存已有一半空闲的时间。然后：接受方就发出确认报文，并向发送方通知当前窗口的大小