SSE 长连接流式传输与背压控制

SSE 长连接流式传输与背压控制架构 (Server-Sent Events Streaming & Reactive Backpressure Architecture) 是大模型在线对话服务中将模型逐 Token 自回归生成的离散 Token 实时、单向、低开销推送至客户端浏览器的核心网络传输标准；与双向繁重的 WebSocket 相比，SSE 基于原生标准 HTTP/1.1 或 HTTP/2 协议（`Content-Type: text/event-stream`），具备极其轻量、原生支持断线自动重连 (Reconnection with `Last-Event-ID`)、天然穿越公司防火墙与代理网关的巨大优势；在高并发场景下，网关与推理服务之间采用响应式背压流控机制 (Reactive Streams / Backpressure: 基于 TCP 滑动窗口与缓冲队列水位)，当客户端消费过慢或发生网络拥塞时，主动向 LLM 推理引擎施加反压暂停下一 Token 生成，杜绝网关内存耗尽。

ChatGPT 式实时打字机流式对话、智能 Agent 实时思考过程 (Thinking Process) 流式输出、实时代码生成。

若采用传统单次 HTTP 请求同步等待，用户必须忍受长达 10~30 秒的完全白屏等待（首字延迟 TTFT 极高）；SSE 流式传输让用户在 200ms 内看到首字吐出，极大提升交互体验，而背压机制保证了数十万并发长连接下网关内存的绝对安全。

详细对比 SSE (Server-Sent Events) 与 WebSocket 在连接开销、双向通信、代理网关缓冲 (Nginx Buffering) 与断线重连机制上的差异？

Nginx 代理层配置：为什么必须显式配置 `proxy_buffering off;` 和 `X-Accel-Buffering: no;` 才能防止网关缓冲大模型流式 Token？

大模型推理服务（如 vLLM / TensorRT-LLM）中的 Token 生成器与异步协程背压：如何通过 AsyncGenerator 队列防止消费者过慢导致的显存/内存泄漏？

长连接连接池管理与负载均衡：如何避免数万个长连接导致特定后端网关节点连接数倾斜 (Connection Skew)？

客户端异常断线检测与推理中断 (Client Disconnect Abort)：当用户主动点击“停止生成”或关闭网页时，如何跨服务通知 GPU 即刻终止该 Request 的 KV Cache 计算？