DNS 协议是什么？完整查询过程？为什么选择使用 UDP 协议发起 DNS 查询？
共 5142字，需浏览 11分钟
·
2021-06-08 09:49
点击上方 三分钟学前端，关注公众号
回复交流，加入前端编程面试算法每日一题群
引言
你可能了解 DNS 协议是什么？那你了解 DNS 完整查询过程是什么吗？它底层是基于 TCP 还是 UDP 喃？TCP 与 UDP 又各自负责 DNS 的哪些部分喃？
本文就从以下几个方面循序渐进走进 DNS 协议、它的完整查询过程以及底层是基于 UDP 还是 TCP 实现？
DNS 协议是什么？ 域名结构 域名解析缓存优化 DNS 查询方式有哪些 DNS 完整查询过程 为什么选择基于 UDP 协议发起 DNS 查询，而不是 TCP？
DNS 协议是什么？
DNS（Domain Name System：域名系统），与 HTTP、FTP 和 SMTP 一样，DNS 协议也是应用层的协议，用于将用户提供的主机名（域名）解析为 IP 地址。
简单来说，DNS 就像是一个自动的电话号码簿，我们可以直接拨打 47.105.127.0 呼叫对方，但这不方便记录、记忆，DNS 提供一种手段能够让我们直接拨打对方的域名 www.pzijun.cn 找到对方
👆就是将域名 www.baidu.com 解析成 ip地址：1.1.1.1 ，思考一下🤔
DNS 如何根据域名解析成 IP 地址？
域名结构
DNS 的核心系统是一个三层的树状、分布式服务，基本对应域名的结构：
根域名服务器（Root DNS Server）：管理顶级域名服务器，返回“com”“net”“cn”等顶级域名服务器的 IP 地址 顶级域名服务器（Top-level DNS Server）：管理各自域名下的权威域名服务器，比如 com 顶级域名服务器可以返回 apple.com 域名服务器的 IP 地址 权威域名服务器（Authoritative DNS Server）：管理自己域名下主机的 IP 地址，比如 apple.com 权威域名服务器可以返回 www.pzijun.cn 的 IP 地址
有了👆这个系统后，任何域名都可以在上面这个结构中进行从上到下查询，例如，你要访问“www.pzijun.cn”，就要进行下面的三次查询：
访问根域名服务器，它会告诉你“cn”顶级域名服务器的地址； 访问“cn”顶级域名服务器，它再告诉你“pzijun.com”域名服务器的地址； 最后访问“pzijun.com”域名服务器，就得到了“www.pzijun.cn”的地址
但如果全世界的域名解析都往这个系统里挤，这个系统可能被挤瘫痪了，即使不瘫痪，解析速度也会大打折扣，所以 DNS 采取了一种非常有效的手段来解决这个问题： 缓存
域名缓存优化
域名缓存有以下两种方式：
非权威域名服务器（本地域名服务器）缓存 ：各大运营服务商或大公司都有自己的 DNS 服务器，一般部署在距离用户较近地方，代替用户用户访问核心 DNS 系统，可以缓存之前的查询结果，如果已经有了记录，就无需再向根服务器发起查询，直接返回对应的 IP 地址 本地计算机 DNS 记录缓存 ： 浏览器缓存 ：浏览器在获取某一网站域名的实际 IP 地址后，进行缓存，之后遇到同一域名查询之前的缓存结果即可，有效减少网络请求的损耗。每种浏览器都有一个固定的 DNS 缓存时间，如 Chrome 的过期时间是 1 分钟，在这个期限内不会重新请求 DNS 操作系统缓存 ：操作系统里有一个特殊的“主机映射”文件，通常是一个可编辑的文本，在 Linux 里是 /etc/hosts，在 Windows 里是C:\WINDOWS\system32\drivers\etc\hosts，如果操作系统在缓存里找不到 DNS 记录，就会找这个文件
DNS 查询方式
DNS 查询有两种方式：递归 和 迭代 。
一般来说，DNS 客户端设置使用的 DNS 服务器一般都是 递归服务器 ，它负责全权处理客户端的 DNS 查询请求，直到返回最终结果
而 DNS 根域名服务器之间一般采用 迭代查询 方式，以免根域名服务器的压力过大
递归查询
迭代查询
DNS 完整查询过程
将我们上面所说的域名服务器之间的 DNS 查询请求过程和域名缓存结合起来，完整查询过程👇：
首先搜索 浏览器的 DNS 缓存 ，缓存中维护一张域名与 IP 地址的对应表 如果没有命中😢，则继续搜索 操作系统的 DNS 缓存 如果依然没有命中🤦♀️，则操作系统将域名发送至 本地域名服务器 ，本地域名服务器查询自己的 DNS 缓存，查找成功则返回结果（注意：主机和本地域名服务器之间的查询方式是 递归查询 ） 若本地域名服务器的 DNS 缓存没有命中🤦，则本地域名服务器向上级域名服务器进行查询，通过以下方式进行 迭代查询 （注意：本地域名服务器和其他域名服务器之间的查询方式是迭代查询，防止根域名服务器压力过大）：
首先本地域名服务器向根域名服务器发起请求，根域名服务器是最高层次的，它并不会直接指明这个域名对应的 IP 地址，而是返回顶级域名服务器的地址，也就是说给本地域名服务器指明一条道路，让他去这里寻找答案 本地域名服务器拿到这个顶级域名服务器的地址后，就向其发起请求，获取权限域名服务器的地址 本地域名服务器根据权限域名服务器的地址向其发起请求，最终得到该域名对应的 IP 地址
本地域名服务器 将得到的 IP 地址返回给操作系统，同时自己将 IP 地址 缓存 起来📝 操作系统 将 IP 地址返回给浏览器，同时自己也将 IP 地址 缓存 起来📝 至此， 浏览器 就得到了域名对应的 IP 地址，并将 IP 地址 缓存 起来📝
这些远程查询都是基于UDP协议，通常使用 53 号端口。
为什么选择基于 UDP 协议发起 DNS 查询，而不是 TCP？
衡量计算机通信快慢的指标是 响应时间 ，即从用户发出通信指令（输入网址敲回车键）开始，到用户看到完整页面为止，所花费的时间。即：
响应时间 = DNS域名解析时间 + TCP 连接建立时间 + HTTP交易时间
其中，TCP 连接建立需要三次挥手，HTTP交易一来一回，都不可能减少（具体计算过程可见 说一下HTTP/3新特性，为什么选择使用UDP协议？ ），所以只能让DNS域名解析的时间越小越好
TCP
如果 DNS 查询继续采用 TCP 连接？TCP 作为可靠的传输协议，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) 字节
需要注意的是，我们在这里计算结果的前提是 DNS 解析器只需要与一个命名服务器或者权威服务器进行通信就可以获得 DNS 响应，但是在实际场景中，DNS 解析器可能会递归地与多个命名服务器进行通信，这也加倍地放大了 TCP 协议在额外开销上的劣势。
UDP
如果使用 UDP 协议（共 84 字节）
查询协议头 — 14(Ethernet) + 20(IP) + 8(UDP) 字节 响应协议头 — 14(Ethernet) + 20(IP) + 8(UDP) 字节
如果 DNS 查询的请求体和响应分别是 15 和 70 字节，那么 TCP 相比于 UDP 协议会增加 ~250 字节和 ~145% 的额外开销
所以当请求体和响应的大小比较小时，通过 TCP 协议进行传输不仅需要传输更多的数据，还会消耗更多的资源，多次通信以及信息传输带来的时间成本在 DNS 查询较小时是无法被忽视的，TCP 连接带来的可靠性在 DNS 的场景中没能发挥太大的作用。
UDP 传输的弱点
由于历史的原因，互联网上物理链路的最小 MTU = 576 ，基于 UDP 传输的 DNS 为了限制报文不超过 576 ，所以将 DNS 报文限制在 512 字节。
这样一旦 DNS 查询应答超过 512 字节，基于 UDP 的 DNS 就只有截短为 512 字节，那么用户得到的 DNS 应答就是不完整的。
为了克服这种困难，我们第一次在 DNS 协议中明确了 『当 DNS 查询被截断时，应该使用 TCP 协议进行重试』 这一规范。尽管交易时间可能比较长，但毕竟可以得到完整的答案，总比得到不完整的答案要好。
同时，当数据包足够大的时候，TCP 三次握手带来的额外开销比例就会越来越小，与整个包的大小相比就会趋近于 0：
RFC6891 中引入了 EDNS 机制，它允许我们使用 UDP 最多传输 4096 字节的数据，但是由于 MTU 的限制导致的传输数据分片以及丢失（在实际生产中，一旦数据包中的数据超过了传送链路的最大传输单元MTU，当前数据包就可能会被分片传输、丢弃），使得这一特性不够可靠；
总结
需要注意的是，DNS 使用了 UDP 协议来获取域名对应的 IP 地址，这个没错，但有些片面，准确的来说，DNS 查询在刚设计时主要使用 UDP 协议进行通信，而 TCP 协议也是在 DNS 的演进和发展中被加入到规范的：
DNS 在设计之初就在区域 传输中引入了 TCP 协议 ， 在查询中使用 UDP 协议 ，它同时占用了 UDP 和 TCP 的 53 端口 当 DNS 超过了 512 字节的限制，我们第一次在 DNS 协议中明确了 『当 DNS 查询被截断时，应该使用 TCP 协议进行重试』 这一规范； 随后引入的 EDNS 机制允许我们使用 UDP 最多传输 4096 字节的数据，但是由于 MTU 的限制导致的数据分片以及丢失，使得这一特性不够可靠； 在最近的几年，我们重新规定了 DNS 应该同时支持 UDP 和 TCP 协议，TCP 协议也不再只是重试时的选择；
参考地址
极客时间透视 HTTP 协议 超详细 DNS 协议解析：https://segmentfault.com/a/1190000039039275 为什么 DNS 使用 UDP 协议：https://draveness.me/whys-the-design-dns-udp-tcp/
你还有哪些补充吗？或对文中有任何异议，欢迎提交至 https://github.com/Advanced-Frontend/Daily-Interview-Question/issues/502 ，你的每一次反馈对我们都至关重要，感谢
如果感觉还不错，欢迎点赞与在看，你的点赞与在看都是对我们最好的支持❤️
最近开源了一个github仓库：百问百答，在工作中很难做到对社群问题进行立即解答，所以可以将问题提交至 https://github.com/Advanced-Frontend/Just-Now-QA ，我会在每晚花费 1 个小时左右进行处理，更多的是鼓励与欢迎更多人一起参与探讨与解答🌹
来自：https://github.com/Advanced-Frontend/Daily-Interview-Question