1. 为什么又要聊TCP和UDP从一场面试谈起TCP和UDP这两个名字在网络技术讨论中出现频率绝对排得进前五。我面试过不少做客户端和后端开发的候选人简历上写着熟悉网络编程、做过高并发项目但一问到这两个协议的本质区别往往只能扔出一句“一个可靠、一个快”就没了下文。再追问TCP为什么可靠、UDP到底能不能做可靠传输、实际项目中应该怎么选多数人就开始支支吾吾了。这个现象其实不奇怪。现在开发框架和中间件太发达了很多场景下你根本不需要直接碰裸Socket。但正因为不碰一旦线上出了问题比如服务端出现大量TIME_WAIT、客户端偶发性卡顿、UDP丢包导致视频花屏你就很容易被卡住不知道怎么排查。所以我一直觉得TCP和UDP值得每个写网络代码的人重新认真梳理一遍而且要从“为什么这样设计”的角度去理解而不是死记硬背状态机。这篇文章我会从协议设计的底层逻辑、报文结构的核心细节、实际场景中的选型判断、抓包实证的方法以及真实项目中容易踩的坑这五个维度来展开。内容偏网络基础但我会尽量带上实操视角——毕竟这既是一篇给新手的入门梳理也是给我自己平时带团队时的一份内部文档。2. TCP一台精密的状态机2.1 三次握手到底在保证什么很多人把三次握手记成了“为了确认双方收发能力正常”这个说法没错但不够精确。我更愿意把它理解为双方在建立连接前先对一组初始序列号达成共识。为什么需要序列号因为TCP是字节流协议每个字节都要有编号接收方才能按序重组、去重、确认。假如没有初始序列号协商接收方就不知道对方发来的第一段数据应该是第几个字节。第一次握手客户端把自己的初始序列号告诉服务端同时申请服务端的序列号第二次握手服务端确认客户端的序列号并把自己的序列号发过去第三次握手客户端确认服务端的序列号。到这里两边都知道了对方的初始序列号接下来每发一个字节序列号都往后递增双方才能精确对齐。有一个经典问题为什么不是两次握手假设只有两次握手客户端发起的连接请求在网络中滞留了很久客户端等不到回应超时重传了结果滞留的那个旧请求先到达了服务端。服务端认为这是新连接立即分配资源并响应客户端收到响应后发现自己并没有发起这条连接于是丢弃这个响应。但服务端已经建立了一个半吊子的连接资源白白占用。三次握手的存在就是为了让服务端确认“客户端确实收到了我的响应”避免这种历史连接导致的资源浪费。实际开发中三次握手在客户端感知上一般不超过十几毫秒对局域网内的通信几乎无感。但跨地域的远端调用RTT如果偏高连接建立时间就会直接反映在接口时延上这也是为什么后来出现了连接复用、连接池、HTTP长连接这些优化手段——本质上都是在摊薄三次握手的成本。2.2 四次挥手与TIME_WAIT的真相断开连接比建立连接复杂因为TCP连接是双工的两边都能主动发送数据。四次挥手里前两次是主动方关闭自己这一半的发送通道后两次是被动方完成剩余数据发送后再关闭另一半。有个地方容易被忽视主动关闭方在收到对方的FIN后并不会立刻进入CLOSED状态而是进入TIME_WAIT要等2个最大报文段寿命2MSL之后才彻底关闭。很多人只记得这个常数不清楚原因。原因有两个。第一要确保被动关闭方收到自己的最后一次ACK。如果这个ACK丢了被动方会重发FIN主动方只有继续留在TIME_WAIT状态才能回应。第二要让网络中本连接的所有旧报文段自然消亡避免它们重现在同端口的新连接中被误判成新数据。TIME_WAIT这个机制在分布式微服务架构下会带来一个很实际的烦恼高并发短连接的服务器上TIME_WAIT套接字会大量堆积端口被占满新连接无法建立。我在排查类似问题时见过很多同事上来就调小TIME_WAIT值甚至直接禁用TIME_WAIT。这个做法只能说治标不治本。正确的思路是优先优化连接复用策略减少不必要的短连接其次调整系统参数时也要明白把2MSL调小意味着降低了极端场景下的报文防串扰能力需要权衡后再改。2.3 滑动窗口、拥塞控制与重传策略建立连接只是开始真正决定TCP传输效率的是滑动窗口和拥塞控制这两者经常被混为一谈。滑动窗口解决的是“收发双方速度不匹配”的问题。接收方在确认报文里捎带自己的窗口大小告诉发送方我现在还能接收多少字节。发送方据此把未确认但仍在窗口内的数据连续发出去不必等每个包都确认后再发下一个这就是批量流水线式传输的由来。拥塞控制解决的则是“网络本身能不能承受”的问题。即使接收端能处理得过来交换机、路由器也有缓存上限。如果发送端不管不顾猛发数据会在路由器排队等到队列满了就开始丢包反而触发重传风暴。TCP的拥塞控制算法里有一个最朴素的逻辑慢启动——连接刚建立时不知道网络的水有多深先小步试探确认没有丢包就指数增长遇到丢包就立即减半或者归零重来。从这个角度看TCP本质上是一个不断在“试探网络水位”的系统。它宁可保守也不愿意因为贪快把网络搞崩溃。这种设计哲学在实时音视频场景里反而变成缺点——因为TCP的拥塞控制对丢包异常敏感一旦网络抖动它会主动降速视频就会卡顿。这就是很多实时通信服务宁可选择UDP并自己实现拥塞控制的原因。3. UDP没有请柬的快递3.1 UDP报文结构看完就懂UDP的报文头就8个字节源端口、目的端口、长度、校验和。相比TCP动辄20字节以上的头部精简得有点寒酸。没有序列号没有确认号没有窗口公告没有标志位。发出去的数据对方收不收得到、按什么顺序收到、有没有重复UDP根本不闻不问。这种极简设计带来一个直接的好处首部开销极低能承载更大比例的有效数据。另外一个隐藏的好处是UDP没有连接状态的概念不需要维护每一条连接的表项。TCP的服务器基本每多一个客户端都要给连接分配文件描述符、维护状态、申请缓冲区UDP服务器则可以用同一个套接字接收所有客户端发来的数据每次只要从recvfrom里取出源地址再按这个地址回包就行。因此在同样资源下UDP能支撑的并发客户端数量要高出一个量级。我常把TCP比作两个人在电话里聊事情通了话就不挂断双方都占着线UDP则像是往一个收件箱里扔明信片寄给谁、寄了多少封、对方有没有看寄件人一概不知。这个类比贴切的地方在于它精准还原了“连接状态”和“无连接”的本质差异。3.2 UDP经常被误解的三件事误解一UDP一定会丢包。这要看场景。局域网内通信质量很好的时候UDP的丢包率可能极低低到可以忽略。丢包往往出现在跨公网的高延迟路径上此时路由器拥塞导致尾丢弃UDP报文会被无差别地丢掉。UDP本身不重传但你可以自己在应用层实现确认与重传逻辑做到业务层的可靠。误解二UDP比TCP一定更快。UDP去掉了握手、确认、拥塞控制这些机制原始速度确实比TCP“裸奔”更快但“快”不等于“体验好”。如果网络不稳定丢包后没有恢复手段接收方看到的可能就是破碎的声音和糊掉的画面。真正好的实时传输方案会在UDP之上加前向纠错编码即使丢少量包也能原样还原这比重传要快得多因为重传至少要等一个RTT才能补上。误解三UDP报文不能太大。这是新手最容易踩的坑。UDP报文最大理论可以达到65507字节但如果超过路径MTUIP层会分片出现分片后只要其中一个片丢了整个数据报就会被接收方丢弃。所以生产环境里UDP负载通常控制在1400字节以内给IP头部和UDP头部留足余量避免触发IP分片。这个细节经常被忽略甚至有些开源框架的例子里也会写一个超大的UDP块直接发出来在本地不出问题换个跨网环境就疯狂丢包。3.3 哪些场景是真的适合UDP最典型的就是流媒体传输。视频、语音对实时性要求高少量丢包可以通过编码冗余或插值掩盖但如果用TCP重传等一个RTT再补包整个节奏就全乱了。这就是为什么直播、实时语音、在线游戏大量采用UDP并自行在应用层实现丢包控制。另一个热门场景是物联网设备上报状态。传感器数据每秒钟可能上报几十次偶尔丢一次几乎没有影响下一帧数据很快会补上来。在这些场景里用TCP建立可靠长连接反而是一种资源浪费因为握手维持和保活探测都会消耗电量和带宽。还有QUIC。这个名字你可能听过它本质上是基于UDP做的一个全新传输协议结合了TCP的可靠性和UDP的低延迟优势现在HTTP/3已经全线依赖它。也就是说UDP并没有因为TCP的稳固地位而“过气”反而在新一代网络协议里扮演了核心角色。网上有些观点说UDP只能用于不重要的数据传输这种看法过于片面了。4. 选型逻辑什么时候该用TCP什么时候该考虑UDP4.1 四类业务场景的取舍判断我见过不少团队在技术选型时纠结TCP还是UDP纠结到最后往往是照搬网上文章或者凭感觉拍脑袋。其实做判断有一个比较实用的框架就是看业务对“数据完整”和“实时性”两个维度分别有多敏感。第一类强一致性、低并发、弱实时性业务比如数据库事务、文件传输、邮件发送。这类业务对数据完整性的要求极高宁可慢也绝不允许缺。TCP的确认重传、顺序保障在这里就是刚需。第二类高并发、短连接、请求响应型业务比如Web API、微服务间调用。这种业务用TCP依然合适但连连接都是严格按照TCP协议所以直接建议使用连接池来降低握手开销。真正要解决的是微妙时延和连接堆积问题而不是换协议。第三类低延迟流式传输比如直播推拉流、视频会议、在线游戏操作指令。这类业务最怕延迟不线性宁可偶尔丢一个包也不愿意因为等待重传造成卡顿。UDP是首选但要注意光选UDP不够应用层必须设计丢包补偿策略比如FEC、交织、冗余编码否则“快”很快会变成“烂”。第四类位于公网且链路质量极不稳定的物联网上报。可以考虑使用UDP加应用层确认的混合方案既减少连接资源开销又在小概率丢包场景下做可靠兜底。4.2 一个模拟项目X的选型经历我之前参与过一套跨平台通信系统的开发服务端需要同时支持消息发送和实时音视频通话。刚开始团队为了省事所有链路都统一走TCP长连接。消息功能没问题但音视频偶尔出现明显卡顿尤其是跨地域通信时网络一有抖动声音直接断断续续。后来我们把媒体流改成UDP通道信令层继续保留TCP。改动方案其实不复杂音视频数据用UDP直接送同时在接收端设计一个抖动缓冲区和丢包隐藏机制通知信令通道反馈网络质量。改造后卡顿概率明显下降因为TCP重传造成的随机延迟不再影响媒体流节奏。信令层保持TCP又确保了消息的可靠到达。这个项目的经验是没有必要在TCP和UDP之间做非此即彼的选择。成熟系统往往是混用模式——管理面用TCP数据面用UDP各取所长。把网络协议当成工具组合比把它当成信仰要实用得多。4.3 选型时容易忽略的隐性成本选TCP还是UDP不能只看协议本身还要算整体成本。用TCP开发可靠传输、流量控制、顺序重组都有协议栈帮你做完开发量小排查问题也有现成工具。用UDP看起来协议简单但可靠机制全部要自己担起来序号的维护、定时重传、重复包检测、乱序重组、拥塞控制每一项都不亚于重新实现半个TCP。所以在没有明确的低时延诉求也没有大规模并发连接压力时使用TCP其实是成本最低的选项。很多团队提出要用UDP其实并没有想清楚那几项隐藏成本。比如需要量化丢失率需要评估重传延迟是否能被业务容忍需要设计发送窗口的控制这些都不是简单换一个Socket类型就能解决的。选型是推演出来的不是拍脑袋拍出来的。5. 动手抓包把协议“看”明白5.1 Wireshark抓TCP三次握手的姿势协议这种东西光看文字理解很容易浮于表面。我建议你花半小时抓一次包亲眼看看三次握手的样貌比读十篇文章都管用。先准备一个能开启回环抓包的网络接口Wireshark直接抓Loopback即可。然后随便找一个TCP服务比如本地开一个Web服务浏览器去访问一次过滤表达式写tcp.port 8080抓完包后按时间排列你会看到前三条记录分别是SYN、SYN-ACK、ACK。点开任意一条重点看TCP头部里的Sequence Number和Acknowledgment Number。你会发现后一条报文的确认号恰好是前一条报文序列号加一。这个过程就是前面讲的初始序列号协商。有一个细节很有意思如果不是标准浏览器而是某个自己写的Socket客户端初始序列号往往从随机值开始这个随机化正是出于安全考虑防止第三方猜测序列号注入伪造数据。抓包时如果看到初始序列号不是0这不是bug是新内核默认开启了临时端口随机化和时间戳偏移机制。5.2 用Python模拟一段UDP通信UDP的抓包验证比TCP容易得多。写一个最小示例一个进程发一个进程收。先看发送端import socket sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) data bhello udp sock.sendto(data, (127.0.0.1, 60000)) response, peer sock.recvfrom(1024) print(response, peer)接收端import socket sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.bind((127.0.0.1, 60000)) while True: data, peer sock.recvfrom(1024) print(ffrom {peer} received {data}) sock.sendto(bpong, peer)用Wireshark抓回环口过滤udp.port 60000你就能清楚地看到双方往返的报文。注意观察这里的报文顺序不会出现TCP那样的确认迹象一切看起来就像两个程序在“喊话”没有同步握手也没有窗口协商。网上很多教程写到这里就结束了但这恰恰忽略了UDP面对分片时的表现。如果我把data改成一个超大的字符串比如100KB抓包里你会看到IP层把UDP报文切成了多个分片。这意味着接收端只要丢其中一个分片整个UDP数据报就废弃了。这个现象最好自己实验一次你会对“为什么UDP数据负载不宜过大”这句话有刻骨铭心的理解。5.3 抓包验证“快重传”需要一点点小技巧TCP的拥塞控制机制想抓包验证并不容易因为默认本地网络条件太好很难自然触发丢包。可以借助macOS或Linux上的网络损伤工具模拟丢包、延迟和乱序然后再发起一个TCP下载任务。Wireshark里重点关注TCP重传标记和Dup ACK再结合IO Graph里的吞吐量曲线你能看到窗口下降后再慢慢恢复的节奏比单纯看状态机图有说服力得多。这里有一个经验不要一上来就在复杂的生产网络里抓包人为制造可控干扰在仿真环境里验证协议行为得到的结论既清晰又好复现。等你对协议在异常条件下的表现有了直观印象再去排查线上问题思路会清晰很多。6. 常见问题与排查经验6.1 TIME_WAIT过多导致端口不足现象是服务端日志报“Cannot assign requested address”或者客户端连接超时的概率变高。排查时先用命令看套接字统计注意区分是哪一侧出现问题。这类问题常见于高并发短连接服务解决方案优先级第一优先使用连接池第二优先复用客户端实例第三考虑调整tcp_tw_reuse参数。关键点在于不要把参数调整当成终极手段它只是短期缓解。我实际观察过不少项目把连接池配好后TIME_WAIT数量能降一大截根本不需要动系统参数。如果一上来就改内核参数短期内好像解决了换一个流量模型又可能引入新的隐蔽问题。6.2 粘包与半包使用TCP时会遇到的经典问题就是粘包与拆包。TCP是字节流协议它不关心业务消息边界接收方拿到的可能是两个消息拼接成的数据也可能是一个消息切成两半的数据。解决办法主要看消息格式用固定长度、特殊分隔符、或者自定义长度字段。实际开发中我倾向于使用“长度前缀”方式因为通用性最强也没有转义问题。很多开源通信框架其实也是基于这个思路实现的。写自己的拆包逻辑时一定要处理半包情况因为只是简单地“读够长度再解析”遇到网络慢或缓冲区小仍然会出现问题。另一个纵深防御是对接收缓冲区做上限保护防止恶意对端声明一个超大的消息体导致内存被打满。这个教训来自一个真实的线上事故没做长度上限校验客户端发了一个异常长度值服务端直接申请了异常大的缓冲区把内存拉垮了。6.3 UDP偶发丢包排查思路UDP丢包不是等概率随机发生的它在接收端通常和缓冲区溢出有关。Linux上每个UDP套接字对应一个接收队列当应用处理不过来时新到的数据包会被内核直接丢弃。查看丢包计数可以用netstat或ss里的UDP相关字段。丢包数持续增长说明用户态处理速度跟不上到达速度只调大缓冲区是延缓而非根治。有效的做法有几个多线程接收与业务处理分离减少在接收线程里的磁盘操作如果吞吐量特别大可以绕过内核协议栈使用DPDK这类用户态网络框架。业务量还没到那个级别时先优化处理逻辑和队列模型即可。UDP还有一个隐性丢包源路由器或交换机的队列溢出。这类丢包在服务端和客户端指标上看不出来只有抓包对比输出端和输入端流量差才能确认。很多同事第一次排查公网UDP丢包时总在程序代码里找问题忽略了网络中间设备其实先做两段抓包对比定位会更高效。6.4 MTU分片与性能陷阱前面提到UDP负载过大触发IP分片会严重影响可靠性但TCP同样躲不开MTU问题。TCP虽然不会让IP层随意分片但路径MTU发现机制一旦失效探测包本身也可能被丢弃导致连接反复重传吞吐量骤降。排查思路是抓包看是否有大包被标记为不可分片然后回显ICMP错误消息。有些网络设备出于安全考虑会屏蔽ICMP这就造成MTU黑洞。生产环境有一条实用经验内网服务的网卡MTU绝大多数是1500如果业务帧特别大考虑改为巨型帧前必须确认交换机、中间链路设备全部支持。只改服务器网卡而不改中间链路等于在高架桥上放了个限宽桩大车一次过不去来回倒腾性能反而变差。6.5 常见问题速查表问题现象可能原因首选排查动作客户端大量连接失败TIME_WAIT堆积占满临时端口检查ss统计确认TIME_WAIT数量改造连接池TCP发送吞吐量骤降触发了拥塞控制或链路丢包抓包看重传和重复确认用工具模拟并复现条件应用收到数据不完整TCP半包或粘包检查自定义拆包逻辑验证长度字段处理UDP接收端有丢包接收缓冲区溢出查看队列丢弃计数优化消费处理能力UDP跨公网大量丢包IP分片或中间设备受限降低单个报文负载确认MTU与分片策略视频通话随机卡顿弱网下TCP重传导致时延抖动尝试媒体流切UDP并增加抖动缓冲与FEC冗余这张表是我基于平时排障的经验整理的不覆盖所有场景但可以作为你排查时的起点。真正面对问题的时候先看数据再动配置不猜例外试完一步看一步效率反而最高。7. 结尾我的一些体会与后续扩展方向写到最后分享一个我自己的感受。TCP和UDP谈论了几十年看似是老生常谈但每一年都有人因为基本功不扎实而走弯路。无论是排查线上偶发不稳定还是设计新系统的通信方案最终拼的是对这两个协议在真实网络条件下行为的直觉。多抓包、多模拟异常、亲手复现一次粘包和丢包比记一堆状态名管用得多。如果还想继续深入可以从几个方向入手看一遍TCP拥塞控制不同实现的源码动手写一个基于UDP的ARQ重传协议或者研究HTTP/3和QUIC为什么选择用UDP重建可靠传输。网络协议栈像一个精密的机械手表每一个看似冗余的设计背后都有它存在的逻辑研究得越深你在做系统设计时的底气也越足。
