从URL输入到页面渲染：网络协议的那些事儿

是你的小橘呀
2 阅读8分钟

作为前端开发者，我们每天都在和 URL、页面渲染打交道，但很少深究从输入一个网址到页面最终展示在眼前，背后到底经历了哪些网络协议的 “协作”。本文会从 DNS 解析说起，依次拆解 TCP、UDP、HTTP（含 HTTPS）这些核心协议的底层逻辑，帮你理清网络通信的本质。

一、第一步：DNS 解析 —— 找到网址的 “真实地址”

输入www.baidu.com/后，浏览器做的第一件事不是直接请求数据，而是要知道这个域名对应的 IP 地址 —— 这就是 DNS（域名系统）的核心作用。

小知识

域名是给人看的，IP 地址是给机器看的，DNS 就是 “翻译官”。

DNS 解析的流程像 “层层问路”：

  1. 浏览器先查本地 DNS 缓存，如果有对应 IP，直接使用；
  2. 缓存没找到，本地域名服务器（比如运营商的 DNS 服务器）会先问根域名服务器；
  3. 根服务器不知道具体 IP，会指引本地服务器去问顶级域名服务器（.com 服务器）；
  4. 顶级域名服务器再指引去问目标域名服务器（百度的 DNS 服务器）；
  5. 最终拿到 IP 后，会把结果写入 DNS 缓存，方便后续复用。

关键

只有拿到 IP，浏览器才能和目标服务器建立连接，这是所有网络通信的 “前置步骤”。

二、TCP：可靠的 “完美主义者”

TCP（传输控制协议）是网络通信的 “主力军”，比如 HTTP/1.1、HTTP/2.0 都基于 TCP 实现，它的核心是 可靠、有序、可控。

1. TCP 的数据包结构

TCP 把数据拆分成一个个数据包传输，每个数据包都有 “身份证” 和 “沟通规则”：

  • 序列号（Sequence Number）：标记数据包的发送顺序，确保接收端能按序重组；

  • 确认号（Acknowledgment Number）：告诉发送方 “我已经收到了哪些数据包”；

  • 窗口大小（Window Size）：限制发送方的速度，避免接收端缓冲区溢出（流量控制）；

  • 核心标识符：

    • SYN：发起连接的 “敲门信号”；
    • ACK：确认收到数据的 “回应信号”；
    • FIN：断开连接的 “告别信号”。

2. 三次握手：建立可靠连接

TCP 连接的建立必须经过三次 “确认”，少一次都不行：

  1. 客户端发 SYN 包：“我想和你建立连接”，客户端进入 SYN_SENT 状态；
  2. 服务器回 SYN-ACK 包：“我收到你的请求了，我也同意建立连接”，服务器进入 SYN_RECEIVED 状态；
  3. 客户端发 ACK 包：“我确认收到你的同意了”，客户端进入 ESTABLISHED 状态。

为什么要三次？

两次握手只能确保一方知道对方在线，三次才能让双方都确认 “彼此都能收发消息”，避免无效连接。

ScreenShot_2026-03-19_204358_873.png

3. 四次挥手：体面地断开连接

TCP 断开连接需要四次交互，因为连接是双向的，关闭也需要双方确认：

  1. 客户端发 FIN 包：“我这边数据发完了，想断开连接”，客户端进入 FIN_WAIT_1 状态；
  2. 服务器回 ACK 包：“我收到你的断开请求了，你等我处理完剩余数据”，服务器进入 CLOSE_WAIT 状态；
  3. 服务器处理完数据后发 FIN 包：“我这边也处理完了，咱们断开吧”，服务器进入 LAST_ACK 状态；
  4. 客户端回 ACK 包：“确认断开”，客户端进入 TIME_WAIT 状态（等待 2MSL，确保服务器收到确认）。

ScreenShot_2026-03-19_204337_672.png

### 4. TCP 的核心特点
  • 可靠传输：丢包会重传，通过序列号和确认号保证数据不丢、不重复；
  • 有序传输：接收端按序列号重组数据，不会乱序；
  • 流量控制：通过滑动窗口（Window Size）限制发送方速度，避免接收端缓冲区溢出；
  • 拥塞控制：慢启动是 TCP 建立连接初期的策略（从 1 个 MSS 逐步增加发包量）；检测到网络拥塞时，会触发拥塞避免 / 快速重传等机制降低发包速度。

三、UDP：洒脱的 “即时主义者”

UDP（用户数据报协议）和 TCP 是完全相反的风格，它是 无连接、不可靠、高效率 的代表。

1. UDP 的核心特点

  • 无连接：不用像 TCP 那样三次握手建立连接，直接发数据包就行；
  • 不可靠传输：不在乎丢包、不在乎数据乱序，发出去就不管了；
  • 无内置的拥塞控制和流量控制：不会因为网络情况调整发送速度（可在应用层自定义实现，如 QUIC）；
  • 高效：正因为 “不纠结”，UDP 的传输延迟极低，适合对实时性要求高的场景 —— 比如视频会议、语音通话、直播、游戏实时交互。

2. 一个有趣的比喻

有人说：

  • 像 UDP 的人，情绪上来了一句话发出去，回不回来无所谓，至少那一刻是真实的；
  • 像 TCP 的人，每一句话都小心翼翼等回应，每一步靠近都要对方确认，少一次 “握手” 就不敢前进；
  • 而最残酷的是，当一个人不想和你 “通信” 时，你再怎么像 TCP 一样反复发 “SYN”（发 “在吗？”“怎么不回消息？”），对方也不会回应，你的所有 “重传、重连、等待确认”，都改变不了 “她不想接收你的数据流” 的事实。

四、HTTP：浏览器和服务器的 “沟通语言”

HTTP（超文本传输协议）是浏览器和服务器之间的 “通用语言”，从 0.9 到 3.0，它的进化始终围绕 更快、更安全、更高效。

1. HTTP/0.9：极简的 “初代版本”

最初的 HTTP 非常简单，只用来传输极小的 HTML 文件：

  • 只有请求行（比如http://192.168.3.1:80/index.html），没有请求头、请求体；
  • 服务端也只有纯文本响应，没有响应头、响应体；
  • 数据以 ASCII 码字符流传输，功能单一到只能传 HTML。

2. HTTP/1.0：适配多样的 “升级版本”

随着图片、视频、JS、CSS 等资源的传输需求出现，HTTP/1.0 引入了核心改进：

  • 新增请求头 / 响应头：比如 accept（告诉服务器想要的文件类型）、content-type（服务器告诉浏览器返回的内容类型）、content-encoding（数据压缩方式）；
  • 新增状态码、Cache 机制、用户代理字段，让 HTTP 的 “沟通能力” 更完整。

3. HTTP/1.1：性能优化的 “关键版本”

HTTP/1.1 解决了 1.0 的核心痛点，也带来了新问题：

  • 核心优化：持久连接（Keep-Alive，默认开启），主流浏览器对每个域名维持 6 个 TCP 长连接，大幅提升资源下载速度；
  • 新增特性：host 字段（指定目标主机）、分块传输编码（Chunk transfer encoding）；
  • 核心问题：带宽利用率低，原因包括 —— 多条 TCP 连接竞争带宽、TCP 慢启动、队头阻塞（一个 TCP 连接中，某个请求响应延迟，后续所有请求都被堵）。

4. HTTP/2.0：解决拥堵的 “高效版本”

HTTP/2.0 针对 1.1 的痛点做了颠覆性优化：

  • 核心思路：只保留 1 个 TCP 长连接，解决连接竞争问题；
  • 多路复用：通过二进制分帧层，把请求 / 响应切成带标记的小片段，服务器可按标记整合、优先处理（比如给 CSS/JS 打加急标签），彻底解决 HTTP 层的队头阻塞；
  • 其他优化：头部压缩（HPACK 算法），大幅减小请求头 / 响应头的体积。

5. HTTPS：安全加密的 “升级版 HTTP”

HTTPS = HTTP + TLS，核心是解决 HTTP 明文传输的安全问题：

  • 加密方式：结合对称加密和非对称加密 —— 客户端生成随机的对称密钥，用服务端的公钥加密后传输；服务端用私钥解密得到该密钥，后续数据传输均使用此对称密钥加密（兼顾安全和效率）；
  • TLS 的作用：保护 HTTP 数据包在传输过程中不被窃取、篡改。

6. HTTP/3.0：突破 TCP 限制的 “未来版本”

HTTP/2.0 没解决 TCP 层的队头阻塞，而 TCP 协议 “僵化” 无法修改，于是 HTTP/3.0 来了：

  • 核心方案：基于 QUIC 协议（融合 TCP 和 UDP 的优点）；
  • QUIC 的特性：基于 UDP 实现，保留了 TCP 的可靠传输、流量控制（含拥塞控制），还支持 TLS 加密、多路复用、快速握手，彻底解决 TCP 队头阻塞；
  • 普及挑战：旧设备不支持 QUIC，需更换全套设备，只能靠时间逐步推广。

HTTP 各版本核心对比

表格

HTTP 版本核心优化核心问题
0.9极简 HTML 传输仅支持 GET、无头部
1.0新增请求头 / 响应头每次请求新建 TCP 连接
1.1持久连接、Host 字段队头阻塞、带宽利用率低
2.0多路复用、头部压缩TCP 层队头阻塞
3.0基于 QUIC、无队头阻塞设备兼容差、升级成本高

总结

从输入 URL 到页面渲染，DNS 解析找到 “地址”，TCP/UDP 负责 “传输”，HTTP 负责 “沟通”—— 每一层协议都在解决特定的问题，也在不断进化。理解这些底层逻辑，不仅能帮我们排查网络问题，更能让我们在做性能优化（比如首屏加载、资源请求）时，找到更本质的解决方案。

avatar
文章
阅读
粉丝