引言
从浏览器输入 URL 到页面展示,中间发生了什么"几乎是计算机网络里最经典的问题之一。
这道题之所以重要,是因为它把 DNS、TCP、HTTP、路由转发这些知识点全部串起来了。看懂这个过程,网络知识才算真正连成一条线。
域名解析
假设在浏览器中输入:
text
http://www.myorange.com
浏览器首先并不知道这个域名对应哪台服务器,所以第一步一定是解析域名。
一个常见的查找顺序如下:
- 浏览器缓存
- 操作系统缓存
- 本地
hosts文件 - 本地 DNS 服务器
- 上级 DNS 服务器或递归解析过程
最终,浏览器会拿到一个目标 IP,比如:
text
www.myorange.com -> 2.2.2.2
到这里,应用程序才真正知道"请求应该发往哪台主机"。
浏览器构造 HTTP 请求
有了目标 IP 后,浏览器会构造 HTTP 请求报文。
例如最简单的请求大致长这样:
http
GET / HTTP/1.1
Host: www.myorange.com
Connection: keep-alive
User-Agent: Mozilla/5.0
此时浏览器会把以下信息交给操作系统网络协议栈:
- 目标 IP
- 目标端口
- 请求数据内容
如果是 HTTP,默认端口通常是 80;如果是 HTTPS,默认端口通常是 443。
TCP 三次握手建立连接
如果使用的是 TCP,那么在发送真正业务数据之前,客户端和服务端需要先建立连接。
第一次握手
客户端发送 SYN 报文,表示"我想建立连接"。
第二次握手
服务端收到后,回复 SYN + ACK,表示"我收到了,也同意建立连接"。
第三次握手
客户端再回复 ACK,表示"我也收到你的确认了"。
至此,TCP 连接建立完成。
这个过程的意义是:
- 双方确认发送和接收能力正常
- 双方协商初始序列号
- 为后续可靠传输建立基础
三次握手过程示意图如下:

客户端发送 HTTP 请求数
连接建立后,浏览器就可以发送真正的 HTTP 请求内容。
这个过程并不是"HTTP 自己飞过去",而是:
- HTTP 请求报文先交给传输层
- 传输层把它封装进 TCP 报文段
- 网络层继续封装成 IP 包
- 数据链路层再封装成帧
- 最终通过网卡发出去
如果客户端和服务器不在同一个网段,数据不会直接到达对方,而是会先发给网关,再由路由器逐跳转发。
服务器处理请求并返回响应
服务器收到请求后,会按相反顺序解封装,最终把 HTTP 请求交给 Web 服务程序处理。
如果请求的是网页,服务器可能会返回:
http
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 138
然后再带上响应体,也就是 HTML、JSON、图片或其他资源内容。
浏览器收到响应后开始解析:
- 如果是 HTML,就继续解析 DOM
- 遇到 CSS、JS、图片,还会继续发起新的请求
- 最终完成页面渲染
所以用户看到一个页面,往往不是一次请求,而是一组请求共同完成的。
TCP 如何保证数据可靠送达
TCP 的可靠性依赖于序列号和确认应答。
例如客户端要发送 1000 字节数据,起始序列号是 1,那么:
- 发送方把这段数据标记为从
1开始 - 接收方成功收到后,会回复确认号
1001
这个确认号的含义是:
"从 1 到 1000 的数据我已经收到,下一次请从 1001 开始发送。"
这就是 TCP 能实现可靠传输的重要原因之一。
通信结束后释放连接
当数据传输完成后,TCP 连接不会永远存在,通常需要通过四次挥手关闭。
第一次挥手
客户端发送 FIN,表示"我这边没有数据要发了"。
第二次挥手
服务端回复 ACK,表示"我知道了"。
第三次挥手
服务端处理完剩余数据后,也发送 FIN,表示"我这边也发完了"。
第四次挥手
客户端回复 ACK,连接关闭流程结束。
四次挥手的本质是:
- 两个方向的关闭要分开确认
因为 TCP 是全双工通信,客户端和服务端的发送通道可以分别关闭。
四次挥手过程示意图如下:

整个过程涉及哪些核心组件
从输入 URL 到页面展示,常见组件包括:
- 浏览器
- 本地 DNS 解析器
- 操作系统协议栈
- 网卡
- 网关和路由器
- 目标服务器
- Web 应用程序
所以这个过程并不是单一协议完成的,而是多个层次协同工作。
总结
把整个过程压缩成一句话就是:
"先解析域名,再建立 TCP 连接,然后发送 HTTP 请求,服务器返回响应,浏览器解析资源并渲染页面,最后按需复用或关闭连接。"
如果你能把下面这些点顺着讲清楚,这道题基本就答稳了:
- DNS 解析
- TCP 三次握手
- HTTP 请求与响应
- 路由转发与网关
- TCP 四次挥手
这也是理解整个互联网通信过程最好的入口。
如果这篇文章对你有帮助,欢迎继续阅读本系列后续内容。若文中有不准确或需要补充的地方,也欢迎指出。