主题
第五章 应用层：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 | 负责该域的权威服务器 | 层级结构里"下一级去问谁"的指路牌 |
3. HTTP：万维网的对话规则
HTTP（超文本传输协议）规定浏览器与网站服务器之间怎么请求和响应，基于 TCP 的 80 端口（HTTPS 为 443）。
先澄清一组常被混用的概念：互联网（Internet）是全球互联的网络基础设施；万维网（WWW）只是运行在互联网之上的一种应用——用 HTTP 传输、用 HTML 描述、用 URL 定位的超文本系统。邮件、网游、视频通话都跑在互联网上，但都不属于万维网。"互联网就是 WWW"是错误表述。
3.1 请求与响应的格式
一次 HTTP 对话就是一去一回两段结构化文本：
请求 = 请求行（方法 路径 版本）+ 请求头 + 空行 + 请求体
GET /index.html HTTP/1.1
Host: www.example.com
响应 = 状态行（版本 状态码 短语）+ 响应头 + 空行 + 响应体
HTTP/1.1 200 OK
Content-Type: text/html
<html>……</html>3.2 常见方法与状态码
| 方法 | 语义 |
|---|---|
| GET | 获取资源，参数在 URL 里，可被缓存 |
| POST | 提交数据，参数在请求体里 |
| PUT | 更新（整体替换）资源 |
| DELETE | 删除资源 |
| HEAD | 只要响应头不要正文，常用于探测 |
状态码按首位数字分五类，"1 信息、2 成功、3 重定向、4 客户端错、5 服务器错"：
| 状态码 | 含义 | 白话 |
|---|---|---|
| 200 | OK | 成功 |
| 301 / 302 | 永久 / 临时重定向 | 搬家了，去新地址 |
| 304 | Not Modified | 没变，用你的缓存 |
| 403 | Forbidden | 认识你，但不让你看 |
| 404 | Not Found | 没这个东西 |
| 500 | Internal Server Error | 服务器自己出错了 |
| 502 / 503 | 网关错误 / 服务不可用 | 后端挂了 / 忙不过来 |
区分 403 与 404、404 与 500 的责任方（4 开头怪客户端请求，5 开头怪服务器）是选择题常客。
3.3 无状态与 Cookie/Session
HTTP 是无状态协议：每个请求独立处理，服务器不记得你上一次来过——这让服务器实现简单、容易横向扩展。但购物车、登录态需要"记住你"，于是打补丁：
- Cookie：服务器发响应时塞给浏览器一小段数据，浏览器以后每次请求自动带上——把记忆存在客户端。
- Session：服务器把用户状态存在自己这边，只给浏览器一个入场券号码（Session ID，通常放在 Cookie 里传递）——把记忆存在服务端，客户端只拿号。
一句大白话点透：Cookie 是"会员卡信息写在卡上"，Session 是"卡上只有卡号，信息在店里的登记簿上"。
3.4 HTTP/1.1、/2、/3 演进一段话
HTTP/1.1 用持久连接解决了每个请求都要重新握手的浪费，但同一连接上请求必须排队，队头一个慢全体等（队头阻塞）；HTTP/2 引入二进制分帧和多路复用，多个请求在一条 TCP 连接上交错并行，但 TCP 层丢一个包仍会卡住所有流；HTTP/3 干脆抛弃 TCP，改用基于 UDP 的 QUIC 协议，在应用层自己实现可靠传输和加密，各流独立互不牵连，连接建立更快。演进主线就一句话：一直在跟"排队等待"作斗争。
3.5 静态页面与动态页面
另一组基础概念：静态页面是服务器上现成的 HTML 文件，谁来访问都返回同一份，像印好的传单；动态页面由服务器程序在收到请求时现场生成（查数据库、填模板），不同用户、不同时刻内容不同，像现点现做的菜。判断标准看"服务器是否在请求时执行程序生成内容"，而不是看页面上有没有动画——一张带轮播图的纯 HTML 仍是静态页面，动画是浏览器里 JS 的事。
4. 其他常用协议：各自解决什么问题
| 协议 | 解决什么问题 | 传输层 | 端口 | 备注 |
|---|---|---|---|---|
| FTP | 文件上传下载 | TCP | 21 控制 / 20 数据 | 控制与数据双连接是其特色 |
| SMTP | 发送邮件、邮件服务器间投递 | TCP | 25 | 只管"寄"，不管"取" |
| POP3 | 从邮箱服务器收取邮件 | TCP | 110 | 通常下载到本地即从服务器删除 |
| IMAP | 收取并同步管理邮件 | TCP | 143 | 邮件留在服务器，多设备状态一致 |
| Telnet | 远程登录 | TCP | 23 | 明文传输，已被淘汰 |
| SSH | 加密的远程登录 | TCP | 22 | Telnet 的安全替代品 |
| DHCP | 自动分配 IP、掩码、网关、DNS | UDP | 67/68 | 新设备入网的"发牌员" |
| DNS | 域名解析 | UDP 为主 | 53 | 大响应与区域传送用 TCP |
三个易混点专门说清：
- 邮件三兄弟：SMTP 负责"发"（用户发给自己邮箱服务器 + 服务器投递给对方服务器），POP3/IMAP 负责"收"（从自己邮箱服务器取信）。一封邮件的完整旅程要用到两类协议。POP3 与 IMAP 的差别是"取走"与"同步"：POP3 像取信后信箱清空，IMAP 像网盘，手机电脑看到同一份。
- Telnet 与 SSH：功能相同（远程登录），差别只在是否加密。看到"Telnet 安全"直接判错。
- DHCP：设备刚入网时连 IP 都没有，用广播找 DHCP 服务器讨要配置，因此必须基于 UDP。第七章会看它的完整流程。
一封邮件的完整旅程
把邮件流程画出来，SMTP 与 POP3/IMAP 的分工一目了然——这张图能直接对付"发件到收件各环节用什么协议"的考题：
注意两个细节：前两段"上行提交"和"服务器互递"用的都是 SMTP；只有最后"收件人取信"这一段才轮到 POP3 或 IMAP。所以"整个邮件过程只用一种协议"必错，"SMTP 出现两次"却是对的。
5. URL 结构拆解
URL（统一资源定位符）是资源在互联网上的"完整地址"，以 https://www.example.com:443/news/list.html?page=2#top 为例：
| 片段 | 名称 | 作用 |
|---|---|---|
| https | 协议（方案） | 用什么协议访问 |
| www.example.com | 主机（域名） | 资源在哪台服务器，经 DNS 转成 IP |
| 443 | 端口 | 服务器上哪个进程；省略时用协议默认值 |
| /news/list.html | 路径 | 服务器上的哪个资源 |
| page=2 | 查询参数 | 附加条件，问号开头，多个用与号连接 |
| top | 片段（锚点） | 页面内定位，不发给服务器 |
注意两点：端口省略时按协议取默认（HTTP 80、HTTPS 443）；锚点只在浏览器本地起作用。
本章要点回顾
| 知识点 | 一句话结论 |
|---|---|
| C/S vs P2P | 集中服务 vs 人人皆服务器；P2P 用户越多资源越多 |
| DNS 结构 | 根—顶级—权威三级分工，每级只指路给下一级 |
| 递归 vs 迭代 | 递归"给我最终答案"，迭代"我给你下一条线索" |
| DNS 传输层 | 默认 UDP 53，缓存让多数查询不出本地 |
| DNS 记录 | A 记 IPv4、AAAA 记 IPv6、CNAME 别名、MX 收邮件 |
| 静态 vs 动态页面 | 看服务器是否在请求时执行程序生成内容，与动画无关 |
| HTTP 格式 | 请求行/状态行 + 头部 + 空行 + 正文 |
| 状态码分类 | 2 成功、3 重定向、4 客户端错、5 服务器错 |
| WWW 与互联网 | 万维网只是互联网上的一种应用，二者不能画等号 |
| 无状态补丁 | Cookie 存客户端，Session 存服务端发号 |
| 邮件旅程 | 提交与投递两段用 SMTP，最后取信才用 POP3/IMAP |
| HTTP 演进 | 1.1 持久连接、2 多路复用、3 基于 UDP 的 QUIC |
| 邮件协议 | SMTP 只管发，POP3 取走，IMAP 同步 |
| 远程登录 | Telnet 明文已淘汰，SSH 加密 |
| URL | 协议://主机:端口/路径?参数#锚点 |
做题提醒
- DNS 默认用 UDP（53 端口），不是 TCP；但"DNS 只能用 UDP"也是错的——区域传送和大响应用 TCP。
- 主机到本地域名服务器是递归查询，本地服务器往上（根/顶级/权威）通常是迭代查询，方向别答反。
- SMTP 只用于发送邮件，收邮件用 POP3 或 IMAP；"用 SMTP 收取邮件"是典型错误选项。
- 状态码归属：404 是客户端一侧的请求问题（资源不存在），500 是服务器内部错误；403 是"有此资源但拒绝访问"。
- HTTP 无状态指"服务器不保留请求之间的上下文"，不等于"不能实现登录"——Cookie/Session 就是补状态的机制。
- 端口配对题必背：FTP 21、SSH 22、Telnet 23、SMTP 25、DNS 53、HTTP 80、POP3 110、HTTPS 443。
- GET 与 POST 的规范区别在语义（获取 vs 提交）和参数位置（URL vs 请求体）；"GET 绝对不能携带任何数据"过于绝对。
- URL 中省略端口时按协议取默认值（HTTP 80、HTTPS 443）；锚点部分不会发送给服务器。
- "万维网就是互联网"混淆了应用与基础设施：WWW 只是互联网上众多应用之一，邮件、即时通信并不属于 WWW。