Web 服务器与计算机网络全景原理

副标题：从浏览器、交换机、网关与路由器，到 HTTP、TCP/UDP、应用后端和数据库

阅读目标： 不仅知道"有哪些设备和协议"，更能解释"一次 Web 访问为什么能成功、在哪里可能失败、应该怎样配置和保护"

摘要

Web 系统不是"一台服务器响应一个浏览器"这么简单。一次看似普通的网站登录，至少涉及五类连续而又相互独立的机制：

命名与寻址：DNS 把域名解析为 IP 地址；IP 地址说明目标位于哪个网络。
局域网交付与跨网转发：网卡、无线接入点、交换机、默认网关和路由器把数据逐跳送向目标。
端到端传输与安全信道：TCP 提供可靠字节流，或由基于 UDP 的 QUIC 提供可靠多路传输；TLS 提供机密性、完整性和服务器身份验证。
Web 语义与应用处理：HTTP 表达"请求什么、提交什么、返回什么"；反向代理、应用服务器和业务代码完成路由、校验、鉴权与响应生成。
状态与数据持久化：数据库、缓存和对象存储保存不同类型的数据；会话机制把无状态的多次 HTTP 请求关联为"同一个已登录用户"。

这五类机制的边界必须分清。DNS 负责"找到地址"但不负责"把包送过去"；路由器负责"选择下一跳"但通常不理解登录业务；TLS 保护传输内容但不替代权限控制；数据库验证的是应用服务身份，而网站用户密码通常只用于应用层认证，绝不应直接作为数据库连接密码。

0. 阅读地图：先看全局，再进入细节

0.1 一次访问的全景路径

下面这张图先给出全文的主线。实际系统可能省略某些节点，也可能在每一层部署多个实例，但逻辑关系基本不变。

图 1　一次 Web 访问的端到端全景路径

理解这张图时要抓住三个事实：

它是一条逻辑链，不一定是一条物理直线。 DNS 查询和网站访问是两条不同的数据流；缓存命中后，内容甚至不会到达源站。
端到端连接常被拆成多段连接。 浏览器到 CDN、CDN 到负载均衡、反向代理到应用、应用到数据库，通常分别拥有独立的套接字、超时和加密策略。
每层只承担有限职责。 分层降低了系统复杂度，也造成了典型的"层间误判"：例如把 DNS 解析成功误认为服务一定可访问，把 443 端口可连误认为登录业务一定正常。

0.2 全文回答的核心问题

问题	最短答案	详细位置
域名怎样找到服务器？	DNS 返回地址，路由系统把包逐跳送往该地址	第 3、4 章
交换机、路由器和网关有什么区别？	交换机主要转发二层帧；路由器转发三层分组；网关是跨边界的功能角色	第 2、3 章
HTTP、TCP、UDP 是上下级关系吗？	HTTP 是应用语义；TCP/QUIC 提供传输；UDP 是 QUIC 的承载之一	第 5、6 章
登录时密码怎样到数据库？	通常不会"拿用户密码登录数据库"；应用查询密码哈希并本地验证	第 8 章
Web 服务器和应用服务器是否相同？	可以在小系统中合一，生产环境通常分工	第 7 章
为什么需要反向代理、负载均衡和缓存？	为入口治理、扩展、隔离、性能与高可用	第 7、10 章
服务器应该开放哪些端口？	公网通常只开放必要入口；数据库和管理面应限制在内网或受控源	第 11 章
出错时从哪里查？	依次检查名称、路由、端口、TLS、HTTP、应用、依赖和数据	第 13 章

第一部分：网络设备如何协同

1. 分层不是背诵题，而是定位责任的工具

1.1 TCP/IP 模型与 OSI 模型

工程实践最常使用 TCP/IP 分层，OSI 七层则常用于交流和排障。二者不是两套互相竞争的协议，而是不同粒度的观察框架。

TCP/IP 视角	常对应的 OSI 层	典型对象	主要问题
应用层	5--7 层	HTTP、DNS、SSH、SMTP、应用数据	"传什么业务语义？"
传输层	4 层	TCP、UDP、QUIC	"哪个进程与哪个进程通信？可靠性如何实现？"
网际层	3 层	IPv4、IPv6、ICMP、路由	"分组怎样跨网络到达目标主机？"
链路层	1--2 层	Ethernet、Wi‑Fi、MAC、VLAN、ARP/NDP	"同一条链路上怎样交付一帧？"

图 2　TCP/IP 分层封装与解封装

封装的关键意义是：每一层只阅读自己负责的首部。交换机通常依据 MAC 表决定端口；普通路由器依据目标 IP 和路由表选择下一跳；TCP 根据端口和连接状态把字节交给正确套接字；Web 应用才会理解"登录""订单""用户名"等语义。

1.2 五元组与"连接"

网络排障中常用五元组描述一条传输流：

复制代码

(源 IP, 源端口, 目标 IP, 目标端口, 传输协议)

例如浏览器的一条 HTTPS/TCP 连接可以表示为：

复制代码

(192.168.1.23, 51544, 203.0.113.50, 443, TCP)

源端口 51544 通常由操作系统临时分配；目标端口 443 表示服务入口。经过家庭 NAT 后，互联网侧可能看到：

复制代码

(198.51.100.27, 62001, 203.0.113.50, 443, TCP)

NAT 设备保存一条状态映射，才能把返回给 198.51.100.27:62001 的报文重新交给内网 192.168.1.23:51544。

1.3 哪些字段会在途中变化

字段	典型变化规律	原因
源/目标 MAC	每经过一个三层转发点都会重写	MAC 只在当前二层链路内有意义
源/目标 IP	通常端到端不变；经过 NAT、代理或隧道时可能变化	IP 标识网络层端点，NAT/代理会形成新边界
TTL / Hop Limit	每经过一个路由器减 1	防止路由环路导致分组永久循环
TCP/UDP 端口	端到端通常不变；NAPT、代理后可能变化	NAT 复用公网地址，代理建立新连接
HTTP Host、Path、Cookie	普通 IP 路由器不读取；七层代理可以读取或改写	它们属于应用层
TLS 内的 HTTP 正文	中间普通设备不可见；在 TLS 终止点解密	TLS 提供机密性与完整性

最容易产生的误解是：浏览器并不需要知道远端 Web 服务器网卡的 MAC 地址。 如果目标 IP 不在本地子网，客户端只通过 ARP（IPv4）或邻居发现 NDP（IPv6）寻找"下一跳默认网关"的链路层地址。

2. 网卡、交换机、无线 AP、路由器和防火墙

2.1 网卡：主机进入网络的接口

网卡（NIC）连接操作系统协议栈与物理/无线介质。它通常拥有：

一个或多个链路层地址（MAC）；
IP 地址、前缀长度、默认路由等三层配置；
发送/接收队列、校验和卸载、分段卸载等性能功能；
有线速率、Wi‑Fi 频段与信道等物理属性。

程序通常不直接操作网卡，而是通过 Socket API 请求操作系统建立 TCP 连接或发送 UDP 数据报。内核根据路由表选择出接口，再完成邻居解析、封装和队列调度。

2.2 交换机：在一个二层广播域内转发帧

以太网交换机通过学习"源 MAC 从哪个端口出现"建立 MAC 地址表。收到帧后：

目标 MAC 已知：只转发到对应端口。
目标 MAC 未知：在相应 VLAN 内泛洪，等待后续学习。
广播帧：在广播域内转发，例如传统 ARP 请求。

交换机不等同于"多口路由器"。二层交换机不负责跨 IP 子网选路；VLAN 能在同一物理交换结构上形成多个逻辑广播域，但 VLAN 之间仍需三层设备路由。

2.3 无线 AP：把 802.11 无线接入桥接到有线网络

家庭"无线路由器"常把多个角色做在一台盒子中：无线 AP、以太网交换机、路由器、NAT、防火墙、DHCP 服务器和 DNS 转发器。概念上应拆开：

AP 负责无线接入和二层桥接；
交换部分 连接本地有线设备；
路由部分 连接 LAN 与 WAN；
DHCP 给客户端分配 IP、掩码、网关、DNS 等参数；
NAT/防火墙 控制并转换出入流量。

2.4 路由器：按最长前缀匹配选择下一跳

路由器收到 IP 分组后，核心动作是：

检查分组是否可转发，并递减 TTL/Hop Limit；
在路由表中进行最长前缀匹配；
确定出接口和下一跳；
为下一条链路重新封装二层帧；
依据队列、QoS、ACL 等策略发送或丢弃。

示例路由表：

目的前缀	下一跳	出接口	含义
`10.20.2.0/24`	直连	`eth1`	数据库子网直接连接
`10.20.0.0/16`	`10.20.1.1`	`eth1`	站点内部其他子网
`203.0.113.50/32`	`192.0.2.9`	`eth0`	对某个目标的更具体路由
`0.0.0.0/0`	`192.0.2.1`	`eth0`	默认路由，匹配其他所有 IPv4 目的地址

若目标是 203.0.113.50，/32 比 /0 更具体，因此选 192.0.2.9。路由器并不是从整条路径中"算出终点"，而是只做下一跳决策；后续路由器重复同样过程。

2.5 防火墙：对流量执行安全策略

防火墙可以是独立设备、路由器功能、主机内核功能或云平台规则。常见能力包括：

无状态 ACL：根据源/目标 IP、端口、协议逐包判断；
有状态检测：识别连接方向和状态，只允许已建立连接的返回流量；
应用识别：理解部分七层协议，执行更细粒度策略；
NAT：常与防火墙集成，但 NAT 本身不等同于安全策略；
日志、限速、入侵防御和恶意地址阻断。

NAT 不应被视为防火墙的替代品。 NAT 的主要目标是地址转换和地址复用；真正的安全边界来自明确的允许/拒绝规则、状态跟踪、身份验证和网络分段。

2.6 设备职责对照

组件	主要观察对象	典型工作层	是否改变端到端连接	常见误解
二层交换机	MAC、VLAN	L2	否	"交换机也能把包路由到互联网"
路由器	IP 前缀、下一跳	L3	通常否	"每台路由器都知道整条路径"
NAT 网关	IP、端口、连接状态	L3/L4	改写地址/端口	"NAT 自动等于安全"
状态防火墙	五元组、连接状态	L3/L4	通常不终止连接	"端口开放就代表应用健康"
四层负载均衡	IP、端口、连接	L4	常作为连接边界	"能按 URL 路径分流"
七层反向代理	Host、Path、Header、Cookie	L7	是，前后端为两段连接	"只是在转发同一个 TCP 包"
WAF	HTTP 语义与内容	L7	常在 TLS 终止点工作	"能修复应用自身所有漏洞"

3. "网关"到底是什么：一个角色，多种实现

"网关"不是某一种固定硬件，而是连接不同网络、信任域或协议域的边界角色。不同语境中的网关，工作层次和职责可能完全不同。

图 3　不同类型网关所处的位置与职责

3.1 默认网关

主机路由表中，若没有更具体的目标路由，就把分组交给默认网关。默认网关必须与主机在某条可直接到达的链路上。例如：

复制代码

主机：192.168.1.23/24
默认网关：192.168.1.1
目标网站：203.0.113.50

客户端计算前缀后发现目标不属于 192.168.1.0/24，于是查询 192.168.1.1 的 MAC，并把"目标 IP 仍为 203.0.113.50"的分组封装给网关。链路层目标是网关，网络层目标仍是网站。

3.2 NAT 网关

NAT 网关用于私网与公网之间的地址转换。常见形式：

SNAT：改变源地址，常用于私网主机访问公网；
DNAT/端口转发：改变目标地址，把公网入口映射到内网服务；
NAPT/PAT：同时改写端口，让大量内网连接复用一个公网 IP。

NAT 需要维护状态，因此有连接表容量和超时问题。UDP 没有握手，NAT 只能依据一段时间内是否仍有数据报来维持映射；长时间静默的 UDP 应用可能需要保活。

3.3 VPN 网关

VPN 网关把原始 IP 分组封装进加密隧道，使两个私网或远程用户与内网建立逻辑连接。它同时涉及：

隧道端点身份认证；
加密和完整性保护；
隧道内地址分配与路由下发；
全隧道或分流策略；
对内网资源的访问控制。

3.4 互联网网关与云路由表

云环境中的 Internet Gateway 往往是逻辑化、托管化的公网边界。它与子网路由表、安全组、网络 ACL、公网 IP/NAT 网关共同决定可达性。仅仅"挂载了互联网网关"不代表实例可从公网访问，还需要：

子网路由把公网流量指向该网关；
实例或负载均衡拥有合适的公网地址映射；
安全组和网络 ACL 允许流量；
主机防火墙和服务监听正确。

3.5 API 网关

API 网关工作在应用层，常完成统一认证、令牌校验、限流、配额、版本路由、协议转换和审计。它面向的是"API 调用"，与默认网关的"IP 下一跳"不是一回事。

3.6 服务网格网关

服务网格中常见入口网关、出口网关和 Sidecar/节点代理。它们把服务间流量纳入统一的身份、mTLS、可观测性与策略控制。服务网格不能消除底层 IP 网络；它是在可达的 L3/L4 网络之上增加 L7 或身份层治理。

3.7 网关语义总表

名称	连接的边界	主要层次	核心职责	典型风险
默认网关	本地子网 ↔ 其他网络	L3	提供默认下一跳	网关错误导致只能访问本地
NAT 网关	私网 ↔ 公网	L3/L4	地址和端口转换	端口耗尽、状态超时、单点
VPN 网关	不可信网络 ↔ 私网	L3--L4	加密隧道与路由	路由冲突、凭据泄露、横向移动
互联网网关	云 VPC ↔ Internet	L3	公网连通边界	错误路由或过度暴露
API 网关	外部调用方 ↔ API	L7	鉴权、限流、路由、审计	策略绕过、密钥管理不当
Ingress/Gateway	集群外 ↔ 集群服务	L7 为主	域名/路径路由、TLS 终止	默认暴露、配置漂移
邮件/协议网关	不同协议或信任域	L7	协议转换、内容检查	转换歧义、策略不一致

4. 从局域网到互联网：寻址、ARP、路由、NAT 与 BGP

4.1 DHCP：让主机获得可用网络参数

客户端接入网络时，常通过 DHCP 获得：

IP 地址和租期；
子网掩码或前缀长度；
默认网关；
DNS 服务器；
可选的域名、NTP、静态路由等信息。

"拿到 IP"只是开始。若掩码错误，主机会错误判断目标是否本地；若默认网关错误，只能访问同一子网；若 DNS 错误，直接访问 IP 可能正常而域名失败。

4.2 ARP/NDP：只解析本链路的下一跳

IPv4 使用 ARP 把本地链路上的 IPv4 地址映射为 MAC；IPv6 使用邻居发现协议 NDP。对于远端服务器，客户端解析的是默认网关的链路层地址，而不是远端服务器的 MAC。

图 4　ARP、默认网关与逐跳转发

4.3 子网、CIDR 与最长前缀

CIDR 记法 192.168.1.0/24 表示前 24 位是网络前缀，剩余位用于子网内地址。路由表允许前缀重叠，最长前缀优先保证更具体的路径覆盖更泛化的默认路径。

常见私有 IPv4 地址范围是 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16。它们不会在公共互联网中作为正常可路由前缀传播，因此通常需要 NAT 或 VPN 才能跨公网通信。IPv6 拥有更大的地址空间，常减少对地址复用型 NAT 的依赖，但防火墙策略仍不可缺少。

4.4 域内路由与跨域路由

一个组织或运营商控制的路由域称为自治系统（AS）。

AS 内部常使用 OSPF、IS-IS 等 IGP，目标是快速收敛和内部最优转发；
AS 之间使用 BGP 交换可达前缀，路径选择不仅考虑距离，也受商业关系、策略和安全控制影响；
数据面根据已经计算好的转发表高速转发，控制面负责学习、选择和下发路由。

因此，traceroute 看到的路径不是"DNS 指定的路径"，也未必是地理最短路径。互联网路由是分布式、策略驱动的，去程与回程还可能不对称。

4.5 完整逐跳示例

假设：

复制代码

客户端       192.168.1.23:51544
家庭网关 LAN 192.168.1.1
家庭公网地址 198.51.100.27
网站入口     203.0.113.50:443

位置	链路层源/目标	网络与传输层	发生的动作
客户端发出	`MAC-H → MAC-G`	`192.168.1.23:51544 → 203.0.113.50:443`	查路由，目标非本地，交默认网关
家庭网关 WAN	本跳接口 MAC 重写	`198.51.100.27:62001 → 203.0.113.50:443`	SNAT/PAT，建立状态映射
运营商路由器	每跳 MAC 重写	IP/端口通常保持	查前缀、减 TTL、排队转发
网站边界	本地链路 MAC	公网五元组到达 VIP	防火墙、DDoS/WAF、负载均衡
反向代理后端	新的链路与连接	`10.20.1.10:43022 → 10.20.2.15:8080`	前端连接终止，另建后端连接
应用访问 DB	又一条独立连接	`10.20.2.15:54018 → 10.20.3.20:5432`	使用服务账号和连接池访问数据库

这张表说明：所谓"一次网站连接"在用户体验上是一件事，在网络实现上却可能是多条独立连接与多次地址重写的组合。

第二部分：协议怎样把"能到达"变成"能通信"

5. TCP、UDP 与 QUIC

5.1 TCP：可靠、有序的字节流

TCP 向应用提供双向字节流。它的"可靠"不是链路永不丢包，而是通过序列号、确认、重传、校验、滑动窗口和拥塞控制，使应用最终看到按序字节，或明确得到连接失败。

图 5　TCP 连接建立、传输与关闭

必须区分两种"控制"：

流量控制 保护接收端，核心参考接收窗口 rwnd；
拥塞控制 保护网络，核心参考拥塞窗口 cwnd、往返时延和丢包/显式拥塞信号。

TCP 不保留应用消息边界。应用写入两次数据，接收端可能一次读出；应用写入一次大数据，也可能多次读出。因此应用协议必须有自己的长度、分隔或帧格式。HTTP/1.1 使用起始行、首部和正文长度/分块机制；HTTP/2 使用二进制帧。

5.2 UDP：尽力而为的数据报

UDP 保留数据报边界，没有连接握手，不承诺送达、顺序、去重、重传或拥塞控制。它的优势是首部和状态较轻、应用可自定义时延与可靠性策略。

典型用途包括：

DNS 的常规查询；
实时音视频和在线游戏；
网络测量与遥测；
QUIC 的底层承载；
某些 VPN 与服务发现协议。

"UDP 不可靠"不等于"基于 UDP 的应用一定不可靠"。QUIC 就在用户态实现了可靠传输、拥塞控制、流和加密；实时音视频也可以用序列号、前向纠错、选择性重传来满足自身需求。

5.3 QUIC：在 UDP 之上重新组织传输能力

QUIC 使用 UDP 数据报承载，但自身提供连接、可靠流、拥塞控制、连接迁移和 TLS 1.3 集成。HTTP/3 把 HTTP 语义映射到 QUIC。与 HTTP/2 复用在单条 TCP 字节流不同，QUIC 在传输层暴露多个流，一个流的丢包通常不会阻塞其他不相关流的有序交付。

图 6　HTTP/1.1、HTTP/2 与 HTTP/3 协议栈

5.4 三者对照

维度	TCP	UDP	QUIC
抽象	可靠、有序字节流	尽力而为数据报	加密连接中的多个可靠流与不可靠数据报能力
握手	TCP 三次握手	无传输层握手	QUIC 与 TLS 握手结合
消息边界	不保留	保留	流有字节语义，也可使用数据报扩展
可靠与有序	整条连接字节序列	协议本身不提供	通常按流可靠、有序
加密	需上层 TLS	需应用另行实现	协议集成 TLS 1.3
多路复用丢包影响	HTTP/2 仍受单 TCP 流队头阻塞	由应用决定	不相关流可独立恢复
内核/中间盒支持	最成熟	最简单	常在用户态，便于演进但可能受 UDP 阻断
常见 Web 用法	HTTP/1.1、HTTP/2	DNS、媒体，以及承载 QUIC	HTTP/3

6. DNS、TLS 与 HTTP：从名字到安全的业务语义

6.1 DNS：分布式、层次化、可缓存的命名系统

当浏览器访问 https://www.example.test/login 时，系统需要获得域名对应的地址。典型过程是：

图 7　DNS 递归解析与缓存过程

常见记录：

记录	作用	Web 场景
`A`	名称 → IPv4 地址	返回网站 IPv4 入口
`AAAA`	名称 → IPv6 地址	返回网站 IPv6 入口
`CNAME`	名称 → 另一个规范名称	把业务域名指向 CDN 域名
`NS`	指明区域权威服务器	建立 DNS 委派
`MX`	指明邮件交换服务器	与网站同域的邮件系统
`TXT`	承载文本策略/验证数据	SPF、域名所有权验证等
`HTTPS/SVCB`	描述服务端点与参数	可辅助发现 HTTP/3 等能力

DNS 回答"可尝试连接哪个地址"，不保证该地址当前健康。负载均衡 DNS、Anycast、CDN 和健康检查可以改善可用性，但最终仍需传输层和应用层验证。

6.2 TLS：机密性、完整性与服务器身份

HTTPS 是 HTTP 在安全传输之上运行。TLS 1.3 握手的主要目标是：

协商版本、密码套件和密钥交换参数；
服务器提供证书链，证明其公钥与域名身份的绑定；
客户端验证域名、证书有效期、签发链和撤销等条件；
双方派生会话密钥；
后续应用数据获得机密性和完整性保护。

图 8　TLS 1.3 握手的核心过程

注意以下边界：

TLS 只保护其两个端点之间的数据。若 TLS 在 CDN 或反向代理处终止，后端是否继续使用 TLS/mTLS，需要单独设计。
浏览器地址栏出现锁形图标，说明到所连接站点的传输和证书验证成立，不说明网站业务一定可信。
HTTPS 不能阻止应用把密码错误地写入日志，也不能修复 SQL 注入、越权和弱密码哈希。
证书公钥与会话密钥不是一回事；现代 TLS 使用临时密钥交换以获得前向保密。

6.3 HTTP：请求---响应语义

HTTP 描述方法、目标资源、首部、状态码和表示内容。一个简化登录请求：

复制代码

POST /api/login HTTP/1.1
Host: www.example.test
Content-Type: application/json
Accept: application/json
Origin: https://www.example.test
Content-Length: 58

{"username":"alice","password":"correct horse battery staple"}

成功响应可能为：

复制代码

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Set-Cookie: session=RANDOM_OPAQUE_VALUE; Path=/; Secure; HttpOnly; SameSite=Lax

{"ok":true,"displayName":"Alice"}

HTTP 方法的语义要与实现一致：

方法	典型语义	幂等性	常见注意点
`GET`	获取资源表示	是	不应产生关键业务副作用；可缓存性需显式设计
`HEAD`	只取首部	是	应与 GET 的元数据一致
`POST`	提交处理、创建子资源	通常否	重试可能重复执行，支付等需幂等键
`PUT`	用给定表示创建/替换目标资源	是	语义是整体替换还是应用自定义需说明
`PATCH`	部分修改	不一定	需要定义补丁格式和并发控制
`DELETE`	删除目标资源	是（语义上）	多次调用结果状态可一致，但响应码可不同
`OPTIONS`	查询通信选项	是	浏览器 CORS 预检常用

常见状态码应按层次解释：

2xx：请求已成功处理，如 200、201、204；
3xx：重定向或缓存相关，如 301、302、304；
4xx：客户端请求或权限问题，如 400、401、403、404、409、429；
5xx：服务器或上游故障，如 500、502、503、504。

其中 502 常表示网关收到上游无效响应，503 表示服务暂不可用，504 表示网关等待上游超时。它们比笼统的"服务器坏了"更能帮助定位责任层。

6.4 HTTP/1.1、HTTP/2、HTTP/3

维度	HTTP/1.1	HTTP/2	HTTP/3
报文编码	文本起始行与首部	二进制帧	基于 QUIC 流的二进制帧
传输	通常 TCP，可配 TLS	通常 TLS over TCP	QUIC over UDP，集成 TLS 1.3
并发	常以多个 TCP 连接提高并行度	单连接多路复用	单 QUIC 连接多流
首部压缩	无专门二进制压缩	HPACK	QPACK
丢包影响	影响相应 TCP 连接	TCP 层丢包可能阻塞全部流	通常限制在受影响的 QUIC 流
部署现实	兼容性最好	已广泛使用	需 UDP 可达并配置回退

HTTP 版本改变的是编码与传输组织，不改变 GET、POST、状态码、缓存等核心语义。应用开发者不应把"升级 HTTP/3"误解为自动修复慢 SQL 或错误缓存策略。

第三部分：Web 服务器、应用服务器与数据系统

7. Web 服务器的整体原理

7.1 一个监听端口背后发生了什么

Web 服务器进程启动后，会创建监听 Socket，并将其绑定到地址和端口，例如 0.0.0.0:443 或 [::]:443。操作系统收到目标为该端口的合法流量后，根据连接状态把数据交给相应进程。服务器随后可能：

接受 TCP 连接或 QUIC 连接；
完成 TLS 握手；
解析 HTTP 请求行、首部与正文；
根据虚拟主机、路径和方法选择处理器；
直接读取静态文件，或把请求代理给应用服务器；
生成响应首部和正文；
复用连接、关闭连接或把连接升级为 WebSocket。

高性能服务器通常采用事件驱动、非阻塞 I/O、多进程/多线程和连接复用等机制，避免"一条空闲连接永久占用一个昂贵线程"。但应用模型不同：CPU 密集任务仍需要受控的进程/线程资源，阻塞式数据库调用也可能耗尽工作池。

7.2 Web 服务器与应用服务器的分工

层次	典型职责	常见软件
CDN/边缘	就近缓存、Anycast、DDoS 缓解	商业 CDN、云 CDN
L4 负载均衡	按连接分发 TCP/UDP，不必理解 HTTP	HAProxy、LVS/IPVS、云网络负载均衡
L7 代理/Web 服务器	TLS、虚拟主机、静态文件、HTTP 路由、限速	NGINX、Apache HTTP Server、Caddy、IIS、HAProxy、Envoy、Traefik
应用服务器/运行时	业务逻辑、认证授权、模板/API、事务	Node.js、Gunicorn/Uvicorn、Tomcat/Jetty、Kestrel、PHP-FPM、Go/Rust 程序
数据与消息	持久化、缓存、搜索、异步解耦	PostgreSQL、MySQL、Redis、MongoDB、Elasticsearch/OpenSearch、Kafka/RabbitMQ

小型系统可以由一个进程同时提供静态文件、API 和数据库访问；生产系统拆分角色，主要为了：

限制故障和攻击的传播范围；
独立扩展计算、连接、缓存和存储；
统一入口策略与证书管理；
让应用保持无状态，便于横向扩容；
允许不同组件使用最适合的资源和更新节奏。

7.3 正向代理、反向代理和透明代理

正向代理代表客户端访问外部资源，服务端通常只看到代理地址；企业上网代理、隐私代理属于此类。
反向代理代表一个或多个服务端接收客户端请求，客户端不必知道真实后端；网站入口、负载均衡常属于此类。
透明代理在客户端未显式配置时介入流量，可能用于缓存、审计或安全控制；加密流量限制了其可见性，除非执行受信任的 TLS 检查。

7.4 虚拟主机与同一 IP 多网站

多个域名可共用一个 IP 和 443 端口：

TLS 握手中的 SNI 帮助入口选择证书和 TLS 配置；
HTTP 的 Host（HTTP/2/3 中对应 :authority）帮助选择虚拟主机；
反向代理再按域名和路径转发到不同后端。

因此，仅用 IP 访问 HTTPS 站点可能遇到证书域名不匹配或落入默认站点。排障时必须同时核对 DNS、SNI、Host 和证书。

7.5 典型三层架构

图 9　典型三层 Web 系统架构

7.6 负载均衡到底均衡什么

负载均衡不是"平均分配每个数据包"。常见策略包括：

轮询：实现简单，适合实例能力相近；
加权轮询：不同实例承担不同份额；
最少连接：更适合请求时长差异较大的场景；
一致性哈希：让某类键较稳定地落到同一后端，常用于缓存；
基于路径/域名/首部：七层路由不同业务；
主动或被动健康检查：移除不可用实例。

会话黏性可以把同一用户尽量送到同一实例，但会增加扩缩容和故障迁移复杂度。更通用的设计是让应用实例无状态，把会话放到共享存储，或使用经过审慎设计的自包含令牌。

8. 深入案例：一次网站登录究竟发生了什么

这一章把前面所有机制串起来。假设用户访问 https://www.example.test/login，网站使用反向代理、应用服务、Redis 和 PostgreSQL。

8.1 先分清三类完全不同的"账号密码"

身份	谁向谁证明	凭据示例	应保存在哪里
网站用户身份	用户 → Web 应用	用户名、密码、MFA、Passkey	密码只保存慢哈希结果；MFA 密钥专门保护
应用服务身份	应用 → 数据库/缓存/队列	DB 角色密码、客户端证书、云工作负载身份	密钥管理系统或受控 Secret，不写入源码
运维管理身份	管理员 → 服务器/控制面	SSH 密钥、短期证书、硬件 MFA	个人安全设备、堡垒机或身份平台

最重要的结论是：网站用户输入的密码一般不会被拿去建立 PostgreSQL/MySQL 连接。 应用早已通过连接池使用自己的最小权限数据库服务账号连接数据库。用户密码只用于验证"这个人是否拥有某个应用账号"。

8.2 登录全链路时序

图 10　网站登录的完整后端时序

为避免时序图横向过度拥挤，图中"应用返回浏览器"的箭头折叠了反向代理和边缘层的回程；实际响应仍会按 应用 → 反向代理 → 边缘入口 → 浏览器 逐段返回，每一段都执行各自的超时、连接复用与加密策略。

8.3 浏览器提交阶段

浏览器在 TLS 建立后发送登录请求。密码存在于浏览器内存和 TLS 端点的应用内存中，但在线路上是加密的。实践要求：

登录页和 API 全程 HTTPS，HTTP 入口仅用于安全重定向；
不把密码放入 URL 查询串，因为 URL 更容易进入历史、代理日志和 Referer；
请求与响应禁止被公共缓存；
保护登录接口免受暴力尝试、凭据填充和自动化滥用；
服务端仍需做长度、编码和结构校验，不能信任前端校验。

8.4 反向代理与可信客户端地址

当请求经过多层代理，后端看到的 TCP 对端往往是反向代理，而不是用户。代理可以添加 Forwarded 或 X-Forwarded-For。但是后端只能信任由受控代理覆盖写入的值，不能盲信客户端自带同名首部，否则攻击者可伪造来源地址绕过限速或审计。

推荐做法：

公网只能访问入口代理，不能绕过入口直连应用；
入口删除不可信转发首部并重新生成；
应用配置明确的可信代理数量或地址范围；
安全决策不要只依赖容易共享或变化的客户端 IP。

8.5 应用怎样查询账号

伪代码如下：

复制代码

def login(username, password, request_context):
    normalized = normalize_username(username)
    enforce_rate_limit(request_context.ip, normalized)

    user = db.query_one(
        "SELECT id, password_hash, status, role_version "
        "FROM app_user WHERE username = %s",
        [normalized],                 # 参数绑定，不拼接 SQL
    )

    # 即使用户不存在，也执行成本接近的虚拟哈希验证，减弱时序枚举
    stored_hash = user.password_hash if user else DUMMY_HASH
    verified = password_hasher.verify(stored_hash, password)

    if not user or not verified or user.status != "active":
        record_failed_attempt(normalized, request_context)
        raise GenericLoginFailure("用户名或密码错误")

    if password_hasher.needs_rehash(stored_hash):
        update_hash(user.id, password_hasher.hash(password))

    session_id = secure_random_token()
    session_store.create(session_id, user.id, ttl="30m")
    return session_cookie(session_id, secure=True, http_only=True, same_site="Lax")

这里有四个安全要点：

SQL 使用参数绑定，用户名永不作为 SQL 结构拼接；
密码验证应使用成熟库，避免自制密码学；
登录失败响应保持通用，减少用户枚举；
算法参数升级时可在成功登录后"验证并重新哈希"。

8.6 密码在数据库中怎样保存

数据库不应保存明文密码，也不应保存可逆"加密密码"。正确模型是：

图 11　密码哈希存储与登录验证流程

密码哈希与普通文件哈希目标不同。SHA‑256 很快，适合完整性校验，却会让攻击者每秒尝试大量候选密码。密码 KDF 故意消耗时间和内存，以提高离线破解成本。盐不需要保密，但必须随机且每个密码唯一；Pepper 若使用，应与数据库分离并纳入密钥轮换与故障恢复设计。

数据库中的一条记录可能类似：

复制代码

$argon2id$v=19$m=19456,t=2,p=1$<salt-base64>$<derived-value-base64>

这是包含算法和参数的编码格式，不是可以"解密回原密码"的密文。实际参数应依据硬件基准、安全要求和官方指南选择，并随时间提升。

8.7 数据库连接怎样建立

应用启动或首次访问时，连接池使用服务凭据连接数据库：

复制代码

postgresql://app_role@db.internal.example:5432/appdb

密码、客户端证书或云身份不应硬编码在源代码和镜像中。连接建立涉及：

内部 DNS 解析 db.internal.example；
路由和防火墙允许应用子网访问数据库端口；
TCP 建连；
可选/强制 TLS 与服务器证书验证；
PostgreSQL 根据 pg_hba.conf 等规则选择认证方法；
数据库角色认证成功并进入指定数据库；
连接放入池中复用。

连接池避免每个 HTTP 请求都执行完整数据库握手，但池不是越大越好。假设 20 个应用实例、每实例 50 个连接，就是 1000 条数据库连接；数据库的内存、进程/线程模型和锁竞争可能因此恶化。容量应从数据库可承受连接数反推，并预留管理和故障切换空间。

8.8 参数化查询、事务与索引

安全查询：

复制代码

SELECT id, password_hash, status
FROM app_user
WHERE username = $1;

而不是：

复制代码

# 错误示范：用户输入改变 SQL 结构，可能导致注入
sql = "SELECT * FROM app_user WHERE username = '" + username + "'"

username 应具有唯一索引，否则查找可能退化为全表扫描，并且难以保证唯一性。更新失败次数、最后登录时间或会话版本时，要考虑事务隔离、并发更新和重复请求。支付、发券等高价值操作还需要业务幂等键，不能只依赖 TCP"没有报错"。

认证通过后，后续请求不能每次重新提交密码。常见两种模式：

模式	浏览器持有什么	服务端状态	优点	风险/代价
不透明会话 ID	高熵随机 ID	Redis/数据库保存用户与会话映射	易撤销、权限变化立即生效	依赖共享会话存储
签名令牌/JWT	含声明的签名令牌	可较少查询中央会话	适合分布式验证和跨服务场景	撤销、过期、密钥轮换、声明陈旧更复杂

JWT 不是"更安全的 Cookie"，Cookie 也不是"会话本身"。Cookie 是浏览器携带数据的一种机制，既可承载不透明会话 ID，也可承载令牌。对浏览器应用，通常优先把敏感会话凭据放入 Secure; HttpOnly; SameSite Cookie，降低被脚本读取和跨站发送的风险；仍需结合 CSRF、XSS、会话固定、超时、退出和并发会话策略。

8.10 认证、会话和授权是三件事

认证（Authentication）：你是谁？
会话（Session）：后续请求怎样持续关联这个身份？
授权（Authorization）：这个身份能否对这个具体资源执行这个动作？

登录成功不代表用户可以访问所有接口。每个敏感请求都应在服务端执行授权检查，例如"用户 A 是否有权读取订单 123"，不能只判断"已经登录"。

8.11 第三方登录、OAuth 2.0、OpenID Connect 与 Passkey

"使用某平台登录"通常不是把第三方账号密码交给当前网站。当前网站把浏览器重定向到身份提供方（IdP），用户只在 IdP 的可信页面完成认证；随后网站通过授权码换取令牌并建立自己的本地会话。

图 12　OAuth 2.0 / OpenID Connect 第三方登录流程

OAuth 2.0 的核心是授权委托，解决"客户端能代表用户访问哪些资源"；
OpenID Connect 在 OAuth 2.0 之上增加身份层，用 ID Token 等机制回答"用户是谁"；
授权码流程配合 PKCE、state 和 nonce 可降低授权码拦截、请求伪造和重放风险；
当前网站必须验证令牌签名、签发者 issuer、受众 audience、过期时间等，不能只解码 JSON；
Passkey/WebAuthn 使用公钥凭据并绑定站点来源，可显著降低共享秘密泄露和钓鱼风险，但账户恢复流程仍是安全边界。

9. 常见网站协议与软件生态

9.1 不要把"端口"当成"协议本身"

端口是传输层复用标识。IANA 为常见服务登记默认端口，但应用可以在其他端口运行；防火墙看到 TCP/443 也不能仅凭端口绝对断言它一定是合法 HTTPS。加密、代理和隧道还会让"外层协议"与"内层业务"不同。

业务	常见协议与端口	传输	主要用途	安全要点
Web	HTTP `80`、HTTPS `443`	TCP；HTTP/3 使用 UDP/QUIC	页面、API、文件	公网业务应优先 HTTPS；80 常仅重定向
域名	DNS `53`、DoT `853`、DoH `443`	UDP/TCP；TLS/HTTPS	名称解析	防劫持、缓存投毒、递归器访问控制
远程管理	SSH `22`	TCP	命令、隧道、SFTP	密钥/MFA、限制来源、禁弱口令
邮件发送	SMTP `25/465/587`	TCP，常叠加 TLS	服务器间/客户端提交邮件	STARTTLS 策略、SPF/DKIM/DMARC
文件传输	SFTP `22`、FTPS	TCP	文件管理	不要把 SFTP 与 FTP 混淆；禁明文 FTP
数据库	PostgreSQL `5432`、MySQL `3306`	TCP	应用数据访问	通常只在私网开放，强认证与 TLS
缓存	Redis `6379`（常见默认）	TCP	缓存、会话、队列	不应裸露公网；启用 ACL/TLS/隔离
可观测性	OTLP `4317/4318` 等	gRPC/HTTP	指标、日志、追踪	防止遥测泄露凭据与个人数据
实时双向	WebSocket over HTTP(S)	TCP	聊天、推送、协作	验证 Origin、鉴权、心跳与背压
RPC	gRPC over HTTP/2	TCP/TLS	服务间调用	mTLS、截止时间、重试与幂等性

表中的端口只是常见默认值。生产设计应以实际监听、服务发现和策略为准。

9.2 WebSocket、SSE 与轮询

技术	方向	连接特点	适合场景	注意事项
短轮询	客户端周期请求	实现简单，请求多	低频状态检查	空请求开销、延迟受周期限制
长轮询	服务端延迟响应	兼容 HTTP，中等复杂度	通知、兼容旧环境	超时、重连、连接占用
SSE	服务端 → 浏览器	HTTP 流，浏览器自动重连	事件推送、日志流	主要是单向，代理缓冲需配置
WebSocket	双向	从 HTTP 握手升级为长连接	聊天、协作、实时控制	鉴权续期、心跳、背压、连接扩容

建立 WebSocket 后，反向代理必须正确传递升级首部并设置适当的空闲超时。长连接会改变容量模型：每秒请求数不再是唯一指标，在线连接数、每连接内存和广播扇出同样关键。

9.3 REST、RPC 与消息队列不是互斥选项

REST 风格强调资源、标准 HTTP 语义和可缓存性，适合开放 API 与通用集成；
gRPC 强类型、基于 HTTP/2，适合受控环境中的服务间调用和流式通信；
消息队列用于异步解耦、削峰和失败重试，适合邮件发送、图片处理、事件传播；
Webhook 是服务端向外部 HTTP 端点推送事件，需要签名、防重放和重试策略。

同步调用表达"现在需要结果"，异步消息表达"任务已被接受，稍后处理"。把慢任务直接塞进登录或下单请求，会放大超时和资源占用；但把强一致交易完全异步化，又会带来状态协调难题。选择应来自业务一致性与时延要求。

9.4 常见软件在栈中的位置

图 13　常见 Web 软件在技术栈中的位置

软件名称不是架构。NGINX 既可提供静态文件，也可反向代理和负载均衡；Envoy 可承担边缘代理或服务网格数据面；Node.js 既是运行时，也能直接监听 HTTP。真正需要说明的是：组件处于哪个信任边界，终止哪条连接，掌握哪些密钥，负责哪些超时和重试。

第四部分：服务器部署、配置与安全边界

10. 从单机到高可用：三种部署形态

10.1 学习与低流量单机

复制代码

Internet
   │ 80/443
主机防火墙
   │
NGINX/Caddy ── 本机回环地址 ── 应用进程
                                  │
                              PostgreSQL

优点是成本低、易理解、易备份；缺点是单点故障、资源争用和安全边界较弱。即使同机，也应让数据库只监听回环或内部接口，使用独立低权限账户，并把静态入口与应用进程分开。

10.2 生产三层网络

图 14　生产环境的网络分区与访问边界

核心思想不是"堆三层防火墙"，而是建立可验证的最小通信矩阵：

源区域	目标区域	允许的典型流量	默认策略
Internet	公开入口	TCP 80/443；需要 HTTP/3 时 UDP 443	其他拒绝
公开入口	应用子网	指定应用端口、健康检查	只允许负载均衡/代理地址
应用子网	数据库	PostgreSQL 5432 或 MySQL 3306	只允许应用身份与必要主机
应用子网	缓存/队列	对应内部端口	不对公网暴露
数据子网	Internet	补丁、备份等经受控出口	默认无直接出口或严格代理
管理网	各层管理面	SSH、RDP、数据库管理端口	强认证、审计、限源

10.3 云原生/容器集群

容器将进程隔离并打包，Kubernetes 等编排系统负责副本、调度和服务发现。典型流量是：

复制代码

外部负载均衡 → Gateway/Ingress → Service → Pod
Pod → Service/DNS → 其他 Pod 或托管数据库

每个 Pod 可以有独立 IP，但 Pod 会重建、地址会变化，Service 提供稳定虚拟入口，EndpointSlice 维护当前后端。NetworkPolicy 控制 Pod 的入站和出站，但只有支持该能力的网络插件才会真正执行策略。生产环境应明确：

集群入口由 Gateway API、Ingress 或 Service LoadBalancer 中的哪一层负责；
TLS 在外部负载均衡、网关还是 Pod 终止；
东西向流量是否使用 mTLS；
网络策略是否默认拒绝，再按业务放行；
Secret 如何加密、轮换与限制读取；
数据库是否在集群外，以及故障域如何隔离。

10.4 高可用不只是"多开几台"

图 15　跨故障域高可用与数据恢复架构

冗余只有在故障独立、流量能切换、数据能恢复时才有效。两个应用副本若位于同一宿主机，共享同一个电源故障域；数据库有副本但从未演练切换，也不能证明恢复能力。应明确：

RTO：允许多长时间恢复服务；
RPO：最多可接受丢失多少时间范围的数据；
健康检查是只看进程存活，还是验证关键依赖；
自动重试是否会放大故障；
备份能否在隔离环境实际还原。

11. 一套可解释的参考服务器配置

以下示例用于展示配置逻辑，不应不经修改地复制到生产环境。域名、证书路径、网段、资源限制和安全首部都必须按实际系统调整。

11.1 目标拓扑

python 复制代码

Internet
  │ TCP 80/443（可选 UDP 443）
  ▼
NGINX 10.20.1.10
  │ HTTP 10.20.2.15:8080、10.20.2.16:8080
  ▼
应用实例
  │ TLS/TCP 5432；内部 DNS：db.internal.example
  ▼
PostgreSQL 10.20.3.20

11.2 NGINX 反向代理示例

bash 复制代码

# /etc/nginx/conf.d/example.conf

limit_req_zone $binary_remote_addr zone=login_per_ip:10m rate=5r/m;

upstream app_backend {
    least_conn;
    server 10.20.2.15:8080 max_fails=3 fail_timeout=10s;
    server 10.20.2.16:8080 max_fails=3 fail_timeout=10s;
    keepalive 32;
}

server {
    listen 80;
    listen [::]:80;
    server_name www.example.test;
    return 308 https://$host$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;  # 具体语法以安装版本的官方文档为准

    server_name www.example.test;
    ssl_certificate     /etc/ssl/example/fullchain.pem;
    ssl_certificate_key /etc/ssl/example/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;

    client_max_body_size 10m;
    proxy_connect_timeout 3s;
    proxy_send_timeout 30s;
    proxy_read_timeout 30s;

    add_header Strict-Transport-Security "max-age=31536000" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    location = /api/login {
        limit_req zone=login_per_ip burst=5 nodelay;
        proxy_pass http://app_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Request-ID $request_id;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    location /api/ {
        proxy_pass http://app_backend;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Request-ID $request_id;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    location /assets/ {
        root /srv/www/example;
        try_files $uri =404;
        expires 7d;
        add_header Cache-Control "public, max-age=604800, immutable";
    }
}

配置背后的逻辑：

80 端口只做 HTTPS 重定向；HSTS 只应在确认所有子域和证书策略后扩大范围；
TLS 私钥只让需要终止 TLS 的进程读取；
入口显式设置 Host、协议信息和请求 ID；
登录接口单独限速，但真实防护还应结合账号维度、设备风险和全局风控；
上游设置连接和读取超时，防止请求永久占用资源；
静态资源用内容哈希文件名时才适合长时间 immutable 缓存；
CSP、CORS 等策略必须根据实际前端资源制定，不能机械复制。

11.3 应用配置与 Secret

应用配置可以通过环境变量或配置文件注入，但敏感值应来自专门 Secret 管理系统，并防止进入日志、崩溃转储、构建记录和版本库。

bash 复制代码

APP_ENV=production
LISTEN_ADDRESS=10.20.2.15
LISTEN_PORT=8080
DATABASE_HOST=db.internal.example
DATABASE_PORT=5432
DATABASE_NAME=appdb
DATABASE_USER=app_role
DATABASE_SSLMODE=verify-full
DATABASE_PASSWORD=<由密钥管理系统在运行时注入>
SESSION_TTL_SECONDS=1800
TRUSTED_PROXY_CIDRS=10.20.1.0/24

不要把真实密码直接写在 .env 示例中；不要在异常信息中打印完整连接串。更成熟的环境可使用短期数据库凭据、工作负载身份、客户端证书或自动轮换的动态 Secret。

11.4 PostgreSQL 访问控制示例

bash 复制代码

# postgresql.conf（仅示意）
listen_addresses = '10.20.3.20'
password_encryption = 'scram-sha-256'
ssl = on
# pg_hba.conf：规则自上而下匹配，顺序有意义
hostssl  appdb  app_role  10.20.2.0/24  scram-sha-256
host     all    all       0.0.0.0/0     reject

hostssl 规则要求 TLS 连接，并把来源限制为应用子网；数据库角色 app_role 只应拥有应用所需的表和操作权限，不应是超级用户。数据库还需要：

验证服务端证书而不只是"加密但不验身份"；
设定连接上限、语句超时和空闲事务超时；
审计权限变更和高风险操作；
对备份加密，并定期做恢复演练；
把迁移账号与运行账号分离，避免应用日常拥有 DDL 权限。

11.5 主机防火墙的最小暴露原则

以下是策略示意，不是直接执行脚本：

主机	监听	来源限制
反向代理	`80/tcp`、`443/tcp`，可选 `443/udp`	公网；管理端口仅管理网
应用服务器	`8080/tcp`	仅反向代理子网
PostgreSQL	`5432/tcp`	仅应用子网和受控管理源
Redis	内部端口	仅应用身份/子网，禁止公网
SSH	`22/tcp` 或内部管理端口	VPN/堡垒机/固定管理源，强认证

服务"只监听 127.0.0.1"与"防火墙拒绝公网"是两个独立控制。前者限制绑定接口，后者限制网络路径；纵深防御可同时使用。

11.6 容器网络中的端口发布

容器内服务监听 0.0.0.0:8080，不等于互联网可访问；还取决于容器网络、宿主机端口发布、主机防火墙和云安全组。反之，把数据库发布为 0.0.0.0:5432->5432 可能绕过原本预期的内部隔离。

一个更安全的 Compose 思路是只发布入口端口，让应用与数据库通过内部网络通信：

bash 复制代码

services:
  proxy:
    image: nginx:stable
    ports:
      - "80:80"
      - "443:443"
    networks: [frontend]

  app:
    image: registry.example.test/app:2026.08
    expose: ["8080"]
    networks: [frontend, backend]

  db:
    image: postgres:stable
    expose: ["5432"]
    networks: [backend]
    volumes:
      - db_data:/var/lib/postgresql/data

networks:
  frontend: {}
  backend:
    internal: true

volumes:
  db_data: {}

镜像标签、Secret、备份、健康检查、资源限制、只读文件系统和非 root 用户等仍需补充。示例的重点是：expose 用于容器网络内可见性，只有必要入口使用 ports 发布到宿主机。

12. 安全设计：每一层都只解决一部分问题

12.1 威胁与控制矩阵

层次	典型威胁	主要控制	不能替代什么
物理/链路	非授权接入、ARP 欺骗、恶意 AP	802.1X、端口安全、无线加密、分段	应用认证
网络	扫描、伪造、横向移动、路由劫持	ACL、防火墙、网络策略、RPKI/路由安全	输入校验
传输/TLS	窃听、篡改、伪装服务端	TLS 1.3、证书验证、mTLS	业务授权
HTTP 边缘	DDoS、恶意请求、机器人、首部攻击	CDN、限速、WAF、规范化、大小/超时限制	修复应用逻辑漏洞
应用	SQL 注入、XSS、CSRF、越权、逻辑滥用	参数化、输出编码、CSRF 防护、逐资源授权	数据库备份
身份	凭据填充、会话劫持、钓鱼	MFA/Passkey、强会话、风险检测、失窃密码阻断	最小权限
数据	泄露、误删、勒索、损坏	最小权限、加密、审计、备份恢复	高可用与业务连续性
供应链/运维	恶意依赖、错误配置、密钥泄露	锁定依赖、签名、扫描、变更审核、Secret 管理	运行时监测

12.2 TLS 终止点决定可见性与信任边界

图 16　多段 TLS 连接与信任边界

每次 TLS 终止都产生一个能看见明文的受信任节点。设计评审时应问：谁能读取私钥？谁能读取 HTTP 正文？后端链路是否跨越不可信网络？日志是否会记录敏感字段？

12.3 常见 Web 漏洞的机制

SQL 注入

根因是把不可信输入解释为 SQL 结构。防护以参数化查询为主，辅以最小权限、输入约束和异常监控。WAF 只能降低部分攻击，不可替代代码修复。

XSS

根因是把不可信数据当作浏览器可执行内容。防护包括上下文相关输出编码、安全模板、避免危险 DOM API、内容安全策略（CSP）以及 Cookie 的 HttpOnly。HttpOnly 不能阻止脚本代表用户发请求，因此仍要修复 XSS。

CSRF

浏览器会自动携带某些 Cookie，攻击站点可能诱导浏览器向目标站点提交请求。防护包括 SameSite Cookie、CSRF Token、校验 Origin/Referer，以及对高风险操作重新认证。仅允许 POST 不是 CSRF 防护。

越权/IDOR

根因是服务端只检查"已登录"，没有验证当前用户是否有权操作目标资源。对象 ID 随机化可降低猜测，但不能替代逐对象授权。

SSRF

服务端替用户请求 URL 时，攻击者可能访问云元数据、内网管理接口或本机服务。需要目标允许列表、网络出口控制、DNS/重定向复核和元数据服务保护。

12.4 认证系统的防御组合

图 17　认证系统的纵深防御流程

12.5 超时、重试和限流也是安全边界

资源耗尽型攻击常利用"慢"：慢速发送请求头、超大请求体、长期不读响应、慢 SQL、无限重试。每一跳都应有预算：

连接建立超时；
TLS 握手超时；
请求头/请求体大小和读取超时；
上游连接与响应超时；
数据库语句与锁等待超时；
队列最大积压和任务执行期限；
客户端总截止时间。

重试只能针对可重试、幂等或带幂等键的操作，并使用指数退避、抖动和重试上限。若三层组件各重试三次，一个失败请求可能放大为 27 次下游调用，这就是"重试风暴"。

第五部分：性能、可观测性与故障定位

13. 性能从哪里来：减少距离、工作量与等待

13.1 一次请求的延迟预算

总时延不是某一个"服务器耗时"，可粗略拆为：

复制代码

总时延 ≈ DNS + 建连 + TLS + 网络往返 + 排队 + 应用计算
       + 缓存/数据库/外部服务 + 响应传输 + 浏览器渲染

建立连接的开销可通过 DNS 缓存、连接复用、TLS 会话恢复、HTTP/2/3 减少；应用和数据延迟则需要查询优化、缓存、并发控制和依赖治理。不要用 CDN 掩盖动态 API 的慢数据库，也不要通过无限增大线程池掩盖下游容量不足。

13.2 缓存的层次

缓存位置	缓存对象	优势	一致性风险
浏览器	静态资源、可缓存响应	最接近用户，零网络开销	版本更新困难，需内容哈希/正确策略
CDN	公共静态/部分动态内容	减少跨网时延与源站压力	缓存键、Cookie、鉴权数据泄露
反向代理	页面/API 响应	统一治理	错误缓存用户私有内容
应用内存	热点对象、配置	极快	多实例不一致、重启丢失
Redis/Memcached	共享热点与会话	跨实例共享	缓存穿透、击穿、雪崩、失效竞态
数据库缓冲池	表页与索引页	对查询透明	内存竞争、错误索引仍会慢

缓存设计必须回答：键是什么、值能否跨用户共享、何时失效、源数据失败时怎样降级、缓存未命中是否会同时压垮数据库。

13.3 数据库性能的逻辑顺序

确认查询语义和返回数据量正确；
用执行计划判断扫描、连接和排序成本；
为选择性强、访问频繁的条件建立适当索引；
避免 N+1 查询和无界列表；
缩短事务，减少锁持有时间；
限制连接池，避免连接数压垮数据库；
读副本、分区、分片只能在瓶颈明确后引入。

把所有列都加索引会增加写放大和存储；把所有读取都送副本会遇到复制延迟。性能优化是对具体负载的权衡，不是组件清单。

13.4 排队、背压与过载保护

当到达速率持续高于处理速率，队列必然增长，时延上升，最终发生超时和雪崩。系统应在过载时尽早拒绝低优先级工作，而不是让所有请求慢慢超时。

图 18　限流、排队、背压与过载保护

13.5 指标、日志与追踪

**指标（Metrics）**回答"系统总体怎样"，适合速率、错误率、延迟分位数、饱和度和容量趋势；
**日志（Logs）**记录离散事件与上下文，适合错误详情、审计和取证；
**分布式追踪（Traces）**沿请求跨服务记录 Span，适合定位哪一跳变慢或失败。

三者应通过时间、服务名和请求/追踪 ID 关联，但日志中不要记录密码、完整会话令牌、私钥、支付卡数据等敏感信息。X-Request-ID 可以在入口生成并传递；分布式追踪则使用标准 Trace Context。

推荐围绕四类黄金信号组织监控：

信号	示例	解释
延迟	p50、p95、p99，按路由/状态码	尾延迟往往比平均值更能反映体验
流量	请求/秒、连接数、吞吐字节	描述当前负载
错误	5xx、超时、依赖错误、登录失败率	区分系统故障与业务拒绝
饱和度	CPU、内存、队列、连接池、磁盘 I/O	说明离容量上限还有多远

14. 分层排障：从"完全不通"到"业务错误"

14.1 一条严密的排障路径

图 19　分层网络与 Web 故障定位流程

顺序的价值在于减少猜测。例如：

DNS 不正确时，不必先调 SQL；
TCP 连接都建立不了时，HTTP 状态码尚不存在；
TLS 证书失败时，应用可能根本没收到请求；
HTTP 返回 401/403 时，网络层多数已经工作，应查身份和授权；
HTTP 返回 502/504 时，应重点看代理到上游的连接和超时。

14.2 跨平台诊断工具

目标	Linux/macOS 示例	Windows/PowerShell 示例	观察点
地址与接口	`ip addr` / `ifconfig`	`Get-NetIPConfiguration`	IP、前缀、DNS、网关
路由表	`ip route`	`Get-NetRoute` / `route print`	默认路由、更具体路由、接口
邻居表	`ip neigh` / `arp -a`	`Get-NetNeighbor` / `arp -a`	默认网关 MAC、状态
DNS	`dig +trace name`、`resolvectl query`	`Resolve-DnsName name`	记录、TTL、解析器差异
路径	`traceroute` / `tracepath`	`tracert`	哪一跳后无响应；注意设备可丢弃探测
端口	`nc -vz host 443`	`Test-NetConnection host -Port 443`	TCP 建连而非业务健康
HTTP/TLS	`curl -v https://host/`	`curl.exe -v https://host/`	DNS、连接、TLS、状态码、重定向
证书	`openssl s_client -connect host:443 -servername host`	安装 OpenSSL 后同左	SNI、证书链、ALPN
本机监听	`ss -lntup`	`Get-NetTCPConnection -State Listen`	服务监听地址和端口
抓包	`tcpdump` / Wireshark	Wireshark / pktmon	握手、重传、RST、ICMP、时序

抓包应遵守授权和隐私要求。HTTPS 正文通常不可见，但仍可观察 DNS、IP、端口、握手、包长、方向、重传和时序。服务器侧若掌握会话密钥或使用调试环境，可以在合规前提下进行更深入分析。

14.3 症状---层次---原因矩阵

症状	优先层次	常见原因	下一步证据
域名不存在	DNS	记录缺失、委派错误、缓存负响应	`Resolve-DnsName`/`dig`、权威查询
域名有 IP，但端口不通	L3/L4	路由、防火墙、服务未监听、安全组	路由表、端口测试、服务监听、策略日志
TCP 通但 HTTPS 失败	TLS	证书过期、域名不匹配、SNI、时间错误	TLS 握手详情和证书链
`404`	HTTP/L7 路由	Host/Path 错误、虚拟主机未匹配	代理访问日志、路由配置
`401`	认证	未登录、令牌失效、签名/时钟问题	认证日志、Cookie/Authorization 首部
`403`	授权/策略	已识别身份但权限不足，或 WAF 拒绝	授权决策日志、WAF 规则 ID
`502`	网关→上游	上游拒绝连接、协议不匹配、崩溃	代理错误日志、上游监听与健康
`504`	网关→上游	慢 SQL、线程池耗尽、下游超时	Trace、数据库慢查询、队列指标
偶发慢	拥塞/排队	丢包重传、GC、锁、连接池、热点	p99、抓包、Trace、饱和度
登录总失败但数据库可用	应用身份/数据	哈希参数、账号状态、时间、MFA、规范化	结构化认证审计，不记录密码

14.4 "ping 不通"不等于"网站不通"

ping 使用 ICMP Echo。很多网络会限制 ICMP，但允许 TCP/443；也可能 ICMP 正常而 HTTPS 端口被防火墙拒绝。应选择与业务一致的探测：网站用 HTTPS 请求，数据库用受控来源进行协议级探测，健康检查用能代表关键功能但成本可控的端点。

14.5 分布式系统中的超时定位

假设浏览器 10 秒超时，CDN 8 秒、反向代理 5 秒、应用调用数据库 6 秒。外层超时可能先触发，应用仍在后台运行并最终写入数据；用户重试就可能产生重复操作。正确做法是建立递减的截止时间预算，让内层调用早于外层结束，并对会产生副作用的操作使用幂等键和可查询状态。

第六部分：三个架构例子与综合推演

15. 示例一：校园博客/课程网站

15.1 需求

流量不大，读多写少；
需要登录、文章、图片和后台管理；
希望维护简单，但不能明文保存密码或暴露数据库。

15.2 合理架构

复制代码

DNS → CDN（静态图片和 CSS/JS） → Caddy/NGINX → 单个应用服务
                                              ├→ PostgreSQL（内网/本机受限接口）
                                              └→ 对象存储（图片）

设计理由：

CDN 缓存公开静态资源，降低源站带宽；
入口自动或集中管理 TLS；
应用先保持单体，避免无必要的微服务复杂度；
PostgreSQL 每日备份并定期恢复验证；
管理入口通过 MFA，数据库不开放公网；
密码采用成熟框架的 Argon2id/scrypt 配置。

此场景的首要风险不是"没有上 Kubernetes"，而是备份不可恢复、弱口令、依赖未更新和权限过大。

16. 示例二：电商登录与下单

16.1 关键差异

登录可以容忍短暂失败重试，下单和支付却不能重复扣款。架构需要：

登录：账号/IP/设备多维限流、MFA、异常登录通知；
商品：CDN 与多级缓存，但价格/库存需明确一致性；
下单：客户端生成或服务端签发幂等键；
支付：调用外部支付服务，Webhook 验签并防重放；
库存：事务、锁或原子条件更新，不能只看缓存；
审计：订单状态机只允许合法跃迁。

图 20　电商下单、支付与幂等处理时序

网络可靠传输不能提供业务"恰好一次"。TCP 重传字节不会让同一连接重复交付给应用，但客户端、代理或消息系统的重试仍可能让业务请求执行多次。业务幂等必须由唯一键、状态机和事务保证。

17. 示例三：实时音视频/在线游戏

此类业务对时延和抖动敏感，少量过期数据的价值可能低于等待重传。常采用 UDP、RTP/RTCP、WebRTC 或自定义可靠层：

音视频帧带时间戳和序列号；
丢失关键帧时请求刷新，普通过期帧可丢弃；
使用抖动缓冲平滑到达时间变化；
NAT 穿越需要 STUN，无法直连时经 TURN 中继；
信令可使用 HTTPS/WebSocket，媒体路径使用不同协议；
自适应码率根据带宽、丢包和 RTT 调整。

图 21　实时音视频的信令、直连与中继路径

这个例子再次说明：一个"网站功能"可以同时使用多个连接和协议；HTTPS 负责页面和信令，不代表所有媒体数据都通过 HTTP 传输。

第七部分：建立完整心智模型

18. 十个最重要的因果关系

域名先被解析为地址，地址再由路由系统送达。 DNS 不选择逐跳路径。
跨子网时，客户端把帧交给默认网关，而 IP 目标仍是远端服务器。 因此只需解析下一跳 MAC。
交换机解决同链路交付，路由器解决跨网络转发。 三层交换机只是把路由功能集成到交换平台。
NAT 改写地址并维护状态，防火墙执行允许/拒绝策略。 两者可同机，但概念不同。
TCP/QUIC 解决传输，TLS 解决安全信道，HTTP 解决业务报文语义。 任一层成功都不能推出上层必然成功。
反向代理会终止前端连接并建立后端连接。 所以代理到应用也有独立的 DNS、端口、TLS、超时和故障。
网站用户凭据与数据库服务凭据分离。 用户密码哈希用于应用认证，数据库连接使用应用角色。
认证成功之后仍必须进行会话保护和逐请求授权。 "已登录"不是访问所有对象的通行证。
高可用需要独立故障域、可切换入口和可恢复数据。 多副本不等于可恢复。
排障必须从证据和层次出发。 名称、路由、端口、TLS、HTTP、应用、依赖、数据依次验证。

19. 一张总表：组件、输入、状态与故障表现

组件/层	读取什么	保存什么状态	输出/决策	常见故障表现
DNS 解析器	域名、记录类型	缓存及 TTL	A/AAAA/CNAME 等	域名失败、旧地址、解析慢
交换机	源/目标 MAC、VLAN	MAC 表	出端口	同网段不通、环路、广播异常
路由器	目标 IP、路由表	路由/邻居/队列	下一跳与出接口	跨网不通、绕路、TTL 超时
NAT	五元组	转换表与超时	改写后的地址/端口	映射超时、端口耗尽、回流失败
防火墙	五元组、状态、策略	连接状态/日志	允许、拒绝、丢弃	超时或拒绝连接
TLS 端点	ClientHello、证书、密钥	会话密钥/恢复状态	加密应用通道	证书或握手错误
反向代理	HTTP Host/Path/Header	连接池、限流、健康	静态响应或上游选择	404、429、502、504
应用服务器	HTTP/RPC 业务数据	进程状态、临时上下文	业务响应、下游调用	4xx/5xx、慢请求、内存/线程耗尽
会话/缓存	Key、TTL	临时状态	命中值/未命中	登录丢失、缓存雪崩、脏数据
数据库	SQL、事务、角色	持久数据、锁、日志	结果集/提交/回滚	慢查询、死锁、连接耗尽、复制延迟
消息队列	消息、主题、确认	积压、偏移/确认状态	投递、重试、死信	延迟增长、重复消费、丢消息风险

20. 自测：能否独立解释这些问题

为什么访问外网时 ARP 的通常是网关，而不是网站服务器？
一台家庭无线路由器实际上组合了哪些逻辑角色？
路由表的最长前缀匹配怎样覆盖默认路由？
NAT 改变了什么，防火墙又决定了什么？
HTTP/2 和 HTTP/3 的多路复用为什么面对丢包时表现不同？
TLS 在 CDN 终止后，CDN 到源站是否自动安全？
反向代理返回 502 和 504 分别暗示什么？
为什么用户密码不应直接用于连接数据库？
盐、Pepper、密码哈希和加密之间有什么区别？
Cookie、会话 ID 和 JWT 分别是什么概念？
为什么数据库连接池过大反而可能降低系统稳定性？
为什么 TCP 可靠也不能保证下单"只执行一次"？
只有 ping 结果能否判断网站健康？
如果域名有 IP、443 可连、证书正确，但登录超时，下一步应查什么证据？

如果能从"哪个组件读取什么信息、维护什么状态、在哪个边界建立了新连接"三个角度回答，说明已经形成了可用于设计和排障的网络心智模型。

附录 A：协议栈速查表

层次	协议/技术	关键标识	核心能力
应用	HTTP、DNS、SSH、SMTP、WebSocket、gRPC	域名、URL、方法、状态码、应用字段	业务语义与应用交互
安全会话	TLS 1.3、mTLS	证书、SNI、ALPN、会话密钥	身份、机密性、完整性
传输	TCP	端口、序列号、窗口、标志位	可靠有序字节流
传输	UDP	端口、数据报长度	轻量尽力而为数据报
传输	QUIC	Connection ID、Stream ID	加密、多流、可靠传输、连接迁移
网际	IPv4/IPv6、ICMP	IP、前缀、TTL/Hop Limit	跨网络寻址和诊断
路由控制	OSPF、IS-IS、BGP	前缀、下一跳、路径属性	生成可达路径
链路	Ethernet、Wi‑Fi、VLAN	MAC、VLAN ID	本链路帧交付与隔离
邻居/配置	ARP、NDP、DHCP	IP↔MAC、租约参数	下一跳解析、自动配置

附录 B：上线前检查清单

B.1 网络与入口

DNS 记录、TTL、权威委派和故障切换策略已验证。
IPv4 与 IPv6 均按预期配置；若发布 AAAA，IPv6 路径也必须真实可用。
公网只暴露必要端口；数据库、缓存、管理面没有意外发布。
安全组、网络 ACL、主机防火墙和容器端口发布的规则一致。
反向代理有连接、头部、请求体、上游和空闲超时。
健康检查能代表实例可服务，但不会对数据库制造高压。
代理首部在可信边界内重写，应用配置了可信代理范围。

B.2 TLS 与 HTTP

证书覆盖全部域名，自动更新和到期告警已经测试。
仅启用合适的 TLS 版本与密码套件，私钥权限最小。
后端跨不可信边界时使用 TLS/mTLS，并验证服务身份。
HTTP→HTTPS 重定向、HSTS 范围与回滚风险经过评估。
Cookie 使用 Secure、HttpOnly 和合适的 SameSite。
CORS 仅允许必要来源，不使用"带凭据的任意来源"。
缓存策略区分公共与私有内容，认证响应使用 no-store 等合适策略。

B.3 应用与身份

密码使用成熟密码 KDF；不存在明文、可逆密文或快速散列存储。
登录有账号/IP/设备维度的限速、退避和审计。
支持 MFA 或抗钓鱼认证，敏感操作有再认证。
登录失败不泄露账号存在性，日志不记录密码和令牌。
会话在登录后轮换标识，支持超时、注销、撤销和密钥轮换。
每个资源和动作在服务端执行授权，不依赖前端隐藏按钮。
SQL 全部参数化；输出编码与上下文匹配；CSRF/XSS/SSRF 有针对性控制。

B.4 数据、可靠性与运维

应用数据库账号最小权限；迁移账号和运行账号分离。
连接池总量按全部副本计算，预留故障和管理连接。
数据库启用合适认证与 TLS，未开放到公网。
备份加密、版本化、跨故障域保存，并完成恢复演练。
明确 RTO/RPO，故障切换和回滚流程经过演练。
指标、日志、追踪可关联；告警基于用户影响和 SLO。
依赖版本、镜像来源、构建产物和 Secret 变更可追溯。
重试有截止时间、指数退避、抖动和次数上限；高价值操作有幂等键。

附录 C：术语辨析

易混术语	正确区分
互联网 / Web	互联网是互联网络基础设施；Web 是运行其上的应用体系之一
域名 / URL	域名标识命名空间节点；URL 还包含协议、路径、查询等资源定位信息
主机 / 服务器	主机是联网计算实体；服务器既可指提供服务的软件，也可指运行它的机器
Web 服务器 / 应用服务器	前者侧重 HTTP、TLS、静态内容和代理；后者侧重业务逻辑；可合并实现
网关 / 路由器	路由器是典型三层转发设备；网关是跨边界角色，可位于多种层次
交换 / 路由	交换常指同二层域按 MAC 转发；路由按 IP 前缀跨网络转发
带宽 / 吞吐 / 时延	带宽是容量；吞吐是实际传输速率；时延是完成或到达所需时间
加密 / 哈希	加密可用密钥恢复明文；哈希通常单向；密码应使用专用慢哈希/KDF
认证 / 授权	认证确认身份；授权判断该身份能否执行具体操作
Cookie / Session / JWT	Cookie 是浏览器携带机制；Session 是状态关联；JWT 是令牌格式
代理 / NAT	代理终止并重建应用或传输连接；NAT 主要改写网络/传输地址并维护映射
负载均衡 / 高可用	负载均衡分发流量；高可用还需要故障检测、切换、数据恢复和独立故障域

参考资料与延伸阅读

以下优先列出标准组织和项目官方文档，适合继续深入：

IETF, RFC 9293: Transmission Control Protocol (TCP)。
IETF, RFC 768: User Datagram Protocol。
IETF, RFC 1034: Domain Names --- Concepts and Facilities 与 RFC 1035。
IETF, RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3。
IETF, RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport。
IETF, RFC 9110: HTTP Semantics、RFC 9113: HTTP/2、RFC 9114: HTTP/3。
OWASP, Password Storage Cheat Sheet。
OWASP, Authentication Cheat Sheet。
OWASP, Session Management Cheat Sheet。
NGINX, HTTP Load Balancing 与 HTTP Proxy Module。
PostgreSQL, Client Authentication: pg_hba.conf 与 Authentication Methods。
Kubernetes, Services, Load Balancing, and Networking 与 Network Policies。
IETF, RFC 6749: The OAuth 2.0 Authorization Framework 与 RFC 7636: Proof Key for Code Exchange (PKCE)。
OpenID Foundation, OpenID Connect Core 1.0；W3C, Web Authentication Level 2。

结语

理解 Web 系统的关键，不是记住更多缩写，而是始终追问四个问题：

这一层用什么标识对象？ MAC、IP、端口、域名、URL、用户 ID，不能混用。
这一跳在哪里终止，又在哪里建立了新连接？ NAT、负载均衡、TLS 终止和反向代理都会改变观察边界。
这一层维护了什么状态？ ARP 缓存、路由表、NAT 表、TCP 状态、TLS 会话、登录会话、数据库事务各不相同。
失败时能拿到什么证据？ 抓包、访问日志、错误日志、指标、Trace、查询计划和审计记录应组成连贯证据链。

把一次网站登录从浏览器一路解释到数据库，再把响应按相反方向解释回来，就已经掌握了 Web 服务器、计算机网络、网关、路由器、协议和后端系统之间最核心的联系。接下来无论学习网络安全、云计算、分布式系统还是应用开发，都可以在这套框架上继续增加细节，而不会把概念堆成彼此孤立的名词。

Web 服务器与计算机网络全景原理

摘要

0. 阅读地图：先看全局，再进入细节

0.1 一次访问的全景路径

0.2 全文回答的核心问题

第一部分：网络设备如何协同

1. 分层不是背诵题，而是定位责任的工具

1.1 TCP/IP 模型与 OSI 模型

1.2 五元组与"连接"

1.3 哪些字段会在途中变化

2. 网卡、交换机、无线 AP、路由器和防火墙

2.1 网卡：主机进入网络的接口

2.2 交换机：在一个二层广播域内转发帧

2.3 无线 AP：把 802.11 无线接入桥接到有线网络

2.4 路由器：按最长前缀匹配选择下一跳

2.5 防火墙：对流量执行安全策略

2.6 设备职责对照

3. "网关"到底是什么：一个角色，多种实现

3.1 默认网关

3.2 NAT 网关

3.3 VPN 网关

3.4 互联网网关与云路由表

3.5 API 网关

3.6 服务网格网关

3.7 网关语义总表

4. 从局域网到互联网：寻址、ARP、路由、NAT 与 BGP

4.1 DHCP：让主机获得可用网络参数

4.2 ARP/NDP：只解析本链路的下一跳

4.3 子网、CIDR 与最长前缀

4.4 域内路由与跨域路由

4.5 完整逐跳示例

第二部分：协议怎样把"能到达"变成"能通信"

5. TCP、UDP 与 QUIC

5.1 TCP：可靠、有序的字节流

5.2 UDP：尽力而为的数据报

5.3 QUIC：在 UDP 之上重新组织传输能力

5.4 三者对照

6. DNS、TLS 与 HTTP：从名字到安全的业务语义

6.1 DNS：分布式、层次化、可缓存的命名系统

6.2 TLS：机密性、完整性与服务器身份

6.3 HTTP：请求---响应语义

6.4 HTTP/1.1、HTTP/2、HTTP/3

第三部分：Web 服务器、应用服务器与数据系统

7. Web 服务器的整体原理

7.1 一个监听端口背后发生了什么

7.2 Web 服务器与应用服务器的分工

7.3 正向代理、反向代理和透明代理

7.4 虚拟主机与同一 IP 多网站

7.5 典型三层架构

7.6 负载均衡到底均衡什么

8. 深入案例：一次网站登录究竟发生了什么

8.1 先分清三类完全不同的"账号密码"

8.2 登录全链路时序

8.3 浏览器提交阶段

8.4 反向代理与可信客户端地址

8.5 应用怎样查询账号

8.6 密码在数据库中怎样保存

8.7 数据库连接怎样建立

8.8 参数化查询、事务与索引

8.9 会话 Cookie 与 JWT

8.10 认证、会话和授权是三件事

8.11 第三方登录、OAuth 2.0、OpenID Connect 与 Passkey

9. 常见网站协议与软件生态

9.1 不要把"端口"当成"协议本身"

9.2 WebSocket、SSE 与轮询

9.3 REST、RPC 与消息队列不是互斥选项

9.4 常见软件在栈中的位置

第四部分：服务器部署、配置与安全边界

10. 从单机到高可用：三种部署形态

10.1 学习与低流量单机

10.2 生产三层网络

10.3 云原生/容器集群

10.4 高可用不只是"多开几台"

11. 一套可解释的参考服务器配置

11.1 目标拓扑

11.2 NGINX 反向代理示例

11.3 应用配置与 Secret

11.4 PostgreSQL 访问控制示例

11.5 主机防火墙的最小暴露原则

11.6 容器网络中的端口发布