TCP的连接&断连&状态转移过程

本篇文章参考Linux高性能服务器编程（作者：游双）一书的第三章。

首先来看下TCP的连接和断连：



上图示意了TCP连接的三次握手和断连时的四次握手。

首先在连接时，客户端向服务端发送一个SYN（序号为x）的同步报文，然后服务端对客户端发来的报文进行确认，向客户端发送ACK报文（x+1表示对客户端发来的序号为x的报文进行确认）和SYN报文（序号为y）。注意这里ACK报文和SYN报文是同一个报文，只是将此报文的TCP头部的ACK位和SYN为都置位。然后客户端在对服务器端发送来的报文进行确认，向服务器段发送ACK报文（y+1表示对服务器端序号为y的SYN报文进行确认），而SEQ=x+1表示这个报文是客户端发送的序号为x+1的报文。至此TCP通过三次握手，建立连接。

再来看TCP断连的4次握手过程：

首先客户端发送一个FIN终止连接报文（序号为u），然后服务器端对客户端发送来的序号为u的报文予以确认，向客户端发送ACK报文（u+1表示对对客户端的序号为u的报文予以确认）。这时TCP连接的这对套接字出于半关闭半连接的状态。然后服务器端在向客户端发送一个FIN终止连接报文（序号为y），客户端对服务器端的FIN报文予以确认返回ACK报文（y+1表示对服务器端的y号报文予以确认）。至此，TCP断连的四次握手完成。

接下来我们来看一下TCP的状态转移过程，如下为TCP状态转移过程图：

                 


上面虚线表示典型的服务器端连接的状态转移，实线表示典型的客户端连接的状态转移。CLOSED是一个假想的起始点，并不是一个实际的状态。

我们先讨论服务器的典型状态转移过程，此时我们说的连接状态都是指该连接的服务器端的状态。

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

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

下面讨论客户端的典型状态转移过程，此时我们说的连接状态都是指该连接的客户端的状态。

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

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状态），前提是处于FIN_WAIT_1状态的服务器直接接收到带确认信息的结束报文段（而不是先收到确认报文段，再收到结束报文段）。既是确认报文段和结束报文段同在一个报文段中发送（实质就是同时置此报文段TCP头部的ACK和FIN位）。

前面说过，处于FIN_WAIT_2状态的客户端需要等待服务器发送结束报文段，才能转移至TIME_WAIT状态，否则他将一直停留在这个状态。如果不是为了在半关闭状态下继续接受数据，连接长时间地停留在FIN_WAIT_2状态并无益处。连接停留在FIN_WAIT_2状态的情况可能发生在：客户端执行半关闭后，未等到服务器关闭连接就强行退出了。此时客户端连接由内核来接管，可称之为孤儿连接（和孤儿进程类似）。Linux为了防止孤儿连接长时间存留在内核中，定义了两个内核变量：/proc/sys/net/ipv4/tcp_max_orphans和/proc/sys/net/ipv4/tcp_fin_timeout。前者指定内核能接管的孤儿连接数目，后者指定孤儿连接在内核中生存的时间。

至此，我们简单地讨论了服务器和客户端程序的典型TCP状态转移路线。对应于下图所示的TCP连接的建立与断开过程，客户端与服务器端的状态转移如下图所示：



TIME_WAIT状态



从上图来看，客户端连接在收到服务器的结束报文段（TCP报文段6）之后，并没有直接进入CLOSED状态，而是转移到TIME_WAIT状态。在这个状态，客户端连接要等待一段长为2MSL（Maximum Segment Life，报文段最大生存时间）的时间，才能完全关闭。MSL是TCP报文段在网络中的最大生存时间，标准文档RFC1122的建议值是2min。

TIME_WAIT状态存在的原因有两点：

1、可靠的终止TCP连接

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

第一个原因很好理解。假设上图中用于确认服务器结束报文段6的TCP报文段7丢失，那么服务器将重发结束报文段。因此客户端需要停留在某个状态以处理重复收到的结束报文段（即向服务器发送确认报文段）。否则，客户端将以复位报文段来回应服务器，服务器则认为这是一个错误，因为它期望的是一个像TCP报文段7那样的确认报文段。

在Linux系统上，一个TCP端口不能被同时打开多次（两次及以上）。当一个TCP连接出于TIME_WAIT状态时，我们将无法立即使用该连接占用着的端口来建立一个新连接。反过来思考，如果不存在TIME_WAIT状态，则应用程序能够建立一个和刚关闭的连接相似的连接（这里说的相似，是指它们具有相同的IP地址和端口号）。这个新的、和原来相似的连接被称为原来的连接的化身。新的化身可能接受到属于原来的连接的、携带应用程序数据的TCP报文段（迟到的报文段），这显然是不应该发生的。这就是TIME_WAIT状态存在的第二个原因。

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

有时候我们希望避免TIME_WAIT状态，因为当程序退出后，我们希望能够立即重启它。但由于处在TIME_WAIT状态的连接还占用着端口，程序将无法启动（直到2MSL超时时间结束）。

对于客户端程序来说，我们通常不用担心上面描述的重启问题。因为客户端一般使用系统自动分配的临时端口号来建立连接，而由于随机性，临时端口号一般和程序上一次使用的端口号（还处于TIME_WAIT状态的那个连接使用的端口号）不同，所以客户端程序一般可以立即重启。

但如果是服务器主动关闭连接后异常终止，则因为它总是使用同一个知名服务端口号，所以连接的TIME_WAIT状态将导致它不能立即重启。不过，我们可以通过socket选项SO_REUSEADDR来强制进程立即使用出于TIME_WAIT状态的连接占用的端口。