关于四次挥手的很详细的解释

了解四次挥手前，需要先了解三次握手，不是因为两者有直接联系，而是因为有些概念性的东西我不想再重复了(lll￢ω￢)。毕竟握手相见，挥手再见。先相见才能再见呀。

关于四次挥手：

第一次：客户端发出连接释放报文，FIN=1， seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1), 此时。客户端进入FIN-WAIT-1（终止等待1）状态。此处的数据包FIN表示断开连接。

第二次：服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1, seq=v;此时服务端进入了CLOSE-WAIT（关闭等待）状态。

(客户端收到第二次挥手中服务器的确认请求后，就进入了FIN-WAIT-2终止等待2状态，等待服务器发送连接释放报文,在这个状态还需要接受服务器发送的最后的数据)

第三次：服务器数据发送完毕，开始发送连接释放报文，FIN=1，ack=u+1，seq=w。此后服务器进入LAST-ACK最后确认状态，等待客户端的确认。

第四次：客户端收到服务器的释放报文，发出确认。ACK=1， ack=w+1, seq=u+1.完了之后，客户端进入时间为2*MSL的TIME-WAIT时间等待状态，其中MSL为最长报文段的寿命。

(之后服务端收到了第四次中客户端的确认后，立即进入CLOSED状态)

什么客户端最后还要等待2MSL？

MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。

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

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

为什么建立连接是三次握手，关闭连接确是四次挥手呢？

建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。 而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。