2. Socket API 的隐形成本：系统调用、上下文切换与数据拷贝
很多人写 UDP 程序，觉得调个 sendto() 就完事了。数据丢出去，内核自然会帮你搞定。嗯，我以前也这么想。直到有一次压测，我发现 CPU 全耗在了内核态，业务逻辑反而没跑多少。这才意识到——Socket API 不是免费的。
说白了，每次你调用 sendto() 或 recvfrom()，背后都藏着三笔开销：系统调用、上下文切换、数据拷贝。这三样东西，单个看都不大，但架不住次数多。UDP 小包一多，积少成多，性能就崩了。
核心观点：Socket API 的隐形成本，是 UDP 性能瓶颈的第一道坎。不理解这三笔账，优化无从谈起。
2.1 系统调用：用户态到内核态的“过路费”
应用程序跑在用户态，网络协议栈跑在内核态。你想发数据，必须通过系统调用让内核帮你干活。这个切换本身就有成本。
我习惯把系统调用比作“过收费站”。每次 sendto() 都是一次过站，你得停车、交费、再启动。虽然单次耗时只有几百纳秒到几微秒，但每秒几十万次调用，这个时间就非常可观了。
| 操作 | 大致耗时（x86_64） | 说明 |
|---|---|---|
| 空系统调用（getpid） | ~100 ns | 仅切换开销 |
| sendto() 小包 | ~500 ns - 2 µs | 含参数校验、路由查找 |
| recvfrom() 小包 | ~500 ns - 2 µs | 含数据从内核队列取出 |
你想想看，如果每秒发 100 万个小包，光系统调用开销就占了 0.5 秒到 2 秒的 CPU 时间。这还没算业务逻辑呢。
我的经验：我曾经优化过一个游戏服务器，每秒要处理 50 万条玩家位置更新。一开始每个包都调 sendto()，CPU 直接跑满。后来改成批量发送，一次调用发多个包，CPU 使用率降了 40%。
2.2 上下文切换：CPU 的“换挡”代价
系统调用必然伴随上下文切换。CPU 要从用户态切到内核态，保存用户态的寄存器、栈指针，加载内核态的上下文。回来时再切一次。
这个切换不是免费的。它会让 CPU 的流水线清空、TLB 失效、缓存污染。说白了，CPU 刚在用户态跑得正欢，突然被拉去干内核的活，回来时原来的数据可能已经不在缓存里了。
我记得有一次排查性能问题，用 perf 看上下文切换次数，发现每秒高达 30 万次。每次切换大约消耗 1-3 µs。算下来，光切换就占了 30%-90% 的 CPU 时间。业务逻辑反而成了配角。
避坑指南：我曾经见过一个团队，为了“高并发”开了几百个线程，每个线程都阻塞在 recvfrom() 上。结果上下文切换成了瓶颈，吞吐量反而比单线程还低。记住：上下文切换不是免费的，线程数不是越多越好。
2.3 数据拷贝：内存搬家的“体力活”
这是最容易被忽略的成本。你调用 sendto() 时，数据从用户态缓冲区拷贝到内核态缓冲区。内核再把它拷贝到网卡驱动。接收时反过来：网卡 -> 内核 -> 用户态。
一次 UDP 收发，至少经历 2 次数据拷贝（发送：用户->内核；接收：内核->用户）。如果用了某些机制，可能更多。
数据拷贝的代价有多大？我直接给个数字：拷贝 1 KB 数据大约耗时 100-200 ns。看起来不多，但如果你每秒发 100 万次，光拷贝就占了 100-200 ms 的 CPU 时间。而且这还只是拷贝本身，没算缓存污染。
你想想看，数据在内存里搬来搬去，CPU 的缓存被反复冲刷。本来热点数据在 L1 缓存里待得好好的，一拷贝全没了。
| 阶段 | 拷贝次数 | 数据流向 |
|---|---|---|
| 发送 | 1 次（用户 -> 内核） | 应用程序缓冲区 -> 内核 Socket 缓冲区 |
| 接收 | 1 次（内核 -> 用户） | 内核 Socket 缓冲区 -> 应用程序缓冲区 |
| 总计 | 2 次 | 每次收发至少 2 次内存拷贝 |
关键认知：数据拷贝不仅是 CPU 时间的消耗，更是缓存效率的杀手。优化 UDP 性能，很多时候就是在减少不必要的拷贝。
2.4 三笔账的总和：一个典型场景
我们算一笔账。假设你要发送 64 字节的 UDP 包，每秒 50 万次。在普通 x86_64 服务器上：
- 系统调用：每次 ~1 µs，共 0.5 秒 CPU
- 上下文切换：每次 ~2 µs，共 1.0 秒 CPU
- 数据拷贝：每次 ~0.1 µs，共 0.05 秒 CPU
- 合计：约 1.55 秒 CPU
这还只是 Socket API 本身的成本。如果加上协议栈处理、中断、业务逻辑，一个 CPU 核心很快就跑满了。
所以，优化 UDP 通信，第一步就是减少系统调用次数、降低上下文切换频率、避免不必要的数据拷贝。后面的章节我们会具体讲怎么做。
2.5 一张图看懂隐形成本
下面这张图，把系统调用、上下文切换、数据拷贝的关系画清楚了。我建议你多看几遍，理解数据在用户态和内核态之间的流转路径。
2.6 怎么量化这些成本？
光说理论不够，你得能测出来。我常用的方法：
- 用
perf stat看上下文切换：perf stat -e context-switches ./your_app - 用
strace -c统计系统调用耗时：strace -c -p <pid> - 用
bpftrace跟踪数据拷贝路径：写个脚本 hookcopy_user_enhanced_fast_string之类的函数
我个人习惯是先跑一轮 perf stat，看看上下文切换次数是不是异常高。如果每秒超过 10 万次，基本可以断定这里有优化空间。
小技巧：如果你不想用复杂工具，可以简单对比：在 sendto() 前后加 clock_gettime()，算出差值。虽然不精确，但能看出趋势。我曾经用这个方法，发现某个场景下 sendto() 平均耗时 3 µs，其中 2 µs 是上下文切换。
2.7 小结：记住这三笔账
系统调用、上下文切换、数据拷贝。这三样东西，是 Socket API 的隐形成本，也是 UDP 优化的起点。
后面的章节，我们会讲怎么绕过这些成本。比如用 sendmmsg() 减少系统调用，用 SO_BUSY_POLL 减少上下文切换，用 mmap 或 DPDK 减少数据拷贝。但前提是——你得先理解成本在哪。
嗯，这一章就到这里。记住这三笔账，后面优化的时候，你自然知道该往哪个方向使劲。