hyb
> 建议直接只用cronet cronet 似乎只有h3接口, 没有裸udp协议。
> 请问是把chromium base库裁掉了吗？直接使用的libc++吗？ 看源码是的
这个剪裁更简洁 对源码几乎无改动 [webtransport ](https://github.com/fails-components/webtransport)
测试受限于cpu性能, 我在9700上ping-pong跑大概540-600MB/s. tcp可以到1800MB
专门高度优化后的demo测试quic性能. 性能差距主要发包(sendto. sendmmg) 还有部分在gquic协议栈.
> > 测试受限于cpu性能, 我在9700上ping-pong跑大概540-600MB/s. tcp可以到1800MB > > 请问下这个500MB/s是怎么测试的呢，用QUIC做代理统计有效流量还是网卡上传输UDP传输数据包流量？什么条件下测试的呢，一个connection下的一个stream？ 自己写的quic客户端和服务器demo，带宽统计有效stream载荷数据，一个连接一个流（多流不能提升ping-pong性能） 服务器绑定127.0.0.1, 客户端连上后预先发送10-1000KB数据(握手协商关闭加密功能)，服务器收到直接发回客户端 编译优化开了LTO和PGO，使用GCC10.3 和Ubutun 20.04(win WSL2)。 为了提升性能做了聚合回包（sendmmsg/gso）之类的大量性能优化。
经过多年持续度gquic 性能极致优化（基于2023.05版本quiche），剪裁部分功能， 在win10 + wsl2 + 12700 cpu，ping-pong测试能跑出1GB+的带宽性能，单核心处理（收+发）80万+个 quic数据包。 应用层cpu从45%降到25%， 后续打算优化系统cpu， 如果配合DPDK，估计cpu性能还能提升一倍以上 ``` Statics:1118 [C=10001] 1 ep_fd/last_udp = 1/3, active_udps, udps = 1, 1 tid = 19: client send_batch:1 Statics:1121...
quiche底层的核心数据基本都被换成高性能的数据结构（small vector/map/set/list/hash）. 原来使用的absl系列容器并不适合的小数据集合。 时间和定时器开销不小，采用极致的优化方法减少了大量的不必要的高频调用（90%） gcov 测试各种分支覆盖情况，改进if 判断语句（收发报文核心路径删除大约20% if 语句，去除不常用的部分功能） 大量防御代码基本都被删除了（需要进行大量功能性和稳定性测试,） 最好是内存优化，改进后正常的收发报文过程中不再有动态内存分配。 配合perf+lto 最后分析瓶颈， 都是代码细节问题。**密切关注核心路径的每一行代码副作用**
I only use google quiche in my projcet. from my benchmark it can reach 520MB/s in my pc intel 9700. the benchmark client/server is a simple single-thread ping-pong without using...