HTTP1.1 还好吧，简单的协议。HTTP2 、HTTP3 得找其他轮子了

@ysc3839 噢，不对，我看错了。应该这样说：类似回调函数的实现，但因为多做了一些事，导致性能要差很多

@ysc3839 这个看起来像是，因为没有需要等待的东西，所以被编译器优化成了普通回调

@FrankHB 我用 c 艹 20 的东西不是因为我特别喜欢新特性，主要原因是我非常喜欢 c#的 await 语法，迫不及待想在 c 艹里用而已。毕竟对于 c 艹来说，能像 c#一样简单的开发异步程序是一件很有意思的事

@Calatrava 好吧。这个我后面加上

@FrankHB 1 、你上面说的是对的，所以 u8string 之类的难用或者不稳定的特性我都没用到，新特性里我只用到了 co_await
2 、beast 不好用，我是想一行 co_await 就能发起请求，beast 只能说，挺规范的
3 、作为个人开发者我没法保证任何情况都能积极维护。用的人少就不说了，用的人多了，像 duilib 那样，就算作者不维护其实也能开枝散叶

@Calatrava 你说的有道理，不过你见过哪个流行的库有做 dns 缓存的嘛？这个需求非常个性化，只能用户自己处理。libcurl 、asio 、libev/uv/hv 等等不都没做。不做这个不代表局限于 demo ，而是给用户自由发挥流有余地

@wanguorui123 c 艹 20 有 co_await

@hankai17 很难回答。使用不同品牌 cpu 、编译为不同指令集、不同编译器的不同优化等级，估计对这个都会有影响。你可以看看这个，对原理说的很详细。http://purecpp.org/detail?id=2288 。我个人看法，效率就是 O(1)，因此忽略性能问题（狗头

@ysc3839 你说的是底下一层，这层的做法不兼容；我说的是顶上一层，这层的做法就兼容。让我选做法我会选择最简单通用的方式。

@ysc3839 c 艹、c#、python 回调转异步做法是，创建原子信号量然后异步等待，同步回调里设置信号。异步等待任务收到信号后恢复执行

@ysc3839 所以这就是实现方式的不同咯。实际用户体验一致，比如 c 艹异步代码迁移到 python ，需要做的也是语法变为 python ，co_await 改为 await ，不会说换一种逻辑去实现

@forcecharlie 截止 c 艹 20 前没任何标准，这也是 c 艹标准委员会效率低下的体现。但大家并没减少 c 艹开发网络程序，都开始尝试用三方库去做网络。go 和 c 艹不完全对标，没有可比性。rust 的话，相比 c 艹 03 及以前具有极大优势，但对于 c 艹 20 及以后版本，难说。

@ysc3839 其实所有语言的 stackless 都是一样的，实现都是状态机+线程池管理异步任务，区别只有底层实现的代码不同、用起来给人感觉不同。对其他语言来说，我不是深度体验用户（因此对这个议题具有比较强的主观看法），不过你可以参考我以前写的一个库的源码，https://github.com/fawdlstty/SMLite ，里面有 js 和 python 的异步实现（ c 艹的还没写进去）

@janus77 没有。看了下，也和 http 没啥关系吧

@ysc3839 想要实现 co_await 等待首先就必须得有一个线程池。我这儿是写死的一个线程池就一个线程。其实也可以多个

@FrankHB 1 、co_await 确实是半成品，直接用确实存在你说的那个问题，但我不是直接用，我用的 boost.asio ，如果这个库也存在你说的问题，那说明你用错了
2 、co_await 作为半成品的原因是，只提供了语法支持，需要自己造 awaitable 对象，c 艹 23 将在标准库引入 awaitable 对象，这代表老的 awaitable 也能继续用，因此升级也不会火葬场。即使库中的 awaitable 全体升级到 c 艹标准的 awaitable 对象，也能 ide 里全局字符串替换，几乎不会有啥问题
3 、任何技术都不可能 100%让所有人满意。我做这个初衷也不是为了在所有场合都能使用，至少，c 艹 17 及之前版本不能用。我做这个库的目的是为了方便实现 co_await 方式去等待 http 响应

@Danswerme c 艹 20 是不是很简单，和 js 一样（狗头

c 艹语法进步了，c 艹原本的库还没能更新呢，一堆库全同步或者回调的用法，标准出来等了两年多了都还没啥好用的库，这都 2202 年了