先补充一个知识：
1.停止等待协议：是tcp保证传输可靠的重要途径，“停止等待”就是指发送完一个分组就停止发送，等待对方确认之后，才能继续发送下一个分组
停止等待协议的优点是简单，缺点就是信道的利用率太低，一次只发送一个消息，信道大部分时间都是空闲的。
2：超时重传有一下三种情况：
1） 分组丢失：发送方发出来了，接收方没有收到
2） 确认丢失：接收方收到了，也发送了确认分组，但是确认分组丢失了
3） 确认延时：确认分组没有丢失，由于传输太慢，发送方在规定时间内没有收到接收方发的确认分组。
3.下面两个协议就是解决信道效率太低和增大吞吐量，以及流量控制：
1）连续ARQ协议：它是指发送方维护着一个窗口，这个窗口中不止有一个分组，而是有好几个分组。窗口的大小是由接收方返回的win值决定的。所以窗口大小 是动态变化的。只要在窗口中的分组都可以被发送，这就使得TCP一次不是只发送一个分组了。从而大大提高了信道利用率。并且它采用累积确认的方式，对于按序到达的最后一个分组进行确认。
2）滑动窗口协议：因为窗口不断往前走。该协议允许发送方在停止并等待确认前发送多个数据分组。不需要每发送一个就分组就停下来等待确认。所以可以加速数据的传输，还可以控制流量。
3）累积确认：如果发送方发送了5个分组，接收端只收到了1 2 4 5 ，没有收到3，那么我的确认信息会是说明我期望下一个收到的组是第三个，此时发送方会将3 4 5都重发一遍。
20.1 引言
本章我们将介绍TCP所使用的被称为滑动窗口协议的另一种形式的流量控制方法。
该协议允许发送方在停止并等待确认前可以连续发送多个分组。
20.2 正常数据流
经受时延的确认：假设 A -> B，B要对A的数据进行确认，当有一个分组来的时候，B不立即确认，而是启动一个定时器（RFC规定要小于500ms，很多都是200ms），等待200ms，如果在这期间A又来了其他的数据就可以一起确认了 。或者A要发数据给B了，就顺带把之前的也确认了。
比如下面这样，对1025的确认放到了跟2049一起。
使用滑动窗口协议，接收方不必确认每一个收到的分组。在TCP中，ACK是累积的—它们表示连接方已经正确收到了一直到确认号减1的所有字节。比如上面的2049，就表示我收到了2048个字节。
20.3 滑动窗口协议
比如上面的例子，应该是右边发送数据给左边。左边进行确认。窗口往右移动。
接收方通告的窗口称为提出的窗口（offered window）：上面的4 – 9
说明接收方已经收到了3字节的数据，且通告窗口大小为6.
当接收方确认数据后，这个滑动窗口不断的向右移动。下面用三个术语来描述窗口左右边沿的运动：
1） 称窗口左边沿向右边沿靠近为窗口合拢。这种现象发生在数据被发送和确认时。
2） 当窗口右边沿向右移动时将允许发送更多的数据，我们称之为窗口张开。这种现象发生在另一端的接收进程读取已经确认的数据，并释放了TCP的接收缓存时。（就是接收方读取了缓冲区里面的数据的时候）
3） 当右边沿向左移动，称为窗口收缩。
如果左边沿到达右边沿，则称其为一个零窗口。此时发送方不能发送任何数据。
20.4 窗口大小
由接收方提供的窗口的大小通常可以由接收进程控制，这将影响TCP的性能。
插口API允许进程设置发送和接收缓存的大小。接收缓存的大小是该连接上所能通告的最大窗口大小。有一些应用程序通过修改插口缓存大小来增加性能。
20.5 PUSH标志
发送方使用该标志通知接收方将所收到的数据全部提交给接收进程。（这里的数据包括与PUSH一起传送的数据，以及接收方TCP已经为接收进程收到的其他数据）
假设一个客户端发送数据给服务器，设置了PUSH标志：
对客户端来说：客户进程通知TCP在向服务器发送一个报文段时不要因等待额外数据而使已提交数据在缓冲中滞留。
对服务器来说：TCP收到一个设置了PUSH标志的报文时，它需要立即将这些数据递交给服务器进程而不能等待判断是否还会有额外的数据到达。
目前大多数的API没有向应用程序提供通知其TCP设置PUSH的方法，很多实现程序任务PUSH已经过时了。一个好的TCP实现能够自动设置PUSH标志。
如果待发送数据将清空发送缓存，则大多数的源于伯克利的实现能够自动设置PUSH标志。
20.6 慢启动
“慢启动”slow start算法：通过观察到新分组进入网络的速率应该与另一端返回确认的速率相同而进行工作。