Tcp可靠性和网络优化

Tcp可靠性和网络优化

Tcp可靠性传输的原理

发送方每次发送一个报文段后，接收方必须要回复给发送方已经收到的确认信息。

出现差错的时候，如果发送放发送了一个报文后，在一段时间内还没收到确认返回，这时候就要重新发送刚才报文，称为超时重传。（发送方的角度）

在接收方，并不知道报文的丢失，在发送方重发的报文过来后，接收以后，突然之前在网络中丢失的那段报文突然到达了，原来是因为网络延迟的缘故，这时候接收方应该立即丢弃这个报文，但是还需要向发送方发送确认，只不过这时候发送方接收到这个如果是重复的确认不做任何的处理。

连续的ARQ协议保障可观的信道利用率。如果每次我们发送一个报文，等待第一个报文的确认再发送第二个报文，这样的话好是好，但是信道的利用率太低，所以采用持续的发送窗口，位于发送窗口中的报文可以连续发送出去，每次收到一个分组的确认，窗口向前滑动一个分组。

Tcp可靠性传输的实现

滑动窗口机制

Tcp的滑动窗口是以字节为单位的，本文以一个个的报文段来进行描述窗口。发送方为A，维护发送窗口，接收方为B，维护接收窗口。发送窗口A的状态需要三个指针来描述，P1，P2，P3，小于P1的是已经发送并已经收到确认的部分，而大于P3部分的是不允许发送的部分。P3-P1=A，即发送窗口或者通知窗口。P2-P1=已经发送的但是尚未收到确认的字节数。P3-P2=允许发送但是尚未发送的字节数。

如果B接受某序列的顺序为a,b,c, 但是由于某种原因a没有收到，b,c收到了，但是此时B发送的确认报文段中的确认号任然是a的而不是其它的，而b,c就缓存在B中的接收窗口中。

如果A在继续发送数据的时候P2和P3重合了，意味着发送窗口已满，还没收到一个确认号，可用窗口减少到0，所以必须立即停止发送。当然如果这时候A窗口中的所有报文都发送出去了，而且B已经接受到了，但是确认报文却在网络传输中丢失了，过了一段时间后，那么A只能认为B没有收到（由超时计时器控制）重传这部分数据。

接受窗口接收按序到达的但是还没有被应用程序接收的数据以及未按序到达的。如果接受程序来不及读取收到的数据，接收缓存最终就会被填满，接收窗口就减小到0。这时候接收方就不能接收报文了。

虽然A的发送窗口是根据B的接收窗口设置的，但是在同一时刻A的发送窗口并不总是和B的接收窗口一样大。因为网络有一些滞后，或者A还要根据自己的情况调整数值。

Tcp的流量控制

流量控制的意思就是发送方的发送速率不要太快，要让接收方来得及接收。

总的来说就是发送方的发送窗口不能超过接收方给出的接收窗口的的数值。接收方在发送确认ACK的时候附带这样一个参数。

如果接收方的由于某种原因（a,报文没有按序到达，缓存后面的报文;b,接收方来不及处理这么多报文）使得接收窗口一直减少到0，及不允许发送方再发送数据了。直到主机B重现新发送一个不为0的新窗口过来为止。

为了防止这种情况，当B的接收窗口为0后，在某一时刻，缓存释放了又有了一些新空间，于是发送一个报文通知A有空间了，可以开始传输数据了。然而这个报文在传输的过程中丢失了，但是A并不知道，一直在等待，从而造成一种相互等待的死锁。Tcp为每个连接设置了一个持续计数器，只要Tcp接收到一个对方窗口为0的通知，就启动持续计时器。每隔一段时间去发送一个0窗口的探测报文，获取对方的窗口值是否为0.

Tcp的拥塞控制

若网络中的某一资源的需求已经超过了该资源所能提供的有效的部分 ，网络的性能就开始下降了，就称发生拥塞了。

流量控制和拥塞控制的区别

拥塞控制是防止过多的数据注入到网络，使得网络中的路由器或者链路过载。它是一个全局性的过程，涉及到所有的主机和路由器以及与降低网络传输性能有关的所有因素。相反，流量控制往往是指的点对点的通信量的控制，是个端到端的问题。流量控制所要做的就是抑制发送方发送的速率，以便接收方来得及接收。

轻度拥塞：当网络的吞吐量明显小于理想的吞吐量。

拥塞状态：网络的吞吐量反而随提供的负载的增大而下降。

死锁：负载继续增大，网络的吞吐量下降到零，网络已经无法工作。

拥塞控制的手段

慢开始，拥塞避免，快重传，快恢复。

慢开始

发送方维持一个叫做拥塞窗口的状态变量，它的大小取决于网络额拥塞程度，动态变化。当主机开始发送数据的时候，不是立即把大量的数据注入到网络，而是采用从小到大的方式探测，将拥塞窗口从小到大进行增加。通常在最开始的时候，将拥塞窗口的大小设置为一个最大报文的长度。然后每次收到接收方的一个确认报文，将窗口的大小扩充2倍，因此每经过一个传输轮次，拥塞窗口就加倍。

拥塞避免

由于慢开始的策略，拥塞窗口一直增加，为了防止拥塞窗口增长过大引起网络拥塞，还需要设置一个慢开始门限。

拥塞窗口 < 慢开始门限，使用慢开始算法。

拥塞窗口 > 慢开始门限，停止使用慢开始算法，改用拥塞避免算法。

拥塞窗口 = 慢开始门限，既可以使用慢开始算法，也可以使用拥塞避免算法。

拥塞避免算法的目的是让拥塞窗口缓慢增大，每次收到一个确认以后，不是像慢开始一样，将拥塞窗口加倍，而是拥塞窗口大小加1。这样拥塞窗口就按照线性缓慢增长。

无论在慢开始阶段还是拥塞避免阶段，只要发送放判断网络出现拥塞（根据是没有按时收到确认），就要把慢开始的门限设置为出现拥塞时的一半，然后把拥塞窗口设置为1，重新执行慢开始算法。

快重传和快恢复

当不使用快重传机制，发送方设置的超时计时器时限已到，但是还没有收到确认，那么很可能发送放的报文在网络中已经被丢弃了，这时候发送方就认为已经发生网络拥塞了，将慢开始门限减半，拥塞窗口置为1，执行慢开始算法。

快重传算法是要求，每收到一个失序的报文段后就立即发出重复确认（目的是让发送方及早知道报文段有没有达到对方）而不是等待自己发送数据时才进行捎带确认。

如果有四个个报文abcdef，ab已经收到，分别发送了确认报文A，B，但是，c报文的发送丢失了，这时候在接收到d，e，f 的报文后，显然不能进行确认，应及时发送对b的确认，也就是说，发送放一共会收到b报文的四次确认，其中有三次是重复的。

快重传算法规定，一旦发送方一连收到三个重复的确认，就立即重传对方没有收到的报文c，不必等到c的超时计时器到期再重传。

与快重传配合使用的还有快恢复,当发送方一连收到三个重复确认，就把慢开始的门限减半，但是不执行慢开始算法，依然执行拥塞避免算法（因为发送方是通过超时来判断网络是否拥塞，才会将慢开始门限减半，执行慢开始算法）。

随机早期检测 RED

前面讨论的Tcp的拥塞控制都没有和网络层联系起来。路由器的队列通常都是按照先进先出的规则来处理分组的。由于队列的长度总是有限，所以当队列已满时，以后到达的分组都将被丢弃。

但是这种尾部丢弃策略有时候会是的拥塞控制恰得其反，如果某一时间段导致一连串的分组都丢失，这时候就会使得发送方超时重发，Tcp进入慢开始阶段，使得发送方突然把发送速率降到最低。更为严重的是，网络中的很多Tcp连接通常是复用在IP数据报中。这种情况下，若发生尾部丢弃，就可能影响多条Tcp连接，结果使得很多Tcp连接在同一时刻都进入到慢开始阶段，使得网络通讯量迅速降低很多，而在网络恢复的时候，其通讯量又突然增大很多。为了避免这种情况，可以在路由器中采用随机早期检测措施

路由器的队列维持两个参数，队列长度最小门限和最大门限。经验值证明，最大门限等于最小门限的值的两倍是合适的。当每一个分组到达时，RED组都要计算平均队列长度。

若平均队列长度 < 最小门限，则把新到达的分组放入队列中。

若平均队列长度 > 最大门限，则把新到达的分组全部丢弃。

若平均队列长度在最小门限和最大门限之间，则按照一定的概率将新到达的分组进行丢弃。