为什么这么设计（Why’s THE Design）是一系列关于打算机领域中程序设计决策的文章，我们在这个系列的每一篇文章中都会提出一个详细的问题并从不同的角度谈论这种设计的优缺陷、对详细实现造成的影响。如果你有想要理解的问题，可以在文章下面留言。
本日要剖析的详细问题是『为什么 DNS 利用 UDP 协议』，DNS 作为全体互联网的电话簿，它能够将可以被人理解的域名翻译成可以被机器理解的 IP 地址，使得互联网的利用者不再须要直接打仗很难阅读和理解的 IP 地址。作者曾经在 详解 DNS 与 CoreDNS 的实现事理 一文中先容过 DNS 的实现事理，这篇文章中就不会先容 DNS 的实现事理了，感兴趣的读者可以看一下。
相信 DNS 利用 UDP 协议已经成为了软件工程师的知识，对打算机网络稍有理解的人都知道 DNS 会利用 UDP 协议传输数据，但是这一不雅观点实在不是完备精确的，我们在这里就会详细剖析『为什么 DNS 会利用 UDP 传输数据』以及『为什么 DNS 不止会利用 UDP 传输数据』两个问题，希望能够帮助各位读者理解 DNS 协议的全貌。
我们将要谈论的两个问题实在并不冲突，在绝大多数情形下，DNS 都是利用 UDP 协议进行通信的，DNS 协议在设计之初也推举我们在进行域名解析时首先利用 UDP，这确实能办理很多需求，但是不能办理全部的问题。
实际上，DNS 不仅利用了 UDP 协议，也利用了 TCP 协议，不过在详细先容本日的问题之前，我们还是要对 DNS 协议进行大略的先容：DNS 查询的类型不止包含 A 记录、CNAME 记录等常见查询，还包含 AXFR 类型的分外查询，这种分外查询紧张用于 DNS 区域传输，它的浸染便是在多个命名做事器之间快速迁移记录，由于查询返回的相应比较大，以是会利用 TCP 协议来传输数据包。
作为被广泛利用的协议，我们能够找到非常多 DNS 干系的 RFC 文档，DNS Camel Viewer 中列出了将近 300 个与 DNS 协议干系的 RFC 文档，个中有 6 个是目前的互联网标准，有 102 个是 DNS 干系的提案，这些文档共同构成了我们目前对付 DNS 协议的设计理解，作者也没有办法去逐一阅读个中的内容，只选择了个中一些主要的文档帮我们理解 DNS 的发展史以及它与 UDP/TCP 协议的关系，这里只会摘抄文档中与 UDP/TCP 协议干系的内容：
RFC1034 · Domain Names - Concepts and Facilities Internet Standard, 1987-11DNS 查询可以通过 UDP 数据包或者 TCP 连接进行传输；由于 DNS 区域传输的功能对付数据的准确有着较强的需求，以是我们必须利用 TCP 或者其他的可靠协议来处理 AXFR 类型的要求；2.RFC1035 · Domain Names - Implementation and Specification互联网支持命名做事器通过 TCP 或者 UDP 协议进行访问；
UDP 协议携带的不应该超过 512 字节，超过的会被截断并设置 DNS 协议的 TC 位，UDP 协议对付区域传输功能是不可接管的，不过是互联网上标准查询的推举协议。通过 UDP 协议发送的查询可能会丢失，以是须要重传策略办理这个问题；3.RFC1123 · Requirements for Internet Hosts – Application and SupportInternet Standard, 1989-10
未来定义的新 DNS 记录类型可能会包含超过 512 字节的信息，以是我们该当利用 TCP 协议来传输 DNS 记录；因此解析器和命名做事须要利用 TCP 协议作为 UDP 无法知足需求时的备份；DNS 解析器和递归做事器必须支持 UDP 协议，并且该当支持利用 TCP 协议发送非区域传输的查询；也便是说，DNS 解析器或者做事器在发送非区域传输查询时，必须先发送一个 UDP 查询，如果该查询的相应被截断，它该当考试测验利用 TCP 协议重新要求；4.RFC3596 · DNS Extensions to Support IP Version 6 Internet Standard, 2003-10
通过 DNS 扩展支持 IPv6 协议，每个 IPv6 占 16 个字节是 IPv4 的四倍；5.RFC5011 · Automated Updates of DNS Security (DNSSEC) Trust AnchorsIndependent, 2007-10
新增多种资源记录为 DNS 客户真个 DNS 数据来源进行认证，记录包含的数据每每较大；6.RFC6376 · DomainKeys Identified Mail (DKIM) Signatures Internet Standard, 2011-09
选择得当的键大小进行加密是须要在本钱、性能和风险之间的权衡，然而大的键（4096-bit）可能没有办法直接放到 DNS UDP 相应包中直接返回；7.RFC6891 · Extension Mechanisms for DNS (EDNS(0)) Internet Standard, 2013-04
利用 UDP 进行传输的 DNS 查询和相应最大不能超过 512 字节，不能支持大量 IPv6 地址或者 DNS 安全署名等记录的传输；EDNS 为 DNS 供应了扩展功能，让 DNS 通过 UDP 协议携带最多 4096 字节的数据；8.RFC7766 · DNS Transport over TCP - Implementation RequirementsProposed Standard, 2016-03
当客户端吸收到一个被阶段的 DNS 相应时，该当通过 TC 字段判断是否须要通过 TCP 协议重复发出 DNS 查询要求；DNSSEC 的引入使得截断的 UDP 数据包变得非常常见；利用 UDP 传输 DNS 的数据包大小超过最大传输单元（MTU）时可能会导致 IP 数据包的分片，RFC1123 文档中预测的未来已经到来了，唯一一个用于增加 UDP 能够携带数据包大小的 EDNS 机制被认为不足可靠；所有通用 DNS 实现必须要同时支持 UDP 和 TCP 传输协议，个中包括威信做事器、递归做事器以及桩解析器；桩解析器和递归解析器可以根据情形选择利用 TCP 或者 UDP 查询直接要求目标做事器，以 UDP 协议来开始发起 DNS 要求不再是逼迫性的，TCP 协议与 UDP 协议在 DNS 查询中可以相互替代，而不是作为重试机制；9.Specification for DNS over Transport Layer Security (TLS) Proposed Standard, 2016-05
在 DNS 协议中引入 TLS 来为用户供应隐私，减少对 DNS 查询的窃听和修改，但是 TLS 协议的引入会带来一些性能方面的额外开销；10.RFC8484 · DNS Queries over HTTPS (DoH) Proposed Standard, 2018-10
定义了一种通过 HTTPS 发送 DNS 查询和获取 DNS 相应的协议；我们可以大略总结一下 DNS 的发展史，1987 年的 RFC1034 和 RFC1035 定义了最初版本的 DNS 协议，刚被设计出来的 DNS 就会同时利用 UDP 和 TCP 协议，对付绝大多数的 DNS 查询来说都会利用 UDP 数据报进行传输，TCP 协议只会在区域传输的场景中利用，个中 UDP 数据包只会传输最大 512 字节的数据，多余的会被截断；两年后发布的 RFC1123 预测了 DNS 记录中存储的数据会越来越多，同时也第一次显示的指出了创造 UDP 包被截断时该当通过 TCP 协议重试。
过了将近 20 年的韶光，由于互联网的发展，人们创造 IPv4 已经不足分配了，以是引入了更长的 IPv6，DNS 也在 2003 年发布的 RFC3596 中进行了协议上的支持；随后发布的 RFC5011 和 RFC6376 增加了在鉴权和安全方面的支持，但是也带来了巨大的 DNS 记录，UDP 数据包被截断变得非常常见。
RFC6891 供应的 DNS 扩展机制能够帮助我们在一定程度上办理大数据包被截断的问题，减少了利用 TCP 协议进行重试的须要，但是由于最大传输单元的限定，这并不能办理所有问题。
DNS 涌现之后的 30 多年，RFC7766 才终于提出了利用 TCP 协议作为紧张协议来办理 UDP 无法办理的问题，TCP 协议也不再只是一种重试时利用的机制，随后涌现的 DNS over TLS 和 DNS over HTTP 也都是对 DNS 协议的一种补充。
从这段发展时来看，DNS 并不但是利用 UDP 数据包进行通信，在 DNS 的标准中就一贯能看到 TCP 协议的身影，我们在本日也是想要站在历史的角度上剖析 ——『为什么 DNS 查询选择利用 UDP/TCP 协议』。
设计在这一节中，我们将根据 DNS 利用协议的不同，分两个部分先容 UDP 和 TCP 两种不同的协议在支持 DNS 查询和相应时有哪些优点和缺陷，在剖析的过程中我们也会结合历史上的高下文，还原做出设计决策时的场景。
UDPUDP 协议在过去的几十年中实在都是 DNS 紧张利用的协议，作为互联网的标准，目前的绝大多数 DNS 要乞降相应都会利用 UDP 协议进行数据的传输，我们通过抓包工具就能轻松得到以 UDP 协议为载体的 DNS 要乞降相应。
DNS 要求的数据都会以二进制的形式封装成如下的所示的 UDP 数据包中，下面便是一个调用 DNS 做事器获取 www.baidu.com 域名 IP 地址的要求，从第四行的 05 字节开始到末了便是 DNS 要求的内容，全体数据包中除了 DNS 协议干系的内容之外，还包含以太网、IP 和 UDP 的协议头：
0000 b0 6e bf 6a 4c 40 38 f9 d3 ce 10 a6 08 00 45 00 .n.jL@8.......E.
0010 00 3b 97 ae 00 00 40 11 0b 0a c0 a8 32 6d 72 72 .;....@.....2mrr
0020 72 72 f3 27 00 35 00 27 6b ee 0c 5a 01 00 00 01 rr.'.5.'k..Z....
0030 00 00 00 00 00 00 03 77 77 77→05 62 61 69 64 75 .......www.baidu
0040 03 63 6f 6d 00 00 01 00 01 .com.....
虽然每一个 UDP 数据包中都包含了很多以太网、IP、UDP 以及 DNS 协议的干系内容，但是上面的 DNS 要求大小只有 73 个字节，上述 DNS 要求的相应也只有 132 个字节，这对付本日其他的常见要求来讲都是非常小的数据包：
0000 38 f9 d3 ce 10 a6 b0 6e bf 6a 4c 40 08 00 45 00 8......n.jL@..E.
0010 00 76 00 00 00 00 96 11 4c 7d 72 72 72 72 c0 a8 .v......L}rrrr..
0020 32 6d 00 35 f3 27 00 62 5b c2 0c 5a 81 80 00 01 2m.5.'.b[..Z....
0030 00 03 00 00 00 00 03 77 77 77 05 62 61 69 64 75 .......www.baidu
0040 03 63 6f 6d 00 00 01 00 01 c0 0c 00 05 00 01 00 .com............
0050 00 02 cb 00 0f 03 77 77 77 01 61 06 73 68 69 66 ......www.a.shif
0060 65 6e c0 16 c0 2b 00 01 00 01 00 00 01 18 00 04 en...+..........
0070 3d 87 a9 7d c0 2b 00 01 00 01 00 00 01 18 00 04 =..}.+..........
0080 3d 87 a9 79 =..y
UDP 和 TCP 的通信机制非常不同，作为可靠的传输协议，TCP 协议须要通信的双方通过 三次握手 建立 TCP 连接后才可以通信，但是在 30 年前的 DNS 查询的场景中我们实在并不须要稳定的连接（或者以为不须要），每一次 DNS 查询都会直接向命名做事器发送 UDP 数据报，与此同时常见 DNS 查询的数据包都非常小，TCP 建立连接会带来以下的额外开销：
TCP 建立连接须要进行三次网络通信；TCP 建立连接须要传输 ~130 字节的数据；TCP 销毁连接须要进行四次网络通信；TCP 销毁连接须要传输 ~160 字节的数据；假设网络通信所花费的韶光是可以忽略的不计的，如果我们只考虑 TCP 建立连接时传输的数据的话，可以大略来算一笔账：
利用 TCP 协（共 330 字节）三次握手 — 14x3(Ethernet) + 20x3(IP) + 44 + 44 + 32 字节查询协议头 — 14(Ethernet) + 20(IP) + 20(TCP) 字节相应协议头 — 14(Ethernet) + 20(IP) + 20(TCP) 字节利用 UDP 协议（共 84 字节）查询协议头 — 14(Ethernet) + 20(IP) + 8(UDP) 字节相应协议头 — 14(Ethernet) + 20(IP) + 8(UDP) 字节须要把稳的是，我们在这里打算结果的条件是 DNS 解析器只须要与一个命名做事器或者威信做事器进行通信就可以得到 DNS 相应，但是在实际场景中，DNS 解析器可能会递归地与多个命名做事器进行通信，这也更加地放大了 TCP 协议在额外开销上的劣势。
如果 DNS 查询的要求体和相应分别是 15 和 70 字节，那么 TCP 比较于 UDP 协议会增加 ~250 字节和 ~145% 的额外开销，以是当要求体和相应的大小比较小时，通过 TCP 协议进行传输不仅须要传输更多的数据，还会花费更多的资源，多次通信以及信息传输带来的韶光本钱在 DNS 查询较小时是无法被忽略的，TCP 连接带来的可靠性在 DNS 的场景中没能发挥太大的浸染。
TCP本日的网络状况实在没有几十年前设计的那么大略，我们不仅碰着了 IPv4 即将无法分配的状况，而且还须要引入 DNSSEC 等机制来担保 DNS 查询和要求的完全性以及传输安全，总而言之，DNS 协议须要处理的数据包越来越大、数据也越来越多，但是『为什么当须要传输的数据较多时我们就必须利用 TCP 协议呢？』，如果连续利用 UDP 协议就不能完成 DNS 解析么。
从理论上来说，一个 UDP 数据包的大小最多可以达到 64KB，这对付一个常见的 DNS 查询实在是一个非常大的数值；但是在实际生产中，一旦数据包中的数据超过了传送链路的最大传输单元（MTU，也便是单个数据包大小的上限，一样平常为 1500 字节），当前数据包就可能会被分片传输、丢弃，部分的网络设备乃至会直接谢绝处理包含 EDNS(0) 选项的要求，这就会导致利用 UDP 协议的 DNS 不稳定。
TCP 作为可靠的传输协议，可以非常好的办理这个问题，通过序列号、重传等机制能够担保的不重不漏，接管方的 TCP 栈会对分片的数据重新进行拼装，DNS 等运用层协议可以直策应用场置好的完全数据。同时，当数据包足够大的时候，TCP 三次握手带来的额外开销比例就会越来越小，与全体包的大小比较就会趋近于 0：
当 DNS 数据包大小为 500 字节时，TCP 协议的额外开销为 ~41.2%；当 DNS 数据包大小为 1100 字节时，TCP 协议的额外开销为 ~20.7%；当 DNS 数据包大小为 2300 字节时，TCP 协议的额外开销为 ~10.3%；当 DNS 数据包大小为 4800 字节时，TCP 协议的额外开销为 ~5.0%；以是，我们在 DNS 中存储较多的内容时，TCP 三次握手以及协议头带来的额外开销就不是关键成分了，不过我们 TCP 三次握手带来的三次网络传输耗时还是没有办法避免的，这也是我们在目前的场景下不得不接管的问题。
总结很多人认为 DNS 利用了 UDP 协议来获取域名对应的 IP 地址，这个不雅观点虽然没错，但是还是有一些片面，更加准确的说法实在是 DNS 查询在刚设计时紧张利用 UDP 协议进行通信，而 TCP 协议也是在 DNS 的演进和发展中被加入到规范的：
DNS 在设计之初就在区域传输中引入了 TCP 协议，在查询中利用 UDP 协议；当 DNS 超过了 512 字节的限定，我们第一次在 DNS 协议中明确了『当 DNS 查询被截断时，该当利用 TCP 协议进行重试』这一规范；随后引入的 EDNS 机制许可我们利用 UDP 最多传输 4096 字节的数据，但是由于 MTU 的限定导致的数据分片以及丢失，使得这一特性不足可靠；在最近的几年，我们重新规定了 DNS 该当同时支持 UDP 和 TCP 协议，TCP 协议也不再只是重试时的选择；这篇文章已经详细先容了 DNS 的历史以及选择不同协议时考虑的关键点，在这里我们重新回顾一下 DNS 查询选择 UDP 或者 TCP 两种不同协议时的紧张缘故原由：
UDP 协议DNS 查询的数据包较小、机制大略；UDP 协议的额外开销小、有着更好的性能表现；TCP 协议DNS 查询由于 DNSSEC 和 IPv6 的引入迅速膨胀，导致 DNS 相应常常超过 MTU 造成数据的分片和丢失，我们须要依赖更加可靠的 TCP 协议完成数据的传输；随着 DNS 查询中包含的数据不断增加，TCP 协议头以及三次握手带来的额外开销比例逐渐降落，不再是霸占总传输数据大小的紧张部分；无论是选择 UDP 还是 TCP，最核心的抵牾就在于须要传输的数据包大小，如果数据包小到一定程度，UDP 协议绝对最佳的选择，但是当数据包逐渐增大直到打破 512 字节以及 MTU 1500 字节的限定时，我们也只能选择利用更可靠的 TCP 协议来传输 DNS 查询和相应。到末了，我们还是来看一些比较开放的干系问题，有兴趣的读者可以仔细思考一下下面的问题：
如何对利用 TCP 协议的 DNS 进行一些优化，减少一些额外开销？我们现在已经可以利用 UDP/TCP/TLS/HTTPS 四种办法传输 DNS 数据，这些办法有什么异同？是否还可以通过其他的协议实现 DNS 查询？如果对文章中的内容有疑问或者想要理解更多软件工程上一些设计决策背后的缘故原由，可以在博客下面留言，作者会及时回答本文干系的疑问并选择个中得当的主题作为后续的内容。
如果对本文 为什么 DNS 利用 UDP 协议 · Why's THE Design? 的内容有疑问，请不才面的评论系统中留言，感激。
原文链接：为什么 DNS 利用 UDP 协议 · Why's THE Design? · 面向崇奉编程
Follow: Draveness · GitHub
