C语言中Raw sockets与SOCK_DGRAM对比：低CPU系统下能否提升吞吐量？

• 确实能降低开销、提升吞吐量，但收益取决于场景
  对低CPU的资源受限系统来说，Raw sockets绕过了内核TCP/UDP协议栈的一系列处理（比如分片重组、校验和计算、队列调度），直接让用户态程序掌控数据包构造逻辑，确实能省掉不少内核态与用户态之间的拷贝、协议解析开销。尤其是当你能跳过校验和计算（前提是硬件支持校验和卸载，或者你能接受少量丢包风险），这部分CPU消耗在低算力系统里占比极高，释放出来的资源能处理更多数据包，自然能拉高吞吐量。

• 但不是所有情况都值得折腾
  如果你的业务是常规UDP通信，而且内核已经开启了硬件校验和卸载、GRO/GSO这类优化，那Raw sockets带来的收益可能微乎其微。因为内核已经把大部分耗时操作甩给硬件完成了，你自己写Raw socket的数据包构造、缓冲管理代码，反而可能因为用户态实现不够高效（比如冗余内存拷贝、粗糙的循环逻辑），比内核协议栈更费CPU。

• 要不要用，看这三点

  1. 先查硬件卸载支持：用ethtool -k 你的网卡名查看checksum offload、tcp-segmentation-offload等选项是否开启。如果已经全开，内核协议栈的开销已经很低，没必要换Raw sockets。
  2. 跑基准测试对比：先写个基于SOCK_DGRAM的基准程序，统计CPU占用和吞吐量；再快速写个极简Raw socket测试程序（只做基础收发），对比两者的CPU使用率和吞吐量差异。如果Raw版本能把CPU占用降10%以上，同时吞吐量提升明显，那就值得投入开发。
  3. 权衡开发维护成本：Raw sockets需要自己手动构造IP头、UDP头，还要处理数据包缓冲、甚至重传（如果需要可靠传输），这些代码的维护成本很高。如果你的系统只需要简单的高吞吐量UDP通信，且内核优化已经够用，折腾Raw sockets就是浪费时间。

内容的提问来源于stack exchange，提问作者Simao