图解TCP-IP协议(1)(2)

图2给出了TCP通信过程中的状态转移图，理解此图是我们理解TCP-IP协议的关键。

图2 TCP状态转移图

状态图详细解读：

1.CLOSED：起始点，在超时或者连接关闭时候进入此状态。

2.LISTEN：服务端在等待连接过来时候的状态，服务端为此要调用socket，bind,listen函数，就能进入此状态。此称为应用程序被动打开(等待客户端来连接)。

3.SYN_SENT:客户端发起连接，发送SYN给服务器端。如果服务器端不能连接，则直接进入CLOSED状态。

4.SYN_RCVD：跟3对应，服务器端接受客户端的SYN请求，服务器端由LISTEN状态进入SYN_RCVD状态。同时服务器端要回应一个ACK，同时发送一个SYN给客户端;另外一种情况，客户端在发起SYN的同时接收到服务器端得SYN请求，客户端就会由SYN_SENT到SYN_RCVD状态。

5.ESTABLISHED：服务器端和客户端在完成3次握手进入状态，说明已经可以开始传输数据了。

以上是建立连接时服务器端和客户端产生的状态转移说明。相对来说比较简单明了，如果你对三次握手比较熟悉，建立连接时的状态转移还是很容易理解。

下面，我们来看看连接关闭时候的状态转移说明，关闭需要进行4次双方的交互，还包括要处理一些善后工作(TIME_WAIT状态)，注意，这里主动关闭的一方或被动关闭的一方不是指特指服务器端或者客户端，是相对于谁先发起关闭请求来说的：

6.FIN_WAIT_1:主动关闭的一方，由状态5进入此状态。具体的动作是发送FIN给对方。

7.FIN_WAIT_2:主动关闭的一方，接收到对方的FIN-ACK(即fin包的回应包)，进入此状态。

8.CLOSE_WAIT：接收到FIN以后，被动关闭的一方进入此状态。具体动作是接收到FIN，同时发送ACK。(之所以叫close_wait可以理解为被动关闭方此时正在等待上层应用发出关闭连接指令)

9.LAST_ACK：被动关闭的一方，发起关闭请求，由状态8进入此状态。具体动作是发送FIN给对方，同时在接收到ACK时进入CLOSED状态。

10.CLOSING：两边同时发起关闭请求时，会由FIN_WAIT_1进入此状态。具体动作是接收到FIN请求，同时响应一个ACK。

11.TIME_WAIT：最纠结的状态来了。从状态图上可以看出，有3个状态可以转化成它，我们一一来分析：

a.由FIN_WAIT_2进入此状态：在双方不同时发起FIN的情况下，主动关闭的一方在完成自身发起的关闭请求后，接收到被动关闭一方的FIN后进入的状态。

b.由CLOSING状态进入:双方同时发起关闭，都做了发起FIN的请求，同时接收到了FIN并做了ACK的情况下，由CLOSING状态进入。

c.由FIN_WAIT_1状态进入：同时接受到FIN(对方发起)，ACK(本身发起的FIN回应)，与b的区别在于本身发起的FIN回应的ACK先于对方的FIN请求到达，而b是FIN先到达。这种情况概率最小。

关闭的4次连接最难理解的状态是TIME_WAIT，存在TIME_WAIT的2个理由：

1.可靠地实现TCP全双工连接的终止。

2.允许老的重复分节在网络中消逝。

附：

慢热启动算法 – Slow Start

首先，我们来看一下TCP的慢热启动。慢启动的意思是，刚刚加入网络的连接，一点一点地提速，不要一上来就像那些特权车一样霸道地把路占满。新同学上高速还是要慢一点，不要把已经在高速上的秩序给搞乱了。

慢启动的算法如下(cwnd全称Congestion Window)：

1)连接建好的开始先初始化cwnd = 1，表明可以传一个MSS大小的数据。

2)每当收到一个ACK，cwnd++; 呈线性上升

3)每当过了一个RTT，cwnd = cwnd*2; 呈指数让升

4)还有一个ssthresh(slow start threshold)，是一个上限，当cwnd >= ssthresh时，就会进入“拥塞避免算法”(后面会说这个算法)

所以，我们可以看到，如果网速很快的话，ACK也会返回得快，RTT也会短，那么，这个慢启动就一点也不慢。

拥塞避免算法 – Congestion Avoidance

前面说过，还有一个ssthresh(slow start threshold)，是一个上限，当cwnd >= ssthresh时，就会进入“拥塞避免算法”。一般来说ssthresh的值是65535，单位是字节，当cwnd达到这个值时后，算法如下：

1)收到一个ACK时，cwnd = cwnd + 1/cwnd

2)当每过一个RTT时，cwnd = cwnd + 1

这样就可以避免增长过快导致网络拥塞，慢慢的增加调整到网络的最佳值。很明显，是一个线性上升的算法。

拥塞状态时的算法

前面我们说过，当丢包的时候，会有两种情况：

1)等到RTO超时，重传数据包。TCP认为这种情况太糟糕，反应也很强烈。

sshthresh = cwnd /2

cwnd 重置为 1

进入慢启动过程

2)Fast Retransmit算法，也就是在收到3个duplicate ACK时就开启重传，而不用等到RTO超时。

TCP Tahoe的实现和RTO超时一样。

TCP Reno的实现是：

cwnd = cwnd /2

sshthresh = cwnd

进入快速恢复算法——Fast Recovery

上面我们可以看到RTO超时后，sshthresh会变成cwnd的一半，这意味着，如果cwnd<=sshthresh时出现的丢包，那么TCP的sshthresh就会减了一半，然后等cwnd又很快地以指数级增涨爬到这个地方时，就会成慢慢的线性增涨。我们可以看到，TCP是怎么通过这种强烈地震荡快速而小心得找到网站流量的平衡点的。

快速恢复算法 – Fast Recovery

TCP Reno

这个算法定义在RFC5681。快速重传和快速恢复算法一般同时使用。快速恢复算法是认为，你还有3个Duplicated Acks说明网络也不那么糟糕，所以没有必要像RTO超时那么强烈。 注意，正如前面所说，进入Fast Recovery之前，cwnd 和 sshthresh已被更新：

cwnd = cwnd /2

sshthresh = cwnd

然后，真正的Fast Recovery算法如下：

cwnd = sshthresh + 3 * MSS (3的意思是确认有3个数据包被收到了)

重传Duplicated ACKs指定的数据包

如果再收到 duplicated Acks，那么cwnd = cwnd +1

如果收到了新的Ack，那么，cwnd = sshthresh ，然后就进入了拥塞避免的算法了。

如果你仔细思考一下上面的这个算法，你就会知道，上面这个算法也有问题，那就是——它依赖于3个重复的Acks。注意，3个重复的Acks并不代表只丢了一个数据包，很有可能是丢了好多包。但这个算法只会重传一个，而剩下的那些包只能等到RTO超时，于是，进入了恶梦模式——超时一个窗口就减半一下，多个超时会超成TCP的传输速度呈级数下降，而且也不会触发Fast Recovery算法了。

TCP New Reno

于是，1995年，TCP New Reno(参见 RFC 6582 )算法提出来，主要就是在没有SACK的支持下改进Fast Recovery算法的——

当sender这边收到了3个Duplicated Acks，进入Fast Retransimit模式，开发重传重复Acks指示的那个包。如果只有这一个包丢了，那么，重传这个包后回来的Ack会把整个已经被sender传输出去的数据ack回来。如果没有的话，说明有多个包丢了。我们叫这个ACK为Partial ACK。

一旦Sender这边发现了Partial ACK出现，那么，sender就可以推理出来有多个包被丢了，于是乎继续重传sliding window里未被ack的第一个包。直到再也收不到了Partial Ack，才真正结束Fast Recovery这个过程

我们可以看到，这个“Fast Recovery的变更”是一个非常激进的玩法，他同时延长了Fast Retransmit和Fast Recovery的过程。