关于添加gRPC回落的具体探讨

[e1732a364fed]

举个例子，比如我是一个 山寨app的皮包公司，我的安卓app使用 gRPC连接我的服务器；同时我还想用我的服务器搭建私有
gRPC代理；我的想法是，打一枪换一个地方，比如使用月抛机，复制粘贴golang程序比部署 nginx配置文件快多了，因此我想用 v2ray回落，而不是nginx

皮包公司的想法：两个golang文件，一个皮包公司自己的app，一个v2ray，一个v2ray配置文件。

没有v2ray内置gRPC回落功能的办法：三个golang文件，皮包公司app，v2ray, caddy, l两个配置文件

此时，显然，回落加个grpc的servicename判断比较好

因该是不难的，毕竟gRPC的包是谷歌的，早就做好了。

总之，此discussion确定了 gRPC分流的非非必要性

比如，我是一个专门制作聊天app的皮包公司，使用gRPC，这个gRPC也不是我定的，我copy的其他开源聊天app源码里就用的gRPC；我的聊天app也许是非法的，所以我的素质很低下，根本不会配置什么nginx或者caddy，我希望配置文件越少越好。

我就是想利用这个聊天app作为我 科学上网的掩护，所以我同时在 v2ray中使用gRPC，并想按情况回落到我的聊天app。 那么回落的需求就来了。

为啥不用其它协议？有gRPC的优点啊。我说了这么多，为什么纠结gRPC，就是他延迟低，我喜欢

聊天app（外界可知的），浏览网页（我偷偷的用代理），都是需要延迟低，所以我这个假设正好对口

为啥不直接用 http/2 呢? 不过cdn, 现在这个形式，以后肯定越来越严，肯定首选能过cdn的。再说，根据我的假设，我的皮包公司可能是非法的，所以被墙可能性也是很高的。（以上纯假设，我没皮包公司）根据国家规定，聊天app需要审查，所以确实很难合法搞一个聊天app

http/2 也能过，只是从 cdn 到服务器是 http/1.1, 那就还是没低延迟优势了

[e1732a364fed]

关于 gRPC 和 cdn以及回源，我的笔记：

根据下面文章，http2理论上果然也是可以被cdn转发的, 但是 cloudflare回源是1.1，所以没法转发h2
https://guide.v2fly.org/advanced/h2_tls_web.html

果然cloudflare文档里说，cloudflare到 源站这一段 用的是 http1.1

https://support.cloudflare.com/hc/en-us/articles/200168076-Understanding-Cloudflare-HTTP-2-and-HTTP-3-Support

https://support.cloudflare.com/hc/zh-cn/articles/200168076-%E4%BA%86%E8%A7%A3-Cloudflare-HTTP-2-%E5%92%8C-HTTP-3-%E6%94%AF%E6%8C%81

This article is in reference to eyeball requests (connections from clients to Cloudflare's Edge). Connections from Cloudflare's Edge to your origin server(s) only support HTTP/1.1.

但是我就不懂了，如果回源只是http1.1, 那它是怎么转发 gRPC流量的？ gRPC不是强制 h2吗、

根据cloudflare官方博客
https://blog.cloudflare.com/zh-cn/road-to-grpc-zh-cn/

原来，cloudflare将 gRPC的 h2流量 转换成了 h1.1 流量 发送到源站

我们找到了一个比较好的办法：在内部网络中将 gRPC 消息转换为不含尾部的 HTTP/1.1 消息，然后在请求发送到源站之前将转换回 HTTP/2

我们不必自己发明格式，gRPC 社区已经开发了一种 HTTP/1.1 兼容版本：gRPC-web。gRPC-web 是对基于 HTTP/2 的原始 gRPC 规范的修改。最初目的是与不能直接访问 HTTP/2 帧的 Web 浏览器搭配

再根据
https://blog.cloudflare.com/announcing-grpc/

Adding support to establish HTTP/2 connections to customer origins for gRPC traffic, allowing gRPC to be proxied through our edge. HTTP/2 to origin support is currently limited to gRPC traffic, though we expect to expand the scope of traffic proxied back to origin over HTTP/2 soon

也就是说，如果源站是 http2的，则 cloudflare 会直接用 http2来访问 源站，但是这个仅限于 gRPC；普通的 http2连接是不行的。

这个问题的回答也证实了：

https://community.cloudflare.com/t/is-traffic-between-cloudflare-and-origin-server-http-2/255471/2

(traffic between Cloudflare and Origin server is ) HTTP/1, unless you’re proxying gRPC.

[ksdakcnsa]

我配置了trojan+grpc+cdn，回落到本机nginx监听的h2网站。按照
https://support.cloudflare.com/hc/zh-cn/articles/200168076-%E4%BA%86%E8%A7%A3-Cloudflare-HTTP-2-%E5%92%8C-HTTP-3-%E6%94%AF%E6%8C%81，
在浏览器中访问服务器443端口时，确实是回落到了h2网站，并且cdn到源站确实是h2协议。但神奇的是，在没有cdn的情况下，trojan+grpc在对远程的speedtest服务器测速时，带宽基本上是trojan+tcp+tls的一半，而加了cdn之后，带宽居然和tcp基本一致。请问这是因为什么？是trojan的协议的grpc数据在cdn发到源站的时候被转发为了h1.1，所以提高了带宽吗？

[SakuraSakuraSakuraChan]

我配置了trojan+grpc+cdn，回落到本机nginx监听的h2网站。按照 https://support.cloudflare.com/hc/zh-cn/articles/200168076-%E4%BA%86%E8%A7%A3-Cloudflare-HTTP-2-%E5%92%8C-HTTP-3-%E6%94%AF%E6%8C%81， 在浏览器中访问服务器443端口时，确实是回落到了h2网站，并且cdn到源站确实是h2协议。但神奇的是，在没有cdn的情况下，trojan+grpc在对远程的speedtest服务器测速时，带宽基本上是trojan+tcp+tls的一半，而加了cdn之后，带宽居然和tcp基本一致。请问这是因为什么？是trojan的协议的grpc数据在cdn发到源站的时候被转发为了h1.1，所以提高了带宽吗？

你源站不要接收1.1然后再测下不就知道了

[e1732a364fed]

在verysimple v1.2.0 版本 中，grpcSimple 已经支持了grpc 回落 到 h2c。