问题
DNS在进行区域传输的时候使用TCP，普通的查询使用UDP。为什么查询是使用UDP呢？网络上大部分答案都说UDP性能更好，打开网页速度快。如果是这样的话，为什么HTTP却是使用TCP呢？
正文
衡量计算机通信快慢的指标是“响应时间”，即从用户发出通信指令（输入网址敲回车键）开始，到用户看到完整页面为止，所流逝的时间。
响应时间（ResponseTime）
以浏览器为例，这个响应时间大体分为三部分：
响应时间= DNS域名解析时间+ TCP 连接建立时间 + HTTP交易时间
如果让响应时间尽可能小，只有让等号右侧的三者尽可能小。
- TCP连接是固定的三次握手，所以很难有进一步缩小的空间。
- HTTP交易，基于Request / Response，也很难有提升的空间。
所以，只能让DNS域名解析的时间越小越好。
域名解析
采用TCP传输，则域名解析时间为：
DNS域名解析时间 = TCP连接时间 + DNS交易时间
采用UDP传输，则域名解析时间为：
DNS域名解析时间 = DNS交易时间
很显然，采用UDP传输，DNS域名解析时间更小。
不就多一次TCP连接时间吗？
NO!
在很多时候，用户在访问一些冷门网站时，由于DNS服务器没有冷门网站的解析缓存，需要到域名根服务器、一级域名服务器、二级域名服务器迭代查询，直到查询到冷门网站的权威服务器，这中间可能涉及到多次的查询。
如果使用TCP传输，多几次查询，就多几次TCP连接时间，这多出来的时间不容小觑。
UDP传输的弱点
由于历史的原因，互联网上物理链路的最小MTU = 576，基于UDP传输的DNS为了限制报文不超过576，所以将DNS报文限制在512字节。
这样一旦DNS查询应答超过512字节，基于UDP的DNS就只有截短为512字节，那么用户得到的DNS应答就是不完整的。
为了克服这种困难，最简单的方式就是使用TCP，来重新查询。尽管交易时间可能比较长，但毕竟可以得到完整的答案，总比得到不完整的答案要好。
难道UDP没有办法传输超过大于576字节的数据吗？
并不是这样。
DNS是由于自身的限制，原因上述文字已经解释。
当基于UDP传输的DNS有1000字节需要传输时，会将1000字节砍成两个500字节的报文传输？
不会！只会保留前面的512字节，剩下的488字节会抛弃！
为什么要这样？
DNS没有字段来标识报文ID，比如1、2、3，所以默认只有一个报文，剩下的多余数据只有被扔的份！
互联网的不安全性
互联网经过多年的发展，鱼龙混杂，欺骗横行，用户的域名服务器是8.8.8.8，用户能够拍着胸脯说，从8.8.8.8返回的DNS应答真的就是8.8.8.8回答的吗?
不能！
无论是采用UDP、还是TCP传输，都无法保证！
怎么办呢？
如果8.8.8.8 返回的应答，使用自己的私钥签名，那么主机得到应答之后，先检查签名是否来自于8.8.8.8的签名，如果是，接收。如果不是，拒绝！
这样是不是就可以拍着胸脯说，应答真的是来自于8.8.8.8。
但签名带来了很多负面问题，DNS应答由于携带了证书链，整个报文有几千字节，无法使用UDP传输，那也只好使用TCP传输了。
总结一下
- 使用UDP传输是由于效率高，传输小于等于512字节报文。
- 使用TCP传输是由于可以传输大于512字节报文。
- 使用签名是保证数据来源的可靠性。
- 使用TCP传输，同样是可以传输证书链、签名。
- 使用UDP同样可以传输远远大于576字节的数据，只要应用程序可以标识数据ID。