再附带一个小小的吐槽：node.js 的异步 IO 本质不是为了解决磁盘 IO，而是网络 IO （ MySQL、redis、RPC 等），磁盘 IO 已经超快了，不需要异步。

@mashiro233 回复的是 #99 的内容

node.js 的异步 IO 是用 libuv 来做的，这里是中文文档： http://luohaha.github.io/Chinese-uvbook/source/introduction.html

简而言之，libuv 封装的是 libev （*NIX ） 和 IOCP （ Windows ），而 libev 使用的是 epoll （ Linux ）和 Kqueue （*BSD ），归根到底都是操作系统提供的功能，我上面说过，这个功能是 CPU 和操作系统联合实现的。更多细节请参考《 CS:APP 》。

另外稍微提一句，IO 的意思就是输入输出，Linux 下严格讲不存在“文件 IO ”这个东西，因为一切皆文件。

@mashiro233 正面回应：

首先我希望你不要把你在网上的博客上看来的浅显甚至是错误的知识用来反驳我。从你的反驳可以看出，这不是你自己工作经验的产物，甚至都不是系统学习的产物，你需要学习的是《计算机组成原理》和《 CS:APP 》，特别是后者，建议你看一下。

1. 协程是在单线程内工作的一点错没有，现实中协程调度就是在单线程内做的，理论上讲只占一个核心。但是，第一操作系统会自动调控，第二单线程的协程也比多线程多进程性能高几个数量级，例如 C10K 和 C1000K。
2. 你完全没有好好看我的评论，协程为什么性能高，就是因为没有上下文切换了。
3. 你管这个叫测试？好好学学英语，这是一个研究者在某一个会议上发表的论文，目的就是网络调优。关于 x86 网络性能你可以读读腾讯云的文章： https://cloud.tencent.com/developer/article/1035503 中文的。
4. DPDK 你都不知道是什么原理吧？找个文档就反驳我。实际上你这个回复是在帮我解释。这也反映了你真的完全不懂什么是协程，请再读一遍我上面的那条回复，学习一下什么是协程。等你明白了就知道你这个回复的逻辑错误在哪里了。
5. 还是你不懂协程导致的。你不仅不懂协程，还不懂网络编程的本质，frame 依旧是 kernel 提供的，网卡那里就是一个又一个电信号，哪管你什么 frame 不 frame 的。多学习，你会明白的。
6. 你拿着现有的多线程网络编程思想来看待我的话，自然无法理解。实际上我觉得你的这条回复不知所云，自己都乱了。还是建议你仔细读一下我上面的回复，学习一下什么是协程。

总结：

从你的回复来看，我上面的结论“写不出来的话，能一句话概括我也认。绝大多数人都不知道高性能服务器开发领域的协程概念。”是正确的。

你真的要好好学习一个。“协程的开销会比手动接管 callback 来的要高”，协程调度器的本质就是手动接管 callback，你还是不懂协程，唉。

如果你真的是 15 级本科生的话，真的不建议你出来误导人，你的道行还浅。水平低不可怕，出来误导人就是你的不对了。

五年前我还在上大学的时候就断言过“知乎是技术的荒漠”，这五年来一直在应验我这句话，很遗憾，v2 不是技术的荒漠，说错了容易被分分钟打脸。

归根到底，你要试着从技术的使用者的角度切换到技术的提供者的角度看待问题，这才是真正的技术进步之道。引用我很喜欢的一个大牛的话结束本次回复：水平和经验无关，大牛永远是大牛，如果不提高自己的知识水平，就算积累十年经验，也只是熟练的弱鸡。（况且你还没有实际经验，真的不建议你现在出来追求成就感，对你技术价值观的建立有害。）

@mashiro233 这个是你的博客吗？ https://2heng.xin/ 2015 级的商科本科生，技术爱好者？下一条回复我会一一驳斥你的观点。

这里不是你误导人的地方。

如果你想获得成就感，出门左转知乎谢谢，上面很多中学生，一定会对你五体投地的。

订正：
1. 需要上下文切换：将寄存器的内容暂存到内存。
2. 于是 DPDK 诞生了

统一回复：协程产生的目的是提高性能。

另外大家先站在 提供协程功能 的角度来看待协程：

Linux 下线程就是一堆共用内存的进程，需要上下文切换：将寄存器的内存暂存到内存。

当初为了解决 C10K 问题使用了 epoll，epoll 本质就是操作系统把自己的事件驱动功能下放到应用层的产物，自 kernel 2.5.44 引入。换个角度大家想想，操作系统本身就是事件驱动的。

事件驱动能力来自于 CPU 的 exception 机制，就是中断，正式中断这个 CPU 和 kernel 合作完成的功能提供的“多用户”能力，这里的多用户可以理解成三层：1. 系统进程和用户进程宏观上同时运行 2. 多个终端登录一台机器，宏观上同时使用这台机器 3. 多个进程宏观上同时运行。实际上我们知道一个 CPU 核心微观上在任一个时刻都只运行一个指令，本质还是图灵机，只不过简单的纸带换成了复杂的寄存器、一二三级缓存、内存的集合。

但是进程模型无法解决更新的需求。

1. Linux 标准线程占用的内存还是太大，理论上实现 C1000K 需要的内存过大，于是就需要一种能够占用更小内存的多任务调度方案，于是协程诞生了。
2. 当今顶级 x86 CPU 的性能已经爆棚，一块一万多的至强计算能力可以秒杀售价一百万的 40G 专业路由设备，为什么我们不能用至强来做呢，多省钱呀（实际上市面上有不少 DIY 的 x86 软路由，跑个 500Mbps 不成问题）。但是很遗憾，Linux kernel 的网络栈还是要依靠中断来调度，这就导致需要频繁地进行上下文切换：读写寄存器的内容到内存。而一次内存读写需要 70-90 ns，是无法实现 10Gbps 和 40Gbps 的网卡速度的，实测能跑到 2Gbps 就算不错了。于是 DPAK 诞生了：在用户态使用单线程的方式来阻止上下文切换，在驱动层面抛弃 kernel 的网络栈来自己实现，在单线程内部，自己构造协程调度器，等于自己又在图灵机模型下实现了一遍多任务调度，成功实现了高性能 SDN：软件定义网络。目前阿里云和腾讯云的自研高性能用户态 SDN 已经上线，已经创造很大的价值了。

自己手动实现协程是很麻烦的。人脑最容易理解的是同步，其次是上下文切换，而协程这种软件实时调度的纯异步是非常难以理解的，这才是协程最难的地方。

当然我对楼主表示同情，我也出现过初始化失败的情况，不过我发了工单很快就解决了。建议下次再遇到这种问题的时候，站在对方的角度想想，而且不要气到自己，不值得。必要的时候算算损失了自己几个小时的工资，就过去了。

@c3824363 哈哈，不是这样的哦，协程的编程异常复杂，进程才是符合人类思维的。

个人用户建议你们老老实实用超售的 VPS 吧，云服务真不是给你们用的。

大家以为云服务的目的是提高服务器利用率来获利，实际云服务是靠给小公司提供大公司才负担得起的平台部门研发的各种高级服务来获利的，再往底层看，云服务本质是云安全。

我赞了五楼，云服务是生产力工具，不是消费产品，服务商没有赔笑的义务。

这种问题应该给客服打电话让他们工程师手动处理，工程师操作就是一分钟的事儿，楼主你干嘛要对自己生气。

腾讯云？不要万不得已我是不会用的，无底线的促销，我可不想和一帮薅羊毛的人做邻居。那什么是到了万不得已？比如我司被腾讯收购了，就人在屋檐下不得不低头了。

写不出来的话，能一句话概括我也认。绝大多数人都不知道高性能服务器开发领域的协程概念。

能手写一个协程调度器我觉得就步入高手行列了，因为你要懂得 进程、线程 的概念和 Linux 的设计模型。

1386 的 extreme 确实是支持的，但是这个价格随便选一个其他品牌的都秒杀他。

@litp airport express 支持 5G，但是用的是 802.11n 协议。莫非你说的是时间胶囊？