网络与操作系统

一、知识体系

1. 计算机网络 ★★★

1.1 网络分层模型

• 核心结论
  • 面试里常用的是 TCP/IP 四层模型，OSI 七层更多用于帮助理解。
  • 分层的价值是解耦职责，每一层只关注自己的问题：应用层关心语义，传输层关心端到端传输，网络层关心寻址与转发，链路层关心局域网内帧传输。
• 原理展开
  • OSI 七层是理论模型，TCP/IP 四层是工程上更常见的抽象。
  • 各层核心协议可以按“解决什么问题”来记：
    • 应用层：HTTP/HTTPS/DNS/SMTP，定义数据如何表达和交互。
    • 传输层：TCP/UDP，定义端到端传输方式。
    • 网络层：IP/ICMP/ARP，定义寻址、路由和网络可达性。
    • 数据链路层：Ethernet，负责同一链路内的帧传输。
• 面试怎么答
  • “我一般按 TCP/IP 四层来讲。分层不是为了背模型，而是为了隔离问题边界。比如 HTTP 是应用层协议，TCP 负责可靠传输，IP 负责寻址和路由，Ethernet 负责链路内传输。”
• 易错点
  • 不要把 ARP 和 DNS 混为一谈。ARP 解决 IP 到 MAC 的映射，DNS 解决域名到 IP 的映射。

1.2 TCP协议 ★★★

三次握手

• 核心结论
  • 三次握手的目标不是“形式上建立连接”，而是确认双方的收发能力和初始序列号。
• 原理展开
  • 第一次：客户端发 SYN，表示“我想建连，并告诉你我的初始序列号”。
  • 第二次：服务端回 SYN + ACK，表示“我收到了你的建连请求，也告诉你我的初始序列号”。
  • 第三次：客户端回 ACK，表示“我确认收到了你的响应，连接正式建立”。
  • 不是两次的原因，是服务端无法确认客户端是否具备接收能力，也无法规避失效历史报文导致的误建连。
  • 不是四次的原因，是服务端的确认和自己发起建连可以合并为一次 SYN + ACK。
• 面试怎么答
  • “三次握手本质上是在同步双方的建连意图、确认收发能力并交换初始序列号。两次不够，主要是服务端没法确认客户端的接收能力，也可能被历史 SYN 报文误导。”
• 易错点
  • 不要把“三次确认双方收发能力”机械背诵成口诀，最好顺着每一步为什么存在来解释。

四次挥手与 TIME_WAIT

• 核心结论
  • 挥手是四次，因为 TCP 支持半关闭，一方不发数据了，不代表另一方也立刻发完了。
• 原理展开
  • 主动关闭方发送 FIN，表示自己没有数据要发了。
  • 被动关闭方先回 ACK，但此时还可能继续发送剩余数据。
  • 等被动关闭方也发完后，再发送自己的 FIN。
  • 主动关闭方最后回 ACK，进入 TIME_WAIT。

TIME_WAIT状态 ★★★

• 核心结论
  • TIME_WAIT 的核心作用有两个：确保最后一个 ACK 能到达；让旧连接残留报文在网络中自然消失，避免污染新连接。
• 原理展开
  • 持续时间通常是 2MSL。如果最后 ACK 丢了，被动关闭方会重发 FIN，主动关闭方还在 TIME_WAIT 才能重新确认。
  • 高频短连接场景下，大量 TIME_WAIT 会占用本地端口和连接表资源。
• 面试怎么答
  • “TIME_WAIT 不是异常状态，而是 TCP 的安全兜底。它保证最后 ACK 的可靠性，也防止旧报文污染新连接。大量 TIME_WAIT 说明连接创建和关闭太频繁，要优先从连接复用和调用模式上优化。”
• 易错点
  • 不要把所有 TIME_WAIT 都当问题。服务端正常承接大量短连接时，出现一定规模的 TIME_WAIT 是合理现象。

CLOSE_WAIT堆积

• 核心结论
  • 大量 CLOSE_WAIT 往往不是网络问题，而是应用层没有及时关闭 socket。
• 面试怎么答
  • “TIME_WAIT 更多是主动关闭方的协议后果，CLOSE_WAIT 堆积通常是代码问题，说明对端已经发来 FIN，但本地迟迟没有 close。”

可靠传输机制

• 核心结论
  • TCP 的可靠，不是靠单一机制实现的，而是序列号、确认应答、重传、滑动窗口、流量控制、拥塞控制共同作用。
• 原理展开
  • 序列号与确认号保证数据有序和可确认。
  • 滑动窗口解决“不能每发一段就停下来等 ACK”的性能问题。
  • 流量控制保护接收方，核心依据是接收窗口。
  • 拥塞控制保护网络，核心依据是拥塞窗口。

滑动窗口(Sliding Window) ★★

• 核心结论
  • 滑动窗口的本质是把“停等协议”升级为“批量发送 + 累积确认”，提升链路利用率。
• 面试怎么答
  • “窗口越大，不代表越快；真正生效的发送能力取决于发送窗口、接收窗口和拥塞窗口三者的最小值。”

拥塞控制 ★★★

• 核心结论
  • 拥塞控制解决的是“网络扛不扛得住”，不是“接收方来不来得及处理”。
• 原理展开
  • 慢启动：指数增长，快速摸到可用带宽区间。
  • 拥塞避免：线性增长，避免过快打满网络。
  • 快速重传：收到 3 个重复 ACK 后提前重传，不等超时。
  • 快速恢复：出现轻度拥塞后不回到最初状态，而是在减半窗口基础上继续探测。
  • BBR 的思路不同，它尝试基于带宽和时延建模，不再只靠丢包信号判断拥塞。
• 面试怎么答
  • “流量控制关注接收端，拥塞控制关注整个网络。传统 Reno/Cubic 主要基于丢包调整，BBR 更像是在估算瓶颈带宽和最小 RTT。”
• 易错点
  • 不要把拥塞窗口和接收窗口混成一件事。

TCP粘包/拆包 ★★

• 核心结论
  • 粘包/拆包不是 TCP 出错，而是因为 TCP 只保证字节流，不提供消息边界。
• 原理展开
  • 发送端可能合并多次写入，接收端也可能一次读到半包、多包或半包加半包。
  • 解决思路是由应用层定义边界：
    • 定长协议。
    • 分隔符协议。
    • 长度前缀协议，生产最常见。
    • 自定义报文头。
• 面试怎么答
  • “TCP 没有包边界，业务协议必须自己定义消息边界。实际项目里最稳的方案通常是固定头 + 长度字段 + 消息体。”
• 易错点
  • 不要说“TCP 会粘包，UDP 不会粘包，所以 UDP 更适合业务消息”。UDP 的问题是它不保证可靠性和顺序。

1.3 UDP协议 ★

• 核心结论
  • UDP 的核心优势是轻量和低时延，不是“更先进”。
• 原理展开
  • 无连接、无重传、无拥塞控制，协议开销小。
  • 常见场景是 DNS、音视频实时流、在线游戏，以及基于 UDP 自己实现可靠传输的 QUIC。
• 面试怎么答
  • “UDP 适合可以容忍少量丢包、但更在意时延的场景；TCP 适合要求有序、可靠、完整传输的场景。”

1.4 HTTP协议 ★★★

HTTP/1.0 vs HTTP/1.1 vs HTTP/2 vs HTTP/3

• 核心结论
  • 版本演进的主线，可以概括成三个词：复用、压缩、降延迟。
• 原理展开
  • HTTP/1.0 以短连接为主，请求开销大。
  • HTTP/1.1 支持持久连接，默认 Keep-Alive，但同一连接上的请求处理仍容易出现队头阻塞。
  • HTTP/2 引入二进制分帧、多路复用、头部压缩，显著提升连接复用效率。
  • HTTP/3 基于 QUIC/UDP，把传输层与加密协商一起优化，重点解决 TCP 层队头阻塞和建连时延问题。
• 面试怎么答
  • “HTTP/1.1 解决了连接复用问题，HTTP/2 解决了应用层并发复用和头部冗余问题，HTTP/3 继续往下沉，把传输层建连成本和丢包阻塞问题一起优化。”
• 易错点
  • HTTP/2 的多路复用解决的是应用层队头阻塞，不代表 TCP 层丢一个包不影响整个连接。

HTTP方法

• 核心结论
  • GET/POST/PUT/DELETE/PATCH 的区别，本质是语义约定，不是“谁能传参谁不能传参”。
• 面试怎么答
  • “GET 主要用于获取资源，POST 常用于创建或触发处理，PUT 强调整体更新，PATCH 强调部分更新，DELETE 表示删除语义。语义一致性比表面形式更重要。”

状态码

• 核心结论
  • 状态码不是死背清单，面试更关注你是否理解常见状态对应的系统行为。
• 原理展开
  • 200/201/204 代表成功但语义不同。
  • 301/302/304 反映重定向和缓存协商。
  • 401/403 经常被混淆：前者偏认证，后者偏已识别身份但无权限。
  • 429 是限流场景高频码，502/503/504 常用于网关和上游服务异常定位。

HTTP缓存 ★★

• 核心结论
  • 强缓存和协商缓存的区别，在于浏览器是否连请求都不用发。
• 原理展开
  • 强缓存依赖 Cache-Control / Expires，命中后直接使用本地副本。
  • 协商缓存依赖 ETag/If-None-Match 或 Last-Modified/If-Modified-Since，浏览器会带条件请求去问服务器资源是否变化。
• 面试怎么答
  • “优先级上通常是先看强缓存，没命中再走协商缓存。静态资源治理里更推荐 Cache-Control + ETag 这套组合。”
• 易错点
  • 304 不是“资源成功返回了”，而是“资源没变，你继续用本地缓存”。

Cookie vs Session vs Token

• 核心结论
  • 这三个概念解决的问题不同，不能简单比较谁先进。
• 原理展开
  • Cookie 是浏览器端存储机制，常用来承载会话标识。
  • Session 是服务端会话状态，问题在于分布式共享和扩容。
  • Token 是一种无状态认证载体，常见实现如 JWT，但无状态不代表没有失效治理成本。
• 面试怎么答
  • “Cookie 是存储位置，Session 是服务端状态，Token 是认证凭证。分布式系统里常把 Token 和统一认证中心结合，而不是孤立讨论 JWT。”
• 易错点
  • 不要把 Cookie 理解成不安全，把 Token 理解成绝对安全。关键看传输方式、过期策略、签名与服务端校验能力。

1.5 HTTPS ★★★

TLS握手过程

• 核心结论
  • HTTPS 的目标不是“把所有数据都用非对称加密”，而是安全地协商出一个后续通信用的对称密钥。
• 原理展开
  • 客户端先发 Client Hello，声明支持的协议版本、密码套件、随机数。
  • 服务端回 Server Hello、证书和自己的协商参数。
  • 客户端验证证书链，确认服务端身份。
  • 双方通过密钥交换协商出会话密钥，之后主要使用对称加密传输业务数据。

对称加密 + 非对称加密的组合

• 核心结论
  • 非对称加密负责身份校验和安全协商，对称加密负责高效传输。
• 面试怎么答
  • “HTTPS 用混合加密不是折中方案，而是工程上的最优组合。非对称安全但慢，对称快但需要先安全分发密钥。”

证书链与CA

• 核心结论
  • 证书链的核心是逐级验签，直到命中本地信任的根证书。
• 易错点
  • 浏览器真正信任的是本地内置的根 CA 列表，不是“互联网上所有证书”。

TLS 1.2 vs TLS 1.3（1-RTT vs 0-RTT）

• 核心结论
  • TLS 1.3 的重点收益，是减少握手往返并默认收敛到更安全的密钥交换方案。
• 面试怎么答
  • “TLS 1.3 把握手轮次压缩到 1-RTT，并全面推进前向保密。0-RTT 是优化项，但要注意重放风险，不能把所有写操作都放进去。”

1.6 DNS ★

• 核心结论
  • DNS 本质上是一个分布式层级命名系统，核心考点是解析链路和缓存。
• 原理展开
  • 递归查询是“本地 DNS 服务器帮你一路问到底”。
  • 迭代查询是“上游告诉你下一跳去哪问”。
  • TTL 决定缓存寿命，影响切流和故障恢复速度。
• 面试怎么答
  • “DNS 解析一般会经过浏览器缓存、系统缓存、本地 DNS，再走递归或迭代查询。线上切流时，TTL 过长会直接影响变更生效速度。”

1.7 网络编程模型 ★★★

BIO(同步阻塞)

• 核心结论
  • BIO 是最直观的编程模型，但一连接一线程决定了它不适合高并发长连接。

NIO(同步非阻塞)

• 核心结论
  • NIO 的优势不只是非阻塞，而是配合 Selector 把连接管理和线程数解耦。
• 面试怎么答
  • “NIO 依然是同步模型，因为业务线程要自己处理读写结果；它只是把等待 IO 就绪的阶段从阻塞变成了多路复用。”

AIO(异步非阻塞)

• 核心结论
  • AIO 更强调“内核完成后再通知我”，但在 Java 和 Linux 传统生产体系里，落地普及度不如 NIO。

IO多路复用 ★★★

• 核心结论
  • select/poll/epoll 的核心差异，不是接口长什么样，而是就绪事件如何被发现和分发。

select / poll / epoll

• 原理展开
  • select 有 fd 数量限制，且每次都要把 fd 集合从用户态拷到内核态，再线性扫描。
  • poll 去掉了 1024 限制，但仍然线性扫描。
  • epoll 把关注的 fd 注册到内核，事件就绪后放入就绪链表，避免全量扫描。
• 面试怎么答
  • “epoll 高效，不是因为时间复杂度口诀，而是因为它把‘遍历所有 fd 找就绪事件’改成了‘由内核直接告诉你哪些 fd 就绪了’。”

epoll 的 LT(水平触发) vs ET(边缘触发)

• 核心结论
  • LT 更稳，ET 更激进。ET 模式必须把缓冲区一次读空，否则容易丢事件感知。
• 易错点
  • 不是 ET 一定优于 LT。很多框架默认 LT，是为了可维护性和正确性。

2. Linux基础 ★★

2.1 进程与线程 ★★

• 核心结论
  • 进程是资源分配单位，线程是 CPU 调度单位，协程是用户态轻量调度单元。
• 原理展开
  • 进程有独立地址空间，隔离性强但切换重。
  • 线程共享进程资源，适合并发执行。
  • 协程把调度部分下沉到用户态，切换更轻，但本质上仍依赖底层线程承载。
• 面试怎么答
  • “我通常把三者放在资源隔离、切换开销、调度位置这三个维度来对比。线上 Java 服务主要还是多线程模型，协程更多出现在 Go 或异步运行时里。”
• 易错点
  • 不要把协程理解成“比线程更高级的线程”。它解决的是不同层级的调度问题。

2.2 内存管理 ★

• 核心结论
  • 虚拟内存的核心价值是隔离、扩展和统一管理，不只是“看起来内存变大了”。
• 原理展开
  • 页表负责虚拟地址到物理地址映射。
  • TLB 是页表缓存，用于减少地址转换开销。
  • 缺页中断说明访问的页不在当前物理内存映射里，需要 OS 介入处理。
  • mmap 允许文件或设备映射到进程地址空间，是零拷贝和高性能文件访问的重要基础。

2.3 文件系统 ★

• 核心结论
  • inode 负责元数据，文件描述符是进程访问文件的句柄索引。
• 原理展开
  • 一个文件可以有 inode，但不同进程里对应不同 fd。
  • 网络 socket、管道、普通文件，在 Unix 世界里都可以被统一抽象成文件描述符。

零拷贝技术 ★★

• 核心结论
  • 零拷贝不是完全没有拷贝，而是尽量减少用户态和内核态之间的无效数据搬运与上下文切换。
• 原理展开
  • 传统 IO 往往要经历磁盘到内核、内核到用户、用户到 socket、socket 到网卡等多次拷贝。
  • mmap 通过内存映射减少一次用户态数据复制。
  • sendfile 让文件数据直接从内核态送到 socket，进一步减少拷贝和切换。
  • splice/tee 适合更底层的数据搬运优化。
• 面试怎么答
  • “零拷贝的收益主要体现在大文件传输和高吞吐场景，Kafka、Netty、Nginx 都会利用这一类能力。”
• 易错点
  • 不要把 sendfile 和 mmap 生搬硬套到所有场景。复杂协议编解码时，用户态仍然需要处理数据内容。

3. 线上排查命令 ★★★

3.1 系统资源

• 核心结论
  • 系统排查先看全局，再看局部，不要一上来就盯某个线程栈。
• 常用命令
  • top / htop：CPU 和内存总体概览。
  • vmstat：上下文切换、运行队列、内存和 IO 概况。
  • iostat：磁盘 IO 瓶颈判断。
  • free -h：内存使用和缓存情况。
  • df -h / du -sh：磁盘容量与目录占用。
  • uptime：系统负载。

3.2 网络排查

• 常用命令
  • netstat / ss：连接状态与端口监听。
  • tcpdump：抓包分析。
  • curl / wget：模拟 HTTP 请求。
  • ping / traceroute：网络连通性与路径探测。
  • lsof -i：端口占用与进程映射。

3.3 进程排查

• 常用命令
  • ps aux / ps -ef：进程列表和启动参数。
  • strace：系统调用追踪。
  • lsof：打开文件和 fd 占用。
  • kill / kill -9：终止进程，线上应谨慎使用。

3.4 Java进程排查 ★★★

CPU 100%排查步骤

• 核心结论
  • Java 进程高 CPU 的标准链路，是“进程 -> 线程 -> 线程栈 -> 业务代码/GC/锁”。
• 原理展开
  1. top 找到高 CPU 的 Java 进程 PID。
  2. top -Hp PID 找到占用高的线程 TID。
  3. printf '%x' TID 转为十六进制。
  4. jstack PID | grep nid=0x... -A 30 定位线程栈。
  5. 判断是死循环、频繁 GC、热点锁竞争，还是某段 CPU 密集计算。
• 面试怎么答
  • “先定进程，再定线程，再看线程栈，不要只看系统指标猜。很多时候 CPU 100% 的根因不是机器问题，而是代码里的死循环、忙等或异常重试。”

内存泄漏排查

• 核心结论
  • 内存排查要区分“正常占用高”和“持续增长不释放”。
• 原理展开
  1. jmap -heap PID 看堆区整体布局。
  2. jmap -histo PID 看对象分布。
  3. jmap -dump:format=b,file=heap.bin PID 导出堆。
  4. 用 MAT 分析大对象、可疑集合和 GC Root 引用链。
• 易错点
  • 只看堆占用百分比不够，要结合 Full GC 后是否回落来判断。

---

二、高频面试题

基础级（P7必答）

1. TCP 三次握手和四次挥手的过程？为什么握手三次挥手四次？

• 30秒答法
  • 三次握手是为了确认双方收发能力并同步初始序列号，两次无法避免历史连接误建连。四次挥手是因为 TCP 支持半关闭，一方发完数据后，另一方可能还没发完，所以确认和自己的 FIN 不能总合并。
• 关键词
  • SYN
  • ACK
  • 初始序列号
  • 半关闭
• 追问提醒
  • 面试官常继续问 TIME_WAIT、CLOSE_WAIT、SYN Flood。

2. TIME_WAIT 是什么？大量 TIME_WAIT 会怎样？怎么解决？

• 30秒答法
  • TIME_WAIT 是主动关闭方在最后一个 ACK 后保留的一段等待期，通常是 2MSL。作用是保证最后 ACK 可重发、旧报文不会污染新连接。大量 TIME_WAIT 会占用端口和连接资源，治理重点是长连接、连接池、减少短连接风暴，而不是简单粗暴改内核参数。
• 关键词
  • 2MSL
  • 主动关闭方
  • 端口耗尽
  • 长连接
• 追问提醒
  • 继续准备回答 SO_REUSEADDR、为什么不建议只靠调参数硬压。

3. TCP 粘包问题是什么？怎么解决？

• 30秒答法
  • 粘包不是协议 bug，而是 TCP 只提供字节流，没有消息边界。解决办法是在应用层自己定义边界，最常见是固定头加长度字段，其次是定长或分隔符协议。
• 关键词
  • 字节流
  • 消息边界
  • 长度前缀
• 追问提醒
  • 可以补充 Netty 里的拆包器思路，如 LengthFieldBasedFrameDecoder。

4. HTTP/1.1 和 HTTP/2 的区别？

• 30秒答法
  • HTTP/1.1 解决了持久连接问题，但同连接并发能力弱，仍有明显队头阻塞。HTTP/2 通过二进制分帧、多路复用和头部压缩提升性能，不过底层还是 TCP，所以 TCP 层丢包时仍会影响整条连接。
• 关键词
  • Keep-Alive
  • 多路复用
  • HPACK
  • TCP 队头阻塞
• 追问提醒
  • 常追问 HTTP/3、服务器推送为何没大规模用起来。

5. HTTPS 的加密过程？

• 30秒答法
  • HTTPS 不是全程靠非对称加密，而是先用证书和密钥交换安全协商出会话密钥，后续业务数据主要用对称加密传输。这样既保证安全，也兼顾性能。
• 关键词
  • Client Hello
  • 证书链
  • 密钥交换
  • 对称加密
• 追问提醒
  • 继续准备 TLS 1.2 和 TLS 1.3 区别、前向保密。

6. select/poll/epoll 的区别？epoll 为什么高效？

• 30秒答法
  • select/poll 的主要问题是每次都要遍历所有 fd 找事件，epoll 则把关注 fd 注册到内核，由内核把就绪事件放进就绪队列，避免全量扫描，所以更适合高并发连接场景。
• 关键词
  • 线性扫描
  • 就绪队列
  • 事件驱动
  • fd 注册
• 追问提醒
  • 常追问 LT/ET 差异，以及 Netty 默认为什么更偏向 LT。

7. BIO/NIO/AIO 的区别？

• 30秒答法
  • BIO 是同步阻塞，一连接一线程；NIO 是同步非阻塞，靠 Selector 多路复用管理大量连接；AIO 是异步非阻塞，内核完成 IO 后再通知应用。Java 服务端生产里最常见还是 NIO。
• 关键词
  • 同步阻塞
  • Selector
  • 多路复用
  • 回调通知
• 追问提醒
  • 可继续补充 Netty、io_uring 和 Linux AIO 支持现状。

8. 零拷贝是什么？有哪些实现方式？

• 30秒答法
  • 零拷贝的目标是减少用户态和内核态之间的数据复制与上下文切换，典型方式有 mmap 和 sendfile。它适合大文件传输和高吞吐网络场景，但不是所有业务都能直接套用。
• 关键词
  • mmap
  • sendfile
  • 上下文切换
  • 内核态
• 追问提醒
  • 可以准备 Kafka、Nginx、Netty 的应用案例。

进阶级（P8+深挖）

1. TCP 拥塞控制的四个阶段？BBR 算法相比传统算法有什么优势？

• 30秒答法
  • 经典拥塞控制包括慢启动、拥塞避免、快速重传、快速恢复。传统 Reno/Cubic 主要基于丢包调节发送速率，BBR 更关注带宽和最小 RTT，在高时延、弱网场景下通常吞吐更好。
• 关键词
  • cwnd
  • 慢启动
  • 快速恢复
  • 带宽时延模型
• 追问提醒
  • 常追问为什么 BBR 不完全依赖丢包信号。

2. epoll 的 ET 和 LT 模式区别？Netty 用的是哪种？为什么？

• 30秒答法
  • LT 只要缓冲区还有数据就会持续通知，更稳健；ET 只在状态变化时通知一次，要求应用一次读空，否则容易漏处理。JDK NIO 默认偏 LT，Netty 默认也更强调安全和易用，epoll 原生 transport 才会提供更细的模式选择。
• 关键词
  • LT
  • ET
  • 一次读空
  • 事件丢失风险
• 追问提醒
  • 面试官可能会追问 ET 的性能收益是不是一定明显。

3. 一次完整的 HTTP 请求，从输入 URL 到页面展示，经过了哪些步骤？

• 30秒答法
  • 核心链路是 DNS 解析、TCP 建连、TLS 握手、HTTP 请求与响应、浏览器解析和渲染。如果是服务端问题排查，还要加上网关、应用服务、缓存、数据库这些后端链路。
• 关键词
  • DNS
  • TCP/TLS
  • DOM/CSSOM
  • 渲染树
• 追问提醒
  • 常追问缓存命中点、静态资源加载并发和浏览器渲染流程。

4. Linux 中如何排查一个 Java 进程 CPU 100% 的问题？

• 30秒答法
  • 先用 top 定位进程，再用 top -Hp 找高 CPU 线程，把线程 ID 转十六进制后用 jstack 找线程栈，最后再判断是死循环、锁竞争、GC 还是热点计算。链路一定是“进程 -> 线程 -> 栈”。
• 关键词
  • top
  • top -Hp
  • jstack
  • 线程栈
• 追问提醒
  • 常追问 Arthas 怎么辅助，以及高负载和高 CPU 的区别。

5. HTTP/3 为什么基于 UDP？QUIC 解决了 TCP 的什么问题？

• 30秒答法
  • QUIC 基于 UDP，是为了在用户态更快迭代传输协议能力，同时绕开 TCP 层队头阻塞。它把多路复用、TLS 1.3、快速建连、连接迁移整合到一起，重点优化移动网络和弱网体验。
• 关键词
  • UDP
  • QUIC
  • 连接迁移
  • 0-RTT/1-RTT
• 追问提醒
  • 可以准备 0-RTT 的重放风险和 QUIC 为什么更便于协议演进。

---

三、实战场景题（P8+重点）

1. 连接异常：线上服务出现大量 CLOSE_WAIT，原因是什么？如何排查？

• 回答框架
  • 先定性：CLOSE_WAIT 说明对端已经关闭，本端没有及时 close。
  • 再定位：用 ss -antp / lsof -i 看连接归属进程，用线程栈和业务日志定位没有释放连接的代码路径。
  • 最后治理：补齐资源释放、超时控制、连接池配置和异常分支回收。
• 核心关注点
  • 区分协议状态问题和业务代码泄漏。
  • 是否存在异常分支没有关闭连接。
  • 是否有下游慢调用导致连接回收延迟。

2. 网络抖动：服务间调用偶发超时，如何定位是网络问题还是应用问题？

• 回答框架
  • 先按链路分层：客户端指标、网关指标、服务端线程池、下游依赖、网络丢包和 RTT。
  • 再做对比：同机房是否同时波动、重试是否放大问题、抓包与应用日志时间点是否一致。
  • 最后收敛：判断是 DNS、连接池、线程池、GC、网卡或链路问题。
• 核心关注点
  • 不要一上来就认定是网络。
  • 要结合超时分布、错误码、RT 波动和机器资源一起看。

3. 端口耗尽：高并发 HTTP 调用下游时出现端口耗尽，如何解决？

• 回答框架
  • 先判断是否短连接过多导致本地临时端口耗尽。
  • 再看 TIME_WAIT 数量、连接池复用率、下游超时配置和重试策略。
  • 最后从长连接、连接池、批量化、限流和调用模型上治理。
• 核心关注点
  • 端口耗尽通常是架构与调用方式问题，不是单纯系统参数问题。
  • 重试风暴会显著放大端口压力。

4. Netty性能：基于 Netty 开发的网关服务，如何优化到最大吞吐？

• 回答框架
  • 先分层看瓶颈：编解码、事件循环、线程模型、内存分配、下游调用、内核参数。
  • 再做针对性优化：减少阻塞逻辑、使用池化 ByteBuf、控制 pipeline 深度、批量 flush、评估零拷贝与 native transport。
  • 最后用压测数据验证吞吐、P99 和 CPU 使用变化。
• 核心关注点
  • 不要只盯 epoll 或线程数。
  • 真实瓶颈 often 在编解码、下游阻塞或对象分配。

---

四、学习资源推荐

书籍

• 《TCP/IP详解 卷1》：协议原理的核心参考书。
• 《图解HTTP》：适合快速补齐 HTTP/HTTPS 基础。
• 《UNIX网络编程》：网络编程与 socket 细节经典。
• 《Linux高性能服务器编程》：网络与 IO 模型结合得较好。

博客/文章

• 小林coding《图解网络》：适合复习 TCP、HTTP、HTTPS、IO 多路复用。
• 极客时间《趣谈网络协议》：适合建立整体链路视角。
• 极客时间《Linux性能优化实战》：适合线上排查视角补齐。

视频

• 韩立刚计算机网络：适合系统性回看。
• B 站 TCP 三次握手 / HTTPS 握手动画：适合快速建立过程感。