【通俗易懂】三次握手与四次挥手

1.三次握手

三次握手（Three-way Handshake）是指在建立一个TCP连接时，客户端和服务器会一共发送三个报文段。

初始时客户端和服务器都处于CLOSED状态，当服务器应用程序创建一个监听套接字时，服务器处于LISTEN状态。

1.第一次握手：客户端向服务器发送一个SYN报文段，报文段的首部中的标志位SYN置为1，另外还会指明自己的初始化序号seq=x，此时客户端处于SYN_SENT状态。

2.第二次握手：服务器收到SYN的报文段后，会以自己的SYN-ACK报文进行应答。该应答报文的首部有三个重要信息：首先SYN被置为1；其次，确认号字段ack=x+1；最后服务器选择自己的初始序号seq=y。该报文段表明：“我收到了你发起建立连接的请求，该请求报文的初始序号是x（确认号ack=x+1就表明了我收到了初始序号seq=x的报文），我同意建立该连接，我的初始序号是y。”此时服务器处于SYN_RCVD状态。

3.第三次握手：客户端收到SYN-ACK报文后，会发送一个ACK报文段，该报文段中序号seq=x+1，确认号ack=y+1，表明我已经收到了你的确认。此时客户端处于ESTABLISHED状态。

服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方以建立起了链接。

需要注意的是：第一次握手和第二次握手都只是消耗掉一个序号，但不能携带数据；第三次握手可以携带数据。

在这里插入图片描述

三次握手的作用？（为什么要进行三次握手？两次握手不行吗？）

1.1 三次握手的作用：

（1）确认双方的接受能力、发送能力是否正常。
（2）指定自己的初始化序列号，为后面的可靠传送做准备。

1.2 三次握手的目的是什么？

第一次握手：客户端给服务器发送一个报文，告知服务器：“我客户端想和你建立连接”。

服务器收到第一段报文后得出结论：客户端发送功能正常，服务器接收功能正常。

第二次握手：服务器收到报文后给客户端回复一个报文，告知客户端：“我服务器收到了你的请求，同意和你建立连接”。

客户端收到第二段报文后得出结论：客户端发送和接收功能都正常，服务器的发送接收功能也都正常。（但此时服务器不能确认客户端的接收功能和自己的发送功能是否正常）。

第三次握手：客户端收到第二段报文后给服务器回复一个报文，告知服务器：“我客户端收到了你的回复，知道你同意连接，那我们开始连接吧！”

服务器收到第三段报文后得出结论：客户端的接收功能和服务器的发送功能也都正常。

所以当服务器收到第三个报文后，两边就建立起了TCP连接。

1.3 两次握手为什么不行？

那么两次握手为什么不行就显而易见了，只有前两次握手的话，服务器就不能确认自己回复的报文段是否被客户端接收到，也就不知道自己的发送功能和客户端的接收功能是否正常。

2.四次挥手

四次挥手也就是客户端与服务器断开连接时，需要一共发送四个报文段来完成断开TCP连接。

初始时，客户端与服务器都处于ESTABLISHED状态，假如客户端发起断开连接的请求（服务器也可以发起），四次挥手过程如下：

1.第一次挥手：客户端发送一个FIN报文段，报文段中指定序号seq=u。此时客户端处于FIN_WAIT_1状态。

2.第二次挥手：服务器收到FIN报文后，立即发送一个ACK报文段，确认号为ack=u+1，序号设为seq=v。表明已经收到了客户端的报文。此时服务器处于CLOSE_WAIT状态。

在第二次挥手和第三次挥手之间的时间段内，由于只是半关闭的状态，数据还是可以从服务器传送到客户端的。

3.第三次挥手：如果数据传送完毕，服务器也想断开连接，那么就发送一个FIN报文，并重新指定一个序号seq=w，确认号还是ack=u+1，表明可以断开连接。

4.第四次挥手：客户端收到报文后，一样发出一个ACK报文段做出应答，上一次客户端发送的报文段序号为u，那么这次序号就是seq=u+1，确认号为ack=w+1。此时客户端处于TIME_WAIT状态，需要经过一段时间确保服务器收到自己的应答报文后，才会进入CLOSED状态。

服务器收到ACK报文后，就关闭连接，也处于CLOSED状态了。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-C1Vxa8bt-1635066684897)(C:\Users\15921\AppData\Roaming\Typora\typora-user-images\image-20211024164019559.png)]$

2.1为什么挥手需要四次？

这个问题可以换一种问法，也就是：中间两个步骤为什么不能合并呢？只要服务器收到客户端的FIN报文后，同时发送ACK报文和FIN报文不就可以三次挥手断开连接吗？

答案是通常情况下不行，因为ACK和FIN的触发时机是不一样的。我们要搞清楚一件事：服务器在收到FIN报文后可以立即发送ACK报文，表明我服务器收到了你的报文；但是服务器想发送FIN报文就需要等到处理完接收缓冲区的数据后才可以。所以挥手需要四次。

2.2为什么要等待2MSL？（为什么会存在一个TIME_WAIT状态？）

报文段最大生存时间MSL（Maximum SegmentLifetime），它是任何报文段被丢弃前在网络内的最长时间，超过这个时间报文将被丢弃。等待2MSL是为了确保服务器收到了最后一段ACK报文。

如何确保服务器收到了最后一段ACK报文？

如果服务器没有收到最后一段ACK报文，就会触发超时重传：服务器会再次发送FIN ACK报文。那么在2MSL的时间内，客户端会再次收到FIN报文，客户端就知道刚刚发送的ACK丢失，需要再次发送。

如果服务器收到了最后一段ACK报文，客户端在2MSL的时间内就不会收到任何报文，客户端就知道刚刚发送的ACK报文没有丢失，不需要再次发送，可以安心进入CLOSED状态了。