【转】TCP（协议号6）的方方面面

转：http://blog.sina.com.cn/s/blog_6002b97001018fxh.html

第一：TCP连接的建立（也就是所谓的三次握手）过程。

第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态

第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

为什么A还要发送一次确认呢（即为什么是三次握手而不是两次,公司常考），这主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。

所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常情况。A发出连接请求，但因连接请求报文丢失而未收到确认。于是A再重传一次连接请求。后来A 收到了确认，建立了连接。数据传输完毕后，就释放了连接。A共发送了两个连接请求报文段，其中第一个丢失，第二个到达了B。没有“已失效的连接请求报文 段”。

现假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达B。本来 这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，误以为是A又发出一次新的连接请求。于是就向A发出确认报文段，同意建立连接。假定不采用 三次握手，那么只要B发出确认，新的连接就建立了。

由于现在A并没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B却以为新的运输连接已经建立了，并一直等待A发来数据。B的许多资源就这样白白浪费了。

采用三次握手的方法可以防止上述现象的发生。例如在刚才的情况下，A不会向B的确认发出确认。B由于收不到确认，就知道A并没有要求建立连接。

第二：TCP连接释放过程。

TCP协议的连接是全双工连接，一个TCP连接存在双向的读写通道。
简单说来是 “先关读，后关写”，一共需要四个阶段。以客户机发起关闭连接为例：
1.服务器读通道关闭
2.客户机写通道关闭
3.客户机读通道关闭
4.服务器写通道关闭
关闭行为是在发起方数据发送完毕之后，给对方发出一个FIN（finish）数据段。直到接收到对方发送的FIN，且对方收到了接收确认ACK之后，双方的数据通信完全结束，过程中每次接收都需要返回确认数据段ACK。

详细过程：
第一阶段 客户机发送完数据之后，向服务器发送一个FIN数据段，序列号为i；
1.服务器收到FIN(i)后，返回确认段ACK，序列号为i+1，关闭服务器读通道；
2.客户机收到ACK(i+1)后，关闭客户机写通道；
（此时，客户机仍能通过读通道读取服务器的数据，服务器仍能通过写通道写数据）
第二阶段 服务器发送完数据之后，向客户机发送一个FIN数据段，序列号为j；
3.客户机收到FIN(j)后，返回确认段ACK，序列号为j+1，关闭客户机读通道；
4.服务器收到ACK(j+1)后，关闭服务器写通道。
这是标准的TCP关闭两个阶段，服务器和客户机都可以发起关闭，完全对称。
FIN标识是通过发送最后一块数据时设置的，标准的例子中，服务器还在发送数据，所以要等到发送完的时候，设置FIN（此时可称为TCP连接处于半关闭状
态，因为数据仍可从被动关闭一方向主动关闭方传送）。如果在服务器收到FIN(i)时，已经没有数据需要发送，可以在返回ACK(i+1)的时候就设置
FIN(j)标识，这样就相当于可以合并第二步和第三步。

第三：TCP流量控制过程（主要是根据接收方的窗口大小确定发送放的发送速率）。

滑动窗口的概念由此诞生。由于数据的发送方和接收方并不一定有相同的数据处理能力，为了避免数据发送过快而超过对方的接收能力，TCP采用了流量控制机制，接收方在TCP的包头里面通告了发送方自己的接收窗口，也就是还能够接收的最多的数据包，这样TCP就不会过度发包而超过对方的接收能力。

第四：TCP拥塞控制过程。

1986年10月，一件事情的发生使得TCP开启了一个新领域，从美国LBL到UC
Berkeley的数据吞吐量从32Kbps下降到40bps。是什么原因导致了数据吞吐量如此严重的下降呢？原来在TCP的控制机制里面只考虑到了接收
端的接受能力，而忽略了一个很重要的方面，那就是没有考虑到网络自己的传输能力，从而造成了整个网络崩溃的发生。从这以后，TCP的研究课题就开始多了一
个方向，那就是拥塞控制。

与上面介绍的TCP的流控比较下就可以发现，流控主要是考虑接收端，不要发送过快，超过对方的接收能力，而拥塞控制则是要考虑到整个网络环境，使其负载不能超过网络的最大承受能力。

为了防止网络的拥塞现象，TCP提出了一系列的拥塞控制机制。最初由V.
Jacobson在1988年的论文中提出的TCP的拥塞控制由“慢启动(Slow start)”和“拥塞避免(Congestion
avoidance)”组成，后来TCP Reno版本中又针对性的加入了“快速重传(Fast
retransmit)”、“快速恢复(Fast Recovery)”算法，再后来在TCP
NewReno中又对“快速恢复”算法进行了改进，近些年又出现了选择性应答( selective
acknowledgement,SACK)算法。

由于需要考虑拥塞控制和流量控制两个方面的内容，因此TCP的真正的发送窗口=min(rwnd,
cwnd)。但是rwnd是由对端确定的，网络环境对其没有影响，所以在考虑拥塞的时候我们一般不考虑接收端通知窗口（rwnd）的值，我们暂时只讨论如何确定拥塞窗口（cwnd）值的
大小。关于cwnd的单位，在TCP中是以字节来做单位的，我们假设TCP每次传输都是按照MSS大小来发送数据的，因此你可以认为cwnd按照数据包个数来做单位也可以理解，所以有时我们说cwnd增加1也就是相当于字节数增加1个MSS大小。

慢启动：最初的TCP在连接建立成功后会向网络中发送大量的数据包，这样很容易导致网络中路由器缓存空间耗尽，从而发生拥塞。因此新建立的连接不能够一开始就大量发送数据包，而只能根据网络情况逐步增加每次发送的数据量，以避免上述现象的发生。具体来说，当新建连接时，cwnd初始化为1个最大报文段(MSS)大小，发送端开始按照拥塞窗口大小发送数据，每当有一个报文段被确认，cwnd就增加1个MSS大小。这样cwnd的值就随着网络往返时间(Round
Trip
Time,RTT)呈指数级增长，事实上，慢启动的速度一点也不慢，只是它的起点比较低一点而已。我们可以简单计算下：

开始 ---> cwnd
= 1

经过1个RTT后 --->
cwnd = 2*1 = 2

经过2个RTT后 --->
cwnd = 2*2= 4

经过3个RTT后 --->
cwnd = 4*2 = 8

如果带宽为W，那么经过RTT*log2W时间就可以占满带宽。

拥塞避免：从慢启动可以看到，cwnd可以很快的增长上来，从而最大程度利用网络带宽资源，但是cwnd不能一直这样无限增长下去，一定需要某个限制。TCP使用了一个叫慢启动门限
(ssthresh)的变量，当cwnd超过该值后，慢启动过程结束，进入拥塞避免阶段。对于大多数TCP实现来说，ssthresh的值是
65536(同样以字节计算)。拥塞避免的主要思想是加法增大，也就是cwnd的值不再指数级往上升，开始加法增加。此时当窗口中所有的报文段都被确认时，cwnd的大小加1，cwnd的值就随着RTT开始线性增加，这样就可以避免增长过快导致网络拥塞，慢慢的增加调整到网络的最佳值。

发送方取拥塞窗口与通告窗口中的最小值作为发送上限。拥塞窗口是发送方使用的流量控制，而通告窗口则是接收方使用的流量控制。

上面讨论的两个机制都是没有检测到拥塞的情况下的行为，那么当发现拥塞了cwnd又该怎样去调整呢？

首先来看TCP是如何确定网络进入了拥塞状态的，TCP认为网络拥塞的主要依据是它重传了一个报文段。上面提到过，TCP对每一个报文段都有一个定时器，
称为重传定时器(RTO)，当RTO超时且还没有得到数据确认，那么TCP就会对该报文段进行重传，当发生超时时，那么出现拥塞的可能性就很大，某个报文段可能在网络中某处丢失，并且后续的报文段也没有了消息，在这种情况下，TCP反应比较“强烈”：

1.把ssthresh降低为cwnd值的一半

2.把cwnd重新设置为1

3.重新进入慢启动过程。

 
快重传：其实TCP还有一种情况会进行重传：那就是收到3个相同的ACK。TCP在收到乱序到达包时就会立即发送ACK，TCP利用3个相同的ACK来判定数据包的丢失，此时进行快速重传，快速重传做的事情有：

1.把ssthresh设置为cwnd的一半

2.把cwnd再设置为ssthresh的值(具体实现有些为ssthresh+3)

3.重新进入拥塞避免阶段。

后来的“快速恢复”算法是在上述的“快速重传”算法后添加的，当收到3个重复ACK时，TCP最后进入的不是拥塞避免阶段，而是快速恢复阶段。快速重传和快速恢复算法一般同时使用。快速恢复的思想是“数据包守恒”原则，即同一个时刻在网络中的数据包数量是恒定的，只有当“老”数据包离开了网络后，才能向网
络中发送一个“新”的数据包，如果发送方收到一个重复的ACK，那么根据TCP的ACK机制就表明有一个数据包离开了网络，于是cwnd加1。如果能够严格按照该原则那么网络中很少会发生拥塞，事实上拥塞控制的目的也就在修正违反该原则的地方。

快恢复：具体来说快速恢复的主要步骤是：

1.当收到3个重复ACK时，把ssthresh设置为cwnd的一半，把cwnd设置为ssthresh的值加3，然后重传丢失的报文段，加3的原因是因为收到3个重复的ACK，表明有3个“老”的数据包离开了网络。

2.再收到重复的ACK时，拥塞窗口增加1。

3.当收到新的数据包的ACK时，把cwnd设置为第一步中的ssthresh的值。原因是因为该ACK确认了新的数据，说明从重复ACK时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态。

第五：TCP超时重传算法。

重传定时器：TCP 必须维护一个重传定时器，以进行超时重传

问题：如何设置超时时间间隔 RTO？

时间间隔太短则可能导致大量不必要的重传；太长则导致性能下降；

TCP 采用了一个高度动态的算法，来不断的调整时间间隔，这个算法就是 Jacobson 1988
算法

 

在此算法中， TCP 需要维护几个变量：

 

1）、RTT：对往返时间的当前最佳估计值

当一个数据段被发送出去后，TCP 启动定时器，如果在定时器过期之前确认数据段回来的话，则 TCP
测量一下这次确认所花的时间 M，然后根据如下公式更新 RTT。

                          
平均往返时延RTT = a(旧的RTT） + (1-a)M

其中 a 是平滑因子，典型的值是 7/8

这个公式的意思就是说，旧的 RTT 占有 7/8 的权重，新的往返时间占有 1/8
的权重

 

2)显然，计时器设置的超时重传时间RTO应略大于上面得出的平均往返时延RTTI，即：

                                      
 RTO = b*RTTI

这里的b是个大于1的系数。实际上，系数b是很难确定的。若取b很接近于1，发送端可以很及时地重传丢失的报文段，因此效率得到提高。但若报文段并未丢失而仅仅是增加了一点时延，那么过早地重传未收到确认的报文段，反而会加重网络的负担。因此TCP原先的标准推荐b值取为2.

 

3) Karn 算法：
Jacobson 算法只用于处理正常的情况，但是当发生重传后，如果收到一个确认，这时候就不用这个算法来调整 RTO
值了。因为你无法判断这个确认是针对第一次传输，还是后来的重传。在这种情况下，采用 Karn 算法来调整 RTO 的值
。

Karn 算法很简单：
1）、 对于发生重传的数据段，在收到确认后，不更新
RTT。但是，报文段每重传一次，就将重传时间增大一些（不然重传时间就得不到更新）：

                         
 新的重传时间 = c *
旧的重传时间

 
系数c的典型值是2。当不再发生报文段的重传时，才根据报文段的往返时间更新平均往返时延RTTI和重传时间的数值。即：

2）、在重传的时候，RTO 是倍增的，直到达到最大值的限制。如果重传超过一定的次数，TCP 连接会断开
3）、在重传并收到确认后，如果下一次的数据段没有发生重传（即一次性收到确认），则又恢复 Jacobson
算法。

 

参考文献：

（1）计算机网络（第四版）；谢希仁

（2）http://blog.csdn.net/great3779/article/list/1