”TCP 拆包粘包“网络上的争论挺大的，原因在于这一概念在 RFC 中并未提到过，(*￣︶￣)有点民科的赶脚。但实际上它是挺常见的一个问题，比较准确的描述应该是应用层分包问题。那么为什么提到这一概念总是会带上 TCP 而不是 UDP 呢？因为应用层分包问题本质是接收方在某个时刻接收到的数据不构成一条完整的消息

• 对于 UDP 来说，它并未在 IP 协议外作出额外的可靠性特性，所以无论发送的数据荷载是多少都会完整的交由 IP 层处理，而 IP 层虽然会根据 MTU 进行分包，但是接收方会确保在 IP 层重组完成才会交由 UDP 处理，否则会直接丢弃。所以基于 UDP 协议实现的应用层协议每次接收到的数据都是完整的消息，无需应用层做额外的分包和重组

• 对于 TCP 来说，它是无边界的字节流协议，为了解决可靠性的问题以及各种性能优化会导致接收方收到的数据不是完整的消息，比如：

  • 若数据荷载过小时，TCP 根据 Nagle 算法整合多个小数据包统一发送
  • 若数据荷载过大时，TCP 会根据 MSS 大小对数据进行分段发送

  这也就是为啥”拆包粘包“总是碰瓷 TCP 的原因了

DNS 解析的作用就是将主机名转换为 IP 地址，那么 DNS 解析过程是怎么样的，DNS 服务器又是如何快速响应全球用户的请求的呢？

DNS 解析原理

在解释 DNS 解析原理前首先需要知道的是，DNS 服务器只是一种统称，实际上 DNS 服务器的不同类型负责完全不同的功能，这对于后续理解整个原理具有非常关键的作用。下面根据 DNS 服务器功能不同主要分为 4 种类型：

• 根域名服务器：根域名服务器负责维护顶级域名（如 .com, .net, .org 等）对应的 TLD 域名服务器地址，即当客户端向其发送 DNS 解析请求时，根域名服务器会返回其顶级域名对应的 TLD 域名服务器地址。目前全球的根域名服务器的任播（Anycast）地址共有 13 个

• TLD 域名服务器(顶级域名服务器)：不同顶级域名由不同的托管商负责，在根域名服务器响应了 TLD 域名服务器后的域名后，用户可以在 TLD 域名服务器获取到定向到权威服务器的信息，比如返回 zzcoder.cn 所在的权威服务器域名

• 权威服务器：权威服务器维护了特定顶级域名下的所有子域名（比如 zzcoder.cn）的 DNS 记录。比如用户在域名注册商(如 DNSPod)下注册 zzcoder.cn 实际上就是在权威服务器添加各类 DNS 记录（A 记录，CNAME 记录等等）

• 递归解析器：递归解析器也称为 DNS 解析器。递归解析器作为客户端与 DNS 域名服务器的中间人，是面向客户端最近的一站，它负责接收客户端的 DNS 查询，并分别向根域名服务器，TLD 域名服务器，权威服务器发送解析请求，然后将最终的响应返回给客户端。常见的公开的 DNS 解析器有 Google 的 8.8.8.8, Cloudflare 的 1.1.1.1

  每个递归解析器都会内置 DNS 根域名服务器的 13 个 任播地址

大家常提起 HTTP 协议是无状态的，其指代的“无状态”是什么？常见的观点有：

• 无状态代表相同的请求参数总是能返回相同的结果
• HTTP 本身的设计是无状态的，增加了有状态协议头（Cookie/Session）后变成了有状态协议

对于第一个观点显而易见是错误的，它的表示更倾向于“幂等性”，这往往无法由协议本身保证，还需要服务器进行“有状态”的响应（若服务器不进行状态的持久化，当然无法做到幂等）；而第二个观点听起来就靠谱很多，通过 Cookie/Session 进行状态维护从而保证了有状态。但我们可以考虑下 Cookie 或 Session 保证的是谁的状态？一般情况下，它们保证了后端服务器的状态，而非 HTTP 协议的状态。因此对于最初的问题 HTTP 协议的”无状态“，我们是不是应该从协议的本身出发呢？