1、网络IO的痛点：传统IO模型的数据拷贝路径、上下文切换开销、为什么网络延迟高？
大家好，我是你们的老朋友。今天咱们来聊聊网络IO里最让人头疼的问题——延迟。
做网络系统这么多年，我见过太多应用被IO卡死的场景。说白了，网络延迟高，很多时候不是网速慢，而是数据在操作系统内部折腾得太久了。你想想看，一个数据包从网卡到应用程序，中间要经过多少道关卡？
1.1 传统IO模型的数据拷贝路径
先看一个最经典的场景：你的应用程序要从磁盘读一个文件，然后通过网络发出去。传统做法长什么样？
// 伪代码示意
read(file_fd, buf, len); // 从磁盘读到用户态缓冲区
write(socket_fd, buf, len); // 从用户态缓冲区写到网卡这段代码看起来简单，但背后藏着巨大的开销。我画个图你就明白了：
看到了吗？一次简单的读写，数据在内存里被搬了4次！
- 第1次：磁盘通过DMA把数据搬到内核缓冲区。这一步还好，不占CPU。
- 第2次：CPU把数据从内核缓冲区搬到用户缓冲区。这一步CPU得亲自干活。
- 第3次：CPU再把数据从用户缓冲区搬到Socket缓冲区。又是CPU在搬。
- 第4次：DMA把数据从Socket缓冲区搬到网卡。终于发出去了。
核心问题：数据在用户态和内核态之间来回倒腾了两次，每次都要CPU参与。这就像你搬家，先把东西从卧室搬到客厅，再从客厅搬到门口，最后才装车——多此一举。
1.2 上下文切换开销
数据拷贝还不是最要命的。真正让人头疼的是上下文切换。
每次调用 read() 或 write()，程序都得从用户态切到内核态。切一次，CPU要保存当前线程的寄存器、栈指针、程序计数器……然后加载内核的上下文。切回来的时候，再来一遍。
我给大家算笔账：
| 操作 | 上下文切换次数 | 单次切换开销（约） | 总开销 |
|---|---|---|---|
| read() 调用 | 2次（用户→内核→用户） | 1-5微秒 | 2-10微秒 |
| write() 调用 | 2次（用户→内核→用户） | 1-5微秒 | 2-10微秒 |
| 合计 | 4次 | — | 4-20微秒 |
你可能觉得，20微秒不算什么吧？但你要知道，现代数据中心里，网络往返延迟（RTT）也就几十微秒。你光在IO路径上就浪费了20微秒，这还没算数据拷贝的时间。
我的经验：有一次我在优化一个高频交易系统，发现每次订单处理都要做一次文件日志记录。就这一个read+write操作，硬生生把延迟从50微秒拉到了120微秒。去掉上下文切换后，延迟直接降回60微秒。嗯，这就是差距。
1.3 为什么网络延迟高？
好了，我们把上面的问题串起来，看看网络延迟到底高在哪里。
传统IO模型下，一次网络发送的完整路径是这样的：
- 应用程序调用 read() → 陷入内核态 → DMA从磁盘读数据到内核缓冲区 → CPU拷贝到用户缓冲区 → 返回用户态
- 应用程序处理数据（如果需要的话）
- 应用程序调用 write() → 陷入内核态 → CPU拷贝数据到Socket缓冲区 → DMA发送到网卡 → 返回用户态
这里面有三个主要瓶颈：
- 数据拷贝次数多：4次拷贝，其中2次占用CPU。CPU忙着搬数据，就没空处理真正的业务逻辑。
- 上下文切换频繁：4次上下文切换，每次切换都污染CPU缓存（L1/L2 cache），导致后续指令执行变慢。
- 内核态与用户态隔离：这个设计本身是为了安全，但代价就是数据必须跨边界拷贝。
避坑指南：我曾经见过一个团队，为了降低延迟，把业务逻辑全部塞到内核模块里写。结果呢？一个内核panic，整个机器挂了。千万别为了性能牺牲稳定性。零拷贝技术是在用户态解决问题，不是让你去改内核。
说白了，传统IO模型的设计初衷是「通用」和「安全」，而不是「性能」。它假设数据需要在用户态和内核态之间来回传递，这个假设在大多数场景下没问题。但在高并发、低延迟的场景下——比如Web服务器、消息队列、数据库——这个假设就成了性能杀手。
你想想看，一个Nginx服务器每秒要处理几万个请求，每个请求都来这么一套4次拷贝+4次切换，CPU资源全浪费在搬数据上了。
所以，业界才提出了零拷贝技术。它的核心思想就一句话：尽量减少甚至消除用户态和内核态之间的数据拷贝。具体怎么做？后面的章节我会详细讲。
今天先聊到这儿。记住这个痛点：传统IO模型下，数据拷贝和上下文切换是网络延迟的两大元凶。理解了问题，后面我们再来看怎么解决它。