与 quinn 相比 这个项目有什么独特的优势嘛？

[lmmqxyx404]

就目前我看到的而言，似乎就架构层面上似乎比 quinn 更细？

[huster-zhangpeng]

首先，gm-quic 是从一开始就是采用异步 Rust 设计的，在这种设计下各模块能够做的更加精细、独立、解耦；quinn 一开始则是多线程的基础上做起来的，它内部的 drive 驱动可谓相当复杂，它提供的上层异步接口也像是个临时可用版本，非异步加上复杂的 drive 扫描驱动模式，也致使 quinn 性能不佳。

接着看模块设计，通过异步解耦，gm-quic 的结构定义、接口保留了大部分原汁原味的 RFC 中描述的味道，比如 ErrorKind 定义，没有额外增加自定义的错误，因为 RFC 已经定义的很周全了；再比如 stream 的状态转换，几乎保留了 RFC 中原汁原味的状态机风格，语义更加清晰。这些意味着更符合标准，更不容易出错。我们希望 RFC 上的每一个概念，都能在 gm-quic 的代码中有不偏不倚的体现，所以本项目对于熟悉 quic 协议、了解异步 Rust 的写法也有很高的学习价值。

然后，我们在对比测试各家 quic 实现时，发现 quinn 是相当不稳定的一个实现，失败率偏高，稳定性、性能均排名倒数。参考小红书刚开源的网关，就因此没使用 quinn。gm-quic 项目更新，功能也会更加完善。

再者，在应用层接口设计上，无论是客户端还是服务端的， gm-quic 都更语义化，更加易用。比如，对上层应用而言的 Stream 的 API 则直接是实现了标准的 AsyncRead、AsyncWrite trait，保持着良好的接口通用性。在 Rust 常见的套娃结构或者深层次关联类型 trait 绑定上，与接口的方便理解上，有着良好的平衡。

最后，gm-quic 未来规划上，将会实现更丰富的扩展，比如 qlog 都实现到了 0.9，以致于 qvis 还只支持到 0.3。

quic 协议很新，有很广阔的应用价值，欢迎大家一起学习交流～

[matheus23]

Nice to see more effort being put into finding good architectures for async rust QUIC implementations.
I want to point out that quinn does indeed implement AsyncRead and AsyncWrite for their streams though.

[spongebob888]

这个支持multipath， quinn不支持，还是蛮有吸引力的

[matheus23]

Can you tell me more about what you mean by multipath? Are you referring to https://multipath-quic.org/ ?

Looking at the source, I can't see any reference to frame types such as PATH_AVAILABLE or PATH_BACKUP, which is a baseline requirement for a multipath implementation.

There is support for multiple paths, conceptually, but this only provides the framework without implementing it fully yet, as far as I understand.