接收窗口（rwnd）由net.ipv4.tcp_rmem、net.ipv4.tcp_window_scaling和net.ipv4.tcp_app_win共同决定：tcp_rmem设定缓冲区范围，tcp_window_scaling启用窗口缩放以突破64KB限制，tcp_app_win控制通告可用缓冲区比例。
Linux 内核参数直接影响 TCP 滑动窗口的实际行为和性能上限。滑动窗口不是固定值，而是由接收方通告窗口（rwnd）与发送方拥塞窗口（cwnd）共同决定的动态结果：实际发送窗口 = min(rwnd, cwnd)。内核参数主要通过控制缓冲区大小、窗口缩放能力、通告策略和拥塞算法来塑造这两个窗口的生成逻辑。
接收窗口（rwnd）由哪些参数决定？
接收窗口反映接收方当前可用缓冲区容量，其大小直接受以下参数影响：
- net.ipv4.tcp_rmem：三元组（min, default, max），单位字节。内核根据 socket 接收队列压力，在该范围内动态调整实际接收缓冲区大小；该缓冲区大小直接参与 rwnd 计算。例如设为“4096 131072 6291456”，表示最小 4KB、默认 128KB、最大 6MB；若应用未显式设置 SO_RCVBUF，内核会在此区间自适应。
- net.ipv4.tcp_window_scaling：必须为 1（默认开启）才能启用窗口缩放选项。否则即使 tcp_rmem 设置再大，rwnd 最大只能是 65535 字节（16 位限制），无法适配高带宽延迟积（BDP）网络。
- net.ipv4.tcp_app_win：默认为 0，表示应用层提供的接收缓冲区全部用于通告；若设为正整数（如 31），内核会预留部分空间不对外通告，防止应用读取慢导致缓冲区长期淤积（buffer bloat）。
发送窗口（cwnd）如何被内核参数调控？
拥塞窗口 cwnd 由拥塞控制算法动态计算，但内核参数决定了它的起点、增长方式与上限：
- net.ipv4.tcp_congestion_control：指定当前启用的拥塞控制算法（如 cubic、bbr、reno）。不同算法对丢包、延迟的响应逻辑不同，直接影响 cwnd 的收敛速度与稳态值。BBR 更关注带宽估计，CUBIC 更依赖丢包信号。
- net.ipv4.tcp_slow_start_thresh：慢启动阈值。当 cwnd 超过该值后，进入拥塞避免阶段（线性增长而非指数增长）。合理设置可平衡建连初期吞吐与稳定性。
- net.ipv4.tcp_wmem：虽不直接设定 cwnd，但发送缓冲区过小会限制数据供给，使 cwnd 无法充分扩张；过大则可能掩盖真实网络瓶颈，造成重传或延迟升高。
窗口缩放与通告行为的关键调节点
即使缓冲区足够大，若窗口缩放未协商成功或通告被压制，滑动窗口仍无法突破 64KB：
- 窗口缩放需双方在 SYN/SYN-ACK 中协商，net.ipv4.tcp_window_scaling=1 是前提，且客户端和服务端都需开启才生效。
- net.ipv4.tcp_timestamps=1（默认开启）虽非窗口直接参数，但它是窗口缩放协商的必要条件之一；关闭后可能导致缩放失败。
- net.ipv4.tcp_adv_win_scale 控制“应用窗口偏移量”，影响内核最终向对端通告的 rwnd 值——它基于 tcp_rmem 和 tcp_app_win 计算，决定多少缓冲区真正可用于通告。
典型调优场景下的参数组合逻辑
针对不同网络环境，参数应协同调整：
- 高带宽低延迟局域网：重点调大 tcp_rmem/tcp_wmem 的 max 值（如 4M~16M），确保 BDP（带宽 × RTT）能被窗口覆盖；保持 window_scaling=1、timestamps=1；可选用 bbr 算法提升利用率。
- 公网长肥管道（High-BDP）：除增大缓冲区外，还需确认 tcp_slow_start_thresh 足够高（如 524288），避免过早退出慢启动；配合 net.core.rmem_max / wmem_max 提升全局上限。
- 高并发短连接服务：更关注连接建立与释放效率，滑动窗口调优优先级低于 syn_backlog、somaxconn 等；但若存在大量长连接传输大文件，仍需保障单连接窗口能力。
