tcp_wmem不直接塑形流量，而是作为“蓄水池”支撑Nginx限速策略稳定生效；其三元组（min/default/max）需按链路BDP匹配，协同wmem_max等参数，避免抖动或延迟。
Nginx 本身不直接做流量塑形，真正起作用的是内核 TCP 发送缓冲机制与 Nginx 外发行为的协同。关键不是“控制发送队列长度”，而是让 net.ipv4.tcp_wmem 提供恰到好处的缓冲能力，支撑上层限速策略稳定生效。
tcp_wmem 的真实角色是“蓄水池”，不是“水龙头”
它由三元组构成：min default max（单位字节），分别控制每个 TCP socket 发送缓冲区的下限、初始值和上限。这个缓冲区决定 Nginx 能攒多少待发数据——太小，限速抖动甚至断流；太大，延迟升高、内存浪费、突发放大。
必须匹配客户端链路的 BDP（带宽 × 往返时延）
比如目标链路是 1Gbps + 33ms RTT，BDP ≈ 4MB。若 tcp_wmem[2] 小于该值，sendfile 推送大文件时会频繁阻塞、分段，破坏 limit_rate 的平滑性；若远超，则排队延迟拉长，对低延迟场景不利。
Nginx 行为直接受其影响
-
sendfile on时，数据从磁盘直接送入 socket 发送队列，缓冲区大小决定是否能一次性填满窗口 -
tcp_nopush on（默认）等待缓冲区满或超时才发包，default值过低会导致小包泛滥，干扰限速节奏 - 反向代理场景中，该参数约束的是 Nginx → 客户端 这一跳，而非 Nginx → 后端
实操配置建议（按典型场景）
- 普通 Web 服务（兼顾延迟与吞吐）：
net.ipv4.tcp_wmem = 4096 65536 1048576（4KB / 64KB / 1MB） - 高吞吐静态资源（CDN 边缘、1Gbps+）：
net.ipv4.tcp_wmem = 4096 262144 4194304（4KB / 256KB / 4MB） - 低延迟 API 代理（sub-10ms RTT）：
net.ipv4.tcp_wmem = 4096 16384 65536（4KB / 16KB / 64KB）
硬性协同项不可遗漏
-
net.core.wmem_max必须 ≥tcp_wmem[2]，否则内核静默截断 - 若 Nginx worker 显式调用
setsockopt(SO_SNDBUF)，则tcp_wmem[1]不生效，需统一管控 -
limit_rate或tc才是真正的塑形执行者，tcp_wmem只负责不让缓冲成为瓶颈
不复杂但容易忽略
