三次握手与四次挥手及常见问题

答：建立连接的过程是利用客户服务器模式，假设主机A为客户端，主机B为服务器端。

（1）TCP的三次握手过程：主机A向B发送连接请求；主机B对收到的主机A的报文段进行确认；主机A再次对主机B的确认进行确认。

（2）采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。

（3）采用两次握手不行，原因就是上面说的实效的连接请求的特殊情况。

答：因为TCP有个半关闭状态，假设A.B要释放连接，那么A发送一个释放连接报文给B，B收到后发送确认，这个时候A不发数据，但是B如果发数据A还是要接收，这叫半关闭。然后B还要发给A连接释放报文，然后A发确认，所以是4次。

在tcp连接握手时为何ACK是和SYN一起发送？这里ACK却没有和FIN一起发送呢？

是因为tcp是全双工模式，接收到FIN时意味将没有数据再发来，但是还是可以继续发送数据。

1）为了保证客户端发送的最后一个ACK报文段能够到达服务器。这个ACK报文段可能丢失，因而使处在LAST_ACK状态的服务器收不到确认。服务器会超时重传FIN+ACK报文段，客户端就能在2MSL时间内收到这个重传的FIN+ACK报文段，接着客户端重传一次确认，重启计时器。最好，客户端和服务器都正常进入到CLOSED状态。如果客户端在TIME-WAIT状态不等待一段时间，而是再发送完ACK报文后立即释放连接，那么就无法收到服务器重传的FIN+ACK报文段，因而也不会再发送一次确认报文。这样，服务器就无法按照正常步骤进入CLOSED状态。

2）防止已失效的连接请求报文段出现在本连接中。客户端在发送完最后一个ACK确认报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

为什么TIME_WAIT状态还需要等2*MSL（Max SegmentLifetime，最大分段生存期）秒之后才能返回到CLOSED状态呢？

答：因为虽然双方都同意关闭连接了，而且握手的4个报文也都发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SENT状态到ESTABLISH状态那样），但是我们必须假想网络是不可靠的，你无法保证你最后发送的ACK报文一定会被对方收到，就是说对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。

time_wait 是「服务器端」的状态？or 「客户端」的状态？

• RE：time_wait 是「主动关闭 TCP 连接」一方的状态，可能是「客服端」的，也可能是「服务器端」的

• 一般情况下，都是「客户端」所处的状态；「服务器端」一般设置「不主动关闭连接」

服务器在对外服务时，是「客户端」发起的断开连接？还是「服务器」发起的断开连接？

• 正常情况下，都是「客户端」发起的断开连接

• 「服务器」一般设置为「不主动关闭连接」，服务器通常执行「被动关闭」

• 但 HTTP 请求中，http 头部 connection 参数，默认为 close，则服务端处理完请求会主动关闭 TCP 连接，若为close，则服务器在响应时就会断开连接，这时在高并发的情况下，服务端产生TIME_WAIT过多的情况就很正常了。

• 虽然HTTP默认Connection值为close，但是，现在的浏览器发送请求的时候一般都会设置Connection为keep-alive了，这个时候一般就都是客户端发起的断开了

在高并发情况下，服务器端存在大量的time_wait状态的TCP连接，应该如何处理？

• 服务器端允许 time_wait 状态的 socket 被重用

• 缩减 time_wait 时间，设置为 1 MSL（即，2 mins）