为什么 DNS 协议使用 UDP？只使用了 UDP 吗？

尽人事，听天命。博主东南大学硕士在读，携程 Java 后台开发暑期实习生，热爱健身和篮球，乐于分享技术相关的所见所得，关注公众号 @ 飞天小牛肉，第一时间获取文章更新，成长的路上我们一起进步

本文已收录于 「CS-Wiki」Gitee 官方推荐项目，现已累计 1.6k+ star，致力打造完善的后端知识体系，在技术的路上少走弯路，欢迎各位小伙伴前来交流学习

如果各位小伙伴春招秋招没有拿得出手的项目的话，可以参考我写的一个项目「开源社区系统 Echo」Gitee 官方推荐项目，目前已累计 700+ star，基于 SpringBoot + MyBatis + MySQL + Redis + Kafka + Elasticsearch + Spring Security + ... 并提供详细的开发文档和配套教程。公众号后台回复 Echo 可以获取配套教程，目前尚在更新中

---

为什么 DNS 协议使用 UDP 呢？这个问题可能大部分同学在各种博客或者面试过程中都或多或少遇见过，张口就来，UDP 快啊，DNS 使用 UDP 使得打开网页速度更快。

那各位有没有想过，既然 UDP 更快，为什么 HTTP 不使用 UDP 呢？

另外，为什么 DNS 协议使用 UDP 这个问题本身其实并不完全正确，DNS 并非只使用 UDP 协议，它同时占用了 UDP 和 TCP 的 53 端口，作为单个应用层的协议，DNS 同时使用两种传输协议也属实是个另类了。

DNS 为什么同时使用 TCP 和 UDP

我们从 TCP 与 UDP 的比较说起，老生常谈的话题，不过相信大部分同学都会忽略掉一个点，等下会指出来。

OK，轻松环节，闭着眼睛背：

1）TCP 需要三次握手建立连接，四次挥手释放连接；UDP 不需要，面向无连接

2）TCP 首部需要 20 个字节；而 UDP 首部只有 8 个字节

3）TCP 具有一系列保证可靠传输的机制；而 UDP 尽最大努力交付，不提供可靠传输的机制，如果在数据传输的过程中出现部分数据的丢失，UDP 协议本身并不能做出任何检测或补救措施

4）正是由于 UDP 没有了可靠传输机制，所以速度远远快于 TCP，在某些情况下 UDP 是一种最有效的工作方式，一般用于即时通信，比如： 语音电话、 直播等等；而 TCP 一般用于文件传输、发送和接收邮件、远程登录等准确性要求比较高的场景

上面这些是最基本的吧。

接下来讲的这个点，也就是很多人容易忽略的点，和 DNS 为什么需要同时使用 UDP 和 TCP 这个问题息息相关：

• 那就是 TCP 是面向字节流的，而 UDP 是面向报文的

解释一下这句话，我们知道，TCP 具有序列号机制，发送方会把一个大的 HTTP 报文按序号分割成若干报文段并加上 TCP 首部，也就是封装成 TCP 报文段。那么接收方在收到这些 TCP 报文段后，就会按照序号以原来的顺序重组 HTTP 报文。这就是面向字节流的 TCP。

而所谓 UDP 面向报文，发送方的 UDP 对应用层交付下来的 HTTP 报文， 在添加 UDP 首部后也就是封装成 UDP 报文，就向下交付给网络层 IP 协议。不做任何的拆分与合并，主要就是因为 UDP 没有像 TCP 一样的序列号机制来标识报文，所以默认只有一个 UDP 报文。

UDP 这么做就会导致一个问题。

互联网上物理链路的最小传输单元 = 576 字节，为了在物理链路上顺利传输，UDP 报文不能超过 576 字节，为此，UDP 报文被限制在 512 字节以内。

而 DNS 由于大面积使用了 UDP，这样一旦 DNS 报文超过 512 字节，基于 UDP 的 DNS 报文就只有抛弃多出来的 64 字节，截短为 512 字节，那么用户得到的 DNS 报文就是不完整的。

如何解决这个问题呢？

没错，最简单的方式就是使用 TCP。尽管速度可能相之 UDP 较慢，但对于得到完整的 DNS 报文，速度慢一点也可以忍受。

DNS 分别在什么情况下使用 UDP 和 TCP

了解了 TCP 面向字节流而 UDP 面向报文的这个特性之后，在域名解析的时候，也就是客户端向 DNS 服务器查询域名获取 IP 地址的时候，DNS 协议关于 UDP 和 TCP 的选择通常可以分为以下两种情况：

1）若客户端事先知道 DNS 响应报文的长度会大于 512 字节，则应当直接使用 TCP 建立连接

2）若客户端事先不知道 DNS 响应报文的长度，一般会先使用 UDP 协议发送 DNS 查询报文，若 DNS 服务器发现 DNS 响应报文的长度大于 512 字节，则多出来的部分会被 UDP 抛弃（截断 TrunCation），那么服务器会把这个部分被抛弃的 DNS 报文首部中的 TC 标志位置为 1，以通知客户端该 DNS 报文已经被截断。客户端收到之后会重新发起一次 TCP 请求，从而使得它将来能够从 DNS 服务器收到完整的响应报文。

当然了，在域名解析的时候，一般返回的 DNS 响应报文都不会超过 512 字节，用 UDP 传输即可。事实上，很多 DNS 服务器进行配置的时候，也仅支持 UDP 查询包。

不过，DNS 不仅存在域名解析的过程，还有区域传输的过程，而在进行区域传输的时候 DNS 会强制使用 TCP 协议。

什么是区域传输？

这就不得不提一下主域名服务器和辅助域名服务器。

设置域名服务器时，服务器管理员可以选择将域名服务器指定为主服务器还是辅助服务器（也称为从服务器）。

主域名服务器负责维护一个区域的所有域名信息，是特定的所有信息的权威信息源，数据可以修改。主服务器直接从本地文件获取此信息。只能在主服务器上更改区域的 DNS 记录，然后主服务器才能更新辅助服务器。

当主域名服务器出现故障、关闭或负载过重时，辅助域名服务器作为主域名服务器的备份提供域名解析服务。辅助域名服务器中的区域文件中的数据是从主域名服务器中复制过来的，无法自行修改。

其实就是主从的概念，各位应该也都比较熟悉了。主域名服务器用来写，辅助域名服务器用来读，提供负载均衡的能力，缓解主域名服务器的压力。

那么所谓区域传输（zone transfer）呢，就是辅助域名服务器与主域名服务器通信，并同步数据信息的过程。

辅域名服务器会定时向主域名服务器进行查询以便了解数据是否有变动。如有变动，则会执行一次区域传输。区域传输使用 TCP 而不是 UDP，因为数据同步传送的数据量比一个 DNS 请求和响应报文的数据量要多得多。

文章开头提到的既然 UDP 更快，为什么 HTTP 不使用 UDP 呢？这个问题的答案也大抵如此。

由于互联网的不安全性，我们需要数字证书并携带数字签名来保证数据的安全性，为此，整个 HTTP 报文的大小已经远远超过 512 字节，无法使用 UDP 传输。

小结

综上，总结下，虽然 UDP 速度更快，DNS 协议也确实大面积使用了 UDP，但是由于 UDP 面向报文、只能传输小于 512 字节的特性，DNS 并非只使用了 UDP，具体的 TCP 和 UDP 使用场景如下：

• DNS 在域名解析的过程中，会根据 DNS 响应报文的大小选择使用 TCP 还是 UDP。但是一般情况下，返回的 DNS 响应报文都不会超过 512 字节，所以事实上，很多 DNS 服务器进行配置的时候，也仅支持 UDP 查询包；
• DNS 在进行区域传输的时候使用 TCP 协议。

关注公众号 | 飞天小牛肉，即时获取更新

• 博主东南大学硕士在读，携程 Java 后台开发暑期实习生，利用课余时间运营一个公众号『 飞天小牛肉 』，2020/12/29 日开通，专注分享计算机基础（数据结构 + 算法 + 计算机网络 + 数据库 + 操作系统 + Linux）、Java 技术栈等相关原创技术好文。本公众号的目的就是让大家可以快速掌握重点知识，有的放矢。希望大家多多支持哦，和小牛肉一起成长
• 并推荐个人维护的开源教程类项目： CS-Wiki（Gitee 推荐项目，现已累计 1.6k+ star）, 致力打造完善的后端知识体系，在技术的路上少走弯路，欢迎各位小伙伴前来交流学习 ~
• 如果各位小伙伴春招秋招没有拿得出手的项目的话，可以参考我写的一个项目「开源社区系统 Echo」Gitee 官方推荐项目，目前已累计 700+ star，基于 SpringBoot + MyBatis + MySQL + Redis + Kafka + Elasticsearch + Spring Security + ... 并提供详细的开发文档和配套教程。公众号后台回复 Echo 可以获取配套教程，目前尚在更新中。