PDD 9.18 后端开发一面：TCP 握手、listen 不 accept、HTTPS 与 MySQL 隔离级别

《面试题目》

1. 编程题：实现俄罗斯方块的下落逻辑。
2. 介绍一个你做过比较有意思、有挑战的项目。
3. TCP 三次握手的过程是什么？
4. 假设服务端监听了（listen）一个端口，但它不去 accept 新连接、也不处理请求，客户端仍然继续向服务端发送请求，这时候会发生什么？
5. HTTPS 是怎么保证安全的，具体协议过程是什么？
6. 进程间通信的方式有哪些？
7. Linux 系统下用 Ctrl+C 退出进程，这个过程中按 Ctrl+C 发生了什么？
8. MySQL 有哪几种隔离级别？不同隔离级别分别有什么问题？

《参考解析》

俄罗斯方块下落。 面试官通常看三件事：棋盘的数据结构、碰撞检测的边界、以及消行与重力的处理顺序。棋盘用二维数组（或每列一个高度数组）表示，方块用 4×4 的相对坐标矩阵加一个旋转状态；每次下落先算出新位置，越界或与已固定方块重叠就判定碰撞，不碰撞才提交位置。顺序上先固定当前方块、再消行、最后从上往下做重力压实，避免「消行后方块悬空」。如果要求旋转加墙踢，把旋转后的偏移依次尝试（原位置、左移、右移、上移）取第一个不冲突的。

listen 了但不 accept。 内核仍然会完成三次握手，把连接放进该 socket 的 accept 队列（已完成队列），所以客户端侧 connect 成功、可以发数据，数据进入服务端的接收缓冲区，客户端收到 ACK。队列被填满后（somaxconn / backlog 限制），新的 SYN 会被丢弃或按 tcp_abort_on_overflow 回 RST，客户端表现为连接超时或直接被重置；同时应用层永远读不到这些请求。这个问题的考点是「TCP 连接建立与 accept 是两件事」——accept 只是把已完成连接从队列取到应用层。

HTTPS 的过程。 核心是「用非对称加密协商出对称密钥，再用对称加密传数据，并用证书解决公钥归属」。握手阶段：客户端发 ClientHello（支持的版本、套件、随机数），服务端回 ServerHello + 证书链，客户端验证证书链到受信根、检查域名与有效期，然后用服务端公钥加密预主密钥（或走 ECDHE 交换），双方各自算出会话密钥，再发 Finished 校验握手未被篡改。之后的应用数据用对称算法（AES-GCM 等）加密并带 MAC 保证完整性。它同时给了机密性、完整性和身份认证——只加密不验证书，中间人照样能解密。

进程间通信。 管道与命名管道（字节流、半双工）、消息队列（有边界、可按类型取）、共享内存（最快，但要自己做同步）、信号量（同步手段，不传数据）、信号（异步事件通知）、Socket（可跨机）、以及 mmap 文件映射。答题时按「要不要跨机、数据量大小、是否需要同步」给选型，比背清单更有说服力。

Ctrl+C 到底发生了什么。 终端驱动把按键解释成控制字符，内核向该前台进程组发送 SIGINT；进程默认处理是终止，但可以捕获（比如做优雅退出）。所以严格说不是「终端杀了进程」，而是「终端发信号、进程按自己的处置策略退出」。如果进程在后台或有自定义 handler，Ctrl+C 可能毫无作用。

MySQL 隔离级别。 读未提交（脏读、不可重复读、幻读都可能）、读已提交（避免脏读，仍有不可重复读与幻读）、可重复读（InnoDB 默认，快照读靠 MVCC 保证可重复读，当前读靠间隙锁压制幻读）、串行化（全加锁，正确但并发最差）。要能补一句：InnoDB 的可重复读并没有完全消灭幻读——快照读与当前读混用时仍可能出现，这是很多人被追问的点。