程云来 / 杭州
返回文章·计算机网络
·约 16 分钟

网络面试（二十四）：怎样把知识连成回答？

用一次订单页访问串起协议职责，练习 TCP 连环追问与十道情景题，再按薄弱环节返回对应章节。

名词都认识，为什么还是接不住追问？

设想面试官给出订单页 https://shop.example.com/orders/O204，问“从输入网址到看到订单，发生了什么？”你回答 DNS、TCP、TLS、HTTP，然后卡在“浏览器第二次打开，还是这个顺序吗？”

问题出在把一次可能的路径背成了每次必经的清单。已有连接可复用，缓存可能省去请求，HTTP/3 又改变传输路径。面试回答需要先说明条件，再解释谁完成了什么，最后指出条件变化后的分支。

能把一个结论放回具体请求、字段和状态，并用反例检验，才算理解了它。 本章沿订单 O204 练习；情景数据均为教学设定，参考回答是组织思路的示例，不代表招聘评分标准。

先把一次访问说完整

先限定：浏览器没有可直接复用的响应，需要新建 HTTPS over TCP 连接，页面普通读取订单信息；实际 DNS 和代理设置仍由客户端环境决定。可以按四段展开，每段说明一个完成条件。

  1. 找到服务入口。 浏览器解析 URL 的协议、主机与路径，使用名字解析结果选地址；缓存、系统解析器或安全 DNS 会影响取得地址的过程。IP 路由选择下一跳，在以太网本地链路中用相应 MAC 交付帧。访问远端网络时通常寻找网关的链路地址，不是跨互联网查询服务器 MAC。
  2. 建立并验证通道。 TCP 同步双方序号与连接状态；TLS 根据协商和认证结果建立受保护通道。客户端要验证服务名字和证书信任，连接到某个 IP 不足以证明它是目标服务。若前方终止于 CDN，浏览器验证的是该入口，回源连接有自己的保护与验证边界。
  3. 交换应用信息。 客户端发送请求，入口可能从缓存应答，或转发到有权限处理订单的服务。服务读取身份、检查订单权限，返回 HTTP 状态、首部与正文。HTTP 无状态不妨碍应用借助 Cookie 或其他凭据维持会话。
  4. 形成可见页面。 浏览器处理返回内容，可能继续取得脚本、样式、图片或接口数据，最后完成页面布局与绘制。收到首字节、正文下载完成和页面可用是三个不同时间点。

这四段说明职责，并不要求所有请求都重新做一遍。跟进“第二次为什么快”，先区分直接使用新鲜响应、复用现有连接和新连接的 TLS 恢复；跟进 HTTP/3，则说明 QUIC 在 UDP 上提供安全、多路流传输，不再套用 TCP 三次握手路径。HTTP 的缓存与中间节点、QUIC 流与连接

一个口述版本是：

我先假设需要联网，并新建 HTTPS 的 TCP 连接。浏览器取得主机地址，网络按下一跳转发；TCP 建立连接，TLS 验证服务身份并协商保护通道。随后交换 HTTP 请求和响应，服务检查订单身份与权限，浏览器处理内容及后续资源，形成页面。实际访问可能使用缓存、复用连接或经过 CDN；HTTP/3 使用 QUIC，所以我会先确认这些条件，再解释具体路径。

这一版留出了追问入口。不要在最初回答中把 DNS 全部记录、每个 TCP 状态和每种证书字段都塞进去；面试官指定某一步，再沿该步骤的状态变化展开。

TCP 连环追问：每次只推进一个保证

面试官接着问“TCP 为什么可靠？”先解释字节编号、确认与重传，再主动给出边界：传输接收不等于订单提交。下面是一组可连续练习的追问。

追问回答中的关键变化不能越过的边界
为什么三次握手？双方同步初始序号，服务端收到对其 SYN 的有效确认“双方能收发”只是入门说法，还要解释旧连接报文和状态同步
ACK=1001 是确认包 1001 吗？普通累计确认表示下一期待的字节序号字节序号不是抓包编号；不能从 ACK 推出数据库提交
可靠为什么还会超时？重传只能在连接及等待条件允许时继续链路可长期中断，应用也可先达到截止时间
recv 为什么没有一次一条消息？TCP 交付有序字节流，应用按长度或其他规则分帧send 调用、TCP 段和业务消息没有一一对应关系
FIN 后还能回消息吗？一个方向结束发送，反向仍可能交付数据FIN 不是直接关闭两个方向；RST 又是另一种结束路径

握手、累计确认、流与关闭的语义见 RFC 9293 §3.4—§3.6。具体数字与状态轨迹可回看第 9 章、第 10 章和第 13 章。

“为什么不能一直发”需要另外区分两个限制：接收方公布的窗口约束接收能力，拥塞窗口约束网络中的在途量。把其中一个说成另一个，解释不了“接收缓冲还空着，但丢包后发送速率下降”。经典拥塞控制的窗口变化有算法和事件前提，不能背成所有实现每次都减半。RFC 5681：流量与拥塞限制

最后给一个应用反例：请求已送到服务端，O204 创建成功，响应在途中丢失，客户端等待超时。此时传输层信息没有告诉客户端订单是否提交。应用要用查询和幂等契约处理不确定结果，重试同一操作也应保留原来的业务身份；不能靠更换连接或“换个请求 ID”消除重复执行风险。HTTP 幂等与重试、第 14 章的提交时间线

HTTP 与 TLS：先分清回答的是哪个问题

“连接是长的，所以 HTTP 有状态”“HTTPS 安全，所以登录没风险”都把不同职责合并了。解释时先指出状态或保证存在哪里，再讨论能做什么。

容易混在一起的概念应怎样拆开回答
HTTP 无状态与连接复用前者描述请求语义，后者复用传输资源；应用会话又有自己的身份与存储
GET/POST 与安全、幂等方法表达契约；安全不等于保密，幂等不等于每次响应相同，POST 可另设业务幂等机制
no-cache 与 no-store无参数 no-cache 要求复用前验证；no-store 约束存储，不能用中文“不要缓存”代替区分
TLS 证书与流量加密证书参与身份认证；握手建立密钥，记录保护承载数据，登录授权由应用判断
TLS 恢复与 0-RTT恢复不必发送早期应用数据；早期数据要单独考虑重放及业务适用性
多路复用与无阻塞HTTP/2 仍受 TCP 有序交付影响；QUIC 减少跨流的传输等待，流内缺口和共享资源仍存在

缓存指令按 RFC 9111 §5.2.2 的具体形式判断；HTTP/2 流控与 QUIC 流内顺序分别见 RFC 9113 §5.2 和 RFC 9000 §2.2。

面对“换成新协议是否一定更快”，先询问冷连接还是复用、响应体大小、丢包、缓存来源和服务端工作量。协议改变了哪些等待可以重叠，才是可解释的收益；一次测量或版本号不能推出所有场景的性能排序。

十道情景题：先作答，再看解析

建议遮住后面的解析，每题写出“结论、依据、下一条证据”三句话。数字只用于手算，运行环境和失败症状都是题设，不能把它们当成本书的新增实测。

  1. 下一跳。 主机 192.0.2.10/24 的默认网关为 192.0.2.1，要访问 198.51.100.20，已有适用默认路由且没有更具体路由。在以太网中，应为哪个 IPv4 地址解析 MAC？
  2. 子网与选路。 地址 192.0.2.130/26 位于哪个子网？若路由表同时有 192.0.2.0/24 和 192.0.2.128/26，访问 192.0.2.140 时选哪条匹配路由？
  3. 缓存年龄。 某响应 max-age=60，到达时经正确计算的当前年龄为 20 秒，本地又放了 15 秒，其他条件不阻止复用。现在年龄和剩余新鲜时间是多少？
  4. 发送额度。 教学模型中 rwnd=12000、cwnd=8000 字节，已有 6000 字节在途；无重传、探测等特殊情况。当前还能新增多少在途字节？
  5. 未知提交。 创建 O204 的请求超时，服务端日志显示事务已经提交。客户端能把超时当创建失败、换一个幂等键立即重试吗？
  6. 名字验证。 DNS 返回地址，TCP 也连上了，但客户端拒绝证书名字。把 URL 改成该 IP，或关闭验证，是否完成修复？
  7. 跨域读取。 跨源 fetch 使用 credentials: include，服务器返回 Access-Control-Allow-Origin: * 和 Access-Control-Allow-Credentials: true。即使 HTTP 返回 200，页面脚本是否一定能读取正文？
  8. 丢包等待。 HTTP/2 两个流共用一条 TCP，后到的 B 数据位于缺口之后，A 的缺失字节未补齐。B 能因为自己的 HTTP 流号不同就绕过 TCP 缺口交给 HTTP 层吗？
  9. 早期下单。 客户端持有恢复材料，准备使用 TLS 1.3 的 0-RTT 发送创建订单请求。“已加密”和“有幂等键”是否足以无条件批准早期执行？
  10. 实时恢复。 SSE 客户端观察到 ID=42 两次，服务器收到了 Last-Event-ID: 42。能推断浏览器自动去重，或消费者已将 42 提交数据库吗？

动手作答，保留首次判断

用下面的十题逐项检验。选完先读依据，再返回相关章节；修改答案可以练习，但首次记录仍保留原来的薄弱点。

先做判断，再用证据检验回答

每题先选结论，再尝试说出依据和下一条证据。首次作答只计一次；重做用来练习，不改写首次记录。

第1题：下一跳

192.0.2.10/24访问198.51.100.20，适用默认网关192.0.2.1且无更具体路由。ARP应解析谁？

首次作答：已答0/10题 · 正确0题 · 待复习0题

题设来自本章十道练习；记录仅存在当前页面内存，刷新即清空。正确数用于发现复习方向，不评价口述质量，也不是招聘评分标准。完整推理见下方逐题解析。

逐题解析：证据到哪里，结论到哪里

1. 解析网关，不解析远端服务器的 MAC

192.0.2.10/24 的本地子网为 192.0.2.0/24，目标在外部网络。按题设默认路由，下一跳是 192.0.2.1，ARP 寻找这个网关的 MAC；IP 目的地址仍是远端 198.51.100.20。若路径发生 NAT，转换是后续设备上的动作。回看链路与 ARP。

2. /26 子网从 128 开始，更具体路由胜出

/26 留下 6 位主机部分，每段 64 个地址，130 落在 128—191，子网为 192.0.2.128/26。140 同时匹配两条路由；按最长前缀匹配选 /26。常规 IPv4 子网中网络地址是 .128、广播地址是 .191，可分配范围 .129—.190；不要把这条常规规则机械套给 /31 等特殊用途。回看子网与选路。

3. 年龄为 35 秒，还剩 25 秒

题设已经给出到达时正确计算的年龄，所以加本地驻留时间即可：20+15=35，60−35=25。它不是“下载到浏览器后重新获得 60 秒”。现实还要处理年龄计算、验证、请求指令和匹配条件；此题只固定新鲜度算例。RFC 9111 §4.2、缓存章节

4. 普通模型的额度为 2000 字节

两种窗口取较小值 8000，减掉 6000 在途字节，得到 2000；rwnd 较大没有解除拥塞约束。这个计算不是实际发送调度器的完整实现，还要满足窗口边界、应用数据等条件。回看窗口与拥塞。

5. 超时不能撤销已发生的提交

换键可能把同一个动作表达成新操作，再次创建订单。应按服务契约查询既有结果或用同一业务幂等身份重试，并确认去重范围、参数一致性和有效期。服务端要在相应原子边界记录结果；“有一个键”本身不保证提交与记录不会失配。回看超时、重试与幂等。

6. 成功绕过错误条件，不代表满足验证条件

服务身份是客户端原本要访问的名字。改成 IP 会改变参考身份，关闭验证则删除要求。应检查 URL、入口配置、证书中的名字、链和真实客户端信任，使原始访问通过正常验证。回看真实证书验证实验。

7. 带凭据模式不能用通配符共享响应

题设不满足 CORS 的凭据响应条件，200 不保证脚本可读。服务器应按可信 Origin 策略返回具体允许来源和正确凭据许可，并处理所需预检；Cookie 是否发送还有自己的条件。CORS 约束浏览器共享响应，不能代替服务端认证授权，也不能据此推断请求一定未到服务端。Fetch：CORS 协议与凭据、登录与跨域

8. HTTP 流号没有改写 TCP 的交付边界

缺口后的 B 字节仍等待 TCP 连续交付；HTTP/2 多路复用没有让 TCP 获得独立有序流。QUIC 的其他流在数据和首部依赖满足时可以继续，但同包丢失、流内缺口、拥塞额度和应用依赖仍可能造成等待。回看HTTP 版本与丢包轨迹。

9. 还要评估重放、身份和所有副作用

0-RTT 的加密完整性没有消除重放风险。幂等键只能在其真实覆盖范围内发挥作用，还要检查跨实例一致性、记录有效期、授权，以及订单之外的扣款、通知等副作用；不能仅据这两个条件宣称早期执行安全。需要拒绝早期执行或退回握手完成后时，遵守相应协议与业务契约。TLS 1.3 §8：0-RTT 防重放、恢复与早期数据

10. 事件游标不等于应用提交确认

原生 EventSource 会派发重复的完整事件，ID 不自动去重；Last-Event-ID 表达协议侧重连位置，没有携带数据库事务确认。需要业务自己的去重、持久进度和恢复契约。第 21 章真实实验观察到重复 42 被两次派发，页面 Set 才显式过滤，且 Set 只存在内存中。SSE 实验与恢复边界

按薄弱环节复习，而不是从头反复背

我的建议是先脱稿解释一个场景，再用反例找缺口。回答出现“肯定”“永远”“一定更快”时，补问自己前提；答错具体数字时回到字节、掩码或时间计算，不只修改最后结果。

暴露的问题返回哪些章节复习时要交出的结果
地址与各层职责混淆01—07：请求、性能、链路、IP、配置、ICMP、DNS画出远端 IP 与每跳链路地址，手算一个子网和查询缓存边界
把可靠传输当可靠业务08—14：端口、握手、可靠性、窗口、分帧、关闭、重试按序号复述握手与确认，解释提交成功却响应丢失的处理
缓存、登录和加密相互替代15—19：HTTP、缓存、会话、TLS、恢复区分一次响应复用、一次身份判断与一次握手保护
新协议、代理与长连接判断绝对化20—22：版本、实时通信、CDN/LB指出阻塞属于哪层、状态存在谁那里、代理是否终止通道
只会猜“网络慢”23：分层排障为症状写出最早缺失的证据、工具边界和下一组对照

手算后可运行第 12 章分帧、第 13 章半关闭、第 18 章 TLS、第 21 章 SSE和第 23 章 curl的公开入口。实验用于核对特定机制；回环延迟、临时证书和内存游标都不代替公网性能或生产恢复的验证。

30—60 秒参考回答

我会先限定场景，再按谁负责什么来组织答案。访问订单页时，从地址与下一跳、通道建立和身份验证，讲到 HTTP 与应用权限、最后到页面处理；缓存、复用、代理或 QUIC 会改变路径。追问 TCP 可靠，我解释字节确认与重传，同时说明它不保证订单提交结果。遇到故障则先找完成边界，用日志和工具验证假设。这样每个结论都有机制、适用条件和能检验它的反例。

四个追问及解析

1. 不记得一个系统的默认超时，该怎么回答？

说明需要目标系统、版本及配置才能给数值，先解释超时发生在哪一层、限制哪个等待。猜一个数字无法替代机制；参数结论应回到该版本文档和实际配置核对。

2. 面试官要求一句话解释 TCP 和 UDP 的区别呢？

TCP 提供连接中的可靠有序字节流，UDP 提供数据报边界和较少的内建传输保证。再根据追问讨论可靠性、拥塞和应用协议，不能把 UDP 直接等同于业务不可靠或一定更快。

3. 用了 HTTPS，为什么还要检查订单权限？

通道认证和加密保护没有授予某个用户访问 O204 的权利。服务端仍要验证凭据和资源权限，代理终止 TLS 后还要检查后续链路的保护。

4. 测一次发现 HTTP/3 更慢，怎样解释？

先确认测的是新建还是复用、是否发生回退、缓存和服务路径是否一致，再比较各阶段时间。单个结果能说明那次条件下的观察，不能代表协议的普遍排序。

两个容易说错的结论

“按 DNS→TCP→TLS→HTTP 背下来，就覆盖了所有网址访问。” 这是一条有前提的路径；缓存、已有连接、代理与 QUIC 都会改变它。

“背得越多、结论越绝对，面试回答越有说服力。” 可检验的字段、状态与因果更有帮助。回到 O204：能解释它怎样到达、怎样验证身份、为何超时后仍不确定，再指出下一条证据，回答才连得起来。

资料核验日期：2026-10-09。规范链接支持相应协议判断；练习题、数字、口述组织和复习路线为作者教学设计，不是新增网络实测或官方面试标准。