tcp滑动窗口详解(2)
http://blog.csdn.net/yujun00/article/details/636495
ARQ与滑动窗口概念
滑动窗口协议，是TCP使用的一种流量控制方法。该协议允许发送方在停止并等待确认前可以连续发送多个分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输。
自动重传请求（Automatic Repeat-reQuest，ARQ）是OSI模型中数据链路层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。ARQ可能包括停止等待ARQ协议、回退ARQ和连续ARQ协议，错误检测（Error Detection）、正面确认（Positive Acknowledgment）、超时重传（Retransmission after Timeout）和 负面确认及重传（Negative Acknowledgment and Retransmission）等机制。
他们的概念是差不多的只是作用于不同的网络层。数据链路层的滑动窗口是“个数固定”的。而TCP的滑动窗口是“个数可变”的，可以由接收端设置WIN字段来修改。
传统自动重传请求分成为三种，即停等式(stop-and-wait）ARQ，回退n帧（go-back-n）ARQ，以及选择性重传（selective repeat）ARQ。后两种协议是滑动窗口技术与请求重发技术的结合，由于窗口尺寸开到足够大时，帧在线路上可以连续地流动，因此又称其为连续ARQ协议。三者的区别在于对于出错的数据报文的处理机制不同。三种ARQ协议中，复杂性递增，效率也递增。除了传统的ARQ，还有混合ARQ（Hybrid-ARQ）。
当发送窗口和接收窗口的大小都等于 1时，就是停止等待协议。
当发送窗口大于1，接收窗口等于1时，就是回退N步协议。
当发送窗口和接收窗口的大小均大于1时，就是选择重发协议
停止并等待ARQ协议(stop-and-wait)
停止并等待协议的工作原理如下：
- 发送点对接收点发送数据包，然后等待接收点回复ACK并且开始计时。
- 在等待过程中，发送点停止发送新的数据包。
- 当数据包没有成功被接收点接收时候，接收点不会发送ACK. 这样发送点在等待一定时间后，重新发送数据包。
- 反复以上步骤直到收到从接收点发送的ACK.
发送点的等待时间应当至少大于传输点数据包发送时间（数据包容量除以发送点传输速度），接收点ACK接收时间（ACK容量除以接收点传输速度），数据在连接上的传送时间，接收点检验接收数据是否正确的时间之和。在实际应用当中，等待时间是这个和的2到3倍。
这个协议的缺点是较长的等待时间导致低的数据传输速度。在低速传输时，对连接频道的利用率比较好，但是在高速传输时，频道的利用率会显著下降。
回退n帧的ARQ
在回退n帧的ARQ中，当发送方接收到接收方的状态报告指示报文出错后，发送方将重传过去的n个报文。 回退N，发送窗口大于1，接收窗口等于1。允许发送方可以连续发送信息帧，但是，一旦某帧发生错误，必须重新发送该帧及其后的n帧。这种方式提高了信道的利用率，但允许已发送有待于确认的帧越多，可能要退回来重发的帧也越多。
回退的基本原理图：
如果当前发送的是数据链路层上的最后一个帧（无论是数据帧还是确认帧），但不幸的是该帧出错或丢失了，此种情况也适用于中间某一帧开始的所有后继帧全部出错或丢失的情况（同样可以是数据帧或确认帧），那么发送端会一直等待下去，而且接收端对此也毫无察觉。
为了解决这个问题，需要采用超时机制。可以有多种定时方案，在早期方案中采用的一种是独立的定时器，发送端每发送一个数据帧就启动一次，当收到确认帧后，定时器复位；如果直到超时还没有收到确认帧，则重发该帧以及后继的帧。
其原理如图下所示：
连续ARQ协议(Continuous ARQ)
为了克服停止并等待ARQ协议长时间等待ACK的缺点。这个协议会连续发送一组数据包，然后再等待这些数据包的ACK.
连续 ARQ 协议的工作原理图：
如图所示，结点 A 向结点 B 发送数据帧。当结点 A 发完 0 号帧后，不是停止等待，而是继续发送后续的 1 号帧、2 号帧等。由于连续发送了许多帧，所以应答帧不仅要说明是对哪一帧进行确认或否认，而且应答帧本身也必须编号。
结点 B 正确地收到了 0 号帧和 1 号帧，并送交其主机。现在设 2 号帧出了差错，于是结点 B 就将有差错的 2 号帧丢弃。结点 B 运行的协议可以有两种选择：一种是在出现差错时就向结点 A 发送否认帧，另一种则是在出现差错时不做任何响应。我们现在假定采用后一种协议，这种协议比较简单，使用得较多。
选择重传 (Selective Repeat)
- 发送点连续发送数据包但对每个数据包都设有个一个计时器。
- 当在一定时间内没有收到某个数据包的ACK时，发送点只重新发送那个没有ACK的数据包
这个方法的缺点是接收点收到的数据包的顺序可能不是发送的数据包顺序。因此在数据包里必须含有顺序字符来帮助接受点来排序。
- 接收点丢弃从第一个没有收到的数据包开始的所有数据包。
- 发送点收到NACK后，从NACK中指明的数据包开始重新发送
这个办法的问题是如何正确选择表明数据包的顺序字符的数量。这个数量因当包括ACK或者ACK从接收点到达发送点的时间。
滑动窗口
TCP滑动窗口用来暂存两台计算机间要传送的数据分组。每台运行TCP协议的计算机有两个滑动窗口：一个用于数据发送，另一个用于数据接收。发送端待发数据分组在缓冲区排队等待送出。被滑动窗口框入的分组，是可以在未收到接收确认的情况下最多送出的部分。滑动窗口左端标志X的分组，是已经被接收端确认收到的分组。随着新的确认到来，窗口不断向右滑动。
TCP协议软件依靠滑动窗口机制解决传输效率和流量控制问题。它可以在收到确认信息之前发送多个数据分组。这种机制使得网络通信处于忙碌状态，提高了整个网络的吞吐率，它还解决了端到端的通信流量控制问题，允许接收端在拥有容纳足够数据的缓冲之前对传输进行限制。在实际运行中，TCP滑动窗口的大小是可以随时调整的。收发端TCP协议软件在进行分组确认通信时，还交换滑动窗口控制信息，使得双方滑动窗口大小可以根据需要动态变化，达到在提高数据传输效率的同时，防止拥塞的发生。
称窗口左边沿向右边沿靠近为窗口合拢，这种现象发生在数据被发送和确认时。当窗口右边沿向右移动时将允许发送更多的数据，称之为窗口张开。这种现象发生在另一端的接收进程读取已经确认的数据并释放了TCP的接收缓存时。
当右边沿向左移动时，称为窗口收缩。Host Requirements RFC强烈建议不要使用这种方式。但TCP必须能够在某一端产生这种情况时进行处理。 如果左边沿到达右边沿，则称其为一个零窗口。
滑动窗口原理图：
在这个图中，我们将字节从1至11进行标号。接收方通告的窗口称为提出的窗口，它覆盖了从第4字节到第9字节的区域，表明接收方已经确认了包括第3字节在内的数据，且通告窗口大小为6。我们知道窗口大小是与确认序号相对应的。发送方计算它的可用窗口，该窗口表明多少数据可以立即被发送。当接收方确认数据后，这个滑动窗口不时地向右移动。窗口两个边沿的相对运动增加或减少了窗口的大小。我们使用三个术语来描述窗口左右边沿的运动：
-
称窗口左边沿向右边沿靠近为窗口合拢。这种现象发生在数据被发送和确认时。
-
当窗口右边沿向右移动时将允许发送更多的数据，我们称之为窗口张开。这种现象发生在另一端的接收进程读取已经确认的数据并释放了T C P的接收缓存时。
- 当右边缘向左移动时，称之为窗口收缩。
滑动窗口流量控制管理：
1、流量控制是管理两端的流量，以免会产生发送过块导致收端溢出，或者因收端处理太快而浪费时间的状态。用的是：滑动窗口，以字节为单位
2、窗口有3种动作：展开（右边向右），合拢（左边向右），收缩（右边向左）这三种动作受接收端的控制。
合拢：表示已经收到相应字节的确认了
展开：表示允许缓存发送更多的字节
收缩（非常不希望出现的，某些实现是禁止的）：表示本来可以发送的，现在不能发送；但是如果收缩的是那些已经发出的，就会有问题；为了避免，收端会等待到缓存中有更多缓存空间时才进行通信。
发端窗口的大小取决于收端的窗口大小rwnd（TCP报文的窗口大小字段）和拥塞窗口大小cwnd（见拥塞控制）
发端窗口大小 = min{ rwnd , cwnd };
3、关闭窗口：窗口缩回有个例外，就是发送rwnd=0表示暂时不愿意接收数据。这种情况下，发端不是把窗口收缩，二是停止发送数据。（为了比避免死锁，会用一些探测报定时发送试探，见定时器一节）
4、问题：某些时候，由于发端或收端的数据很慢，会引起大量的1字节数据痛惜，浪费很多资源。
（1）、发端的进程产生数据很慢时候，时不时的来个1字节数据，那么TCP就会1字节1字节的发送，效率很低。
解决方法（Nagle算法）：
a、将第一块数据发出去
b、然后等到发送缓存有足够多的数据（最大报文段长度），或者等到收端确认的ACK时再发送数据。
c、重复b的过程
（2）、收端进程由于消耗数据很慢，所以可能会有这么一种情况，收端会发送其窗口大小为1的信息，然后有是1字节的传输
解决办法（2种）
a、Clark方法：在接收缓存的一半变空，或者有足够空间放最大报文长度之前，宣告接收窗口大小为0
b、推迟确认：在对收到的报文段确认之前等待到足够的接收缓存，或者等待到一个时间段
