网络与流量工程¶

网络请求失败时，如何按层建立端到端证据链？¶

技术说明

先明确五元组、方向、时间窗、失败比例与错误类型，再按 DNS¹→路由/邻居→TCP/UDP²→TLS³→HTTP/RPC⁴→应用依赖分层。客户端用 dig、ip route get、ss -ti、curl -v --trace-time 提供起点证据；服务端核对监听、accept、应用日志与代理指标。tcpdump -nn -s 0 在关键跳点短时抓取，使用 SYN、RST、重传和时序判断包在哪一段消失，而不是看到一个 RST 就猜防火墙。

分布式环境需要把客户端、负载均衡、网关、Pod/VM 和服务端时间对齐，记录 NAT⁵ 前后地址与请求 ID。抓包看不到加密后的业务内容，但仍可验证握手、RTT⁶、重传和连接关闭。镜像流量、全量 pcap⁷ 与 payload 可能泄露凭证和个人数据，必须限范围、限时长、加访问控制，并优先用统计聚合与头部脱敏。

实践经验

复合场景中，单可用区调用偶发超时。客户端抓包只有 SYN 重传，网关无请求日志，路由表正常；目标节点接口却有入包无回包，最终发现安全组自动化遗漏返程规则。团队先从健康区分流、回滚规则，代价是跨区费用和容量压力上升；长期对双向五元组做合成探测，网络策略变更使用差异检查和金丝雀。

面试回答要点

路由、ARP/邻居发现异常如何表现，怎样排查？¶

技术说明

主机发送包时先按策略路由、最长前缀和 metric 选择下一跳，再在二层通过 IPv4 ARP⁸ 或 IPv6 Neighbor Discovery 解析链路地址。ip rule、ip route get <dst> from <src> 比单看路由表更准确，因为它考虑源地址和策略；ip neigh 可见 REACHABLE、STALE、FAILED 等状态。多网卡、VRF、容器网络和非对称路由还会受到反向路径过滤及 conntrack⁹ 状态影响。

邻居缓存抖动可能由地址冲突、网关不可达、邻居表溢出或二层广播问题造成。用 arping（在获准网段）、邻居统计、交换机/MAC 表和抓包验证 request/reply。不要把 ICMP¹⁰ 不通直接等同服务不通，防火墙可能只阻断 ICMP；也不要随意清空全机邻居表，会造成瞬时广播风暴。路由修复需确认回程，否则单向可达仍会失败。

实践经验

复合场景中，扩容后同网段新节点间歇无法访问网关，ip neigh 大量 FAILED，系统日志提示 neighbor table overflow。团队先降低短连接扫描并扩展网关侧容量，而非只放大主机阈值；长期缩小二层故障域、调度扫描任务并按真实规模校准邻居缓存。增大缓存会消耗内核内存，故同步做容量上限和告警。

面试回答要点

MTU、MSS 与 PMTUD 问题为什么常表现为“小包通、大包不通”？¶

技术说明

MTU¹¹ 是链路可承载的最大三层包，TCP MSS 是一端声明愿意接收的 TCP payload 上限。路径中最小 MTU 决定实际可传大小；IPv4 可分片但设置 DF 后需依赖 ICMP “fragmentation needed”，IPv6 路由器不做中途分片。Path MTU Discovery（PMTUD）¹² 若所需 ICMP 被过滤，会形成黑洞：握手小包成功，携带证书或大响应的数据包重传直至超时。

排查用 tracepath、带 DF 与不同载荷的 ping（语法依平台）、ss -ti 的 MSS/重传，以及两端抓包观察大段重复。隧道、VPN、VXLAN/Geneve 会增加封装开销，底层 MTU 未预留时尤为常见。修复优先统一底层/覆盖网络 MTU并允许必要 ICMP；MSS clamping 是兼容性缓解，但可能掩盖错误路径且只覆盖 TCP。

实践经验

复合场景中，跨云 API 的 TCP 与小 JSON 正常，上传大请求稳定超时。抓包显示 TLS ClientHello 后某方向大段反复重传，tracepath 的路径 MTU 小于接口配置，VPN 新增封装未调整。团队先在边界做受控 MSS clamp 止血；长期统一隧道 MTU、放通 PMTUD ICMP并加入不同尺寸探测。减小 MSS 会增加包数和 CPU，是明确记录的代价。

面试回答要点

TCP 三次握手、listen/accept 队列与 SYN flood 如何关联？¶

技术说明

服务端收到 SYN 后维护半连接状态并回复 SYN-ACK，最终 ACK 到达后连接进入已完成队列，等待应用 accept()。Linux 中 backlog 受应用 listen(backlog) 和内核上限共同影响；半连接队列、accept 队列及其统计不能混为一谈。用 ss -lnt、nstat/netstat -s 的 listen overflow/drop、SYN retransmit 和应用 accept 速率判断瓶颈。

SYN cookies 可在半连接压力下减少状态占用，是抗攻击机制之一，但不能解决应用不 accept 或 CPU 饱和。盲目增大 backlog 会把拒绝变成排队并增加内存；应同时设置入口限速、扩容 accept 线程、优化连接复用和防护设备。握手超时还可能来自回程路由、ACL、源端口 NAT 或 SYN-ACK 丢失，需要双端抓包确认。

实践经验

复合场景中，促销开始后连接超时，服务 CPU 仍有余量。SYN 队列无明显溢出，但 accept queue overflow 激增，应用单 acceptor 被同步证书加载阻塞。团队回退证书热加载版本并扩容入口；长期把加载移出 accept 路径、增加队列溢出指标与连接压测。仅提高 backlog 的方案被拒绝，因为会放大客户端等待和内存占用。

面试回答要点

如何用 RTT、重传、拥塞窗口分析 TCP 吞吐和尾延迟？¶

技术说明

单连接吞吐受 RTT、丢包、接收/发送窗口和拥塞控制共同影响。ss -ti 可看到 RTT、rttvar、cwnd、retrans、pacing 等连接信息；nstat 与抓包帮助区分快速重传、RTO 和乱序。高 RTT 但无重传可能是物理距离或排队；少量丢包在高带宽时延积链路上会显著压低窗口。应用层超时过短也会在 TCP 尚能恢复时主动终止。

带宽时延积决定填满链路所需在途数据，socket buffer 与窗口缩放必须足够，但全局放大缓冲可能造成内存乘数效应和 bufferbloat。拥塞算法选择应符合内核与网络环境，改变算法要做双端/单端适用性验证。多个并发连接能绕开单流限制，却会损害公平性并增加握手、NAT 与下游压力。

实践经验

复合场景中，跨区域复制带宽只有链路能力的三分之一。ss -ti 显示高 RTT、周期性 RTO，运营商链路有微量丢包；团队先降低单批大小并启用断点续传，避免全批重试。长期建立专线质量 SLO、合理增大流缓冲并评估拥塞算法。并行流从 4 增至 8虽提吞吐，却挤压在线流量，因此通过 QoS 限定复制带宽。

面试回答要点

TIME_WAIT、CLOSE_WAIT 激增分别意味着什么？¶

技术说明

主动关闭 TCP 的一方通常进入 TIME_WAIT，以避免旧报文污染后续同四元组连接并能够重传最后 ACK；它是协议正确性机制，不等于泄漏。CLOSE_WAIT 表示对端已发 FIN，而本地应用尚未关闭 socket，长期、大量增长通常是应用未 close 或阻塞在清理路径。ss -tanp 按状态、本地/远端地址和进程聚合，再结合连接建立/关闭速率判断。

TIME_WAIT 多时优先使用长连接、连接池和 HTTP/2 复用，减少主动短连接；不应随意启用危险的旧式时间戳复用参数。CLOSE_WAIT 必须修应用生命周期，调内核超时通常无效。FIN_WAIT 与 RST 的解释也要结合谁主动关闭、是否有未读数据。容器/NAT 环境还需确认状态究竟在应用 namespace、sidecar、节点还是负载均衡器。

实践经验

复合场景中，服务调用下游逐渐报 fd 耗尽，ss 显示数万 CLOSE_WAIT，栈追踪发现异常响应分支未关闭 body。团队滚动重启并临时限制并发止血；长期采用自动关闭模式、错误路径测试和连接状态告警。另一轮 TIME_WAIT 增长则通过连接池解决，没有贸然改内核参数；池过大会长期占下游连接，故设置每主机上限和空闲回收。

面试回答要点

临时端口耗尽如何发生，如何与 fd、conntrack 问题区分？¶

技术说明

客户端出站连接需要本地 IP、临时端口、目标 IP/端口与协议组成唯一流。短连接率过高、TIME_WAIT 保留、单一 NAT 出口或狭窄 ip_local_port_range 会导致可用组合耗尽，常见错误为 EADDRNOTAVAIL 或连接超时。fd 耗尽通常是 EMFILE/ENFILE，conntrack 满则常伴内核丢包和表统计；三者可以同时发生，需分别取证。

检查 sysctl net.ipv4.ip_local_port_range、ss -s、按目标聚合 TIME_WAIT、NAT 网关端口指标和 /proc/sys/net/netfilter/nf_conntrack_*。缓解优先连接复用、减少重试风暴、增加源 IP/NAT 地址或目标分片；扩大端口范围有边界，不能与服务监听保留端口冲突。单纯降低 TIME_WAIT 会破坏旧包隔离，不是首选。

实践经验

复合场景中，任务平台从单 NAT IP 并发访问同一 SaaS 端点，主机 fd 尚充足，但大量新连接报地址不可用。NAT 指标显示端口分配失败，发布后的无连接池 SDK 将调用变成短连接。团队回滚 SDK、降低并发并增加出口 IP；长期统一 HTTP client、设连接池和重试预算。更多出口 IP 增加白名单及成本，纳入资产管理。

面试回答要点

一次域名解析经过哪些层，排查时为何要指定解析器？¶

技术说明

应用可能先查自身缓存和 NSS，glibc stub resolver 再依据 /etc/nsswitch.conf、/etc/resolv.conf 访问递归解析器；递归解析器按需从根、TLD 到权威服务器迭代，并缓存正向或负向结果。容器中还可能经本地 DNS cache、集群 DNS 和云 VPC resolver。getent hosts 更接近应用 NSS 行为，dig @server name type 用于隔离某一 DNS 服务器，两者结果不同不应惊讶。

排查要记录查询名、类型、搜索域展开、递归服务器、响应码、TTL、延迟和是否 TCP fallback。ndots 与 search 列表可能把短名扩展成多次查询；AAAA/A 并发及 Happy Eyeballs 也会影响感知。直接查询 8.8.8.8 不能代表生产路径，还可能绕过 split-horizon 私有解析，必须逐层比较而不是替换配置试运气。

实践经验

复合场景中，Pod 访问短名偶发慢，dig 完整域名正常。抓包显示 ndots:5 让短名依次尝试多个搜索域，其中一个上游超时后才查正确名称。团队先改调用为 FQDN 并缩短问题搜索域；长期审查 search/ndots、部署节点缓存并对每个响应码和上游延迟监控。改 ndots 可能破坏依赖短名的旧应用，因此分批验证。

面试回答要点

DNS TTL、负缓存和变更传播应如何设计？¶

技术说明

TTL 是缓存可复用记录的时间上限，不保证所有客户端恰好在该时刻刷新；应用、JVM、操作系统、中间递归器和浏览器可能有自己的最小/最大缓存策略。NXDOMAIN 等负响应也可按 SOA 相关字段缓存，误删记录恢复后仍可能持续失败。权威记录更新、注册商委派与 DNSSEC 链的传播路径不同，变更前应明确控制平面生效与缓存到期两段时间。

迁移通常先在至少一个旧 TTL 窗口前降低 TTL，再发布新旧端点并行，观察各地解析与流量，最后下线旧端点和恢复 TTL。极低 TTL 增加权威/递归负载并让故障更直接暴露；极高 TTL 降低查询量但减慢故障切换。DNS 只做粗粒度指向，健康检查与客户端连接复用会让流量迁移滞后，不能把 TTL 当精确排空时钟。

实践经验

复合场景中，团队直接把生产域名切到新 LB，TTL 原为一小时，却在十分钟后关闭旧 LB，造成部分地域失败。团队恢复旧端点并保持双栈服务直至缓存尾部消失；长期建立“降 TTL→等待旧 TTL→双端验证→切换→延迟下线”清单，并从多地域递归器合成探测。并行运行增加短期成本，但换取可回滚性。

面试回答要点

DNS 常见的约 5 秒延迟从何而来，怎样证伪？¶

技术说明

固定在数秒量级的 DNS 延迟常来自解析器超时后重试或切换 nameserver，而不是 DNS 协议规定所有请求都等待五秒。可能原因包括首选服务器丢包、UDP 响应过大需 TCP fallback 但 TCP/53 被阻断、搜索域产生无效查询、A/AAAA 某一类路径异常，或 conntrack/NAT 丢首包。具体超时取决于 resolver 实现与配置，不能凭“5 秒”直接定根因。

证据需要应用侧时间分解、resolv.conf、指定各 nameserver 的 dig +stats，并在客户端及 DNS 服务端抓 UDP/TCP 53。比较是否有重复 query ID、何时重发、是否收到 truncated 标志及 TCP SYN。修改 resolver timeout 只会缩短症状窗口，可能增加误失败；修复应针对丢包、容量、网络策略或不合理搜索域。

实践经验

复合场景中，只有部分节点每次首次请求多约 5 秒。抓包显示向第一个 DNS IP 的 UDP 查询无响应，超时后第二个立即成功；故障节点的网络策略漏放首选 DNS。团队先调整 nameserver 顺序和策略止血；长期做每节点到所有 DNS 端点的 UDP/TCP 探测，并在策略发布前验证。减少 attempts 虽能更快失败，却降低短暂抖动容忍度，未作为根治。

面试回答要点

TLS 握手失败或变慢时，应检查哪些阶段？¶

技术说明

TLS 1.3 的典型完整握手协商版本、密码套件和密钥材料，服务端发送证书与证明，客户端验证身份后建立流量密钥；会话恢复可减少计算与往返。排障先区分 TCP 连接、ClientHello、ServerHello、证书验证和 Finished 阶段。openssl s_client -connect host:443 -servername name -showcerts、curl -v 可检查 SNI、ALPN、证书链和时间，抓包可看握手时序及 alert，但无法直接看到加密应用数据。

常见失败包括证书过期/尚未生效、主机名 SAN 不匹配、中间证书缺失、客户端信任库过旧、版本/算法无交集、SNI 路由错误和 OCSP/CRL 访问问题。性能需看全握手比例、恢复命中、证书大小、签名算法、网络 RTT 与 CPU。启用旧协议或弱算法换兼容会扩大安全风险，应优先修客户端、分端点过渡并设淘汰期限。

实践经验

复合场景中，浏览器正常但部分 Java 客户端报链验证失败。s_client 显示 LB 只发送叶证书，浏览器通过缓存补全中间证书而精简信任库不能。团队补齐服务端 full chain 并保留旧入口短时过渡；长期对多种独立信任库做上线前探测，监控证书到期和握手 alert。双入口增加配置漂移风险，因此设明确下线日期。

面试回答要点

mTLS 与内部 PKI 如何实现可轮换、可撤销且不大面积中断？¶

技术说明

mTLS 中服务端和客户端都验证对方证书，身份通常来自 SAN URI/DNS 而非可变的 Common Name。PKI 需明确根、中间 CA、签发器、私钥托管、证书用途、有效期和信任分发。工作负载证书宜短期自动轮换，代理或应用必须热加载并在重叠窗口同时信任新旧 CA；只更新磁盘文件但进程不 reload 等同没有轮换。

撤销可依赖短证书降低窗口，或使用 CRL/OCSP，但在线状态检查本身有可用性、缓存和 fail-open/fail-closed 权衡。授权不能只看“由内部 CA 签发”，还要将具体身份映射到服务/操作权限。私钥最小暴露，最好由工作负载 API 或硬件/密钥服务提供；监控签发失败、剩余有效期、加载后的序列号与握手拒绝原因。

实践经验

复合场景中，中间 CA 轮换后约 15% 服务互调失败：部分旧 sidecar 未获得新 trust bundle。团队立即恢复双信任 bundle、暂停旧 CA 下线，并按实际握手身份盘点；长期把“先分发信任→验证→签新证→验证→撤旧信任”固化为状态机，使用短期证书与自动回滚。双信任期扩大被盗旧 CA 的窗口，故严格限定持续时间。

面试回答要点

HTTP/1.1 长连接、管线化与队头阻塞有哪些工程影响？¶

技术说明

HTTP/1.1 默认可复用 TCP 连接，减少握手与慢启动成本，但客户端和代理必须正确界定响应体长度并处理 keep-alive 超时。传统 pipelining 要按请求顺序返回响应，一个慢响应会阻塞同连接后续响应，且中间代理兼容性差；实践中更常用有限连接池并发。每个上游连接池需设置总数、每主机数、空闲超时、最大寿命与获取连接超时。

客户端、负载均衡器和服务端的空闲超时不协调会产生复用已被对端关闭连接，表现为间歇 RST/502。通常让外层或客户端提前淘汰、配合探活，但不存在对所有栈通用的固定大小关系。连接池过小会排队，过大会压垮下游、耗 fd 与端口；必须用池等待时间、活跃/空闲数、建立率和下游上限调优。

实践经验

复合场景中，代理更新后低流量时偶发 502。抓包显示应用在 120 秒复用连接，但 LB 在 60 秒已关闭，首个请求收到 RST。团队把代理空闲回收调短并重试仅限未发送请求；长期统一超时契约、监控连接年龄和 reset 来源。更频繁建连提高 TLS CPU，因此同时启用会话恢复并评估成本。

面试回答要点

HTTP/2 与 gRPC 的多路复用、流控和失败模式是什么？¶

技术说明

HTTP/2 在一个 TCP 连接上以 stream 多路复用，头部用 HPACK 压缩，并有连接级和流级流控。它消除了 HTTP 层按响应顺序的阻塞，但底层 TCP 丢包仍会让同连接所有 stream 等待重传。并发 stream 上限、窗口和单连接数需要与服务端能力匹配；只用一条连接可能形成故障与负载集中，多条连接又增加资源。

gRPC 基于 HTTP/2，deadline、取消、metadata、streaming 和状态码都应显式处理。代理必须支持 HTTP/2 与 trailer，健康检查通常需要专门协议；长流会影响负载均衡粒度和滚动排空。排查关注 stream reset、GOAWAY、窗口耗尽、消息大小、deadline exceeded 与连接级错误。应用级 keepalive 过于激进会制造探测风暴或被服务器拒绝。

实践经验

复合场景中，单 gRPC 连接承载数百流，某跨区链路微量丢包时所有调用 P99 同步尖峰。团队将客户端连接分为小规模池并就近路由止血；长期调流控窗口、限制每连接 stream、对 GOAWAY 做优雅重连。多连接提高 fd 与负载均衡离散度，故用压测确定而非无限增加。

面试回答要点

QUIC/HTTP/3 相比 TCP+TLS 改变了什么，迁移有哪些边界？¶

技术说明

QUIC 基于 UDP，在用户态实现可靠传输、拥塞控制和 TLS 1.3 集成；不同 stream 的丢包通常不会像单 TCP 连接那样互相阻塞。连接 ID 支持客户端网络变化时迁移，恢复连接可减少握手往返，0-RTT 可发送早期数据。但 0-RTT 可能被重放，只适合幂等或有防重放保护的操作，不能把所有写请求直接开放。

HTTP/3 运行于 QUIC，部署需保证 UDP 可达、LB 能正确路由连接 ID，并保留 HTTP/2 回退，因为某些网络会阻断或限速 UDP。可观测与抓包方式不同，用户态 CPU、加密和最大 UDP payload/PMTU 都要压测。协议升级不是自然获得更快：低 RTT、无丢包网络收益可能有限，中间设备和运营能力是重要成本。

实践经验

复合场景中，移动端启用 HTTP/3 后总体 P95 改善，但企业网络失败率上升，客户端通过 Alt-Svc 回退耗时。团队按网络类型灰度并缩短失败回退路径；长期监控 QUIC 握手、版本协商、UDP 不可达和回退率，边缘同时保留 H2。双协议增加容量与故障排查复杂度，因此只对显著受益流量开放。

面试回答要点

SNAT/DNAT 如何影响连接容量、回程路径与可观测性？¶

技术说明

SNAT 改写源地址/端口，常用于私网出站；DNAT 改写目标，常用于服务暴露。状态 NAT 必须记录原始与转换后的五元组，以便返程反向改写，因此受到端口空间、状态表容量和超时限制。同一源 IP 到同一目标的并发连接可能先耗尽可分配端口；增加实例而共享一个 NAT 出口并不一定增加容量。

NAT 会让服务端看到网关地址，影响审计、限流和哈希；需通过可信代理头或代理协议传递原地址，并限定可信跳数防伪造。非对称回程绕过原 NAT 设备会导致状态不匹配。排障应同时取 NAT 前后抓包、转换统计、端口分配失败与连接状态，核对路由是否确保会话双向经过同一有状态节点。

实践经验

复合场景中，双可用区出口网关切换后只有部分新连接超时，NAT 端口与 conntrack 容量均未接近上限。双点抓包显示出站流量经网关 A 完成 SNAT，回程却因路由收敛进入没有该会话状态的网关 B，随后被丢弃。团队先撤回不对称路由并把受影响流量固定到原状态路径；长期让会话哈希、路由健康与故障切换协同，flow log 同时记录原始/转换五元组。状态同步或路径粘性会增加带宽、复杂度并可能降低最优利用率，因此通过分区演练验证，而不是把问题误判为端口不足后盲目扩容 NAT。

面试回答要点

conntrack 表满为什么会造成“随机丢包”，怎样治理？¶

技术说明

netfilter conntrack 为有状态防火墙、NAT 等维护连接记录，TCP、UDP 等有不同状态和超时。表接近 nf_conntrack_max 时新流可能无法建表并被丢弃，内核日志常出现 table full；conntrack -S、/proc/sys/net/netfilter/nf_conntrack_count 与 max、按协议/状态聚合可确认。短 UDP 查询、短连接和重试风暴都可能快速制造大量条目。

直接增大上限会增加内核内存和哈希查找成本，只是容量措施之一。治理优先减少短连接、修正失控重试、分散 NAT/节点、对无需跟踪且安全的流量谨慎使用 NOTRACK；超时调整需理解协议，过短会让有效长连接失去状态，过长会占表。还要检查网络插件、sidecar 和节点升级是否改变了路径或 zone。

实践经验

复合场景中，DNS 与 HTTP 同时偶发首包丢失，CPU/带宽均正常。节点日志报 conntrack full，表中大量到失效下游的 SYN-SENT，客户端又立即重试。团队先熔断下游、限制重试并扩容节点；长期设置重试预算、分离高连接率任务，并按每条目内存校准上限。扩大表作为缓冲，但配套内存余量与占用告警。

面试回答要点

四层与七层负载均衡如何选型？¶

技术说明

四层 LB 基于 IP、端口和连接转发，通常协议透明、吞吐高，可承载 TCP/UDP，但难以按 HTTP 路径、header 或身份路由。七层 LB 终止并理解 HTTP/gRPC，可做路由、认证、重试、限流和观测，却增加解析、TLS、缓冲和配置复杂度。TLS 可在 LB 终止、透传或再加密，每种方案对证书管理、客户端身份和端到端加密不同。

选择依据协议、策略、性能、故障域和团队运营能力，而非“L7更高级”。长连接场景扩容后旧连接不会自动迁移；L7 body buffering 会增加内存和延迟；L4 保留源 IP 的方式可能约束拓扑。无论哪层都应明确健康检查、连接排空、跨区策略、容量和失败行为，并避免在多层代理重复重试。

实践经验

复合场景中，团队将大文件上传从 L4 迁到默认缓冲的 L7 网关，网关内存暴涨并产生 502。团队先对上传路径关闭全量缓冲、限制 body 并回退部分流量；长期把简单大流量路径放 L4/流式 L7，把需鉴权限流的 API 留 L7。架构多一入口增加证书和路由管理成本，统一在声明式配置中治理。

面试回答要点

轮询、最少连接、一致性哈希与会话粘性应如何权衡？¶

技术说明

轮询适合实例同质、请求成本接近；加权轮询表达容量差异。最少连接对长短请求混合更友好，但连接数不一定代表实际负载，例如 HTTP/2 一条连接可含大量流。基于延迟或 outstanding request 的算法更贴近负载，却可能因测量滞后产生羊群效应。负载算法必须结合慢启动、异常实例剔除和容量反馈。

一致性哈希按 key 稳定映射，在节点变化时减少重映射，适合缓存亲和；虚拟节点或 ring/hash 算法仍需处理热点 key 与容量不均。cookie/IP 粘性简化有状态应用，却削弱弹性、容灾和均衡，NAT 后大量用户还可能集中。优先把会话状态外置；若粘性不可避免，要有 TTL、失效转移和热点保护。

实践经验

复合场景中，WebSocket 使用最少连接，某些连接承载高频事件却与空闲连接计数相同，少数实例 CPU 打满。团队按连接+消息速率做加权分流并限制单连接速率；长期输出每实例 outstanding work，逐步拆分热点租户。更复杂算法对指标延迟敏感，因此保留静态加权回退和熔断阈值。

面试回答要点

健康检查如何避免误摘、抖动和级联故障？¶

技术说明

liveness 判断进程是否需要重启，readiness 判断是否接流量，startup 保护慢启动；外部 LB 健康检查则决定端点是否进入后端池。检查应轻量、有界、能代表服务处理能力，但不能每次深查所有下游，否则一个共享依赖故障会让全部实例同时 not-ready。阈值需用连续成功/失败、间隔和超时形成滞回，避免瞬时抖动频繁进出池。

readiness 可检查本地关键队列、线程池或初始化状态，对可降级的下游不应硬依赖。重启无法修复外部依赖，liveness 过敏会形成重启风暴。摘流量还要考虑 LB 传播、连接排空和最小健康容量；自动化应在健康实例少于阈值时停止继续摘除，并告警“检查本身”延迟和错误。

实践经验

复合场景中，数据库短暂抖动使所有 API readiness 深查失败，LB 同时摘除全部实例，实际可缓存读取也中断。团队将 readiness 改为本地能力、数据库故障走功能降级，恢复服务；长期分类关键/可选依赖、加入摘除速率限制和最小后端保护。代价是降级期间部分写请求返回明确 503，而不是全站不可用。

面试回答要点

多层代理下如何可靠保留客户端 IP 与请求身份？¶

技术说明

L7 常通过 Forwarded 或 X-Forwarded-For 传递原地址，L4 可使用 PROXY protocol 或保留源地址的转发模式。任何客户端都能自行发送 XFF，因此应用必须只信任已知代理，并从右向左按可信代理链解析第一个非可信地址；简单取最左或最右都可能被伪造或拿到最后一跳。PROXY protocol 需要监听端明确启用，协议不匹配会让首包解析失败。

客户端 IP 只能作为风险信号，不能当强身份：NAT、移动网络、IPv6 隐私地址和代理都会改变它。请求身份应使用经过验证的 token/mTLS，跨层传递 request/trace ID 时由入口覆盖外部不可信值或加签。日志要记录原始链、解析结果和代理节点，但对 IP 等个人数据设访问与保留策略。

实践经验

复合场景中，应用按 XFF 最左地址限流，攻击者自填不同地址绕过限制。团队在边缘删除外来头并重写，应用只信任两层固定代理网段；长期把限流主键改为认证主体+设备/IP复合信号，建立代理链契约测试。网段白名单会随基础设施变化，故由配置管理自动同步并默认拒绝未知跳点。

面试回答要点

Kubernetes Ingress 504 应如何分层定位？¶

技术说明

Ingress 是 API 资源，实际数据面由具体 controller 实现；504 通常表示网关等待上游超时，但可能发生在连接、响应头、响应体或下游代理任一层。先确认返回 504 的组件（响应头、访问日志、request ID），再核对 Ingress/Service/EndpointSlice、端口、协议、健康端点和控制器生成配置。用控制器指标区分 connect timeout、upstream response time、reset 与无可用后端。

从网关到 Pod 直接请求并对齐应用 trace，检查 DNS、网络策略、sidecar、连接池、请求排队及应用依赖。提高 proxy-read-timeout 可能让长任务完成，也可能占满连接并把故障拖长；同步请求应有明确 SLA，超长任务更适合异步化。不同 Ingress controller 的 annotation 名称与语义不同，必须查对应版本文档，避免复制无效配置。

实践经验

复合场景中，报表接口稳定在 60 秒返回 504，Pod 最终在 75 秒完成并继续耗资源。团队先将入口超时有限提高并限制并发，避免客户重复提交；长期改为异步作业+状态查询，客户端使用幂等键，网关超时恢复较短。提高超时期间占用更多 worker 是已知副作用，因此仅作为过渡且设到期项。

面试回答要点

Gateway API 相比 Ingress 解决了哪些组织与表达问题？¶

技术说明

Kubernetes Gateway API 将基础设施入口、监听器与具体路由拆为 GatewayClass、Gateway、HTTPRoute/TCPRoute 等资源，支持角色分工和跨 namespace 受控绑定。路由通过 parentRefs 连接 Gateway，Gateway 的 allowedRoutes 限定谁可附着；跨 namespace 引用后端通常需要 ReferenceGrant，避免租户任意引用他人服务。状态条件应作为控制面是否接受配置的证据。

它提供更结构化的匹配、过滤、权重和协议模型，减少各 Ingress controller 私有 annotation，但具体功能仍分标准支持级别且由实现决定。迁移需盘点 controller 支持的 API 版本、功能与状态，采用双入口/分域名金丝雀，验证证书、客户端 IP、超时、重试和观测。不要假设创建资源成功就代表数据面已生效。

实践经验

复合场景中，多团队共用 Ingress，平台管理员才能修改整份资源，发布冲突频繁。团队建立中心 Gateway 与命名空间自有 HTTPRoute，通过 allowedRoutes 和 ReferenceGrant 限定边界；先迁低风险域名，保留旧入口回滚。长期用策略检查和状态告警治理。资源数量增加带来认知成本，因此提供黄金模板与自助验证。

面试回答要点

如何设计端到端超时、重试、退避与重试预算？¶

技术说明

调用链总 deadline 应来自用户/业务 SLO，扣除网络、排队、计算和回退预算后向下游传播；每跳连接、首字节和总请求超时必须小于上游剩余 deadline。若每层独立使用同样超时并各重试三次，会产生乘法放大。服务应在剩余时间不足时尽早拒绝，取消信号要真正停止下游工作，而非客户端超时后服务仍继续执行。

重试只用于瞬时且可安全重放的错误，配指数退避、随机抖动和次数/时间上限。写操作需幂等键、条件更新或去重记录；连接 reset 时“服务端是否已执行”常不可知，不能默认安全。重试预算把额外请求限制为正常流量的一小部分，并由一层负责主要重试；尊重服务端 Retry-After，过载时宁可削峰。

实践经验

复合场景中，下游短暂延迟导致五层服务各重试两次，入口流量不变但数据库 QPS 增十余倍。团队在入口关闭通用重试、启用熔断和负载削减；长期只让最接近用户且掌握幂等语义的一层重试，传播 deadline，按服务设置重试预算。更早失败会提高短期错误率，却缩短恢复时间并保护核心事务。

面试回答要点

熔断、隔舱、限流和负载削减分别解决什么问题？¶

技术说明

熔断器在下游错误/慢调用达到阈值时快速失败，经过开放窗口后用少量 half-open 探测恢复；它保护调用方资源，但不增加下游容量。隔舱把线程池、连接池、队列或租户分开，防止一个依赖耗尽共享资源。限流控制允许进入的速率/并发，负载削减在容量不足时按优先级拒绝低价值工作。四者常组合，但配置不当会互相震荡。

触发信号应使用错误率、慢调用和资源饱和的滑动窗口，设最小样本量和滞回；全局/本地限流需考虑实例数变化。排队上限由允许等待预算决定，队列满时返回明确可重试状态并给出退避。降级必须定义数据新鲜度、权限和一致性边界，不能用陈旧缓存处理余额等强一致写入。

实践经验

复合场景中，推荐服务超时占满 API 共用线程池，登录也失败。团队将推荐调用熔断并返回空推荐，给认证独立池和并发保留；长期按业务优先级做 admission control、演练依赖慢而非仅宕机。隔舱降低资源利用率、降级损失个性化效果，但换取核心登录 SLO，权衡通过产品确认并量化。

面试回答要点