TCP状态转移图

服务端：

      通过listen系统调用，进入LISTEN状态，被动等待客户端连接，因此执行的是所谓的被动打开，服务器一旦监听到某个连接请求(收到同步报文段)，就会将该连接放入内核等待队列中，冰箱客户端发送带SYN标志的的确认报文段。此时该连接处于SYN_RCVD状态。如果服务器成功的收到客户端发送回的确认报文段，则该连接转移到ESTABLISHED状态。ESTABLISHED状态时连接双方能够进行双向数据传输的状态。

      当客户端主动关闭连接时(通过close或shutdown系统调用向服务器发送结束报文段)，服务器通过返回确认报文段是连接进入CLOSE_WAIT状态。这个状态的含义很明确：等待服务器应用程序关闭连接。通常，服务器检测到客户端关闭连接后 ，也会立即给客户端发送一个结束报文段来关闭连接。这将使连接转移到LAST_ACK状态，以等待客户端对结束报文段的最后一次确认。一旦确认完成，连接就彻底关闭了。

 

客户端：

       客户端通过connect系统调用主动与服务器建立连接。connect系统调用首先给服务器发送一个同步报文段，使连接转移到SYN_SENT状态，然后connect系统调用肯能因为如下2个原因失败返回：

1 如果connect连接的目标端口不存在(未被任何进程监听)，或者该端口仍被处于TIME_WAIT状态的连接所占用，则服务器给客户端发送 一个复位报文段，connect调用失败。

2 如果目标端口存在，但connect在超时时间内未收到服务器的确认报文段，则connect系统调用失败。

       connect调用失败将连接立即返回初始的CLOSED状态，如果客户端成功收到服务器的同步报文段和确认，则connect调用成功返回，连接转移至ESTABLISHED状态。

当客户端主动关闭时，它将向服务器发送一个结束报文段，同时连接进入FIN_WAIT_1状态，若此客户端客户端收到服务器专门用于确认目的的确认报文段，则连接转移至FIN_WAIT_2状态。当客户端处于FIN_WAIT_2状态时，服务器处于CLOSE_WAIT状态，这一对状态是可能发生半关闭的状态。此时如果服务器也关闭连接(发送结束报文段)，则客户端给予确认并进入TIME_WAIT状态。客户端也能直接从FIN_WAIT_1进入TIME_WAIT状态。

      处于FIN_WAIT_2状态的客户端需要等待服务器发送结束报文段，才能转移至TIME_WAIT状态，否则它将一直停留在这个状态。连接停留在FIN_WAIT_2状态可能发生在：客户端执行半关闭后，未等服务器关闭连接就强行退出了。此时客户端连接由内核接管，可称之为孤儿连接。linux为了防止连接长时间存留在内核中，定义了2个变量：/proc/sys/net/ipv4/tcp_max_orphans 和 /proc/sys/net/ipv4//tcp_fin_timeout. 前者指定内黑能接管的孤儿连接数目,后者指定孤儿连接在内核中生存的时间。

 

TIME_WAIT:

客户端在收到服务器的结束报文段后，并没有直接进入CLOSED状态，而是转移到TIME_WAIT状态，在这个状态，客户端连接要等待一段长为2MSL(Maximum Segment Life 报文段最大生存时间)，才能完全关闭。

MSL 标准文档RFC 1122的建议值是2 min。

TIME_WAIT存在的原因有2点：

1 可靠的终止TCP连接

2 保证让迟来的TCP报文段有足够的时间被识别并丢弃。

 

第一点，假设TCP连接关闭的 6，7报文段丢失，那么服务器会重发结束报文段。因此客户端需要停留在某个状态以处理重复收到的结束报文段(即向服务器发送第7个确认报文段)。否则，客户端将以复位报文段来回应服务器，服务器则认为这是一个错误，因为它期望的是一个像TCP报文段7那样的确认报文段。

 

2在linux系统上，一个TCP端口不能被同时打开多次(两次及以上)，当一个TCP连接处于TIME_WAIT状态时，我们无法立即使用该连接占用着的端口来建立一个新连接。反过来思考，如果不存在TIME_WAIT状态，则应用程序能立即建立一个和刚关闭的连接相似的连接(即相同的IP地址和端口号)。这个新的，和原来相似的连接称为原来的连接的化身(incarnation)。新的化身肯恶搞收到属于原来的连接的，携带应用程序数据的TCP报文段(迟到的报文段)，这显然是不应该发生的。这就是TIME_WAIT状态存在的第二个原因。

      另外，因为TCP报文段的最大生存时间是MSL,所以坚持2MSL时间的TIME_WAIT状态能够确保网络上连个传输方向上尚未被接受到的，迟到TCP报文段都已消失(被中转路由器丢弃)。因此一个连接新的化身可以在2MSL时间后安全的建立，而绝对不会收到属于原来应用程序的数据，这就是TIME_WAI状态要持续2MSL时间的原因。