Socket缓冲区需按业务流量与网络路径精准调优：过小致CPU空转，过大引发延迟与重传；接收缓冲区影响丢包率，发送缓冲区制约吞吐与RTT；须协同内核参数（如netdev_max_backlog、tcp_congestion_control）及应用层非阻塞IO优化。
Socket缓冲区大小直接影响Linux高并发网络传输的吞吐量、延迟和丢包率。缓冲区过小会频繁触发系统调用和上下文切换，造成CPU空转；过大则浪费内存、加剧TCP延迟（如Delayed ACK、Nagle算法交互），还可能放大重传风暴。关键不在“越大越好”，而在于匹配实际业务流量模型与网络路径特性。
接收缓冲区（rx buffer）影响数据接收效率
当应用层读取速度跟不上网卡收包速度时，内核接收队列会积压数据包。若缓冲区填满，新到达的数据包会被内核直接丢弃（netstat -s 中可见 “packet receive errors” 或 “RcvbufErrors”）。对于短连接高频请求（如HTTP API），建议将 net.core.rmem_max 调至 4MB～16MB，并配合应用层设置 SO_RCVBUF 显式指定（绕过自动调优干扰）。
- 查看当前值：sysctl net.core.rmem_default net.core.rmem_max
- 临时调整：sysctl -w net.core.rmem_max=8388608（8MB）
- 对单个socket生效：调用 setsockopt(fd, SOL_SOCKET, SO_RCVBUF, &size, sizeof(size))
发送缓冲区（tx buffer）制约发包节奏与吞吐上限
发送缓冲区存放待确认的TCP报文。若太小，应用写入后立即阻塞（或返回EAGAIN），限制并发写能力；若太大，会导致BTLB（Bufferbloat）现象——大量数据堆积在中间节点队列中，RTT飙升、丢包率上升。典型Web服务可设 net.core.wmem_max 为 2MB～4MB，同时启用TCP拥塞控制优化（如bbr或cubic）。
- 确认是否启用自动调优：sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem（三元组表示 min/default/max）
- 禁用自动扩缩（避免突发流量下缓冲区无序膨胀）：sysctl -w net.ipv4.tcp_window_scaling=0（慎用，仅限可控内网）
- 观察真实占用：ss -i 查看每个socket的 snd_wnd、snd_cwnd、wscale 等字段
内核参数协同调优比单点调大更关键
单纯增大socket缓冲区效果有限，需同步优化底层网络栈行为。例如：net.core.netdev_max_backlog 控制网卡中断后软中断队列长度，高吞吐场景建议 ≥ 5000；net.ipv4.tcp_slow_start_after_idle 关闭可防止长连接空闲后重置慢启动，保持高发送窗口。
- 批量调优示例（适用于千兆以上网卡+万级并发）：
sysctl -w net.core.netdev_max_backlog=5000
sysctl -w net.ipv4.tcp_slow_start_after_idle=0
sysctl -w net.ipv4.tcp_congestion_control=bbr - 验证是否生效：sysctl net.ipv4.tcp_congestion_control 应返回 bbr
应用层需适配缓冲区变化
增大缓冲区后，若应用仍采用阻塞read/write且未做批量处理，性能不会提升。应使用epoll + 非阻塞IO，每次read尽量读到 EAGAIN，write前检查SO_SNDLOWAT，结合MSG_MORE减少小包。对于gRPC/HTTP/2等多路复用协议，还需关注流控窗口（stream-level flow control）与socket缓冲区的叠加效应。
- 避免“一次只读1KB”：按缓冲区大小分批次读（如4KB/16KB对齐）
- 写操作前检查可写空间：ioctl(fd, SIOCOUTQ, &qlen) 获取当前发送队列字节数
- 对延迟敏感服务（如实时音视频），反而应适当减小缓冲区并启用TCP_NODELAY
