接收缓冲区应匹配带宽时延积（BDP），初始值设为BDP的1.2–1.5倍；优先启用系统TCP自动调优，避免硬编码；需协同优化NoDelay、Keep-Alive等参数，并通过抓包或系统命令验证实际生效情况。
在大带宽、长距离网络（如跨洲专线、高延迟卫星链路）下，单纯增大 socket.receivebuffersize 并不能线性提升吞吐——关键在于让接收缓冲区匹配“带宽时延积”（bdp），同时避免与系统级自动调优冲突。
先算清楚最小合理值：BDP 是底线
接收缓冲区至少应 ≥ 带宽 × 往返时延（RTT）。例如：
- 1 Gbps 带宽 + 100 ms RTT → BDP = 10⁹ bit/s × 0.1 s ≈ 12.5 MB
- 此时若只设
ReceiveBufferSize = 64KB，TCP 接收窗口会被严重限制，无法填满管道，吞吐卡在几MB/s是常态
实践中建议初始值设为 BDP 的 1.2–1.5 倍，并预留余量应对突发抖动。
别绕过系统自动调优，除非你明确需要固定窗口
现代 Windows（Win7+）和 Linux（2.4+）都默认启用 TCP 接收窗口自动调节（Auto-Tuning）：
- Windows 上它叫 Receive Window Auto-Tuning Level，会动态扩缩
SO_RCVBUF，上限可达数MB - Linux 通过
/proc/sys/net/ipv4/tcp_rmem（如4096 87380 4194304）控制范围，内核按内存和网络状况实时调整 - 手动调用
setReceiveBufferSize()只会设为“最小保证值”，实际运行中仍可能被系统覆盖或扩展
除非业务强依赖固定窗口（如某些实时音视频协议），否则不建议硬编码超大值；更稳妥的做法是确认系统 Auto-Tuning 已启用，并通过 setReceiveBufferSize(0) 或不设置，交由内核决策。
配合其他关键选项协同生效
单改接收缓冲区效果有限，需同步优化关联参数：
-
保持
NoDelay = false：大块文件传输中，Nagle 算法的合并行为反而有利，关闭它（true）易导致小包碎片化，加剧丢包重传 -
启用并调优 Keep-Alive：设
SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.KeepAlive, true)，配合 120 秒空闲检测，防中间设备静默断连 -
检查是否启用了重叠 IO（Windows）：若开启
UseOnlyOverlappedIO，某些缓冲区行为会变化，可能导致预期外的阻塞或拷贝，非必要不启用
验证是否真正生效
光看代码设了没用，要观测真实内核行为：
- Linux：抓包看 TCP Option 中的
window scale和实际通告窗口大小（Wireshark 过滤tcp.window_size） - Windows：命令行执行
netsh int tcp show global，确认 Receive Window Auto-Tuning Level 为normal或experimental - 应用层：用
Socket.ReceiveBufferSize读回当前值，注意它返回的是“应用层请求值”，不是内核实际分配值
如果实测吞吐仍上不去，优先排查丢包率、路径 MTU、中间防火墙限速等外部因素，而非一味调大缓冲区。
