作为一名 Web 开发者，理解从浏览器地址栏到应用服务器整个链路，能帮助我们定位问题、做出正确的架构与性能选择。本文以入门角度，串起 DNS、HTTPS、负载均衡与后端应用的基本概念。

用户输入 URL
   │
   ├── DNS 解析：域名 → IP
   │
   ├── TCP 建连（三次握手）
   │
   ├── TLS 握手（若为 HTTPS）
   │
   ├── 负载均衡（可终止 TLS / 路由请求）
   │
   └── 应用服务器处理业务逻辑 → 返回响应

---

1. 从地址栏开始，会发生什么？

当用户在浏览器输入 URL（如 https://example.com）并回车后，浏览器会依次完成：

1. 解析域名：通过 DNS 获取目标服务器 IP。
2. 建立连接：与该 IP 上的服务端口（80/443）进行 TCP 建连。
3. 开启 TLS（若为 HTTPS）：完成密钥交换，协商加密套件。
4. 发起 HTTP 请求：携带方法、路径、头部与可选的请求体。
5. 等待响应：解析状态码、响应头与响应体，渲染页面或执行脚本。

HTTP 是无状态协议，单次请求完成后，连接可复用（HTTP/1.1 Keep-Alive、HTTP/2 多路复用），但语义上不记录上一请求的状态——需要状态时，通常借助 Cookie / Token / 会话存储 等机制。

---

2. DNS Query（域名解析）

浏览器要与服务器通信，必须先知道服务器的 IP 地址。这一过程由 DNS 完成，一般包含：

• 浏览器 / 系统缓存：若命中，直接返回 IP。
• 递归解析：向本地 DNS 递归查询，逐步询问根域、顶级域（.com）、权威 NS，最终获得权威记录中的 A/AAAA 结果。
• TTL：记录存活时间，影响缓存与变更生效速度。

线上排障时，dig +trace、nslookup 能快速确认解析是否正确。

---

3. HTTPS（TLS 上的 HTTP）

HTTP 明文传输，任何中间人都能窃听与篡改。HTTPS 通过 TLS 提供机密性与完整性：

• 握手阶段：客户端与服务端协商协议、交换密钥材料、验证服务器证书（由受信任 CA 颁发）。
• 会话建立：双方基于对称密钥加密后续数据。
• 证书与域名：证书的 CN/SAN 必须覆盖访问的域名；证书过期或域名不匹配会导致浏览器警告。

反向代理（如 Traefik、Nginx）常终止 TLS：代理与客户端走 HTTPS，再以 HTTP 或内网 HTTPS 与后端应用通信，便于统一证书与安全策略。

---

4. 负载均衡

一个热门服务通常需要多台应用服务器共同承担流量，这就需要负载均衡：

• 四层 / 七层：L4（基于传输层端口与 IP）与 L7（基于 HTTP 头、路径、Host 等）。
• 常见策略：轮询、最少连接、按权重、基于健康检查的摘除与恢复。
• 职责扩展：TLS 终止、路径/主机路由、压缩与缓存、速率限制、WAF 等。

在 TLS 终止场景中，请求在 LB 解密成原始 HTTP，再按路由规则转发给后端服务（例如 Host=api.example.com → API 服务，PathPrefix=/static → 静态服务）。

---

5. 应用服务器

应用服务器（Node/Go/Java/Python…）负责执行业务逻辑：

• 职责：解析请求 → 鉴权与校验 → 业务处理 → 返回响应。
• 状态管理：应用本身尽量无状态，会话信息放入 Redis 等内存存储；业务数据进入 关系型数据库（如 Postgres）或其他持久化系统。
• 连接与资源：注意数据库连接池、外部服务超时、重试与熔断，避免“雪崩”。
• 可观测性：日志、指标（Metrics）、分布式追踪（Tracing）是定位线上问题的基础。

常见组合：Redis 存放会话与短期缓存（快但容量有限），Postgres 存放核心业务数据（强一致、容量大）。

---

小结与实践建议

• 先把链路图画清楚：DNS → TLS/HTTPS → 负载均衡 → 应用 → 数据存储。
• 客户端 4xx/5xx、代理 502/504、应用超时等，定位时遵循自外向内排查。
• 强化证书与域名管理、健康检查与熔断/超时，避免单点故障。
• 将日志、指标与追踪打通，形成端到端可观测闭环。

当你能将这些基础贯通起来，绝大多数 Web 线上问题都会变得可解释、可复现、可修复。