TCP中成块确认： 数据发送方在发送下一个数据块之前需要等待接收对已发送数据的确认。T C P所使用的被称为滑动窗口协议的另一种形式的流量控制方法。该协议允许发送方在停止并等待确认前可以连续发送多个分组。由于
发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输。
图2.jpg
忽略掉1~3握手建立连接报文，发送方首先传送3个数据报文段（4 ~ 6）。下一个报文段（7）仅确认了前两个数据报文段，
注意到报文段7、 1 4和1 6中的A C K确认了两个收到的报文段是很重要的。使用 T C P的滑动
窗口协议时，接收方不必确认每一个收到的分组。在 T C P中， A C K是累积的—它们表示接
收方已经正确收到了一直到确认序号减 1的所有字节。在本例中，三个确认的数据为 2 0 4 8字节
而两个确认的数据为 1 0 2 4字节（忽略了连接建立和终止中的确认）。
滑动窗口
可视化的方法显示了我们在前一节观察到的滑动窗口协议
图1.jpg
在这个图中，我们将字节从 1至11进行标号。接收方通告的窗口称为提出的窗口（offered window），它覆盖了从第 4字节到第 9字节的区域，表明接收方已经确认了包括第 3字节在内的
数据，且通告窗口大小为 6。回顾第1 7章，我们知道窗口大小是与确认序号相对应的。发送方
计算它的可用窗口，该窗口表明多少数据可以立即被发送。
当接收方确认数据后，这个滑动窗口不时地向右移动。窗口两个边沿的相对运动增加或
减少了窗口的大小。我们使用三个术语来描述窗口左右边沿的运动：
- 称窗口左边沿向右边沿靠近为窗口合拢。这种现象发生在数据被发送和确认时。
- 当窗口右边沿向右移动时将允许发送更多的数据，我们称之为窗口张开。这种现象发
生在另一端的接收进程读取已经确认的数据并释放了 T C P的接收缓存时。 - 当右边沿向左移动时，我们称之为窗口收缩。 Host Requirements RFC强烈建议不要使
用这种方式。但T C P必须能够在某一端产生这种情况时进行处理。第 2 2 . 3节给出了这样的一个
例子，一端希望向左移动右边沿来收缩窗口，但没能够这样做。
数据传输过程中滑动窗口协议的动态性.jpg
以该图为例可以总结如下几点：
- 发送方不必发送一个全窗口大小的数据。
- 来自接收方的一个报文段确认数据并把窗口向右边滑动。这是因为窗口的大小是相对
于确认序号的。 - 正如从报文段 7到报文段 8中变化的那样，窗口的大小可以减小，但是窗口的右边沿却
不能够向左移动。 - 接收方在发送一个 A C K前不必等待窗口被填满。在前面我们看到许多实现每收到两个
报文段就会发送一个 A C K。
下面我们可以看到更多的滑动窗口协议动态变化的例子。
窗口大小：
由接收方提供的窗口的大小通常可以由接收进程控制，这将影响 T C P的性能
