本文为社区首发签约文章，14天内制止转载，14天后未获授权制止转载，侵权必究！
接上一篇文章《DNS中有哪些值得学习的优异规划》 终究留传的两个问题。
- 从抓包能够看出，DNS在传输层上运用了UDP协议，那它只用UDP吗？
- DNS的IPV4根域名只需
13个，这里边其实有不少都布置在美丽国，那是不是意味着，只需他们不高兴了，堵截咱们的拜访，咱们的网络就得瘫痪了呢？
咱们来展开今天的话题。
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协议。
但是，其实 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?》
miek.nl/2013/novemb…
终究
最近原创更文的阅读量稳步下跌，左思右想，夜里翻来覆去。
我有个不成熟的恳求。
离开广东好长时间了，好久没人叫我靓仔了。
咱们能够在谈论区里，叫我一靓仔吗？
我这么善良质朴的希望，能被满意吗？
假如真实叫不出口的话，能帮我点下重视和右下角的点赞+保藏吗？
