解释一下这句话，我们知道，TCP 具有序列号机制，发送方会把一个大的 HTTP 报文按序号分割成若干报文段并加上 TCP 首部，也就是封装成 TCP 报文段。那么接收方在收到这些 TCP 报文段后，就会按照序号以原来的顺序重组 HTTP 报文。这就是面向字节流的 TCP。
而所谓 UDP 面向报文，发送方的 UDP 对应用层交付下来的 HTTP 报文， 在添加 UDP 首部后也就是封装成 UDP 报文，就向下交付给网络层 IP 协议。不做任何的拆分与合并，主要就是因为 UDP 没有像 TCP 一样的序列号机制来标识报文，所以默认只有一个 UDP 报文。
UDP 这么做就会导致一个问题。
互联网上物理链路的最小传输单元 = 576 字节，为了在物理链路上顺利传输，UDP 报文不能超过 576 字节，为此，UDP 报文被限制在 512 字节以内。
而 DNS 由于大面积使用了 UDP，这样一旦 DNS 报文超过 512 字节，基于 UDP 的 DNS 报文就只有抛弃多出来的 64 字节，截短为 512 字节，那么用户得到的 DNS 报文就是不完整的。
如何解决这个问题呢？
没错，最简单的方式就是使用 TCP。尽管速度可能相之 UDP 较慢，但对于得到完整的 DNS 报文，速度慢一点也可以忍受。
DNS 分别在什么情况下使用 UDP 和 TCP
了解了 TCP 面向字节流而 UDP 面向报文的这个特性之后，在域名解析的时候，也就是客户端向 DNS 服务器查询域名获取 IP 地址的时候，DNS 协议关于 UDP 和 TCP 的选择通常可以分为以下两种情况：
1）若客户端事先知道 DNS 响应报文的长度会大于 512 字节，则应当直接使用 TCP 建立连接
2）若客户端事先不知道 DNS 响应报文的长度，一般会先使用 UDP 协议发送 DNS 查询报文，若 DNS 服务器发现 DNS 响应报文的长度大于 512 字节，则多出来的部分会被 UDP 抛弃（截断 TrunCation），那么服务器会把这个部分被抛弃的 DNS 报文首部中的 TC 标志位置为 1，以通知客户端该 DNS 报文已经被截断。客户端收到之后会重新发起一次 TCP 请求，从而使得它将来能够从 DNS 服务器收到完整的响应报文。
当然了，在域名解析的时候，一般返回的 DNS 响应报文都不会超过 512 字节，用 UDP 传输即可。事实上，很多 DNS 服务器进行配置的时候，也仅支持 UDP 查询包。
不过，DNS 不仅存在域名解析的过程，还有区域传输的过程，而在进行区域传输的时候 DNS 会强制使用 TCP 协议。
什么是区域传输？
这就不得不提一下主域名服务器和辅助域名服务器。
设置域名服务器时，服务器管理员可以选择将域名服务器指定为主服务器还是辅助服务器（也称为从服务器）。
主域名服务器负责维护一个区域的所有域名信息，是特定的所有信息的权威信息源，数据可以修改。主服务器直接从本地文件获取此信息。只能在主服务器上更改区域的 DNS 记录，然后主服务器才能更新辅助服务器。
当主域名服务器出现故障、关闭或负载过重时，辅助域名服务器作为主域名服务器的备份提供域名解析服务。辅助域名服务器中的区域文件中的数据是从主域名服务器中复制过来的，无法自行修改。
其实就是主从的概念，各位应该也都比较熟悉了。主域名服务器用来写，辅助域名服务器用来读，提供负载均衡的能力，缓解主域名服务器的压力。
那么所谓区域传输（zone transfer）呢，就是辅助域名服务器与主域名服务器通信，并同步数据信息的过程。
辅域名服务器会定时向主域名服务器进行查询以便了解数据是否有变动。如有变动，则会执行一次区域传输。区域传输使用 TCP 而不是 UDP，因为数据同步传送的数据量比一个 DNS 请求和响应报文的数据量要多得多。
文章开头提到的既然 UDP 更快，为什么 HTTP 不使用 UDP 呢？这个问题的答案也大抵如此。
由于互联网的不安全性，我们需要数字证书并携带数字签名来保证数据的安全性，为此，整个 HTTP 报文的大小已经远远超过 512 字节，无法使用 UDP 传输。
小结
综上，总结下，虽然 UDP 速度更快，DNS 协议也确实大面积使用了 UDP，但是由于 UDP 面向报文、只能传输小于 512 字节的特性，DNS 并非只使用了 UDP，具体的 TCP 和 UDP 使用场景如下：
本文分享自微信公众号 - 飞天小牛肉（CS-Wiki）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。