项目里真正让人纠结的不是“TCP 可靠/UDP 不可靠”这种结论而是这些更具体的问题这个接口/链路到底能不能丢丢了能不能重试补救延迟更重要还是正确更重要连接数很多、短连接很多时系统扛不扛得住线上出问题了我怎么证明“丢包/重传/乱序”到底发生没发生这篇就用“知识分享 可验证”的方式把 TCP/UDP 的选择讲清楚。目录按做决策/排查的顺序先定标准你到底在权衡什么一张差异表先有地图TCP 的可靠性成本它到底多做了哪些事UDP 的低延迟来源它到底省掉了什么场景选择给你业务你怎么一句话选出来实战如何抓包/用命令验证是 TCP 还是 UDP、有没有重传最后总结1. 先定标准你到底在权衡什么在真实业务里你选 TCP 还是 UDP通常不是“选协议”而是在权衡三件事可靠性正确时延快开销轻TCP 偏可靠UDP 偏低延迟。TCP强调“可靠有序”适合文件/交易/登录/接口调用这类不能丢、不能乱序的场景。UDP强调“低延迟/轻量”适合音视频、实时游戏、DNS这类更在意时延、能容忍少量丢包的场景。2. 差异对照表先看整体维度TCPUDP连接面向连接三次握手/四次挥手无连接发就完了可靠性可靠确认/重传/序号/滑动窗口/拥塞控制不保证可靠、可能丢包/乱序有序性有序按序交付给应用不保证有序流量控制有接收窗口 rwnd无内建机制拥塞控制有慢启动/拥塞避免等无内建机制头部开销较大最少 20 字节小8 字节传输模式面向字节流没有消息边界面向报文有消息边界典型场景HTTP/HTTPS、SSH、FTP、数据库连接DNS、语音、直播、游戏、QUIC(基于 UDP)建议你先把这张表当成“地图”记住后面所有细节都能在这张表上找到位置。3. TCP 的“可靠”到底包括什么面试里不要只说“可靠”。你要能说清楚它靠哪些机制实现可靠。3.1 可靠交付序号 确认 重传序号Sequence Number给每段数据编号便于识别丢失/乱序。确认ACK接收方告诉发送方“我收到了哪些数据”。重传Retransmission发送方发现超时或收到重复 ACK就重发丢失的数据。3.2 有序交付乱序缓存按序给应用网络中可能出现乱序到达。TCP 会把乱序到达的片段先缓存等缺口补齐后再按序交付给应用所以应用层看到的是“顺序的数据流”。3.3 流量控制避免把接收方压垮接收方会在 ACK 中告诉发送方我当前还能接收多少数据接收窗口rwnd发送方就根据窗口控制发送速率。本质目的让接收方来得及处理3.4 拥塞控制避免把网络打爆即使接收方很强如果网络本身拥塞你继续狂发也会造成更严重的丢包。TCP 有拥塞控制典型四大算法慢启动拥塞避免快重传快恢复面试不用背公式但要能讲人话先试探网络容量出现拥塞就收敛网络变好再逐步放开4. UDP 的“不可靠”到底意味着什么UDP 的“不可靠”不是说它一定不可靠而是说协议层不保证所以它可能丢包乱序重复但优点也很直接不需要建立连接头部开销小发送路径短延迟更低而且 UDP 也不是完全不能“可靠”。你可以把可靠性上移到应用层比如 RTP/RTCP、游戏协议、或者 QUIC。5. 什么时候选 TCP什么时候选 UDP5.1 选 TCP 的典型场景特征数据不能丢顺序不能乱业务能接受额外握手与开销例子登录/下单/支付/转账文件上传下载数据库连接大多数传统 Web APIHTTP/1.1、HTTP/2 仍基于 TCP5.2 选 UDP 的典型场景特征极度在意延迟允许少量丢包或者可通过应用层补偿更需要“快”而不是“绝对正确”例子语音通话视频直播实时对战游戏DNS一次请求很小丢了重试成本也低5.3 一个面试官喜欢的说法权衡三角你可以用一句话总结“为什么要选”可靠性正确时延快开销轻TCP 偏可靠UDP 偏低延迟。6. 实战如何验证“我到底在用 TCP 还是 UDP”以及是否有重传6.1 最直接看端口协议Windowsnetstat-ano你关注两点连接是TCP还是UDP对应进程 PID 是谁把“网络问题”定位到具体进程6.2 抓包看证据Wireshark如果是 TCP你会看到三次握手、序号/ACK、可能的重传[TCP Retransmission]如果是 UDP你会看到一发一收的 datagram没有握手也没有协议层 ACK/重传6.3 常见排障思路你觉得“丢包”时先问 3 个问题是UDP 丢包应用层没补偿还是TCP 重传网络抖动导致吞吐下降是服务端处理慢应用耗时还是网络传输慢RTT/重传能不能通过重试/幂等把“少量丢”变成“可接受的结果”7. 最后总结7.1 UDP 真的不能保证可靠性吗协议层不保证。但应用层可以自己做序号、ACK、重传、窗口。加分点QUIC就是基于 UDP 在应用层实现可靠传输与拥塞控制用于 HTTP/3。7.2 TCP 为什么慢慢在哪里连接建立三次握手可靠性机制带来的确认/重传拥塞控制导致的“先慢后快”7.3 TCP 是“面向字节流”UDP 是“面向报文”是什么意思TCP你write的边界不保留可能出现粘包/拆包应用层要自己处理消息边界。UDP一次sendto对应一个报文边界接收时仍是一个整体超长会被截断。7.4 你可以这样总结写在脑子里的版本TCP 用“握手 确认 重传 窗口/拥塞控制”换来了可靠有序但代价是更高的开销与在弱网下更明显的性能波动UDP 把这些保证交给应用层换来更低延迟与更轻的协议负担适合实时场景。