用最通俗的语言讲解 TCP “三次握手，四次挥手”

一. 前言

二. TCP 报文的头部结构

三. 三次握手

3.1. 三次握手过程

3.2. 为什么要三次握手

四. 四次挥手

4.1. 四次挥手过程

4.2. 为什么要四次挥手

五. 大白话说

5.1. 大白话说三次握手

5.2. 大白话说四次挥手

六. 总结

一. 前言

TCP 是一种面向连接的、可靠的、基于字节流的传输层通信协议，在发送数据前，通信双方必须在彼此间建立一条连接。所谓的“连接”，其实是客户端和服务端保存的一份关于对方的信息，如IP 地址、端口号等。TCP 可以看成是一种字节流，它会处理 IP 层或以下的层的丢包、重复以及错误问题。在连接的建立过程中，双方需要交换一些连接的参数。这些参数可以放在 TCP 头部。一个 TCP 连接由一个4元组构成，分别是两个 IP 地址和两个端口号。一个 TCP 连接通常分为三个阶段：连接、数据传输、退出（关闭）。通过三次握手建立一个链接，通过四次挥手来关闭一个连接。当一个连接被建立或被终止时，交换的报文段只包含 TCP 头部，而没有数据。

所谓“任 TCP 虐我千百遍，我仍待 TCP 如初恋”。“不管面试 Java 、C/C++、Python 等开发岗位， TCP 的知识点可以说是的必问的了。我们都知道TCP是面向连接的，三次握手就是用来建立连接的，四次挥手就是用来断开连接的。

二. TCP 报文的头部结构

在了解 TCP 连接之前先来了解一下 TCP 报文的头部结构：

上图中有几个字段需要重点介绍下：
（1）序号：seq 序号，占32位，用来标识从 TCP 源端向目的端发送的字节流，发起方发送数据时对此进行标记。
（2）确认序号：ack 序号，占32位，只有 ACK 标志位为1时，确认序号字段才有效，ack=seq+1。
（3）标志位：共6个，即 URG、ACK、PSH、RST、SYN、FIN 等，具体含义如下：

ACK：确认序号有效。
FIN：释放一个连接。
PSH：接收方应该尽快将这个报文交给应用层。
RST：重置连接。
SYN：发起一个新连接。
URG：紧急指针（urgent pointer）有效。需要注意的是：不要将确认序号 ack 与标志位中的ACK 搞混了。确认方 ack= 发起方 seq+1，两端配对。

三. 三次握手

三次握手的本质是确认通信双方收发数据的能力。首先，我让信使运输一份信件给对方，对方收到了，那么他就知道了我的发件能力和他的收件能力是可以的。于是他给我回信，我若收到了，我便知道我的发件能力和他的收件能力是可以的，并且他的发件能力和我的收件能力是可以。然而此时，他还不知道他的发件能力和我的收件能力到底可不可以，于是我最后回馈一次，他若收到了，他便清楚了他的发件能力和我的收件能力是可以的。这，就是三次握手。

3.1. 三次握手过程

我们来看一下三次握手的过程：

1. 准备阶段

一开始，客户端和服务端都处于 CLOSED 状态。客户端主动打开连接，服务端被动打卡连接，结束CLOSED 状态，开始监听，进入 LISTEN 状态。

2. 第一次握手

客户端会随机初始化序号（client_isn），将此序号置于 TCP 首部的「序号」字段中，同时把 SYN 标志位置为 1 ，表示 SYN 报文。接着把第一个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于 SYN-SENT 状态。

3. 第二次握手

服务端收到客户端的 SYN 报文后，首先服务端也随机初始化自己的序号（server_isn），将此序号填入 TCP 首部的「序号」字段中，其次把 TCP 首部的「确认应答号」字段填入 client_isn + 1, 接着把 SYN 和 ACK 标志位置为 1。最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于 SYN-RCVD 状态。

4. 第三次握手

客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先该应答报文 TCP 首部 ACK 标志位置为 1 ，其次「确认应答号」字段填入 server_isn + 1 ，最后把报文发送给服务端，这次报文可以携带客户到服务器的数据，之后客户端处于 ESTABLISHED 状态。

好了，经过三次握手的过程，客户端和服务端之间的确定连接正常，接下来进入 ESTABLISHED 状态，服务端和客户端就可以快乐地通信了。

这里有个动态过程的图示：

这里有个小细节，第三次握手是可以携带数据的，这是面试常问的点。

3.2. 为什么要三次握手

为什么要三次握手呢？两次不行吗？

为了防止服务器端开启一些无用的连接增加服务器开销
防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

由于网络传输是有延时的（要通过网络光纤和各种中间代理服务器），在传输的过程中，比如客户端发起了 SYN=1 的第一次握手。

如果服务器端就直接创建了这个连接并返回包含 SYN、ACK 和 Seq 等内容的数据包给客户端，这个数据包因为网络传输的原因丢失了，丢失之后客户端就一直没有接收到服务器返回的数据包。

如果没有第三次握手告诉服务器端客户端收的到服务器端传输的数据的话，服务器端是不知道客户端有没有接收到服务器端返回的信息的。服务端就认为这个连接是可用的，端口就一直开着，等到客户端因超时重新发出请求时，服务器就会重新开启一个端口连接。

这样一来，就会有很多无效的连接端口白白地开着，导致资源的浪费。

这个过程可理解为：

还有一种情况是：已经失效的客户端发出的请求信息，由于某种原因传输到了服务器端，服务器端以为是客户端发出的有效请求，接收后产生错误：

所以我们需要“第三次握手”来确认这个过程：
通过第三次握手的数据告诉服务端，客户端有没有收到服务器“第二次握手”时传过去的数据，以及这个连接的序号是不是有效的。若发送的这个数据是“收到且没有问题”的信息，接收后服务器就正常建立 TCP 连接，否则建立 TCP 连接失败，服务器关闭连接端口。由此减少服务器开销和接收到失效请求发生的错误。

四. 四次挥手

4.1. 四次挥手过程

还是先上图：

聚散终有时，TCP 断开连接是通过四次挥手方式。双方都可以主动断开连接，断开连接后主机中的「资源」将被释放。

上图是客户端主动关闭连接：

第一次挥手：

客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。

第二次挥手：

服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSED_WAIT 状态。

第三次挥手：

客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。

第四次挥手：

1. 客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态；
2. 服务器收到了 ACK 应答报文后，就进入了 CLOSED 状态，至此服务端已经完成连接的关闭；
3. 客户端在经过 2MSL 一段时间后，自动进入 CLOSED 状态，至此客户端也完成连接的关闭。

你可以看到，每个方向都需要一个 FIN 和一个 ACK，因此通常被称为四次挥手。