企业官网建设流程全解析

这次我们不只讲概念，还把为什么需要三次握手、抓包怎么看、常见报错怎么排查一起拆开。TCP 三次握手是网络工程师、后端开发、运维同学绕不开的基础，但很多人在面试时能背出 SYN、SYN-ACK、ACK，一遇到真实故障就不知道从哪里下手。这篇文章会帮你把“书本上的三次握手”变成“自己动手能验证的三次握手”，读完你可以在自己的电脑上抓包复现全过程。

先说清楚这篇文章的范围：三次握手的核心原理、TCP 报文关键字段、客户端与服务端的状态变化、Wireshark/tcpdump 抓包验证方法、Python 模拟连接实验、常见连接超时和连接重置排查思路。文中不涉及路由器、交换机配置，也不会展开拥塞控制，放心往下看。

1. TCP 三次握手核心知识点速览

三次握手解决的核心问题只有一个：在不可靠的信道上让通信双方确认“我能发送、你能接收、你能发送、我能接收”。少了任何一次确认，都无法同时确认双方的收发能力。

从实际开发角度看，这部分知识直接关系到连接超时、端口被占用、代理连接断开等真实排障场景。热词列表里出现的tcp connect超时、curl: (35) tcp connection reset by peer、error: listen tcp 127.0.0.1:11434: bind全是三次握手与连接生命周期相关的报错，后面会专门讲。

2. 为什么是三次，不是两次或四次

很多人在面试时被问“为什么 TCP 建立连接要三次握手”，标准回答是“防止失效的连接请求突然到达服务器”。这个答案没错，但不够完整。需要理解的是，TCP 要求连接双方都确认对方的收发能力，同时还要同步双方的初始序列号。

2.1 两次握手的问题

假设只用两次握手，客户端发送 SYN，服务端收到后回复 SYN+ACK，然后服务端就认为连接建立成功。问题在于：如果客户端发送的 SYN 在网络中滞留了较长时间，客户端已经超时放弃并发起新的连接，而旧的 SYN 又突然到达服务端，服务端会误以为这是一个新连接请求，于是为这个失效请求分配连接资源，浪费内存和端口。

如果客户端收到服务端的 SYN+ACK 后不回复 ACK，服务端就一直处于 SYN_RCVD 状态，不知道客户端是否准备好。更准确地说，两次握手无法让“发送方确认接收方收到了自己的确认”。

2.2 三次握手的设计逻辑

第一次握手：客户端发送 SYN，序号为 x。客户端此时确认自己的发送能力和服务端的接收能力未知，但服务端能收到才能触发后续回复。

第二次握手：服务端收到 SYN，回复 SYN+ACK，服务端的序号为 y，同时确认号 ack=x+1。服务端确认客户端的发送能力正常，自己的接收能力也正常，同时把自己的序号 y 告诉客户端，但服务端还不知道客户端是否能接收。

第三次握手：客户端收到 SYN+ACK，回复 ACK，确认号 ack=y+1。客户端确认服务端的发送能力正常，自己的接收能力也正常。服务端收到这个 ACK 后，确认客户端的接收能力正常。

到这里，双方都确认了对方的收发能力，也完成了初始序号同步，连接建立。这就是“三次”的必要性。

2.3 四次握手是否可行

理论上四次也能完成上述验证，比如把第二次握手拆成 SYN 和 ACK 两次发送，但这样会多一个 Round-Trip Time（RTT），增加建连延迟，而且第三次握手的 ACK 已经可以携带应用数据，效率更高。TCP 选择三次握手是在可靠性和效率之间做了平衡。

3. 三次握手过程详解：报文与状态变化

三次握手最关键的三个报文是 SYN、SYN+ACK、ACK。报文内容看起来复杂，其实每个字段都有明确作用。

3.1 第一次握手

客户端向服务端发送 SYN 报文，设置 SYN=1，初始序号 seq=x。这个 x 是客户端随机生成的一个 32 位序号，客户端进入 SYN_SENT 状态。

客户端 -> 服务端 TCP Flag: SYN Sequence Number: x Acknowledgment Number: 0

第一次握手的作用是告诉服务端：我要建立连接，我的初始序号是 x。

3.2 第二次握手

服务端收到 SYN 报文后，如果同意建立连接，会回复 SYN+ACK 报文，设置 SYN=1，ACK=1，服务端的序号为 y，同时确认号 ack=x+1。服务端进入 SYN_RCVD 状态。

服务端 -> 客户端 TCP Flag: SYN, ACK Sequence Number: y Acknowledgment Number: x+1

第二次握手的作用是告诉客户端：我收到你的 SYN，同意建立连接，我的初始序号是 y。ack=x+1 表示期望收到客户端序号为 x+1 的报文。

3.3 第三次握手

客户端收到 SYN+ACK 报文后，回复 ACK 报文，设置 ACK=1，确认号 ack=y+1。此时客户端进入 ESTABLISHED 状态。服务端收到 ACK 后，也进入 ESTABLISHED 状态。

客户端 -> 服务端 TCP Flag: ACK Sequence Number: x+1 Acknowledgment Number: y+1

第三次握手的作用是告诉服务端：我收到你的 SYN+ACK，连接建立成功。

注意，第三次握手的 seq 是 x+1，因为第一次握手的 seq=x 已经被消耗。第三次握手时，ACK 报文可以携带应用数据，这也是 TCP 快速打开等优化技术的基础。

3.4 状态变化总结

服务端在 SYN_RCVD 状态如果一直收不到第三次 ACK，会根据操作系统配置超时重传 SYN+ACK，超过重传次数后关闭连接。客户端在 SYN_SENT 状态如果一直收不到 SYN+ACK，也会超时重传 SYN。

4. TCP 报文格式：三次握手该看哪些字段

三次握手抓包时，不需要把整个 TCP 头都背下来，但以下几个字段必须认识，否则看抓包结果会一头雾水。

4.1 关键字段说明

4.2 Flags 标志位

SYN: 同步序号，建连时置 1 ACK: 确认号有效，除第一次握手外的报文通常都置 1 FIN: 关闭连接，发送方数据发送完毕 RST: 重置连接，异常时使用

三次握手时只用到了 SYN 和 ACK 两个标志位。看到 SYN=1、ACK=0 的报文，就是第一次握手报文；看到 SYN=1、ACK=1，是第二次；看到 SYN=0、ACK=1，通常就是第三次或后续普通数据报文。

4.3 抓包如何区分三次报文

Wireshark 中可以直接看 Flags 列，如果显示[SYN]、[SYN, ACK]、[ACK]，就是三次握手的三个报文。除了看标志位，还要对比 Sequence Number 和 Acknowledgment Number 的变化规律，确认号等于对方序号加 1，这是验证三次握手的关键逻辑。

5. 实验环境准备与抓包验证

光看理论不实操，记不牢。这里准备一套可在自己电脑上运行的抓包验证流程。不需要服务器，只需要一台能联网的 Linux 或 Windows 电脑。

5.1 准备工具

• tcpdump（Linux）或 Wireshark（Windows/macOS）
• curl 或 nc 命令，用于发起真实连接
• 一个已知开放端口，比如www.baidu.com:80或本地局域网服务

macOS 自带tcpdump和nc，Windows 可以用 Wireshark 抓包，或者装 Git Bash 后用 curl 发起连接。Linux 如果有 sudo 权限，直接用 tcpdump 即可。

5.2 tcpdump 抓包命令

sudo tcpdump -i any -nn host www.baidu.com and port 80 -c 20

解释参数：

• -i any：抓所有网卡
• -nn：不做 DNS 反解，直接显示 IP 和端口
• host www.baidu.com：过滤该域名解析出的 IP
• port 80：过滤目标端口为 80 的报文
• -c 20：抓到 20 个报文后停止

在另一个终端执行：

curl -v http://www.baidu.com

curl 发起 TCP 连接的过程就是三次握手的过程，终端会输出Connecting to xxx (xxx.xxx.xxx.xxx) port 80，此时去看 tcpdump 输出，能看到三条关键报文：

Flags [S] seq=xxxxx Flags [S.] seq=yyyyy ack=xxxxx+1 Flags [.] seq=xxxxx+1 ack=yyyyy+1

S表示 SYN，.表示 ACK，[S.]表示 SYN+ACK。看到这三条报文顺序正确三次握手就完成了。

5.3 Wireshark 图形化操作

Wireshark 操作更直观：启动抓包后，用 curl 访问一个网站，然后停止，在过滤器输入：

tcp.flags.syn == 1 || tcp.flags.ack == 1

再按序号排序，能直接看到三次握手报文。Wireshark 默认在 Info 列显示[SYN]、[SYN, ACK]、[ACK]，非常清楚。

5.4 本机局域网抓包验证

如果没有外网访问权限，可以自己搭一个最简单的 TCP 服务端验证。用 Python 起服务方便快速，下面给出一段可运行示例。

# server.py import socket server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server_socket.bind(("127.0.0.1", 12345)) server_socket.listen(5) print("server listening on 127.0.0.1:12345") conn, addr = server_socket.accept() print("client connected:", addr) conn.close() server_socket.close()

再写一个客户端：

# client.py import socket client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) client_socket.connect(("127.0.0.1", 12345)) print("connected to server") client_socket.close()

先运行python server.py，再运行python client.py，同时用 tcpdump 抓回环接口，命令如下：

sudo tcpdump -i lo -nn port 12345 -S -c 10

-S参数可以让 tcpdump 显示绝对序号，更容易看出 seq、ack 的逻辑关系。

6. 使用 nc 和 Python 验证三次握手

抓包看到报文之后，还可以通过 nc 和 Python 模拟一次完整的连接过程，加深对状态的理解。

6.1 用 nc 建立连接

环境准备：一台 Linux 服务器开放一个端口，或者本机自己监听。

nc -l 0.0.0.0 9999

客户端执行：

nc 127.0.0.1 9999

然后查看连接状态：

ss -tnp | grep 9999

正常情况下能看到类似ESTAB的状态。如果连接没有建立成功，会看到SYN-SENT、SYN-RECV等状态，这些状态本身就是三次握手过程的直观体现。

6.2 监听系统 socket 状态

在 Linux 上，ss或netstat是排查连接状态最常用的两个命令。

ss -tn state syn-sent ss -tn state syn-recv ss -tn state established

• SYN-SENT：客户端已经发 SYN，等待服务端回复
• SYN-RECV：服务端收到 SYN 并回复 SYN+ACK，等待客户端 ACK
• ESTAB：三次握手完成

看到大量 SYN-SENT 或 SYN-RECV 状态，说明建连过程卡住了，需要进一步排查网络连通性或服务端资源。

6.3 模拟连接失败场景

如果服务端监听端口不存在，客户端 connect 会直接失败。用 Python 连接一个未监听的端口：

import socket client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) try: client_socket.connect(("127.0.0.1", 9998)) except ConnectionRefusedError as e: print("connection refused:", e) finally: client_socket.close()

运行后终端输出connection refused。这是因为目标端口没有服务在监听，服务端直接回了 RST 报文，连接被重置。这个现象就是热词列表里connection reset by peer的一种常见原因。

7. 三次握手常见故障与排查方法

实际开发运维中，遇到最多的问题不是“三次握手怎么握”，而是“连接建立不起来”。这里把热词列表里出现的常见报错和排查思路整理成表。

7.1 常见报错排查表

7.2 端口被占用问题

热词中出现了error: listen tcp 127.0.0.1:11434: bind: only one usage of each socket address，这是本地服务启动时的常见报错，意思是端口 11434 已经被其他进程占用。排查方法：

ss -lnt | grep 11434

或者：

lsof -i :11434

找到占用进程后，杀进程或改用其他端口即可。Python 服务端启动时也可以通过SO_REUSEADDR缓解 TIME_WAIT 状态导致的端口占用问题，但解决不了“两个进程同时监听同一端口”的问题。

7.3 connect 超时与会话管理

tcp connect超时常见于跨地域网络或防火墙丢包。排查时先确认基础连通性：

ping 目标IP nc -vz 目标IP 目标端口

nc -vz返回succeeded表示端口通，返回timed out说明 SYN 被丢弃或不可达。如果 ping 通但端口超时，优先检查防火墙策略、安全组、负载均衡后端状态。

数据库连接超时还有一个常见原因：应用层连接池已满或数据库max_connections达到上限。这时候 TCP 层面的三次握手其实可能已经完成，但应用资源分配失败导致连接被关闭，抓包看不到明显的 SYN 重传，要注意区分。

8. 从三次握手到四次挥手

热词列表里大量出现“三次握手四次挥手”，这里简要补一下四次挥手，方便对照理解。TCP 关闭连接需要四次挥手，原因是 TCP 连接是双工的，每个方向的关闭都需要单独确认。

四次挥手报文：

客户端 -> 服务端: FIN 服务端 -> 客户端: ACK 服务端 -> 客户端: FIN 客户端 -> 服务端: ACK

• 第一次：客户端发送 FIN，表示客户端不再发送数据，进入 FIN_WAIT_1
• 第二次：服务端回复 ACK，表示收到关闭请求，进入 CLOSE_WAIT，但服务端可能还有数据要发
• 第三次：服务端发送 FIN，表示服务端数据发送完毕，进入 LAST_ACK
• 第四次：客户端回复 ACK，进入 TIME_WAIT，等待 2MSL 后关闭

抓包时注意区分 FIN 和 RST：FIN 是正常关闭，RST 是异常重置。排障时看到 RST 报文，优先关注服务端是否崩溃、端口是否被防火墙拒绝、程序是否异常退出。

8.1 TIME_WAIT 状态

TIME_WAIT 出现在主动关闭连接的一方，持续时长通常是 2MSL（Maximum Segment Lifetime）。大量 TIME_WAIT 是高并发短连接系统的常见现象，本身是 TCP 的正常机制，用于防止旧连接的报文干扰新连接。但如果系统负载上升且端口耗尽，可能需要优化连接复用或调整内核参数，不建议盲目调小 TIME_WAIT 时间，否则可能引入数据混串风险。

9. 端口、抓包和连接状态的实用命令清单

排查 TCP 连接问题时，下面这些命令值得保存。

# 查看所有 TCP 连接状态 ss -tn state all # 查看 LISTEN 状态端口 ss -lnt # 查看 ESTABLISHED 连接 ss -tn state established # 查看指定端口占用 lsof -i :3306 # 抓取指定端口的完整 TCP 报文 sudo tcpdump -i any -nn port 3306 -S # 测试端口连通性 nc -vz 192.168.1.100 3306

Windows 上可以用：

netstat -ano | findstr 3306 tasklist | findstr 进程PID

这些命令覆盖了“端口监听、连接建立、连接状态、数据收发”的检查链路，基本能定位大多数连接层问题。

10. 面试知识点补充：这些细节帮你加深理解

三次握手是高频面试题，除了前面的内容，还有几个细节值得记一下。

10.1 三次握手的初始序号

客户端和服务端的初始序号 x 和 y 都不是固定的，而是随机生成或根据时间函数计算得出。随机初始序号可以防止旧连接的报文被误认为新连接报文，降低伪造 RST 攻击的风险。

10.2 抓包中看到的相对序号

Wireshark 默认会显示相对序号，比如第一次握手 seq=0，第二次握手 seq=0 ack=1，这样看起来更直观。但要注意这不是真实的序号，只是 Wireshark 为了方便查看把首个序号归一化了。需要看真实序号时，可以在 Wireshark 的 TCP 配置里关闭相对序号显示。

10.3 SYN 重传机制

客户端发送 SYN 后如果超时未收到 SYN+ACK，会重传 SYN。Linux 下重传次数由net.ipv4.tcp_syn_retries控制，默认可能重传 6 次。tcpdump 抓包时如果看到一个端口反复出现 SYN，说明对端没有响应，通常是防火墙丢包或服务端未启动。

10.4 半连接队列与全连接队列

服务端收到 SYN 后，连接状态变成 SYN_RCVD，此时连接存在半连接队列中；三次握手完成后进入全连接队列。高并发下全连接队列满会导致连接被丢弃，表现为客户端 connect 超时或服务端 accept 慢。排查时可以看：

ss -lt

组合使用这些状态信息，可以更准确地定位连接层问题。

11. 90 秒记不住也没关系，记住这套排查思路

回到文章标题。90 秒记不住全部内容才是正常现象，因为三次握手知识点密集，涉及报文格式、状态变化、重传机制和大量真实报错。真正值得记住的是这套思路：

1. 看到连接失败，先分清是 TCP 层失败还是应用层失败，用nc -vz和ss -tn快速确认。
2. 需要看细节，就用 tcpdump 或 Wireshark 抓 SYN、SYN+ACK、ACK 三条报文，确定卡在哪一次握手。
3. 卡在 SYN 无响应，优先查网络和防火墙；卡在 SYN_RCVD，查服务端半连接队列和内核参数；连接建立后秒断，查应用层资源和 RST 来源。
4. 端口占用类报错，优先用ss -lnt和lsof -i找到占用进程，再决定是换端口还是清理进程。

掌握了这套排查流程，TCP 三次握手就不再只是面试题，而是可以真正用来解决线上问题的技能。如果你在本地启动服务时遇到过bind: address already in use，在调用远程接口时遇到过curl: (35) tcp connection reset by peer，建议把这篇文章的命令保存下来，下次遇到类似问题直接按表排查。