TCP 与 UCP 比较

今天我们来了解一下 TCP 与 UCP ，在详细展开之前，我们先来简单认识一下TCP/IP 协议栈。

TCP/IP协议栈是互联网的核心技术架构，采用分层设计实现跨网络通信。它将复杂的网络通信过程分解为五个层次，每层专注于特定功能，并通过清晰的接口与相邻层交互。这种设计既实现了功能解耦，又确保了系统的可扩展性。

协议栈的层级结构自下而上依次为：

物理层：负责物理介质上的原始比特流传输
数据链路层：实现相邻节点间的可靠帧传输
网络层：处理端到端的数据包路由和转发
传输层：提供端到端的可靠数据传输服务
应用层：直接面向用户提供各类网络服务

各层之间通过严格的封装/解封装机制协作，上层利用下层提供的服务，下层为上层屏蔽实现细节，共同构建起标准化的网络通信体系。

我们要讲的 TCP 和 UDP 就是传输层协议的两大核心实现。

1.TCP

1.1简介

TCP（传输控制协议，Transmission Control Protocol）是TCP/IP协议栈中传输层的核心协议。它在不可靠的网络层（IP协议）基础上，为应用层提供面向连接、可靠且有序的字节流传输服务 。具体而言，IP协议仅负责将数据包从源地址发送到目标地址，但不保证传输成功、顺序正确或数据完整。TCP通过一系列复杂机制弥补了IP协议的不足，使应用层无需关注网络传输的稳定性，就能获得如同在"可靠管道"中传输数据的效果。

1.2头部标志位

在解释工作之前，我们需认识头部标志位，它们用于控制 TCP 连接的建立、数据传输和释放过程，相当于通信中的 "控制信号"，每个标识都有明确的语义。

标志位	全称（含义）	核心作用
SYN	Synchronize（同步）	用于发起连接请求，告知对方 "我想建立连接，并同步我的初始序列号"
ACK	Acknowledgment（确认）	用于确认收到对方的数据，告知对方 "我已收到你发送的某部分数据，接下来请发后续内容"。标志位 `ACK=1` 时，报文中的 "确认号（ack）" 字段才有效，确认号即 "期望接收的下一个序列号"。
FIN	Finish（结束）	用于请求释放连接，告知对方 "我这边已没有数据要发送了，准备断开连接"。发送 `FIN=1` 的报文，代表主动关闭连接的一方已完成数据传输。
RST	Reset（重置）	用于强制断开异常连接，告知对方 "当前连接有问题，必须重新建立连接"。通常在连接超时、端口未开放、数据错误等场景下发送，直接终止当前连接。
PSH	Push（推送）	用于要求接收方立即将数据提交给应用层，而不是缓存起来。例如：即时通讯中发送紧急消息时，可能携带 `PSH=1`，确保对方立即显示。
URG	Urgent（紧急）	用于标记报文中包含紧急数据，配合 "紧急指针" 字段指示紧急数据的位置。实际应用中较少使用，常见于远程登录（如 SSH）中的中断指令。

1.3工作过程

TCP（传输控制协议）的工作过程可分为连接建立 、数据传输 、连接释放三个核心阶段，每个阶段通过特定机制实现有序、无丢失的通信。我们用通俗的方式来了解这一过程。

1.3.1连接建立三次握手（类似 "拨通电话确认双方通信能力"）

TCP 是一种面向连接的协议，通信双方需要通过三次握手建立逻辑连接，确保通信能力正常并同步初始状态：

1.第一次握手（SYN 报文）

客户端发送连接请求报文，其中：

SYN=1（标识为连接请求）
包含客户端初始序列号（ISN，如x）客户端随后进入SYN_SENT状态（相当于拨号方说"喂，能听到吗？"）

2.第二次握手（SYN+ACK 报文）

服务器收到请求后返回确认报文，其中：

SYN=1（同意建立连接）
ACK=1（确认收到请求）
包含服务器初始序列号（ISN，如y）
确认号为x+1（表示期望接收客户端下一个序列号）服务器进入SYN_RCVD状态（相当于接听方说"能听到，我也准备好了"）

3.第三次握手（ACK 报文）

客户端发送最终确认报文，其中：

ACK=1
确认号为y+1（表示期望接收服务器下一个序列号）双方随后进入ESTABLISHED状态（相当于拨号方说"好的，开始聊吧"），连接正式建立。

1.3.2数据传输：可靠传输机制（类似 "边说话边确认，没听清就重说"）

TCP 通过以下机制确保可靠传输：

1.序列号与确认应答

每个数据字节分配唯一序列号（从 ISN 开始递增）
接收方返回 ACK 报文，确认号为"最后接收字节序号+1"（类似"已收到1-10句，请继续第11句"）

2.重传机制

发送方在超时未收到ACK或收到3次重复ACK时重传数据（类似"未收到回应则重复刚才的话"）

3.流量控制（滑动窗口）

接收方通过"窗口大小"字段告知可用缓冲区空间
发送方据此调整发送量（类似"接收方提示'说慢点，我跟不上了'"）

4.拥塞控制

根据网络状况动态调整发送速率
避免网络过载（类似"信号差时自动放慢语速"）

1.3.3连接释放：四次挥手（类似 "说完话确认双方都结束，再挂电话"）

1.第一次挥手（FIN 报文） ：主动关闭方（如客户端）发送连接释放请求，包含FIN=1（标记为释放连接）和当前序列号（如 u），进入FIN_WAIT_1状态（类似 "说的人说'我说完了'"）。

2.第二次挥手（ACK 报文） ：被动关闭方（如服务器）回复确认，包含ACK=1和确认号（u+1），进入CLOSE_WAIT状态（此时仍可发送剩余数据）（类似 "听的人说'知道了，我再看看有没有遗漏'"）。

3.第三次挥手（FIN 报文） ：被动关闭方发送最终释放请求，包含FIN=1和当前序列号（如 v），进入LAST_ACK状态（类似 "听的人说'我也说完了'"）。

4.第四次挥手（ACK 报文） ：主动关闭方回复确认，包含ACK=1和确认号（v+1），进入TIME_WAIT状态（等待 2MSL 确保对方收到确认），最终双方进入CLOSED状态（类似 "说的人说'好的，挂了'"），连接彻底释放。

1.4应用场景

TCP 适用于对可靠性要求高于实时性的场景，例如：

网页浏览（HTTP/HTTPS）：需确保网页内容、图片、脚本等数据完整传输；
文件传输（FTP、SFTP）：避免文件传输过程中丢失或损坏；
邮件发送（SMTP）、即时通讯（微信文字消息）：确保消息不丢失、按序展示；
数据库访问（MySQL、PostgreSQL）：确保 SQL 指令和查询结果可靠传输。

2.UDP

2.1简介

UDP（用户数据报协议，User Datagram Protocol），主打无连接、不可靠、低延迟、轻量级的数据传输，核心设计理念是 "效率优先"------ 舍弃 TCP 复杂的可靠性保障机制，以最小的协议开销实现数据快速投递，适用于实时性要求远高于数据完整性的场景。

2.2工作过程

2.2.1数据封装：给应用数据 "贴标签"（类似 "给快递包写地址"）

应用层（如游戏、直播软件）将数据传递给 UDP 协议栈后，UDP 仅做最基础的封装：

添加上层协议标签：明确数据对应的应用层进程（通过 "源端口" 和 "目的端口"，比如 DNS 用 53 端口、游戏用特定端口，类似 "快递包上写收发地址和联系方式"）；
计算校验和：对 UDP 头部和数据部分做简单校验（可选，类似 "快递包表面检查是否破损"）；
形成 UDP 数据报：封装后的数据包固定格式，头部仅 8 字节（远少于 TCP），整体体积小、封装速度快（类似 "快速打包，不额外加防护"）。

2.2.2数据传输：直接投递，不等待、不确认（类似 "快递直接投递，不打电话确认"）

UDP 数据报封装完成后，直接交给网络层（IP 协议），后续传输过程无任何额外控制：

无连接建立：发送方无需像 TCP 那样 "三次握手"，拿到数据就发，不管接收方是否准备好（类似 "不用提前跟收件人确认，直接寄快递"）；
无确认应答：发送方发送后不等待接收方回复，也不知道数据是否到达、是否完整（类似 "寄完快递不跟踪物流，不管对方收没收到"）；
无速率控制：发送方按自身速率持续发送，不管网络是否拥堵、接收方是否处理得过来（类似 "不管快递站忙不忙，一直往那边寄"）；
数据报独立传输：每个 UDP 数据报都是独立的，发送顺序和接收顺序可能不一致，丢失了也不会重传（类似 "多个快递分开寄，可能有的先到、有的丢了，不会补寄"）。

2.2.3数据接收：直接解封装，交给应用层（类似 "收件人直接拿快递，不签收"）

接收方的 UDP 协议栈收到网络层传递的 UDP 数据报后：

解封装：剥离 UDP 头部，提取源端口、目的端口和数据（类似 "拆快递包，拿出里面的东西"）；
简单校验：若开启校验和，验证数据是否破损，破损则直接丢弃（类似 "看快递包破损严重就直接扔掉"）；
交付应用层：将完整数据按端口号交给对应应用进程，不做排序、不做缓存（类似 "把完好的快递直接交给收件人，不管收到的顺序是否和寄出顺序一致"）。

2.3应用场景

因高效实时 的特性，UDP 广泛用于能容忍少量数据丢失的场景：

实时音视频：视频通话、语音聊天（VoIP）、直播（画面卡顿可容忍，需低延迟）；
网络游戏：玩家移动、技能释放等指令（偶尔丢包不影响游戏体验，卡顿会严重影响操作）；
短平快请求：DNS 查询（数据量小，追求快速响应，一次请求一次回复）；
广播 / 多播：局域网设备发现、视频会议广播（一对多传输，无需逐一建立连接）。

3.TCP 与 UCP 对比

TCP 是一种面向连接的可靠字节流协议。在通信前需要通过"三次握手"建立连接，传输过程中采用序列号、确认应答、重传机制、滑动窗口流量控制和拥塞控制等技术，确保数据无丢失、无重复且按序到达。它支持全双工通信，但由于额外的控制机制会产生较高延迟和开销，适用于对可靠性要求较高的场景，如 HTTP/HTTPS、FTP 文件传输、SMTP 邮件发送以及 SSH 远程登录等。

UDP 则是一种无连接的不可靠数据报协议。通信前无需建立连接，直接将数据封装成数据报发送。它不保证送达顺序、不会重传丢失数据、也没有流量和拥塞控制，仅提供端口寻址和基本差错校验。因此具有延迟低、开销小、传输效率高 的特点，适用于实时性优先于可靠性的场景，如视频通话、VoIP 语音聊天、直播、游戏数据传输和 DNS 查询等，也常用于广播/多播通信。

简而言之，TCP 以**"可靠有序"** 为核心，牺牲效率换取稳定性；UDP 以**"高效实时"**为核心，牺牲可靠性换取速度。实际应用中需根据业务需求选择。