本文目录
给朋友打电话，先要查号码；拨通后要确认线路；如果谈的是隐私，还得确认对方身份，防止接错人。浏览器访问 HTTPS 网站，也不是一个协议包办到底，而是 DNS、TCP、TLS 分层接力。
四层关卡各自解决什么
DNS 解决“服务器在哪”；TCP 解决“数据怎样可靠地到”；TLS 解决“我连的是谁、内容有没有被偷看”；HTTPS 只是 HTTP 运行在 TLS 保护的通道里。
DNS 不负责传网页
浏览器先询问域名对应的 IP 地址。结果可能来自浏览器缓存、操作系统缓存、局域网 DNS 或递归解析器。解析失败时，后面的 TCP 和 TLS 都不会开始。
example.com -> 93.184.216.34DNS 也可能返回多个地址，让客户端或系统选择更合适的节点。它不是一次永远正确的翻译，TTL 到期后还会重新查询。
TCP 先把线路铺好
TCP 通过三次握手确认双方都能收发数据，并建立序列号、确认号等状态。数据丢失时，它会重传；数据乱序时，接收方会重新整理。代价是建立连接需要往返时间，网络拥塞时还会主动降低发送速度。
连接关闭也不是“按一下挂断”。双方要确认不再发送，半关闭、超时和异常断开都可能让连接处于不同状态。
TLS 要确认身份
TLS 握手会协商加密算法，服务器发送证书，浏览器验证证书是否由可信机构签发、域名是否匹配、是否过期。验证通过后，双方协商出会话密钥，用它加密后续 HTTP 内容。
证书主要解决“你连到的服务器是不是它声称的那一个”，不代表网站业务一定可信，也不代表服务器不会记录你的数据。HTTPS 保护传输途中，应用仍要自己做好权限、输入校验和日志管理。
握手为什么会影响首屏
第一次访问一个主机时，浏览器可能要经历 DNS 查询、TCP 握手和 TLS 握手，每一步都需要网络往返。连接复用、HTTP/2 多路复用和会话恢复可以减少后续成本，所以“第一次打开慢，第二次快”不一定是服务器突然变好了。
这也是资源域名不宜无限拆分的原因。把图片、接口、字体和脚本拆到很多主机，可能增加并行机会，也可能增加 DNS 和 TLS 成本。域名拆分应该由连接、缓存、隔离和部署需求共同决定，而不是看到请求多就机械地增加域名。
证书错误为什么不能随便点继续
浏览器提示证书不匹配、过期或不受信任时，意味着它无法确认通道对端。开发环境可以使用本地证书或测试 CA，但生产环境绕过警告会让中间人攻击变得可能。证书链、域名覆盖、自动续期和服务器时间都应纳入部署检查。
HTTPS 还要求站点正确处理混合内容：HTTPS 页面加载 HTTP 脚本、样式或接口，会被浏览器阻止或降级。一个页面地址改成 HTTPS，不代表它引用的每个资源都自动安全。
TCP 和 TLS 解决的问题不同
TCP 可靠，不等于保密；TLS 加密，不等于应用一定收到完整业务结果。TCP 可以保证字节按序到达，TLS 可以发现内容被篡改，HTTP 再把字节解释成报文。任何一层失败，最终都可能表现为“页面打不开”，但修复位置不同。
抓包或排障时，先判断失败在哪层：域名是否解析，端口是否可连，证书是否通过，HTTP 是否返回，业务是否成功。把所有错误都归为“网络不好”，会让排查失去方向。
为什么不能只加密密码
如果只加密密码，路径、Cookie、搜索内容和响应仍可能被观察或篡改。HTTPS 保护的是通道中的整体 HTTP 传输，让中间网络无法轻易看到正文或偷偷替换内容。
分层的核心价值，是让每一层只对自己承诺的事情负责。DNS 只提供地址，不保证端口可达；TCP 只保证字节可靠有序，不知道字节是不是合法 HTTP；TLS 只保护连接和验证对端，不知道用户是否有权限；HTTP 只表达请求与响应，不知道数据库事务是否已经提交。上层可以建立在下层之上，却不能把下层的承诺扩大成业务成功。
性能问题也因此要按层拆开。DNS 慢是等待解析，TCP 慢是连接往返或拥塞，TLS 慢是握手和证书链，HTTP 慢可能是服务端计算或响应体过大。连接复用能减少握手，但无法替代服务端优化；压缩能减少传输，却可能增加解压和解析成本。优化不是给某一层加速，而是找出当前链路中真正占据关键路径的那一段。
DNS 解析结果还会影响负载均衡和故障切换。多个 A/AAAA 记录不代表每次都会按你想象的顺序选择；IPv6 可用性、运营商线路和本地缓存都会改变实际路径。CDN 使用 CNAME 把域名交给另一套解析体系后，最终地址可能离用户更近，也可能因为配置错误绕到很远的节点。
TCP 的三次握手并不是为了“确认三句话”，而是为了让双方都确认初始序列号和收发能力，避免旧连接中的延迟数据被误认成新连接。连接建立后，确认号、窗口和拥塞控制共同决定发送速度。应用看到的是一个可以读写的流，却看不到每个包的重传细节。
TLS 的证书和密钥也承担不同角色。证书把公钥和域名身份绑定，握手期间用非对称密码学协商信任，后续大量数据通常用更高效的对称密钥加密。私钥泄露、证书误签和信任根被加入，都可能破坏“我连的是正确服务器”这个前提。
HTTPS 页面里的安全边界还会延伸到 WebSocket、图片、字体和 API。只保护主文档、让脚本继续请求 HTTP，页面仍然可能被降级或遭到篡改。部署时需要检查所有资源协议、重定向链、HSTS、CSP 和反向代理转发的原始协议，不能只看地址栏有没有锁图标。
为什么连接建立的往返次数很重要
网络延迟不是带宽的另一个名字。带宽决定单位时间能搬多少数据，往返时间决定发出请求后多久能得到下一步许可。一个很小的接口也可能因为 DNS、TCP、TLS 和 HTTP 多次往返，在高延迟网络上明显变慢；把响应体再压缩一点，未必比减少一次往返更有效。
预连接、连接复用和资源优先级都是在减少等待，但它们会消耗连接和服务器资源。preconnect 适合确定很快要访问的关键域名，给大量不一定使用的域名预连接反而会浪费；preload 适合明确的关键资源，错误预加载会抢占真正需要的请求。
代理为什么会让协议变复杂
浏览器看到的 HTTPS 连接，可能先到企业代理，再由代理建立另一条到服务器的连接；负载均衡可能在 TLS 终止后通过 HTTP 转发到内网；反向代理还可能修改 Host、X-Forwarded-Proto 和客户端地址。应用如果错误地相信这些头，就可能生成 HTTP 重定向、错误 Cookie 或不安全链接。
部署时要明确哪一层负责 TLS，哪一层可信地追加转发头，哪一层负责压缩和缓存。协议问题经常不是代码写错，而是链路中两个组件对“当前请求是什么协议、来自哪里”理解不一致。
IPv4、IPv6 与连接选择
一个域名可能同时有 A 记录和 AAAA 记录。浏览器会尝试可用的地址，某条 IPv6 路径质量差时可能回退 IPv4。开发者只在公司网络测试 IPv4，用户在移动网络走 IPv6，就可能出现“只有部分用户打不开”的问题。
DNS、TCP、TLS 的监控最好按地址族、地区、运营商和协议版本拆分。平均成功率很高，不代表某个网络群体没有持续失败；网络是路径集合，不是一条固定管道。
网络分层真正解决了什么
分层不是为了把概念写得复杂，而是为了让变化局部化。更换 DNS 服务，不应要求 HTTP 业务代码重写；升级 TLS 密码套件，不应改变 JSON 字段；从 HTTP/1.1 切到 HTTP/2，应用仍然可以使用同一个请求接口。每层通过约定的边界向上提供能力，具体实现可以演进。
把每层的承诺边界记住，遇到问题时就不会把所有现象都归咎于“网络”。
网络排障的价值也在这里：它不是寻找一个万能开关，而是把故障定位到可以验证的层。知道 DNS 正常，只能排除一部分问题；知道 TCP 建立，只能说明字节通道存在；知道 TLS 通过，只能说明连接身份和加密条件满足。真正的 HTTP 与业务结果仍然需要继续验证。
但分层也会带来误判：应用只看到“请求失败”，浏览器只看到“连接错误”，代理只看到“上游超时”。要排查真实问题，就必须把抽象层重新展开。知道每层承诺什么，也知道每层没有承诺什么，是网络工程里比背协议名更重要的能力。
在 CDN 或反向代理终止 TLS 时，用户到代理之间是加密的，代理到应用之间可能是另一条连接。内部网络是否继续使用 TLS，要看威胁模型、网络边界和合规要求。不能因为外层有 HTTPS，就默认内网所有跳数都可信。
把一次访问还原成时间线
排查网络时可以按真实发生顺序问：域名何时被解析，哪个地址被选中，连接何时建立，证书何时验证，HTTP 请求何时发送，服务器何时开始返回，响应何时结束，页面何时消费。这个顺序把“网络慢”拆成了可测量的阶段。
一旦知道阶段，就可以选择工具：DNS 工具看解析，连接工具看端口，TLS 工具看证书，curl 看 HTTP，浏览器 Performance 和 Network 看页面上下文，服务端 trace 看内部依赖。工具不是越多越好，关键是每个工具回答一个明确问题。
只有把每一层都验证过，才能知道问题究竟发生在地址、连接、安全通道、协议报文还是业务处理。分层不是记忆负担，而是一张缩小故障范围的地图：每层只承诺自己能保证的事情，排查才有方向；DNS、TCP、TLS 与 HTTP 的边界清楚时，复杂网络问题也能逐段验证，而不是把所有现象都叫作“网络不稳定”。
容易踩的坑
HTTPS 保护的是传输链路，不替你消除业务漏洞；TLS 终点通常就是服务器，服务器仍能读取明文业务内容。DNS 返回 IP 也只说明解析完成，后面还要建传输与安全连接。排障时把“解析到了”“连上了”“证书过了”“HTTP 谈妥了”分成四步问，比笼统说“网络挂了”更快定位。