tcp IP 状态图 （一）

看Tcp IP 卷一状态时一直就有迷惑（且很久），网上相关信息一直没看到相关说明，今天和同事聊下，还算弄清楚些。主要是画红色的部分。几个方面要注意。

1：书上说了，此状态图是一个子集。－－说明不能代表全部情况。

2：下面的二条线的说明。其实图中是有三种类型的线，实线有二种，粗一点，细一点。再加上虚线。

我给他重注一次： 粗线代表：客户端正常状态变迁

                 虚线代表：服务端正常状态变迁

                 细线代表：客户端，服务端异常状态变迁

一：先看看三次握手的图

  二：模拟场景，客户端发送syn,由closed-->syn_sent进入了syn_sent状态，服务器端收到syn,由listen-->syn_recv 进入了syn_recv状态。

   客户端下一步正常是收到syn +ack ,然后进入established,图中有那条线（我没标记）， 再看最大的红圈那条线，客户端从syn_sent-->syn_recv，为什么会这样，是因为只收到syn 没收到ack,所以重发syn 进入了syn_recv，同时发送了syn+ack。

   再往后有点复杂：

情况一：此时的服务端收到ack,且发送对客户端重发的syn的应答ack, 然后进入estabblished状态(虚线)。[客syn_recv 服:established]

    此时再分case:

        case 1: 客户端收到ACK，也进入到established. 

        case 2: 客户端没收到ack , 客户端会不断发送syn ,直到超时发送 RST 后进入closed,服务器端连接复位。

        case 3: 客户端没收到ack , 关闭发送FIN,服务端收到FIN 被动关闭。

        case 4: 客户端没收到ack, 服务端关闭发FIN,但不会收到ack,不断重发FIN，2分钟后，发送RST，二端复位。

情况二：此时的服务端没有收到ack，还处于syn_recv。  [客syn_recv 服:syn_recv]

    此时再分case:

        case 1: 客户端超时发送 RST 后进入closed,服务器端收到RST 后到Listen 态。[复原]

        case 2: 客户端发送FIN,但不会收到ack 超时关闭，不断重发FIN，2分钟后，发送RST，服务端收到RST 也复位。

        case 3: 服务端发送FIN,但不会收到ack 超时关闭，不断重发FIN，2分钟后，发送RST，客户端收到RST也复位。

无论何时一个报文段发往基准的连接出现错误，tcp 都会发出一个复位报文段（ＲＳＴ）。收到RST的一方将终止连接，并通知应用层连接复位（recv =0）。