TCP三次握手和四次握手中常见面试问题的具体分析-优快云博客

本文链接：https://blog.youkuaiyun.com/neverthe/article/details/105385171

TCP三次握手和四次握手中常见面试问题的具体分析

一、TCP三次握手和四次挥手的通俗理解：

图1 三次握手

图2 四次挥手

二、TCP三次握手和四次挥手的详细过程：

1.三次握手

注：对服务器发出的接收报文的解释：

• 为什么seq=y呢，因为服务器发出的确认接收报文里面可能携带了数据（这里的数据并不是说真正传送的数据，而是TCP协议里的一些规定，比如说：TCP规定，SYN报文段不能携带数据，但要消耗掉一个序列号；TCP标准规定，ACK的报文段可以携带数据，但如果不携带数据则不消耗序列号），因此需作以标记

•为什么ack=x+1呢，因为之前发送的请求连接报文里面ack=x，我们接收方必须给它一个回复，表明你之前发送给我的收到了，就传一个x+1过去，表明我下次想要这个数据，如果说第三次挥手中客户端真的发了x+1，就表明客户端也收到了服务端刚才对它的确认，至此三次握手结束。

2.四次挥手

与“三次挥手”一样，在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性，一旦出现某一方发出的TCP报文丢失，便无法继续"挥手"，以此确保了"四次挥手"的顺利完成。

注：TCP三次握手和四次挥手的过程中也是TCP报文段的传送，TCP报文段包括首部和数据部分。因此三次握手和四次挥手其实就是报文传送，也需要符合相关规定。

与握手相关的首部字段：

•同步SYN：用来连接请求或连接接收

•seq（序列号）:数据包本身的第一个序号

•ack（确认号）：表示已收到对方刚才发送的数据，我希望下一次接收以ack开始的数据包。

•ACK:要想使确认号字段（ack）有效，就必须是使ACK置1。

与挥手相关的首部字段：

•终止FIN:用来释放一个连接。当其置1时，表明数据传送结束，用释放连接。其可由任何一方发出。

•seq（序列号）:数据包本身的第一个序号

•ack（确认号）：表示已收到对方刚才发送的数据，我希望下一次接收以ack开始的数据包。

•ACK:要想使确认号字段（ack）有效，就必须是使ACK置1。

注：刚开始对为什么连接过程中需要有seq和ack这2个首部字段不是很理解，后来认为握手和挥手它也是报文段，既然是报文段，它就可能携带数据，因此就需要seq和ack。

三、为什么要进行三次握手，只进行前两次握手不行吗？

“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。对这句话做以下解释：

两次握手的情况：

如果客户端想建立连接，给服务端发了一个连接请求（SYN），但是由于网络中种种情况，导致没有及时到达服务端，这就导致客户端在很长一段时间中没有收到回复消息（ACK），这时客户端又给服务端发送一个SYN，这次的发送和接收的很顺利，很快就收到了ACK，但是这时之前的SYN终于到了服务端，服务端规规矩矩的为这个SYN申请资源，然后返回ACK。由于之前的SYN已经失效了，所以客户端也不会去理会这个ACK，但是傻乎乎的服务端并不知道这个SYN已经失效了，一直为他委会着资源，这就造成了资源的浪费。

三次握手的情况：

在两次握手中服务端不知道当前这个SYN是不是有效的，三次握手就很好的解决了这个问题，第三次握手就是客户端给服务端回复第二次握手，这也就是说服务端会等第三次握手的到来，如果第三次握手迟迟不来，服务端就可以识别这个SYN是无效的，就会将他的资源释放了。还有一种情况就是第三次握手由于网络中的种种原因失败了，这时候客户端认为自己已经连接好了，就会给服务端发送数据，服务端由于没有收到第三次握手，就会以RST包对客户端响应，收到RST的的客户端就知道第三次握手没有成功，就会重新连接。

第三次握手失败:

如果第三次握手的ACK传输失败，导致服务端迟迟没有收到ACK，就会释放资源，这时候客户端认为自己已经连接好了，就会给服务端发送数据，服务端由于没有收到第三次握手，就会以RST包对客户端响应。但是实际上服务端会因为没有收到客户端的ACK多次发送SYN+ACK，次数是可以设置的，如果最后还是没有收到客户端的ACK，则释放资源。

四、为什么要进行四次挥手？

因为释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，表示我已经收到了你发给我释放连接的信号，你先等着，等我处理完手头的数据我就和你返回一个我这边也同意连接释放的信号，然后过了一会，被动方服务器处理完了手头的事情，就可以释放连接了，就返回给主动方客户端一个FIN=1以及相关首部字段。所以被动方服务器的挥手用了两次，而不是像三次握手那样在接收到客户端的请求后，立马同意建立请求，进行连接。

五、time_wait状态在哪一端出现？什么时候出现？time_wait作用是什么？为什么客户端在TIME-WAIT阶段要等2MSL?

time_wait状态在哪一端出现？

准确的说：time_wait状态应该是出现在主动请求释放连接的那一端，而不是客户端，因为释放连接可以由任何一方发起，但是我们通常说出现在客户端的原因是我们默认这个主动请求释放由客户端发起。

time_wait状态发生在什么时候？

time_wait状态发生在客户端向服务端发送最后一次ACK确认之后。

什么是MSL？

MSL是Maximum Segment Lifetime英文的缩写，中文可以译为“报文最大生存时间”，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。我的理解就是，一个报文段最长就只能活1MSL，所以一个报文从发送到被接受最多持续1MSL时间。

MSL由时间等待计时器设置。

为什么不直接关闭要进入等待状态？

•保证客户端发送的ACK报文段能够到达服务器，从而保证tcp连接能够进行可靠的关闭。

这个很好理解，如果客户端发动ACK后就立刻关闭，那么如果ACK丢失的话，服务端就会一直处于等待关闭确认的状态，超时后再发送关闭请求时，此时的客户端已经关闭，那么服务端就无法进行正常的关闭。

•保证此次连接的数据段消失，防止失效的数据段。

为什么是2MSL？

报文的最长传送时间是MSL，假设第四次挥手之后，客户端开始进入time_wait状态，假设第四次挥手所用的时间是MSL，此时time_wait已经过了1MSL，但是由于网络原因，服务端没有收到，于是服务端又重新穿了FIN+SYN，假设它也用了MSL才到客户端，此时一共用了2MSL，也就是time_wait时2MSL。也就是设置2MSL的原因是给服务端里一次重传的机会。那么当重传收到后，此时客户端重启2MSL计时器，重传一次确认。注意：2MSL里面并不包含客户端重传确认的时间，客户端重传确认的时间是在另一个2MSL里面，如果服务端还是没有接收到这个重传确认，那么就继续此过程一直循环下去。