【面试高频】TCP三次握手、四次挥手【为什么建立连接协议是三次握手，而关闭连接却是四次握手？/为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？/如果已经建立连接，但是客户端】

三次握手

第一次握手：在建立连接时，客户端发送SYN包（SYN=1）到服务器，
			并进入了SYN_SENT状态，等待服务端的确认；

第二次握手：服务端接收到SYN包后，必须确认客户端的SYN，
			同时自己也发送一个SYN包，即SYN+ACK包，此时服务端进入了SYN_RCVD状态；

第三次握手：客户端收到服务端的SYN+ACK包，向服务端发送一个确认包ACK，
			此包发送完毕后，客户端和服务端就进入了ESTABLISHDE状态，完成三次握手。

第一步：客户机的TCP首先向服务器的TCP发送一个连接请求报文段。这个特殊的报文段中不含应用层数据，其首部中的SYN标志位被置为1。另外，客户机会随机选择一个起始序列号 seq = x（连接请求报文不携带数据，但要消耗掉一个序号）。

第二步：服务器的TCP收到连接请求报文段后，如同意建立连接，就向客户机发回确认，并未该TCP连接分配TCP缓存和变量。在确认报文段中，SYN和ACK位都被置为1，确认号字段的值为x+1,并且服务器随机产生起始序列号 seq = y（确认报文不携带数据，但也要消耗掉一个序号）。确认报文段同样不包含应用层数据。

第三步：当客户机收到确认报文段后，还要向服务器给出确认，并且也要给该连接分配缓存和变量。这个报文段的ACK标志位被置为1，序号字段为 x+1，确认号字段 ack = y+1。该报文段可以携带数据，如果不携带数据则不消耗序号。

四次挥手

第一步：客户机打算关闭连接，就向其TCP发送一个连接释放报文段，并停止再发送数据，主动关闭TCP连接，该报文段的FIN标志位被置为1，seq = u，它等于前面已传送过的数据的最后一个自己的序号加1（FIN报文段即使不携带数据，也要消耗一个序号）。TCP是全双工的，即可以想象成是一条TCP连接上有两条数据通路。当发送FIN报文时，发送FIN报文的一段就不能再发送数据，也就是关闭了其中一条数据通路，但对方还可以发送数据。

第二步：服务器收到连接释放报文段后即发出确认，确认号是ack = u+1，而这个报文段自己的序号是v，等于它们前面已传送过的数据的最后一个字节的序号加1。此时，从客户机到服务器这个方向的连接就释放了，TCP连接处于半关闭状态。但服务器若发送数据，客户机仍要接收，即从服务器到客户机这个方向的连接并未关闭。

第三步：若服务器已经没有要向客户机发送的数据，就通知TCP释放连接，此时其发出FIN=1的连接释放报文段。

第四步：客户机收到连接释放报文段后，必须发出确认。在确认报文段中，ACK字段被置为1，确认号ack = w+1，序号seq = u+1。此时TCP连接还没有释放掉，必须经过时间等待计时器设置的时间2MSL后，A才进入到连接关闭状态。

---

面试高频问题：

1．为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？

这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的.

2．为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？

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

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

TCP还设有一个保活机制。显然，如果客户端出现了故障，服务端不能一直等下去。若等了一段时间还没有收到客户端的任何数据，服务端就会发送一个探测报文段，若一连发送10个探测报文段仍然没有反应，服务端就认为是客户端出现了故障，就会关闭连接。

4.TCP的三次握手过程？为什么会采用三次握手，若采用二次握手可以吗？

建立连接的过程是利用客户服务器模式，假设主机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的资源浪费。

5.tcp的保活计时器

除时间等待计时器外,TCP还设有一个保活计时器 keepalive timer))设想有这样的情况：
客户已主动与服务器建立了TCP连接。但后来客户端的主机突然出故障。显然,服务 器以后就不能再收到客户发来的数据。因此,应当有措施使服务器不要再白白等待下去,这 就是使用保活计时器。服务器每收到一次客户的数据,就重新设置保活计时器,时间的设置 通常是两小时。若两小时没有收到客户的数据,服务器就发送一个探测报文段,以后则每隔 75秒钟发送一次。若一连发送10个探测报文段后仍无客户的响应,服务器就认为客户端出 了故障,接着就关闭这个连接 .

6.为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？

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

---

文章持续更新：欢迎各位小伙伴关注我的公众号：菜丸的程序屋。希望将我的不足之处给予指点，谢谢大家。喜欢Java，热衷学习的小伙伴可以加我微信: CaiWan_Y