15.91.09 Linux（操作系统）网络、Netty（网络通信框架）与证据链追问

本册训练的不是命令清单，而是把“用户影响、资源等待、连接状态、协议阶段、事件循环、业务终态”串成可证伪的因果链。所有结论必须标注 E1（直接证据）、E2（既有材料映射）、E3（演练设计）或 E0（待核对）；没有同一时间窗的原始指标、日志、线程、套接字、变更和业务账本，不把候选根因说成生产事实。

Linux（操作系统）网络与 Netty（网络通信框架）失败追问证据链

完整机制回链 Linux（操作系统）网络与 Netty（网络通信框架）正文入口，统一事故回答顺序为：影响定界、冻结现场、竞争假设、跨层证据、可回滚止血、根因修复、存量查证、同条件回归、分档放量与复盘。

1. CPU（中央处理器）、内存、磁盘与文件描述符：先回答谁在等待

1.1 四类资源不能用一个“机器负载高”概括

资源排障先固定实例、容器、进程、线程和时间窗，再区分“可运行但抢不到 CPU（中央处理器）”“等待内存回收或被控制组限制”“等待块设备或文件系统”“进程无法再取得文件描述符”。平均负载包含可运行任务和部分不可中断等待，不能等同于 CPU（中央处理器）利用率；宿主机有空闲内存也不能排除容器触达 cgroup（控制组）上限；df（文件系统容量工具）有空间也不能排除 inode（索引节点）耗尽或删除文件仍被进程持有；系统级文件句柄充足也不能排除进程级 RLIMIT_NOFILE（打开文件数限制）触顶。

flowchart TD
    A[固定实例 容器 进程 线程与时间窗] --> B{主要等待信号}
    B -->|运行队列与节流| C[CPU（中央处理器）证据]
    B -->|回收 交换与限额| D[内存证据]
    B -->|不可中断等待与设备延迟| E[磁盘证据]
    B -->|打开失败与套接字增长| F[文件描述符证据]
    C --> G[进程与线程热点交叉验证]
    D --> G
    E --> G
    F --> G
    G --> H{能排除至少一个竞争假设}
    H -- 否 --> B
    H -- 是 --> I[执行可回滚止血并保存业务账本]
    I --> J[同负载同故障回归]

图解读： 第一信号只负责分流，第二信号必须落到同一对象和时间窗。正常路径会得到“哪一类任务、在何处、因何等待”；失败路径若只有一张总览截图，就回到分层采样，不通过重启销毁现场。

维度	容易误判的现象	最小证据组合	可回滚止血	根因修复与验证
CPU（中央处理器）	利用率高或平均负载高	运行队列、节流、进程占比、热点线程栈	限制低优先任务、回滚异常版本	消除热点或锁竞争，以同负载验证尾延迟
内存	宿主机尚有可用内存	容器事件、匿名页/页缓存、交换、堆外与线程数	降并发、摘除泄漏版本、保留转储	修复所有权或容量边界，验证水位不再单调增长
磁盘	`%util`（设备繁忙比例）高或空间充足	延迟、队列深度、吞吐、脏页、文件系统和 inode（索引节点）	暂停导出与日志洪峰、隔离设备	分离负载并校准并发，验证刷盘与交易延迟
文件描述符	新连接失败	进程限制、已用数量、描述符类型、增长调用栈	停止新接入、滚动摘流量、保留现有长连接	关闭泄漏路径并建立软硬水位，验证稳态回收

数据演绎 1：同一个 504 的四条资源路径。 E3（演练设计）中，8 核容器基线 P99（99 分位响应时间）为 180ms（毫秒）。路径甲运行队列从 3 增到 19且节流 32%，热点线程持续计算；路径乙匿名内存每分钟增加 600MiB（兆字节），5 分钟后触达 4GiB（吉字节）限额；路径丙导出从 8 个增到 64 个，设备 await（平均等待时间）由 4ms（毫秒）升到 86ms（毫秒）；路径丁进程限制为 65535，套接字和未关闭文件达到 65000 后新建连接报错。四条路径都会让接口超时，但止血分别是降计算流量、摘除泄漏版本、暂停导出和限制新连接。数字只用于容量演练，生产结论必须由原始监控与命令输出升级为 E1（直接证据）。

失败注入、止血、修复、验证与复盘： 在隔离环境分别注入处理器忙循环、受控堆外保留、磁盘延迟和响应体未关闭，保存注入版本、容器限制、压力比例、进程/线程采样、设备指标、描述符类型和业务请求。任一资金、库存或履约护栏越界立即停止注入。止血先暂停非关键导出与 Runner（执行器）任务、摘除异常版本并保留现场；修复资源所有权、有界并发和关闭路径后，以相同故障种子重放，再按 10%、30%、60%、100% 分档放量。验证既看资源水位，也核对库存流水、支付分录和履约任务唯一；复盘记录为什么第一告警没有指向真正等待点。机制为 E2（既有材料映射），注入值为 E3（演练设计），生产阈值为 E0（待核对）。参考 Linux（操作系统）proc（进程伪文件系统）手册。

2. TCP（传输控制协议）握手、重传、流量控制与拥塞：状态不等于根因

2.1 从建连队列到窗口收缩的传输证据

三次握手建立双方序列号与连接状态：服务端收到 SYN（同步序列号）后进入半连接阶段，最终 ACK（确认）到达后进入已完成连接队列，应用再通过 accept（接受连接）取得连接。半连接高通常指向回程丢失、攻击或握手处理能力，完成队列高而 accept（接受连接）速率下降更像应用消费停顿。已连接后的重传可能来自真实丢包、严重乱序、路径黑洞或接收端迟迟不消费；rwnd（接收窗口）约束接收方能力，cwnd（拥塞窗口）约束网络承载估计，二者必须和发送队列、接收队列、RTT（往返时间）及应用线程联合解释。

stateDiagram-v2
    [*] --> LISTEN: 服务端监听
    LISTEN --> SYN_RECV: 收到 SYN（同步序列号）
    SYN_RECV --> ESTABLISHED: 收到最终 ACK（确认）
    ESTABLISHED --> ZERO_WINDOW: 应用消费停顿
    ZERO_WINDOW --> ESTABLISHED: 接收窗口重新开放
    ESTABLISHED --> RETRANSMIT: 丢失 乱序或路径黑洞
    RETRANSMIT --> ESTABLISHED: 快速重传或超时重传恢复
    ESTABLISHED --> FIN_WAIT: 本端主动关闭
    ESTABLISHED --> CLOSE_WAIT: 收到对端关闭但应用未关闭
    FIN_WAIT --> TIME_WAIT: 完成双方关闭
    CLOSE_WAIT --> [*]: 应用关闭描述符
    TIME_WAIT --> [*]: 等待期结束

图解读： SYN_RECV（已收同步序列号）、CLOSE_WAIT（等待本端关闭）和 TIME_WAIT（等待关闭）都只是状态。正常路径要求队列被持续消费、窗口可推进、关闭责任明确；失败路径要把状态增长与内核计数、抓包、应用调用栈和对端证据对齐。

现象	竞争假设	第一证据	排他性第二证据	处置边界
建连超时	去回程丢失、半连接压力、完成队列满	连接状态与握手重传增量	受限抓包加 `accept`（接受连接）速率	先限新建与重试，再修链路或消费
已连接尾延迟	重传、接收端慢、远端业务慢	RTT（往返时间）、重传、发送/接收队列	窗口、应用线程与远端阶段耗时	不把所有重传都归为带宽不足
零窗口	接收缓冲满	`rwnd`（接收窗口）为零和接收队列	事件循环或业务线程阻塞	恢复消费，不盲目改拥塞算法
大包超时小包正常	MTU（最大传输单元）黑洞或中间设备策略	大段重复与必要反馈缺失	路径承载探测和受控报文大小对照	临时降低报文后仍要修路径契约
连接状态暴涨	主动关闭过多或应用漏关	状态分布与新建率	四元组、关闭调用栈和连接池复用率	区分 TIME_WAIT（等待关闭）与 CLOSE_WAIT（等待本端关闭）责任

数据演绎 2：1% 丢失为何显著抬高尾延迟。 E3（演练设计）中跨境链路 RTT（往返时间）为 50ms（毫秒），每个请求产生 20 个数据段，假设单段独立丢失率为 1%，至少一段丢失的概率约为 1-0.99^20≈18.2%。多数请求仍在 80ms（毫秒）左右完成，少数等待快速重传或 200ms（毫秒）以上的 RTO（重传超时时间），所以平均值变化有限而 P99（99 分位响应时间）显著上升。若同时看到 rwnd（接收窗口）降为零且接收端线程阻塞，则传输重传可能只是后果；若窗口正常、同一出口的内核重传与抓包缺口同步上升，链路假设才增强。

失败注入、止血、修复、验证与复盘： E3（演练设计）分别注入丢包、RTT（往返时间）阶梯、最终 ACK（确认）丢失、应用停止 accept（接受连接）、接收端暂停读取和路径 MTU（最大传输单元）降低。保存路由、套接字状态、队列、窗口、重传增量、受限抓包、应用线程与业务键。止血关闭多层立即重试、限制新建连接、切换已验证出口，并把支付和履约写保持为未知态等待原键查证；修复连接复用、队列消费、路径反馈和超时预算后，用相同随机种子回放。验证以尾延迟、重传、窗口、建连成功率和业务副作用唯一共同裁决；复盘说明是网络触发、应用放大还是二者共同作用。机制为 E2（既有材料映射），生产链路为 E0（待核对）。参考 RFC 5681 TCP（传输控制协议）拥塞控制。

3. HTTP（超文本传输协议）、HTTPS（安全超文本传输协议）与 MQTT（消息队列遥测传输协议）：通信成功不等于业务完成

3.1 把解析、建连、安全握手、协议响应和业务提交拆开

一次 HTTPS（安全超文本传输协议）请求至少包含 DNS（域名系统）解析、TCP（传输控制协议）建连、TLS（传输层安全协议）握手、HTTP（超文本传输协议）请求发送、首字节、响应体与业务状态收敛。状态码只描述本次协议响应，不能单独证明支付、库存或履约副作用；客户端超时也不能证明服务端未提交。MQTT（消息队列遥测传输协议）还要区分会话、订阅、保留消息、遗嘱和 QoS（服务质量）：QoS（服务质量）1 允许重复，QoS（服务质量）2 缩小协议会话内的重复窗口，却不能替代桥接、消费重试、数据库事务和告警通知层的业务幂等。

sequenceDiagram
    participant C as 调用方或设备
    participant D as DNS（域名系统）解析器
    participant P as 代理或接入层
    participant S as 业务服务
    participant L as 业务账本
    C->>D: 查询目标地址
    D-->>C: 地址与有效期
    C->>P: TCP（传输控制协议）建连
    C->>P: TLS（传输层安全协议）握手并校验身份
    C->>S: HTTP（超文本传输协议）请求或 MQTT（消息队列遥测传输协议）消息
    S->>L: 以稳定业务键受理或条件更新
    alt 响应正常返回
        L-->>S: 已提交终态
        S-->>C: 状态码或确认
    else 提交后响应丢失
        L-->>S: 已提交
        S--xC: 超时或连接断开
        C->>S: 使用原业务键查证
        S->>L: 读取权威终态
        L-->>C: 返回同一结果
    end

图解读： 失败支路故意把“响应丢失”和“业务提交”分开。安全握手成功只证明身份与加密通道，协议确认只证明相应交付阶段；最终仍要靠稳定业务键、权威状态和对账裁决副作用。

层次	成功能证明什么	不能证明什么	关键证据	安全恢复
DNS（域名系统）	得到一个解析结果	地址正确、实例健康	查询耗时、答案、有效期、解析器	切已验证解析器并保留旧新答案
TCP（传输控制协议）	双向字节通道建立	TLS（传输层安全协议）与业务可用	握手状态、RTT（往返时间）、队列	限新建、复用健康连接
TLS（传输层安全协议）	身份校验与密钥协商通过	应用授权和业务提交	证书链、主机名、版本、握手告警	切已验证域名，禁止关闭校验
HTTP（超文本传输协议）	获得一次协议响应	写操作未重复或最终成功	分段耗时、请求键、状态码、服务端日志	未知写先查证，按契约重试
MQTT（消息队列遥测传输协议）	达到约定交付阶段	业务全局只处理一次	会话、报文标识、设备序号、事件流水	可靠接管后确认，业务层去重

数据演绎 3：IoT（物联网）断网恢复如何把协议重复放大成报警风暴。 E3（演练设计）中 6 万设备同时恢复，30 秒内平均每秒重连 2000 次；每台补发 20 条 QoS（服务质量）1 消息，其中 15% 因确认延迟再次发送，原始 120 万条变为 138 万次接入。若规则引擎对每条都生成 2 个通知，额外 18 万次协议重复会放大为 36 万次无效通知。止血把重连摊到 10 分钟、按设备分组限速、非关键遥测降采样，并按“设备编号+事件序号+类型”唯一接管；报警层只在状态升级时通知。恢复不能只看在线率，还要验证事件流水唯一、关键报警不丢和队列年龄下降。

失败注入、止血、修复、验证与复盘： E3（演练设计）注入解析延迟、证书链缺失、主机名不匹配、提交后断开、重复回调、MQTT（消息队列遥测传输协议）确认丢失与会话重连。证据包保存各阶段耗时、证书摘要、请求/设备稳定键、代理与服务日志、协议确认和业务账本。支付场景止血只能切已验证渠道或域名、保持处理中并查单，绝不关闭证书校验；IoT（物联网）场景限制重连和通知但保留关键事件可靠接管。修复超时预算、证书发布、业务幂等和确认时点后，重放同一输入，按地区和设备组分档恢复。验证资金分录平衡、履约外部单唯一、设备事件不重不漏；复盘区分安全问题、传输问题和业务提交窗口。机制为 E2（既有材料映射），生产证书与阈值为 E0（待核对）。参考 RFC 9110 HTTP（超文本传输协议）语义、RFC 8446 TLS（传输层安全协议）1.3 与 MQTT（消息队列遥测传输协议）5.0 官方规范。

4. DNS（域名系统）与连接池：控制面缓存和数据面连接必须一起看

4.1 解析答案、连接寿命、池等待和远端容量是四个边界

DNS（域名系统）故障不只表现为解析失败，还包括尾延迟、负缓存、陈旧地址、搜索域放大和不同运行环境使用不同解析器。连接池则同时管理地址、身份、连接年龄、并发和等待：扩大池可能减少本地等待，却把过载推给代理、NAT（网络地址转换）、临时端口或下游；解析地址已经变化，旧长连接仍可能继续通向下线实例；中间层已回收空闲连接，客户端池却认为可用，会在借出后首次写入时复位。排查必须同时回答“解析到了谁、实际连到谁、连接多老、池内为何等待、下游允许多少并发”。

graph LR
    Q[业务请求] --> R[解析器与缓存]
    R --> A[地址集合与有效期]
    A --> P[按路由与身份选择连接池]
    P --> I{可复用健康连接}
    I -- 是 --> U[借出并记录连接年龄]
    I -- 否 --> N[受预算约束地新建连接]
    N --> U
    U --> X[代理或远端服务]
    X --> Y[响应后归还或淘汰]
    R -. 负缓存或尾延迟 .-> F[建连前失败]
    A -. 陈旧地址 .-> G[连到旧实例]
    P -. 池满 .-> H[本地排队超时]
    Y -. 中间层先回收 .-> S[陈旧连接首次写复位]

图解读： 正常路径要求解析缓存、连接地址、身份和寿命策略一致；四条失败支路分别位于建连前、地址选择、本地排队和复用之后，不能都通过“调大池”处理。

故障	识别证据	常见误修	正确止血	长期验证
解析尾延迟	单次/分位查询耗时与应用解析阶段同升	只增加请求超时	切已验证解析器、降低新建率	解析分位、缓存命中和业务尾延迟同窗恢复
负缓存	失败答案与有效期、恢复后仍失败	反复重启应用	受控清理并确认权威答案	注入短时不存在后按有效期恢复
陈旧地址	解析答案已变但连接远端仍旧	强制每次重新解析	摘除旧池并分批建新连接	地址轮换、滚动发布与连接排空
池等待	获取耗时升高、在用满、远端时延高	无界扩池	限流、隔离业务、缩短无效等待	按 Little’s Law（利特尔法则）和下游配额校准
陈旧连接	失败集中于特定空闲年龄，首次写复位	对所有写无限重试	淘汰超龄连接、原键限次重试	跨过中间层回收阈值的空闲回归

数据演绎 4：连接池为什么不能只按并发请求数配置。 E3（演练设计）中跨境履约峰值 600QPS（每秒查询率），渠道 P99（99 分位响应时间）为 0.8s（秒），单连接同一时刻处理一个请求，按 Little’s Law（利特尔法则）在途量约为 600×0.8=480。池为 200 时，至少 280 个请求存在等待机会；盲目扩到 1000 又超过渠道 500 并发配额，并增加临时端口和重试压力。合理上界受渠道配额约束，超出部分进入有年龄指标的队列或被限流。若中间代理 60s（秒）回收空闲连接而客户端保留 300s（秒），还应让客户端空闲寿命低于 60s（秒）并对旧连接做受控淘汰。

失败注入、止血、修复、验证与复盘： E3（演练设计）注入递归解析器 1.2s（秒）尾延迟、短时不存在的负缓存、地址轮换、池容量耗尽、代理提前回收与下游配额拒绝。保存解析器、答案、有效期、连接远端、创建/最后使用时间、池获取耗时、在用/空闲、临时端口和业务键。止血减少新建与多层重试、切已验证解析器、淘汰旧地址池、按渠道限流；支付写复位后仍按原键查单。修复缓存策略、连接寿命、获取超时、舱壁和容量模型后，用相同轮换和空闲窗口重放，再分档恢复。验证解析、池等待、复位、新建率、渠道成功率与业务未知态同步收敛；复盘检查配置为何跨层不一致。机制为 E2（既有材料映射），实际解析拓扑和容量为 E0（待核对）。参考 RFC 1035 DNS（域名系统）与 RFC 9210 DNS（域名系统）基于 TCP（传输控制协议）的运行要求。

5. epoll（事件轮询机制）、Reactor（反应器模型）与 Netty（网络通信框架）线程模型：就绪之后仍要推进

5.1 EventLoop（事件循环）的预算、归属与阻塞证据

epoll（事件轮询机制）负责维护关注集合并返回就绪事件，不替应用读取、解码或执行业务；边缘触发下若未循环读到 EAGAIN（暂时不可用错误），缓冲中剩余数据可能没有新的边沿提醒。Reactor（反应器模型）把连接接入、事件分发和处理职责组织起来，Netty（网络通信框架）通常让一个 Channel（通道）在生命周期内归属于一个 EventLoop（事件循环），借单线程顺序减少并发控制。这个便利的代价是：一个同步数据库调用、阻塞域名解析、大对象编码或过长任务，就会拖慢同一 EventLoop（事件循环）上的许多连接。业务卸载也不能无界，必须使用有界池、截止时间、拒绝语义，并将结果安全回投到 Channel（通道）所属 EventLoop（事件循环）。

mindmap
  root((事件推进))
    epoll（事件轮询机制）
      注册关注
      返回就绪
      非阻塞读写
      边缘触发读到不可继续
    Reactor（反应器模型）
      接入连接
      分发事件
      控制处理预算
    Netty（网络通信框架）
      Boss（接入线程）
      Worker（工作线程）
      EventLoop（事件循环）归属
      Pipeline（处理流水线）
    失败信号
      循环延迟
      任务年龄
      每轮就绪数
      阻塞线程栈

图解读： 内核就绪、线程分发和业务执行是三层责任。正常路径在有限预算内读写、解码、传播并返回等待；失败路径要区分事件未消费、任务队列饥饿和业务处理阻塞。

位置	正常职责	典型阻塞	直接证据	修复与回归
接入线程	接受连接并注册	在接入路径做鉴权远调	接受速率、完成队列、线程栈	只做轻量接入，重放连接风暴
EventLoop（事件循环）	处理就绪、任务和定时器	同步数据库、文件、解析或计算	循环延迟、任务年龄、连续线程栈	卸载有界业务池，验证同组连接公平性
Pipeline（处理流水线）	解码、校验、传播与编码	单处理器耗时或异常未传播	处理器分段耗时与事件顺序	缩短职责并做嵌入式回归
业务池	执行允许阻塞的业务	无界队列、拒绝后立即重试	到达/完成率、队列年龄、拒绝数	容量预算与业务降级，验证净积压下降
回投阶段	在连接存活时写回结果	结果迟到、跨线程乱序	Channel（通道）状态、任务标识、写结果	检查存活和版本，验证关闭竞态

数据演绎 5：一次同步调用怎样拖慢 1.5 万连接。 E3（演练设计）中 12 万个 IoT（物联网）连接均分到 8 个 EventLoop（事件循环），每个约 1.5 万连接。某处理器在单个 EventLoop（事件循环）每秒触发 20 次 80ms（毫秒）同步查询，需求为 20×80ms=1.6s 处理时间/秒，单线程不可能追平；循环 P99（99 分位响应时间）从 3ms（毫秒）升到 740ms（毫秒），心跳确认延迟后设备重连，接入压力继续上升。将查询卸载到有界业务池后，若池完成率低于到达率，队列仍会积压，因此还要限流、超时和聚合，不能把阻塞从一个队列搬到另一个队列。

失败注入、止血、修复、验证与复盘： E3（演练设计）注入边缘触发只读一次、EventLoop（事件循环）同步睡眠、阻塞解析、业务池满、拒绝后立即重试和连接关闭后迟到回写。保存每循环延迟、任务年龄、处理器分段耗时、线程栈、连接分布、业务池到达/完成与拒绝、心跳和重连。止血摘除异常版本、关闭非关键推送、按设备组限速并保护关键连接；修复为非阻塞推进、有界卸载、截止时间和可解释拒绝。相同连接分布与故障种子重放后按分组放量，验证健康连接不饥饿、任务有界、关键心跳不丢、重复报警不增加。复盘记录为何代码评审和循环延迟告警未发现阻塞。机制为 E2（既有材料映射），线程数和阈值为 E0（待核对）。参考 Linux（操作系统）epoll（事件轮询机制）手册与 Netty（网络通信框架）线程模型说明。

6. ByteBuf（字节缓冲区）、背压与支付/履约/IoT（物联网）证据链：恢复性能还要恢复业务事实

6.1 内存所有权、可写水位和业务终态必须同时闭环

Netty（网络通信框架）的 ByteBuf（字节缓冲区）使用引用计数管理部分内存，初始所有者、转交、派生视图、retain（保留引用）与 release（释放引用）必须成对。slice（切片）和 duplicate（重复视图）通常共享底层内存及引用计数，异步跨线程持有前若未正确保留会过早释放，消费后遗漏释放则造成直接内存持续增长。写侧的高低水位通过 isWritable（是否可写）把慢消费者暴露出来，但它只发出信号；业务必须停止继续生产、合并或降级非关键消息，并在低水位后受控恢复。关闭连接、清空队列和进程重启只能恢复资源，事故窗口中的支付未知态、履约重复单和 IoT（物联网）重复报警仍需账本查证。

timeline
    title 从 Netty（网络通信框架）阻塞到业务恢复的证据时间线
    T0 基线 : 循环延迟稳定 : 写缓冲低于低水位 : 业务差异为零
    T1 触发 : 阻塞处理器发布 : EventLoop（事件循环）延迟先升高
    T2 放大 : 写缓冲越过高水位 : 直接内存和连接重试增长
    T3 业务影响 : 支付响应未知 : 履约任务重试 : IoT（物联网）报警重复
    T4 止血 : 摘除版本 : 停非关键写 : 原业务键查证
    T5 修复验证 : 所有权回归 : 背压重放 : 三类账本对账
    T6 分档恢复 : 10% : 30% : 60% : 100%

图解读： 时间先后用于构造因果假设：循环延迟先于写积压，写积压先于内存和重连，支持“阻塞是触发、背压失效是放大器”。回滚后指标逆序恢复且同条件复现，证据增强；仍不能跳过业务账本。

风险	资源信号	业务风险	止血	修复与验收
ByteBuf（字节缓冲区）泄漏	直接内存单调增长、泄漏采样	进程终止、连接重建、重复消息	摘除版本、降低接入、保留泄漏记录	明确最后访问者释放，压力下水位稳定
过早释放	`IllegalReferenceCountException`（非法引用计数异常）	帧损坏、请求失败	停止异常异步路径	跨线程前保留、消费后释放，覆盖关闭竞态
写缓冲越高水位	不可写连接和待发送字节增长	慢设备拖垮健康设备	停非关键生产、聚合、断开超预算慢端	监听可写变化，低水位分批恢复
背压传错方向	入站仍读、业务池仍产出	队列和重试正反馈	限入口、冻结重复重试	端到端定义容量、年龄和拒绝语义
技术恢复但账本未知	资源指标恢复	重复扣款、重复履约、重复报警	保持未知态并按原键查证	支付分录、外部单、设备序号对账归零

数据演绎 6：慢消费者怎样把写积压变成直接内存压力。 E3（演练设计）中 IoT（物联网）接入层每秒向设备产生 12000 条 1KiB（千字节）消息，网络只能发出 6000 条，净积压约 6000×1KiB=5.86MiB/s（兆字节每秒），一分钟约 352MiB（兆字节）。若 8 个 EventLoop（事件循环）平均分配但 20% 连接极慢，积压会集中在少数线程和连接；继续无界 write（写入）十分钟可超过 3GiB（吉字节），即使 Java（编程语言）堆稳定，直接内存也会逼近上限。高水位触发后暂停非关键遥测、聚合状态并对超预算慢端断开，发送能力恢复到每秒 10000 条、入口限制为每秒 7000 条时，净消化每秒 3000 条，理论清理一分钟积压约需 120 秒，实际还要按循环延迟和业务优先级分档。

失败注入、止血、修复、验证与复盘： E3（演练设计）注入处理器遗漏释放、派生缓冲跨线程未保留、20% 慢客户端、写侧忽略不可写信号、支付响应提交后断开和履约回调重复。保存泄漏检测记录、分配栈、引用计数所有权、每连接待发送字节、直接内存、循环延迟、业务池队列、支付请求号、外部履约单和设备事件序号。护栏越界立即停止注入。止血摘除版本、暂停非关键推送、限制入口并对三类业务保持原键查证；修复释放责任、高低水位处理、慢端策略和幂等状态机。以同样慢端比例和断开时点重放，先影子验证，再按 10%、30%、60%、100% 放量；每档要求直接内存稳定、净积压下降、循环 P99（99 分位响应时间）达标、支付分录平衡、履约任务唯一、重复报警归零。复盘把触发、放大器、误操作、监控缺口和所有者写入行动项。机制为 E2（既有材料映射），实际影响为 E0（待核对）。参考 Netty（网络通信框架）引用计数官方说明与 Netty（网络通信框架）写缓冲水位接口。

7. Linux（操作系统）网络、Netty（网络通信框架）与证据链综合追问题库

纯口述统计口径： 每题从 口述答案 字段冒号后的首字符开始，统计到首个 追问 1 之前；移除 Markdown（标记语言）标记、链接和全部空白，硬性范围为 570—900 个有效字符。每题固定 4 组追问直答，并同时给出真实相对正文链接和官方依据链接。

问题：线上接口变慢且 CPU（中央处理器）升高，你如何从主机定位到热点代码？
- 考点：时间窗、容器节流、进程/线程映射、竞争假设和业务护栏。
- 回答思路：先确认影响和对象，再从全局、容器、进程、线程到调用栈逐层收敛。
- 事实等级：排障机制为 E2（既有材料映射），阈值与故障注入为 E3（演练设计），真实事故影响为 E0（待核对）。
- 详细答案：高利用率只生成计算热点候选；必须结合运行队列、控制组节流、热点线程与连续调用栈，并用回滚或限流后的同向恢复增强因果证据。
- 进阶追问：热点线程栈每次都不同怎么办？
- 进阶回答：增加连续采样并按请求、锁、分配或系统调用聚类；若样本分散，检查调度、软中断、短任务洪峰和多个实例间的负载偏斜。
- 口述答案：我先固定用户影响、开始时间、版本、实例、容器和请求类型，不从一张总览图直接下结论。第一层看核数、整体利用率、运行队列、负载、上下文切换、软中断和控制组节流，区分持续计算、线程争抢、内核网络工作与配额不足；第二层比较同机进程和同服务实例，确认热点是否只出现在异常版本。第三层把热点进程内的线程标识映射到 Java（编程语言）线程，连续抓取多次线程栈，观察同一栈帧是否稳定出现，同时对照垃圾回收、锁等待、请求分段耗时和流量结构。E3（演练设计）中 8 核容器运行队列从 3 升到 19、节流 32%，一个线程持续占满单核；这只能说明候选，若线程栈反复落在运单规则循环，回滚该版本后利用率、队列和接口 P99（99 分位响应时间）同步恢复，因果才增强。止血先限制低优先导出和 Runner（执行器）任务、摘除异常实例，避免直接重启销毁现场；库存和支付入口保留最小配额。长期修复算法热点、锁粒度或错误重试，并在相同数据分布和峰值流量下回归。验证既看处理器、尾延迟和吞吐，也核对库存流水、支付分录和履约任务没有因超时重试产生重复。恢复观察窗还要比较同版本正常实例和上一版本，确认流量迁移、缓存预热或软中断没有成为新的解释；若证据冲突，就保留多假设而不是强行归因。复盘补充每线程利用率、节流和最长任务告警；没有原始采样时只报告 E0（待核对）的候选根因。观察期必须保留同版本对照实例和业务分母，防止流量自然回落被误认成修复收益。
- 追问 1：负载高就代表处理器不够吗？ 直接回答：不代表，负载还可能包含不可中断等待，应结合利用率、运行队列和等待对象。
- 追问 2：单线程 100% 是否需要立即加核？ 直接回答：先确认它是否位于关键路径；单线程热点通常不会因简单加核而消失。
- 追问 3：重启恢复能证明根因吗？ 直接回答：不能，重启同时清空线程、连接和缓存，只能算止血结果。
- 追问 4：如何验证优化没有转移瓶颈？ 直接回答：同负载比较处理器、锁、垃圾回收、数据库、网络和业务吞吐，确认其他资源未恶化。
- 详细章节：Linux（操作系统）资源、进程与排障
- Linux（操作系统）proc（进程伪文件系统）官方手册
问题：容器内存持续增长并被终止，怎样区分堆、直接内存、线程栈和页缓存？
- 考点：容器记账、内存区域、增长斜率、现场保护与泄漏回归。
- 回答思路：先确认谁触发终止，再用区域分解和分配/所有权证据收敛。
- 事实等级：内存机制为 E2（既有材料映射），增长速率为 E3（演练设计），生产转储与影响为 E0（待核对）。
- 详细答案：容器总内存是多区域之和；堆稳定不能排除 ByteBuf（字节缓冲区）、线程栈、映射文件或页缓存增长，必须把运行时指标、进程映射和容器事件对齐。
- 进阶追问：为什么扩大容器限制不是根治？
- 进阶回答：它只延长触顶时间；若水位单调增长且无稳态，最终仍会失败，还可能扩大单实例故障影响。
- 口述答案：我先保存容器限制、当前与峰值记账、终止事件、进程退出原因和事故时间线，确认是容器 OOM（内存溢出）终止、JVM（Java 虚拟机）堆内异常，还是宿主机全局压力。然后把进程内存拆成 Java（编程语言）堆、元数据、直接内存、线程栈、内存映射、原生库和文件页缓存：堆看使用量、垃圾回收后基线与对象保留；直接内存看 Netty（网络通信框架）分配器、ByteBuf（字节缓冲区）泄漏记录和引用计数所有权；线程栈看线程总数及创建来源；页缓存和映射看文件负载与回收行为。E3（演练设计）中容器上限 4GiB（吉字节），堆回收后稳定在 1.5GiB（吉字节），但直接内存每分钟增加 300MiB（兆字节），10 分钟后触顶；这时缩堆只能多争取时间。止血是摘除异常版本、限制新连接和非关键推送，保留泄漏采样、分配栈与必要转储，不能先全量重启。修复要明确最后访问者负责 release（释放引用），覆盖异常和异步跨线程路径；若是线程泄漏则修线程池生命周期，若是页缓存压力则隔离批量文件任务。回归用相同消息大小、连接数和异常分支持续压测，要求垃圾回收后堆基线、直接内存、线程数和容器水位进入稳态。恢复按实例分档，同时核对 IoT（物联网）事件、支付回调和履约任务未因进程终止重复生效；还要覆盖连接关闭、解码异常和业务池拒绝这些最容易遗漏释放的路径。复盘记录为何只监控堆而遗漏容器总量。
- 追问 1：堆转储能看到直接内存内容吗？ 直接回答：通常不能完整反映底层原生内存，只能看到部分引用对象，还需原生内存与分配器证据。
- 追问 2：页缓存高一定是泄漏吗？ 直接回答：不一定，页缓存通常可回收；要看回收能力、文件负载和容器记账压力。
- 追问 3：开启最高级泄漏检测能直接上全量吗？ 直接回答：不建议，开销较高，应先测试或小流量实例，保留对照后再扩大。
- 追问 4：修复后观察多久？ 直接回答：至少覆盖原触顶周期、峰值连接和异常分支，并证明水位有稳定上界。
- 详细章节：Netty（网络通信框架）线程、缓冲与本地内存
- Netty（网络通信框架）引用计数官方说明
问题：磁盘延迟升高且文件描述符接近上限，如何判断谁是根因、谁是伴随现象？
- 考点：文件生命周期、设备排队、删除占用、描述符类型和因果时间线。
- 回答思路：分别建立磁盘与描述符假设，再用先后顺序和受控止血验证。
- 事实等级：文件与设备机制为 E2（既有材料映射），并发和阈值为 E3（演练设计），生产文件清单为 E0（待核对）。
- 详细答案：描述符增长可能来自文件或套接字泄漏，磁盘慢也可能让正常描述符存活更久；必须按类型、调用栈、设备队列和任务并发确定触发与放大关系。
- 进阶追问：删除大日志后 df（文件系统容量工具）为什么不下降？
- 进阶回答：文件可能已取消目录关联但仍被进程打开，数据块要等最后一个打开引用关闭后才释放。
- 口述答案：我会先冻结时间窗，保存文件系统容量、inode（索引节点）、挂载点、设备延迟、队列深度、吞吐、脏页、进程描述符限制与已用数量，再按普通文件、套接字、管道和匿名节点分类。磁盘延迟先升后描述符上涨，可能是请求完成变慢导致连接和文件存活时间变长；描述符先单调增长、随后日志轮转和新连接失败，则更像关闭路径泄漏触发，设备压力只是放大器。E3（演练设计）中 64 个导出任务把设备 await（平均等待时间）从 4ms（毫秒）推到 86ms（毫秒），支付同步刷盘变慢；同时响应体异常分支未关闭，使套接字每分钟增加 3000，20 分钟接近进程 65535 上限。止血分别处理：暂停低优先导出、保留分片检查点，为支付落盘预留预算；限制新接入并滚动摘除泄漏实例，不能粗暴终止全部长连接。若删除日志释放空间，先确认合规要求和打开者，防止文件名消失但空间未回收。根因修复包括导出有界并发、存储隔离、正确轮转、所有响应与文件在异常路径关闭，并为描述符设置软硬水位。验证在相同导出量和故障分支下持续运行，要求设备延迟、队列、描述符数量和空间进入稳态，导出摘要一致，支付分录无缺失。恢复时先放交易和关键履约，再逐档恢复导出；每档保存设备和描述符斜率，任一重新单调恶化就回退。复盘用时间线明确“导出是触发、泄漏是独立缺陷”或相反，避免硬选单一根因。任何清理动作都要先保留文件清单、打开者和审计期限，避免恢复容量却破坏事后查证。
- 追问 1：%util（设备繁忙比例）100% 就说明磁盘饱和吗？ 直接回答：不一定，要结合延迟、队列、吞吐、设备并行能力和业务目标解释。
- 追问 2：文件描述符上限能否直接调大？ 直接回答：可作为短期缓冲，但必须确认系统上限、内存成本和泄漏，否则只会推迟失败。
- 追问 3：如何证明响应体泄漏？ 直接回答：看套接字描述符单调增长、调用栈或分配来源、异常分支覆盖，以及修复后的稳态对照。
- 追问 4：导出暂停后何时恢复？ 直接回答：设备队列与交易刷盘恢复并完成存量校验后，按并发档位逐步恢复。
- 详细章节：Linux（操作系统）文件系统与 I/O（输入输出）
- Linux（操作系统）open（打开文件）官方手册
问题：大量 TCP（传输控制协议）建连超时，如何区分回程丢包、半连接压力和应用未及时接受连接？
- 考点：三次握手、两类队列、抓包边界、接入线程和安全止血。
- 回答思路：用 SYN_RECV（已收同步序列号）、完成队列、重传与接受速率构造排他证据。
- 事实等级：握手机制为 E2（既有材料映射），队列数字为 E3（演练设计），生产路径为 E0（待核对）。
- 详细答案：半连接接近上限且握手响应重传上升更支持回程或恶意流量；半连接低、完成队列满且接受速率下降更支持应用接入停顿。
- 进阶追问：调大监听队列为什么可能无效？
- 进阶回答：它只能增加缓冲，不能修复回程丢失或阻塞的接入线程，反而可能延长等待和扩大内存占用。
- 口述答案：我先确认失败发生在解析、路由、发送 SYN（同步序列号）、收到 SYN-ACK（同步序列号确认）还是最终 ACK（确认）之后，并固定源/目标、网络命名空间和时间窗。服务端查看监听、SYN_RECV（已收同步序列号）、完成连接队列、握手重传、接受速率和接入线程栈；客户端看建连耗时与重传；经审批做小范围抓包确认哪一段缺失。E3（演练设计）中半连接有效容量 1024，故障时 SYN_RECV（已收同步序列号）为 980、每秒握手重传增加 620而完成队列仅 18，支持最终 ACK（确认）回程异常或异常 SYN（同步序列号）流量；另一分支半连接为 9、完成队列 510/512、accept（接受连接）速率从每秒 1800 降到 40，线程栈停在同步鉴权，说明应用未及时接受。止血对前者限制新建与立即重试、启用既定防护或切换已验证路径；对后者摘除阻塞版本、让接入线程只做轻量注册。支付和履约写在建连超时后仍不能换业务键重试。长期修复回程路由、防护容量或接入线程职责，并按实际连接风暴校准队列。回归分别注入最终 ACK（确认）丢失和接入线程阻塞，要求两组证据能被清晰区分，健康连接不受饥饿，业务副作用保持唯一。恢复还要覆盖滚动发布和中间层连接排空，证明旧实例退出时不会再次填满完成队列。复盘说明为什么只看端口监听或总连接数会误判。恢复观察还要覆盖一次滚动下线，确认旧实例连接排空后不会让队列再次升高。
- 追问 1：端口监听能证明服务健康吗？ 直接回答：不能，只证明存在监听套接字，不代表队列可消费、协议和业务依赖可用。
- 追问 2：客户端超时服务端无日志说明什么？ 直接回答：请求可能未到应用层，也可能日志采样缺失；先查解析、握手、代理和接入队列。
- 追问 3：SYN Cookie（同步序列号信息编码）能解决所有半连接问题吗？ 直接回答：不能，它是特定压力下的防护手段，不能修复真实回程故障和后续应用消费瓶颈。
- 追问 4：抓包为何要限范围？ 直接回答：为控制性能、隐私和密钥风险，只抓必要接口、主机、端口、包数和时间窗并脱敏。
- 详细章节：TCP/IP（传输控制协议/互联网协议）连接与拥塞
- RFC 9293 TCP（传输控制协议）规范
问题：跨境链路重传和 P99（99 分位响应时间）同时升高，如何区分拥塞、零窗口和 MTU（最大传输单元）黑洞？
- 考点：拥塞窗口、接收窗口、重传、包大小、路径反馈和尾延迟。
- 回答思路：从发送方窗口、接收方消费和大小敏感性三条假设并行取证。
- 事实等级：传输机制为 E2（既有材料映射），丢失比例与窗口为 E3（演练设计），生产出口故障为 E0（待核对）。
- 详细答案：拥塞通常伴随拥塞窗口收缩与路径重传，零窗口由接收端消费停顿通告，MTU（最大传输单元）黑洞常表现为握手和小包正常、大包重复且缺少必要反馈。
- 进阶追问：切换拥塞算法能否作为首个止血动作？
- 进阶回答：不宜，若根因是接收端停读或路径黑洞，切算法无效；应先按窗口和包大小证据定位。
- 口述答案：我先按同一四元组和出口保存 RTT（往返时间）、重传增量、cwnd（拥塞窗口）、rwnd（接收窗口）、发送/接收队列、吞吐、网卡错误与包大小分布，再结合接收端线程和路径探测。拥塞假设通常看到 cwnd（拥塞窗口）收缩、重传和 RTT（往返时间）同窗上升，多个目标共享该路径；零窗口则是接收方通告 rwnd=0，接收队列堆积，应用线程可能卡在数据库或事件循环，恢复消费后窗口重新开放；MTU（最大传输单元）黑洞常见握手、小请求成功，大响应反复重传且缺少需要的 ICMP（互联网控制消息协议）反馈，临时降低报文大小后恢复。E3（演练设计）中 50ms（毫秒）路径每请求 20 段、单段独立丢失 1%，至少一段丢失概率约 18.2%，足以抬高尾延迟；但公式不是现场证据。止血优先关闭多层重试、限制并发，按审批切换已验证出口；零窗口要恢复接收端消费，路径黑洞可临时降低 MSS（最大报文段长度）但必须设置吞吐回滚条件。长期修复容量、应用阻塞或隧道与反馈策略。回归用相同 RTT（往返时间）、丢失和报文大小重放，要求窗口、重传和 P99（99 分位响应时间）恢复，同时核对轨迹游标、支付请求号和履约外部单没有因超时重复。恢复观察期比较不同报文大小、目标和出口，防止把单目标限流误当成全链路拥塞；任何抓包结论都保留采样边界。复盘结论限定到具体出口、目标和时间窗。若不同出口表现不一致，我只把结论限定到已采样路径，不外推为对端整体故障。
- 追问 1：平均延迟正常能排除网络问题吗？ 直接回答：不能，少量重传或超时会主要影响尾部，平均值可能变化很小。
- 追问 2：零窗口是谁的问题？ 直接回答：它说明接收侧暂时无缓冲，根因可能是应用停读、线程阻塞或下游慢，需要继续向上定位。
- 追问 3：小包探测成功说明路径正常吗？ 直接回答：不能排除 MTU（最大传输单元）黑洞，大包可能因隧道开销或反馈被过滤而失败。
- 追问 4：带宽高就不会拥塞吗？ 直接回答：不会，包率、突发、共享队列、RTT（往返时间）和窗口都可能限制实际传输。
- 详细章节：TCP/IP（传输控制协议/互联网协议）重传与拥塞
- RFC 5681 TCP（传输控制协议）拥塞控制
问题：支付 HTTPS（安全超文本传输协议）请求超时，怎样区分 DNS（域名系统）、建连、TLS（传输层安全协议）、代理和业务处理？
- 考点：分段耗时、安全身份、未知结果、稳定业务键和资金对账。
- 回答思路：先拆通信阶段，再用渠道和账务权威事实裁决业务结果。
- 事实等级：协议机制为 E2（既有材料映射），超时值与注入为 E3（演练设计），真实渠道状态为 E0（待核对）。
- 详细答案：总耗时必须拆成解析、连接、安全握手、池等待、代理等待、服务处理和回包；任何通信错误都不能单独裁决扣款结果。
- 进阶追问：TLS（传输层安全协议）握手成功为何仍可能收到错误证书对应的业务？
- 进阶回答：若主机名、SNI（服务器名称指示）、信任策略或代理路由配置错误，连接可能到达非预期虚拟主机；必须校验身份并核对响应来源。
- 口述答案：我先固定支付请求号、商户订单号、目标域名、解析器、出口、代理、应用版本和用户总预算，把一次请求拆成 DNS（域名系统）解析、连接池获取、TCP（传输控制协议）建连、TLS（传输层安全协议）握手、代理上游等待、渠道处理、首字节和响应体。解析慢要有查询分位和应用解析阶段同升；建连慢看握手状态、队列和重传；安全握手失败看证书链、主机名、SNI（服务器名称指示）、版本与 ALPN（应用层协议协商）；代理慢看上游池等待和后端实际处理；渠道业务慢则由其请求日志或查单时间证明。E3（演练设计）中总耗时 2 秒，解析 8ms（毫秒）、建连 12ms（毫秒）、握手 35ms（毫秒），代理上游池等待 1.72 秒、渠道处理 90ms（毫秒），说明扩应用实例无效。止血可切换身份、证书和业务能力都已验证的备用渠道，限制新扣款并保留查单与回调；绝不关闭证书校验，也不因本地超时生成新请求号。未知结果保持处理中，用原键主动查单，最终以渠道流水、支付单和不可变分录裁决。修复要统一各层超时与连接寿命、隔离渠道池、自动巡检证书并传播截止时间。回归覆盖新连接、复用连接、证书轮换、提交后断开和代理提前超时，按 10%、30%、60%、100% 分档恢复；每档同时看分段耗时、未知态年龄、重复扣款和对账差异。复盘把通信恢复与资金恢复分开，没有渠道与账务证据时不把超时说成扣款失败。任何渠道切换还要记录在途请求清单和回切责任人，避免两条路径同时处理同一笔资金意图。
- 追问 1：能否只看一次详细请求日志定位？ 直接回答：不能，需分位、同窗多实例和代理/渠道证据，单样本可能是偶发路径。
- 追问 2：握手失败能否自动重试？ 直接回答：可在身份校验未降级且预算允许时限次重连，但业务写仍复用原请求号。
- 追问 3：代理返回 504（网关超时）代表渠道没收到吗？ 直接回答：不代表，渠道可能已执行，只是代理等待预算先耗尽。
- 追问 4：何时解除备用渠道？ 直接回答：原渠道分段耗时与业务成功稳定、未知态收敛并完成小流量回切后再逐档恢复。
- 详细章节：HTTP（超文本传输协议）、HTTPS（安全超文本传输协议）与 MQTT（消息队列遥测传输协议）
- RFC 8446 TLS（传输层安全协议）1.3
问题：IoT（物联网）断网恢复后 MQTT（消息队列遥测传输协议）重复、重连和报警同时暴涨，如何治理？
- 考点：会话恢复、QoS（服务质量）、重连抖动、事件幂等、背压和报警状态机。
- 回答思路：先切断重连与重复通知正反馈，再保证关键事件可靠接管。
- 事实等级：协议与治理机制为 E2（既有材料映射），设备量和速率为 E3（演练设计），生产报警收益为 E0（待核对）。
- 详细答案：协议至少一次允许重复，恢复时必须同时治理连接到达率、事件唯一性、规则计算和通知聚合，不能只扩接入层。
- 进阶追问：如何证明限流没有丢掉关键报警？
- 进阶回答：按事件优先级和稳定序号核对原始接管流水、规则状态与通知结果，非关键降采样不能覆盖关键状态变化。
- 口述答案：我先保存设备分组、客户端版本、会话参数、重连策略、QoS（服务质量）、确认耗时、每秒建连、包率、事件循环延迟、队列年龄、重复事件和报警状态，不把“在线率下降”直接归因于网络。E3（演练设计）中 6 万设备在 30 秒内同时重连，平均每秒 2000 次，每台补发 20 条消息；确认变慢使 15% 再次发送，接入从 120 万条变成 138 万次，规则引擎若每条发两次通知就新增 36 万次无效通知。止血先按设备组把重连摊到 10 分钟，使用指数退避和 Jitter（随机抖动），限制非关键遥测与推送，但为火警、断电等关键事件预留配额；事件循环不可写时停止继续生产，规则层只对状态升级通知。平台以“设备编号+单调事件序号+类型”作为跨重连稳定键，可靠写入事件流水或持久队列后再确认，重复消息读取既有结果。长期修复会话恢复、客户端退避、有界业务池、写水位、事件幂等和报警窗口聚合，并对慢设备设置公平策略。回归复现 6 万设备分组恢复、确认丢失、进程强杀、乱序与重复，要求峰值建连受控、EventLoop（事件循环）P99（99 分位响应时间）达标、队列年龄下降、关键事件无缺失、重复报警低于门槛。恢复按设备组逐档放量，任一循环延迟或关键丢失护栏越界立即退档。复盘区分网络触发、客户端同步重连和服务端背压失效三个责任，不用“扩容后恢复”替代根因证明。对降采样的非关键遥测要保留策略版本、有效期和恢复水位，事故结束后自动撤销，防止临时降级长期存在。
- 追问 1：QoS（服务质量）2 能彻底去重吗？ 直接回答：不能，它不覆盖桥接、消费重试、数据库提交响应丢失和人工补发。
- 追问 2：确认越早越好吗？ 直接回答：不是，可靠接管前确认可能丢消息，过晚又增加重复，应以可恢复存储边界裁决。
- 追问 3：设备时间能做唯一键吗？ 直接回答：不能单独使用，时钟会漂移或回拨，应优先稳定设备标识和单调序号。
- 追问 4：在线率 99% 就算恢复吗？ 直接回答：不够，还要看关键事件、重复报警、队列年龄和循环延迟。
- 详细章节：IoT（物联网）报警风暴项目与综合题
- MQTT（消息队列遥测传输协议）5.0 官方规范
问题：DNS（域名系统）偶发慢且地址刚切换，怎样避免把解析、缓存和旧连接混为一谈？
- 考点：查询分位、有效期、负缓存、运行时缓存、连接实际远端与灰度切换。
- 回答思路：沿“权威答案—递归答案—应用缓存—连接远端”逐层核对。
- 事实等级：解析机制为 E2（既有材料映射），尾延迟和有效期为 E3（演练设计），生产解析拓扑为 E0（待核对）。
- 详细答案：新答案生效不代表应用立即重解析，也不代表旧池中长连接已退出；解析耗时和连接远端必须分别观测。
- 进阶追问：为什么切换解析器后恢复仍不能直接认定根因？
- 进阶回答：切换可能同时改变缓存、网络路径和负载，需比较查询耗时、答案和应用阶段，并复现原解析器的异常。
- 口述答案：我先固定域名、查询类型、解析器、网络命名空间、应用实例和变更时间，保存权威与递归答案、有效期、负缓存、查询 P50（中位响应时间）/P99（99 分位响应时间）、应用解析阶段、连接目标地址和连接年龄。这样可以区分四类问题：递归解析器尾延迟使新建连接慢；短时不存在被负缓存后，即使权威记录恢复仍继续失败；运行时或本地缓存持有旧地址；连接池继续复用旧地址上的长连接。E3（演练设计）中每秒 800 个业务请求因复用只产生 20 次解析，2% 查询耗时 1.2 秒，整体平均延迟只从 42ms（毫秒）到 65ms（毫秒），但新建连接 P99（99 分位响应时间）升到 1.35 秒；所以平均值会掩盖解析尾部。止血可切已验证解析器、降低连接新建率、摘除旧地址连接池并分批建立新连接，但不能把有效期粗暴改为零制造解析风暴。长期明确权威记录、递归缓存、运行时缓存和连接寿命的契约，地址切换前预热新池，旧实例先摘流量再排空连接。回归注入解析延迟、短时不存在、地址轮换和旧实例恢复，要求应用最终只连新地址、查询尾延迟受控、旧连接按窗口退出。支付与履约写若在切换中超时，仍按原业务键查证；恢复后核对渠道流水和外部单，不能以解析正常替代业务终态。复盘记录每层缓存所有者和紧急回退步骤，结论只覆盖实际采样的解析路径。如果切解析器后只看到请求成功率恢复，却没有解析阶段和答案对照，我会把它记录为有效止血而非已证明根因。恢复观察至少跨过一个旧缓存有效期和一个连接最大寿命，并确认下线实例没有新流量。
- 追问 1：有效期越短切换越快吗？ 直接回答：只影响允许缓存时间，实际还受递归、运行时缓存和连接复用影响，且会增加查询压力。
- 追问 2：应用解析到新地址为何仍访问旧地址？ 直接回答：正在复用的旧长连接不会因新解析自动迁移，必须排空或淘汰旧池。
- 追问 3：负缓存有什么风险？ 直接回答：短时不存在可能在记录恢复后继续失败，恢复时间取决于失败答案的缓存策略。
- 追问 4：只用公共解析命令够吗？ 直接回答：不够，应用可能使用不同解析器、缓存和命名空间，必须从实际进程路径取证。
- 详细章节：网络故障、性能与命令证据链
- RFC 1035 DNS（域名系统）规范
问题：连接池等待和陈旧连接复位同时发生，如何止血并重新计算容量？
- 考点：Little’s Law（利特尔法则）、下游配额、连接寿命、池等待、临时端口和业务幂等。
- 回答思路：先区分容量不足与寿命错配，再按依赖能力确定池上限。
- 事实等级：容量方法为 E2（既有材料映射），速率和阈值为 E3（演练设计），生产配额为 E0（待核对）。
- 详细答案：池等待可能由远端变慢造成，陈旧复位由中间层先回收空闲连接造成；扩池不能修复寿命错配，还可能压垮下游。
- 进阶追问：借出前健康检查是否应该每次执行？
- 进阶回答：需按连接年龄、失败概率和检查成本选择；每次远程检查可能把检查本身变成瓶颈。
- 口述答案：我先保存池获取耗时、在用/空闲/等待、连接创建和最后使用时间、目标地址、新建率、复位发生阶段、临时端口、代理空闲回收配置、下游时延与并发配额。等待高可能是池过小、连接泄漏或下游变慢；复位若集中在空闲超过 60 秒后的首次写，而客户端池保留 300 秒，新建连接立即成功，则支持陈旧连接。E3（演练设计）中跨境履约 600QPS（每秒查询率）、P99（99 分位响应时间）0.8 秒，单连接一次处理一个请求，按 Little’s Law（利特尔法则）在途约 480；池 200 会等待，扩到 1000 又超过渠道 500 配额。止血应把客户端空闲寿命调到代理阈值以下，淘汰超龄连接，关闭多层重试，按渠道限制在途并为关键业务留配额；履约建单和支付写复位后用原键查证，不能把一次传输失败变成第二个业务意图。长期按到达率、服务时间、下游配额和超时预算确定池容量，设置有限获取等待、渠道舱壁、连接最大寿命和旧地址排空。回归跨过代理回收阈值，覆盖并发借还、滚动重启、地址轮换和提交后断开；要求池等待、复位与新建率受控，临时端口稳定，外部履约单和支付分录唯一。恢复按渠道和业务类型分档，若下游尾延迟或未知态年龄恶化立即退回。复盘检查客户端、代理和服务端连接寿命为何没有统一所有者。容量验收不能只看池平均使用率，还要按渠道、租户和请求类型查看尾部等待及公平性；若关键小流量仍被批任务占满，说明舱壁没有生效。配置发布必须版本化并保留上一份池参数，防止全量调整后无法快速回退。
- 追问 1：重试成功能证明陈旧连接吗？ 直接回答：不能，需失败与连接年龄统计相关，并由调整寿命后的对照实验增强证据。
- 追问 2：池越大吞吐越高吗？ 直接回答：不会超过下游、网络和业务处理能力，过大只会增加并发、内存和失败影响。
- 追问 3：获取超时应大于请求超时吗？ 直接回答：不应，池等待属于用户总预算的一部分，必须给建连、执行和回包留时间。
- 追问 4：如何处理池中的旧地址连接？ 直接回答：按地址和连接年龄标记排空，停止新借出，允许在途完成后关闭并预热新池。
- 详细章节：网络连接池、截止时间与重试
- RFC 9210 DNS（域名系统）基于 TCP（传输控制协议）的运行要求
问题：epoll（事件轮询机制）边缘触发下连接有数据却不再触发读取，如何定位和修复？

考点：就绪语义、非阻塞读取、EAGAIN（暂时不可用错误）、兴趣集和公平预算。
回答思路：证明内核已有数据但应用未完整消费，再重放错误读取循环。
事实等级：事件机制为 E2（既有材料映射），连接数和注入为 E3（演练设计），生产触发方式为 E0（待核对）。
详细答案：边缘触发只在状态变化时通知，应用若只读取一次而未读到暂时不可继续，剩余数据可能没有新边沿；还需排除兴趣集被错误修改。
进阶追问：循环读取会不会让单连接饿死其他连接？
进阶回答：会有风险，应在读到 EAGAIN（暂时不可用错误）的正确性基础上设置每轮字节/消息预算，并重新调度热点连接。
口述答案：我先确认连接状态、内核接收队列、应用读取事件、兴趣集、触发模式和 EventLoop（事件循环）线程栈。如果内核接收队列持续有数据，网卡和 TCP（传输控制协议）窗口正常，但应用在一次就绪后只调用一次非阻塞读取，读取到部分字节就返回，且没有新的状态变化，那么边缘触发可能不再提醒；另一个候选是异常路径错误取消了可读兴趣，或解码器保留半帧却没有等待后续字节。E3（演练设计）中一次到达 64KiB（千字节），处理器只读 8KiB（千字节）后退出，剩余 56KiB（千字节）停在接收队列；修复循环后要读到 EAGAIN（暂时不可用错误）、关闭或预算边界。止血可以回滚触发模式变更、摘除异常版本并限制新连接，不能靠不断重连掩盖未消费数据。长期修复使用标准非阻塞读取循环，正确处理半包、关闭和错误，同时给单连接设置每轮字节/消息预算，预算耗尽后重新排队，避免热点连接独占线程。回归覆盖小包、多帧、半帧、突发大包、对端关闭、兴趣集修改和单连接洪峰，观察每轮就绪数、读取字节、任务年龄和健康连接延迟。IoT（物联网）场景还要核对设备序号与确认，防止读取恢复后历史消息集中触发重复报警。恢复分组放量，若循环延迟或未读队列再次增长立即回退。复盘要求代码评审明确触发模式和消费不变量，不把“epoll（事件轮询机制）丢事件”作为没有证据的结论。对照实验还应在同一连接分布下切换触发模式，确认只有修正消费循环才能稳定清空接收队列，而不是流量偶然下降。
追问 1：就绪等于一定有业务数据吗？ 直接回答：不等于，也可能是关闭或错误；即使有字节也未必组成完整业务帧。
追问 2：改回水平触发就算修复吗？ 直接回答：可止血，但仍应修正消费循环和兴趣集，否则会产生重复唤醒或空转。
追问 3：为什么必须非阻塞读取？ 直接回答：事件循环若在单连接上阻塞，会拖慢同线程的全部连接和定时任务。
追问 4：如何证明不是解码器问题？ 直接回答：对照原始接收字节、解码器累积状态和读取调用，确认字节是否已从内核进入用户态。
详细章节：epoll（事件轮询机制）、Reactor（反应器模型）与事件循环
Linux（操作系统）epoll（事件轮询机制）官方手册

问题：如何解释 Reactor（反应器模型）与 Netty（网络通信框架）线程模型，并为 12 万长连接做容量设计？

考点：接入与工作线程、Channel（通道）归属、活跃度、每事件预算和下游约束。
回答思路：先讲事件归属与推进，再用负载而非连接数单独计算容量。
事实等级：线程模型为 E2（既有材料映射），连接数与预算为 E3（演练设计），生产线程配置为 E0（待核对）。
详细答案：连接数只代表注册规模，真正负载由活跃比例、消息率、单事件成本、业务池和下游容量决定；增加事件循环线程不能修复阻塞业务。
进阶追问：连接建立后能否随意迁移到其他 EventLoop（事件循环）？
进阶回答：不能把迁移当常规扩容手段；线程归属关系影响事件顺序和处理器状态，应通过框架支持的注册流程或重连完成并验证。
口述答案：Reactor（反应器模型）的核心是等待就绪、分发事件和执行处理职责分离；Netty（网络通信框架）通常由 Boss（接入线程）接受连接，再把 Channel（通道）注册到 Worker（工作线程）组中的某个 EventLoop（事件循环），同一 Channel（通道）的事件按线程归属顺序推进，Pipeline（处理流水线）负责解码、校验、业务传播和编码。容量不能用“12 万连接除以线程数”就结束，我还要收集活跃连接比例、每连接消息率、平均/最大帧、单事件处理时间、定时任务、写缓冲、业务池完成率和下游配额。E3（演练设计）中 12 万连接分到 8 个线程，每线程约 1.5 万；若每线程每秒 20 次 80ms（毫秒）同步查询，需求 1.6 秒处理时间/秒，必然积压，增加连接承载宣传值没有意义。止血是摘除阻塞版本、关闭非关键推送、按设备组限流并保护关键心跳。长期把允许阻塞的工作卸载到有界业务池，设置截止时间和拒绝语义，结果回投前检查连接存活和任务版本；接入线程只做轻量注册。回归同时覆盖低活跃多连接、20% 慢端、单连接洪峰、重连风暴、业务池拒绝和滚动关闭，按每个 EventLoop（事件循环）观察循环延迟、任务年龄、连接分布和写积压，而不是只看全局平均。恢复按设备组放量，要求关键在线率、消息唯一性和资源上界同时达标。复盘记录线程数选择所依据的真实事件预算；生产数据缺失时，12 万只是 E3（演练设计）容量场景。
追问 1：Boss（接入线程）越多越好吗？ 直接回答：不是，接入并非总是瓶颈，过多线程会增加调度和共享资源竞争。
追问 2：单线程模型是否意味着完全无线程安全问题？ 直接回答：不意味，跨线程任务、共享处理器和外部状态仍需明确并发边界。
追问 3：业务池队列能否无界？ 直接回答：不能，下游变慢时会把延迟和内存风险隐藏为无限排队。
追问 4：如何发现连接分配不均？ 直接回答：按每个事件循环看连接数、活跃事件、任务年龄、最长任务和待发送字节。
详细章节：Netty（网络通信框架）线程与处理流水线
Netty（网络通信框架）线程模型官方说明

问题：EventLoop（事件循环）阻塞导致一组连接超时，你如何证明、止血和回归？

考点：每循环指标、连续线程栈、故障共享、任务卸载和重连放大。
回答思路：用时间先后证明循环阻塞是触发，再验证卸载后同组连接恢复。
事实等级：事件循环机制为 E2（既有材料映射），阻塞耗时为 E3（演练设计），生产影响范围为 E0（待核对）。
详细答案：全局处理器不高不能排除单事件循环阻塞；应按线程看循环延迟、任务年龄、连接组、处理器分段耗时与连续栈。
进阶追问：把阻塞任务提交到线程池为何仍可能失败？
进阶回答：无界队列、共享池或拒绝后立即重试会把故障转移并放大；卸载必须有容量、超时、隔离和回投协议。
口述答案：我先固定受影响连接是否集中在同一个 EventLoop（事件循环）、同一实例和同一版本，保存每循环 P50（中位响应时间）/P99（99 分位响应时间）、任务队列年龄、最长任务、处理器分段耗时、连续线程栈、套接字队列、写水位和设备重连率。若网卡、重传与其他事件循环正常，而异常线程的栈持续停在同步数据库、文件或域名解析，循环延迟先升、心跳确认后延、写缓冲和重连随后增长，就支持阻塞为触发、重连为放大器。E3（演练设计）中一个线程每秒执行 20 次 80ms（毫秒）同步查询，单秒需求 1.6 秒，理论上无法推进。止血先回滚或摘除版本，关闭非关键推送，对受影响设备组限速并扩大客户端重连抖动，但不把心跳超时无限调大。长期把阻塞任务放入按依赖隔离的有界池，提交时携带截止时间和稳定任务键；队列满时按业务语义拒绝、降级或持久化，不在 EventLoop（事件循环）调用方运行慢任务。结果回投检查 Channel（通道）是否仍存活、请求版本是否仍有效。回归用相同连接分布注入数据库慢、解析慢、业务池满和连接关闭竞态，要求异常只影响目标舱壁、健康连接不饥饿、队列有上界。恢复按 10%、30%、60%、100% 放量，每档同时验证循环延迟、重连率、重复报警和关键事件。复盘补齐阻塞调用静态检查、循环延迟告警和所有者，重启恢复只记为止血。观察窗至少覆盖原故障持续时间和一次滚动关闭，确认迟到任务不会再次写入已失效连接。还要对比同线程的正常连接，确认恢复来自阻塞任务移除，而不是流量自然下降或设备集中离线。
追问 1：全局处理器空闲为何仍会阻塞？ 直接回答：单事件循环可能等待外部 I/O（输入输出）或锁，其他核空闲也无法推进其连接。
追问 2：调用方运行拒绝策略适合事件循环吗？ 直接回答：通常不适合，慢任务会反过来阻塞事件循环并扩大超时。
追问 3：只看线程栈一次够吗？ 直接回答：不够，需要连续采样和分段耗时，排除偶发采样命中。
追问 4：何时可以恢复非关键推送？ 直接回答：循环和业务池水位稳定、重连下降并完成小组灰度后分档恢复。
详细章节：事件循环阻塞与写背压
Netty（网络通信框架）官方用户指南

问题：ByteBuf（字节缓冲区）直接内存泄漏如何定位，怎样验证不是正常池化高水位？

考点：引用计数、所有权、派生视图、分配栈、泄漏检测和稳态对照。
回答思路：先证明使用量不回落，再定位最后访问者和缺失释放路径。
事实等级：引用计数机制为 E2（既有材料映射），压力与采样配置为 E3（演练设计），生产泄漏栈为 E0（待核对）。
详细答案：池化内存可能保留高水位复用，泄漏则在相同负载与回收周期下持续增长；必须结合分配/释放、泄漏记录和异常路径对照。
进阶追问：为什么 slice（切片）尤其容易出错？
进阶回答：它通常共享父缓冲内存和引用计数，异步跨边界若未保留或重复释放，会形成过早释放或泄漏。
口述答案：我先确认容器总内存、直接内存、Netty（网络通信框架）分配器已用/保留、连接数、消息率和垃圾回收后基线，区分“池为复用保留已申请区域”和“活动引用无法归还”。正常池化高水位在负载稳定或下降后应进入平台期；泄漏往往在连接数和吞吐稳定时仍单调增长，并伴随泄漏采样或特定处理器访问记录。然后沿所有权检查：入站处理器消费后是否释放，向后传播是否错误重复释放，异常和提前返回是否覆盖，出站转换是否释放旧对象，slice（切片）/duplicate（重复视图）跨异步线程前是否正确 retain（保留引用），消费者是否最终 release（释放引用）。E3（演练设计）中堆稳定而直接内存每分钟增加 300MiB（兆字节），连接关闭后也不回落，开启高级检测的小流量实例重复指向解码异常路径，修复 finally（最终执行块）释放后同负载进入稳态，证据才闭环。止血摘除异常版本、限制新连接和大帧，保留泄漏记录；最高检测级别先用于测试或小流量，避免全量开销。回归覆盖正常、半帧、非法长度、异常关闭、跨线程和写失败，执行同一输入前后比较引用计数、直接内存和泄漏日志。恢复跨过原触顶周期，核对进程未重启、IoT（物联网）事件不重不漏。复盘明确每类消息的所有者和代码评审清单，不以“扩大直接内存上限”结案。对照实例应使用相同分配器配置和连接分布，否则池缓存差异会被误当成修复效果；修复发布后仍保留小流量泄漏采样窗口。同一异常种子至少重复三轮，证明释放路径稳定，且修复没有转化成过早释放或重复释放。
追问 1：垃圾回收后直接内存未降就一定泄漏吗？ 直接回答：不一定，池可能保留内存；要看活动使用量、负载平台期和可复用行为。
追问 2：访问引用计数为零的对象会怎样？ 直接回答：通常抛出 IllegalReferenceCountException（非法引用计数异常），说明所有权或生命周期错误。
追问 3：出站消息都不用管释放吗？ 直接回答：框架通常在写完成后释放原出站对象，但中间处理器转换出的新旧对象仍要明确责任。
追问 4：如何把修复做成门禁？ 直接回答：在异常分支测试启用严格泄漏检测，并要求压力回归无泄漏日志且内存进入稳态。
详细章节：ByteBuf（字节缓冲区）内存与引用计数
Netty（网络通信框架）引用计数官方说明

问题：Netty（网络通信框架）写缓冲持续越过高水位，如何设计真正的端到端背压？

考点：可写信号、生产源、高低水位、慢消费者、公平性和积压恢复。
回答思路：从发送能力反推入口和业务生产速率，并定义不可写时的业务语义。
事实等级：背压机制为 E2（既有材料映射），速率与水位为 E3（演练设计），生产消息分级为 E0（待核对）。
详细答案：高水位只暴露待发送压力，业务若继续生产就没有背压；信号必须传播到入口、业务池和消息优先级。
进阶追问：把高水位提高十倍为何危险？
进阶回答：它不增加网络发送能力，只扩大直接内存和排队时间，并让超时消息继续占资源。
口述答案：我先按 Channel（通道）和 EventLoop（事件循环）保存待发送字节、isWritable（是否可写）变化、高低水位、实际发送率、消息大小、慢连接比例、直接内存、循环延迟和业务生产率。E3（演练设计）中每秒生产 12000 条 1KiB（千字节）消息，网络只能发出 6000 条，净积压约 5.86MiB/s（兆字节每秒），一分钟约 352MiB（兆字节）；继续无界 write（写入）十分钟可超过 3GiB（吉字节）。高水位变为不可写只是信号，处理器必须停止为该连接继续生成非关键消息，把压力反馈到业务池和入口；状态类消息可合并为最新值，关键报警进入有界可靠队列，超过最大年龄的非关键消息丢弃并记录，长期慢端按策略断开。止血先关闭非关键推送、按设备组限制入口、暂停重试和广播，保护关键事件配额；不能在 EventLoop（事件循环）上执行慢降级逻辑。长期用高低水位防抖，监听可写变化，在低水位后小批恢复；业务池、消息队列和网络层共享截止时间、优先级与容量预算。回归注入 20% 慢端、网络降速、写失败和恢复抖动，要求不可写连接不拖垮健康连接，直接内存有上界，关键消息可追踪。恢复时若发送每秒 10000、入口限制每秒 7000，理论净消化每秒 3000，但仍按队列年龄和循环 P99（99 分位响应时间）分档。复盘记录背压在哪一层曾被截断以及临时丢弃策略的审计结果。
追问 1：关闭 autoRead（自动读取）就是完整背压吗？ 直接回答：不是，它只影响入站读取，还需控制业务生产、队列和写侧慢消费者。
追问 2：所有不可写连接都立即断开吗？ 直接回答：不应，先按业务优先级、持续时间和积压预算处理，长期超预算慢端才断开。
追问 3：低水位后为何不能全量恢复？ 直接回答：全量生产会再次越过高水位，应小批恢复并观察净积压和抖动。
追问 4：如何验证公平性？ 直接回答：按连接组比较发送份额、等待年龄、关键消息成功和慢端占用，防止少数慢端垄断内存。
详细章节：Netty（网络通信框架）写水位与端到端背压
Netty（网络通信框架）写缓冲水位接口

问题：请用一条统一证据链复盘支付未知、履约重复和 IoT（物联网）报警风暴的网络事故。

考点：跨层时间线、竞争假设、E 等级、业务不变量、止血修复验证复盘。
回答思路：从同一网络触发出发，分别用三种权威业务键完成存量收敛。
事实等级：统一方法为 E2（既有材料映射），故障组合与量级为 E3（演练设计），真实项目事故和收益为 E0（待核对）。
详细答案：技术层可以共享资源、连接、协议和事件循环证据，业务层必须分别以资金分录、履约外部单和设备事件序号裁决，不能用接口恢复替代对账。
进阶追问：如何区分触发因素、放大器和最终根因？
进阶回答：按时间先后、受控移除和同条件复现判断：最先变化且可复现的是触发候选，重试/背压失效等扩大影响，根因陈述包含机制和失守的防线。
口述答案：我先统一事故时间线和 E 等级：用户影响、版本/配置、主机与容器资源、DNS（域名系统）答案、连接状态与重传、TLS（传输层安全协议）/HTTP（超文本传输协议）/MQTT（消息队列遥测传输协议）阶段、EventLoop（事件循环）延迟、写缓冲、队列和三类业务账本。E3（演练设计）中某出口抖动先使重传和尾延迟升高，支付响应丢失形成未知态；多层立即重试使连接池等待，履约建单重复；IoT（物联网）确认延迟让设备同步重连，事件循环阻塞和背压失效继续放大报警。证据上要求资源/网络、运行时和业务至少两类独立信号同窗，并列出“出口故障、远端慢、事件循环阻塞、连接池错配”等可证伪假设。止血关闭内层重试、限制新写、切已验证出口，暂停非关键履约与遥测推送，按设备组分散重连；支付不返回伪失败，履约不生成新外部键，IoT（物联网）保留关键事件。存量分别以支付请求号查渠道并核对不可变分录，以内部任务键查外部履约单，以设备编号和事件序号去重报警。长期修复端到端超时、连接寿命、渠道舱壁、事件循环有界卸载、写水位和业务状态机。回归复用相同丢失、断开和慢端种子，按 10%、30%、60%、100% 分档，要求技术指标恢复且资金平衡、履约任务唯一、关键事件不丢、重复报警归零。复盘写清触发、放大器、失效护栏、误操作、监控缺口和负责人；没有生产原始证据时，事故量级与收益保持 E0（待核对），不包装成真实战绩。
追问 1：服务恢复后为何不能立即关闭事故？ 直接回答：存量未知、重复和迟到消息仍可能继续改变业务，必须完成查单、对账和观察窗。
追问 2：三类业务能共用一个幂等键方案吗？ 直接回答：不能机械共用，必须按各自权威身份和状态机定义，但可复用稳定键与唯一约束原则。
追问 3：如何证明切出口有效？ 直接回答：比较切换前后同流量的路由、重传、尾延迟和业务结果，并限定到该路径和时间窗。
追问 4：复盘最重要的输出是什么？ 直接回答：可验证的因果链、业务差异清零、可回滚修复、监控门禁和明确行动所有者。
详细章节：WMS（仓储管理系统）、IoT（物联网）、支付项目与综合题库
RFC 9110 HTTP（超文本传输协议）语义

15.91.09 Linux（操作系统）网络、Netty（网络通信框架）与证据链追问

15.91.09 Linux（操作系统）网络、Netty（网络通信框架）与证据链追问

1. CPU（中央处理器）、内存、磁盘与文件描述符：先回答谁在等待

1.1 四类资源不能用一个“机器负载高”概括

热门面试题

2. TCP（传输控制协议）握手、重传、流量控制与拥塞：状态不等于根因

2.1 从建连队列到窗口收缩的传输证据

热门面试题

3. HTTP（超文本传输协议）、HTTPS（安全超文本传输协议）与 MQTT（消息队列遥测传输协议）：通信成功不等于业务完成

3.1 把解析、建连、安全握手、协议响应和业务提交拆开

热门面试题

4. DNS（域名系统）与连接池：控制面缓存和数据面连接必须一起看

4.1 解析答案、连接寿命、池等待和远端容量是四个边界

热门面试题

5. epoll（事件轮询机制）、Reactor（反应器模型）与 Netty（网络通信框架）线程模型：就绪之后仍要推进

5.1 EventLoop（事件循环）的预算、归属与阻塞证据

热门面试题

6. ByteBuf（字节缓冲区）、背压与支付/履约/IoT（物联网）证据链：恢复性能还要恢复业务事实

6.1 内存所有权、可写水位和业务终态必须同时闭环

热门面试题

7. Linux（操作系统）网络、Netty（网络通信框架）与证据链综合追问题库

8. 复习与验收清单