面试必备HTTP之TCP三次握手及四次挥手详解

前言

在面试中，经常会问到TCP的三次握手和四次挥手。最近在面试3-5年开发经验的程序员，发现能简单谈谈三次握手的寥寥无几，能剖析出整个具体过程的十不存一。这就是本篇文章诞生的原因之一，希望大家再次面试的时候能够侃侃而谈！

关于TCP

• TCP 提供一种面向连接的、可靠的字节流服务
• 在一个 TCP 连接中，仅有两方进行彼此通信。广播和多播不能用于 TCP
• TCP 使用校验和，确认和重传机制来保证可靠传输
• TCP 给数据分节进行排序，并使用累积确认保证数据的顺序不变和非重复
• TCP 使用滑动窗口机制来实现流量控制，通过动态改变窗口的大小进行拥塞控制

TCP并不能保证数据一定会被对方接收到，因为这是不可能的。它不是100%可靠的协议，它所能提供的是数据的可靠传递或故障的可靠通知。

三次握手

image

三次握手(Three-way Handshake)，是指建立一个 TCP 连接时，需要客户端和服务器总共发送3个包。

1. 第一次握手([SYN], Seq = x)
   客户端发送一个SYN标记的包，Seq初始序列号x，发送完成后客户端进入SYN_SEND状态。

2. 第二次握手([SYN,ACK], Seq = y, ACK = x + 1)
   服务器返回确认包(ACK)应答，同时还要发送一个SYN包回去。ACK = x + 1,表示确认收到(客户端发来的Seq值 + 1)，Seq = y, 表示让客户端确认是否能收到。发送完成后服务端进入SYN_RCVD状态。

3. 第三次握手([ACK], ACK = y + 1)
   客户端再次发送确认包(ACK),ACK = y + 1, 表示确认收到服务器的包（服务端发来的Seq值 + 1）。客户端发送完毕后，进入ESTABLISHED状态，服务端接收到这个包，也进入ESTABLISHED状态, TCP握手结束。

以上大家可能觉得难以记忆和理解，可以用一种形象的方式来解释:

1. 女朋友向程序员提出约会(Seq = x)的建议，然后女朋友进入SYN_SEND状态。
2. 程序员收到后同意了去约会(ACK = x + 1), 然后向女朋友建议去吃麻辣烫吧(Seq = y)，程序员进入SYN_RCVD状态。
3. 女朋友收到建议后，勉为其难的答应了，然后告诉程序员说 那好吧(ACK = y + 1)。女朋友就进入了ESTABLISHED状态， 程序员也进入了 ESTABLISHED状态，整个约会讨论结束。

为什么是三次握手?不是两次或者四次？

• 从假设的角度来分析吧，假如是两次握手，会发生什么情况呢? 服务端在发出应答消息后，它根本就不能确认客户端是否接受到消息了，那么这样意味着只有客户端可以向服务端发送数据。

• 假如是四次握手呢？明明已经保证了一个稳定的传输流了，为什么还要浪费性能再去发一次消息，浪费了性能。

• 所以三次是最合适的，这里本人只是从个人的角度简单分析，没有从序列等原理的角度去剖析。

四次挥手

image

TCP连接的断开需要发送四个包，所以称为四次挥手。

1. 第一次挥手（[FIN], Seq = x）
   客户端发送一个FIN标记的包，告诉服务器需要关闭连接，表示自己不用发送数据了，但是还可以接收数据。发送完成后，客户端进入FIN_WAIT_1状态。

2. 第二次挥手 ([ACK], ACK = x + 1)
   服务端发送一个ACK的确认包，告诉客户端接收到关闭的请求，但是还没有准备好。发送完成后，服务端进入CLOSE_WAIT状态，客户端收到这个包后，进入FIN_WAIT_2，等待服务器关闭连接。

3. 第三次挥手 ([FIN], Seq = y)
   服务端准备好关闭连接时，发送FIN标记的包，告诉客户端准备关闭了。发送完成后，服务端进入LAST_ACK状态，等待客户端确认。

4. 第四次挥手 ([ACK], ACK = y + 1)
   客户端接收到服务端的关闭请求，再发送ACK标记的确认包，进入TIME_WAIT状态，等待服务端可能请求重传的ACK包。
   服务端接收到ACK包后，关闭连接，进入CLOSED状态。
   客户端在等待固定时间(两个最大段生命周期)后，没有接收到服务的ACK包，认为服务器已关闭连接，自己也关闭连接，进入CLOSED状态。

四次挥手连接看起来挺复杂，其实认真看看也挺简单的，同样的比喻:

1. 女朋友向程序员提出分手
2. 程序员告诉女朋友说，我知道了，但是要考虑一下
3. 程序员考虑清楚后，跟女朋友说那就分手吧
4. 女朋友接收到程序员的消息后，然后还在等程序员发挽留的消息，然而等了两天后没等到，就认为程序员是真的不会再发消息来了，于是就拉黑删除程序员，关闭连接了。

为什么是三次握手，却是四次挥手？三次挥手不可以吗？

继续从假设的角度分析，如果是三次挥手，在服务器接收到客户端发送关闭的请求后，把SYN和ACK包一起发过去。这样会造成服务端还有数据没有发送完，造成了数据的丢失。所以中间的这一段时间，等待服务器把剩余的数据发送完是很有必要的。

用Wireshark抓取三次握手和四次挥手

Wireshark下载链接: 密码:3l1t
讲了一大堆，还是用实践来验证一下我们的结果吧。利用自带的命令行模拟TCP连接。

1. 打开命令行工具，输入 nc -l 1234监听本地的1234端口
   

   image

2. 打开Wireshark，找到Loopback双击进去，监听本地

   
   
   image

3. 再新开一个命令行工具，输入nc 127.0.0.1 1234

4. 这时看到Wireshark，出现了TCP的三次握手的每次连接详情

   
   
   image
   
   

   但是我们发现这个Seq = 0, 上面提到Seq是x随机数，我们随便选中一个发送信号的步骤再设置一下即可

   
   
   image

5. 命令行control+C断开连接重复一下上面的步骤，再次建立连接发现Seq值已经改
   变了

6. 清空一下信息，断开连接，然后可以抓到四次挥手的整个过程

   
   
   image

总结

TCP的三次握手和四次挥手是非常重要的，希望大家出去面试的时候能够在面对有关这里的问题时，能够装逼成功！