Q1：TCP 和 UDP 有什么区别？在 K8s 场景下分别常见于哪些地方？
  • 核心要点
    • TCP 是 面向连接、可靠传输、按序到达 的协议。
    • UDP 是 无连接、尽力而为、不保证顺序 的协议。
    • TCP 有确认应答、重传、流量控制、拥塞控制；UDP 没有这些机制，协议头也更小。
    • K8s 场景里：
      • kube-apiserver、etcd、大多数 Web 服务通信通常走 TCP
      • DNS 常用 UDP 53，报文过大或特殊场景会回退到 TCP 53
      • 某些实时日志、监控、流式场景可能使用 UDP
  • 易错点
    • 不能简单说 UDP “不可靠就没用”，它适合 低时延 场景。
    • 不能说 TCP “一定更快”，TCP 是 更可靠，但控制开销更大。
    • DNS 不只是 UDP，也可能走 TCP。
  • 深挖点
    • 为什么视频、语音、游戏偏 UDP：允许少量丢包，但不能接受高延迟。
    • 为什么 K8s 控制面大量使用 TCP：状态一致性和可靠性交付更重要。
    • 如果面试官追问，可以补充：TCP 面向字节流，UDP 面向报文。
Q2：TCP 为什么能够保证可靠传输？
  • 核心要点
    • 通过 序列号 保证数据有序。
    • 通过 ACK 确认应答 确认数据是否到达。
    • 通过 超时重传 处理丢包。
    • 通过 校验和 检测传输错误。
    • 通过 流量控制 防止接收方被压垮。
    • 通过 拥塞控制 避免网络被打爆。
  • 易错点
    • 校验和只能发现错误，不能单独保证可靠性。
    • ACK 不是“每个包都单独确认”的绝对固定模式，还可能有 累计确认。
    • TCP 保证的是 传输层意义上的可靠，不代表应用一定正确处理了业务。
  • 深挖点
    • 如果出现乱序，接收端依赖序列号重排。
    • 如果 ACK 丢了，发送端可能触发重传，但接收端可根据序列号去重。
    • 可以延伸到 重传触发方式：超时重传、快速重传。
Q3：TCP 三次握手的过程是什么？为什么不是两次或四次？
  • 核心要点
    • 第一次：客户端发 SYN，表示想建立连接。
    • 第二次：服务端回 SYN + ACK，表示收到并同意建立。
    • 第三次：客户端回 ACK，表示确认，连接建立。
    • 三次握手的目的：确认 双方收发能力 都正常，并同步初始序列号。
  • 易错点
    • 不能只说“为了建立连接”，要说清楚 确认双向通信能力。
    • 两次握手不够，因为服务端无法确认客户端是否收到了自己的响应。
    • 四次握手没必要，因为第二次已经可以把 SYN 和 ACK 合并返回。
  • 深挖点
    • 为什么要同步初始序列号：避免历史报文干扰新连接。
    • K8s/运维场景里，若大量 SYN_RECV，可能是：
      • 半连接队列压力大
      • SYN Flood
      • 后端处理不过来
    • 可结合排障命令理解：ss -ant、netstat -ant。
Q4：TCP 四次挥手的过程是什么？为什么会有 TIME_WAIT？
  • 核心要点
    • 第一次：主动关闭方发送 FIN
    • 第二次：被动关闭方回 ACK
    • 第三次：被动关闭方处理完数据后发送 FIN
    • 第四次：主动关闭方回 ACK
    • 之所以四次，是因为 TCP 是 全双工，两个方向要分别关闭。
    • TIME_WAIT 常出现在 主动关闭方。
  • 易错点
    • 不能把三次握手和四次挥手混在一起说。
    • TIME_WAIT 不是异常，它是 TCP 的正常设计。
    • CLOSE_WAIT 不是同一个概念，通常说明应用没及时关闭连接。
  • 深挖点
    • TIME_WAIT 的作用：
      • 保证最后一个 ACK 能让对方收到
      • 让旧连接残留报文在网络中自然消失
    • K8s/运维里如果大量 TIME_WAIT，常见原因：
      • 短连接过多
      • 健康检查频繁
      • 上游/下游连接复用不足
    • 如果大量 CLOSE_WAIT，更像是 应用层没有正确 close。
Q5：TCP 的流量控制是怎么实现的？滑动窗口有什么作用？
  • 核心要点
    • 流量控制解决的是：发送方别发太快，接收方来不及处理。
    • TCP 通过 滑动窗口 实现流量控制。
    • 接收方在 ACK 中通告自己的 接收窗口 rwnd。
    • 发送方实际能发多少，要受窗口限制。
  • 易错点
    • 不要把 流量控制 和 拥塞控制 混为一谈。
    • 流量控制关注 接收端处理能力，拥塞控制关注 网络是否拥堵。
    • 发送窗口不只是“已发送未确认的数据”，还涉及可继续发送的范围。
  • 深挖点
    • 发送方真正可发送窗口通常受 min(cwnd, rwnd) 限制。
    • 如果接收窗口变成 0，会出现 零窗口等待/探测。
    • 在容器场景中，应用处理慢、缓冲区小，也会导致窗口缩小，表现为吞吐下降。
Q6：TCP 的拥塞控制有哪些阶段？分别有什么作用？
  • 核心要点
    • 慢启动：开始时谨慎探测网络能力，拥塞窗口快速增长。
    • 拥塞避免：达到阈值后改为线性增长，防止过快打满网络。
    • 快重传：收到 3 个重复 ACK，直接重传丢失报文，不等超时。
    • 快恢复：重传后不必回到最初状态，而是较快恢复传输。
  • 易错点
    • 不能说拥塞控制是为了保护接收方，那是流量控制的目标。
    • 不能把 cwnd 和 rwnd 混为一谈。
    • “3 个重复 ACK”是快重传的重要触发条件，容易漏掉。
  • 深挖点
    • 拥塞控制本质是在 吞吐量与网络稳定性 之间找平衡。
    • 在 K8s 集群里，如果出现网络抖动、丢包、延迟升高，TCP 吞吐会明显下降。
    • 面试如果继续问，可以补充：超时重传通常意味着比重复 ACK 更严重的拥塞判断。
Q7：TCP Keepalive 和 HTTP Keep-Alive 有什么区别？
  • 核心要点
    • TCP Keepalive 是 传输层保活机制，用于检测连接是否还活着。
    • HTTP Keep-Alive 是 应用层连接复用机制，用于一个 TCP 连接上复用多个 HTTP 请求。
    • 一个是“探活”，一个是“复用”。
  • 易错点
    • 名字像，但不是一个东西。
    • HTTP Keep-Alive 不等于 TCP Keepalive。
    • HTTP 长连接也不代表连接永远不关闭，仍然受超时和连接池策略影响。
  • 深挖点
    • K8s 中常见长连接场景：
      • API Server 与客户端
      • Ingress / Service 与后端
      • 监控采集、日志上报
    • 如果长连接中间被防火墙/NAT 清掉，TCP Keepalive 能帮助发现失效连接。
    • 运维排障时要区分：是 应用层连接复用问题，还是 传输层连接保活问题。
Q8：UDP 如何实现“可靠传输”？
  • 核心要点
    • UDP 自身不可靠，但应用层可以补齐机制。
    • 常见补齐手段：
      • 序列号
      • ACK 确认
      • 超时重传
      • 滑动窗口
      • 去重、乱序重排
    • 本质上是在应用层“模拟 TCP 的一部分能力”。
  • 易错点
    • 不能说“UDP 无法实现可靠传输”，准确说法是 UDP 协议本身不提供，但应用层可以实现。
    • 不能忽略代价：一旦自己补齐可靠性，复杂度会明显上升。
  • 深挖点
    • 为什么有些系统不直接用 TCP，而是基于 UDP 自研可靠协议：
      • 更可控的重传策略
      • 更低延迟
      • 更适配实时业务
    • 可以顺带提到：现代很多协议会在 UDP 之上实现更复杂能力。
Q9：运维面试中，为什么大量 TIME_WAIT、CLOSE_WAIT 会被重点问？
  • 核心要点
    • 这是传输层知识和线上排障能力的结合点。
    • TIME_WAIT 多：一般说明 主动关闭连接的一方很多，常见于短连接高并发。
    • CLOSE_WAIT 多：一般说明 对端已关闭，但本端应用没正确 close。
    • 对 K8s 运维来说，这经常关联到：
      • Pod 服务短连接风暴
      • Nginx/Ingress 连接复用不足
      • 健康检查过于频繁
      • 应用连接泄漏
  • 易错点
    • 不能简单把 TIME_WAIT 全都当问题。
    • CLOSE_WAIT 往往更值得警惕，因为它常指向 程序缺陷。
    • 不要只会背状态名，要能说出排查思路。
  • 深挖点
    • 排查方向：
      • 看连接状态分布
      • 看谁是主动关闭方
      • 看是否启用连接池/长连接
      • 看应用日志和 fd 使用情况
    • 常用命令：
      • ss -ant
      • netstat -ant
      • lsof -i
    • K8s 中可继续看：
      • Pod 内连接状态
      • Node 侧 NAT/conntrack 压力
      • Ingress / Service 转发路径

速记笔记

  • TCP：面向连接、可靠、按序、字节流；有重传、流控、拥塞控制
  • UDP：无连接、不保证可靠、报文导向；快、轻、适合低时延
  • 三次握手：确认双方收发能力 + 同步初始序列号
  • 四次挥手：TCP 全双工，两个方向分别关闭
  • TIME_WAIT：主动关闭方常见，保证最终 ACK 可达、旧报文消散
  • CLOSE_WAIT：多半是本端应用没正确关闭连接
  • 流量控制：防止接收方被压垮，靠 rwnd
  • 拥塞控制：防止网络被打爆，核心是 cwnd
  • 发送窗口：通常受 min(cwnd, rwnd) 约束
  • 快重传：3 个重复 ACK 触发
  • TCP Keepalive：保活探测
  • HTTP Keep-Alive：连接复用
  • K8s 高频关联：
    • API Server / etcd：TCP
    • DNS：UDP 为主，必要时 TCP
    • 运维排障高频：连接状态、重传、丢包、长短连接、TIME_WAIT/CLOSE_WAIT