关于grpc的高丢包网络环境下测速慢的疑问？

[moranno]

在丢包率在20%的网络环境下：trojan grpc和trojan tcp的测速对比。
多线程：

单线程：

请问下作者，关于这个网络环境下为何grpc的网速会慢那么多？

另外期待继续更新本项目。

[bash99]

grpc似乎就是这个特征。我用其它项目(xray)的grpc碰上网络糟糕时（不单纯是高丢包），也是非常容易卡死。

另外你的trojan开启smux了吗？如果没开，能否帮忙测试trojan开smux和不开smux，在grpc很糟时的效果。

[moranno]

我的trojan没开smux，我估计开了smux的结果会和grpc很类似，因为多路复用要维持链接状态，消耗的资源要比普通的多。
如果你有结论记得在这里分享。

[bash99]

我的trojan没开smux，我估计开了smux的结果会和grpc很类似，因为多路复用要维持链接状态，消耗的资源要比普通的多。 如果你有结论记得在这里分享。

我这边没有特别稳定慢的vps，只好反复多次测，挑了一个丢包高一点的vps，下载速度。
trojan：30~35 Mbps
trojan-mux: 0.5 ~ 20 Mbps
trojan-grpc: 0.3 ~ 25 Mbps

单纯上面没法判断grpc和smux谁好，不过都够差。

总之丢包高网络差时下限trojan高很多；不过网络好时 mux/grpc的页面打开速度还是明显快一点，直接单个请求测延时也是快很多的。
我拿curl命令行测单个请求延时：

 curl  -w "%{time_total}\n" --proxy localhost:10268 -s google.com/ncr

[moranno]

我的trojan没开smux，我估计开了smux的结果会和grpc很类似，因为多路复用要维持链接状态，消耗的资源要比普通的多。 如果你有结论记得在这里分享。

我这边没有特别稳定慢的vps，只好反复多次测，挑了一个丢包高一点的vps，下载速度。 trojan：30~35 Mbps trojan-mux: 0.5 ~ 20 Mbps trojan-grpc: 0.3 ~ 25 Mbps

单纯上面没法判断grpc和smux谁好，不过都够差。

总之丢包高网络差时下限trojan高很多；不过网络好时 mux/grpc的页面打开速度还是明显快一点，直接单个请求测延时也是快很多的。 我拿curl命令行测单个请求延时：

 curl  -w "%{time_total}\n" --proxy localhost:10268 -s google.com/ncr

感谢分享，请问你上面的测试是使用本作的grpc吗？因为我看到作者在文档中有写：

根据用户反映，本作的grpc比xray的快多了。
如果你的线路不好，那么可能多个tcp链接会显得很卡，此时grpc则特别好用。

但似乎实际体验是相违背的。

我之前的经验是基于xray的trojan GRPC，在晚高峰的时候经常出现连不上的情况（连接断开，浏览器显示“该页无法显示”，多次刷新后可以打开）不知道是grpc断流还是被GFW阻断？

而默认的trojan TCP好像不会（等我再详细测试下）

---

另外grpc还有个最大的劣势，因为会保持长连接和多路复用，所以当有多台服务器做负载均衡，多线程的TCP应用不会连接到多台服务器做负载均衡。所以grpc可能天然不适合做负载均衡。不知道未来的QUIC在这方面会不会更有优势？

还有，我觉得grpc的多路复用应该优于trojan的smux。

[bash99]

感谢分享，请问你上面的测试是使用本作的grpc吗？因为我看到作者在文档中有写：

嗯，模式是 caddy -> grpc -> verysimple，不知道直连会不会有优势。
这个模式下和 caddy -> grpc -> xray 差异不大。

他也提到 ”grpc可能只适合优质网络。“

[bash99]

还有，我觉得grpc的多路复用应该优于trojan的smux。

这些多路复用，除非用上连接池（比如grpc的pool）并且主动判别心跳失败，我感觉差异不会太大。
都会被TCP的Head of Line blocking问题困扰，也就是一个tcp窗口内的包完了，首包还没收到，那就会触发完全停止发包，等待这个包重传。
如果丢包率不是特别高，不出现上述情况，就能省一些握手。

普通trojan是多次握手多个链接，互相不影响，反而不太受限制。

彻底解决可能还是得quic之类的协议。

[moranno]

还有，我觉得grpc的多路复用应该优于trojan的smux。

这些多路复用，除非用上连接池（比如grpc的pool）并且主动判别心跳失败，我感觉差异不会太大。 都会被TCP的Head of Line blocking问题困扰，也就是一个tcp窗口内的包完了，首包还没收到，那就会触发完全停止发包，等待这个包重传。 如果丢包率不是特别高，不出现上述情况，就能省一些握手。

普通trojan是多次握手多个链接，互相不影响，反而不太受限制。

彻底解决可能还是得quic之类的协议。

是啊，我也觉得可能quic才是未来，这是我最近的发现：XTLS/Xray-core#975 (comment)

[e1732a364fed]

grpc在搞丢包情况下就是这么水，因为它是多路复用的。

不像quic，quic是可以设置路数的，grpc好像不能吧，时间有点长忘了。确实，这时就用quic吧。

[moranno]

我的trojan没开smux，我估计开了smux的结果会和grpc很类似，因为多路复用要维持链接状态，消耗的资源要比普通的多。 如果你有结论记得在这里分享。

我这边没有特别稳定慢的vps，只好反复多次测，挑了一个丢包高一点的vps，下载速度。 trojan：30~35 Mbps trojan-mux: 0.5 ~ 20 Mbps trojan-grpc: 0.3 ~ 25 Mbps

单纯上面没法判断grpc和smux谁好，不过都够差。

总之丢包高网络差时下限trojan高很多；不过网络好时 mux/grpc的页面打开速度还是明显快一点，直接单个请求测延时也是快很多的。 我拿curl命令行测单个请求延时：

 curl  -w "%{time_total}\n" --proxy localhost:10268 -s google.com/ncr

我想了下smux可以设置最大tcp链接数，把这个数值调高（比如5-10左右）会不会增加smux的速度？普通tcp随便发起20-30个链接。
grpc不能调整tcp链接数，从流量监控来grpc最多只有2个链接。

不知道你有没有做过增加链接数的速度测试？

[bash99]

我想了下smux可以设置最大tcp链接数，把这个数值调高（比如5-10左右）会不会增加smux的速度？普通tcp随便发起20-30个链接。 grpc不能调整tcp链接数，从流量监控来grpc最多只有2个链接。

不知道你有没有做过增加链接数的速度测试？

trojan-go的smux缺省似乎是8个链接，碰到高丢包也是一样挂。

而且增加链接数增加了首次访问延时，而且也暴露了很多特征。