DNS、CDN、Cookie 与 Session

DNS 查询过程

DNS 将域名映射为 IP 地址及其他资源记录。浏览器可能同时请求 IPv4 的 A 记录和 IPv6 的 AAAA 记录。

典型流程：

1. 浏览器、操作系统和本地 hosts 文件先参与解析；命中缓存则按 TTL 直接返回。
2. 本机的 stub resolver 向配置的递归解析器发请求（通常是 ISP、企业 DNS 或公共 DNS）。
3. 递归解析器缓存未命中时，向根 DNS查询，根服务器返回对应 TLD（如 .com）服务器的委派信息。
4. 解析器向 TLD DNS 查询，获得目标域名权威 DNS 的委派信息。
5. 解析器向权威 DNS查询，获得最终的 A/AAAA/CNAME 等记录。
6. 解析器将结果返回客户端，并按 TTL 缓存。若有 CNAME，需继续解析其目标名称。

客户端通常只发起一次“递归查询”；根、TLD、权威服务器之间常见的是解析器代为进行的“迭代查询”。DNS 传统 UDP/53 为主，响应较大或特定场景使用 TCP；也可通过 DoH/DoT 加密查询。

CDN 是什么

CDN（Content Delivery Network）在多个地域部署边缘节点，使用调度系统让用户从合适的节点获取内容。

• 就近/就优访问：调度不只是物理距离，也会考虑网络质量、节点负载、健康状态和运营商。
• 边缘缓存：图片、JS、CSS、视频分片等静态或可缓存内容由节点命中返回；未命中或过期时向源站回源，并按缓存策略保存。
• 源站保护与高可用：大量请求由边缘吸收，异常节点可摘除或切换；CDN 常同时提供 DDoS 防护、TLS 终止和边缘计算能力。

CDN 不自动保证“全局立刻一致”。内容更新应使用版本化文件名（如 app.abc123.js）、合理 TTL 与缓存刷新/失效策略。

Cookie

Cookie 是浏览器保存并按规则随请求自动发送的一小段键值数据。服务端通过 Set-Cookie 设置，浏览器在匹配的后续请求中通过 Cookie 携带。

Set-Cookie: session_id=abc; Path=/; HttpOnly; Secure; SameSite=Lax; Max-Age=3600

重要属性：

属性	作用
Domain / Path	限定可携带到哪些域名与路径
Expires / Max-Age	过期时间；未指定时通常为会话 Cookie
Secure	仅 HTTPS 请求携带
HttpOnly	禁止 JavaScript 读取，缓解 XSS 窃取 Cookie
SameSite	限制跨站请求携带，缓解 CSRF；常用 Lax/Strict/None

Cookie 容量有限（单个通常数 KB，具体由浏览器决定），且会增加匹配请求的头部开销。HttpOnly 不能阻止浏览器在恶意请求中自动携带 Cookie，因此仍需 CSRF 防护。

Session

Session 是服务端保存的用户会话状态，例如登录身份、临时表单或购物车上下文。服务端生成不可预测的 Session ID，并把 ID 常放入 Cookie；请求到达后按 ID 查找对应状态。

维度	Cookie	Session
状态主要存储处	客户端浏览器	服务端（内存、数据库、Redis 等）
容量	较小	取决于服务端资源
篡改风险	客户端可修改，需签名/校验	状态本身不暴露给客户端，但 Session ID 必须防窃取
扩展性	不依赖服务端存储	多实例需共享存储或粘性会话
生命周期	可设过期	服务端过期策略 + 客户端 ID 生命周期

现代无状态认证也可使用签名 Token（如 JWT）。它不等同于“更安全”：撤销、过期、密钥轮换和敏感声明泄露仍需设计；Token 同样应通过安全的传输与存储方式保护。