计算机基础

一、网络

⚡ 30 秒速记

• 分层模型：应用层（HTTP/DNS/WebSocket）→ 传输层（TCP/UDP）→ 网络层（IP）→ 链路层
• TCP 用三次握手换可靠有序，UDP 用不可靠换实时；QUIC（HTTP/3）在 UDP 上重新实现了可靠性
• 前端最该掌握的三段：DNS 解析（多级缓存 + TTL）、建连成本（握手往返，所以要复用连接和 preconnect）、缓存策略（强缓存/协商缓存）
• 队头阻塞贯穿演进线：HTTP/1.1 管道化（应用层）→ HTTP/2 多路复用解决应用层但 TCP 层仍在 → HTTP/3 换 QUIC 彻底解决
• 排查思路按层缩小范围：打不开先查 DNS/网络层，证书报错是 TLS 层，有响应但内容不对才是应用层

前端理解网络，重点是分层定位问题，并抓住 DNS、建连成本和缓存策略。 应用层包含 HTTP、DNS 和 WebSocket，下面依次是传输层、网络层与链路层；TCP 偏可靠有序，UDP 偏实时，QUIC 则在 UDP 上补回可靠性。连接握手需要往返，所以会考虑复用连接和 preconnect；缓存则要分清强缓存与协商缓存。排查时也按层收缩范围：打不开先看 DNS 或网络，证书错误看 TLS，有响应但内容异常再查应用层。

💬 面试官追问

• 客服说部分用户打不开活动页，但服务端监控、错误率和接口探活都正常，你为什么不会立刻让前端回滚业务代码？

  服务正常并不能证明用户到服务之间的整条链路正常，应先按解析、建连、安全连接和应用响应逐层缩小范围。可让受影响用户检查域名解析结果，并与预期地址对照；只有收到响应但内容或状态异常时，才更有依据进入应用层排查。

• 海外落地页引用五个第三方域名，首屏白屏明显，但业务不允许删除资源，你会优先改哪些网络环节？

  应先收敛实际需要建立连接的域名，并对确定会访问的关键源使用 preconnect，减少首屏前重复等待。还要检查重定向、跨域预检、缓存与资源体积；预连接过多同样会争抢连接和带宽，因此不能对所有候选域名无差别启用。

• 运营要求图片每天更新，前端却给静态资源设置长期强缓存；上线后部分用户持续看到旧图，你怎样兼顾命中率和更新？

  长期缓存必须配合内容版本化地址，使新资源通过新 URL 绕开旧缓存，而不是依赖用户手动清理。入口文档或接口仍需采用可及时校验的策略；版本管理缺失时，缓存时间越长，错误内容的影响窗口就越大。

• 用户把域名写入 hosts 后页面立刻恢复，但直接访问域名仍失败，这个现象把范围缩小到了哪里？

  固定 hosts 绕过正常解析后恢复，优先说明域名解析结果、缓存或解析链路存在异常，而不是业务页面本身必然故障。应核对不同网络下的解析地址、缓存有效期和权威记录；若固定地址也失败，则还要继续检查建连及后续链路。

• 一次优化只能选“增加更多资源域名并行下载”或“收敛域名复用连接”，你会依据什么做决定？

  不能只按请求数量决定，应结合单域名排队、连接建立成本、跨地域往返延迟和关键资源优先级判断。拆域名可能增加并行度，也会新增解析和建连开销；收敛域名利于复用，但资源调度不合理时仍可能让关键请求排队。