TCP状态转移
粗虚线表示典型的服务器端的连接状态，粗实线表示典型的客户端连接状态转移
CLOSED为起点
1、TCP连接的建立
首先服务器通过listen系统调用进入LISTEN状态，被动等待客户端连接，因此执行是被动打开。
下面就是三次握手过程：
第一次握手，服务器监听到连接请求（即SYN同步报文段），并将该连接放入内核等待队列。即客户端发送SYN请求建立连接，并且客户端进入SYN_SENT状态。
第二次握手，向客户端发送带SYN标志的确认报文段（SYN+ACK）。此时该连接处于SYN_RCVD状态。
第三次握手，服务器如果成功收到客户端发回的确认报文段（ACK），则该连接转移到ESTABLISHED状态。
ps：为什么是三次握手，如果采用二次握手会怎么样？
如果是两次握手可能会产生这样的一种情况：
客户端第一次向服务器发送连接请求，然而服务器没有收到这个请求。过一会儿客户端没收到确认报文段，会第二次给服务器发送一个连接请求，这次服务器收到了，并且确认，然后建立连接开始传数据。然后第一次的那个请求报文在网络上转了半天终于到了服务器，这时服务器会把它当成客户端的一次新请求，并且同意，但此时客户端已经建立了连接，不会理会，但是服务器会一直等待客户端发送数据，从而造成资源浪费。
所以两次握手少了，四次握手冗余，三次握手刚好。
2、TCP连接的断开
即四次挥手：
第一次挥手，客户端主动关闭连接（close/shutdown系统调用向服务器发送结束报文段）。客户端主动发送一个结束报文段（FIN），同时客户端进入到FIN_WAIT_1状态，在收到服务器专门的确认报文段后会进入FIN_WAIT_2状态。
第二次挥手，服务器通过返回确认报文段（ACK），使连接进入到CLOSE_WAIT状态，同时客户端进入到FIN_WAIT_2状态。（CLOSE_WAIT状态：等待服务器应用程序关闭连接）
第三次挥手，服务器检测到客户端关闭连接后，会立即给客户端发送一个结束报文段（FIN+ACK）来关闭连接，这时连接会进入到LAST_ACK状态，以等待客户端对结束报文段的最后一次确认。同时客户端会进入TIME_WAIT状态。
第四次挥手，客户端对结束报文段确认，连接彻底关闭。
ps：当客户端处于FIN_WAIT状态时，服务器处于CLOSE_WAIT状态，这一对状态是可能发生半关闭的状态。
半关闭状态（half close）：TCP连接允许两个方向的数据传输被独立关闭。人话：通信一端发送结束报文段给对方，告诉它已经完成数据发送，但允许继续接收来自对方的数据，直到对方也发送结束报文段关闭连接。
3、TIME_WAIT状态
从客户端连接在收到服务器的结束报文段（报文段6）之后，并没有直接进人CLOSED状态，而是转移到TIME_WAIT状态。在这个状态，客户端连接要等待一段长为2MSL (Maximum Segment Life，报文段最大生存时间〉的时间，才能完全关闭。MSL是TCP报文段在网络中的最大生存时间，标准文档RFC 1122的建议值是2MSL。
TIME_WAIT状态存在的原因有两点：
- 可靠地终止TCP连接。
- 保证让迟来的TCP报文段有足够的时间被识别并丢弃。
第一个原因很好理解。假设图中用于确认服务器结束报文段6的TCP报文段7丢失，那么服务器将重发结束报文段。因此客户端需要停留在某个状态以处理重复收到的结束报文段（即向服务器发送确认报文段)。否则，客户端将以复位报文段来回应服务器，服务器则认为这是一个错误，因为它期望的是一个像TCP报文段7那样的确认报文段。
第二个原因：在Linux系统上，一个TCP端口不能被同时打开多次（两次及以上)。当一个TCP连接处于TIME_WAIT状态时，将无法立即使用该连接占用着的端口来建立一个新连接。如果不存在TIME_WAIT状态，则应用程序能够立即建立一个和刚关闭的连接相似的连接（这里说的相似，是指它们具有相同的IP地址和端口号)。这个新的、和原来相似的连接被称为原来的连接的化身。新的化身可能接收到属于原来的连接的、携带应用程序数据的TCP报文段（迟到的报文段)，这显然是不应该发生的。
另外，另外，因为TCP报文段的最大生存时间是MSL，所以坚持2MSL时间的TIME_WAIT状态能够确保网络上两个传输方向上尚未被接收到的、迟到的TCP报文段都已经消失（被中转路由器丢弃)。因此，一个连接的新的化身可以在2MSL时间之后安全地建立，而绝对不会接收到属于原来连接的应用程序数据，这就是TIME_WAIT状态要持续2MSL 时间的原因。