从输入 URL 到页面显示：DNS、TCP、TLS 与 HTTP 完整链路

浏览器访问网站不是“把网址发给服务器”这么简单。域名需要先变成 IP，进程通过端口接收连接，HTTPS 还要先建立 TLS 安全通道，最后才轮到 HTTP 请求和页面渲染。

四个最容易混淆的概念

概念	解决的问题	示例
IP 地址	在网络中找到一台主机或网络接口	`203.0.113.10`
端口	在主机上找到具体服务进程	`443`
Socket	操作系统提供的网络通信端点	IP、端口、协议等状态的组合
域名	便于人记忆的名称	`example.com`

同一台服务器可以同时运行 Web、SSH 和数据库服务，因为它们监听不同端口。Socket 不是一根真实网线，而是程序读写网络连接的操作系统接口。

一次 HTTPS 访问的完整流程

输入 URL
  -> 浏览器解析协议、域名、端口和路径
  -> 查询 DNS，得到服务器 IP
  -> 建立 TCP 连接
  -> 完成 TLS 握手并验证证书
  -> 发送 HTTP 请求
  -> CDN / 负载均衡 / Nginx 接收
  -> 应用服务执行业务逻辑
  -> 查询缓存或数据库
  -> 返回 HTTP 响应
  -> 浏览器解析 HTML、CSS、JavaScript
  -> 布局、绘制并显示页面

例如访问 https://example.com/articles?id=42：

https 表示使用 HTTP over TLS。
example.com 需要通过 DNS 解析。
未显式书写端口时，HTTPS 默认使用 443。
/articles 是路径，id=42 是查询参数。

DNS 不只是一次远程查询

浏览器和系统通常会先检查缓存，再向递归 DNS 解析器查询。解析器可能继续查询根域、顶级域和权威 DNS，最终得到 A、AAAA 或 CNAME 等记录。

DNS 返回 IP 后，浏览器才知道网络包应发往哪里。DNS 成功不代表网站一定可访问；目标端口、防火墙、TLS 和应用仍可能出错。

TCP 与 TLS 分别做什么

TCP 提供可靠、有序的字节流。TLS 在它之上完成服务器身份验证、密钥协商、加密和完整性保护。

HTTP 请求内容
  -> TLS 加密
  -> TCP 分段与可靠传输
  -> IP 路由
  -> 对端按相反顺序还原

证书验证失败通常与域名不匹配、证书过期、信任链不完整或本机时间错误有关，而不是“HTTP 接口代码写错了”。

服务端收到请求后发生什么

常见部署链路如下：

1	浏览器 -> CDN/WAF -> SLB/ALB -> Nginx -> PHP/Go/Java 服务 -> Redis/MySQL

每层只处理自己负责的问题。Nginx 可以终止 TLS、提供静态文件和反向代理；应用服务负责业务规则；数据库负责持久化。定位故障时也应按这条链路逐层缩小范围。

浏览器为什么还会继续请求

首个 HTML 返回后，浏览器通常还要请求 CSS、JavaScript、字体、图片和接口数据。随后经历 DOM/CSSOM 构建、样式计算、布局、绘制与合成。页面慢可能发生在网络，也可能发生在脚本执行和渲染阶段。

常见误区

DNS 只负责名称解析，不负责转发 HTTP 请求。
端口属于主机上的服务入口，不是某个域名独占的物理接口。
TLS 保护传输过程，不会自动修复业务越权或 SQL 注入。
HTTP 200 只表示协议层请求成功，业务仍可能返回失败状态。
页面白屏不一定是后端故障，也可能是静态资源、跨域或 JavaScript 异常。