TCP协议补充

在前面的运输层简介中介绍了运输层中的UDP协议和TCP协议。TCP是面向连接的、可靠的通讯协议。TCP是通过什么机制来保证通讯质量、以及如何处理异常等都在这篇博文中进行介绍。
其中TCP是通过自动重传（ARQ）、流量控制、拥塞控制等机制来保证其通信质量的。其中自动重传就是发送方在规定的时间内没有收到对方的确认信息，会重新传送之前的报文（没有收到确认的报文）。而流量控制便是发送端要根据接收方的接收窗口的大小来调整发送数据的大小，防止发送过多的数据导致接收方接收不了而丢弃。拥塞控制便是通过控制分组进入网络中的数量，而不至于网络中分组过多导致网络负载而丢失分组。

TCP的拥塞控制

首先要理解拥塞，拥塞指的是流入网络中的分组过多，超过了网络能承受的最大负荷而导致网络通信不正常的现象。网络中的链路容量、交换节点中的缓存、处理机的处理速度等都属于网络资源，要使网络资源提升并不是简单的提升其中某个资源或这些资源（宽带、缓存、处理速度）。因为这些资源都会相互影响，所以需要平衡的增加资源。如某个结点缓存的容量太小了，到达该结点的分组因无存储空间暂存而不得被丢弃。现在将该节点的容量扩展到非常大，于是到达该结点的分组都能缓存在队列中，不受任何限制。由于处理机的速度和宽带没有提高，因此分组排队时间会大大增加，发送方只好把它们进行重传，重传的分组又继续在队列中排队，这样周而复始…从而使网络通信吞吐量更低。
拥塞常常趋于恶化，如路由器没有足够的缓存空间，它便会丢弃一些新到的分组。当分组被丢弃时，发送这一分组的源点就会重传这一分组，甚至可能重传多次，这样就会引起更多的分组流入网络和被网络中的路由器丢弃。可见拥塞引起的重传并不会缓解网络的拥塞，反而会加剧网络的拥塞。
拥塞控制就是防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器以及链路的容量。进行拥塞控制有一个提前，就是网络能够承受现有的网络负荷。进行拥塞控制需要付出代价，这首先需要获得网络内部流量分布的信息，在实施拥塞控制时，还需要在结点之间交换信息和各种命令，以便选择控制的策略和实施控制，这样就产生了额外开销。拥塞控制有时需要预留一些资源给个别用户（网络管理人）单独使用，利用这些资源进行拥塞控制。网络中的通讯如下图：

TCP中拥塞控制的算法有四种，即慢开始、拥塞避免、快重传和快恢复。发送方会维持一个叫做拥塞窗口的状态变量，其值大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口不超过拥塞窗口。
发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就可以再增大一些，以便把更多的分组发送出去，这样就可以提高网络的利用率。但是只要网络出现拥塞或可能出现拥塞，就必须把拥塞窗口减小一些，以减少注入到网络中的分组数，从而缓解网络出现的拥塞。其中判断网络拥塞的依据就是出现超时，因为现在通信线路的传输质量一般都很好，因传输出差错而丢弃分组的概率是很小的（不到1%）。
慢开始算法的思路是这样的：主机发送数据是由小到大逐渐增大发送窗口，即先试探网络中的通信量，在刚刚开始发送报文段时，先把初始拥塞窗口cwnd设置为不超过2至4个SMSS的数值，具体值和SMSS有关，其实就是限制初始拥塞窗口的字节数。在每收到一个对新的报文的确认后，拥塞窗口最多能增加一个SMSS的数值。拥塞窗口CWND每次的增加=min(N,SMSS)，N便是对新的报文段确认的字节数。慢开始拥塞控制窗口的增加以指数形式增加。所以其中的慢并不是指cwnd的增长速率慢，而是指在TCP开始发送报文段时设置的拥塞窗口值小。
为了防止拥塞窗口增长过大引起网络拥塞，还需要设置一个慢开始门限状态变量。拥塞窗口大于慢开始门限值时使用拥塞避免算法，而拥塞窗口小于慢开始门限值时使用慢开始算法。
拥塞避免算法的思路是这样的：让拥塞窗口缓慢地增大，每经过一个往返时间RTT就把发送方的拥塞窗口值加1个smss,而不像慢开始阶段那样加倍增长。此算法拥塞窗口按线性规律缓慢增长。这样使网络比较不容易出现拥塞。
快重传算法的思路是这样：让发送方尽早知道发生了个别报文段的丢失，即接收方不使用捎带确认，而是要立即发送确认。即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。发送方在收到报文确认后会立即进行重传，这样就不会超时。快重传算法可以避免个别报文段在网络中因为别的原因丢失而误认为网络发生了拥塞的现象。这能提升网络的使用效率。
快恢复算法的思路是这样的，在网络中发现了报文丢失，不启动慢开始，而是把发送方门限值调整为此时拥塞窗口的一半，并开始执行拥塞避免算法。这样的目的是使网络的使用效率更高。

在实际的应用中，发送方窗口的上限值=MIn[rwnd,cwnd]，其中rwnd是接收方反馈的接收窗口值，cwnd为发送方的拥塞窗口值。
主动队列管理AQM,路由器中的队列通常都是按照先进先出FIFO的规则处理到来的分组，由于队列长度总是有限的，队列已满时就会丢弃新到的分组。丢失分组后，发送方出现超时重传，使TCP进入拥塞控制的慢开始。然而在网络中通常有很多条TCP连接，所以可能会影响多条TCP连接，结果使许多TCP连接在同一时间突然都进入到慢开始状态，而网络恢复正常后，其通信量又突然增大很多。这就是TCP中的全局同步。
为了避免发生网络中的全局同步现象，在网络层中提出了主动队列管理AQM（active queue Management）算法，主动的含义就是不要等到路由器队列长度达到最大值时才不得不丢弃后面到达的分组，而应当在队列长度达到某个值得警惕的数值时，就主动丢弃到达的分组。AQM可以有不同实现方法，如曾流行多年的随机早期检测RED。RED需要路由器维持两个参数，队列长度最小门限和最大门限值，分组到达后，要是当前的平均队列长度小于最小门限，放入队列；要是平均队列长度超过最大门限，则丢弃新到达的分组；介于最小门限和最大门限两者之间，则概率性丢弃分组。现在已经不使用RED算法了。

TCP的中流量控制

流量控制就是让发送方的发送速率不要太快，要让接受方来得及接受。利用滑动窗口可以很方便地在TCP连接上实现对发送方的流量控制。发送方的发送窗不能超过接受方给出的接收窗口的数值，窗口单位是字节。TCP中存在一个持续计时器用来检测零窗口的情况。接收到对方的零窗口通知，发送方便会启动一个持续计时器，若持续计时器设置的时间到期，就发送一个零窗口探测报文段，对方会给出现在的窗口值，如仍然为0，那么发送方重置持续计时器，不为零则通信。这个持续计时器是为了打破死锁，接收方给发送发0窗口后，发送方不在发送数据，过了一段时间接收方缓存中的数据处理完了，有了空间接收数据，于是给发送发发送非零窗口想继续传输数据，但是这个非零窗口的报文又丢失了，发送方便会一直等待。这就是死锁。
应用程序把数据传送到TCP的发送缓存后，剩下的发送任务就TCP来控制了，具体的发送机制由客户自己来选择（有最大报文段长度MSS、PUSH、计时器等机制）。为了提高网络的使用效率，TCP广泛使用Nagle算法。nagle算法如下：若发送应用进程把要发送的数据逐个字节送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去；后续的数据缓存起来，等收到对方的确认后再一次发送出去，继续缓存…只有在收到确认报文后才会继续发送。Nagle同时还规定当缓存数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。同样对于接受方也存在同样的问题（糊涂窗口综合征），接收到方缓存已满时，要是上层一次只接受缓存中的一个字节数据，那么网络的通信效率会很低。解决方法：让接收方等待一段时间，使得接受方缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半空闲的空间。接收方才会发出确认报文。在通信中尽量使用捎带确认的方法来提高通信的效率。

超时重传时间

ARQ（自动重传请求）机制很简单，但是重传时间的确认确实很复杂，时间设置太短会照成很多不必要的重传，使网络负荷增大，但要是超时重传时间设置得过长，则又使网络的空闲时间增大，降低传输效率。TCP采用了一种自适应算法，它记录每次报文的往返时间RTT，TCP保留了RTT的一个加权平均往返时间（这个时间更加平滑）。新的RTT_S=(1-a)x(旧的RTT_S) + a x (新的RTT样本)。RFC推荐a的值为1/8。
显然超时计时器设置的超时重传时间RTO应略大于上述的RTT_S，其推荐值RTO = RTT_S+4 x RTT_D。其中RTT_D是RTT的偏差的加权平均值，新的RTT_D = (1 - b) x （旧的RTT_D）+ b x | RTT_S -新的RTT |，b的推荐值为1/4.若报文重传，则把超时重传时间RTO增大一些，典型的做法是取新的重传时间为旧的重传时间的2倍。这样可以有效的避免重传带来的问题。