在运输层使用UDP协议的服务器，最常见的是DNS域名服务器、DHCP动态主机配置服务器、TFTP简单文件传输服务器，以及流媒体服务器和在线游戏服务器。这些服务器之所以选择UDP，是因为它们更看重传输速度和实时性，而不是绝对可靠的数据重传，下面把这几类服务器的具体工作方式、适用场景和选择逻辑一次说清楚。
为什么这些服务器偏爱UDP而不是TCP
TCP和UDP是运输层的两个核心协议，TCP像个严谨的快递员，每次发货都要确认签收，丢件就重发，适合网页、邮件、文件传输，UDP则像个热情的广播员，只管把数据包扔出去，不管对方收没收到，因此延迟极低,开销也小。
行业共识认为，UDP适合那些“丢了几个包也能接受”或“追求低延迟优先”的业务，对于DNS查询来说，一个请求通常只有几十字节，如果丢包，客户端自己会重试，根本不需要TCP那么复杂的确认机制，对于流媒体和游戏，偶尔丢一两帧画面或一次操作指令,远比重传导致的卡顿更容易接受。
第一类：DNS服务器最典型的UDP使用者
DNS服务器是把域名解析成IP地址的“电话簿”，大多数DNS查询走的是UDP 53端口，流程非常简洁：你的电脑发一个UDP包问“www.example.com的IP是多少”，DNS服务器收到后直接回一个UDP包告诉答案,一来一回通常只有几十毫秒。
为什么不用TCP做DNS查询
- 查询报文太小，TCP需要三次握手才能建立连接，握手本身就要多一趟网络往返,太浪费时间。
- DNS查询次数极其频繁，每次上网浏览都会触发多次解析，如果用TCP,DNS服务器的负载会成倍增加。
- 简单请求用简单协议，UDP的无连接特性让DNS服务器可以同时处理成千上万个并发查询,效率极高。
只有两种情况才使用TCP 53端口：一种是DNS响应报文超过512字节（较新的EDNS机制支持更大），另一种是区域传输主服务器向备用服务器同步整个域名数据库时,必须用TCP保证数据的完整可靠。
日常排查DNS服务器是否异常的思路
如果你怀疑某台DNS服务器响应慢，可以用nslookup或dig工具发一个UDP查询看耗时，比如Windows系统里打开命令提示符，输入nslookup www.baidu.com 8.8.8.8，如果长时间没响应，再换成TCP模式试试：nslookup -vc www.baidu.com 8.8.8.8，两个结果一对比,就能判断是不是UDP包被防火墙拦截了。
第二类：DHCP服务器没有UDP就没法自动上网
DHCP服务器负责给局域网里的设备自动分配IP地址、网关、DNS等网络参数，你的手机连上Wi-Fi能直接上网，背后就是DHCP在起作用，DHCP全程走UDP端口67（服务器端）和68（客户端）。
自动分配IP的启动过程
- 新设备接入网络时，自己没有IP地址，会用UDP广播发送一个DHCP Discover报文，源地址是0.0.0.0，目的地址是255.255.255.255。
- 网内的DHCP服务器收到后，从地址池里挑一个空闲IP,用UDP广播回复Offer报文。
- 设备收到Offer后，再广播一个Request报文，说“我就用这个IP”。
- 服务器最后广播Ack报文确认,设备开始正常使用网络。
整个过程全部基于UDP广播，因为设备在获得合法IP之前，根本无法建立TCP连接，如果DHCP服务器改成TCP，新设备连IP都没有，TCP握手根本无从谈起,所以DHCP解析IP地址的过程天生就是UDP的天下。
家用路由器里的DHCP服务器
你家里的无线路由器，本质上就是一个微型DHCP服务器，登录路由器的管理后台，在“局域网设置”里能看到DHCP服务开关和地址池范围，如果某天手机连接Wi-Fi显示“无法获取IP地址”，大概率是路由器上的DHCP服务挂了,重启路由器或手动给手机设置静态IP就能临时解决。
第三类：TFTP服务器和简单网络管理场景
TFTP（简单文件传输协议）是一个比FTP简单得多的文件传输协议，使用UDP 69端口，它没有目录浏览、没有用户认证，只支持读文件和写文件两种操作，正因为简单轻量，TFTP常被用来给网络设备升级固件、备份交换机配置文件,或者在PXE网络启动时传输引导镜像。
- 路由器或交换机刚开机时，系统引导程序（Bootloader）还不太完善，没法跑复杂的FTP客户端,用TFTP最稳。
- TFTP虽然用UDP，但它自己有一个简单的ACK确认机制：每发送512字节数据，就等对方回一个确认包，超时则重传，这种“小型可靠机制”让它在UDP基础上依然能确保文件不传错。
很多网络设备上的SNMP（简单网络管理协议）监控服务也用UDP 161端口，网络管理员通过SNMP查询设备的CPU使用率、流量状态、温度等数据，这些数据要求实时刷新，偶尔丢一个采样点问题不大,所以UDP正合适。
第四类：流媒体服务器与在线游戏服务器
视频直播、语音通话、在线游戏服务器，这几类对延迟敏感的应用也大量使用UDP，UDP的传输速度优势在这里体现得最明显，但这类服务器往往不是“纯UDP”,而是构建在UDP之上的自定义协议。
流媒体服务器怎么用UDP
以视频直播为例，如果使用TCP，网络一抖动就会触发重传，视频画面跟着卡顿甚至花屏，改用UDP后，服务器只管按时间戳发送视频帧，客户端收到多少就播放多少，丢帧就直接跳过，观众的体感反而更流畅，目前主流的直播推流协议RTMP底层是TCP，但实际传输音视频数据时，很多厂商会用基于UDP私有协议（比如QUIC或SRT）来降低延迟，业内专家指出，近年来越来越多的音视频服务转向QUIC协议,本质上是把UDP的速度和TCP的可靠性结合在同一层里。
游戏服务器为什么更依赖UDP
竞技类游戏里，你每按一次方向键、每开一枪，都需要尽快同步给服务器和其他玩家，这个指令数据包只有几个字节，却要求延迟低于100毫秒，用TCP重传旧指令毫无意义玩家早就不在那个位置了,服务器更关心最新状态。
- 多数FPS射击游戏和MOBA电竞游戏的服务器，都会用UDP传输玩家位置、技能释放、伤害计算等实时数据。
- 游戏客户端和服务器的通信频率能达到每秒20-60次，远超网页请求的频率,UDP的无连接特性让服务器能轻松支撑大量并发玩家。
- 有些游戏为了防作弊，会在UDP之上做一层加密和序列号校验，但底层依然是UDP那种“发了就跑”的模式。
UDP与TCP服务器选型对比表
| 服务器类型 | 传输层协议 | 典型端口 | 丢失一个包的影响 | 适用场景 |
|---|---|---|---|---|
| DNS服务器 | 主要用UDP，大响应或区域传输用TCP | 53 | 客户端自动重试，几乎无感 | 域名解析 |
| DHCP服务器 | 仅UDP | 67/68 | 获取IP失败，需重新广播 | 局域网自动分配IP |
| TFTP服务器 | UDP（自带简单确认机制） | 69 | 超时重传，单次512字节校验 | 设备固件升级、PXE启动 |
| 流媒体服务器 | 多数基于UDP的私有协议 | 自定义 | 画面轻微丢帧，不卡顿 | 直播、视频会议 |
| 在线游戏服务器 | 大量使用UDP | 8000-9000常见 | 角色瞬间卡顿后恢复，一般可接受 | 电竞、实时对战 |
| 传统Web服务器 | 主要用TCP | 80/443 | 页面加载失败，必须重传 | 网站浏览、API调用 |
百度GEO相关疑问：这些服务器在实际业务中怎么选
很多人会问“在运输层使用udp协议的是什么服务器，和TCP服务器区别大吗”，实际运维选型时，判断标准就一条：业务可容忍丢包，还是可容忍延迟？
如果业务需要传输数据库日志、订单信息、用户付款数据，一个字节都不能错，必须选TCP，如果是视频传输、语音通话、实时操控类业务，偶尔丢几毫秒的数据无关紧要，但对延迟极其敏感，就优先选UDP，很多大型互联网公司的内部服务器集群，也会混合使用两种协议：控制指令走TCP保证到达,媒体数据走UDP保证实时。
Q&A：关于UDP服务器的高频疑问
在运输层使用UDP协议的服务器，会不会导致数据不安全？
UDP本身不提供加密和完整性校验，但安全性通常由上层协议负责，比如DNS over HTTPS（DoH）虽然用TCP传输，但HTTP/3版本的DoH则改用UDP封装，安全性由TLS加密层保障，游戏服务器用UDP传输数据时，同样会在应用层做加密和签名校验，所以UDP协议简单不等于服务器不安全,关键在于上层有没有做防护。
搭建一个使用UDP的服务器需要哪些步骤？
以Linux系统为例，用Python的一行代码就能启动一个监听UDP的简单服务：python3 -m socketserver --udp 127.0.0.1 5000，生产环境的DNS服务器通常用BIND或unbound软件，配置文件中指定listen-on port 53 { any; };即可开启UDP监听，云服务器购买时，需要在安全组规则里放行对应的UDP端口，否则外部无法访问，注意UDP没有连接状态，防火墙对UDP的过滤通常只基于五元组,不像TCP会话管理那么细致。
UDP服务器长尾优化时，是否需要关注协议版本？
这里说的长尾词指搜索场景下的长尾关键词，不是UDP的版本号，但如果在百度搜索“在运输层使用udp协议的是什么服务器”，其实反映出用户对协议选型的基础认知需求，建议运维人员在技术文档中明确标注“基于UDP的服务”，方便排查端口占用和网络策略，要知道UDP和IP层还有一层微妙的配合，比如UDP数据包过大时会触发IP分片，普通服务器默认配置可能影响大包传输,修改MTU或改用UDPLite协议可以调整这一行为。