Futures 和 Tokio 项目的前世今生_rust tokio开发人员-CSDN博客

用Rust搞网络相关，一般是绕不开这两个库的。这里尝试简单介绍一下它们的历史。

？？~2016：原点

最初的时候。

首先futures是一套trait，也是异步操作的基本API。这个库是官方成员alexcrichton开发的。

然后是另一个叫做mio的库。mio是跨(桌面)平台的非阻塞IO API的封装，主要是 EventLoop实现(分别会使用epoll, kqueue, iocp)和其他一些Tcp、Udp的原语。这个库是carllerche开发的，他不是官方成员。但是这个项目是受到官方支持的。所以可以看作半官方项目。

好了，然后接下来就是futures和mio的整合了。因为futures只有trait，而mio是不依赖于futures的，所以需要一个库把它们整合在一起。这个库的名字叫futures_mio，是alexcrichton和carllerche两个人维护的。后来官方开始越来越重视这个，这个成为了官方支持的社区项目，可以看作是半官方项目，并把它列入到2017年的年度计划里，这是后话了。

2016~2017：Tokio 计划

2016年8月的时候，futures_mio 这个库也换了一个更响亮的名字，叫做tokio。tokio依赖futures和mio。tokio的计划是一整套异步支持的设施。这里面没有一个crate叫tokio。（tokio这个名字被预留了但是里面没有内容。）核心组件是tokio-core。并在上面有tokio-io, tokio-timer, tokio-proto等等。

tokio-core 里最重要的东西就是一个名叫Core的类型，它既是reactor又是executor。上层应用把用futures 接口表述的任务交给它，由它来调度执行。这是一个单线程的模型。在tokio-core的基础上，各种上层应用也纷纷尝试迁移过来获得异步支持，整个系统蓬勃地发展了起来。比如hyper（HTTP库），以及建筑在hyper之上的各种web框架。

试用了一段时间之后，大家一方面对它的本身的性能是满意的（参见几次techempower举办的 benchmark)，另一方面在易用性上对tokio系统有很多不满意之处。首先它是那种基于回调的组合（参见使用老版本ES 的Nodejs），并且在调试的时候逻辑会跳来跳去。所以写起来，调试起来都不够好。其次，tokio-proto，这个tokio的上层设施（FramedCodec，Transport等），成为了彻底的鸡肋。

于是勤劳的alexcrichton又被安排以宏的形式实现了一个futures-await库，它可以让你标注一些async和await，以同步形式的代码来表述异步逻辑。这个大家应该都不陌生，其他语言很多也都有。【C++还没有，但是也快了。】实验进展的还是比较顺利的，不过这个必须要用nightly版本的rust编译器才能用。

积累了这些经验，在2017年末，官方又做了一个艰难的决定，搞了一个大新闻。