TCP协议详解之TCP状态转移

状态转移综述

  TCP连接的任意一端在任意时刻都处于某种状态，当前状态可以通过netsata命令查看。
完整的状态转移图，描绘了所有的TCP状态以及可能的状态转换。

  服务器通过listen系统调用进入LISTEN状态，被动等待客户端连接，因此执行的是所谓的被动打开。服务器一旦监听到某个连接请求(收到同步报文段)，就将该连接放入内核等待队列中，并向客户端发送带SYN标志的确认报文段。此时该连接处于SYN_RCVD状态。如果服务器成功地接收到客户端发送回的确认报文段，则该连接转移到ESTABLISHED状态(连接双方能够进行双向传输的状态)。
  当客户端主动关闭连接时(通过close或shutdown系统调用向服务器发送结束报文段)，服务器通过返回确认报文段使连接进入CLOSE_WAIT状态。这个状态的含义很明确:等待服务器应用程序关闭连接。通常，服务器检测到客户端关闭连接后，也会立即给客户端发送一个结束报文段来关闭连接。这将使连接转移到LAST_ACK状态，以等待客户端对结束报文段的最后一次确认。一旦确认完成了，连接就彻底关闭了。

---

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

  conenct调用失败将使连接立即返回到初始的CLOSE状态。如果客户端成功收到服务器的同步报文段和确认，则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状态的服务器直接收到带确认信息的结束报文段(注意，不是先收到确认报文段，再收到结束报文段)。
  处于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连接和断开过程中，客户端和服务器端的状态转移：

TIME_WAIT状态

  客户端连接在收到服务器的结束报文段之后，并没有直接进入CLOSED状态，而是转移到TIME_WAIT状态。在这个状态下，客户端连接要等待一段长为2MSL(Maximum Segment Life,报文段最大生存时间)的时间，才能完全关闭。MSL是TCP报文段在网络中的最大生存时间，标准文档建议值是2min。
TIME_WAIT状态存在的原因：
  1.可靠地终止TCP连接。
  2.保证让迟来的TCP报文段有足够的时间被识别并丢弃。
  第一个原因。如果用于确认服务器结束报文段的客户端TCP报文段丢失，那么服务器将重发结束报文段。因此客户端需要停留在某个状态以处理重复收到的结束报文段(即向服务器发送确认报文段)。否则，客户端将以复位报文段来回应服务器，服务器则认为这是一个错误，因为它期望的是一个TCP确认报文段。
  在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状态将导致它不能立即重启。可以通过socket选项SO_REUSEADDR来强制进程立即使用处于TIME_WAIT状态的连接占用的端口。