目录
[1. 建立连接：三次握手的门道](#1. 建立连接：三次握手的门道)
[2. 数据传输：如何保证可靠？](#2. 数据传输：如何保证可靠？)
[3. 关闭连接：四次挥手的讲究](#3. 关闭连接：四次挥手的讲究)
[其他补充：TCP 核心标志位速记：（发送的包）](#其他补充：TCP 核心标志位速记：（发送的包）)
在我们日常上网的每一刻，浏览网页、刷视频、发消息、传文件，背后都离不开两大核心传输协议------TCP和UDP。这俩"隐形功臣"都工作在网络传输层，目标都是在程序间传递数据，但工作方式和适用场景却大相径庭。今天就用通俗的语言，带大家彻底搞懂它们的区别和原理。
核心差异：连接vs无连接
TCP和UDP最本质的区别，一句话就能概括：TCP是"打电话式"的面向连接传输，UDP是"写信式"的无连接传输。
想象一下，如果你想和朋友传递重要信息：
- **打电话（TCP）：**拨号后要等对方接通，通话中能实时确认对方是否听清，挂电话也需要双方配合挂断。整个过程有始有终，能保证信息准确传达。
- **写信（UDP）：**写好信贴上邮票直接寄出，至于对方有没有收到、收到的内容是否完整、几封信的顺序会不会乱，你一概不知。但胜在简单快捷，不用等对方"准备好"。
这个比喻能帮我们快速理解：TCP追求"可靠"，UDP追求"高效"，两者各有侧重。
深度解析TCP：可靠传输的"严谨派"
TCP（传输控制协议）是网络世界的"完美主义者"，为了保证数据准确、完整、按序传输，设计了一整套严谨的机制。
1. 建立连接：三次握手的门道
TCP传输数据前，必须先通过"三次握手"建立可靠连接，就像打电话时的"喂，能听到吗？""能听到，你说""好嘞"的确认过程：
- **第一次握手：**客户端向服务端发"SYN包"，相当于"我想和你建立连接，可行吗？"
- **第二次握手：**服务端回复"SYN+ACK包"，意思是"没问题，我准备好了，你可以开始了"
- **第三次握手：**客户端再发"ACK包"，回应"收到你的确认，咱们正式开始吧"
为什么要三次握手？两次不行吗？
答案是------不行。为了避免网络延迟导致的错误。
比如客户端发的第一个连接请求因为网络拥堵滞留了，客户端以为没发成功又重发了一个，等第二个请求完成通信后，第一个滞留的请求突然到达服务端。
如果是两次握手，服务端会误以为是新的连接请求，导致状态不一致。
而三次握手需要客户端最后的确认，就能避免这种"失效请求"引发的问题。
2. 数据传输：如何保证可靠？
建立连接后，TCP会通过以下机制确保数据可靠传输：
发送报文由序列号、长度和数据内容组成。
ACK包由序列号和长度组成。
- **序列号+确认应答：**每个字节都有唯一序列号，接收端收到数据后会回复"ACK确认包"，告诉发送端"我已经收到到某个序列号之前的所有数据"
- **重传机制：**如果发送端没收到确认，会自动重传丢失的数据
- **数据重组：**数据可能被拆分成多包发送，接收端会根据序列号重新排序，拼接成完整数据
比如发送端发送了1-100、101-200两包数据，如果101-200先到，接收端会先缓存，等1-100到达后再一起处理；
如果100-199丢失了，接收端会告诉发送端"我需要从1开始的数据"，发送端就会重传。
3. 关闭连接：四次挥手的讲究
TCP连接是"全双工"的，双方都能发送数据，所以关闭连接需要"四次挥手"，就像通话结束时的"我说完了""好的，我知道了""我也说完了""好的，再见"：
- **第一次挥手：**客户端发"FIN包"，表示"我这边没数据要发了"
- **第二次挥手：**服务端回复"ACK包"，表示"收到，我这边还在处理剩余数据"
- 第三次挥手：服务端处理完数据后，发"FIN包"，表示"我这边也没数据了"
- **第四次挥手：**客户端回复"ACK包"，表示"收到，咱们关闭连接吧"
**这里有个关键细节：**客户端发送最后一个ACK包后，不会立即关闭，而是要等一段时间。这是为了防止ACK包在网络中丢失，导致服务端一直等待。如果服务端没收到ACK包，会重发FIN包，客户端看到后会重新发送ACK包并刷新等待时间，确保连接可靠关闭。
快速了解UDP：高效传输的"灵活派"
UDP（用户数据报协议）和TCP完全是两种风格，它是网络世界的"效率至上主义者"，抛弃了复杂的连接和确认机制，追求极致的传输速度。
UDP的工作方式：简单直接
UDP的工作流程特别简单：应用程序把数据交给UDP，UDP给数据加个"头部"（包含源端口、目的端口等基本信息），然后直接通过网卡发送出去。数据包之间没有任何关联，发送方不管接收方是否收到，接收方也不管数据是否完整、顺序是否正确。
这种"简单粗暴"的方式带来了两个明显优势：
- **性能好：**不需要维护连接、不需要确认重传，CPU和内存消耗远低于TCP
- **延迟低：**数据从发送到接收的时间短，适合对实时性要求高的场景
但缺点也很突出：不可靠。网络拥堵、信号干扰等都可能导致数据丢失，UDP不会做任何补救。不过在很多场景下，少量数据丢失并不影响使用------比如视频直播时丢了一个画面帧，我们几乎察觉不到；语音通话时丢了几个字节，也不会影响理解。
TCP与UDP适用场景大比拼
通过上面的分析，我们可以清晰地总结出两者的适用场景：
选TCP的情况：对可靠性要求高
- 网页浏览（HTTP/HTTPS）：不能容忍网页内容缺失、图片加载不全
- **文件传输（FTP）：**丢一个字节都可能导致文件损坏
- **邮件收发（SMTP/POP3/IMAP）：**邮件必须完整准确送达
- **远程登录（SSH/Telnet）：**指令传输错误可能导致操作失误
选UDP的情况：对实时性要求高
- **视频直播/语音通话：**少量丢包不影响体验，延迟高了反而没法用
- **网络游戏：**需要实时传输操作指令，延迟比偶尔的丢包更重要
- **域名查询（DNS）：**查询请求小，需要快速响应，就算失败了重新查询就行
- **隧道网络：**比如SDN中的WECHLINE，需要高效传输数据
总结
TCP和UDP没有绝对的优劣之分，它们是为不同需求设计的协议：
- **TCP：**面向连接、可靠、慢、资源消耗高，适合"稳"比"快"重要的场景
- **UDP：**无连接、不可靠、快、资源消耗低，适合"快"比"稳"重要的场景
正是这两种协议的互补，才支撑起了丰富多彩的互联网应用。下次刷视频时，你可以想到"这是UDP在发力"；下载文件时，你可以知道"这是TCP在保驾护航"------这就是网络传输的底层逻辑。
参考来源：【一条视频讲清楚TCP协议与UDP协议-什么是三次握手与四次挥手】 https://www.bilibili.com/video/BV1kV411j7hA/?share_source=copy_web&vd_source=16a04dbf3e3b75cafdab3f4616e0c789
https://www.bilibili.com/video/BV1kV411j7hA/?share_source=copy_web&vd_source=16a04dbf3e3b75cafdab3f4616e0c789
其他补充：TCP 核心标志位速记：（发送的包）
SYN：同步序列编号 (Synchronize Sequence Numbers)
ACK：确认 (Acknowledge Character) 、
FIN：结束 (Finish Character)
SYN 是连接的起点，负责"搭讪"和同步序号。
ACK 是连接的基石，负责"确认"和保证数据不丢失。
FIN是优雅的告别，可理解为网络世界里的礼貌告别信
表格总结：
|-----------|------------------------------|--------|----------------------------|-----------------------------|
| 标志位名称 | 全称 | 角色 | 作用 | 形象理解 |
| SYN | Synchronize Sequence Numbers | 连接发起者 | 请求建立连接，同步双方的初始序列号。 | "搭讪" ------ "你好，我要连你了，在吗？" |
| ACK | Acknowledge | 可靠传输基石 | 确认收到数据或请求。告诉对方下一个应该发什么。 | "应答" ------ "收到了，请继续。" |
| FIN | Finish | 优雅告别者 | 请求关闭连接。表示发送方数据已发完，但仍可接收数据。 | "告别" ------ "我说完了，咱们正常结束吧。" |
| | | | | |
| 核心机制总结：有始（SYN）、有终（FIN）、有确认（ACK） |||||