三次握手与四次挥手

三次握手与四次挥手

TCP报文

序号(seq)：TCP是面向字节流的。在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。seq是本报文段发送的数据组的第一个字节的序号。

确认号(ack)：确认序号为上次接收的序号的最后一个字节序号加1.只有确认标志位(ACK)为1的时候，确认序号才有效。

同步SYN（synchronization）：在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使SYN=1和ACK=1。因此SYN=1就表示这是一个连接请求或连接接受报文。

终止FIN（finis，意思是“完”“终”）：用来释放一个连接。当FIN=1时，表明此报文段的发送发的数据已发送完毕，并要求释放运输连接

确认ACK（acknowledgment）：仅当ACK = 1时确认号字段才有效，当ACK = 0时确认号无效。TCP规定，在连接建立后所有的传送的报文段都必须把ACK置为1。

TCP/IP协议中的三次握手and四次挥手

TCP/IP即传输控制/网络协议，是面向连接的协议，发送数据前要先建立连接，TCP提供安全可靠的服务。

三次握手：

• TCP/IP 协议是传输层的一个面向连接的安全可靠的一个传输协议，三次握手的机制是为了保证能建立一个安全可靠的连接，那么第一次握手是由客户端发起，客户端会向服务端发送一个报文，在报文里面：SYN标志位置为1，表示发起新的连接。
• 当服务端收到这个报文之后就知道客户端要和我建立一个新的连接，于是服务端就向客户端发送一个确认消息包，在这个消息包里面：ack标志位置为1，表示确认客户端发起的第一次连接请求。
• 以上两次握手之后，对于客户端而言：已经明确了我既能给服务端成功发消息，也能成功收到服务端的响应。但是对于服务端而言：两次握手是不够的，因为到目前为止，服务端只知道一件事，客户端发给我的消息我能收到，但是我响应给客户端的消息，客户端能不能收到我是不知道的。所以，还需要进行第三次握手，第三次握手就是当客户端收到服务端发送的确认响应报文之后，还要继续去给服务端进行回应，也是一个ack标志位置1的确认消息。
• 通过以上三次连接，不管是客户端还是服务端，都知道我既能给对方发送消息，也能收到对方的响应。那么，这个连接就被安全的建了。

四次挥手：

• 四次挥手也是客户端发起的，客户端会发送一个报文，报文FIN=1，当客户端收到这个报文之后，就知道了客户端想要和我断开连接，
• 但是此时服务端不一定做好准备，因为当客户端发起断开连接的报文的时候，服务端有可能还有未发送完的报文消息需要继续发送，所以此时服务端只能告诉客户端我知道你要和我断开连接了，但是我这里可能还没做好准备，需要等我一下，等会我会告诉你，
• 于是，发完这个消息确认报之后，稍过片刻之后服务端继续发送一个断开连接的报文，FIN=1，表明服务端已经做好断开连接的准备，
• 那么，当这个消息发给客户端的时候，客户端同样需要继续发送一个消息确认的报文，那么通过这四次的相互沟通和连接，我就知道了，不管是客户端还是服务端，都已经做好了断开的准备。

用现实理解三次握手的具体细节TCP的四次挥手：

客户端：我数据传完了，我要下线了
服务器：知道了，我还有点数据，你等下
一段时间后
服务器：我数据发完了，你可以下线了
客户端：好的

---

（1）三次握手面试问题

为什么不是两次握手？
因为在这两次握手之后，对于客户端来说，发送和接收都没有问题，但是对于服务器，只知道接受没有问题，发送的消息客户端有没有收到，服务器是不知道的，因此需要第三次握手。

为什么不是四次握手？
这是两种情况，第一种是把服务器的确认ACK和连接SYN分两次发送，这种在理论上是可行的，就好比

服务器：我在
服务器：你在线吗？

但是一次性能干完的事情，非分两次，太浪费资源了，降低传输的效率。
第二种情况就是客户端再次发送确认消息，也是同理，三次握手就已经保证了双方的连接是可靠的，客户端再确认也是浪费资源

第三次握手中，如果客户端的ACK未送达服务器，会怎样？

• Server端：由于Server没有收到ACK确认，因此会每隔 3秒 重发之前的SYN+ACK（默认重发五次，之后自动关闭连接进入CLOSED状态），Client收到后会重新传ACK给Server。
• Client端，会出现两种情况：
  1. 在Server进行超时重发的过程中，如果Client向服务器发送数据，数据头部的ACK是为1的，所以服务器收到数据之后会读取 ACK number，进入 establish 状态
  2. 在Server进入CLOSED状态之后，如果Client向服务器发送数据，服务器会以RST包应答。

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

• 服务器每收到一次客户端的请求后都会重新复位一个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

---

• 三次握手的目的是建立可靠的通信信道，主要的目的就是双方确认自己与对方的发送与接收机能正常。

1. 第一次握手：客户什么都不能确认；服务器确认了对方发送正常
2. 第二次握手：客户确认了：自己发送、接收正常，对方发送、接收正常；服务器确认 了：自己接收正常，对方发送正常
3. 第三次握手：客户确认了：自己发送、接收正常，对方发送、接收正常；服务器确认 了：自己发送、接收正常，对方发送接收正常 所以三次握手就能确认双发收发功能都正常，缺一不可。

---

（4）四次挥手面试问题

为啥不是三次挥手？

• 因为客户端要关闭连接的时候，无法保证服务器已经将数据发送完成，所以此时服务器只能告诉客户端我收到你的关闭请求，知道你的数据发送完成。在服务器把数据发送完成之后，告知客户端，数据发送完了，可以关闭连接。此时，客户端也要应答，同意关闭连接

如果第二次挥手时服务器的ACK没有送达客户端，会怎样？

• 客户端没有收到ACK确认，会重新发送FIN请求。

CLOSE_WAIT状态意义是什么？（为什么不能把服务器发送的ACK和FIN合并起来，变成三次挥手）

• 因为服务器收到客户端断开连接的请求时，可能还有一些数据没有发完，这时先回复ACK，表示接收到了断开连接的请求。等到数据发完之后再发FIN，断开服务器到客户端的数据传送，
• close_wait：等待服务器把数据传输完毕！

2.4、状态

CLOSE_WAIT状态意义是什么？（为什么不能把服务器发送的ACK和FIN合并起来，变成三次挥手）

• 因为服务器收到客户端断开连接的请求时，可能还有一些数据没有发完，这时先回复ACK，表示接收到了断开连接的请求。等到数据发完之后再发FIN，断开服务器到客户端的数据传送，
• close_wait：等待服务器把数据传输完毕！

客户端TIME_WAIT状态的意义是什么？/2MSL的意义

• 第四次挥手时，客户端发送给服务器的ACK有可能丢失，TIME_WAIT状态就是用来重发可能丢失的ACK报文。如果Server没有收到ACK，就会重发FIN，如果Client在2*MSL的时间内收到了FIN，就会重新发送ACK并再次等待2MSL，防止Server没有收到ACK而不断重发FIN。 MSL(Maximum Segment Lifetime)，指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。
• 1MSL保证四次挥手中主动关闭 方最后的ACK报文能最终到达服务器
• 下一个1MSL保证服务器如果没有收到ACK那么进行重传的FIN报文能够到达客户端