五、应用层（DNS/HTTP/HTTPS/无线局域网）（第79-97题）｜计算机网络 · 高频 150 题

五、应用层（DNS/HTTP/HTTPS/无线局域网）（第79-97题）

79. DNS协议的主要功能是（）。

A. 域名→IP地址 B. IP→MAC C. MAC→IP D. IP→域名（唯一功能）

答案：A解析：① 考点定位　DNS 协议的主要功能——域名与 IP 地址之间的映射。

② 知识精讲　DNS（Domain Name System，域名系统）的核心功能是正向解析：域名 → IP 地址。网络通信使用 IP 地址寻址，但人类难以记忆 IP，DNS 充当”翻译官“，将易记的域名（如 www.example.com）翻译成机器可路由的 IP 地址（如 93.184.216.34）。

DNS 还支持反向解析（PTR 记录）：IP → 域名，用于从 IP 反查域名（如邮件服务器反查验证发送方身份），但正向解析是 DNS 的主要功能。

DNS 的层次结构：根域名服务器 → 顶级域服务器（TLD，如 .com/.cn/.edu） → 权威域名服务器（各组织管理自己的域名）。采用客户-服务器模式，默认端口 53，查询走 UDP、区域传送走 TCP。

设计动机： 互联网寻址靠 IP，人类记忆靠域名，DNS 是二者之间的分布式目录服务。设计上强调：层次命名（根→顶级域→二级→主机），避免中心化单点；分布式数据（各域权威服务器自管区数据）；缓存（浏览器/OS/本地 DNS 多级 TTL 缓存，抗高 QPS）。正向解析（域名→IP，A/AAAA）是主功能；反向解析（IP→域名，PTR）用于邮件信誉等场景。DNS 运行在应用层，默认 UDP/TCP 53。没有 DNS，浏览器只能敲 IP，虚拟主机与 CDN 调度都将失效。

③ 本题解析　DNS 的主要功能是域名→IP地址，对应选项 A。

④ 选项逐项辨析

A 域名→IP地址：DNS 正向解析的核心功能，正确。
B IP→MAC：这是 ARP（地址解析协议）的功能，错误。
C MAC→IP：这是 RARP（逆地址解析协议）的功能，已废弃，错误。
D IP→域名（唯一功能）：反向解析（PTR 记录）可以 IP→域名，但正向才是主要功能，”唯一“说法错误。

常见误解来源： 把 DNS 说成分配 IP（那是 DHCP）；DNS 是域名到 IP 的解析。

⑤ 易混对比

协议/服务	映射关系	典型层次	备注
DNS	域名 ↔ IP（正向为主）	应用层	分布式+缓存
ARP	IP → MAC	网络/链路边界	局域网内
RARP / BOOTP	MAC → IP	已过时	被 DHCP 取代
DHCP	动态分配 IP 等	应用层	常与 DNS 更新配合
mDNS	本地域名解析	应用层	局域网 .local

⑥ 拓展延伸工程实践： dig/nslookup 查解析链路；企业内网 split-horizon DNS 让内外网解析不同地址；云上常用 Private Zone。排障顺序：先 dig +trace，再查本地缓存/hosts，再查权威 NS。面试追问：①「DNS 是单点吗？」——逻辑中心化命名，数据与查询分布式。②「正向/反向解析？」——A/AAAA 与 PTR。

⑦ 真题变式　“ARP 的功能是什么？”→IP→MAC 地址解析。“DNS 反向解析用什么记录？”→PTR 记录。“DNS 查询使用什么传输层协议？”→UDP（日常查询）/TCP（区域传送）。

⑧ 记忆锚点　“DNS 域名→IP、ARP IP→MAC、RARP MAC→IP、DHCP 分配IP”。DNS 以正向解析为主，端口 53。

⑨ 知识关联：主库题群：第79题（本题 DNS 功能）、第80题（DNS 传输层辨析）、第81题（域名层次）、第82题（迭代查询）、第83题（A 记录）、第94题（访问时第一步 DNS）构成 DNS 题群。与补题：无直接补题（DNS 细节在主库与面试文件）。与面试20题：面试第8题（DNS 解析过程与缓存）、面试第7题（URL 到页面，DNS 为先）。面试追问：①「递归与迭代谁对主机？」——主机→本地 DNS 常为递归。②「DNS 挂了业务会怎样？」——域名不可达，IP 直连或本地缓存可短时续命。

80. 关于DNS，错误的是（）。

A. 用于域名解析 B. 采用客户-服务器模式 C. 只使用TCP D. 支持递归查询与迭代查询

答案：C解析：① 考点定位　DNS 的传输层协议使用——找出关于 DNS 的错误描述。

② 知识精讲　DNS 既使用 UDP 也使用 TCP，默认端口都是 53：

UDP（日常查询）：DNS 查询报文通常很小（一个请求一个响应），要求低时延，使用 UDP 避免三次握手开销。当响应超过 512 字节（不带 EDNS 的经典 UDP 报文上限）时，先置 TC 位截断、由客户端改用 TCP 重传。启用 EDNS0（RFC 6891）后，UDP 载荷上限改由 16 位的 Request Payload Size 字段协商，理论上限 65535 字节；常见的 1232 / 4096 只是各实现的默认配置值（1232 用于尽量避开 IP 分片），不是协议规定值。
TCP（区域传送）：DNS 区域传送（Zone Transfer）涉及大量记录数据，需要可靠传输，使用 TCP。DNSSEC 等场景也用 TCP。

因此说“DNS 只使用 TCP”或“只使用 UDP”都是错误的——DNS 根据场景灵活选择。

DNS 的其他特性：用于域名解析（A 正确）、采用客户-服务器模式（B 正确）、支持递归查询与迭代查询（D 正确）。

设计动机： DNS 同时使用 UDP 与 TCP 是典型「按场景选传输层」：日常查询报文小、延迟敏感，默认 UDP/53，免握手；区域传送（AXFR/IXFR）、DNSSEC 大响应、或 UDP 被截断时改用 TCP/53，保证可靠与完整。RFC 规定所有 DNS 服务器必须同时支持 TCP 与 UDP 53。EDNS0 扩展 UDP 载荷并允许更大 UDP 响应，但并未取消 TCP。因此「DNS 只用 TCP」或「只用 UDP」都是错误表述。与 HTTP（主要 TCP）、DHCP（UDP）对比，DNS 是少数「双传输层」应用协议。

工程细节补充： DNS 报文结构含 Header/Question/Answer/Authority/Additional 五段；标志字段区分查询与响应、递归期望等。递归解析器还负责缓存与 TTL 过期淘汰。DoH（DNS over HTTPS，443）与 DoT（DNS over TLS，853）可防中间人篡改解析结果，是零信任接入的常见加固项。排障时若 UDP 53 被拦，客户端可能表现为「网页打不开但 IP 可 ping」。

③ 本题解析　选项 C“只使用 TCP”是错误描述——DNS 既用 UDP 也用 TCP。本题选 C。

④ 选项逐项辨析

A 用于域名解析：DNS 的核心功能，正确。
B 采用客户-服务器模式：DNS 的工作模式，正确。
C 只使用TCP：错误——DNS 查询用 UDP、区域传送用 TCP，不只使用一种。
D 支持递归查询与迭代查询：DNS 支持两种查询方式，正确。

常见误解来源： 以为 DNS 只用 TCP 或只用 UDP；查询常用 UDP，区域传送用 TCP。

⑤ 易混对比

说法	正误	说明
DNS 只使用 TCP	❌	日常查询多为 UDP
DNS 只使用 UDP	❌	区域传送/大响应用 TCP
DNS 默认端口 53（UDP+TCP）	✅	两协议同号端口
DNS 查询必须 TCP	❌	小查询 UDP 更合适
区域传送适合 UDP	❌	数据量大需可靠传输

⑥ 拓展延伸工程实践： 防火墙若只放行 UDP/53 会导致部分区域传送/大响应失败；抓包见 TCP 53 建连时往往对应 AXFR 或 truncated 后重试。DoH/DoT 则把 DNS 封装到 HTTPS/TLS（443/853）。面试追问：①「何时 DNS 走 TCP？」——区域传送、DNSSEC、UDP 截断。②「端口？」——UDP/TCP 均为 53。

⑦ 真题变式　“DNS 区域传送使用什么传输层协议？“→TCP。”DNS 日常查询使用什么协议？“→UDP，端口 53。”DNS 默认端口号？“→53。

⑧ 记忆锚点　“DNS 平时 UDP 快，区域传送 TCP 来”。端口 53 同时监听 TCP 和 UDP，这是 DNS 的独特设计。

⑨ 知识关联：主库题群：第79题（DNS 功能）、第80题（本题错误项=只使用 TCP）、第81-83题（层次/查询/A 记录）构成 DNS 簇；与第64/72（UDP 与端口空间）联动。与补题：补-13（UDP 特性，解释为何查询爱用 UDP）。与面试20题：面试第8题（DNS 解析）、面试第20题（53 端口）。面试追问：①「DNS 只用 UDP 对吗？」——不对。②「如何加固 DNS？」——DNSSEC 签名、DoH/DoT 加密传输。

81. 域名www.tsinghua.edu.cn中，层次最高（最顶级）的是（）。

A. www B. tsinghua C. edu D. cn

答案：D解析：① 考点定位　域名结构层次——识别最高级（最顶级）域名。

② 知识精讲　域名从右向左层次递增，最右边的标签层级最高：

www.tsinghua.edu.cn 中：
- cn = 最顶级（国家顶级域，ccTLD）
- edu = 二级域（教育机构类别）
- tsinghua = 三级域（清华大学机构名）
- www = 主机名（具体服务器，层次最低）

DNS 域名树以根（.）为最上端。解析时从右向左逐级查询：先找根服务器 → 定位 .cn 顶级域服务器 → 再向下定位 .edu.cn → tsinghua.edu.cn → 最终找到 www 主机的 A 记录。

域名树与 FQDN： 把域名想成一棵倒置的树：根是 .（点），其下是顶级域 TLD（cn/com/net），再下是二级、三级……最左边的标签离根最远、层次最低，通常表示具体主机或服务。www.tsinghua.edu.cn 的完整写法其实是 www.tsinghua.edu.cn.（末尾有个根点），称为 FQDN（完全合格域名）。解析顺序从右向左：本地 DNS 到根到 .cn 到 edu.cn 到 tsinghua.edu.cn 权威服务器，取得 www 的 A 记录。易混点：题目问层次最高/最顶级时选最右边的标签（本题为 cn）；问主机名时是最左边。国家顶级域（ccTLD）如 cn/us/jp 与通用顶级域（gTLD）如 com/org 的分类也常一并考查。

设计动机： 域名采用层次树状命名，从右向左层级升高，最右侧标签最接近根（根通常写作 . 且省略）。www.tsinghua.edu.cn 中：cn 为国家顶级域，edu 为二级（教育类），tsinghua 为机构三级域，www 仅为主机名/服务名，层次最低。解析方向与书写方向相反：从根开始自右向左逐级委托。这种设计使全球域名数据可分区授权——每个域只需管理自己区（zone），根服务器只知 TLD 位置，从而支撑互联网规模。考试常见陷阱：把 www 当成最高层，或把书写顺序当成层级顺序。

③ 本题解析　层次最高的是最右边的 cn，对应选项 D。

④ 选项逐项辨析

A www：最左端，是主机名，层次最低，错误。
B tsinghua：三级域，不是最高层，错误。
C edu：二级域，不是最高层，错误。
D cn：国家顶级域，最右边，层次最高，正确。

常见误解来源： 把层次最高答成最左边的 www；域名从右向左层次升高。

⑤ 易混对比

标签	在域名中的位置	层级	类型
www	最左	最低（主机名）	可为任意服务名
tsinghua	左2	三级域	机构名
edu	左3	二级域	类别 gTLD/教育
cn	最右（根前）	最高（顶级）	国家 ccTLD
.（根）	书写中省略	最高权威	根区

⑥ 拓展延伸工程实践： 企业申请域名后可再划分子域（dev.example.com）并委派 NS；证书域名匹配也按 FQDN 精确/通配符规则。面试追问：①「从左到右层级如何变化？」——由低到高（主机→…→TLD）。②「根服务器数量？」——标识 13 组（A–M），实际 anycast 实例遍布全球。

⑦ 真题变式　“域名 mail.ustc.edu.cn 中层次最低的是？”→mail（主机名，最左端；这个域名里并没有 www 标签，别照搬上表）。“顶级域有哪些？”→.com、.cn、.edu 等。

⑧ 记忆锚点　“域名层次从右往左升高”——cn > edu > tsinghua > www。类比“文件路径根在左，域名根在右”。

⑨ 知识关联：主库题群：第79-80、第81题（本题最顶级=cn）、第82-83题构成 DNS 层次/查询簇；与第94题（URL 解析）呼应。与补题：无直接补题。与面试20题：面试第8题（解析过程，从根查起）。面试追问：①「edu.cn 与 edu 谁更高？」——cn 更高。②「为何域名与文件路径方向相反？」——域名树根在右，路径根在左，别按直觉混用。

82. 在DNS迭代查询中，本地域名服务器（）。

A. 必须自己一直查到最终结果 B. 每次把问题交给下一级服务器并等待其最终结果 C. 把问题交给根/顶级服务器，对方只给出下一步线索，本地继续查 D. 只查询本地hosts文件

答案：C解析：① 考点定位　DNS 递归查询与迭代查询的区别——迭代查询中本地域名服务器的行为。

② 知识精讲　DNS 两种查询方式：

递归查询：被查询的服务器必须替查询方“问到底”，返回最终结果（IP 地址或“不存在”）。查询方只需发一次请求，等待最终答案。
迭代查询：被查询的服务器只返回“下一步该去问谁”的线索（如“我不知道，但你可以去问根服务器”），由查询方自己继续逐级询问。

标准 DNS 查询链路：

主机 → 本地域名服务器：通常为递归查询（主机说“帮我查到最终 IP”，本地服务器负责到底）。
本地域名服务器 → 根/顶级/权威服务器：通常为迭代查询（本地服务器逐级询问，每级只给线索不给最终答案，本地服务器根据线索继续查下一级）。

迭代查询中，根/顶级域服务器只给”下一步线索“——这正是选项 C 的描述。

设计动机： 标准 DNS 架构中，主机到本地域名服务器（LDNS）通常是递归查询（「帮我查到最终结果」）；LDNS 到根/顶级/权威服务器通常是迭代查询（对方只回「下一步问谁」）。迭代的意义是可扩展性：若全球查询都让根/TLD 做递归，热点服务器会被压垮；迭代把逐级工作量留在 LDNS，权威服务器只回答自己区内的事实。因此「在迭代查询中，本地域名服务器」的正确描述是：它作为查询方，根据线索依次向根、TLD、权威服务器发起查询，自己汇总最终结果，并缓存以降低后续时延。

③ 本题解析　迭代查询中，本地域名服务器把问题交给根/顶级服务器，对方只给出下一步线索，本地继续查，对应选项 C。

④ 选项逐项辨析

A 必须自己一直查到最终结果：这是递归查询的特征（被查询方负责到底），不是迭代，错误。
B 每次把问题交给下一级服务器并等待其最终结果：仍然是递归思路（等待对方给最终结果），错误。
C 把问题交给根/顶级服务器，对方只给出下一步线索，本地继续查：迭代查询的精确定义，正确。
D 只查询本地 hosts 文件：hosts 文件是本地解析的第一步，但不是迭代查询，错误。

常见误解来源： 把迭代查询说成本地域名服务器必须替客户端问到底（那是递归）。

⑤ 易混对比

方向	常见查询类型	被查询方义务	负载特征
主机 → LDNS	递归	必须给最终结果或失败	LDNS 承担递归压力
LDNS → 根/TLD/权威	迭代	只返回线索/答案	权威压力分散
权威应答	可含 referral	告知下级 NS	与缓存配合

⑥ 拓展延伸工程实践： 公共 DNS（如运营商 LDNS）性能差会导致全站首屏变慢；dig +trace 可完整看到迭代路径。企业 DNS 递归器需限制开放递归，防被当放大攻击跳板。面试追问：①「迭代查询中 LDNS 做什么？」——依次问根/TLD/权威并跟进线索。②「为何根不递归？」——保护热点根/TLD，保证全球可扩展。

⑦ 真题变式　“DNS 递归查询中，被查询服务器的职责是什么？”→替查询方查到底，返回最终结果。“主机到本地 DNS 服务器通常用什么查询？”→递归。“本地 DNS 到根服务器通常用什么查询？”→迭代。

⑧ 记忆锚点　“递归帮你查完，迭代给你线索”。主机→本地DNS递归，本地DNS→上级迭代。

⑨ 知识关联：主库题群：第79-81、第82题（本题迭代中 LDNS 行为）、第83题（记录类型）构成 DNS 查询簇；与第94题（访问流程第一步）。与补题：无直接补题。与面试20题：面试第8题（递归 vs 迭代）。面试追问：①「主机端是递归还是迭代？」——对 LDNS 多为递归。②「缓存放哪一层？」——浏览器、OS、LDNS 均可，受 TTL 约束。

83. DNS中「A」记录用于（）。

A. 主机名→IPv4地址 B. IPv4→主机名 C. 邮件交换器 D. 别名

答案：A解析：① 考点定位　DNS 资源记录类型——A 记录的用途。

② 知识精讲　DNS 资源记录（Resource Record, RR）类型：

记录类型	名称	功能	示例
A	地址记录	主机名 → IPv4 地址	www → 93.184.216.34
AAAA	IPv6 地址记录	主机名 → IPv6 地址	www → 2001:db8::1
PTR	指针记录	IP → 域名（反向解析）	93.184.216.34 → www
MX	邮件交换记录	指定邮件服务器	example.com → mail.example.com
CNAME	别名记录	域名 → 另一个域名	web.example.com → www.example.com
NS	域名服务器记录	指定域的权威DNS服务器	example.com → ns1.example.com
TXT	文本记录	存储任意文本（如SPF、DKIM）	反垃圾邮件配置

A 记录是最常用的 DNS 记录类型——将主机名映射到 IPv4 地址。

A 记录在解析链中的位置： 当递归解析器最终从权威服务器问到 www.example.com 的 A 记录是什么时，得到的是一条资源记录：名字、类型=A、TTL、IPv4 地址。客户端拿到这个 IPv4 后才能发起 TCP 连接。与 A 易混的有：AAAA（IPv6，因为 128 位所以叫四个 A）、CNAME（别名，不能与其它记录共存于同一名字，需再解析目标名）、PTR（反向，从 IP 查域名，常用于反垃圾邮件）。TTL 决定缓存时长，权威改记录后本地缓存可能要等 TTL 过期才生效——这是改了解析怎么还不生效的常见原因。国央企笔试常考 A 记录的作用或把域名映射到 IPv4 的记录类型，答案锁定 A。

③ 本题解析　A 记录用于主机名→IPv4地址，对应选项 A。

④ 选项逐项辨析

A 主机名→IPv4地址：A 记录的标准定义，正确。
B IPv4→主机名：这是 PTR 记录的功能（反向解析），错误。
C 邮件交换器：这是 MX 记录的功能，错误。
D 别名：这是 CNAME 记录的功能，错误。

常见误解来源： 把 A 记录说成域名到 IPv6（那是 AAAA）或域名到域名（CNAME）。

⑤ 易混对比　A vs AAAA：A 记录映射到 IPv4（32 位地址），AAAA 记录映射到 IPv6（128 位地址，“AAAA”比“A”多三个 A 表示 IPv6 地址更长）。A vs PTR：A 是正向（域名→IP），PTR 是反向（IP→域名），互为逆操作。

⑥ 拓展延伸　CNAME 别名记录常用于 CDN 配置——将业务域名（如 cdn.example.com）CNAME 到 CDN 服务商提供的域名（如 example.cdn.net），由 CDN 的 DNS 解析返回最近的边缘节点 IP。这是现代 CDN 加速的基础机制。

⑦ 真题变式　“DNS 中 AAAA 记录用于什么？“→主机名→IPv6 地址。”反向解析用什么记录？“→PTR。”指定邮件服务器用什么记录？“→MX。

⑧ 记忆锚点　“A=IPv4、AAAA=IPv6、PTR=反向、MX=邮件、CNAME=别名、NS=服务器”。六个记录类型一句话记全。

⑨ 知识关联： 主库题群：与第79-82题构成 DNS 题群。与补题：无直接补题。与面试20题：面试第8题（记录类型：A/AAAA/CNAME/MX/NS）。面试追问：①「AAAA 记录是什么？」——IPv6 地址记录（A 是 IPv4）。②「CNAME 和 A 的区别？」——A 直接给 IP；CNAME 给另一个域名，需继续解析；CDN 常用 CNAME 做调度。

84. HTTP协议的特点是（）。

A. 有状态协议 B. 使用UDP传输 C. 无状态、基于TCP、默认端口80 D. 请求方法只有GET

答案：C解析：① 考点定位　HTTP 协议的基本特性——无状态、传输层协议、端口。

② 知识精讲　HTTP（HyperText Transfer Protocol，超文本传输协议）三大核心特性：

无状态协议：服务器不自动记忆客户端的连续请求，每个请求独立处理。这一设计简化了服务器实现、提高了可扩展性，但带来了“无法保持用户登录状态”的问题——通过 Cookie/Session 机制弥补。
基于 TCP 传输：HTTP 基于 TCP（可靠传输），默认端口 80。HTTP/1.0 默认短连接（每次请求建一个 TCP 连接），HTTP/1.1 默认持久连接（keep-alive，多个请求复用同一连接）。
请求方法丰富：GET（获取）、POST（提交）、PUT（更新）、DELETE（删除）、HEAD（只取响应头）、OPTIONS（查询支持的方法）、PATCH（部分更新）等，远不止 GET。

设计动机： HTTP 被设计为简单、可扩展、无状态的应用层协议：无状态使服务器不必为每个客户端维护会话，任意后端实例都可处理请求，水平扩展容易；代价是登录态需 Cookie/Session/Token 补齐。HTTP 建立在 TCP（HTTP/1.x）或 QUIC/UDP（HTTP/3）上，语义上是请求/响应、可缓存、支持条件请求。无状态并不等于「不能有会话」，而是「协议本身不记忆」，状态外置到 Cookie 或令牌。与 FTP 等有状态协议对比，HTTP 更适合互联网规模的分布式服务。

③ 本题解析　HTTP 是无状态、基于 TCP、默认端口 80 的协议，对应选项 C。

④ 选项逐项辨析

A 有状态协议：错误——HTTP 是无状态协议，服务器不自动记忆客户端请求。
B 使用UDP传输：错误——HTTP 基于 TCP（HTTP/3 才用 QUIC/UDP，但不是标准 HTTP）。
C 无状态、基于TCP、默认端口80：三大特性完全匹配，正确。
D 请求方法只有GET：错误——方法有 GET/POST/PUT/DELETE/HEAD/OPTIONS/PATCH 等多种。

常见误解来源： 以为 HTTP 有状态、有连接；HTTP 无状态，持久连接是 HTTP/1.1 可选特性。

⑤ 易混对比

特性	HTTP 含义	带来的能力/问题
无状态	请求相互独立	易扩展；需 Cookie/Session
请求-响应	客户端发起	模型简单；服务器推送需额外机制
基于 TCP（1.x）	可靠字节流	默认 80；握手开销
可缓存	语义支持缓存头	降时延；一致性靠校验器
明文（HTTP）	未加密	窃听/篡改风险 → HTTPS

⑥ 拓展延伸工程实践： 无状态便于 LB 任意转发；会话粘滞（ip_hash）或 Redis 共享 Session 是两种工程方案。JWT 则把状态塞进客户端令牌。面试追问：①「HTTP 无状态如何做登录？」——Cookie/Session 或 Authorization Token。②「HTTP/3 为何还说 HTTP？」——语义沿用，传输变为 QUIC（UDP）。

⑦ 真题变式　“HTTP 是有状态还是无状态协议？“→无状态。”HTTP 默认端口？“→80。”HTTP/1.1 默认使用什么连接方式？“→持久连接（keep-alive）。

⑧ 记忆锚点　“HTTP 无状态 + TCP + 80”三连记。无状态用 Cookie/Session 弥补，是理解 Web 会话机制的基础。

⑨ 知识关联：主库题群：第84题（本题 HTTP 特点）、第85题（方法）、第86-87题（状态码）、第88-89题（Cookie/Session）、第90-92题（HTTPS/演进）构成 HTTP 大簇。与补题：无直接补题（HTTP 细节在面试文件）。与面试20题：面试第9/10/13/14/15/19题（状态码、HTTP/2/3、HTTPS、WebSocket、keep-alive、GET/POST）。面试追问：①「无状态的优缺点？」——扩展性 vs 需外置会话。②「默认端口？」——HTTP 80，HTTPS 443。

85. 以下HTTP请求方法中，用于获取资源的是（）。

A. POST B. PUT C. GET D. DELETE

答案：C解析：① 考点定位　HTTP 请求方法——用于获取资源的方法。

② 知识精讲　HTTP 请求方法（HTTP Verbs）：

方法	用途	安全性	幂等性	参数位置
GET	获取资源	安全	幂等	URL 查询串
POST	提交数据	不安全	非幂等	请求体
PUT	整体更新/创建	不安全	幂等	请求体
DELETE	删除资源	不安全	幂等	URL
HEAD	只取响应头	安全	幂等	URL
OPTIONS	查询支持的方法	安全	幂等	URL
PATCH	部分更新	不安全	非幂等	请求体

安全：不修改服务器上的资源状态。
幂等：重复请求的结果与单次请求相同。

GET 用于获取资源——参数拼在 URL 查询串中（如？name=value），有长度限制（浏览器/服务器限制，通常几 KB），安全且幂等。

设计动机： HTTP 方法把「动词」标准化：GET 获取资源，安全且幂等，可缓存；POST 提交产生副作用的数据，非幂等；PUT 整体更新（幂等）；PATCH 部分更新；DELETE 删除（幂等语义上）；HEAD 同 GET 但无 body；OPTIONS 探询能力。选择 GET 用于获取，是因为中间设备可缓存、可书签、可重复点击不产生额外业务副作用。协议本身不限制 GET 参数长度，但浏览器/服务器实现常限制 URL 长度。REST 架构用方法语义映射 CRUD，减少自造动词。

安全与缓存补充： GET 参数出现在 URL，会进浏览器历史、代理日志与 Referer，敏感信息应避免用 GET 传输；POST 放 body 相对更不易被旁路记录，但也不是加密，仍须 HTTPS。缓存层面：GET 响应可被浏览器/CDN 缓存，需 Cache-Control 控制；副作用接口若误用 GET，可能被预取、爬虫或重试重复触发，违反幂等预期。

③ 本题解析　用于获取资源的 HTTP 请求方法是 GET，对应选项 C。

④ 选项逐项辨析

A POST：用于提交数据（如表单提交），参数在请求体中，非幂等，不是获取资源，错误。
B PUT：用于整体更新/创建资源，幂等，不是获取资源，错误。
C GET：用于获取资源，安全且幂等，参数在 URL 中，正确。
D DELETE：用于删除资源，幂等，不是获取资源，错误。

常见误解来源： 把获取资源答成 POST；GET 才是获取，POST 是提交。

⑤ 易混对比

方法	语义	安全	幂等	典型
GET	读资源	是	是	查询列表/详情
POST	创建/提交	否	否	表单、下单
PUT	整体替换	否	是	更新整资源
PATCH	部分修改	否	视实现	改单个字段
DELETE	删除	否	是（语义）	删资源
HEAD	读元数据	是	是	探活、查长度

⑥ 拓展延伸工程实践： 网关限流/日志常按方法区分写读；CSRF 对非幂等方法更敏感。缓存层默认更积极缓存 GET。面试追问：①「GET 与 POST 本质区别？」——语义（读 vs 写）、幂等、缓存与安全边界，而不只是参数位置。②「GET 能否有 body？」——规范允许但互操作性差，实践不用。

⑦ 真题变式　“用于提交数据的 HTTP 方法？”→POST。“用于删除资源的方法？”→DELETE。“GET 和 POST 的区别？”→参数位置（URL vs 请求体）、安全性、幂等性。

⑧ 记忆锚点　“GET 取、POST 交、PUT 改、DELETE 删“。GET 安全幂等有长度限制。

⑨ 知识关联：主库题群：第84题（HTTP 特点）、第85题（本题 GET）、第86-87题（状态码）、第145题（keep-alive）、第146题（ETag 缓存）构成 HTTP 语义簇。与补题：无直接补题。与面试20题：面试第19题（GET/POST 区别）、面试第9题（状态码）。面试追问：①「GET 幂等含义？」——多次请求资源状态应一致。②「为何搜索常用 GET？」——可分享 URL、可缓存、语义为读。

86. HTTP状态码404表示（）。

A. 请求成功 B. 永久重定向 C. 请求的资源不存在 D. 服务器内部错误

答案：C解析：① 考点定位　HTTP 状态码——404 的含义。

② 知识精讲　HTTP 状态码按首位数字分五大类：

类别	含义	典型状态码
1xx	信息（请求已接收，继续处理）	100 Continue
2xx	成功	200 OK
3xx	重定向	301 永久，302 临时，304 未修改
4xx	客户端错误	400 请求错误，401 未认证，403 禁止，404 资源不存在
5xx	服务器错误	500 内部错误，502 网关错误，503 不可用

404 Not Found：请求的资源在服务器上不存在——可能是 URL 写错、资源已删除、或路由配置错误。这是最常见的客户端错误状态码。

状态码家族怎么记、怎么用： 把五类记成 1 信息、2 成功、3 重定向、4 客户端错、5 服务器错。404 属于 4xx，责任在客户端（URL 错、资源没了），与 403（有资源但无权限）、401（需要认证）要分清；5xx 才是服务器端故障（500 内部错误、502 上游网关坏、503 过载/维护）。3xx 里 301 永久、302/307 临时、304 与缓存协商有关（配合 ETag/Last-Modified，见第 146 题）。排障口诀：先看首位数字定责任方，再看具体码定动作。面试常问 404 和 403 区别、301 和 302 区别、502 和 503 区别，把责任方加是否可重试加缓存语义三点说全即可。

设计动机： 状态码把结果分类到 5 个系列，便于客户端与监控统一处理：1xx 信息、2xx 成功、3xx 重定向、4xx 客户端错误、5xx 服务器错误。404 Not Found 表示服务器找不到请求的资源（路径不存在），属于 4xx——责任通常在 URL、路由或资源已删除，而不是服务器崩溃（那是 5xx）。理解 4xx/5xx 边界对排障至关重要：客户端看到 404 应查 URL；运维看到大量 5xx 才查服务进程。与 403（有权限拒绝）不同，404 有时也被故意返回以避免暴露资源是否存在。

③ 本题解析　404 表示请求的资源不存在，对应选项 C。

④ 选项逐项辨析

A 请求成功：这是 200 OK，不是 404，错误。
B 永久重定向：这是 301，不是 404，错误。
C 请求的资源不存在：这是 404 Not Found，正确。
D 服务器内部错误：这是 500，不是 404，错误。

常见误解来源： 把 404 说成服务器错误；4xx 是客户端错误，404=资源不存在。

⑤ 易混对比

状态码	含义	责任方	常见处理
200	OK 成功	—	正常读 body
301/302	重定向	视场景	跟 Location
404	资源不存在	客户端 URL/路由	检查路径、部署
403	禁止访问	权限	查认证授权
500	服务器内部错误	服务端	看日志与堆栈
502/503	网关错误/不可用	网关或后端	查上游健康

⑥ 拓展延伸工程实践： Nginx 可用自定义 404 页；SPA 路由常配置 try_files 回退 index.html，避免刷新 404。监控把 4xx/5xx 分开告警。面试追问：①「404 与 410？」——404 可能临时找不到；410 表示永久消失。②「404 一定是客户端错吗？」——也可能是发布回滚/路由配置错误，需结合部署看。

⑦ 真题变式　“HTTP 状态码 200 表示什么？”→请求成功。“状态码 500 表示什么？”→服务器内部错误。“401 和 403 的区别？”→401 未认证（需要登录），403 已认证但无权限（服务器拒绝）。

⑧ 记忆锚点　状态码分类口诀“1 信 2 成 3 重 4 客 5 服”。404=资源不存在，是 4xx 客户端错误的代表。

⑨ 知识关联：主库题群：第86题（本题 404）、第87题（301）、第84-85题（HTTP 基础）构成状态码簇；与第92题（HTTP 演进）同属应用层。与补题：无直接补题。与面试20题：面试第9题（常见状态码）。面试追问：①「404 属于哪类错误？」——4xx 客户端/资源侧。②「401 与 403？」——未认证 vs 已认证无权限。

87. HTTP状态码301表示（）。

A. 成功 B. 临时重定向 C. 服务器错误 D. 永久重定向

答案：D解析：① 考点定位　HTTP 状态码——301 的含义（永久重定向）。

② 知识精讲　3xx 系列重定向状态码：

状态码	含义	浏览器行为
301	永久重定向（Moved Permanently）	缓存重定向，下次直接访问新地址
302	临时重定向（Found/Moved Temporarily）	不缓存，下次仍访问原地址
304	未修改（Not Modified）	使用浏览器缓存（条件请求）

301 Moved Permanently：资源已永久迁移到新地址，原地址不再使用。浏览器会缓存该重定向结果——用户下次访问原地址时，浏览器直接跳转到新地址，不再请求原服务器。对 SEO 很重要：搜索引擎会将原 URL 的权重转移到新 URL。

301 常见用途：①域名更换（old.com → new.com）；②HTTP→HTTPS 跳转；③URL 规范化（去除 www 或添加 www）。

设计动机： 301 Moved Permanently 告诉客户端资源已永久换址，并鼓励缓存新的 Location，下次直接访问新地址，减少额外跳转与旧域名权重分散（SEO 上权重转移）。与 302（临时，不鼓励缓存）对比是最高频考点。现代还有 307/308：在重定向时保持请求方法与 body，避免某些客户端把 POST 降成 GET 破坏语义。HTTPS 站点从 HTTP 迁到 HTTPS 时常用 301/308。理解「是否缓存 + 是否保方法」两个维度，可一次记清 301/302/307/308。

SEO 与迁移补充： 域名更换时 301 可把权重导向新域；若误用 302，搜索引擎可能继续给旧域权重。HTTP→HTTPS 迁移推荐 301/308 全站跳转，并配置 HSTS 防降级。链式重定向（A→B→C）会增加首屏时延，应尽量一次跳到位。

③ 本题解析　301 表示永久重定向，对应选项 D。

④ 选项逐项辨析

A 成功：这是 200 OK，不是 301，错误。
B 临时重定向：这是 302 Found，不是 301，错误。
C 服务器错误：这是 5xx 系列，不是 301，错误。
D 永久重定向：301 Moved Permanently，正确。

常见误解来源： 301 与 302 混淆；301 永久、302 临时。

⑤ 易混对比

状态码	永久/临时	缓存重定向	方法保持	典型场景
301	永久	是	实现常不保	域名更换、HTTP→HTTPS
302	临时	否	实现常不保	活动页临时跳转
307	临时	否	是	POST 临跳
308	永久	是	是	HTTPS 迁移且保方法
304	—	—	—	协商缓存命中，无 body

⑥ 拓展延伸工程实践： 切换域名时配置 301 并保留路径与查询串；监控 301 链深度，防重定向环与多次跳转拖慢首屏。CDN/网关统一做 HTTPS 跳转。面试追问：①「301 与 302 核心区别？」——永久 vs 临时，浏览器是否缓存 Location。②「为何还需要 307/308？」——强制保持原 HTTP 方法，保护 POST 语义。

⑦ 真题变式　“HTTP 状态码 302 表示什么？“→临时重定向。”301 和 302 的区别？“→301 永久会缓存（转移 SEO 权重），302 临时不缓存。”304 表示什么？“→未修改，使用浏览器缓存。

⑧ 记忆锚点　“301 永久缓存，302 临时不缓存”。301 转权重，302 不转——SEO 经典辨析。

⑨ 知识关联：主库题群：第86题（404）、第87题（本题 301）、第90-91题（HTTPS 访问流程）构成「状态码与访问」簇。与补题：无直接补题。与面试20题：面试第9题（状态码）、面试第13题（HTTP vs HTTPS 迁移）。面试追问：①「301 浏览器会缓存吗？」——会。②「304 是重定向吗？」——不是，表示资源未修改。

88. 关于Cookie与Session，正确的是（）。

A. Cookie存在服务器端 B. Session存在客户端 C. Cookie存在客户端，Session存在服务器端 D. 两者完全相同

答案：C解析：① 考点定位　Cookie 与 Session 的存储位置——正确描述两者关系。

② 知识精讲　HTTP 是无状态协议，Cookie 和 Session 是两种维持用户状态的机制：

Cookie：服务器通过 Set-Cookie 响应头把数据写到客户端浏览器，浏览器之后每次请求自动携带。大小有限制（约 4KB），存储在浏览器端。适合存储非敏感的标识信息。
Session：会话数据保存在服务器端（内存或数据库中），浏览器只保存一个 SessionID（通常通过 Cookie 传递）。服务器根据 SessionID 查找对应的会话数据。安全性更高（数据不暴露给客户端），但服务器需要维护会话存储。

两者配合工作：服务器创建 Session → 生成 SessionID → 通过 Cookie 下发给浏览器 → 浏览器后续请求自动携带 SessionID → 服务器验证 SessionID 查找会话数据。

设计动机： HTTP 无状态，但业务需要「记住用户」。Cookie 把状态放在客户端，服务器 Set-Cookie 后浏览器每次请求自动携带，实现简单但体积与安全受限（约 4KB，可被用户改）；Session 把状态放在服务器端，浏览器只持 SessionID，安全更好但服务器要共享会话存储（单机内存无法水平扩展，需 Redis 等）。现代无状态 API 更常用 JWT：令牌自包含签名，服务器可不存会话，但吊销较难。设计权衡：Cookie 换简单，Session 换安全与控制，Token 换水平扩展。

③ 本题解析　Cookie 存在客户端，Session 存在服务器端，对应选项 C。

④ 选项逐项辨析

A Cookie 存在服务器端：错误——Cookie 存在客户端浏览器中。
B Session 存在客户端：错误——Session 存在服务器端。
C Cookie 存在客户端，Session 存在服务器端：正确描述了两者的存储位置。
D 两者完全相同：错误——存储位置与机制完全不同。

常见误解来源： 以为 Cookie 存在服务器、Session 存在浏览器；通常相反。

⑤ 易混对比

对比项	Cookie	Session
存储位置	客户端浏览器	服务器端
容量	~4KB	受服务器存储限制
安全性	较低（可被读取/伪造）	较高（ID 无意义）
扩展性	天然分布式	需集中会话存储
传输	每请求自动带	通常经 Cookie/URL 携带 ID
典型用途	偏好、追踪、会话 ID	登录态、购物车细节

⑥ 拓展延伸工程实践： Cookie 务必设 HttpOnly（防 XSS 读）、Secure（仅 HTTPS）、SameSite（防 CSRF）。多实例服务用 Redis Session 或 JWT。面试追问：①「Cookie 与 Session 关系？」——SessionID 常通过 Cookie 传递，二者常配合。②「如何水平扩展 Session？」——外置共享存储或改无状态令牌。

⑦ 真题变式　“Cookie 存储在哪里？“→客户端浏览器。”Session 存储在哪里？“→服务器端。”SessionID 如何传递？“→通常通过 Cookie 下发并在每次请求中携带。

⑧ 记忆锚点　“Cookie 客户端、Session 服务器端”。SessionID 存 Cookie、数据存服务器——理解会话机制的关键。

⑨ 知识关联：主库题群：第84题（HTTP 无状态）、第88题（本题 Cookie/Session）、第89题（Cookie 主作用）构成会话管理簇；与第101-102（签名）、第116（证书）在认证话题上延伸。与补题：无直接补题。与面试20题：面试第19/13题（请求与安全）可延伸到 Cookie 安全属性；面试文件较少专考 Cookie，但工程面常追问。面试追问：①「Cookie 存哪？Session 存哪？」——客户端 vs 服务器。②「HttpOnly 解决什么？」——防脚本偷 Cookie。

89. Cookie的主要作用是（）。

A. 加速静态资源 B. 在无状态的HTTP中标识用户、保持会话状态 C. 防止SQL注入 D. 提高TCP吞吐

答案：B解析：① 考点定位　Cookie 的主要作用——在无状态的 HTTP 中标识用户、保持会话状态。

② 知识精讲　HTTP 是无状态协议——服务器无法天然识别“两次请求是否来自同一用户”。Cookie 的主要作用正是为此而生：

服务器下发 Cookie 标识用户（如 Set-Cookie: sessionid=abc123; HttpOnly; Secure）。
浏览器自动在后续请求中携带 Cookie。
服务器读取 Cookie 识别用户身份，从而在无状态的 HTTP 之上实现会话保持、登录状态记忆、个性化推荐、用户行为统计。

Cookie 的典型应用场景：①登录状态保持（免重复登录）；②购物车记录；③用户偏好设置（语言、主题）；④广告追踪与分析。

Cookie 与无状态 HTTP 的互补： HTTP 协议本身不保存上一次请求是谁，这让服务器实现简单、易水平扩展，但登录态、购物车就无处安放。Cookie 用服务器下发、浏览器保存、之后每次请求自动带回的闭环，在应用层重建了轻量会话上下文。关键属性：HttpOnly 禁止 JS 读取（缓解 XSS 窃取）、Secure 仅 HTTPS 发送、SameSite 限制跨站携带（缓解 CSRF）、Expires/Max-Age 控制生命周期。与 Session 对比：Session 数据在服务端，浏览器只存 Session ID（常放在 Cookie 里）；分布式系统里 Session 常外置到 Redis。现代无状态方案 JWT 则把状态放进自包含令牌。考试问 Cookie 主要作用，标准表述是在无状态 HTTP 上识别用户、保持会话。

③ 本题解析　Cookie 的主要作用是在无状态的 HTTP 中标识用户、保持会话状态，对应选项 B。

④ 选项逐项辨析

A 加速静态资源：这是缓存机制（浏览器缓存/CDN）的职责，不是 Cookie 的作用，错误。
B 在无状态的HTTP中标识用户、保持会话状态：Cookie 的核心功能——弥补 HTTP 无状态缺陷，正确。
C 防止SQL注入：这是后端输入校验/参数化查询的职责，与 Cookie 无关，错误。
D 提高TCP吞吐：Cookie 是 HTTP 层机制，与 TCP 吞吐无关，错误。

常见误解来源： 把 Cookie 主要作用说成加密数据；Cookie 主要用于识别用户/保持会话。

⑤ 易混对比　Cookie vs Token（JWT）：Cookie 是浏览器原生的状态保持机制，与浏览器紧耦合；Token（如 JWT）是应用层方案，Token 可存在 localStorage/Cookie 中，但验证逻辑在应用层完成。Cookie+Session 是传统方案，Token 是现代无状态方案（微服务/SPA 场景常用）。

⑥ 拓展延伸　Cookie 安全属性（安全笔试常考）：

HttpOnly：设置后 JavaScript 无法通过 document.cookie 读取，防止 XSS 攻击窃取 Cookie。
Secure：设置后仅通过 HTTPS 传输，防止中间人窃听。
SameSite=Strict/Lax：限制跨站请求携带 Cookie，防止 CSRF 攻击。
Domain/Path：限制 Cookie 的作用域范围。
Max-Age/Expires：控制 Cookie 生命周期。

⑦ 真题变式　“Cookie 的 HttpOnly 属性有什么作用？“→禁止 JavaScript 读取 Cookie，防 XSS。”Cookie 的 Secure 属性有什么作用？“→仅通过 HTTPS 传输 Cookie。”HTTP 无状态如何解决？“→通过 Cookie/Session/Token 机制。

⑧ 记忆锚点　“Cookie 弥补 HTTP 无状态”——标识用户、保持会话。安全三件套：HttpOnly（防 XSS）、Secure（防窃听）、SameSite（防 CSRF）。

⑨ 知识关联： 主库题群：与第88题（Cookie/Session）构成双连。与补题：无直接补题。与面试20题：无直接对应。面试追问：①「Cookie 怎么解决 HTTP 无状态？」——服务器 Set-Cookie 下发，浏览器后续请求自动携带 Cookie，服务器据此识别用户。②「Cookie 大小有限制吗？」——单个约 4KB，每个域名下的 Cookie 数量也有限制（各浏览器不同）。

90. 访问https://www.example.com 的正确基本流程是（）。

A. DNS解析→TCP连接→TLS握手→HTTP请求→HTTP响应→页面渲染 B. TCP连接→DNS解析→HTTP请求→HTTP响应→页面渲染 C. HTTP请求→DNS解析→TCP连接→HTTP响应 D. DNS解析→HTTP请求→TCP连接→TLS握手

答案：A解析：① 考点定位　HTTPS 访问完整流程——从输入 URL 到页面渲染的正确顺序。

② 知识精讲　访问 https://www.example.com 的完整流程（按时间顺序）：

DNS 解析：浏览器查询 www.example.com 的 IP 地址（先查浏览器缓存→OS缓存→hosts→本地DNS→递归/迭代查询）。
TCP 三次握手：浏览器与服务器 IP 的 443 端口建立 TCP 连接。
TLS 握手：在 TCP 连接之上进行 TLS 握手——协商加密算法与密码套件、验证服务器数字证书、安全交换会话密钥。
HTTP 请求：构造 HTTP 请求报文（如 GET /），加密后通过 TLS 隧道发送。
HTTP 响应：服务器处理请求，返回响应（如 200 OK + HTML），加密后通过 TLS 隧道返回。
页面渲染：浏览器解析 HTML/CSS/JS，构建 DOM 树和渲染树，布局并绘制页面。

若访问的是 HTTP（非 HTTPS），则无第 3 步 TLS 握手。

③ 本题解析　正确流程是 DNS解析→TCP连接→TLS握手→HTTP请求→HTTP响应→页面渲染，对应选项 A。

④ 选项逐项辨析

A DNS解析→TCP连接→TLS握手→HTTP请求→HTTP响应→页面渲染：完整正确的 HTTPS 访问流程，正确。
B TCP连接→DNS解析→...：顺序错误——必须先 DNS 解析拿到 IP 才能建立 TCP 连接。
C HTTP请求→DNS解析→...：HTTP 请求不可能在 DNS 解析和 TCP 连接之前，严重错误。
D DNS解析→HTTP请求→TCP连接→TLS握手：缺少 TCP 连接在 HTTP 请求之前、TLS 在 TCP 之后，顺序混乱，错误。

常见误解来源： HTTPS 流程中漏掉 TLS 握手或把 DNS 放在 TCP 之后；正确顺序 DNS→TCP→TLS→HTTP。

⑤ 易混对比　HTTPS vs HTTP 访问流程差异：

HTTP：DNS → TCP 三次握手 → HTTP 请求/响应 → 渲染
HTTPS：DNS → TCP 三次握手 → TLS 握手 → HTTP 请求/响应（加密） → 渲染

唯一区别是 HTTPS 多了 TLS 握手步骤，在 TCP 连接建立之后、HTTP 通信之前。

⑥ 拓展延伸　DNS 解析本身也可能被优化：浏览器 DNS 预解析（dns-prefetch）可以在用户点击链接前提前解析域名，减少等待时间。HTTP/2 的 Server Push 可以在 HTML 引用 CSS/JS 之前主动推送这些资源，减少往返延迟。QUIC（HTTP/3）将 TLS 握手与传输握手合并为一次，进一步优化延迟。

⑦ 真题变式　“HTTP（非 HTTPS）的访问流程？“→DNS→TCP→HTTP请求/响应→渲染（无 TLS 握手）。”TLS 握手在什么之后？“→TCP 三次握手之后。”DNS 解析在什么之前？“→TCP 连接之前（需要 IP 才能建连接）。

⑧ 记忆锚点　全流程口诀”DNS→TCP→TLS→HTTP→渲染“。HTTPS 比 HTTP 多一步 TLS 握手——位于 TCP 之后、HTTP 之前。

⑨ 知识关联： 主库题群：与第91题（HTTPS 端口）、第94题（最先动作 DNS）、第124题（协议顺序）构成「访问过程」题群。与补题：无直接补题。与面试20题：面试第7题（从输入 URL 到页面展示的完整过程，热度 609）、第11题（HTTPS 握手）。面试追问：①「DNS 在 TCP 之前还是之后？」——之前，必须先解析出 IP 才能建连。②「TLS 在哪一步？」——TCP 三次握手之后、HTTP 请求之前。

91. HTTPS默认端口及组成是（）。

A. 80，HTTP+TCP B. 443，HTTP+SSL/TLS C. 8080，HTTP+UDP D. 443，HTTP+UDP

答案：B解析：① 考点定位　HTTPS 的默认端口和组成。

② 知识精讲　HTTPS = HTTP + SSL/TLS：

默认端口：443（HTTP 是 80）。
组成：在 TCP 之上、HTTP 之下增加一层 TLS（Transport Layer Security）安全协议。
三大安全保障：
1. 数据加密（保密性）：对称加密传输应用数据，防止窃听。
2. 完整性校验：MAC/HMAC 防止数据被篡改。
3. 身份认证：数字证书验证服务器身份，防止冒充。

HTTPS 的协议栈层次：HTTP（应用层）→ TLS（安全层）→ TCP（传输层）→ IP（网络层）。TLS 负责加密 HTTP 报文后再交给 TCP 传输。

注意：HTTPS 仍然基于 TCP。HTTP/3 基于 QUIC（UDP 之上）是另一回事——QUIC 自带加密（集成 TLS 1.3），但不叫传统意义上的 HTTPS over TCP。

HTTPS 的三件套与端口 443： 记住 HTTPS = HTTP + TLS，而不是换了端口的 HTTP。TLS 提供：加密（对称算法保护数据机密性）、完整性（AEAD/MAC 防篡改）、认证（数字证书把公钥绑定到域名，防冒充）。握手阶段用非对称（或 (EC)DHE）协商出对称会话密钥，之后全部用对称加密，这就是混合加密。默认端口 443 由 IANA 分配，中间设备普遍放行；HTTP/3 与 QUIC 虽也提供 HTTPS 语义，但跑在 UDP 443 上且集成了 TLS 1.3，与传统 TCP+TLS+HTTP 栈不同。易错点：说 HTTPS 用非对称加密传数据——错，数据面是对称；说 HTTPS 不需要证书——错，公钥基础设施是身份认证的前提。

③ 本题解析　HTTPS 默认端口 443，组成为 HTTP+SSL/TLS，对应选项 B。

④ 选项逐项辨析

A 80，HTTP+TCP：80 是 HTTP 端口，缺少 TLS 安全层，描述的是 HTTP 而非 HTTPS，错误。
B 443，HTTP+SSL/TLS：443 端口 + HTTP 在 TLS 之上，完全正确。
C 8080，HTTP+UDP：8080 是 HTTP 常用备用端口，且 HTTPS 基于 TCP 不是 UDP，错误。
D 443，HTTP+UDP：端口正确但传输层错误——HTTPS 基于 TCP，不是 UDP，错误。

常见误解来源： 以为 HTTPS 端口是 80 或「HTTPS=HTTP+非对称加密传数据」；端口 443，数据面对称加密。

⑤ 易混对比　HTTP vs HTTPS 对比：

对比项	HTTP	HTTPS
端口	80	443
安全层	无	SSL/TLS
加密	无	对称加密
认证	无	数字证书
传输层	TCP	TCP（+TLS）

⑥ 拓展延伸　TLS 握手简要流程（TLS 1.2）：①ClientHello（支持的加密套件+随机数）→②ServerHello+证书+公钥→③客户端验证证书→生成预主密钥→用服务器公钥加密发送→④双方基于三个随机数生成会话密钥→⑤后续用对称加密通信。TLS 1.3 简化为 1-RTT 甚至 0-RTT，大幅提升握手效率。

⑦ 真题变式　“HTTPS 的默认端口？”→443。“HTTPS 在 TCP 和 HTTP 之间增加了什么？”→SSL/TLS 安全层。“HTTPS 提供哪三大安全保障？”→加密（保密性）、完整性校验、身份认证。

⑧ 记忆锚点　“443=HTTPS=HTTP+TLS，底层仍是 TCP”。区分 HTTPS（TCP+TLS）与 HTTP/3（QUIC/UDP）。

⑨ 知识关联： 主库题群：与第74题（443）、第90题（HTTPS 流程）构成 HTTPS 题群。与补题：无直接补题。与面试20题：面试第11题（HTTPS 握手）、第13题（HTTP vs HTTPS）。面试追问：①「HTTPS 由哪两部分组成？」——HTTP + TLS/SSL。②「HTTPS 端口一定是 443 吗？」——默认是，可配置其他端口；端口不是安全性的来源。

92. 关于HTTP/1.1、HTTP/2、HTTP/3，正确的是（）。

A. HTTP/2基于TCP B. HTTP/1.1原生支持多路复用 C. HTTP/3基于TCP D. HTTP/2不支持头部压缩

答案：A解析：① 考点定位　HTTP/1.1、HTTP/2、HTTP/3 的演进——找出正确描述。

② 知识精讲　HTTP 协议三个版本对比：

特性	HTTP/1.1	HTTP/2	HTTP/3
传输层	TCP	TCP	QUIC（UDP）
持久连接	默认持久（keep-alive）	默认持久	默认持久
多路复用	无（管线化有限）	有（二进制分帧）	有
头部压缩	无	HPACK	QPACK
队头阻塞	严重（应用层+TCP层）	TCP 层仍有	根治
服务器推送	无	有	有

HTTP/1.1：默认持久连接，支持管线化但队头阻塞严重，无多路复用——多个资源需要多个 TCP 连接或串行请求。
HTTP/2：基于 TCP，引入二进制分帧、多路复用（一个 TCP 连接并发多个请求）、HPACK 头部压缩、服务器推送。但 TCP 层的队头阻塞仍存在（一个包丢失阻塞整个连接）。
HTTP/3：改为基于 QUIC（UDP），彻底解决 TCP 队头阻塞（不同流之间互不影响），连接迁移更平滑（QUIC 连接 ID 不依赖 IP）。

③ 本题解析　选项 A“HTTP/2 基于 TCP“是正确描述。本题选 A。

④ 选项逐项辨析

A HTTP/2基于TCP：正确——HTTP/2 基于 TCP（与 HTTP/1.1 相同），在 TCP 之上引入二进制分帧和多路复用。
B HTTP/1.1原生支持多路复用：错误——多路复用是 HTTP/2 引入的，HTTP/1.1 只有管线化（且有限）。
C HTTP/3基于TCP：错误——HTTP/3 基于 QUIC（UDP 之上），不是 TCP。
D HTTP/2不支持头部压缩：错误——HPACK 头部压缩是 HTTP/2 的核心特性之一。

常见误解来源： 以为 HTTP/3 基于 TCP；HTTP/3 基于 QUIC/UDP。

⑤ 易混对比　三个版本的传输层变化是核心考点：HTTP/1.1→TCP、HTTP/2→TCP、HTTP/3→QUIC(UDP)。HTTP/3 放弃 TCP 是因为 TCP 层队头阻塞无法在 HTTP/2 中解决——虽然 HTTP/2 在应用层有多路复用，但 TCP 一旦丢包，整个连接的所有流都被阻塞。QUIC 将多路复用下移到 UDP 之上，各流独立重传。

⑥ 拓展延伸　HTTP/3 的 QUIC 协议自带 TLS 1.3 加密，将传输握手与加密握手合并为一次（1-RTT 甚至 0-RTT），比 HTTPS（TCP 握手 + TLS 握手）更快。QUIC 还支持连接迁移——手机从 WiFi 切到 4G 时 IP 变了但 QUIC 连接 ID 不变，连接不会断开（TCP 会断开重连）。

⑦ 真题变式　“HTTP/2 引入了哪些特性？”→二进制分帧、多路复用、HPACK 头部压缩、服务器推送。“HTTP/3 基于什么传输层协议？”→QUIC（UDP 之上）。“HTTP/1.1 和 HTTP/2 都基于 TCP，为什么还要 HTTP/3？”→解决 TCP 层的队头阻塞。

⑧ 记忆锚点　演进主线“1.1 无多路复用 → 2 多路复用但 TCP 队头阻塞 → 3 上 QUIC 根治”。HTTP/2 基于 TCP，HTTP/3 基于 UDP（QUIC）。

⑨ 知识关联： 主库题群：与第84题（HTTP 特点）、第145题（keep-alive）构成 HTTP 演进题群。与补题：无直接补题。与面试20题：面试第10题（HTTP/1.1→2→3 演进，热度 297/284）。面试追问：①「HTTP/2 解决了什么队头阻塞？」——应用层队头阻塞（多路复用）；TCP 层队头阻塞仍在。②「HTTP/3 为什么用 UDP？」——QUIC 在 UDP 上实现可靠传输与多流独立，彻底解决传输层队头阻塞。

93. 下列不属于应用层协议的是（）。

A. HTTP B. IP C. FTP D. DNS

答案：B解析：① 考点定位　协议层次归属——找出不属于应用层的协议。

② 知识精讲　OSI/TCP-IP 模型各层代表协议：

层次	代表协议
应用层	HTTP, HTTPS, FTP, DNS, SMTP, POP3, IMAP, SSH, Telnet, DHCP, SNMP
传输层	TCP, UDP
网络层	IP, ICMP, ARP, OSPF, BGP, IPsec
数据链路层	PPP, Ethernet (IEEE 802.3), HDLC
物理层	RS-232，各种物理介质规范

IP（Internet Protocol） 是网络层的核心协议，负责分组寻址与转发——为数据包分配 IP 地址、根据路由表转发到下一跳。IP 不属于应用层。

判断协议层次的方法论： 不要死记每一层的协议名单，先问三个问题：1)是否直接为应用程序提供消息语义（URL、状态码、方法）→ 应用层；2)是否在两台主机进程之间提供端口复用/可靠字节流 → 传输层；3)是否负责全局寻址与路由转发 → 网络层；4)是否只在相邻节点间成帧、用 MAC → 数据链路层。IP 明显回答全球寻址加路由器查表转发，属网络层。ICMP、ARP 虽有争议，但按谢希仁教材均归网络层（ARP 也有人归链路层，考试以教材为准）。PPP、以太网是链路层；RS-232 是物理层接口标准。本题若选项混入 IP，就是考 IP 不在应用层这一条。

设计动机： 判断协议层次不能看「名字里有没有 IP/网络」，而要看它直接为谁提供服务、完成什么功能。应用层协议直接支撑应用程序进程间语义（HTTP、DNS、SMTP…）；网络层协议负责主机到主机的分组转发与控制（IP、ICMP、路由协议）；传输层负责进程到进程（TCP/UDP）；链路层负责相邻节点成帧（Ethernet、PPP）。IP 虽被天天提及，但它是网络层的核心协议，不是应用层。ICMP 承载于 IP，功能是网络层差错/控制，通常归网络层。考试策略：先把选项协议归类到「应用/传输/网络/链路」，再排除非应用层项。

③ 本题解析　IP 属于网络层，不属于应用层，对应选项 B。

④ 选项逐项辨析

A HTTP：典型的应用层协议（超文本传输），正确归属。
B IP：网络层协议，不属于应用层，是本题答案。
C FTP：应用层协议（文件传输），正确归属。
D DNS：应用层协议（域名解析），正确归属。

常见误解来源： 把 IP 当应用层协议；IP 是网络层。

⑤ 易混对比

协议	层次	一句话功能
HTTP/HTTPS/DNS/SMTP/FTP	应用层	为应用进程提供直接服务
TCP/UDP	传输层	进程间端到端传输
IP/ICMP/OSPF/BGP	网络层	寻址、路由、控制
Ethernet/PPP/HDLC	数据链路层	相邻节点成帧与介质访问
（易混）ARP	网络/链路边界	IP→MAC，教材常归网络层

⑥ 拓展延伸工程实践： 抓包分层过滤：http/dns 是应用层显示过滤器；ip 是网络层；tcp/udp 传输层；eth 链路层。防火墙策略也常按层设计（L3/L4 ACL vs L7 WAF）。面试追问：①「ICMP 属于哪层？」——网络层控制协议。②「ping 用什么协议？」——ICMP Echo Request/Reply，不是 TCP 也不是应用层 HTTP。

⑦ 真题变式　“以下哪个是传输层协议？A. HTTP B. IP C. TCP D. FTP”→C（TCP 是传输层）。”ARP 属于哪一层？“网络层/数据链路层边界。”ICMP 属于哪一层？“→网络层。

⑧ 记忆锚点　层次归属速查”IP 网络层、TCP/UDP 传输层、HTTP/FTP/DNS/SMTP 应用层“。看到”不属于应用层“优先怀疑 IP。

⑨ 知识关联：主库题群：第1-7题（体系结构分层）、第93题（本题协议层次归属）、第34-39题（ARP/ICMP）、第129题（设备工作层次）构成「层次归属」题群。与补题：补-05（PPP，链路层）、补-16（SNMP 网管，应用层）。与面试20题：面试第17题（TCP/IP 协议栈分层与各层协议）。面试追问：①「IP 是应用层吗？」——不是，网络层。②「如何快速判断协议层次？」——看服务对象：应用进程=应用层；主机互通=网络层。

94. 在Web浏览器中输入URL后，最先进行的是（）。

A. TCP三次握手 B. TLS握手 C. 发送HTTP GET D. DNS域名解析

答案：D解析：① 考点定位　浏览器输入 URL 后最先进行的操作。

② 知识精讲　在浏览器输入 URL 回车后，最先进行的是 DNS 域名解析：

完整时序：

DNS 域名解析（最先）：将域名解析为 IP 地址。先查浏览器 DNS 缓存→OS DNS 缓存→hosts 文件→本地域名服务器（递归）→根/顶级/权威（迭代）。只有命中缓存时才能跳过网络查询。
TCP 三次握手：使用解析到的 IP 建立到服务器 80/443 端口的 TCP 连接。
TLS 握手（仅 HTTPS）：在 TCP 连接之上进行 TLS 握手。
发送 HTTP 请求（如 GET /）。
接收 HTTP 响应。
浏览器渲染页面。

DNS 必须最先执行——因为 TCP 连接需要目标 IP 地址，HTTP 请求需要 TCP 连接，一切的前提是”知道服务器的 IP”。浏览器可能命中 DNS 缓存（跳过网络查询），但 DNS 解析这一步始终是第一步。

设计动机： 输入 URL 回车后最先进行 DNS 域名解析——在不知道服务器 IP 之前，无法建立 TCP，更谈不上 TLS 与 HTTP。完整时序：DNS → TCP 三次握手（443/80）→（HTTPS）TLS 握手 → 发送 HTTP 请求 → 服务器响应 → 浏览器解析渲染。若域名已缓存，DNS 可近乎零耗时，但逻辑上仍是第一步。面试要求能按顺序口述，并说明每步失败的表现（DNS 失败→域名解析错误；TCP 失败→无法连接；TLS 失败→证书错误；HTTP 4xx/5xx→应用层错误）。

性能视角补充： 真实访问耗时常被 DNS 与 TLS 握手占据；优化手段包括 DNS 缓存与预解析、TCP Fast Open、TLS1.3 1-RTT/0-RTT、HTTP/2 多路复用、资源预连接。监控上分别统计 DNS 耗时、TCP 建连耗时、TLS 耗时、TTFB，才能定位慢在「查名字」还是「建连接」还是「服务器处理」。

③ 本题解析　最先进行的是 DNS 域名解析，对应选项 D。

④ 选项逐项辨析

A TCP三次握手：依赖 IP 地址，必须在 DNS 解析之后，不是最先，错误。
B TLS握手：更靠后——在 TCP 连接建立之后，不是最先，错误。
C 发送HTTP GET：在 TCP 连接（和 TLS 握手）之后，不是最先，错误。
D DNS域名解析：第一步——需要 IP 才能建立 TCP 连接，正确。

常见误解来源： 以为最先建立 TCP 连接；没有 IP 前无法建连，最先应是 DNS 解析。

⑤ 易混对比

顺序	步骤	失败典型现象
1	DNS 解析	无法解析域名 / NXDOMAIN
2	TCP 握手	连接超时/拒绝
3	TLS 握手（HTTPS）	证书错误、协议不匹配
4	HTTP 请求/响应	404/500 等状态码
5	浏览器渲染	白屏、资源 404、JS 错误

⑥ 拓展延伸工程实践： 首屏优化常用 dns-prefetch/preconnect；抓包可先看 DNS 再看 Client Hello。HTTPDNS 可绕过 LocalDNS 劫持。面试追问：①「为什么 DNS 在 TCP 前？」——必须先解析出 IP。②「HTTPS 比 HTTP 多什么步骤？」——TLS 握手（证书校验、密钥协商）。

⑦ 真题变式　“DNS 解析之后下一步是什么？“→TCP 三次握手。”TLS 握手在什么之后？“→TCP 连接建立之后。”如果 DNS 缓存命中，还会进行网络查询吗？“→不会，直接使用缓存的 IP。

⑧ 记忆锚点　”第一步永远是 DNS（除非有缓存）“。全流程 DNS→TCP→TLS→HTTP→渲染。

⑨ 知识关联：主库题群：第79题（DNS）、第90题（https 访问流程）、第94题（本题最先=DNS）、第124题（协议顺序较合理）构成「访问过程」簇。与补题：无直接补题。与面试20题：面试第7题（从输入 URL 到页面展示，核心必考）、面试第8题（DNS）。面试追问：①「完整顺序口述？」——DNS→TCP→TLS→HTTP→渲染。②「DNS 已缓存还算第一步吗？」——逻辑上仍是解析，只是跳过网络查询。

95. 802.11b使用的频段与最高速率约为（）。

A. 2.4GHz，11Mbps B. 5GHz，54Mbps C. 2.4GHz，54Mbps D. 5GHz，11Mbps

答案：A解析：① 考点定位　IEEE 802.11 无线局域网标准——802.11b 的频段与速率。

② 知识精讲　IEEE 802.11 系列无线局域网标准：

标准	频段	最高速率	特点
802.11b	2.4GHz	11Mbps	早期标准，兼容性好
802.11a	5GHz	54Mbps	5GHz 穿墙弱，干扰少
802.11g	2.4GHz	54Mbps	兼容 802.11b，速率提升
802.11n（WiFi 4）	2.4/5GHz	600Mbps	引入 MIMO 多天线
802.11ac（WiFi 5）	5GHz	Gbps级	高吞吐
802.11ax（WiFi 6）	2.4/5GHz	更高	效率大幅提升，OFDMA

802.11b：使用 2.4GHz ISM 频段，最高速率 11Mbps，是最早广泛部署的 Wi-Fi 标准。2.4GHz 频段穿透性好但干扰多（微波炉、蓝牙等共用）。

802.11 代际与 2.4GHz 的取舍： 802.11b 是第一代大规模商用 Wi-Fi，2.4GHz ISM 频段、最高 11Mbps，穿透较好但只有 2.4GHz 全球较通用、且与蓝牙/微波炉/Zigbee 共频段，干扰大、不重叠信道少（典型 1/6/11）。后续 a/g/n/ac/ax 在频段、调制、MIMO、OFDMA 上演进，速率从 54Mbps 到 Gbps 级。考试高频三连：b=2.4G/11M、a=5G/54M、g=2.4G/54M；n 开始双频与 MIMO。安全上从 WEP 到 WPA 到 WPA2 到 WPA3（见第 97 题）。若题干强调早期、2.4GHz、约 11Mbps，答案就是 802.11b，不要被后面的 ac/ax 高速率干扰。

③ 本题解析　802.11b 使用 2.4GHz 频段，最高速率约 11Mbps，对应选项 A。

④ 选项逐项辨析

A 2.4GHz，11Mbps：802.11b 的标准参数，正确。
B 5GHz，54Mbps：这是 802.11a 的参数，不是 802.11b，错误。
C 2.4GHz，54Mbps：这是 802.11g 的参数，不是 802.11b，错误。
D 5GHz，11Mbps：这个组合不存在——5GHz 的 802.11a 速率是 54Mbps，错误。

常见误解来源： 把 802.11b 的速率记成 54Mbps（那是 a/g）；b 是 11Mbps、2.4GHz。

⑤ 易混对比　三个早期标准容易混淆，记忆方法——“b=2.4G 11M（最早最慢）、a=5G 54M（快但穿墙差）、g=2.4G 54M（兼容b且快）”。b 和 g 都在 2.4GHz，但 g 比 b 快；a 在 5GHz 独立。

⑥ 拓展延伸　WiFi 版本命名（WiFi Alliance 商业命名）：802.11n = WiFi 4、802.11ac = WiFi 5、802.11ax = WiFi 6、802.11be = WiFi 7（下一代）。WiFi 6 引入 OFDMA（正交频分多址）和 BSS 着色技术，在密集环境中效率大幅提升。2.4GHz 频段只有 3 个不重叠信道（1/6/11），5GHz 有更多信道，干扰更少。

⑦ 真题变式　“802.11a 使用的频段和速率？“→5GHz, 54Mbps。”802.11g 使用的频段和速率？“→2.4GHz, 54Mbps。”WiFi 6 对应哪个标准？“→802.11ax。

⑧ 记忆锚点　“b=2.4G 11M、a=5G 54M、g=2.4G 54M”。口诀”b 最早最慢、a 五G 五四、g 兼容快“。

⑨ 知识关联： 主库题群：与第96题（CSMA/CA）、第97题（Wi-Fi 安全）构成「无线局域网」题群。与补题：无直接补题。与面试20题：无直接对应。面试追问：①「802.11a/b/g/n/ac/ax 的速率演进？」——a=54M(5GHz), b=11M(2.4GHz), g=54M(2.4GHz), n=600M(MIMO), ac=6.9G(5GHz), ax=9.6G(Wi-Fi 6)。②「为什么 2.4GHz 穿墙好但速度慢？」——频率低、绕射强、带宽窄、干扰多（蓝牙/微波炉也在 2.4GHz）。

96. 无线局域网CSMA/CA中的CA表示（）。

A. 冲突检测 B. 冲突避免 C. 载波监听 D. 信道分配

答案：B解析：① 考点定位　CSMA/CA 中 CA 的含义——与 CSMA/CD 区分。

② 知识精讲　CSMA/CA vs CSMA/CD：

机制	全称	CA/CD 含义	适用环境	核心策略
CSMA/CA	载波监听多点接入/冲突避免	冲突避免	无线局域网	发送前随机退避+RTS/CTS预约
CSMA/CD	载波监听多点接入/冲突检测	冲突检测	有线以太网	边发边听，检测到冲突立即停止

CA = Collision Avoidance（冲突避免）。无线环境使用 CSMA/CA 而非 CSMA/CD 的原因：

隐蔽站问题：两站都听不到对方（被障碍物遮挡），但都能同时向 AP 发送，冲突不可避免——无法”检测“到对方在发。
无线信号衰减：无线信号无法像有线那样”边发边听“可靠检测冲突（发送时自身信号远强于接收信号，无法同时收发）。
因此无线改为发送前先随机退避（等待随机时间后再发），可选用 RTS/CTS 机制预约信道来尽量避免冲突发生，而非检测后重传。

③ 本题解析　CSMA/CA 中 CA 表示冲突避免，对应选项 B。

④ 选项逐项辨析

A 冲突检测：这是 CD（CSMA/CD）的含义，用于有线以太网，不是 CA，错误。
B 冲突避免：CA 的含义——无线局域网在发送前避免冲突，正确。
C 载波监听：这是 CS（Carrier Sense）的含义，不是 CA，错误。
D 信道分配：这是 TDMA/FDMA 等机制的策略，与 CSMA/CA 无关，错误。

常见误解来源： 把 CA 说成 Collision Avoidance 的「检测」；CA 是避免，不是检测冲突。

⑤ 易混对比　CSMA/CA（无线）vs CSMA/CD（有线）是经典对比：

对比项	CSMA/CD（有线）	CSMA/CA（无线）
策略	边发边听，检测冲突	发前退避，避免冲突
原因	有线可同时收发	无线不能同时收发（半双工）
隐蔽站	不存在	存在（关键原因）
RTS/CTS	不需要	可选预约机制
适用	以太网 IEEE 802.3	Wi-Fi IEEE 802.11

⑥ 拓展延伸　CSMA/CA 的 RTS/CTS 机制：发送方先发 RTS（Request To Send）给 AP，AP 回 CTS（Clear To Send）广播给所有站点，收到 CTS 的其他站点在发送方传输期间保持静默。这解决了隐蔽站问题——虽然 A 听不到 B，但都能听到 AP 的 CTS，从而避免同时发送导致冲突。代价是 RTS/CTS 本身有开销，短数据不划算。

⑦ 真题变式　”以太网使用什么介质访问控制协议？“→CSMA/CD。”CSMA/CD 中 CD 的含义？“→冲突检测。”为什么无线局域网用 CSMA/CA 而非 CSMA/CD？“→隐蔽站问题+无线无法同时收发可靠检测冲突。

⑧ 记忆锚点　”有线 CD 检测、无线 CA 避免“。无线因隐蔽站问题无法可靠检测冲突，只能事前避免。

⑨ 知识关联： 主库题群：与第95题（802.11b）、第97题（Wi-Fi 安全）构成无线题群。与补题：无直接补题。与面试20题：无直接对应。面试追问：①「CSMA/CA 和 CSMA/CD 的区别？」——CD 有线、边发边听检测冲突；CA 无线、不能边发边听（隐蔽站问题），改为冲突避免（RTS/CTS、ACK）。②「为什么无线不能用 CSMA/CD？」——无线网卡发收功率差异大，发送时收不到其他信号；且有隐蔽站/暴露站问题。

97. 无线安全协议按安全性从低到高排序正确的是（）。

A. WEP→WPA→WPA2→WPA3 B. WPA→WEP→WPA3→WPA2 C. WPA2→WPA→WEP→WPA3 D. WEP→WPA2→WPA→WPA3

答案：A解析：① 考点定位　Wi-Fi 安全协议的演进——按安全性从低到高排序。

② 知识精讲　Wi-Fi 安全协议按时间与强度排序（从低到高）：

协议	加密算法	安全性	特点
WEP	RC4（静态密钥）	最弱	已可被轻易破解，几分钟内可破
WPA	RC4+TKIP（动态密钥）	较弱	修补 WEP 缺陷，引入逐包密钥
WPA2	AES-CCMP	较强	多年主流标准，KRACK 攻击后仍较安全
WPA3	AES + SAE	最强	抗离线字典攻击，前向保密

WEP（Wired Equivalent Privacy）：使用 RC4 流加密，静态密钥（所有设备共用一个密钥），IV 太短（24位），几分钟内可被破解。已废弃。
WPA（Wi-Fi Protected Access）：临时方案，引入 TKIP（Temporal Key Integrity Protocol），每包动态密钥+完整性校验，修补 WEP 致命缺陷但仍基于 RC4。
WPA2：改用 AES-CCMP（Counter Mode with CBC-MAC Protocol），安全性大幅提升，是多年来的主流标准。2017 年 KRACK 攻击发现漏洞但已修补。
WPA3：引入 SAE（Simultaneous Authentication of Equals）握手替代 WPA2 的 PSK 四次握手，抵抗离线字典攻击（WPA2 可被离线暴力破解），提供前向保密（即使密钥泄露，之前通信不可解密）。

安全强度逐级递增：WEP < WPA < WPA2 < WPA3。

③ 本题解析　安全性从低到高正确排序是 WEP→WPA→WPA2→WPA3，对应选项 A。

④ 选项逐项辨析

A WEP→WPA→WPA2→WPA3：按时间与强度递增的正确顺序，正确。
B WPA→WEP→WPA3→WPA2：WPA 在 WEP 之前不正确（WEP 更早更弱），且 WPA3 在 WPA2 之前也不对，错误。
C WPA2→WPA→WEP→WPA3：前三个顺序完全颠倒（强→弱），错误。
D WEP→WPA2→WPA→WPA3：WPA2 在 WPA 之前不正确（WPA 更早），错误。

常见误解来源： 安全排序把 WEP 排在最后；WEP 最弱，WPA3 最强。

⑤ 易混对比　对应加密算法的演进：RC4（WEP/WPA）→ AES-CCMP（WPA2）→ AES+SAE（WPA3）。WPA 和 WPA2 的关键区别是加密算法从 RC4/TKIP 升级为 AES-CCMP。WPA2 和 WPA3 的关键区别是从 PSK 四次握手升级为 SAE 握手（抗离线字典攻击）。

⑥ 拓展延伸　WPA3 的 SAE 握手是密钥交换协议（基于 Dragonfly 协议），与 WPA2 的 PSK 不同——SAE 双方同时认证对方（对称认证），且抵御离线暴力破解（攻击者无法在离线状态下反复尝试密码）。WPA3 还强制使用 PMF（Protected Management Frames）保护管理帧，防止 deauth 攻击。企业版 WPA3-Enterprise 支持 192 位加密套件。

⑦ 真题变式　“WPA2 使用什么加密算法？”→AES-CCMP。“WPA3 引入了什么握手机制？”→SAE。“WEP 的主要缺陷是什么？”→静态 RC4 密钥+IV 太短，可被快速破解。

⑧ 记忆锚点　“WEP→WPA→WPA2→WPA3”递增链。算法：WEP/WPA 用 RC4/TKIP，WPA2 用 AES-CCMP，WPA3 用 SAE。安全强度逐级递增。

⑨ 知识关联： 主库题群：与第95-96题（无线）构成无线题群。与补题：无直接补题。与面试20题：无直接对应。面试追问：①「WPA2 和 WPA3 的区别？」——WPA3 用 SAE（同步认证等价）取代 PSK，防离线字典攻击；管理帧加密；192 位套件。②「WEP 为什么被淘汰？」——RC4 密钥短、IV 太小可重放、完整性校验弱，几分钟可破解。