iocp与epoll吞吐差异取决于配置而非模型本身：epoll单线程1000mb/s、iocp多线程400mb/s的测试结果受网卡速率、线程池配置、内存分配等干扰；iocp内核完成数据拷贝，epoll需用户态同步recv，真实瓶颈在内核路径、拷贝次数与调度细节。
IOCP 和 epoll 的吞吐差异不能一概而论——不是“谁更快”，而是“在什么条件下谁更稳、谁更省、谁更容易翻车”。
测试结果常被误读：单线程 epoll 跑赢多线程 IOCP 很可能只是配置问题
你看到的“epoll 1000MB/s vs IOCP 400MB/s”这类数据，大概率混入了关键干扰项：
- 网卡速率不同（XP 主机标称 100M，虚拟机 Ubuntu 显示 1000M）——
ethtool或ip link查实际协商速率比看 GUI 更可靠 - IOCP 示例用了多线程但未说明是否启用线程池负载均衡，
CreateIoCompletionPort第四个参数若传 0，内核不会自动分发完成包，线程可能空转或争抢 - epoll 示例用单线程 +
EPOLLET+ 循环recv()，而 IOCP 示例若对每个WSARecv都分配新OVERLAPPED且未预分配缓冲区，会触发频繁内存分配和锁竞争 - Windows XP 系统本身已无 TCP Chimney、RSS、Receive Side Scaling 等现代网卡卸载支持，而 Linux 5.x 内核默认启用
tcp_rmem/tcp_wmem自动调优和SO_BUSY_POLL
真正影响吞吐的三个硬约束：内核路径、拷贝次数、线程调度
吞吐瓶颈往往不在“模型名字”，而在数据落地前的每一步：
Windows-Android_SSH_Remote_Control
下载
通过 SSH 隧道从 Android 设备在互联网上对 Windows PC 实现完整远程控制的设置与使用指南，适用于远程桌面访问、安全 RDP 等。
- IOCP 在完成通知前，已由内核完成从网卡 DMA 区域到用户
buffer的拷贝（前提是使用WSABUF指向的固定内存），零用户态参与搬运；但若buffer分配在堆上且未锁定物理页（VirtualLock），仍可能触发 page fault 中断 - epoll 下的
recv()是同步系统调用，哪怕非阻塞，也要经历：内核检查 socket 接收队列 → 触发 copy_to_user → 返回。每次调用至少 1 次上下文切换 + 1 次内存拷贝；高频率小包场景下，epoll_wait唤醒开销反而低于GetQueuedCompletionStatus的完成包投递延迟 - Linux 上多线程调用
epoll_wait共享同一epoll_fd是安全的，但 Windows 下多个线程调用GetQueuedCompletionStatus争抢同一个完成端口时，若未设置NumberOfConcurrentThreads = 0，内核不会限制唤醒线程数，可能引发虚假唤醒和线程抖动
别只盯着 epoll/iocp，真异步得看 io_uring 和 Windows 的 I/O priorities
2026 年还在拿原生 epoll 和 IOCP 比吞吐，相当于用 2003 年的网卡跑 10G 网络——模型已不是瓶颈，生态和配置才是：
- Linux 上
io_uring（5.1+）支持IORING_OP_RECV+IORING_FEAT_FAST_POLL，可绕过传统 socket 路径，实测在 4K 小包场景下吞吐比 epoll 高 2–3 倍，但需手动管理 submission queue ring buffer，glibc 仍未封装io_uring_enter的高级接口 - Windows Server 2022 已支持
SetFileInformationByHandle设置FileIoPriorityHintInfo，可为高优先级连接分配更多 IOCP 完成包带宽，但普通桌面版 Windows（如 XP/7/10）不识别该 hint - 跨平台项目若强行统一抽象层（如 ASIO 的
io_context），底层实际在 Windows 走 IOCP，在 Linux 走 epoll，但 ASIO 默认禁用EPOLLET且 recv 缓冲区复用策略保守，吞吐常比手写 epoll 低 30%–50%
真正难调的从来不是“选 epoll 还是 IOCP”，而是：Linux 上如何让 epoll_wait 不因 CPU 频率跳变而延迟抖动，Windows 上如何避免 PostQueuedCompletionStatus 在高负载时被内核丢弃完成包——这些细节文档不写，但线上故障全靠它。
