考点：
- 浏览器输入 URL 到页面展示的全过程
- DNS 解析过程
- TCP 三次握手 / 四次挥手 / TIME_WAIT / CLOSE_WAIT
- HTTP 与 HTTPS 的区别，TLS 握手过程
- HTTP 常见方法、状态码、长连接、Keep-Alive
- HTTP/1.1、HTTP/2、HTTP/3 的区别
- Cookie、Session、Token、JWT
- 浏览器缓存：强缓存、协商缓存
- 跨域问题：同源策略、CORS、预检请求
- WebSocket 与 HTTP 的区别
- CDN、反向代理、负载均衡、网关
- 结合 K8s 的网络排障思路：Service、Ingress、CoreDNS、Pod 网络
Q1：从浏览器输入一个 URL 到页面最终展示，中间发生了什么？
核心要点
- 浏览器先解析 URL，确定协议、域名、端口、路径。
- 查询缓存与 DNS，获取目标 IP。
- 与目标服务建立 TCP 连接；如果是 HTTPS，还要进行 TLS 握手。
- 浏览器发送 HTTP 请求，请求可能经过 CDN、负载均衡、Nginx/Ingress、网关、后端服务。
- 服务端返回 HTTP 响应，浏览器解析 HTML，构建 DOM 树。
- 遇到 CSS/JS/图片等资源继续发起请求。
- 浏览器构建 DOM + CSSOM，生成 Render Tree，布局（Layout），绘制（Paint），合成（Composite）。
易错点
- 把“DNS 解析”和“TCP 建连”顺序说反。
- 以为 HTTPS 只是在 HTTP 外面“加密一下”，却说不清 TLS 握手。
- 忽略浏览器缓存、重定向、CDN、代理层。
- 只说前端渲染，不提网络链路和服务端。
深挖点
- 如果在 K8s 中，请求通常可能经过：
DNS -> SLB/LB -> Ingress -> Service -> Pod。 - 如果页面慢，如何定位是 DNS、TCP、TLS、TTFB、静态资源还是前端渲染问题。
- 首包时间（TTFB）受哪些因素影响。
- 如果在 K8s 中，请求通常可能经过：
Q2：DNS 解析的过程是怎样的？为什么它对运维很重要？
核心要点
- 浏览器先查本地缓存、系统缓存、hosts 文件。
- 若未命中，请求本地域名解析器。
- 本地 DNS 递归查询，可能依次访问根 DNS、顶级域 DNS、权威 DNS。
- 最终返回域名对应的 IP，并按 TTL 缓存。
- 在 K8s 中，集群内部域名解析通常依赖 CoreDNS。
易错点
- 分不清 递归查询 和 迭代查询。
- 不知道
hosts的优先级通常高于 DNS。 - 忽略 DNS 缓存和 TTL 对故障切换的影响。
- 不知道 K8s Pod 内部服务名也依赖 DNS 解析。
深挖点
- 为什么修改 DNS 记录后不能立刻全网生效。
- CoreDNS 异常会导致哪些现象：服务名不可解析、业务间调用失败。
- 如何排查 DNS 问题：
nslookup、dig、Pod 内测试、CoreDNS 日志。
Q3：TCP 三次握手和四次挥手分别是什么？为什么不是两次或三次？
核心要点
- 三次握手目的是确认双方的 收发能力 和初始序列号。
- 四次挥手是因为 TCP 是 全双工，双方关闭连接要分别发送 FIN/ACK。
- 建连流程：
SYN -> SYN+ACK -> ACK。 - 挥手流程：
FIN -> ACK -> FIN -> ACK。
易错点
- 说不清第三次握手的作用。
- 把“确认对方能发能收”和“确认自己能发能收”逻辑说混。
- 认为挥手一定是四次，实际也可能三次（某些 ACK/FIN 合并）。
- 不知道 TIME_WAIT 出现在哪一方。
深挖点
- 为什么需要 TIME_WAIT：防止旧报文影响新连接、保证被动关闭方收到最后 ACK。
- 为什么大量短连接可能导致 TIME_WAIT 过多。
- 在高并发网关/Nginx/Ingress 场景下，连接管理为何重要。
Q4：TIME_WAIT 和 CLOSE_WAIT 分别是什么？面试中常怎么考？
核心要点
- TIME_WAIT：主动关闭连接的一方，在发送最后 ACK 后进入该状态。
- CLOSE_WAIT：被动关闭连接的一方，收到 FIN 后进入该状态，等待应用主动调用 close。
- TIME_WAIT 多通常是连接关闭频繁；CLOSE_WAIT 多通常意味着应用未正确释放连接。
易错点
- 把 TIME_WAIT 和 CLOSE_WAIT 的归属方说反。
- 只会背定义，不会分析问题根因。
- 误以为所有大量 TIME_WAIT 都是异常。
深挖点
- 如果服务端 CLOSE_WAIT 很多，优先怀疑什么：应用代码、连接未释放、线程阻塞。
- 如果 TIME_WAIT 很多，如何优化：连接复用、长连接、合理调参，但不能盲目改内核参数。
- 在容器和节点上怎么排查：
netstat/ss、应用日志、连接池配置。
Q5：HTTP 和 HTTPS 的区别是什么？HTTPS 为什么更安全？
核心要点
- HTTP 明文传输；HTTPS = HTTP + TLS。
- HTTPS 提供 加密性、完整性、身份认证。
- TLS 握手阶段协商加密套件、交换密钥、验证证书。
- 服务端通过 CA 签发的证书证明身份，防止中间人攻击。
易错点
- 只说“HTTPS 更安全”，但说不出安全体现在哪里。
- 认为 HTTPS 使用非对称加密传输所有数据，实际上通常是 非对称加密协商密钥，对称加密传输数据。
- 搞不清证书校验和 CA 信任链。
深挖点
- TLS 握手的主要阶段是什么。
- 为什么 HTTPS 比 HTTP 更耗时，但 HTTP/2、连接复用、TLS 会话恢复可优化。
- 在 K8s 中 TLS 终止通常放在哪里：LB、Ingress、网关。
Q6：HTTP/1.1、HTTP/2、HTTP/3 有什么区别？
核心要点
- HTTP/1.1
- 默认长连接。
- 支持管线化，但基本很少用。
- 存在队头阻塞问题。
- HTTP/2
- 二进制分帧。
- 多路复用。
- Header 压缩。
- 同一连接可并发多个请求。
- HTTP/3
- 基于 QUIC，底层用 UDP。
- 进一步减少传输层队头阻塞。
- 建连和迁移更友好。
- HTTP/1.1
易错点
- 把 HTTP/2 的多路复用和 TCP 层完全独立看待，忽略 TCP 丢包仍会影响。
- 误认为 HTTP/3 只是“更快的 HTTP/2”。
- 不知道 HTTP/3 为何基于 UDP。
深挖点
- 为什么 HTTP/2 仍然可能有队头阻塞。
- 为什么移动网络切换下 QUIC 更有优势。
- 实际运维中，CDN、网关、Ingress 是否支持 HTTP/2/3。
Q7：Cookie、Session、Token、JWT 的区别是什么？
核心要点
- Cookie：浏览器保存的小块数据，会随请求自动带上。
- Session：服务端保存用户会话状态，客户端一般只存 Session ID。
- Token：服务端认证后发给客户端，后续请求客户端主动携带。
- JWT：一种 Token 格式，通常由 Header、Payload、Signature 组成。
易错点
- 把 Cookie 和 Session 当成同一个东西。
- 以为 JWT 天然安全，忽略泄露、过期、吊销问题。
- 不知道 Cookie 可设置
HttpOnly、Secure、SameSite。
深挖点
- 分布式系统中 Session 共享怎么做：Redis、粘性会话等。
- 为什么很多微服务/API 网关场景偏向 Token/JWT。
- JWT 适合无状态认证，但不适合频繁主动注销的复杂场景。
Q8：浏览器缓存有哪些？强缓存和协商缓存有什么区别？
核心要点
- 强缓存：浏览器不发请求，直接用本地缓存。
- 常见字段：
Expires、Cache-Control
- 常见字段：
- 协商缓存：浏览器发请求问服务端资源是否变化。
- 常见字段：
Last-Modified / If-Modified-Since ETag / If-None-Match
- 常见字段：
- 未变更返回
304 Not Modified。
- 强缓存：浏览器不发请求，直接用本地缓存。
易错点
- 分不清强缓存和协商缓存。
- 不知道
Cache-Control优先级通常高于Expires。 - 误认为返回 304 就完全没有网络开销。
深挖点
- 为什么静态资源常配合文件指纹/hash。
- 为什么 API 接口一般不建议随便强缓存。
- CDN 缓存、浏览器缓存、Nginx 缓存之间是什么关系。
Q9：什么是跨域？CORS 是怎么工作的？
核心要点
- 浏览器有同源策略：协议、域名、端口三者相同才算同源。
- 跨域本质是 浏览器安全限制，不是服务端之间不能通信。
- CORS 通过响应头允许指定来源访问。
- 非简单请求通常会先发 OPTIONS 预检请求。
易错点
- 把“跨域”理解成网络不通。
- 不知道跨域限制主要发生在浏览器端。
- 不了解
Access-Control-Allow-Origin、Allow-Credentials的配合限制。 - 误以为 Postman 能跨域说明浏览器也能。
深挖点
- 为什么带自定义 Header、JSON、PUT/DELETE 可能触发预检。
- 为什么
Access-Control-Allow-Origin: *不能和凭证一起用。 - 在 Nginx/Ingress 层如何统一处理跨域配置。
Q10：WebSocket 和 HTTP 有什么区别？什么场景下会用到？
核心要点
- HTTP 通常是请求-响应模式。
- WebSocket 建立连接后可全双工通信，适合实时场景。
- WebSocket 握手基于 HTTP Upgrade。
- 常见场景：实时日志、监控面板、聊天、推送。
易错点
- 认为 WebSocket 完全不是 HTTP。
- 不知道 WebSocket 初始握手依赖 HTTP。
- 说不清为什么它更适合实时通信。
深挖点
- 在 K8s 中通过 Ingress 代理 WebSocket 需要注意什么：连接升级、超时配置、长连接。
- WebSocket 和 SSE 的区别。
- 长连接过多时如何考虑资源占用和连接治理。
Q11：常见 HTTP 状态码有哪些？运维场景重点看哪些？
核心要点
200：成功。301/302：重定向。304：缓存命中，资源未修改。400：请求错误。401：未认证。403：已认证但无权限。404：资源不存在。499：客户端主动断开（Nginx 常见）。502：网关/代理访问上游异常。503：服务不可用。504：网关超时。
易错点
- 分不清
401和403。 - 分不清
502和504。 - 不知道
499常见于 Nginx。
- 分不清
深挖点
- 在 K8s + Ingress 场景下：
502常见于上游 Pod 异常、端口不通、探针失败。504常见于上游处理过慢、超时配置太小。503可能是无可用 Endpoint。
- 如何从浏览器、Nginx、Ingress、Pod 日志联合定位。
- 在 K8s + Ingress 场景下：
Q12：如果用户反馈“网页打不开”，你会怎么排查？
核心要点
- 先确认是 DNS 问题、网络问题、TLS 问题、代理问题、服务异常、前端资源问题 哪一层。
- 典型链路：
- 域名是否解析正常
- 端口是否通
- TLS 证书是否正常
- LB/Ingress/Nginx 是否转发成功
- Service/Pod 是否健康
- 应用日志是否报错
- 命令思路：
ping、curl、dig/nslookup、telnet/nc、ss/netstat、日志查看。
易错点
- 一上来就怀疑代码，忽略 DNS、证书、代理、网络 ACL。
- 只在浏览器层面排查，不分层。
- 不知道 K8s 中还要检查
Service、Endpoints、Ingress、CoreDNS。
深挖点
- 如果浏览器超时但
curl正常，可能是跨域、证书、浏览器缓存、代理插件问题。 - 如果域名解析正常但访问 502，重点看 Ingress/Nginx 到上游的连通性。
- 如果集群内服务名不通，优先看 CoreDNS 和网络策略。
- 如果浏览器超时但
三、速记笔记
- 浏览器访问链路：
URL -> DNS -> TCP/TLS -> HTTP 请求 -> 代理/网关 -> 服务 -> 响应 -> 渲染 - DNS：先缓存，再递归；K8s 里重点看 CoreDNS
- TCP 三次握手：确认双方收发能力与序列号
- TIME_WAIT：主动关闭方；CLOSE_WAIT：被动关闭方未正确 close
- HTTPS：HTTP + TLS，解决 加密、完整性、身份认证
- HTTP/2：多路复用、头部压缩、二进制分帧
- 缓存：
- 强缓存：
Cache-Control/Expires - 协商缓存：
ETag/Last-Modified
- 强缓存：
- 跨域：浏览器同源策略问题，服务端靠 CORS 放行
- Cookie vs Session vs Token
- Cookie：浏览器存
- Session：服务端存
- Token/JWT：客户端携带
- K8s 运维关联重点：
DNS、Ingress、Service、证书、负载均衡、502/503/504 排障