考点:

  1. TCP/IP 基础

    • 四层/七层模型
    • TCP 三次握手、四次挥手
    • TCP 可靠传输、流量控制、拥塞控制
    • TIME_WAIT / CLOSE_WAIT

  2. HTTP / HTTPS / DNS

    • HTTP 常见状态码
    • HTTPS 握手过程、证书校验
    • DNS 解析流程、递归/迭代查询
    • CoreDNS 在 K8s 中的作用

  3. IP、路由、NAT

    • 子网划分、网关、路由转发
    • SNAT / DNAT
    • 公网/私网通信流程

  4. 二层三层基础

    • ARP 工作原理
    • 广播域、冲突域
    • VLAN / VXLAN

  5. 负载均衡

    • 四层负载均衡 vs 七层负载均衡
    • LVS / Nginx / HAProxy
    • K8s Service / Ingress 背后原理

  6. K8s 网络专项

    • Pod 网络通信机制
    • CNI 插件原理
    • Service、ClusterIP、NodePort、LoadBalancer
    • kube-proxy 的 iptables / IPVS
    • Overlay / Underlay
    • conntrack 问题

  7. 网络排障能力

    • 丢包、延迟高、端口不通
    • MTU 问题
    • DNS 故障
    • 抓包思路
Q1：TCP 三次握手和四次挥手分别是什么？为什么建立连接是三次，断开连接是四次？

  • 核心要点

    • 三次握手：
      • 第一次：客户端发送 SYN
      • 第二次：服务端返回 SYN + ACK
      • 第三次：客户端返回 ACK
    • 目的是确认双方的 发送能力 和 接收能力 都正常。
    • 四次挥手：
      • 一方发 FIN
      • 对方回 ACK
      • 对方处理完剩余数据后再发 FIN
      • 最后回 ACK
    • 断开连接需要四次，是因为 TCP 是 全双工，两端关闭发送通道通常要分开进行。

  • 易错点

    • 误以为三次握手是为了“防止重复连接请求”这一点就够了，其实本质还是 双方通信能力确认 + 建立初始序列号同步机制。
    • 误以为挥手也一定能合并成三次。只有在对方没有数据要发时，第二次和第三次才可能合并。

  • 深挖点

    • 为什么需要序列号？
    • SYN Flood 是什么？如何防御？
    • 半连接队列、全连接队列分别是什么？
    • K8s 中大量短连接场景下，三次握手失败可能和什么有关？
Q2：TIME_WAIT 和 CLOSE_WAIT 分别是什么？面试中怎么结合实际排查？

  • 核心要点

    • TIME_WAIT：主动关闭连接的一方进入，主要作用：
      • 确保最后一个 ACK 能到达对端
      • 防止旧连接的延迟报文影响新连接
    • CLOSE_WAIT：被动关闭连接的一方收到 FIN 后进入，说明对端已经关闭，但本端应用还没真正关闭 socket。
    • TIME_WAIT 多通常说明短连接很多。
    • CLOSE_WAIT 多通常说明应用没有及时关闭连接，更多偏应用问题。

  • 易错点

    • 把 TIME_WAIT 多直接判断成故障。很多高并发短连接场景本来就会多。
    • 把 CLOSE_WAIT 归因于内核参数，实际上多数是程序未正确 close()。

  • 深挖点

    • 2MSL 为什么存在？
    • 端口耗尽会带来什么问题？
    • K8s 节点上大量 TIME_WAIT 可能影响什么？
    • 如何通过 ss -antp、netstat、lsof 排查？
Q3：TCP 的流量控制和拥塞控制有什么区别？

  • 核心要点

    • 流量控制：解决发送方发太快，接收方来不及处理的问题。
      • 依据是接收窗口 rwnd
    • 拥塞控制：解决网络本身承载不过来的问题。
      • 依据是拥塞窗口 cwnd
    • 常见机制：
      • 慢启动
      • 拥塞避免
      • 快重传
      • 快恢复
    • 实际发送窗口取 min(rwnd, cwnd)

  • 易错点

    • 把流量控制和拥塞控制混为一谈。
    • 以为丢包一定是接收方处理不过来，很多时候是网络链路拥塞。

  • 深挖点

    • TCP 为什么用滑动窗口？
    • 重传超时和快速重传的区别？
    • 在跨机房或云环境中，RTT 增大会带来什么影响？
    • K8s 内部服务调用延迟上升，如何区分是应用慢、网络拥塞还是 DNS 问题？
Q4：HTTP 和 HTTPS 的区别是什么？HTTPS 握手过程大致是怎样的？

  • 核心要点

    • HTTP 明文传输；HTTPS = HTTP + TLS/SSL，加密传输。
    • HTTPS 的核心目标：
      • 加密
      • 身份认证
      • 数据完整性保护
    • TLS 握手大致流程：
      • 客户端发起握手，带支持的加密套件
      • 服务端返回证书、公钥等信息
      • 客户端验证证书
      • 双方协商会话密钥
      • 后续使用对称加密传输数据
    • 非对称加密通常用于密钥交换，对称加密用于正式数据传输。

  • 易错点

    • 误以为 HTTPS 全程都使用非对称加密。实际上正式传输阶段主要是对称加密。
    • 误以为有证书就一定安全，还要看证书是否可信、域名是否匹配、证书是否过期。

  • 深挖点

    • TLS 1.2 和 TLS 1.3 有什么区别？
    • 对称加密为什么更适合数据传输？
    • Ingress Controller 做 HTTPS 终止是什么意思？
    • K8s 中证书过期会导致哪些问题？
Q5：DNS 解析过程是怎样的？K8s 里 CoreDNS 常见故障有哪些？

  • 核心要点

    • DNS 解析一般流程：
      • 浏览器/系统缓存
      • 本地 DNS 服务器
      • 根域名服务器
      • 顶级域服务器
      • 权威域名服务器
    • 查询方式：
      • 递归查询
      • 迭代查询
    • K8s 中通常由 CoreDNS 负责集群内服务发现。
    • Pod 访问 Service 名称，本质上依赖 DNS 把服务名解析为 ClusterIP。

  • 易错点

    • 认为 DNS 只用于外网域名，实际上 K8s 集群内服务发现高度依赖 DNS。
    • 把 DNS 问题误判成应用问题或网络不通问题。

  • 深挖点

    • Pod 内 resolv.conf 里会有什么？
    • ndots 参数有什么影响？
    • CoreDNS 性能瓶颈怎么排查？
    • 如果出现“Pod 能 ping IP 但不能访问域名”，排查步骤是什么？
Q6：什么是 ARP？为什么有时候同网段通信也会失败？

  • 核心要点

    • ARP 用于根据目标 IP 获取目标 MAC 地址。
    • 同网段通信时，主机先通过 ARP 广播查询目标 MAC，再进行二层封装发送。
    • 若不在同网段，则发给默认网关，由网关转发。
    • ARP 表异常、MAC 学习异常、二层网络故障都可能导致通信失败。

  • 易错点

    • 误以为“同网段一定能直接通信”。还要看 ARP、交换机、VLAN 是否正常。
    • 把 ARP 当成三层协议，它本质上更偏二层与三层之间的解析机制。

  • 深挖点

    • 什么是 ARP 欺骗？
    • 免费 ARP 有什么作用？
    • 在云网络/K8s Overlay 网络里，ARP 表现和传统物理网络有什么不同？
Q7：什么是 SNAT 和 DNAT？它们在 K8s 里分别常见于哪些场景？

  • 核心要点

    • SNAT：修改源 IP
      • 常用于内网访问外网
      • 让返回流量能正确回到出口地址
    • DNAT：修改目标 IP
      • 常用于端口映射、负载均衡、Service 转发
    • K8s 中：
      • Pod 访问集群外部，可能涉及 SNAT
      • 访问 Service 时，kube-proxy 常会做 DNAT 转发到后端 Pod

  • 易错点

    • 把 SNAT 和 DNAT 的方向搞反。
    • 认为 NAT 只在公网出口场景才有，实际上集群内部 Service 转发也大量使用 NAT 思想。

  • 深挖点

    • kube-proxy 的 iptables 规则里是怎么做转发的？
    • NodePort 为什么能从节点端口访问到 Pod？
    • ExternalTrafficPolicy=Local 和 Cluster 有什么区别？
Q8：K8s 中 Pod 到 Pod、Pod 到 Service、集群外到 Service 的通信流程分别是怎样的？

  • 核心要点

    • Pod 到 Pod
      • 同节点：通常通过虚拟网卡/桥接直接通信
      • 跨节点：依赖 CNI 网络方案，通过路由或隧道转发
    • Pod 到 Service
      • 先访问 Service 的 ClusterIP
      • kube-proxy 根据规则转发到后端 Pod
    • 集群外到 Service
      • NodePort：通过节点 IP + 端口访问
      • LoadBalancer：云厂商负载均衡转发
      • Ingress：通常做七层代理转发

  • 易错点

    • 误以为 Service 就是一个真实进程。实际上 Service 多数是一个 虚拟 IP + 转发规则。
    • 误以为 ClusterIP 可以直接在集群外访问。

  • 深挖点

    • 为什么 K8s 要求“每个 Pod 都有独立 IP”？
    • Overlay 和 Underlay 网络的优缺点？
    • Calico、Flannel 的实现思路有什么区别？
    • 如果跨节点 Pod 不通，但同节点正常，优先怀疑什么？
Q9：iptables 和 IPVS 有什么区别？kube-proxy 为什么会涉及它们？

  • 核心要点

    • iptables：
      • 基于规则链匹配
      • 规则多时性能可能下降
      • 实现简单、兼容性强
    • IPVS：
      • 基于内核态负载均衡
      • 更适合大规模 Service
      • 支持更多调度算法
    • kube-proxy 的核心作用是维护 Service 到后端 Pod 的转发规则。

  • 易错点

    • 误以为 kube-proxy 自己转发流量。严格说它主要是 下发和维护规则，实际转发由内核网络栈完成。
    • 误以为用了 IPVS 就完全不用 iptables。实际仍可能配合使用。

  • 深挖点

    • iptables 模式下规则过多会有什么现象？
    • IPVS 支持哪些调度算法？
    • eBPF 替代 kube-proxy 的思路是什么？
    • 如何确认当前节点 kube-proxy 工作模式？
Q10：什么是 MTU？为什么在容器网络里容易出现“能连通但数据异常”？

  • 核心要点

    • MTU 是链路层单次可传输的最大数据帧大小。
    • 如果数据包超过 MTU，就需要分片，或者被丢弃。
    • 容器网络尤其是 Overlay 网络会增加额外封装头，导致可用 MTU 变小。
    • 常见现象：
      • 小包正常，大包异常
      • TCP 建连可以，但请求卡顿
      • 某些接口偶发超时

  • 易错点

    • 只检查“通不通”，忽略“大包是否正常”。
    • 把 MTU 问题误判成应用超时或 DNS 问题。

  • 深挖点

    • MSS 和 MTU 的关系是什么？
    • ping -M do -s 可以怎么辅助排查？
    • VXLAN 场景下 MTU 为什么更容易出问题？
    • K8s 跨节点调用偶发失败，如何验证是不是 MTU 问题？
Q11：四层负载均衡和七层负载均衡有什么区别？K8s 中分别对应什么组件？

  • 核心要点

    • 四层负载均衡
      • 基于 IP + 端口转发
      • 不理解 HTTP 语义
      • 性能高
    • 七层负载均衡
      • 理解 HTTP/HTTPS
      • 可按域名、路径、Header 转发
      • 功能更丰富
    • K8s 中常见对应：
      • 四层：Service、LVS、云 LB
      • 七层：Ingress、Nginx Ingress、Traefik

  • 易错点

    • 误以为 Ingress 是负载均衡器本体。Ingress 是规则对象，真正工作的通常是 Ingress Controller。
    • 把 NodePort 当成七层代理，它本质更偏四层暴露方式。

  • 深挖点

    • 七层代理为什么更灵活但开销更大？
    • HTTPS 终止放在 LB、Ingress、应用侧分别有什么优缺点？
    • K8s 中南北流量和东西流量分别怎么理解？
Q12：如果你排查一个 K8s 服务“访问超时”，你的网络排障思路是什么？

  • 核心要点

    • 分层排查：
      • 先看 DNS 是否正常
      • 再看 IP 是否可达
      • 再看端口是否监听
      • 再看 Service/Endpoints 是否正常
      • 再看 CNI、路由、iptables/IPVS、conntrack
    • 常用命令：
      • nslookup / dig
      • ping
      • curl
      • telnet / nc
      • ss -lntp
      • iptables -t nat -L -n
      • ipvsadm -Ln
      • tcpdump

  • 易错点

    • 一上来就怀疑应用代码，不先做基础网络验证。
    • 只在宿主机测，不进 Pod 内部验证。
    • 忽略 Endpoints 为空、NetworkPolicy 拦截、CoreDNS 异常等 K8s 特有问题。

  • 深挖点

    • tcpdump 应该抓哪个网卡？
    • conntrack 打满会有什么现象？
    • NetworkPolicy 会影响哪些流量？
    • 如果是“偶发超时”，和“稳定不通”，排查思路有什么不同？

三、速记笔记

  • TCP 三次握手：建立连接、确认收发能力、同步序列号。
  • TCP 四次挥手：TCP 全双工，双方关闭要分开。
  • TIME_WAIT：主动关闭方；防止旧包干扰新连接。
  • CLOSE_WAIT：被动关闭方；常见于应用未及时关闭连接。
  • 流量控制看接收方，拥塞控制看网络。
  • HTTP 明文，HTTPS 加密；TLS 中正式数据传输主要靠对称加密。
  • DNS 是 K8s 服务发现核心，CoreDNS 很重要。
  • ARP：IP 找 MAC；同网段通信先 ARP。
  • SNAT 改源地址，DNAT 改目标地址。
  • Service 本质是虚拟 IP + 转发规则，不是实际进程。
  • kube-proxy 负责维护 Service 转发规则，常见模式是 iptables / IPVS。
  • Overlay 网络 易遇到 MTU 问题。
  • 四层 LB 看 IP/端口，七层 LB 看 HTTP 语义。
  • K8s 排障口诀：先 DNS，后连通，再端口，再 Service/Endpoints，再节点网络规则。