TCP(Transmission Control Protocol,传输控制协议)和 UDP(User Datagram Protocol,用户数据报协议)
是 TCP/IP 协议族中最核心的两种传输层协议,二者在可靠性、连接方式、传输效率等维度存在本质区别,
适用于不同的网络场景。以下从 7 个核心维度展开对比,并补充典型应用场景,帮助理解二者的差异与适用边界。
协议特性对比
特性 TCP UDP
连接方式 面向连接(三次握手) 无连接
可靠性 高(确认、重传、校验) 低(可能丢包、乱序)
传输速度 较慢(因控制机制) 较快(无额外开销)
头部大小 20-60字节 固定8字节
流量控制 支持(滑动窗口) 不支持
拥塞控制 支持(慢启动、快速重传等) 不支持
典型应用场景分析
TCP的典型应用
文件传输:需确保每个字节正确到达,如FTP协议
数据库操作:事务处理要求严格的数据一致性
UDP的典型应用
实时音视频:允许少量丢包以降低延迟,如Zoom、腾讯会议
DNS查询:快速响应比可靠性更重要
核心区别对比(表格总结)
对比维度 TCP(传输控制协议) UDP(用户数据报协议)
连接方式 面向连接(三次握手建立连接,四次挥手断开连接) 无连接(发送数据前无需建立连接,直接发送)
可靠性 可靠传输(保证数据不丢失、不重复、按序到达) 不可靠传输(不保证数据到达,可能丢失 / 乱序)
传输效率 效率较低(需处理确认、重传、流量控制等) 效率极高(头部开销小,无额外控制逻辑)
数据边界 面向字节流(无固定数据边界,需应用层定义) 面向数据报(每个数据报独立,有明确边界)
流量控制与拥塞控制 支持(滑动窗口机制实现流量控制,拥塞窗口防网络拥塞) 不支持(发送方无限制发送,可能导致网络拥塞)
头部开销 较大(固定头部 20 字节,可选头部 0-40 字节) 极小(固定头部 8 字节,无可选字段)
适用场景 对可靠性要求高、数据传输不紧急的场景 对实时性要求高、可容忍少量数据丢失的场景
关键区别详解
连接方式:“面向连接” vs “无连接”
这是 TCP 与 UDP 最根本的区别,直接决定了二者的可靠性和效率差异。
TCP:面向连接TCP 在传输数据前,必须通过 “三次握手” 建立双向连接,确保发送方和接收方都具备收发能力;
传输结束后,需通过 “四次挥手” 正常断开连接,释放资源。
三次握手:确认双方 “发 / 收” 功能正常(A→B:我要发数据;
B→A:我收到了,你也可以收;A→B:收到,开始传)。
四次挥手:确保双方数据都已传输完成(A→B:我发完了;
B→A:我知道了,我还在发;B→A:我也发完了;A→B:知道了,断开)。
UDP:无连接UDP 无需建立连接,发送方直接将数据封装成 “数据报”(包含目标 IP 和端口),通过网络层转发;
接收方收到数据报后直接交给应用层,不与发送方确认 “是否准备好”。
类比:TCP 像 “打电话”(先拨号确认对方接电话,再说话),UDP 像 “寄明信片”(写好地址直接寄,不管对方是否在家)。
可靠性:“保证送达” vs “尽力交付”
TCP 的核心设计目标是 “可靠传输”,通过多重机制避免数据丢失、重复或乱序;
UDP 则仅 “尽力发送”,不保证结果。
TCP 的可靠性机制:
确认应答(ACK):接收方收到数据后,必须向发送方返回 “确认包(ACK)”;若发送方超时未收到 ACK,会重传数据。
序号与确认号:TCP 为每个字节分配唯一序号,接收方通过序号判断数据是否缺失、是否乱序,缺失则要求重传,乱序则重新排序。
重传机制:超时重传(超时未收 ACK)、快速重传(收到 3 次重复 ACK,立即重传)。
校验和:TCP 头部和数据都包含校验和,接收方通过校验和判断数据是否损坏,损坏则丢弃并要求重传。
UDP 的无可靠性:UDP 仅在头部包含简单的校验和(可选,部分场景会关闭),若数据损坏或丢失,UDP 不重传、不通知发送方;
接收方收到乱序的数据报,也会直接按 “收到顺序” 交给应用层,不排序。
传输效率:“安全优先” vs “速度优先”
TCP 的可靠性机制会带来额外的网络开销和延迟,UDP 则因 “无额外控制” 实现高效传输。
TCP 的效率损耗:连接建立 / 断开的握手过程(增加延迟,尤其短连接场景);
确认包(ACK)占用带宽(每发 1 个数据报,需 1 个 ACK 回复);
流量控制和拥塞控制会动态降低发送速率(避免网络过载,但牺牲速度)。
例如:100KB 数据,TCP 需传输 “数据报 + ACK”,UDP 仅需传输 “数据报”。
UDP 的高效性:头部仅 8 字节(TCP 固定 20 字节),数据封装开销小;
无握手、无重传、无流量控制,数据从应用层到网络层的延迟极低(通常在毫秒级)。
数据边界:“字节流” vs “数据报”
TCP 和 UDP 对 “数据的划分方式” 不同,直接影响应用层的处理逻辑。
TCP:面向字节流TCP 将数据视为 “连续的字节流”,不划分固定边界。
例如:应用层分 3 次发送 “10 字节、20 字节、30 字节”,TCP 可能合并成 “60 字节” 一次发送,或拆分成 “15 字节、45 字节” 发送;
接收方需通过应用层协议(如 HTTP 的 Content-Length)判断 “哪里是一段数据的结束”。
UDP:面向数据报UDP 将应用层数据封装成 “独立的数据报”,每个数据报是一个完整的单元,发送方发 1 个数据报,接收方就收 1 个数据报,不会合并或拆分。
例如:应用层发 3 个 10 字节的数据报,UDP 会按 3 个独立单元发送,接收方也会按 3 次接收,无需应用层额外定义边界。
流量控制与拥塞控制:“智能调节” vs “无限制发送”
TCP 会根据接收方能力和网络状况动态调整发送速率,避免 “overwhelm” 接收方或网络;UDP 则无此控制。
TCP 的流量控制(滑动窗口):接收方通过 “窗口大小” 告诉发送方 “我当前能接收的最大字节数”,发送方仅发送窗口内的数据,避免接收方缓存溢出。
例如:接收方缓存满了,窗口大小设为 0,发送方就暂停发送,直到接收方释放缓存后更新窗口。
TCP 的拥塞控制(拥塞窗口):TCP 通过 “拥塞窗口” 感知网络拥堵(如超时重传),拥堵时减小发送速率(慢启动→拥塞避免→快速恢复),避免网络因大量数据而瘫痪。
UDP 的无控制:UDP 发送方不管接收方是否能处理、网络是否拥堵,都会按应用层要求持续发送数据,可能导致接收方缓存溢出(丢包)或网络拥塞(影响其他服务)。
典型应用场景
选择 TCP 还是 UDP,核心取决于场景对 “可靠性” 和 “实时性” 的优先级:
TCP 的适用场景(可靠性优先)
文件传输:HTTP/HTTPS(网页加载)、FTP(文件传输)、SFTP(安全文件传输)—— 需保证文件不损坏、不丢失。
数据交互:MySQL(数据库连接)、SSH(远程登录)、SMTP(邮件发送)—— 需保证指令 / 数据准确执行,不能丢包。
即时通讯(文本):微信 / QQ 的文字消息 —— 文本消息丢失会影响沟通,需可靠传输(但语音 / 视频用 UDP)。
UDP 的适用场景(实时性优先,可容忍丢包)
实时音视频:直播(抖音 / 快手)、视频会议(Zoom)、语音通话(微信电话)——1 帧数据丢失不影响整体观看,若用 TCP 重传,延迟会导致 “卡顿”,反而影响体验。
游戏数据:王者荣耀、英雄联盟的玩家操作(如移动、攻击)—— 操作指令需低延迟(延迟 > 100ms 会影响手感),丢 1 个指令可通过后续指令弥补,无需重传。
广播 / 组播:DNS 查询(域名解析)、DHCP(IP 分配)、网络广播(如打印机发现)—— 短数据、单次请求,无需连接,UDP 效率更高(DNS 用 UDP,仅超大响应时用 TCP)。
IoT 设备:传感器数据(如温度、湿度)—— 数据量大、实时性要求高,少量丢包不影响统计,UDP 更节省设备资源。
总结:核心选择逻辑
场景需求 优先选择协议
需保证数据不丢失、不重复 TCP
需低延迟、高实时性 UDP
数据传输量大(如文件) TCP
数据量小、单次请求(如 DNS) UDP
需避免网络拥塞 TCP
广播 / 组播场景 UDP
简言之:“可靠” 用 TCP,“快” 用 UDP。
实际应用中,也存在 “TCP+UDP 混合使用” 的情况(如微信:文本用 TCP,语音 / 视频用 UDP),以平衡可靠性和实时性。