net.core.busy_read 是 Linux 内核中与网络性能优化相关的参数，主要用于控制 socket 层的忙轮询（Busy Polling）行为，与 net.core.busy_poll 配合使用，共同优化网络数据包的处理效率。以下是详细解析：

核心功能

net.core.busy_read 用于设置在 socket 层进行忙轮询的 最大尝试次数（单位为“迭代次数”，非时间单位）。当应用程序调用 recv() 等 socket 读取函数时，如果没有立即获取到数据，系统会根据该参数的值，在用户态主动轮询 socket 接收队列，尝试获取数据包，而非立即返回“无数据”（EAGAIN）。

• 若值为 0（默认）：禁用 socket 层忙轮询，遵循传统机制（无数据时立即返回）。
• 若值大于 0：启用忙轮询，最多尝试指定次数后再返回，以减少因“无数据”导致的系统调用往返开销。

工作原理与优势

传统 socket 读取流程中，若调用 recv() 时无数据，系统会立即返回 EAGAIN，应用程序需等待一段时间后重试（如通过 select/epoll 监听），这会增加延迟。
net.core.busy_read 通过让应用程序在用户态主动轮询 socket 队列，避免了频繁的系统调用和等待，从而：

• 降低延迟：尤其对小数据包、高频次读取的场景（如实时通信、高频交易），减少“无数据-重试”的循环开销。
• 提升吞吐量：减少系统调用次数，降低 CPU 在用户态与内核态之间的切换成本。

配置方式

1. 临时配置（重启失效）

sysctl -w net.core.busy_read=100  # 设置最大轮询次数为 100（示例值）

2. 永久配置（重启生效）

编辑 /etc/sysctl.conf 或 /etc/sysctl.d/ 配置文件，添加：

net.core.busy_read = 100

执行 sysctl -p 使配置生效。

与 net.core.busy_poll 的协同作用

两者均用于优化网络延迟，但作用层次不同：

• net.core.busy_poll：作用于 内核态的网络设备驱动层，控制 CPU 轮询网卡接收队列的时间。
• net.core.busy_read：作用于 用户态与内核态交互的 socket 层，控制应用程序读取 socket 时的轮询次数。

通常需同时配置：例如，先通过 busy_poll 让内核快速将网卡数据传入 socket 队列，再通过 busy_read 让应用程序在用户态快速读取，形成“内核-用户态”协同的低延迟处理链路。

适用场景与注意事项

适用场景：

• 低延迟敏感应用：如金融交易、实时音视频、高频数据采集等，需最小化数据包从内核到用户态的传递延迟。
• 小数据包高频交互：如微服务间的 RPC 通信、物联网设备的实时上报等，减少系统调用开销。

注意事项：

• CPU 消耗：忙轮询会占用用户态 CPU 资源（应用程序在循环中等待），若设置过高，可能导致 CPU 利用率飙升，需根据应用并发量调整。
• 值的选择：需通过测试确定（常见值为 50~500），过小则效果有限，过大会浪费 CPU。例如，100 次迭代约对应几微秒到几十微秒（取决于 CPU 性能）。
• 依赖非阻塞 I/O：需配合非阻塞 socket 使用（O_NONBLOCK），否则可能导致应用程序阻塞。
• 硬件与内核支持：需内核版本 ≥ 3.11（部分老版本可能不支持），且网卡需支持 NAPI 机制。

总结

net.core.busy_read 是优化 socket 数据读取延迟的关键参数，通过在用户态主动轮询减少系统调用开销。需结合 net.core.busy_poll 及应用特性配置，平衡 CPU 消耗与延迟收益，适用于对实时性要求极高的场景。