什么是四次挥手?

　　1. 主动断开方(客户端/服务端)-发送一个 FIN，用来关闭主动断开方(客户端/服务端)到被动断开方(客户端/服务端)的数据传送

　　2. 被动断开方(客户端/服务端)-收到这个 FIN，它发回一 个 ACK，确认序号为收到的序号加1 。和 SYN 一样，一个 FIN 将占用一个序号

　　3. 被动断开方(客户端/服务端)-关闭与主动断开方(客户端/服务端)的连接，发送一个FIN给主动断开方(客户端/服务端)

　　4. 主动断开方(客户端/服务端)-发回 ACK 报文确认，并将确认序号设置为收到序号加1

　　为什么连接的时候是三次握手，关闭的时候却是四次握手?

　　1. 建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。

　　2. 关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了,所以服务器可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接。因此，服务器ACK和FIN一般都会分开发送，从而导致多了一次。

　　为什么TCP挥手每两次中间有一个 FIN-WAIT2等待时间?

　　主动关闭的一端调用完close以后(即发FIN给被动关闭的一端， 并且收到其对FIN的确认ACK)则进入FIN_WAIT_2状态。如果这个时候因为网络突然断掉、被动关闭的一段宕机等原因，导致主动关闭的一端不能收到被动关闭的一端发来的FIN(防止对端不发送关闭连接的FIN包给本端)，这个时候就需要FIN_WAIT_2定时器， 如果在该定时器超时的时候，还是没收到被动关闭一端发来的FIN，那么直接释放这个链接，进入CLOSE状态。

　　为什么客户端最后还要等待2MSL?为什么还有个TIME-WAIT的时间等待?

　　1. 保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，服务器已经发送了FIN+ACK报文，请求断开，客户端却没有回应，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

　　2. 防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，这样新的连接中不会出现旧连接的请求报文。

　　3. 2MSL，最大报文生存时间，一个MSL 30 秒，2MSL = 60s

　　客户端 TIME-WAIT 状态过多会产生什么后果?怎样处理?

　　1. 作为服务器，短时间内关闭了大量的Client连接，就会造成服务器上出现大量的TIME_WAIT连接，占据大量的tuple /tApl/ ，严重消耗着服务器的资源，此时部分客户端就会显示连接不上

　　2. 作为客户端，短时间内大量的短连接，会大量消耗的Client机器的端口，毕竟端口只有65535个，端口被耗尽了，后续就无法在发起新的连接了

　　3. 在高并发短连接的TCP服务器上，当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上

　　高并发可以让服务器在短时间范围内同时占用大量端口，而端口有个0~65535的范围，并不是很多，刨除系统和其他服务要用的，剩下的就更少了短连接表示“业务处理+传输数据的时间 远远小于 TIMEWAIT超时的时间”的连接

　　4. 解决方法：

　　用负载均衡来抗这些高并发的短请求; 服务器可以设置 SO_REUSEADDR 套接字选项来避免 TIME_WAIT状态，TIME_WAIT 状态可以通过优化服务器参数得到解决，因为发生TIME_WAIT的情况是服务器自己可控的，要么就是对方连接的异常，要么就是自己没有迅速回收资源，总之不是由于自己程序错误导致的强制关闭，发送 RST 包越过TIMEWAIT状态，直接进入CLOSED状态

　　服务器出现了大量 CLOSE_WAIT 状态如何解决?

　　大量 CLOSE_WAIT 表示程序出现了问题，对方的 socket 已经关闭连接，而我方忙于读或写没有及时关闭连接，需要检查代码，特别是释放资源的代码，或者是处理请求的线程配置。

　　服务端会有一个TIME_WAIT状态吗?如果是服务端主动断开连接呢?

　　1. 发起链接的主动方基本都是客户端，但是断开连接的主动方服务器和客户端都可以充当，也就是说，只要是主动断开连接的，就会有 TIME_WAIT状态

　　2. 四次挥手是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发

　　3. 由于TCP连接时全双工的，因此，每个方向的数据传输通道都必须要单独进行关闭