网络基础原理可视化

这个专题把 DNS、TCP、TLS、HTTP/2、HTTP/3、代理、缓存和 CDN 这些常见网络概念放到可观察的实验中。目标不是背诵协议名词，而是理解一次请求从浏览器发出后，经过解析、连接、握手、转发、缓存和响应的具体路径。

网络问题常常表现为“偶发慢、偶发失败、某地可访问某地不可访问”。要分析这类问题，需要把协议层次、信任边界、缓存状态和时延组成拆开。本站文章会尽量提供命令、字段、时间线和可复现实验，让读者能把抽象概念对应到实际请求。

推荐顺序

可以先从 DNS TTL 缓存和 CIDR/MTU 开始，理解名字解析和路由的基础。随后阅读 TCP 可靠性与拥塞窗口、TLS 1.3 握手和 HTTP CONNECT 代理隧道，逐步建立连接层和加密边界的直觉。最后再看反向代理、缓存重新验证、HTTP/3 和 CDN 瀑布图，把单个请求扩展到真实网站性能分析。

读这些文章时，建议边看边记录请求头、状态码、缓存命中、证书信息和 RTT。网络调试最怕只看最终结论，忽略中间层。只有把每一层的输入输出拆开，才能判断问题来自 DNS、链路、TLS、代理、缓存还是应用本身。

实验边界

本站的网络实验默认在本地环境、公开测试资源或自有服务器上复现。不要把代理、扫描、缓存、TLS 或流量分析材料用于未授权目标。真实网络环境还会受到运营商、Cloudflare、Nginx、浏览器版本、防火墙和缓存策略影响，因此文章输出应作为学习参考，而不是对所有网络环境的保证。

调试证据应该怎么记录

一个网络问题如果只记录“能访问”或“不能访问”，通常没有排查价值。更有用的记录包括 DNS 解析结果、TTL、目标 IP、TLS 证书链、HTTP 状态码、缓存头、重定向链路、首字节时间、响应大小和客户端所在网络。把这些信息按时间顺序保存下来，才能判断问题发生在解析、路由、握手、代理、缓存还是应用层。

本站网络文章会尽量把这些证据放到正文里，而不是只给最终结论。例如缓存重新验证不只看页面是否刷新，还要看 ETag、Last-Modified、Cache-Control、Age、cf-cache-status 和源站响应；代理隧道不只看连接是否建立，还要区分 CONNECT 隧道、TLS 握手和应用层请求分别由谁处理。

从实验到真实故障排查

教学实验通常只控制一两个变量，真实网站会同时受到浏览器缓存、CDN 边缘节点、Nginx FastCGI 缓存、PHP 应用、数据库、证书、DNS 和网络路径影响。读者在迁移文章方法时，应先把系统画成链路图，再逐段确认每一层的输入输出。这样可以避免把 Cloudflare 缓存问题误判为应用问题，也可以避免把客户端 DNS 缓存误判为服务器变更未生效。

这个专题后续会继续补充“故障现象到证据链”的写法：先描述用户看到的症状，再列出可观察指标，随后逐层排除，最后给出修复和验证结果。这样的结构比单独罗列命令更有学习价值，也更接近真实工程排查。