考点：

  • DNS 与服务发现
  • HTTP/HTTPS 基础与报文结构
  • HTTP/1.1、HTTP/2、HTTP/3 区别
  • TLS/SSL 握手、证书校验、HTTPS 加密过程
  • Cookie / Session / Token / JWT
  • 正向代理、反向代理、网关、Ingress
  • 长连接、短连接、Keep-Alive、连接复用
  • WebSocket、gRPC 的特点与适用场景
  • 应用层负载均衡、限流、重试、超时、熔断
  • 常见应用层问题排查方法
Q1：DNS 解析过程是怎样的？在 K8s 里 Service 是如何被解析到 Pod 的？

  • 核心要点

    • 用户访问域名时，通常会先查本地缓存、操作系统缓存、hosts 文件，再向本地 DNS 服务器发起递归查询。
    • DNS 查询过程中可能涉及根域名服务器、顶级域服务器、权威 DNS 服务器。
    • 在 K8s 中，集群内部通常由 CoreDNS 提供服务发现。
    • Pod 访问 service-name.namespace.svc.cluster.local 时，会由 CoreDNS 返回对应 Service 的 ClusterIP。
    • 若是 Headless Service，则返回后端 Pod IP 列表，而不是虚拟 IP。
    • 这是 K8s 服务发现的基础，和 Ingress、Service Mesh、微服务调用强相关。

  • 易错点

    • 容易把 Service 名称解析结果 和 Pod IP 混为一谈。
    • 容易忽略 ClusterIP Service 和 Headless Service 的区别。
    • 容易只会说公网 DNS，不会结合 K8s 里的 CoreDNS。
    • 容易误以为 DNS 一定是递归到底，实际上客户端通常是递归请求，本地 DNS 再进行迭代查询。

  • 深挖点

    • CoreDNS 的配置一般看哪个对象？答：ConfigMap。
    • 如果 CoreDNS 故障，集群里会出现什么现象？答：服务名无法解析，应用互调失败。
    • 如何排查 DNS 问题？
      • nslookup
      • dig
      • cat /etc/resolv.conf
      • 查看 CoreDNS Pod 日志
    • 为什么有时解析慢？
      • 上游 DNS 不稳定
      • CoreDNS 负载高
      • DNS 缓存命中率低
      • 应用频繁重复解析
Q2：HTTP 和 HTTPS 的区别是什么？为什么生产环境基本都用 HTTPS？

  • 核心要点

    • HTTP 是明文传输，HTTPS 是 HTTP + TLS/SSL。
    • HTTPS 提供三类核心能力：
      • 加密性：防止内容被窃听
      • 完整性：防止报文被篡改
      • 身份认证：确认服务端身份
    • HTTP 默认端口一般是 80，HTTPS 默认端口一般是 443。
    • 在 K8s 中，Ingress/Nginx/网关常承担 HTTPS 终止职责。

  • 易错点

    • 不能简单说“HTTPS 更安全”，要能说明具体安全在什么地方。
    • 容易误以为 HTTPS 会把所有内容都完全隐藏，实际上 域名、IP、证书部分信息 不一定完全隐藏。
    • 容易把 HTTPS 和“接口一定安全”画等号，实际上还要结合鉴权、限流、WAF 等。

  • 深挖点

    • HTTPS 为什么比 HTTP 慢？
      • 多了 TLS 握手
      • 加解密有计算开销
    • 现在为什么影响没那么大？
      • TLS 1.3 优化
      • 会话复用
      • 长连接
      • 硬件性能提升
    • K8s 中 HTTPS 证书通常怎么管理？
      • Secret
      • cert-manager
      • ACME 自动签发
Q3：HTTPS/TLS 握手过程你怎么讲？证书校验是怎么做的？

  • 核心要点

    • 客户端先发起握手，声明支持的 TLS 版本、加密套件等。
    • 服务端返回证书、公钥、协商好的加密参数。
    • 客户端验证证书合法性：
      • 是否在有效期内
      • 域名是否匹配
      • 是否由受信任 CA 签发
      • 证书链是否完整
    • 验证通过后，双方协商会话密钥，后续用对称加密传输应用数据。
    • 非对称加密主要用于身份验证和密钥交换，对称加密用于真正的数据传输。

  • 易错点

    • 容易说成“HTTPS 全程都用非对称加密”，这是不对的。
    • 容易忽略证书校验中的 域名匹配。
    • 容易把 CA、证书、公钥、私钥的关系讲乱。

  • 深挖点

    • 为什么数据传输不用纯非对称加密？
      • 性能差，成本高。
    • 自签证书为什么浏览器默认不信任？
      • 不在受信任 CA 链中。
    • 运维里常见证书问题有哪些？
      • 证书过期
      • 证书域名不匹配
      • 证书链不完整
      • Secret 挂载后应用未热更新
    • 常用排查命令
      • openssl s_client -connect host:443
      • curl -v https://host
Q4：HTTP/1.1、HTTP/2、HTTP/3 的主要区别是什么？

  • 核心要点

    • HTTP/1.1
      • 默认支持长连接
      • 存在队头阻塞问题
      • 常通过多个 TCP 连接并发请求来缓解
    • HTTP/2
      • 二进制分帧
      • 多路复用
      • 头部压缩
      • 一个 TCP 连接上可并发多个流
    • HTTP/3
      • 基于 QUIC
      • QUIC 基于 UDP
      • 进一步优化握手和队头阻塞问题
    • 在云原生场景里，网关、Ingress、Service Mesh 往往会涉及 HTTP/2 和 gRPC。

  • 易错点

    • 不要说 HTTP/2 消除了所有队头阻塞，它只是解决了应用层的部分问题，TCP 层仍可能存在影响。
    • 不要把“HTTP/3 基于 UDP”直接理解为“不可靠”，QUIC 自身实现了可靠性机制。
    • 不要把长连接和 Keep-Alive 完全等同于 HTTP/2。

  • 深挖点

    • 为什么 gRPC 常基于 HTTP/2？
      • 多路复用
      • 流式传输
      • 更高性能
    • 为什么 QUIC 更适合弱网场景？
      • 连接建立更快
      • 丢包恢复机制更灵活
    • 实际生产中为什么 HTTP/3 没有完全替代 HTTP/2？
      • 生态成熟度
      • 网络设备兼容性
      • 运维观测和代理链路支持差异
Q5：GET 和 POST 有什么区别？幂等性是什么意思？为什么运维要关心它？

  • 核心要点

    • GET 通常用于获取资源，POST 通常用于提交数据。
    • GET 一般是幂等的，POST 通常不是幂等的。
    • 幂等指：多次执行同一请求，结果和执行一次相同。
    • 运维要关注幂等性，因为网关、代理、重试机制、超时重发都可能导致请求被重复提交。
    • 在服务治理里，重试策略必须结合接口幂等性设计。

  • 易错点

    • 不能说“GET 没有请求体，POST 才有请求体”，这是不严谨的。
    • 不能把“安全方法”和“幂等方法”混为一谈。
    • 不能简单认为 POST 一定不幂等，业务上也可以通过幂等号设计实现幂等。

  • 深挖点

    • 哪些方法通常是幂等的？
      • GET
      • PUT
      • DELETE
    • 为什么支付、下单接口必须做幂等？
      • 防止重复扣费、重复创建订单。
    • K8s/网关中哪些机制会触发重复请求？
      • 超时重试
      • 代理层重发
      • 客户端失败重试
      • 负载均衡切换
Q6：Cookie、Session、Token、JWT 有什么区别？

  • 核心要点

    • Cookie：浏览器保存在本地的小数据，常随请求自动携带。
    • Session：服务端保存的会话状态，客户端通常通过 Cookie 携带 Session ID。
    • Token：服务端签发给客户端的凭证，客户端后续请求主动携带。
    • JWT：一种自包含的 Token 格式，包含头、载荷、签名。
    • 在分布式和 K8s 场景下，Token/JWT 通常比传统 Session 更利于横向扩展。

  • 易错点

    • Cookie 不是天然不安全，不安全往往来自配置不当。
    • JWT 不是天然“更安全”，它只是更适合某些分布式场景。
    • 不要把“无状态”理解成系统里完全没有状态，通常只是服务端不保存会话状态。

  • 深挖点

    • Session 在多副本部署中有什么问题？
      • 会话不共享
      • 需要粘性会话或集中式 Session 存储
    • JWT 的风险是什么？
      • 一旦签发，吊销困难
      • Token 泄露影响较大
      • 载荷不能存敏感明文
    • Cookie 常见安全属性有哪些？
      • HttpOnly
      • Secure
      • SameSite
Q7：什么是正向代理、反向代理？K8s 里的 Ingress 更接近哪一种？

  • 核心要点

    • 正向代理：代理客户端，服务端通常不知道真实客户端是谁。
    • 反向代理：代理服务端，客户端通常无感知后端真实节点。
    • Ingress / Nginx Ingress / APISIX / Traefik 本质上更接近 反向代理。
    • 反向代理常用于：
      • 路由转发
      • TLS 终止
      • 负载均衡
      • 限流
      • 鉴权
      • 灰度发布

  • 易错点

    • 很多人只会背定义，不会结合实际场景。
    • 容易把 Nginx、网关、Ingress 全混在一起说。
    • Ingress 不是 Service，它们职责不同：
      • Service 解决集群内服务访问
      • Ingress 解决集群外七层入口访问

  • 深挖点

    • Ingress 和 四层负载均衡有什么区别？
      • Ingress 更偏七层，能看 Host、Path、Header。
    • 反向代理为什么能做灰度？
      • 可以按路径、Header、Cookie、权重做转发策略。
    • 若面试官继续追问，可延伸到：
      • Ingress Controller 工作原理
      • 配置下发
      • 动态 reload
      • upstream 健康检查
Q8：WebSocket 和 HTTP 有什么关系？在运维场景中要注意什么？

  • 核心要点

    • WebSocket 建立过程通常先通过 HTTP/HTTPS 发起升级握手，然后升级为全双工长连接。
    • 它适合实时通信场景，如：
      • 在线聊天
      • 实时监控
      • 推送通知
    • 在 K8s 中，如果经过 Ingress/代理层，需要确认是否支持 Upgrade 头和长连接配置。

  • 易错点

    • WebSocket 不是完全独立于 HTTP 的起步协议。
    • 容易忽略代理层超时配置，导致连接被意外断开。
    • 容易把 WebSocket 和 SSE 混淆。

  • 深挖点

    • 为什么 WebSocket 更适合实时推送？
      • 服务端可主动推送数据。
    • 经过 Nginx/Ingress 时常见问题有哪些？
      • Upgrade 头未透传
      • 连接超时过短
      • 负载均衡导致会话漂移
    • 如何排查？
      • 浏览器开发者工具
      • Nginx/Ingress 日志
      • 连接数与超时配置检查
Q9：gRPC 是什么？为什么云原生里经常提到它？

  • 核心要点

    • gRPC 是一种高性能 RPC 框架，通常基于 HTTP/2。
    • 使用 Protocol Buffers 作为接口定义和序列化方式。
    • 支持：
      • 一元调用
      • 服务端流
      • 客户端流
      • 双向流
    • 在微服务、Service Mesh、内部服务通信中很常见。

  • 易错点

    • 不要把 gRPC 简单等同于“就是 HTTP 接口”。
    • 不要忽略它对代理、网关、可观测性的要求更高。
    • 不要只谈性能，不谈调试复杂度和浏览器兼容问题。

  • 深挖点

    • gRPC 为什么性能通常比 REST 更高？
      • Protobuf 更紧凑
      • HTTP/2 多路复用
    • 为什么很多公网 API 不直接用 gRPC？
      • 浏览器支持、生态、调试便利性等因素。
    • Ingress 转发 gRPC 需要注意什么？
      • 是否支持 HTTP/2
      • 超时配置
      • 流式请求支持
      • 错误码映射
Q10：应用层常见故障怎么排查？比如“服务能通 IP，但域名不通；HTTPS 握手失败；接口偶发 502”。

  • 核心要点

    • 先分层排查：域名解析 -> TCP 连通 -> TLS 握手 -> HTTP 状态码 -> 应用日志。
    • 常见工具：
      • nslookup
      • dig
      • curl -v
      • openssl s_client
      • kubectl logs
      • kubectl describe
    • 502 常见于：
      • 上游服务不可达
      • 端口配置错误
      • 探针异常导致无可用后端
      • 代理和后端协议不匹配
    • 504 常见于：
      • 上游响应超时
    • 499 常见于：
      • 客户端提前断开连接（Nginx 语境下）

  • 易错点

    • 只盯着应用日志，不看代理层和 DNS。
    • 看见 502 就说是应用代码问题，实际上可能是网关配置问题。
    • 忽略 Service、Endpoints、Pod Ready 状态。

  • 深挖点

    • 如果域名不通但 IP 通，优先怀疑什么？
      • DNS 配置
      • CoreDNS
      • resolv.conf
      • hosts
    • 如果 HTTPS 失败但 HTTP 正常，优先查什么？
      • 证书
      • SNI
      • TLS 版本
      • 代理配置
    • 如果 Ingress 返回 502，排查顺序是什么？
      • Ingress 规则
      • Service 端口
      • Endpoints
      • Pod 监听端口
      • 应用健康状态

速记笔记

  • DNS

    • K8s 内部服务发现核心是 CoreDNS
    • ClusterIP 返回虚拟 IP，Headless Service 返回 Pod IP 列表

  • HTTP/HTTPS

    • HTTP 明文；HTTPS = HTTP + TLS
    • HTTPS 解决：加密、完整性、身份认证

  • TLS

    • 非对称加密：身份验证/密钥交换
    • 对称加密：真正传输数据
    • 常见问题：证书过期、域名不匹配、证书链不全

  • HTTP版本

    • 1.1：长连接，但存在队头阻塞
    • 2：二进制分帧、多路复用、头部压缩
    • 3：基于 QUIC/UDP，弱网体验更好

  • 接口设计

    • 幂等性非常关键，尤其是重试场景
    • 网关/代理/客户端都可能导致重复请求

  • 鉴权

    • Cookie 存客户端
    • Session 存服务端
    • Token/JWT 更适合分布式部署
    • JWT 方便扩展，但吊销困难

  • 代理与入口

    • 正向代理代理客户端
    • 反向代理代理服务端
    • Ingress 本质上是集群入口的七层反向代理

  • 实时通信

    • WebSocket：先 HTTP Upgrade，再全双工通信
    • gRPC：基于 HTTP/2，适合内部高性能服务调用

  • 排障口诀

    • 先 DNS，再 TCP，再 TLS，再 HTTP，再应用
    • 先入口，再 Service，再 Endpoints，再 Pod，再日志