初识 TCP 协议：从“听说过”到“真正认识它”，新手也能看懂的入门笔记-开发者社区

初识 TCP 协议：从“听说过”到“真正认识它”
（新手友好版 · 2026 年依然适用的核心理解）

大多数人第一次听到 TCP 的时候，只知道两件事：

但真正理解它需要把下面这 7 个核心画面建立起来。

互联网最底层的 IP 协议只负责两件事：

TCP 在 IP 之上补上了这四件事：

一句话总结：
TCP 把不可靠的 IP 网络，伪装成了可靠的字节流管道。

很多人背了口诀却没记住本质。

三次握手的真正目的是：

双方互相确认对方的“发送”和“接收”能力都正常

步骤	发送方	内容含义（最通俗解释）	对方学到了什么
1	客户端 → 服务端	“你好，我要跟你说话（SYN）”	服务端知道：客户端能发
2	服务端 → 客户端	“好的，我也想跟你说话（SYN+ACK）”	客户端知道：服务端能收 + 能发
3	客户端 → 服务端	“太好了，那我们开始吧（ACK）”	服务端知道：客户端收到了我的回复

少了哪一次都不行：

（新手最容易混淆的部分）

标志位	英文	含义（最接地气的说法）	常见出现场景
SYN	synchronize	“我想建立连接” / “这是新连接的第一个包”	三次握手第1、2步
ACK	acknowledgment	“我确认收到你前面发的序号为 X 的数据了”	几乎每个 TCP 包都有
FIN	finish	“我发完了，想优雅地结束连接”	四次挥手第1、3步
RST	reset	“出大事了！连接作废！马上断开！”	端口未监听、异常拒绝等
PSH	push	“别等了！赶紧把数据交给应用程序！”	一般配合小包发送
URG	urgent	“紧急数据！优先处理！”（现在几乎不用了）	极少见

记住口诀：“SYN 开门，FIN 关门，RST 踹门，ACK 点头”

序号 + 确认应答（Seq + Ack）
- 每个字节都有编号（不是每个包）
- 接收方告诉发送方：“我已经连续收到到第 X 字节了”
- 发送方据此判断哪些需要重传
滑动窗口（Sliding Window）
- 不用等上一个包确认才发下一个（效率高）
- 窗口大小 = 对方还能接收多少字节
- 窗口不断向前滑动 → 实现流量控制 + 拥塞避免

步骤	谁发	含义（最直白版）	为什么需要这一步
1	主动方	“我发完了，不发了（FIN）”	—
2	被动方	“收到，我知道了（ACK）”	告诉对方“我收到你结束的请求了”
3	被动方	“我也发完了，不发了（FIN）”	—
4	主动方	“好的，彻底结束（ACK）”	告诉对方“我也知道你结束了”

关键点：被动方第2步和第3步不能合并，因为它可能还有数据要发完。

为什么建立连接要三次而不是两次？
两次只能确认客户端→服务端单向通，双向通必须三次。
为什么关闭连接要四次而不是三次？
因为关闭是双向独立的，任何一方都可以先说“我不发了”，另一方可能还有话要说。
TIME_WAIT 是什么鬼？
第四次挥手发完 ACK 后，主动关闭方进入 TIME_WAIT 状态（通常 1–4 分钟），防止最后一个 ACK 丢失导致被动方不停重发 FIN。
SYN洪泛攻击是怎么回事？
攻击者疯狂发 SYN，不完成三次握手 → 服务端半连接队列被占满 → 正常用户连不上。