网络基础知识第 3 部分：十种应用层协议
最后更新：September 14, 2026
这是一个由四部分组成的系列
第 1 部分：分层模型、链路层与路由层 · 第 2 部分：传输层与 TLS · 第 3 部分：应用层协议 （本文） · 第 4 部分：一次请求的旅程与云
传输协议提供流或数据报；应用层协议则将它们转化为服务。本部分介绍名称解析（DNS 和 DoH）、引导配置（DHCP）、运维访问（SSH）、邮件（SMTP），以及 HTTP/3、WebSocket、WebRTC、gRPC 和 MQTT。
5. 应用层：实际服务
DNS
定义： 将域名解析为 IP 地址和其他记录的分布式目录系统。
工作原理： DNS 使用分层委派。缓存未命中时，递归解析器会沿着从根域到 TLD 再到权威名称服务器的转介链进行查询，或者将请求转发给另一个解析器。缓存的答案可以免去其中部分或全部工作。A/AAAA 记录包含地址，CNAME 记录包含别名，MX 记录包含邮件服务器，TXT 记录则包含供多种协议使用的文本。
实际应用： DNS 是分布式的，但解析器、服务提供商或配置都可能成为共享依赖。对于 DNS 故障转移，要考虑故障检测、记录更新、已缓存答案的 TTL、应用程序缓存和现有连接。现在降低 TTL，并不会缩短旧缓存答案的 TTL。一些解析器还会在规定的故障条件下提供过期答案（RFC 8767）。应测量每个阶段；仅缩短 TTL 并不能保证故障转移时间。负载均衡器和任播可以作为 DNS 的补充，但它们也有各自的健康检测和收敛限制。
常见记录类型一览：
| 类型 | 用途 | 说明 |
|---|---|---|
| A / AAAA | 域名 → IPv4 / IPv6 | 基础记录 |
| CNAME | 别名 → 规范名称 | 不能与顶点处的 SOA/NS 共存；特定服务提供商的 ALIAS/ANAME 或 Route 53 Alias 可以将顶点映射到受支持的目标 |
| MX | 接收邮件的服务器 | 优先级数字越小越优先 |
| TXT | 任意字符串 | SPF/DKIM/DMARC、域名所有权验证 |
| NS | 委派的名称服务器 | 子区域委派 |
| SRV | 服务位置（主机+端口） | 某些协议的服务发现 |
| CAA | 限制获授权的证书颁发者 | 需要 CA 执行；本身不能防止所有错误签发 |
DNSSEC 和 DoH 解决的是不同问题。 DNSSEC 通过经过验证的信任链对已签名 DNS 数据及其完整性进行身份验证；它不会加密查询。DoH 使用 HTTPS 对所选解析器进行身份验证，并保护客户端与解析器之间这一跳的机密性和完整性。它无法证明恶意或配置错误的解析器返回了权威数据。两者可以同时使用。
DoH
定义： 封装在 HTTPS 中并通过 HTTPS 传输的 DNS 查询。
工作原理： 传统 DNS 通常使用明文 UDP 和 TCP 53 端口。DoH 通过 HTTPS 传输 DNS 消息，从而防止他人在这一跳上被动检查或篡改消息。解析器端点和流量元数据仍可能暴露 DoH 的使用情况；所选解析器也能看到查询内容。
实际应用： 自行选择的公共 DoH 解析器可能绕过组织解析器上的过滤/日志记录，并导致私有名称无法解析。DoH 并不会天然禁用策略：受管 DoH 解析器可以应用日志记录/过滤，浏览器/操作系统策略也可以选择获批准的解析器。应测试拆分 DNS 和端点策略，而不是假设总有必要禁用加密。
DHCP
定义： 自动为主机分配 IP 地址和网络配置的协议。
工作原理： 常见的初始 DHCPv4 交互过程为 DORA：发现 → 提供 → 请求 → 确认。本地广播或 DHCP 中继会定位服务器。租约可以包含 IPv4 地址、子网掩码、网关和 DNS 配置。续租时可以使用更简短的交互过程。DHCPv6 使用不同的消息；IPv6 默认路由器信息通常来自路由器通告，SLAAC 则是另一种地址配置机制。
实际应用： 在云中，这部分通常已被抽象处理，但你会在 VPC DHCP 选项集中再次遇到它；DNS 服务器和域名就在这里配置。在使用本地 DNS 的混合环境中，如果名称解析出现故障，这就是需要检查的设置。
SSH
定义： 提供加密远程 Shell 访问和隧道功能的协议。
工作原理： 服务器使用主机密钥进行身份验证，密钥交换过程会生成会话密钥，随后用户进行身份验证（使用公钥或密码）。之后的所有流量都会加密。除了远程 Shell 外，SSH 还支持端口转发、SFTP 和代理转发。
实际应用： 应根据访问策略限制转发，并验证服务器主机密钥。如果已被攻陷的主机能够访问转发的代理套接字，就可以请求代理进行签名/身份验证；通常，转发并不会将私钥材料复制到该主机上。如果不需要代理转发，优先使用跳板主机（ProxyJump）。原始密钥本身没有固有的有效期，但 OpenSSH 支持设置证书有效期和 authorized_keys 到期限制。应移除离职用户的访问权限，并轮换或撤销凭证。
AWS Systems Manager Session Manager 可以在无需开放入站 SSH 端口或分发 SSH 密钥的情况下提供 Shell 访问，前提是已配置受管节点、IAM 权限和服务连接。CloudTrail 会记录 API 活动；要将 Shell 内容记录到 CloudWatch Logs/S3，则需要进行配置。Session Manager SSH 和端口转发会话不支持会话内容日志记录。 仅使用基于 IAM 的访问，并不意味着每条命令都会被记录。
SMTP
定义： 在邮件服务器之间中继消息的协议。
工作原理： 客户端向提交服务器提交邮件，SMTP 服务器会中继和接收邮件，通常通过查询 MX 记录进行路由。IMAP 和 POP3 让用户检索或访问已存储在邮箱中的邮件；它们不能取代 SMTP 的服务器端接收功能。
实际应用： SMTP 身份验证和 TLS 可以保护邮件提交/传输，但本身无法证明可见的发件人域名。以下三种互补的域名机制很重要：
- SPF：为信封 MAIL FROM 或 HELO 身份授权发送主机；这并不自动对应可见的 From 标头。
- DKIM：使用签名域名的 DNS 密钥验证所覆盖邮件内容的签名；签名域名可能与可见的 From 域名不同。
- DMARC：要求可见的 From 域名与通过验证的 SPF 或 DKIM 身份对齐，并发布请求的处理/报告策略。
适用时，应一起配置 SPF、DKIM 和 DMARC，监控报告，并考虑转发/邮件列表的行为。只要有一种机制对齐，DMARC 就可以通过。这些控制措施既不能保证邮件送达，也不能消除显示名称或仿冒相似域名的风险；接收方也会应用本地策略。
HTTP/3
定义： 运行在 QUIC 之上的第三代主要 HTTP 版本。
工作原理： 各版本共享 HTTP 语义，但 HTTP/3 使用 QUIC 流以及自身的分帧和映射机制。它消除了 TCP 跨流排序依赖；但流内丢包、QPACK 依赖和共享拥塞控制仍可能延迟处理。典型的完整握手大约需要 1 RTT；在受支持的情况下，连接迁移可以在地址变更时保持连接。QPACK 取代 HPACK，以适应独立交付的流。
实际应用： 客户端可以通过 Alt-Svc、先验知识或声明受支持协议的 HTTPS DNS 记录发现 HTTP/3。Alt-Svc 可以通过先前的 TCP 连接获知；支持该 HTTPS 记录的客户端则可以在此类交互之前发现 HTTP/3。这两种方法都不能保证网络可达性或一定降低延迟。
独立交付和集成握手有助于应对丢包或高延迟链路。实际延迟、吞吐量和 CPU 开销取决于实现、卸载、工作负载和网络条件。应测量具有代表性的移动网络和数据中心流量，而不是假设总是更好或更差。
三代协议并列对比：
| HTTP/1.1 | HTTP/2 | HTTP/3 | |
|---|---|---|---|
| 传输层 | TCP | TCP | QUIC (UDP) |
| 每个连接的请求数 | 顺序处理，或通过流水线处理但响应有序 | 多路复用 | 多路复用 |
| HOL 阻塞 | 有序响应和 TCP 交付 | 各流之间存在 TCP 排序 | 没有 TCP 跨流排序；仍有其他阻塞 |
| 标头压缩 | 无 | HPACK | QPACK |
| 加密 | 可选（HTTPS） | HTTPS 使用 TLS；也存在明文 HTTP/2 | TLS 1.3 集成在 QUIC 中 |
多路复用会改变排序依赖的产生位置；HTTP/3 减少了一种阻塞来源，但并未消除所有调度、流量控制或应用层依赖。
阅读 HTTP/1.1 请求与响应
HTTP 各版本共享方法、状态码和字段语义。HTTP/1.1 会将这些概念清晰呈现为起始行 → 标头字段行 → 空行 → 可选消息体。消息体可以包含文本或二进制数据；“文本形式的 HTTP/1.1”描述的是其起始行和标头，而非每个负载。
以下内容是用于说明的 HTTP/1.1 消息，不是捕获的输出或命令配方。为便于阅读，示例使用 LF 换行。在网络传输中，起始行和每个标头行都以 CRLF (\r\n) 结尾，另外还需一个 CRLF 来结束标头部分。下面的每个消息体都恰好是 5 个 ASCII 字节，即 hello，末尾没有换行符；结束围栏前的显示换行不属于消息体。
客户端 → 服务器：
POST /echo HTTP/1.1
Host: example.test
Content-Type: text/plain; charset=utf-8
Content-Length: 5
hello服务器 → 客户端：
HTTP/1.1 200 OK
Date: Mon, 14 Sep 2026 00:00:00 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 5
hello| 元素 | 解读方式 |
|---|---|
| 请求行 | POST 是方法，/echo 是请求目标（此处为路径），HTTP/1.1 是版本。必需的 Host 字段提供目标主机名和可选端口（权限部分）。 |
| 状态行 | HTTP/1.1 是版本，200 是状态码，OK 是可选的原因短语。应根据状态码解读结果。 |
| 标头字段 | Name: value 行携带元数据；字段名称不区分大小写。Content-Type 描述表示的媒体类型，在此处还描述其字符集。 |
| 空行 | 结束标头部分。它不指定后续消息体在哪里结束。 |
| 消息体 | 内容字节。此处，Content-Length: 5 表示消息体包含五个字节，不包括起始行、标头和分隔符。应计算字节数，而不是 Unicode 字符数。 |
语义和分帧回答的是不同问题。 方法表示请求执行的操作：GET 检索表示，HEAD 请求相应的响应元数据但不请求响应内容，POST 则要求目标处理所提供的内容。状态码类别概述结果：1xx 表示信息，2xx 表示成功，3xx 表示重定向，4xx 表示客户端错误，5xx 表示服务器错误。Content-Type 说明如何解读内容，但不界定内容的长度。有关这些共享语义，请参阅 RFC 9110。
HTTP/1.1 分帧用于确定在可复用 TCP 流上有多少字节属于当前消息。对于普通的含消息体消息，如果存在有效的 Content-Length 且没有 Transfer-Encoding，则由它给出消息体长度。如果使用 Transfer-Encoding: chunked，则由块大小和终止块大小为零的块来界定消息体，之后是任意尾部字段和最终空行。发送方不得同时发送这两个字段。某些响应以关闭连接作为界定方式；TCP 数据包边界永远不会界定 HTTP 消息。
方法/状态规则优先适用：对 HEAD 的响应，以及状态为 1xx、204 或 304 的响应都没有消息体，即使允许的元数据描述了某种表示也是如此。成功的 CONNECT 响应会启动隧道。既没有长度也没有传输编码的请求不包含消息体。这些区别可以防止将下一条消息误读为当前内容（RFC 9112 §§2–6）。
HTTP/2 和 HTTP/3 保留了这些含义，但使用二进制分帧，包括 HEADERS 和 DATA 帧，而不是这些文本形式的起始行和 CRLF 边界。HTTP/2 使用 TCP；HTTP/3 将消息映射到 QUIC 流上。两者都不使用 HTTP/1.1 分块传输编码。工具可以将解码后的字段呈现为可读文本，而不显示其实际网络编码（RFC 9113、RFC 9114）。
使用 HTTPS 时，TLS 会保护传输中的 HTTP 标头和消息体；没有会话密钥的被动抓包无法显示这些明文（RFC 8446 §5）。QUIC 同样会保护 HTTP/3 应用数据。应在已获授权的端点或 TLS 终止点检查已解码的消息，并明确正在观察哪一段连接。
📎 在将相同区别应用于容器服务、Kubernetes Ingress 或 AWS 负载均衡器之前，请先完成 Linux HTTP 消息实验。
WebSocket
定义： 一种通过单个连接进行双向消息传递的应用层协议。
工作原理： HTTP/1.1 握手使用 Upgrade 和成功的 101 响应。HTTP/2 和 HTTP/3 在支持时改用 Extended CONNECT（RFC 8441 和 9220）。连接建立后，任一对端都可以发送 WebSocket 消息，无需反复使用 HTTP 轮询。
实际应用： 应为长连接做好规划：在相关空闲超时范围内发送心跳流量，在部署期间优雅地排空连接，并采用带抖动的重连退避策略。每个套接字仍由其所属实例维护。共享应用状态或消息系统（例如 Redis Pub/Sub）可以跨实例传递事件，但不会转移活动套接字，本身也不提供持久化交付。应验证协商的 HTTP 版本所使用的握手方式，以及代理是否支持该方式。
WebRTC
定义： 在兼容端点（包括浏览器和媒体服务器）之间传输实时媒体和数据的 API 与协议。
工作原理： NAT 可能会阻碍直接连接，但位于 NAT 后的两个对端仍有可能建立连接。ICE 会交换并测试主机、服务器反射（通过 STUN 学习）和中继（TURN）候选地址。应用层信令会传递会话描述和候选地址。所选路径取决于连通性检查和策略。媒体使用 SRTP，通常通过 DTLS-SRTP 建立密钥；数据通道则使用基于 DTLS 的 SCTP。
实际应用： 使用 TURN 中继会产生带宽和基础设施成本；即使媒体路径是直连的，信令、STUN 和其他服务仍会产生成本。NAT 映射/过滤和防火墙行为都会影响连通性，因此仅凭“对称 NAT”这一标签，不能普遍断定中继不可避免。应为 TURN 回退预留预算，并在实际网络中进行测试。SFU 是常见的多人通信设计；与完整的对等网状结构相比，它会以增加服务器带宽/计算开销为代价，减少客户端上传流量。
gRPC
定义： 一种 RPC 框架，其标准原生传输使用 HTTP/2，通常搭配 Protocol Buffers 服务和消息架构。
工作原理： Protocol Buffers 定义可以生成客户端/服务器代码，并支持一元、服务器流式、客户端流式和双向流式 RPC。二进制编码可能更紧凑，但相较于 JSON 的大小和速度取决于数据、实现和压缩方式；这并非协议保证。
实际应用： 原生 gRPC 适用于许多服务 API。浏览器 API 不会公开原生 gRPC 所需的所有功能，因此浏览器客户端通常会使用 gRPC-Web，并配合兼容的服务器或转换代理；可用的流式模式取决于具体实现。检查和调试时应使用支持架构的工具。
gRPC 通道可以使用零个或多个 HTTP/2 连接，许多 RPC 可以共享一个长连接。L4 负载均衡会按连接选择后端，因此较小的连接池可能导致 RPC 流量集中；它不能保证按 RPC 进行分发。可以考虑合适的客户端策略或支持 gRPC 的 L7 代理（它可能是服务网格的一部分）。已建立的流仍会保留在各自选定的后端。演进架构时，应保留已删除 Protocol Buffers 字段的编号/名称，且绝不要重复使用其编号。
📎 有关 Istio 中的 gRPC 处理，请参阅 Istio gRPC 进阶。
MQTT
定义： 一种轻量级发布-订阅消息协议。
工作原理： 客户端连接到代理，并向主题发布消息或订阅主题。固定标头可以小至 2 字节，但实际报文也可能需要可变标头、属性和负载。QoS 0/1/2 分别提供相关发送方与接收方之间协议层的至多一次、至少一次和恰好一次交付。发布者到代理以及代理到订阅者的交付是彼此独立的。在指定的断开连接条件下，可以发布已配置的遗嘱；MQTT 5 的 Will Delay 和重连行为会影响遗嘱出现的时间。
实际应用： 应根据对丢失/重复消息的容忍度和成本选择 QoS。要成功完成 QoS 2 交付，通常需要交换 PUBLISH、PUBREC、PUBREL 和 PUBCOMP；它并不能保证应用程序的数据库副作用或整个业务工作流恰好执行一次。QoS 1 加应用层去重是一种可选的权衡。应根据所选产品规划代理可用性、持久化会话/消息状态和恢复机制。应使用 TLS 和适当的设备身份验证/授权方案；客户端证书是一种选择，但需要进行配置和轮换。
主要参考资料：DoH、DNS 过期数据服务、OpenSSH、Session Manager、DMARC、HTTP/3、ICE、gRPC 性能、MQTT 5.0。
下一篇：第 4 部分：一次请求的旅程与云