腾讯 WXG 面委一面：WebSocket 鉴权、HTTPS 加密与 Kafka 语义

《面试题目》

1. 自我介绍，然后讲讲你自己的开源项目。
2. 为什么使用 WebSocket？WebSocket 的认证方法是什么？
3. HTTP 和 HTTPS 的差别是什么？
4. HTTPS 的加密过程是怎样的？
5. Kafka 如何保证至少一次？
6. 快排的时间复杂度是多少？
7. 什么情况下会退化？为什么？
8. 介绍下 protobuf。

《参考解析》

为什么用 WebSocket：HTTP 是无状态、请求-响应式的，服务端不能主动推送；轮询（短轮询/长轮询）要么浪费请求、要么占用连接。WebSocket 通过一次 HTTP Upgrade 握手建立全双工的长连接，之后双方可以随时发帧，适合聊天、实时通知、协同编辑、行情推送。代价是要自己管理连接的生命周期（心跳保活、断线重连、消息去重与顺序）、以及服务端的连接数容量规划。

WebSocket 的认证是这题的重点，因为它和 HTTP 不同。常见的三种做法：一是在握手阶段带上凭据（Cookie 会在握手请求里自动带上，或者 URL 参数带 token），服务端在 Upgrade 之前校验，不通过就返回 401；二是握手成功后立即要求客户端发一条认证消息，未认证的连接在超时后关闭；三是用一次性票据（ticket）——先用常规 HTTP 接口换一个短期有效的一次性 token，再用它做握手，避免长期凭据出现在 URL 里。要补的一点是：WebSocket 握手之后就没有 HTTP 的中间件链了，所以鉴权、限流、审计都要在连接层自己做。

HTTP 与 HTTPS 的差别表面是端口（80/443）和 URL 前缀，本质是 HTTPS 在 HTTP 与 TCP 之间加了 TLS 层，提供加密（防窃听）、完整性校验（防篡改）、身份认证（防冒充）。代价是握手增加往返与计算开销，所以有 TLS 1.3 的 1-RTT（甚至 0-RTT 恢复）与会话复用。

HTTPS 的加密过程：客户端发 ClientHello（支持的 TLS 版本、密码套件、随机数）→ 服务端回 ServerHello（选定的套件、随机数）与证书（含公钥，由 CA 签名）→ 客户端验证证书链（是否可信 CA 签发、是否过期、域名是否匹配、是否被吊销）→ 密钥交换（TLS 1.2 的 ECDHE 或 TLS 1.3 的简化流程）→ 双方用 ECDHE 协商出预主密钥，再结合随机数导出会话密钥 → 之后的通信使用对称加密（AES-GCM 或 ChaCha20）。核心设计是「非对称加密只用来协商密钥，真正的数据传输用对称加密」，因为对称加密快几个数量级。

Kafka 的「至少一次」靠三件事配合：生产者侧设置 acks=all（等所有 ISR 副本确认写入）、开启重试、以及 enable.idempotence=true（幂等生产者，用 PID + 序列号让 broker 去重）；broker 侧靠副本机制（replication.factor ≥ 3、min.insync.replicas ≥ 2）保证消息不丢；消费者侧关闭自动提交、在处理完成后手动提交 offset——如果先提交再处理，进程崩溃就会丢消息（变成至多一次）；先处理再提交则可能重复处理（至少一次）。所以「至少一次」的完整答案是：不丢靠 acks + 副本 + 手动提交，重复靠消费端做幂等。

快排的时间复杂度：平均 O(n log n)，最坏 O(n²)，空间 O(log n)（递归栈）。退化的条件是每次划分都极不均衡——比如数组已经有序或逆序、且固定取第一个或最后一个元素作为基准，此时每次只减少一个元素，递归深度变成 n。避免办法是随机选基准、三数取中、或者用三路划分处理大量重复元素；工程上还常用「小数组切换插入排序」和「递归深度超限切换堆排序」的混合策略（introsort）。

protobuf 的介绍按「它解决什么问题」组织：它是一种接口定义语言 + 二进制序列化格式。相比 JSON，体积小（字段用编号而不是键名、变长编码）、解析快、有强类型和跨语言代码生成；代价是不可读（需要 .proto 才能解码）、schema 变更需要遵守兼容规则（字段编号不能复用、删字段要用 reserved 标记、新增字段要可选）。它的兼容性设计是「字段编号」——这也是为什么 .proto 里的编号一旦发布就不能改。

这场面试只有不到 20 分钟、七道题，说明面试官在用少量问题快速判断基础是否扎实。这类短面试的特点是每个问题都可能被追问一层，所以准备时不要停在定义上——比如答完快排 O(n log n) 就要准备好「为什么退化」「怎么避免」「工业实现怎么处理」这三层。