★ FEATURED ARTICLE 做网络开发这些年面试过不少人也被面试过不少次但凡聊到TCP和UDP几乎每一轮都会问。但真正能把这两个协议讲明白、讲透并且落到实际业务里解决问题的其实很少。大部分人能背出三次握手、四次挥手却说不清为什么握手是三次而不是两次为什么挥手要等两分钟更不用说线上出现大量TIME_WAIT时怎么快速定位。我写这篇文章就是想把这些年在传输层上踩过的坑、调过的参、看过的包都整理出来把TCP和UDP背后的设计逻辑和实操要点讲清楚让做后端、客户端、网络运维的朋友都能少走弯路。文章会先从传输层的整体定位入手再分别拆解TCP和UDP的核心机制接着用实际案例讲清楚开发中怎么选型、内核参数怎么调、抓包怎么分析最后整理一份常见问题排查速查表。不管你是刚入门的新手还是已经被线上问题折磨过的老手应该都能从中找到有用的东西。1. 传输层的定位与两个协议的设计哲学1.1 传输层到底在解决什么问题要理解TCP和UDP先得明白传输层在网络模型里是干什么的。简单说网络层负责把数据包从一台机器送到另一台机器但它只保证“尽力送达”不保证顺序、不保证不重复、甚至不保证一定到达。而传输层就是在网络层之上为应用层的进程之间提供端到端的数据传输服务。打个比方网络层像邮政系统它只负责把信件从一个城市送到另一个城市但不保证信件的先后顺序也不保证路上不丢。传输层则是在这个邮政系统之上给两个具体的人进程之间建立通信通道。TCP像是寄挂号信每一封都有编号、有回执丢了会重发收件人会按编号整理好交给收信人UDP像是寄平信或者发短信直接扔进邮筒能不能到、什么时候到、到的时候是不是完整寄信人一概不管。这个定位决定了传输层必须解决几个核心问题如何标识不同的应用进程、如何可靠地传输数据、如何控制流量避免接收方处理不过来、如何避免网络拥塞。TCP和UDP分别给出了两种截然不同的答案。1.2 TCP和UDP的定位差异可靠与实时TCP传输控制协议和UDP用户数据报协议是传输层最核心的两个协议它们的设计哲学几乎是两个极端。我把这两个协议的核心差异整理成了一张对比表方便对照看对比维度TCPUDP连接状态面向连接需要建立连接无连接直接发包可靠性可靠确认重传、序号校验不可靠发完不管数据有序性保证按序到达不保证顺序报文边界字节流需要处理粘包拆包保留报文边界一次发一个数据报流量控制支持滑动窗口机制不支持拥塞控制支持慢启动、拥塞避免不支持传输开销大头部至少20字节小头部仅8字节双工性全双工双向独立收发全双工但无状态控制典型场景文件传输、Web访问、数据库连接实时音视频、游戏同步、DNS查询为什么需要两种如此对立的协议归根到底是因为业务场景的需求是不同的。文件下载不能丢一个字节所以需要TCP的可靠传输视频通话延迟超过几百毫秒体验就崩溃丢几帧反而无所谓所以需要UDP的低延迟特性。没有哪个协议是万能的选型的关键是看清楚业务对可靠性、延迟、带宽利用率各有多敏感。这里有一个常见的误区很多人以为UDP就一定比TCP快。严格来说UDP在延迟表现上确实通常优于TCP因为它省去了握手开销、确认机制、拥塞控制带来的等待。但在带宽受限场景下TCP的拥塞控制反而能更充分地利用带宽因为TCP能够感知网络状况并动态调整发送速率UDP则容易把网络打爆。所以不能说谁绝对更快只能说谁更适配场景。2. TCP的核心机制拆解为了可靠它做了什么2.1 三次握手为什么必须是三次而不是两次或四次三次握手是TCP建立连接的标准流程客户端发SYN服务端回SYNACK客户端再回ACK。这一步大家都很熟但关键是为什么必须是三次。原因在于TCP通信双方都要确认“自己发的包对方能收到对方发的包自己能收到”。第一次握手客户端发出SYN服务端收到后服务端能确认自己的接收能力和客户端的发送能力都正常。第二次握手服务端回SYNACK客户端收到后客户端能确认自己的发送能力、接收能力和服务端的发送、接收能力都正常。但此时服务端还不能确认自己发给客户端的SYN是否被客户端正确接收所以需要第三次握手客户端再回一个ACK服务端收到后整个链路才完全确认畅通。还有个更隐蔽的问题防止历史连接请求的干扰。假设没有第三次握手一个网络中延迟了很久的旧SYN包突然到达服务端服务端直接建立连接并分配资源但这个连接其实是无效的客户端根本不知道这回事。而有了第三次握手客户端收到SYNACK后会判断这个连接是不是自己当前发起的如果发现不是就回一个RST来取消这次无效连接。这个机制在移动网络切换、IP地址变化等场景下特别重要。我曾经遇到过一类线上问题客户端频繁报连接超时但服务端连接数并没有打满。排查后发现是某些客户端发出的SYN包在网络上滞留时间过长或者客户端重试过于激进导致服务端处理不过来。这类问题不能只调代码还需要理解握手机制背后的时序逻辑才能针对性优化。2.2 四次挥手与TIME_WAIT为什么主动关闭方要等两分钟连接建立后正常结束时四次挥手主动方发FIN被动方回ACK被动方再发FIN主动方再回ACK。为什么要分两步因为TCP是全双工的每一方的数据通道都要独立关闭。被动方收到FIN只是说明主动方不再发数据了被动方可能还有数据要发所以先回ACK确认收到关闭请求等自己的数据发完再发FIN这才完整关闭整个连接。四次挥手里最容易出问题的是TIME_WAIT状态。主动关闭方在发完最后一个ACK后不会立即关闭连接而是进入TIME_WAIT状态默认等待2个最大报文段生存期通常为2分钟即2*MSL。这个等待不是白白浪费资源而是有两个作用第一如果最后一个ACK丢失了被动方会重新发FIN主动方需要保证自己还能回应这个FIN所以必须等待足够的时间。第二防止旧连接的数据包在网络里残留干扰新连接。如果主动方立即关闭并重用同一个端口建立新连接老连接在网络里滞留的数据包可能被新连接误认为是自己的数据导致数据错乱。线上最容易遇到的坑是短连接场景下大量TIME_WAIT堆积。某个内部服务用HTTP短连接做远程调用每秒钟成千上万的请求每次请求结束后主动关闭方都会留下一个TIME_WAIT连接如果不处理服务端的本地端口很快会被占据新连接无法建立。这里要注意TIME_WAIT只出现在主动关闭的一方所以如果是服务端主动关闭连接压力就全在服务端。针对TIME_WAIT过多我用的最多的是这几个手段调整内核参数net.ipv4.tcp_tw_reuse允许内核重用处于TIME_WAIT状态的连接开启net.ipv4.tcp_tw_recycle但这个参数在新内核中已经不建议使用因为NAT场景下会引发严重问题改造业务代码让客户端而不是服务端主动关闭连接以及使用长连接池避免频繁建连断连。每种方式都有适用场景实际操作时需要结合业务类型权衡不能盲目开启。2.3 滑动窗口、流量控制与拥塞控制可靠之外的生存法则TCP除了保证不丢包还要保证不发太快。接收方处理数据的能力是有限的如果发送方不管不顾地拼命发接收方缓冲区会溢出数据照样会丢。TCP的做法是引入滑动窗口机制接收方在ACK报文里告诉发送方自己的接收窗口还有多大发送方据此控制自己能发送的未确认数据量。滑动窗口的大小直接决定了TCP的吞吐性能。我调优过很多慢速下载问题最后发现瓶颈往往不在带宽而在接收窗口设置太小。比如一个视频点播服务客户端接收窗口只有16KB服务端每发满16KB就得停下来等ACK即使带宽有100Mbps也跑不满。把接收窗口提升到256KB、甚至1MB后吞吐量成倍增长。这里有个经验调大窗口的同时还要确认网络带宽和延迟的乘积也就是带宽延迟积BDP窗口只有达到BDP的量级才能把链路用满。拥塞控制是TCP的另一大机制它关心的是整个网络而不是单个连接的状况。TCP通过慢启动、拥塞避免、快速重传、快速恢复等算法来感知网络拥塞状态。慢启动阶段拥塞窗口从1开始指数增长每收到一个ACK就翻倍直到达到慢启动阈值之后进入拥塞避免阶段窗口线性增长一旦发生丢包传统TCP会认为网络拥塞把窗口减半甚至重置再重新探测。这里对业务的影响非常大。在高带宽低延迟的数据中心里TCP的拥塞控制可能会导致带宽利用率不高于是出现了BBR等新算法它不再以丢包作为拥塞信号而是估算带宽和延迟来调整发送速率。我在实际调优中测试过BBR对长肥网络的提升非常明显尤其是跨地域传输大文件带宽利用率能从50%左右提升到90%以上。但BBR并非万能在延迟敏感型业务上效果一般需要结合实际场景对比实测。2.4 粘包与拆包TCP字节流带来的应用层难题TCP是字节流协议它不关心应用层的消息边界。发送方调用三次send发送三个消息接收方可能一次recv收到全部数据也可能分两次收第一次收到一条半第二次收到剩下的一条半。这就是粘包和拆包问题的根源。很多人一开始不理解这个问题总觉得网络传输天然会按消息切割。但实际上TCP只保证字节顺序不保证消息边界应用层如果不自己界定边界数据就乱套了。解决粘包拆包问题通用的方案有三种固定长度报文每个消息定长不足则补齐接收方按固定长度截取。简单但浪费带宽适合消息长度变化不大的场景。分隔符每个消息末尾加特定分隔符比如换行符、自定义特殊字符。适用于文本协议但要求消息内容不能包含分隔符否则需要转义。包头加包体长度在消息头中写入整个消息的长度字段接收方先读固定长度的头部解析出长度后再读对应长度的包体。这是最通用、最推荐的做法也是HTTP等协议采用的方式。我在设计内部RPC协议时用的就是最后一种消息头固定若干字节前4字节标识消息总长度后面再跟消息ID、消息类型等字段最后是消息体。接收方通过长度字段做切片彻底解决了粘包问题。实际操作时要注意消息长度字段的设计要预留足够的位宽如果业务可能出现超大报文4字节最大4GB往往够用但接口要做好异常检查防止恶意构造长度字段导致内存分配异常。3. UDP的价值再发现实时传输里的王牌3.1 UDP为什么能快无连接、无状态、低开销UDP之所以在实时场景中表现突出根本原因是它把协议层能省的全省了。发送数据前不需要三次握手直接调sendto就能发。发送后不需要等待ACK不需要维护重传队列不需要管理拥塞窗口接收方也不需要对数据排序。每一条UDP报文独立传输互不依赖协议头部只有8字节比TCP的20字节小一半多。这个设计带来的直接优势是延迟可控。TCP一旦发生丢包重传和数据阻塞会带来明显延迟抖动而UDP即使丢包也只是少了这一帧数据后续数据照常到达。对在线游戏来说角色控制指令迟到了200毫秒是不可接受的但偶尔丢一个位置包反而无关紧要因为下一帧就会刷新位置。对视频通话来说画面卡一下总比整段声音连不上要好。3.2 UDP的典型应用场景与协议设计思路UDP最经典的应用场景包括实时音视频通话、在线游戏、DNS查询、物联网设备上报、网页使用的QUIC等。表面上看这些场景毫无关联但它们都有一个共同点对实时性要求高或者单次交互的数据量小、不依赖长连接状态。拿游戏同步来说场景本身是高速动态变化的玩家位置、动作状态每隔几十毫秒就要同步一次。如果用TCP一旦出现丢包TCP会重传数据并且后续数据被阻塞游戏里看到的就是角色瞬移或者卡顿。而UDP天然不追求可靠游戏引擎会根据多个UDP数据报做插值、预测和补偿让画面表现流畅。游戏引擎内部还会自己实现一套可靠传输层对重要的指令如登录、交易做应用层确认和重发把UDP用完就扔的缺点在应用层补救回来。物联网设备上报是另一种典型场景。大量低功耗设备每隔几分钟上报一次数据连接建立和断开的开销如果都用TCP完成功耗和带宽都受不了。UDP一发一收极其轻量。一些物联网平台推荐设备使用UDP传输再配合应用层的消息确认机制在弱网环境下反而表现更稳定。DNS查询也同理每个查询通常只有一个或少数几个包用TCP反而会因为握手和队头阻塞拖慢响应。3.3 QUICUDP上长出可靠连接的现代化尝试传统观念里可靠传输必须用TCP但QUIC改变了一切。QUIC基于UDP实现在用户态实现了一套类似TCP的可靠传输逻辑数据包编号、确认机制、丢包重传、流级排序。QUIC相比TCP最大的优势有三点。第一连接建立快0-RTT恢复客户端如果之前连接过再次连接时可以在第一个包里携带数据省掉一个RTT对首包延迟极其敏感的业务提升巨大。第二解决了队头阻塞问题TCP的可靠性是整条连接级别的一个报文丢失会导致后续所有报文等待QUIC则是多流并行每条流独立确认一条流的丢包不影响其他流的数据交付这刚好命中当前HTTP/2等场景下多资源并行加载的需求。第三连接迁移支持好TCP用四元组标识连接IP或端口变化就断连QUIC用连接ID标识连接用户从WiFi切到4G网络连接依然保持对移动端体验是实质改善。目前QUIC已经广泛应用于现代浏览器访问网页的HTTP/3协议也就意味着很多你已经日常在用的业务底层其实已经跑在UDP上了。这也是UDP近年重新被业界重视的重要原因不是UDP变强了而是开发者学会了在UDP之上按需叠加可靠性而不是让协议本身去适应所有场景。4. 开发选型与内核调优怎么把两个协议用对4.1 业务需求决定选型一个决策清单选TCP还是UDP不应该凭直觉或技术偏好而是应该逐条审视业务需求。我习惯用下面这张清单来帮助决策数据完整性要求要求不丢不差优先TCP允许少量丢失可考虑UDP。实时性要求交互延迟敏感且数据是周期性更新的优先UDP偶尔的延迟可以容忍则TCP更稳。消息频率与连接时长高频短连接、连接数量巨大的场景UDP开销优势明显。数据量大小海量数据持续传输TCP的拥塞控制更利于网络公平性UDP需要自己实现拥塞控制来避免打垮网络。是否容易实现自定义可靠机制如果团队成员有网络编程经验UDP加应用层确认重传往往是灵活性最高的方案。中间网络设备兼容性有些老旧防火墙和负载均衡设备对UDP并不友好需要验证网络基础设施的支持情况。之前我遇到过两个业务一个做实时对战游戏一个做文件同步工具。前者用了TCP实测在弱网下体验较差后来改为UDP传输位置和动作数据再用TCP承载登录和结算等关键交互效果立竿见影。后者坚持TCP因为文件同步场景对完整性要求极高UDP方案即使加了重传逻辑实现复杂度和出错概率也远高于直接用TCP。4.2 内核参数调优不要盲目照搬网上的配置传输层的很多问题往往不是改代码能解决的需要调整操作系统内核参数。常见的几个参数如下net.ipv4.tcp_tw_reuse允许重用TIME_WAIT连接适合大量短连接场景但只对客户端侧有效因为重用的是本端向外发起的连接。net.ipv4.tcp_fin_timeout主动关闭方等待FIN报文的时间默认60秒适当调低可以减少半连接状态的时长但不能低于合理范围否则数据可能残留。net.core.rmem_max和net.core.wmem_maxUDP收发缓冲区上限UDP报文到达时如果接收缓冲区满报文会被直接丢弃调大缓冲区可以减少丢包。net.ipv4.tcp_rmem和net.ipv4.tcp_wmemTCP读写缓冲区范围TCP会根据延迟和带宽动态调整但边界设置需要贴近业务模型。net.ipv4.tcp_congestion_control拥塞控制算法可选cubic、bbr等不同算法在特定场景下表现差异很大。调整内核参数时我有一条重要经验不要盲目照搬网上的配置。曾经有个同事网上看到某篇调优文章直接把tcp_tw_recycle打开来缓解TIME_WAIT问题结果客户端因为处于NAT网络大量连接异常中断。tcp_tw_recycle依赖对端时间戳递增的机制NAT设备后面的多台设备时间戳可能不一致导致服务端误判乱序拒绝连接。这条参数如今在内核中已经默认移除但理解它的原理对排查历史问题是很有帮助的。4.3 抓包分析把协议细节看清楚遇到传输层疑难问题抓包是定位问题最快的方式。我抓包最常用的工具是系统自带的tcpdump和各种图形化分析工具关键是要学会看TCP报文头部的标志位和时序序列。三次握手的抓包里你会看到客户端发SYNseq为一个随机初始序列号服务端回SYNACKseq为服务端的序列号ack为客户端的序列号加1客户端最后回ACK完成建立。通过这个时序可以快速判断连接卡在哪一步如果只有SYN没有SYNACK说明SYN包被防火墙丢了或者服务端根本没收到如果服务端发出SYNACK但没有收到客户端的ACK则多半是后端应用服务存在半连接处理问题或者客户端异常中断了。UDP抓包相对简单每个数据报都是独立的。主要关注源端口、目的端口、包长以及到达时间间隔。我发现UDP丢包问题时会先看抓包中是否存在大段不连续的时间空隙比如固定每20毫秒发一包的流量抓包里突然断开几百毫秒多半是网络拥塞导致队列溢出。再做双端对比抓包一端在客户端、一端在服务端对比同一时间段的报文数量和序列就能确认丢包发生在哪个网段。5. 常见问题与排查技巧实录5.1 连接建立超时三次握手没握上现象客户端报connect超时服务端日志显示大量SYN_RCVD状态但连接迟迟没有建立。排查思路先在服务端本机抓包看SYN包是否到达。如果服务端根本没收到SYN问题在网络路径上可能是防火墙或安全组拦截如果收到了SYN但没有回SYNACK检查服务端的监听队列是否溢出。TCP有一个重要机制叫SYN队列和accept队列应用进程处理不过来时accept队列会满内核停止响应新的SYN。注意观察服务端状态如果大量连接处于SYN_RCVD但应用侧连接数没有增长基本可以断定是accept队列溢出需要调整应用进程的并发处理能力或者减小握手响应时间。我自己还遇到过一种小众情况客户端SYN携带了TCP时间戳选项而服务端因为开启tcp_tw_recycle导致直接丢弃。这类问题排查时往往需要对TCP选项逐项核对而不仅仅是看标志位。5.2 大量TIME_WAIT导致端口耗尽现象服务端进程出现大量TIME_WAIT连接报错cannot assign requested address无法建立新连接。解决思路首先区分谁是主动关闭方。如果是服务端主动断开的短连接优先改造代码由客户端主动断开如果无法改造再考虑开启tcp_tw_reuse和调整端口范围。客户端端口耗尽问题则可以通过调大net.ipv4.ip_local_port_range来缓解同时注意检查是否有连接没有被正常关闭比如异常分支没有执行close。这类问题的根治方案往往是使用连接池把短连接改成长连接。长连接不代表永不关闭而是复用连接降低建连频率但长连接也会引入空闲连接管理、探活机制等复杂度需要综合考虑。5.3 UDP丢包与乱序应用层如何自愈现象UDP接收端收到流不连续或者数据顺序错乱讲音频时出现声音间断。排查思路UDP丢包常见原因有两个一是网络链路本身丢包二是接收缓冲区太小或应用处理太慢。先做双端抓包对比如果发送端发了1000个包接收端内核只收到800个问题在链路如果接收端内核收到800个但应用层只读出了500个问题在应用读取速度或缓冲区配置。调大net.core.rmem_max和socket接收缓冲优化接收线程的处理效率可以减少大部分丢包。乱序问题通常和网络路径变化有关比如多运营商出口路由策略导致不同包走了不同路径。应用层应对乱序最简单的方法是加序号字段接收端按序号缓存和排序。如果对实时性要求高也可以按时间戳丢弃迟到过多的包保证内容的及时性。5.4 UDP攻击与防爆破端口暴露后的第一道防线UDP本身无连接基于UDP的攻击手段非常多流量放大反射、UDP洪水等攻击方式大家都听过。这里不展开攻击细节只从防御角度提几个经验非业务所需的UDP端口一律对公网关闭只放行明确的业务端口。对UDP业务流量做限速策略保证异常情况下不会击穿核心应用。应用层协议设计时加入验证逻辑比如固定伪随机头字段、时间戳校验、票据认证过滤掉非法报文。很多开发者低估了UDP暴露在公网的风险觉得UDP无连接、无状态攻击者也就无从谈起。实际上UDP的每个报文都可以伪造源地址攻击成本极低防护必须前置。确保线上环境的安全策略是最基本的一步然后是应用层加固。5.5 抓包工具使用与常见误区最后补充几个抓包分析时容易踩的误区第一个误区是只看服务端抓包。网络问题往往需要双端对比才能定位单独看一端很容易误判比如服务端发了数据但客户端没收到问题可能在客户端的内核或应用而不是网络丢弃。第二个误区是忽略TCP重传。抓包过程中如果发现大量TCP重传包说明网络存在丢包或延迟异常。要看重传的时序和间隔快速重传通常间隔很短超时重传则可能达到成百毫秒甚至秒级两者对应的网络问题不同。第三个误区是没有过滤干扰流量。生产环境抓包时其他业务流量会混在一起导致包文件巨大而且难以分析。抓包前规划好过滤规则只看目标IP和端口。实际操作中我会把抓包结果保存为文件再导入分析工具利用工具提供的流重组功能把分散的报文还原成完整的连接视图这比直接看原始报文高效得多。6. 最后一个建议多实践别只停留在理论上写到这里传输层的核心内容已经基本过了一遍。TCP的可靠机制远比我写出来的复杂UDP之上能叠加的设计也远比想象中灵活想要真正掌握一定要多通过动手实践去加深理解。我个人特别喜欢的学习方式是自己在本机搭建百兆和千兆网络环境然后用工具制造人为丢包和延迟再同时运行TCP服务端和UDP服务端对比两个协议在相同网络条件下的表现差异。你会发现只有当丢包率达到一定比例时TCP的重传优势才开始显现而在低丢包、高延迟场景下TCP的握手开销和拥塞控制带来的延迟成本往往比丢包重传的成本更明显。亲手验证这些现象远比背十条理论记住的内容扎实。如果看完这篇文章你决定在某个真实项目里尝试一次UDP加应用层确认重传的方案或者动手调一次TCP的内核参数那我写的这些内容就算真正派上了用场。基础协议的东西看似没什么新意可每次线上出问题最后兜底的还是这些基础认知。
阅读完成 · 觉得有帮助？
