从浏览器到服务端：一条请求经过了哪些网络层次

计算机网络最容易学成“协议名仓库”。

HTTP、HTTPS、TCP、UDP、DNS、IP、MAC、ARP、拥塞控制、流量控制，听起来都重要，做题时也确实都能单独问。可一旦把它们拆开太久，人脑就会开始遗忘一个最关键的事实：这些东西本来就是为了让一次真实通信能成功发生。

所以计网这章我越来越喜欢从一条请求开始学。

不是先背协议，而是先问：当我在浏览器里输入一个 URL，到底有哪些层在接力。

先把一条请求走完整#

只要把这条时间线放在脑子里，后面每一层的职责就好理解很多。

第一步不是发 HTTP，而是先找到对方#

很多人说“浏览器发送请求”，听起来像第一步就发 HTTP。

其实不是。

在大多数场景里，浏览器首先得知道：这个域名到底对应哪台机器。

DNS 做的，是把名字换成地址#

域名好记，但机器真正转发靠的是 IP。

所以 DNS 这层最核心的职责，就是把：

• www.example.com

翻译成：

• 某个可以路由到的 IP 地址。

这一步常见会经过这些缓存或节点：

• 浏览器缓存；
• 操作系统缓存；
• 本地递归解析器；
• 根、顶级域、权威 DNS 服务器。

你不一定要每次都把整套递归过程背全，但最好知道：DNS 不是一张单点电话簿，它本身就是一套分层协作系统。

为什么 DNS 会直接影响访问体验#

因为它不是“前戏”，而是请求真正开始前的必要环节。

• 解析慢，整体首包就慢；
• 解析策略不同，用户可能被导到不同机房；
• CDN 调度很多时候首先依赖的就是域名解析结果。

所以当你说“网站慢”，问题可能都还没到业务服务那里，先慢在了解析路径上。

DNS 这题别答成纯背诵

更好的答法不是死背“根服务器、顶级域、权威服务器”三个名词，而是说明：DNS 把“人类友好的名字”和“机器可路由的地址”解耦了，同时还能借此做缓存和流量调度。这就比背书强很多。

第二步：连接不是一句“连上了”就完事#

拿到 IP 之后，请求也还没真正开始。

如果走的是基于 TCP 的通信，客户端和服务端先得把这条通道建立起来。

三次握手到底在确认什么#

很多人会说“三次握手是为了确认双方收发正常”，这没错，但略显抽象。

更完整一点可以这样理解：

• 客户端先发起连接意愿；
• 服务端确认自己能收、也愿意发；
• 客户端再确认自己收到了对方回应；
• 双方顺便完成初始序列号同步，为后面的可靠传输打地基。

所以握手不是礼貌寒暄，而是给后续可靠字节流建立共同上下文。

为什么关闭连接往往比建立连接更容易答乱#

因为建立连接是三次，关闭连接常常会说到四次挥手、半关闭、TIME_WAIT。

这里最重要的不是死背状态转移，而是明白：

• TCP 是全双工；
• 一端不再发送，不代表另一端也立刻没数据可发；
• 所以关闭两端发送方向，常常需要分开确认。

这也是为什么“四次挥手”通常比“三次握手”更容易被追问细节。

TIME_WAIT 到底在干嘛

它不是单纯“浪费端口”。保留一段等待时间，主要是为了让可能迟到的旧报文彻底消散，并确保最后的确认报文如果丢了，还有机会重发。它的存在，本质上是在为连接生命周期收尾，而不是平白无故拖慢系统。

TCP 真正厉害的地方，在于它把“可靠”做成了一整套机制#

“TCP 可靠，UDP 不可靠”是最常见的总结，但这句话太容易把细节全抹平。

TCP 的可靠，不是凭口号，而是靠几组机制一起堆出来的：

• 序列号；
• 确认应答；
• 超时重传；
• 滑动窗口；
• 流量控制；
• 拥塞控制；
• 乱序重组。

流量控制和拥塞控制不是一个东西#

这也是面试里特别爱混的两个点。

• 流量控制 更像接收端在说：你别发太快，我这边来不及收；
• 拥塞控制 更像网络在说：别把中间链路打爆了。

一个关注接收方处理能力，一个关注整个网络承压情况。

为什么 TCP 适合通用应用层协议#

因为上层应用通常不想自己重新发明一遍这些机制。

HTTP、MySQL 协议、绝大多数面向正确性交互的后端服务，都更愿意直接站在可靠字节流上说话。

这也是 TCP 在传统互联网应用里长期稳坐主力的原因。

HTTPS 不是“更安全的 HTTP”，而是 HTTP 叠了一层 TLS#

这句话很简单，但特别值得记住。

因为它一下就把职责拆清楚了：

• HTTP 负责表达“我要什么、你给我什么”；
• TLS 负责保密性、完整性和身份认证；
• TCP 负责把下层可靠传输通道准备好。

TLS 握手到底在干嘛#

如果只用一句人话来概括，那就是：

• 协商算法；
• 验证服务端身份；
• 建立这次会话要用的密钥材料。

所以 HTTPS 慢一点，常见不只是“加密更复杂”，而是：

• 前面先有 TCP 握手；
• 上面还要走 TLS 协商；
• 证书校验、密钥交换、握手往返都会带来额外成本。

但换来的，是明文 HTTP 根本不具备的安全边界。

HTTPS 主要解决哪几类问题#

• 防窃听：别人看到报文也难直接读懂内容；
• 防篡改：中途改包更容易被发现；
• 防冒充：通过证书体系确认你连的是谁。

所以它不是“单纯把数据加密一下”，而是把通信的身份和完整性也一起管了。

HTTP 层负责的是语义，不是底层可靠性#

这个边界一定要分清。

HTTP 不负责重传、丢包恢复、流量控制，这些是 TCP 或 QUIC 那一层在处理。

HTTP 负责的，是请求与响应的表达：

• 方法；
• 状态码；
• 头部；
• 资源语义；
• 缓存协商；
• 内容协商；
• 连接复用方式。

真正高频的 HTTP 面试点，其实就这几组#

• GET 和 POST 的语义差异；
• 常见状态码；
• 长连接与短连接；
• 缓存控制；
• Cookie、Session、Token；
• 各版本之间的演进。

HTTP 1.1、2、3 应该怎么对比#

• HTTP/1.1
• HTTP/2
• HTTP/3

• 长连接普及后，请求不必每次都重建 TCP。
• 但同一连接上的并发能力有限，队头阻塞问题明显。
• 时代很长，生态成熟。

这里最好别只答“版本越高越快”。

更稳的说法是：每一代都在努力减少额外开销、提高并发传输效率、降低阻塞带来的连锁影响。

一次请求真的慢，问题可能在很多地方#

这也是计网学习最有价值的地方：它会逼你从分层角度看性能。

一个网页打开慢，可能是：

• DNS 解析慢；
• TCP 握手慢；
• TLS 协商慢；
• 应用层缓存没命中；
• 服务端处理慢；
• 网络丢包导致重传；
• 拥塞控制把发送速率压下来了；
• 浏览器还在继续拉 CSS、JS、图片。

所以“网络慢”从来不是一个单点答案。

它更像一段接力赛里某一棒跑崩了。

UDP 为什么依然重要#

讲计网不能只讲 TCP，不然会误以为“可靠 = 万能”。

UDP 的特点很鲜明：

• 头部小；
• 连接负担轻；
• 实时性更友好；
• 上层自己决定要不要补可靠语义。

所以像音视频、实时交互、某些游戏场景，会更愿意站在 UDP 或基于 UDP 的协议之上重新设计传输策略。

这也是后来看 QUIC 会很有意思的原因：它把很多传统上依赖 TCP 的传输能力，搬到了用户态协议层重新组织。

TCP 和 UDP 这题怎么答才不空

别只说“一个可靠一个不可靠”。更好的答法是：TCP 把顺序、确认、重传、窗口、拥塞控制这套机制内建了，适合通用可靠传输；UDP 保持轻量，把更多选择权留给应用层，更适合实时性优先或自定义传输语义的场景。

如果面试官让你“讲一下从输入 URL 到页面显示”#

这题基本算计网总复习题。

1. 先说解析 URL，确认协议、域名、端口和资源路径。
2. 再说 DNS，把域名翻译成 IP。
3. 接着说 TCP 建连，如果是 HTTPS 再补 TLS 握手。
4. 然后说 HTTP 请求与响应语义，以及各版本差异。
5. 最后补传输层的可靠性、拥塞控制，以及浏览器继续拉静态资源和渲染页面。

这套答法的好处是：

• 能把 DNS、TCP、TLS、HTTP 放在一条线上；
• 既能说协议职责，也能说性能影响；
• 对方怎么追问，你都能顺着往下一层展开。

最后把计网这章收成一句话#

计算机网络并不是一堆彼此孤立的协议。

它更像一条分层协作的请求旅程：

• DNS 先告诉你人在哪；
• TCP 或 QUIC 负责把通道搭起来；
• TLS 负责让通道可信且保密；
• HTTP 负责表达请求与响应的语义；
• 流量控制、拥塞控制、重传等机制负责让这条旅程别轻易跑散。

所以真正学会计网之后，你再看一个请求，就不会只看到“浏览器发了个 HTTP”。

你看到的会是一整套协议，在为同一件事接力：把一次通信尽量正确、尽量高效、尽量安全地送到对面去。