TCP和UDP服务用在哪些服务器上，有哪些区别？

TCP和UDP服务于完全不同的服务器场景：所有要求数据完整到达的服务器，比如网页服务器、数据库服务器、邮件服务器和文件传输服务器，都必须依赖TCP；而所有追求实时速度、允许少量丢包的服务器，比如DNS服务器、视频直播服务器、在线游戏服务器和语音通话服务器，则主要靠UDP扛起流量。

这两兄弟的职责划分,说白了就是“可靠”与“快”的取舍，搞懂它们各自服务于哪些服务器，不仅能帮你看懂网络拓扑图，在你租用服务器、配置防火墙、优化业务时也会少走很多弯路，下面就从协议本身开始讲起。

加载中

一条视频讲清楚TCP协议与UDP协议-什么是三次握手与四次挥手

掌芝士zzs

65.8万2.2万821

原视频地址

tcp和udp的区别是什么

很多人背过八股文,说TCP是面向连接的、UDP是无连接的，但落到服务器上，区别远比这句话要实在。

一个把数据当快递签收，一个把数据当广播喊话

TCP的做事风格像快递员,发货前先打电话确认你在家，送完还得让你签字，丢了就重新送，它通过三次握手建立连接，传输过程中带确认机制和重传机制，数据发出去必须等对方回“收到”，没回就重发，这种笨办法保证了数据分毫不差，代价是每一次往返都要消耗额外的时间。

UDP则完全相反,它像广场上的大喇叭，喊完就完事，不管有没有人听见，没有握手、没有确认、没有重传，数据包一股脑往外扔，接收方收到多少算多少，收不到就算了，这种省事的策略换来的是极低的延迟和极高的吞吐，适合那些“画面卡一下可以忍，但绝不能让声音慢半拍”的业务。

用一张表看明白核心差异

这张表是判断“tcp和udp服务于哪些服务器”的总地图，下面具体拆开讲。

网页服务器和数据库服务器，用tcp还是udp

直接给答案：必须用TCP，这类服务器对数据的完整性要求是零妥协的。

网页服务器和HTTP协议：TCP是唯一答案

你访问任何一个网站,浏览器向服务器发起请求，走的是HTTP协议，而HTTP协议的底层就是TCP，为什么？因为网页文件不能丢，假设你在看一篇技术文档，图片加载到一半丢了，或者代码块少了几行，这页面就没法用了，TCP的重传机制保证了网页的每一个字节都完整到达。

用操作系统的视角来看,你在服务器上执行

netstat -anp | grep :80，看到的连接状态基本都是 ESTABLISHED 和 TIME_WAIT，这就是TCP连接的特征，如果你看服务器的80端口用的是UDP协议的监听，那多半是配置出错了，或者是被某种UDP-based HTTP代理工具（比如QUIC的早期形态）所服务，但传统意义上的网页服务器，比如Nginx和Apache，对外提供HTTP服务时监听的都是TCP端口，即使今天HTTP/3换用了基于UDP的QUIC协议，底层逻辑也做了一层类似TCP的可靠性封装，并不是裸用UDP。

数据库服务器靠TCP保证查询不“缺胳膊少腿”

MySQL、PostgreSQL、Oracle等主流数据库，客户端连接服务器时使用的都是TCP协议，一条SQL查询语句，从客户端发往数据库服务器，返回的结果集可能包含成千上万行数据，中间任何一行丢了，整个查询结果就是错误的，数据库服务器必须等所有数据包聚齐、排序正确，才把结果交给应用程序。

更关键的是,数据库的事务机制（ACID）依赖底层传输的绝对可靠，如果一个事务提交成功后，其中某条记录在传输过程中丢失，那整个数据库的一致性就崩溃了，业内专家指出，绝大多数生产事故都发生在应用层，但底层协议若用UDP裸奔，事故率会呈指数级上升，所以在服务器选型时，凡是挂着数据库服务的机器，防火墙策略上一定要确保TCP端口对客户端开放。

邮件服务器、文件传输服务器的共同点

• 邮件服务器（SMTP/POP3/IMAP协议）：邮件内容包含正文和附件，少一个字节文件就损坏了，用TCP是基础操作。
• 文件传输服务器（FTP/SFTP协议）：大文件切片传输，依赖TCP的排序和重传能力，保证文件合并后哈希值一致。
• 远程管理服务器（SSH/RDP协议）：远程登录操作，敲错的命令不能因为丢包而消失，必须可靠传输。

这些服务器的共同点在于：业务允许有几百毫秒的延迟，但不允许一个字节的误差，TCP的拥塞控制机制虽然在网络拥堵时会主动降低速度，但对于上述业务来说，慢一点可以接受，错一点都不行。

哪些服务器更依赖udp传输

另一类服务器恰好相反,它们宁可错，不可等，这类业务的核心诉求是把延迟压到最低，至于偶尔丢几个包，通过业务层的容错机制就能弥补。

DNS服务器：UDP扛起了整个互联网的寻址体系

当你在浏览器里输入一个域名,系统发起的第一次DNS查询走的就是UDP的53端口，为什么不用TCP？因为DNS查询的报文通常只有几十个字节，如果用TCP先建立连接再查询，光握手就要消耗一个RTT（往返时间），对于每次上网都要做无数次DNS解析的场景来说，延迟累积起来是巨大的。

UDP的“发出去就不管”特性正好匹配DNS查询的两大特点：一次请求一次响应

，数据量极小，响应内容就放在一个数据包里，如果这个数据包丢了，客户端会自己超时重试，业内测试数据显示，DNS查询走TCP的场景只占很小比例，主要出现在区域性传输或响应数据超出512字节的扩展场景（DNS over TCP），但日常的递归查询和迭代查询，几乎全部跑在UDP上。

视频直播服务器和语音通话服务器：UDP是保命符

看直播的时候,画面偶尔花屏一下，过一两秒就恢复了，这是UDP数据包丢失后的自然现象，如果你用TCP看直播，一旦丢包，TCP就会重传，重传的数据到达时直播画面已经往前走了好几秒，造成画面卡顿和积压，体验更差。

在线视频会议、语音通话同理，WebRTC（网页实时通信）技术栈底层核心就是UDP协议，配合SRTP加密和FEC前向纠错，在丢包率不超过一定范围内时，通过冗余数据包直接恢复丢失的信息，完全不需要重传等待，语音通话中如果某个音频包丢了，几十毫秒的静音人耳几乎感知不到，但如果是几百毫秒的延迟，那对话就完全没法进行了。

在线游戏服务器：UDP扛起实时同步

FPS射击游戏、MOBA对战类游戏，玩家角色的移动坐标、攻击判定、技能释放这些高频操作信息，靠的全是UDP，一个位置数据包丢了，服务器会用下一个到达的包做插值修正，对玩家来说只是角色稍微瞬移了一点，远比卡顿半秒再恢复要舒服得多。

游戏服务器用tcp还是udp：真实场景里的混合架构

如果你认为游戏服务器只用了UDP,那就太天真了，现实中，绝大多数商业游戏服务器是TCP和UDP混合部署的。

• 登录模块用TCP：账号密码、角色信息、物品数据必须绝对可靠，走HTTP或私有TCP协议。
• 房间模块用TCP：玩家进入房间、加载地图、同步玩家基础信息，这部分数据量大但频率低，必须完整无损。
• 战斗模块用UDP：实时移动、技能释放、伤害数值，高频小数据包，走UDP尽力传输。

以一款典型的多人对战游戏为例,客户端向游戏服务器发送的移动指令走UDP，每秒发送20-30个数据包；而玩家购买道具、升级皮肤这类操作走TCP，确保扣费和到账不出现差错，所以当你问“游戏服务器用tcp还是udp”，正确答案是：看业务层次，实时交互用UDP，数据安全用TCP。

服务器选型时怎么判断用tcp或udp

在实际操作中,你不用从零开始决定用哪个协议，因为大部分业务已经被协议栈定型了。

第一招：看端口号识别协议归属

在Linux服务器上直接执行 cat /etc/services | grep -E '^http|^domain|^mysql|^ssh'，可以看到端口与协议的对应关系，服务商提供的文档里也都会标注端口属于TCP还是UDP：

• TCP 21/22/25/80/443/3306/6379：文件传输、远程管理、邮件、HTTP、HTTPS、MySQL、Redis。



• UDP 53/123/161/514/8000-9000：DNS、NTP时间同步、SNMP网管、Syslog日志、部分游戏或语音服务的自定义端口。

第二招：按业务容忍度倒推

• 业务能否容忍0.1%的丢包？不能，就选TCP。
• 业务对延迟的敏感度是否高于对完整性的要求？是，就选UDP。
• 业务处于内网环境且丢包率极低？可以优先用UDP换吞吐，但需要业务层处理乱序与重放。

第三招：考虑地域和网络链路质量

这是很多人忽略的一点,如果你的服务器面向国内用户，跨运营商访问（比如电信用户访问联通机房的服务器）时，TCP在丢包环境下的重传会造成明显的卡顿，此时考虑把核心业务拆到多地域部署，用智能DNS分流，如果你租用的是香港服务器或海外服务器，对国内用户的TCP连接延迟天然偏高，业务上就要尽可能减少TCP的往返次数，或者基于UDP自研可靠传输协议（比如类QUIC方案），服务器租用价格上，TCP和UDP本身没有区别，带宽计费方式才是主要成本变量。

Q&A：tcp和udp服务于哪些服务器的常见疑问

问：TCP比UDP慢，那所有追求速度的服务器都可以换成UDP吗？

不可以,TCP的“慢”是相对于UDP的无状态发送而言的，但它的慢主要在网络链路不稳定的场景下显现，如果是同机房内网通信，TCP的吞吐可以跑满万兆网卡，速度并不差，UDP虽快，但丢包后不会自动恢复，业务层必须自己处理丢包、乱序和重复包，很多基于UDP二次封装的自研协议（如KCP），本质是用应用层代码还原了TCP的可靠性逻辑，工程复杂度远高于直接用TCP，绝大多数业务场景，默认选TCP就是正确的。

问：为什么DNS服务器用UDP，但很少听说DNS解析出错？

DNS查询通常由操作系统或本地DNS缓存服务器发起,查询失败后会切换到TCP重试，或者由客户端重新请求，这是一种折中策略：正常情况下用UDP的快速响应保证体验，异常情况下用TCP的可靠性兜底，DNS服务器本身有超时重传机制和自己独立的序号字段，同一个查询请求可以重复发出，最终拿到响应即可，UDP的不可靠性是可控的，因为DNS协议设计之初就考虑到了这一点。

问：实际部署服务器时，防火墙或安全组策略需要同时放行TCP和UDP吗？

需要看具体服务,同一个端口号可以同时存在TCP和UDP两种服务，但绝大多数应用程序只监听其中一种，放行策略建议按最小权限原则执行：HTTP只放行TCP 80/443，DNS只放行UDP 53，游戏服务器的自定义端口需要向服务商确认是TCP、UDP还是两者兼顾，错误地同时放行所有端口会增加安全风险，不放行会用不了服务。

TCP和UDP的选型,始终围绕一条原则：数据完整性优先就选TCP，时效性优先就选UDP，搞清楚了这条底线，再去审视你手头的服务器，每个端口该开哪个协议，自然一目了然。