TCP三次握手四次挥手、状态转移以及常见问题

三次握手过程：

1）第一次握手：客户端向服务端发送一个 SYN 报文（SYN = 1），并指明客户端的初始化序列号 ISN(x)，即图中的 seq = x，表示本报文段所发送的数据的第一个字节的序号。此时客户端处于 SYN_Send 状态。
SYN-SENT ：在发送连接请求后等待匹配的连接请求

2）第二次握手：服务器收到客户端的 SYN 报文之后，会发送 SYN 报文作为应答（SYN = 1），并且指定自己的初始化序列号 ISN(y)，即图中的 seq = y。同时会把客户端的 ISN + 1 作为确认号 ack 的值，表示已经收到了客户端发来的的 SYN 报文，希望收到的下一个数据的第一个字节的序号是 x + 1，此时服务器处于 SYN_REVD 的状态。
SYN-RECEIVED：在收到和发送一个连接请求后等待对连接请求的确认

3）第三次握手：客户端收到服务器端响应的 SYN 报文之后，会发送一个 ACK 报文，也是一样把服务器的 ISN + 1 作为 ack 的值，表示已经收到了服务端发来的的 SYN 报文，希望收到的下一个数据的第一个字节的序号是 y + 1，并指明此时客户端的序列号 seq = x + 1（初始为 seq = x，所以第二个报文段要 +1），此时客户端处于 Establised 状态。

四次挥手过程：

1）第一次挥手：客户端发送一个 FIN 报文（请求连接终止：FIN = 1），报文中会指定一个序列号 seq = u。并停止再发送数据，主动关闭 TCP 连接。此时客户端处于 FIN_WAIT1 状态，等待服务端的确认。
FIN-WAIT-1 - 等待远程TCP的连接中断请求，或先前的连接中断请求的确认；

2）第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。
CLOSE-WAIT - 等待从本地用户发来的连接中断请求；
此时的 TCP 处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待 2）状态，等待服务端发出的连接释放报文段。
FIN-WAIT-2 - 从远程TCP等待连接中断请求；

3）第三次挥手：如果服务端也想断开连接了（没有要向客户端发出的数据），和客户端的第一次挥手一样，发送 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态，等待客户端的确认。
LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认；

4）第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答（ack = w+1），且把服务端的序列值 +1 作为自己 ACK 报文的序号值（seq=u+1），此时客户端处于 TIME_WAIT （时间等待）状态。
TIME-WAIT - 等待足够的时间以确保远程TCP接收到连接中断请求的确认；

常见问题：

1. 为什么要三次握手
   三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。
   只有经过三次握手才能确认双发的收发功能都正常，缺一不可：
   第一次握手（客户端发送 SYN 报文给服务器，服务器接收该报文）：客户端什么都不能确认；服务器确认了对方发送正常，自己接收正常
   第二次握手（服务器响应 SYN 报文给客户端，客户端接收该报文）：
   客户端确认了：自己发送、接收正常，对方发送、接收正常；
   服务器确认了：对方发送正常，自己接收正常
   第三次握手（客户端发送 ACK 报文给服务器）：
   客户端确认了：自己发送、接收正常，对方发送、接收正常；
   服务器确认了：自己发送、接收正常，对方发送、接收正常

2. 三次握手过程中可以携带数据吗？
   第三次握手的时候，是可以携带数据的。但是，第一次、第二次握手绝对不可以携带数据
   原因：
   假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据，然后疯狂重复发 SYN 报文的话（因为攻击者根本就不用管服务器的接收、发送能力是否正常，它就是要攻击你），这会让服务器花费很多时间、内存空间来接收这些报文。

3. 如果第三次握手丢失了，客户端服务端会如何处理？
   服务器发送完 SYN-ACK 包，如果未收到客户端响应的确认包，也即第三次握手丢失。那么服务器就会进行首次重传，若等待一段时间仍未收到客户确认包，就进行第二次重传。如果重传次数超过系统规定的最大重传次数，则系统将该连接信息从半连接队列中删除。
   注意，每次重传等待的时间不一定相同，一般会是指数增长，例如间隔时间为 1s，2s，4s，8s…

4. 如果第三次挥手，客户端收到 ACK 后，服务端跑路了？
   客户端在收到「ACK」后，进入了 FIN-WAIT-2 状态，等待服务端发来的「FIN」包，而如果服务端跑路了，这个包永远都等不到。
   在 TCP 协议中，是没有对这个状态的处理机制的。但是协议不管，系统来凑，操作系统会接管这个状态，例如在 Linux 下，就可以通过 tcp_fin_timeout 参数，来对这个状态设定一个超时时间。

5. 为什么TIME_WAIT状态等待2msl？
   网络中可能存在来自发起方的数据段，当这些发起方的数据段被服务端处理后又会向客户端发送响应，所以一来一回需要等待 2 倍的时间。去向ACK消息最大存活时间（MSL) + 来向FIN消息的最大存活时间(MSL)。
   客户端发送的ACK消息可能丢包，服务端因为没有收到 ACK 消息，所以仍然认为当前连接是合法的，客户端重新发送 SYN 消息请求握手时会收到服务端的 RST 消息，连接建立的过程就会被终止防止延迟的数据段被其他使用相同源地址、源端口、目的地址以及目的端口的 TCP 连接收到。

6. 为什么很多close_wait状态？
   某种情况下对方关闭了socket链接，但是我方忙与读或者写，没有关闭连接。代码需要判断socket，一旦读到0，断开连接，read返回负，检查一下errno，如果不是AGAIN，就断开连接。在对方关闭连接之后服务器程序自己没有进一步发出ack信号（阻塞）。
   场景：
   mysql的事务没有正确处理，例如：没有rollback 或者 commit
   服务端接口耗时较长，客户端主动断开了连接，此时，服务端就会出现 close_wait。
   自己创建连接，执行sql，完成之后没有关闭连接
   问题：
   通常来说，一个CLOSE_WAIT会维持至少2个小时的时间（这个时间外网服务器通常会做调整，要不然太危险了）。
   close_wait的危害在于，在一个进程上打开的文件描述符超过一定数量，（在linux上默认是1024，可修改），新来的socket连接就无法建立了，因为每个socket连接也算是一个文件描述符。
   linux上，每个进程，都有其自身的资源限制，比如最大可以打开的文件描述符数量。
   解决：
   只能通过修改一下TCP/IP的参数，来缩短这个时间：修改tcp_keepalive_*系列参数有助于解决这个问题。