直接回答：incast 是“多打一”扇入流量模式下的吞吐崩塌：一个接收方同时向几十个发送方要数据（MapReduce shuffle、分布式存储读条带），所有流汇聚到同一交换机端口，缓冲区瞬间打满丢包，大量 TCP 流进入超时重传（RTO 最小 200ms 起步），有效吞吐跌一两个数量级——不是带宽不够，是丢包引发的同步退避。

展开解析：机理拆解：瓶颈在交换机浅缓冲（数据中心交换机常只有几十 KB 每端口）遇上同步扇入——N 个流同时满窗口发送，超出缓冲的微突发（microburst）丢包；丢包触发超时而非快速重传（窗口尾部丢包 dupack 不够三个），全体发送方等 RTO，链路真空；醒来后窗口重置又同步冲满，周而复始——全局同步震荡。缓解分四层：传输层——减小 min RTO（Linux 可配到 1~5ms 级，数据中心 RTT 微秒级，200ms 默认值是万恶之源）、启用 DCTCP 这类数据中心拥塞控制（用 ECN 标记在队列未满时提前减速，避免真丢包）；网络层——增大交换机缓冲或用动态缓冲分配、ECN 显式拥塞通知替代丢包信号；应用层——限扇入度（并发拉取数封顶）、请求调度错峰（jitter）、聚合响应（中间层合并再回）；链路层——PFC 等无损以太网方案治丢包但引入队头阻塞与死锁风险，RoCE 场景才认真考虑。排查特征：应用层看“偶发 200ms 倍数的长尾延迟”、netstat 看重传率、交换机端口看丢包计数——长尾延迟对 P99 敏感的服务（搜索、推荐）incast 是隐形杀手。现代答案：DCTCP/BBR 类拥塞控制加 ECN 基本是标准解法。

追问方向：为什么快速重传机制在 incast 场景失效？DCTCP 与经典 AIMD 的窗口调节差异？

（约 500 字）