主题
第五章 应用层：DNS、HTTP 与常用协议
1. 应用层在协议栈里的角色
下面四层解决的是"怎么把数据从一个进程送到另一个进程"，应用层解决的是"送到之后，双方说什么、按什么格式说"。每个应用层协议本质上是一份双方程序共同遵守的对话剧本：请求长什么样、响应长什么样、先说什么后说什么。
理解应用层协议时，抓三个问题即可：它解决什么问题？它底下用 TCP 还是 UDP？它的对话流程是什么样？
1.1 C/S 模式与 P2P 模式
应用程序的组织结构有两大类：
| 维度 | C/S（客户/服务器） | P2P（对等网络） |
|---|---|---|
| 角色 | 服务器常驻等待，客户端主动发起 | 每个节点既是客户又是服务器 |
| 资源位置 | 集中在服务器 | 分散在所有节点 |
| 扩展性 | 用户越多服务器压力越大 | 用户越多可用资源反而越多 |
| 管理与安全 | 集中管理，容易控制 | 难以集中管理 |
| 典型应用 | 网页、邮件、数据库 | BT 下载、区块链 |
一句大白话点透：C/S 是"所有人去餐厅吃饭"，P2P 是"百家宴，人人带一个菜"。浏览网页是典型 C/S；迅雷、BT 这类"下载的人越多速度越快"的应用是典型 P2P。
2. DNS：把域名翻译成 IP 地址
网络层认的是 IP 地址，人记的是 www.example.com 这样的域名。**DNS（域名系统）**就是全球分布式的"翻译电话簿"。它默认使用 UDP 的 53 端口（一问一答，量小，建 TCP 连接不划算）。
2.1 层级结构：为什么不搞一个全球大表
全世界几亿个域名，如果放在一台服务器上：单点故障、访问拥堵、更新困难，全都是灾难。DNS 的设计是按域名的层级把权威数据分散出去：
- 根域名服务器：只回答"负责 .com 的服务器在哪"。
- 顶级域服务器：如 .com 服务器，回答"负责 example.com 的服务器在哪"。
- 权威域名服务器：真正存着
www.example.com记录的服务器，由域名持有者管理。
域名本身就体现层级，从右往左读：www.example.com 中 com 是顶级域，example 是二级域，www 是主机名。每一级只需要知道下一级去哪问，就像问路问到街道办，街道办不知道你家门牌，但知道该问哪个居委会。
2.2 递归查询与迭代查询
客户端通常把查询全权委托给本地域名服务器（运营商或公司提供），本地服务器再替你跑腿：
两种查询方式的区别在"被问的人负不负责跑腿"：
- 递归查询：被问方必须给出最终答案，自己去追查——主机对本地服务器的查询是递归的（"你必须给我结果"）。
- 迭代查询：被问方只给一条线索"去问谁"，追查由提问方继续——本地服务器对根、顶级、权威服务器的查询通常是迭代的。
缓存是 DNS 高效的关键：本地服务器和操作系统都会把查到的结果缓存一段时间（由 TTL 控制），绝大多数查询根本到不了根服务器。
2.3 常见的 DNS 记录类型
DNS 电话簿里不只有"域名到 IPv4"一种条目，考试偶尔点名：
| 记录类型 | 存的是什么 | 白话 |
|---|---|---|
| A | 域名对应的 IPv4 地址 | 最常用的"查号" |
| AAAA | 域名对应的 IPv6 地址 | 四个 A，因为 128 位是 32 位的四倍 |
| CNAME | 域名的别名指向 | "此名转接到另一个名字" |
| MX | 该域名收邮件的服务器 | 发邮件前先查它，才知道信投到哪 |
| NS | 负责该域的权威服务器 | 层级结构里"下一级去问谁"的指路牌 |