发布日期：2024-10-11 00:35 点击次数：113
咱们来伸开今天的话题巨乳 gif。
DNS 是基于 UDP 的应用层契约吗？当咱们奉行 dig www.baidu.com 时，操作系统会发出 dns 肯求，去商讨 www.baidu.com 域名对应的 IP 是若干。
$ dig www.baidu.com ; DiG 9.10.6 www.baidu.com global options: +cmd Got answer: -HEADER- opcode: QUERY, status: NOERROR, id: 61559 flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 QUESTION SECTION: ;www.baidu.com. IN A ANSWER SECTION: www.baidu.com. 298 IN CNAME www.a.shifen.com. www.a.shifen.com. 298 IN A 180.101.49.12 www.a.shifen.com. 298 IN A 180.101.49.11
此时，从抓包上来看，DNS 动作应用层契约，在传输层照实是用了 UDP 契约。
传输层使用了 UDP 契约
但是，其实 RFC 5966 中提到。
# https://www.rfc-editor.org/rfc/rfc5966 This document updates the requirements for the support of TCP as a transport protocol for DNS implementations.
也便是说固然咱们大部分情况下看到 DNS 使用 UDP，但其实 DNS 亦然撑持 TCP 的。
当咱们在 dig 敕令里加上 + tcp 的选项时，就不错强制 DNS 查询使用 TCP 契约进行数据传输。
$ dig +tcp www.baidu.com ; DiG 9.10.6 +tcp www.baidu.com global options: +cmd Got answer: -HEADER- opcode: QUERY, status: NOERROR, id: 28411 flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 QUESTION SECTION: ;www.baidu.com. IN A ANSWER SECTION: www.baidu.com. 600 IN CNAME www.a.shifen.com. www.a.shifen.com. 600 IN A 180.101.49.11 www.a.shifen.com. 600 IN A 180.101.49.12
此时再次抓包。
不错发现，在传输层，DNS 使用了 TCP 契约。
那么问题就来了。
为什么有 UDP 了还要用到 TCP？咱们知谈收集传输就像是在某个管谈里传输数据包，这个管谈有一定的粗细，叫 MTU。向上 MTU 则会在发送端的收集层进行切分，然后在接纳端的收集层进行重组。而重组是需要有个缓冲区的，这个缓冲区的大小有个最小值，是 576Byte。
IP 层分片后传输会加大丢包的概率，且 IP 层本人并不具备重传的功能，因此需要尽量幸免 IP 层分片。
若是传输经过中真实发生了分片，需要尽量确保能在接纳端凯旋重组，于是在最保障的情况下，将 MTU 缔造为 576。（有些过于严慎，当今大部分场景下 MTU=1500）。
基于这样的前提，这个 MTU 长度刨去 IP 头和 UDP 头，大要剩下 512Byte。
是以才有了 RFC1035 中提到的，在 UDP 场景下，DNS 报文长度不应该向上 512Byte。
向上则会被截断。那数据包就不完好了，可能会导致下流没法平时认知数据。
但不可幸免的是，总会有需要传多半数据的场景。
何如办呢？那就改用 TCP 吧。
因为 TCP 本人会分段，分段后的长度刚巧小于等于 MTU 的长度。而且丢包后还会重传，因此不错确保数据平时传输。
是以说数据包长度大于 512 时，DNS 就需要使用 TCP 契约进行传输。
那既然 TCP 那么好，为什么不全用 TCP？咱们不错对比上头 UDP 和 TCP 的那两张图，会发现，除了 DNS 的请乞降反映两个数据包，TCP 场景下还多了三次捏手和四次挥手这几个包。
咋一看好像也不算越过多。
咱们再且归看下，通过 DNS 契约去查询域名对应的 IP 的经过。
将查询经过细分的话，是不错分为迭代查询和递归查询的。
迭代查询和递归查询是什么
迭代查询是指，发出 DNS 后，对方若是不知谈这个域名的 IP 是什么，会告诉我有可能知谈这件事的机器的 IP，我我方再去问有可能知谈的机器，不停类似直到问到后果。
递归查询是指，发出 DNS 肯求后，要求对方查好后平直给出最终后果。
看起来递归查询好像很便捷，但其实是将查询的经过转嫁给了其他 DNS 干事器。是以好多时候，这两者是同期存在的。
举个例子。
比如如故查询 www.baidu.com 对应的 IP。
那本机在发出 DNS 肯求时，会要求最近的 DNS 干事器将后果查好了再给回本机（step1），是以这时候是要求的递归查询。
本机是消弱了，然则最近的 DNS 干事器（有可能是你的家用路由器）却需要用功起来了，它需设施受迭代查询的花式，最坏的情况下，它需要：
step2: 查询根域名干事器
step3: 拿到根域名干事器复返的一级域名（com）干事器 IP，
step4: 再去查询一级域（com）干事器
step5: 取得二级域（baidu）干事器的 IP
step6: 查询二级域（baidu）干事器
step7: 取得三级域（www）干事器的 IP
step8: 查询三级域（www）干事器
step9: 取得 www.baidu.com 干事器的 IP
此时 DNS 干事器在将后果放入缓存后，会将后果给回本机（step10）。
不错看到，迭代查询和递归查询在这个场景中其实是同期存在的。
迭代查询和递归查询的报文特征
这在 DNS 的报头里也有体现。
咱们需要情愫的是 Flags 字段中的 RD 和 RA 字段。
RD（Resursion Desired）是指客户端生机的查询花式。
・ 0：暗示迭代查询
・1：暗示递归查询
RA（Recursion Available）是指干事端本色汲取的查询花式，它只会在反映包里出现。
・ 0：暗示迭代查询
・1：暗示递归查询
迭代查询和递归查询带来的影响
回到为什么 DNS 不全部改用 TCP 的问题上。
咱们不错看到，DNS 肯求中，波及到的干事器其实相当多。
若是皆用 TCP 的话，那就皆需要三次捏手建造连结，四次挥手断开连结。
关于递归查询的那一方，其实还好，因为只会建造一次连结，发出一次肯求接纳一次反映就完事了。
但关于迭代查询的一方，就需要与稠密干事器类似建造和断开连结。性能会有很大影响。
这时候推断大家也会想问。
那是不是不停开 TCP 连结，下次复用就好了？
不太好。
因为大部分 URL 所波及到的域名干事器皆不太换取，比如 www.baidu.com 和 www.xiaobaidebug.top 波及到的一、二、三级域名干事器就不一样，因此也没必要珍爱 TCP 长连络作念复用。
是以比拟之下，在数据量较小的场景下，使用 UDP 就不错省下捏手挥手的铺张，因此 UDP 才是更优解。
DNS 的 IPV4 根域独一 13 个吗？照实是的。
问题又来了。
为什么是 13 个 IP，弗成再加吗？这个，单纯是历史原因了。上头提到基于 UDP 的 DNS 报文不应该向上 512Byte，刨去 DNS 本人的报头信息，算下来大致能放 13 个 IP（IPV4）。
具体的策划经过不太迫切，我就不详了，对策划经过感兴味的话，不错看下这篇著作最底下的参考文件。
固然当今大部分机器 MTU=1500 了，但由于还可能存在 MTU=576 的机器，需要上前兼容，因此也不提议舒缓退换。
但问题叒来了。
退一万步，就算所有机器的 MTU 皆到 1500 了，是不是就没这个领域了？
嗯，从这个角度来说，照实不错加，但没必要。
咱们需要念念考下为什么要加？
是因为认为 13 个 IP 对应 13 台干事器，压力太大了吗？
如故说出于其他不可明说的身分辩论？
比如，很久往日看电视的时候，有位砖家提到 "全球 DNS 根干事器独一 13 台，其中 x 台部署在漂亮国，只消它们割断拜谒，那咱们的收集就会受影响 balabala"。
但其实，13 个 IP 不代表独一 13 台干事器。准确点来说，应该说是 13 组干事器，每个组皆不错无尽膨胀干事器的个数，多个干事器共用并吞个 IP。
这内部其实波及到一个叫任播的时间。
任播是什么咱们知谈，在传输的经过中，一台机器发音尘给另一台机器，这叫单播（unicast）。
一台机器，发音尘给腹地网段的所有机器，那叫播送（broadcast）。
这两个皆很常见，应该皆没问题。
一台机器，发音尘给的所有顺应条目的策划机器里的其中一台，那叫任播（anycast）。
咱们知谈，全天下的收集开辟，放在通盘就酿成了一个网状结构，这亦然收集这个称呼的由来。
咱们假定有这样一个路由器，它想要拜谒某个 IP 的机器。从路由器到策划机器有相当多条旅途，路由器不错通过跳数等信息来策划每条旅途的老本，取得最优的旅途。将最优旅途汇成一张表，也便是咱们常说的路由表。
比如底下的图里，绿色的线和红色的线皆能到达不异的策划地，但光显，绿色的旅途更短，是以路由表记载了老本更低的绿色阶梯。
那么当今假定咱们将这个网状结构里的两个点的收集 IP 设为一样，路由器其实不知谈这是两个不同的机器，对它来说，这仅仅两条不同的旅途，但皆是通向并吞个 IP。
这两条旅途皆能到并吞个 IP，因此打到浪漫一个干事皆能拿到想要的信息，从而完了了任播。
当今咱们再加个条目，路由器和其中一台机器皆在国内，另一台机器在国际。对路由器来说，由于国内的机器离得近，传输老本低，而国际的机器远，传输老本高，是以路由器生成的最优阶梯是打到国内的机器。
基于这样的念念路，咱们只消镜像一份国际的 DNS 域名干事器信息到国内机房里。咱们就不再需要肯求国际干事器了。
是以，就算其他国度的根域名干事器挂了，也不会对咱们有什么影响，事实上国内依然有相当多的镜像干事器了，稳得很。
那稍稍膨胀一下，假定在上海和广东皆缔造了换取 IP 的镜像干事，那关于上海的用户来说，他们的路由器会优先将肯求打到上海的镜像干事。而广东的用户则会优先打到广东的机器里，从而完了了就近拜谒。
上海的镜像干事挂了，那对应的上海用户路由器里的路由表，就会将旅途更新为广东的镜像机器。上海用户的肯求就会打到广东的镜像干事中。从而完了高可用（或者说灾备）。
看起来，愚弄任播既能作念到负载平衡，还能完了高可用，这跟 nginx 很像啊。
那么，问题就来了。
霸凌 拳交既然有任播时间，那为什么还要用 nginx？nginx 动作常见的反向代理干事器，背后不错连 N 个干事端。当客户端想要肯求后端时，客户端根柢不需要知谈是哪个干事器在为它提供干事，只管拿 nginx 终末复返的后果就行了。像这种，屏蔽掉具体有哪些干事器的代理花式便是所谓的反向代理。
正因为不知谈背后有哪些干事器，因此不错作念到无尽膨胀，挂了一台其他也能顶上，因此完了了负载平衡和高可用。
之前写过一篇著作《为什么有 HTTP 契约，还要有 websocket 契约？》，提到过关于收集游戏场景，需要有干事器主动推数据到客户端。由于 nginx 与客户端和干事端之间会建造 TCP 长连络，因此客户端在收到干事端的音尘之后，能沿着这条连结反映干事端。
而若是这时候无须 nginx，单纯使用任播，那干事器将音尘主动推给客户端之后，客户端反映时，音尘不保证还能给回原本的干事器。毕竟“任播”的含义便是，只消能拜谒浪漫一台干事器就行了。
因此任播并弗成代替 nginx。
天然这两个本来也不是一个维度的东西，拿来比较其实并不对适，我仅仅举了个反例来匡助大家捋一捋两者之间的相反。
回想・DNS 在传输层既能使用 UDP 也能使用 TCP 契约。当传输数据量小于 512Byte 时会使用 UDP，不然使用 TCP。
・ 固然根域独一 13 个 IP，但不代表独一 13 台干事器，准确的说，应该是十三组干事器，每组干事器皆共用并吞个 IP，国内依然有相当多的镜像干事器，愚弄任播时间，只消能就近拜谒到其中一台就行了。
・ 国内国际若是皆有换取 IP 的策划机器，那关于路由器来说，无非便是有两条旅途不错抵达换取的策划地，一个远一些，一个近一些。基于老本，会将更近的旅途放到路由表中。
・ 任播时间固然也能在一定进程上完了负载平衡和高可用，但它跟 nginx 并不是一个维度的东西，弗成替代 nginx。
参考而已
《Why 13 DNS root servers?》
https://miek.nl/2013/november/10/why-13-dns-root-servers/
本文来自微信公众号：小白 debug （ID：xiaobaidebug），作家：小白
告白声明：文内含有的对外跳转连络（包括不限于超连络、二维码、口令等花样），用于传递更多信息，爽朗甄选时间巨乳 gif，后果仅供参考，IT之家所有著作均包含本声明。