为什么套用 cloudflare grpc 会断流?

[MuenYu]

向 Cloudflare Edge 添加 gRPC 支持
既然 gRPC 使用 HTTP/2，原生支持 gRPC 听起来不难，因为 Cloudflare 已经支持 HTTP/2 了。但是，我们有两个问题：

1. 我们的边缘代理不完全支持 HTTP 请求/响应尾部标头：Cloudflare 使用 NGINX 接受来自用户端的流量，并且对尾部的支持有限。让情况更加复杂的是，穿过 Cloudflare 的请求和响应还需要经过一系列其他代理。
   HTTP/2 至源站：我们的边缘代理使用 HTTP/1.1 从源站获取对象（无论是动态还是静态对象）。要代理 gRPC 流量，我们需要支持使用 HTTP/2 与客户 gRPC 源站连接。
2. gRPC 流式传输需要允许双向请求/响应流：gRPC 有两种类型的协议流；其一是一元的，即简单的请求和响应，其二是流式传输，允许各个方向上不间断的数据流。为了全面支持流式传输，需要在另一端接收到响应标头之后发送 HTTP 消息正文。例如，流式传输客户端将在接收到响应标头之后持续发送请求正文。

出于这些原因，gRPC 请求通过我们的网络代理时会中断。为克服这些限制，我们研究了各种各样的解决方案。例如，NGINX 具有一个 gRPC 上游模块，可支持 HTTP/2 gRPC 源站，但它是一个单独的模块，而且还需要 HTTP/2 下游，不能用于我们的服务，因为请求在某些情况下会穿过多个 HTTP 代理。由于内部负载平衡架构的关系，而且确保所有内部流量都使用 HTTP/2 将花费太多精力，因此在管道的每一处全部使用 HTTP/2 是不现实的。

原文链接

此处做个记录, 方便查阅和讨论.

[33lyl]

我这边测试，好像不用也会断

[niclau]

我这天从websocket更换到grpc同样发现这个问题，配置文件只修改了websocket->grpc的相关区域。
下载大于100MB的文件必断，不套cf倒是十分正常，无奈，只好换回websocket。

[Info] [1419390714] proxy/vmess/inbound: received request for tcp:dl.google.com:443
[Info] [1419390714] app/dispatcher: default route for tcp:dl.google.com:443
[Info] [1419390714] proxy/freedom: opening connection to tcp:dl.google.com:443
[Info] [1419390714] transport/internet/tcp: dialing TCP to tcp:dl.google.com:443
[Info] [1419390714] app/proxyman/inbound: connection ends > proxy/vmess/inbound: connection ends > proxy/vmess/inbound: failed to transfer request > transport/internet/grpc/encoding: unable to read from gun tunnel > rpc error: code = Canceled desc = context canceled
[Info] [1419390714] app/proxyman/outbound: failed to process outbound traffic > proxy/freedom: connection ends > context canceled

[Granzort47]

有办法解决吗

[MuenYu]

已经解决了，见 文档

[niclau]

已经解决了，见 文档

现在感觉vmess和vless用起来速度区别也不大，vless自身不加密，而且套cdn后数据对cdn应该是明文的?

[CrazyBoyFeng]

cf+grpc断流的解决方法是不是把initial_windows_size设为512k？
这是什么原理？

[33lyl]

好像已经修复了，v2ray的， 在 2022-08-12 19:27:43，"狂男风" ***@***.***> 写道： cf+grpc断流的解决方法是不是把initial_windows_size设为524288？ 另外这个补丁目前是否只适用于xray？ — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[Granzort47]

我v2ray没更新 但是不断流了 怀疑是CF的问题 然后他们自己修好了

[CrazyBoyFeng]

你使用了nginx或者类似的反向代理工具吗？如果有的话，请问是怎么配置的？（注意隐藏你的路径和url）

[33lyl]

恩，我前面是用ng啊，ng支持grpc_pass呀 在 2022-08-24 21:45:02，"狂男风" ***@***.***> 写道： 你使用了nginx或者类似的反向代理工具吗？如果有的话，请问是怎么配置的？（注意隐藏你的路径和url） — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[33lyl]

也有可能就是 在 2022-08-24 19:34:15，"anon755" ***@***.***> 写道： 我v2ray没更新 但是不断流了 怀疑是CF的问题 然后他们自己修好了 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[ChainZeaxion]

我是大概一年多以前配的，一直没用
最近测了一下，感觉grpc挺好用啊
也没有什么断流一说
整个反应和有效带宽确实很不错
目测是比v2ws和tr-go-ws快的多
应该是缩短三分之一左右反应
提升15%左右有效带宽，降低了20%左右丢包

[33lyl]

我觉得比ws的快 在 2022-10-17 01:38:06，"ChainZeaxion" ***@***.***> 写道： 我是大概一年多以前配的，一直没用 最近测了一下，感觉grpc挺好用啊 也没有什么断流一说 整个反应和有效带宽确实很不错 目测是比v2ws和tr-go-ws快的多 应该是缩短三分之一左右反应 提升15%左右有效带宽，降低了20%左右丢包 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[Pacio]

grpc主要是测速比较低，但是实际使用体验更好

[33lyl]

比较稳定是不是？ 在 2022-12-29 21:19:58，"Pacio" ***@***.***> 写道： grpc主要是测速比较低，但是实际使用体验更好 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>