nginx非阻塞读写机制依托事件驱动模型（epoll/kqueue）、sendfile零拷贝、合理缓冲与超时配置及http/2协同，高效支撑高并发视频流分发。
Nginx 的非阻塞读写机制在高带宽视频流分发中表现优异，核心在于它能高效复用少量工作进程处理成千上万并发连接，避免传统阻塞 I/O 在等待磁盘或网络响应时的资源空转。
事件驱动模型支撑高并发连接
Nginx 默认基于 epoll（Linux）或 kqueue（FreeBSD/macOS）实现事件驱动，对每个 TCP 连接不独占线程或进程。当一个视频流请求（如 HLS 的 .ts 片段或 DASH 的 .mp4 分片）到达时，Nginx 仅注册读就绪事件；数据可读时才触发回调，立即转发或缓存；发送缓冲区就绪后再异步写入，全程不阻塞其他请求。
- 单 worker 进程轻松承载数万并发连接，尤其适合大量轻量级 HTTP 视频分片请求
- 相比 Apache 的 prefork 或 worker 模型，内存占用低、上下文切换少
- 对 RTMP 或 HLS over HTTP 等长连接场景（如直播流拉取），能稳定维持数小时连接而不泄漏资源
零拷贝与 sendfile 优化大文件传输
对于点播类视频分发（如 MP4、MKV 文件直传），Nginx 启用 sendfile 指令后，内核可直接在文件描述符与 socket 之间搬运数据，绕过用户态内存拷贝。配合非阻塞 socket，即使单个 2GB 视频文件下载，也不会阻塞 worker 进程处理其他请求。
- 需确保操作系统支持（Linux ≥ 2.4）、文件系统支持（ext4/xfs 推荐）、且文件未被 mmap 或加密
- 搭配 tcp_nopush 和 tcp_nodelay 可进一步减少小包开销，提升吞吐稳定性
- 注意：sendfile 不适用于需要内容动态修改（如添加 header、切片重写）的场景
缓冲区与超时配置影响流式体验
非阻塞本身不保证低延迟，实际表现高度依赖缓冲策略与超时设置。例如，直播 HLS 流若后端源响应慢，Nginx 默认 buffer（如 proxy_buffering on）可能累积多个 ts 片段再返回，造成首屏延迟升高。
- 对实时性要求高的流，建议关闭 proxy_buffering，启用 proxy_buffering off，让响应边收边发
- 调小 proxy_read_timeout 和 proxy_send_timeout（如设为 10s），避免卡住连接拖垮整体吞吐
- 使用 limit_rate 或 limit_conn 防止单客户端耗尽带宽，保障多用户公平性
与现代协议协同提升效率
Nginx 1.9.5+ 原生支持 HTTP/2，结合非阻塞 I/O 可复用单连接并行推送多个视频分片（如 HTML + CSS + 多个 .ts），显著降低 TLS 握手和 TCP 建连开销。配合 Brotli/Gzip 压缩静态 m3u8 清单，进一步减少控制面延迟。
- HTTP/2 Server Push 对 HLS/DASH 清单及首片有明显加速效果，但需谨慎控制推送数量以防拥塞
- 启用 ssl_buffer_size 优化 TLS 分片，匹配视频分片大小（如设为 8k）
- 注意：gRPC 或 QUIC（如 Nginx Plus R22+）暂未广泛用于通用视频分发，标准版仍以 HTTP/1.1 + HTTP/2 为主力
不复杂但容易忽略的是：非阻塞能力必须与后端源站性能、网卡中断合并（RPS/RFS）、以及内核网络栈参数（如 net.core.somaxconn）协同调优，才能在 10Gbps+ 带宽下持续发挥最大吞吐。
