小红书一面：网络链路、TLS/QUIC 与负载均衡

《面试题目》

1. 个人介绍。
2. 客户端如何通过 TNC 配置、调度域名和 CDN 被路由到符合数据归属要求的 Region？
3. 流量进入后，如何经过四层负载、七层负载、API 和 RPC 完成更细粒度的调度？
4. TLS 1.3 相比 TLS 1.2 节省了多少 RTT？CA 证书的验证和获取流程是啥？中间 CA 缺失会怎么样？
5. QUIC 基于什么传输层协议？
6. DNS 与自定义客户端 SDK 调度相比有什么不足？
7. DNS 污染和 DNS 劫持分别是怎么发生的？
8. 了解 ClickHouse 吗？是否有实际使用经验？
9. 除了写代码，AI 还能如何帮助你完成文档编写、技术学习和陌生代码库阅读？
10. 如何保证 AI 生成的设计和代码质量？
11. 如果 AI 生成的代码上线后出现异常，你会如何测试、回滚，并结合日志和 AI 定位问题？
12. 了解 NAT 吗？
13. HTTPS 中客户端校验服务端 CA 证书的完整流程是什么？
14. 场景计算题：已知链路 RTT 和待传输数据大小，考虑 MSS 分包及 TCP 慢启动，如何估算传输轮次和总耗时？
15. TCP 慢启动和拥塞避免阶段的拥塞窗口分别如何增长？
16. 介绍一下 OSI 七层模型，以及七层负载均衡在请求链路中的位置和作用。
17. 你们从七层负载到 API、再到 RPC 的调用链路是怎样的？使用了哪些网关或 RPC 框架？
18. 你所在的团队在业务和底层架构之间承担什么角色？遇到数据面流量异常时如何与底层系统协同排查？
19. 了解 Maglev 吗？它解决什么负载均衡问题？
20. 如果使用 AI 做流量异常检测和故障排查，如何按客户端、网关、调度配置及后端链路分层定位？

《参考解析》

客户端怎么被调度到合规 Region

链路是多层配合的。客户端 SDK 定期拉取 TNC（流量与节点配置），配置里带版本号、灰度规则和兜底默认值，本地缓存一份以便离线可用；用户归属地、合规要求、网络质量共同决定目标 Region；SDK 用该 Region 对应的调度域名发起解析，解析走 HTTPDNS 或私有 DNS，避开 LocalDNS 的出口 IP 不准问题；解析结果指向 Region 内的 CDN 或接入点，CDN 边缘再回源到 Region 内的网关。工程要点是配置变更要能灰度、要能快速回滚、变更后要触发连接重建，并且任何一步失败都要有兜底 Region。

四层到七层到 API/RPC 的分工

四层负载（LVS、DPDK、配合 ECMP）只看 IP 和端口，转发性能高、能扛住入口流量，但看不到内容，做不了精细策略。七层负载（Nginx、Envoy）能解析 HTTP，按 Host、Path、Header、Cookie 做路由，承担 TLS 卸载、鉴权、限流、灰度，代价是性能开销更大。再往里是 API 网关做协议转换与聚合，服务之间走 RPC，由服务发现加负载均衡策略选实例，配超时、重试、熔断。原则是粗粒度分流放在外层，细粒度策略放在内层。

TLS 1.3 省下的 RTT 与证书链校验

完整握手 TLS 1.2 需要 2-RTT，TLS 1.3 降到 1-RTT，因为客户端在 ClientHello 里就把 key_share 带上了，服务端选定参数后立即能算共享密钥。会话恢复更快：1.2 靠 session ticket 做到 1-RTT，1.3 的 PSK 可以 0-RTT（但有重放风险，只能用于幂等请求）。1.3 还删掉了 RSA 密钥交换、静态 DH 和 CBC 类套件，只保留前向安全的 (EC)DHE，并且 ServerHello 之后的所有握手消息都加密。证书链校验流程：客户端用本地信任库定位根 CA，逐级验签构建到叶证书的链，校验证书有效期、SAN 中的域名匹配、扩展用途是否允许 serverAuth，查询吊销状态（CRL/OCSP，生产上多用 OCSP stapling），最后用叶证书公钥验证握手中的签名。中间 CA 缺失意味着链断了——服务端必须把中间证书一起下发，否则浏览器报错；部分客户端会尝试用证书里的 AIA 扩展去下载，但这会引入额外网络依赖和延迟，不可靠。

QUIC 与 DNS 的短板

QUIC 跑在 UDP 之上，把 TLS 1.3 内建进握手，做到 1-RTT 甚至 0-RTT 建连；每条流独立，天然没有 TCP 的队头阻塞；用 Connection ID 标识连接，切换网络（WiFi 转 4G）时连接不中断；多路复用不排队。代价是 UDP 常被中间设备限速或丢弃，用户态协议栈带来更高的 CPU 开销。DNS 的不足：递归解析链路长、TTL 缓存由别人控制、按 LocalDNS 出口 IP 做调度不准确（EDNS Client Subnet 只能部分缓解）、解析结果无法感知客户端真实网络质量，所以大厂会用 HTTPDNS 加客户端 SDK 调度来绕开。DNS 污染是在解析路径上注入伪造响应抢答；DNS 劫持是把解析结果改成攻击者可控的 IP（或直接改本地 DNS 配置）。防护手段包括 DoT/DoH 加密解析、DNSSEC 验签（防篡改但不防阻断）、以及自建 HTTPDNS。

慢启动、拥塞避免与链路耗时估算

慢启动阶段每个 RTT 拥塞窗口翻倍（1、2、4、8……），达到慢启动阈值 ssthresh 后进入拥塞避免，每个 RTT 只加约 1 个 MSS，呈线性增长。估算题的解法：先算 MSS（以太网 MTU 1500 减去 IPv4 头 20 字节和 TCP 头 20 字节，通常取 1460），初始窗口现代实现常取 10 个 MSS（RFC 6928），慢启动第 n 个 RTT 的发送量是 10 × 2^(n-1) 个 MSS，累计是 10 × (2^n - 1) 个 MSS；用总量除以单 MSS 得到需要的 MSS 数，解出最少轮次 n；总耗时等于轮次乘 RTT，再加上 DNS、TCP、TLS 的前置开销。要主动说明假设：没有丢包、接收窗口足够大、忽略延迟 ACK 与 Nagle 的影响，一旦丢包会进快速重传或超时重传，估算就不再成立。面试官想听的是建模过程，而不是一个精确数字。

Maglev 与七层负载的位置

Maglev 是 Google 的分布式四层负载均衡方案，核心是它的一致性哈希算法：后端列表变化时，绝大多数已有连接仍然映射到同一台后端，同时把重映射的连接尽量均匀摊开，避免了传统一致性哈希的负载倾斜；配合 ECMP 让多台 Maglev 对同一个流的选路保持一致，且不需要在实例之间同步状态。OSI 七层是物理、数据链路、网络、传输、会话、表示、应用；七层负载工作在应用层，位置在四层负载之后、业务服务之前，负责按内容路由、TLS 卸载、限流与灰度。

ClickHouse 的适用场景

列式存储加向量化执行，MergeTree 家族按主键排序存储、带稀疏索引和分区，适合千万到百亿行的宽表聚合分析（日志、埋点、行为分析）。写入要批量（每批尽量上千行），否则小批量会生成大量 part 拖慢合并；不适合高频点查、事务和复杂的多表 join。回答时可以带上真实用过的细节：分区键怎么选、物化视图怎么预聚合、遇到过 part 过多或内存超限怎么处理。

用 AI 做异常检测与分层排查

按链路分层定位：客户端层看版本分布、地域分布与 SDK 错误码；解析与调度层看 DNS 解析结果、TNC 配置版本与灰度比例；网关层看四层与七层的连接数、状态码、超时与限流指标；后端链路看 RPC 成功率、P99、依赖服务的错误。AI 在这里的价值是聚合多源指标做异常检测、把告警关联成同一条故障链、以及基于历史工单给出排查建议。同时要记住 AI 生成的代码和结论都要人把关：要有评测集、灰度发布、可回滚、以及关键路径的人工复核。