[Feature Request][上游 Golang 已有实现][issue 重开] 允许HTTP/2使用明文传输 #1644

IceCodeNew · 2019-04-15T04:42:33Z

如题，希望 V2ray 的开发人员能重新考虑，把允许 HTTP/2 使用明文传输加到 TODO list 上。
之前已有同样的 issue，但是那个 issue 提得比较早，开发者以上游 Golang 还没有相关实现这个原因关闭了那个 issue。
现在我重新把 #975 这个 issue 打开，是因为 Golang 18 年合并的一个 CL 里已经实现了 h2c。

IceCodeNew · 2019-04-15T04:49:49Z

提出这个问题是因为我用 caddy 做 HTTP/2 反代已有半年之久了。注意到流量在 caddy 端解密以后重新加密发给后端的 V2ray 时性能损失很大。
以我个人的体验来说，在用 IDM 下载文件时会变得无法缓冲 YouTube 视频。我用 tcpdump 抓包以后确认了这里是性能瓶颈。
之所以没有改用 TCP 或者 WS 是因为我希望经过省级或者出口节点的时候的流量看起来是一个非常「标致」的 HTTP 流量，而且这样我也方便通过配置 caddy/nginx（假如 V2ray 支持 h2c 以后）来实现给每个用户限速这样的事。
所以对我来说 V2ray 的 HTTP2 是唯一的选择，而我希望它能有更好的性能表现，因此要辛苦一下开发者们了。

kslr · 2019-04-15T05:20:44Z

流量在 caddy 端解密以后重新加密发给后端的 V2ray

是什么意思？你指谁的加密？

IceCodeNew · 2019-04-15T06:17:44Z

开发者你好，感谢花时间阅读我的 issue。我拿实际的一段 Caddyfile 做例子解释好了：

v2.mydomain.tld {
    root /var/www/v2.mydomain.tld/
    proxy /path_for_v2 https://127.0.0.1:666666 {
        insecure_skip_verify
        header_upstream X-Forwarded-Proto "https"
        header_upstream Host "v2.mydomain.tld"
    }
}

v2.mydomain.tld/http_share {
    root /var/www/v2.mydomain.tld/http_share/
    basicauth / user password
    browse
}

在上面这段配置中，服务v2.mydomain.tld这个域名的服务器可能接收到两种流量对吧，唯一能够区分开它们的方法是解密 caddy 收到的流量然后看 path 究竟是什么。
假设这个流量的 path 是path_for_v2，那么这个流量在被 caddy 解密以后不就被转发给后端的 V2ray 了么。
而 V2ray 现在还不支持 h2c，所以我只能在 Caddyfile 中添加header_upstream X-Forwarded-Proto "https"这句话来把流量先重新加密以后再转发给 V2ray。
——这就是我所谓的「流量在 caddy 端解密以后重新加密发给后端的 V2ray」的意思。

上面的理论分析也许会出错，但是我实际抓包的结果证实了这一点：

Leo-Mu · 2019-04-15T15:48:43Z

这个 feature 可以说是急需的，特别是对于使用云服务的负载均衡器（Azure 或者 Google cloud）以及 CDN 的用户，因为负载均衡器和 CDN 是可以直接接管证书和 TSL 甚至 HTTP/2 、 QUIC 的，所以希望在客户端也能够支持像浏览器一样自动协商底层传输协议是 http1.1 还是 HTTP/2 QUIC 。相当于提供一个尽量简单、不占资源的 HTTP 类型的底层传输协议，再由客户端自动协商去负载均衡器的壳。
以及目前 WebSocket 是直接使用 WebSocket 连接的，与浏览器的 http 协商升级为 ws 不符，跟据谷歌云的表述，其只支持 WebSocket Upgrade request from an HTTP(S) client

LeXwDeX · 2019-04-17T01:39:45Z

这个 feature 可以说是急需的，特别是对于使用云服务的负载均衡器（Azure 或者 Google cloud）以及 CDN 的用户，因为负载均衡器和 CDN 是可以直接接管证书和 TSL 甚至 HTTP/2 、 QUIC 的，所以希望在客户端也能够支持像浏览器一样自动协商底层传输协议是 http1.1 还是 HTTP/2 QUIC 。相当于提供一个尽量简单、不占资源的 HTTP 类型的底层传输协议，再由客户端自动协商去负载均衡器的壳。
以及目前 WebSocket 是直接使用 WebSocket 连接的，与浏览器的 http 协商升级为 ws 不符，跟据谷歌云的表述，其只支持 WebSocket Upgrade request from an HTTP(S) client

负载均衡有4层TCP模式，可以用WS跑起来。

Leo-Mu · 2019-04-17T07:02:57Z

这个 feature 可以说是急需的，特别是对于使用云服务的负载均衡器（Azure 或者 Google cloud）以及 CDN 的用户，因为负载均衡器和 CDN 是可以直接接管证书和 TSL 甚至 HTTP/2 、 QUIC 的，所以希望在客户端也能够支持像浏览器一样自动协商底层传输协议是 http1.1 还是 HTTP/2 QUIC 。相当于提供一个尽量简单、不占资源的 HTTP 类型的底层传输协议，再由客户端自动协商去负载均衡器的壳。
以及目前 WebSocket 是直接使用 WebSocket 连接的，与浏览器的 http 协商升级为 ws 不符，跟据谷歌云的表述，其只支持 WebSocket Upgrade request from an HTTP(S) client

负载均衡有3层TCP模式，可以用WS跑起来。

的确，谷歌云的负载平衡器除了第 7 层 HTTP(S) 负载平衡之外还有第 4 层 TCP 负载平衡可用于支持 WebSocket 传输方式；以及第 4 层 UDP 负载平衡可用于支持 QUIC 传输方式，然而其灵活性会大打折扣，无法像 chrome 那样跟据网络条件在 TCP/UDP 之间自动切换。

如果 QUIC 握手失败（例如，如果UDP被阻止，或者服务器与 chrome 的 QUIC 版本不兼容），则 Chrome 会将 QUIC 标记为该主机已损坏 broken。任何正在进行的请求都将通过 TCP 重新发送。虽然 QUIC 被标记为主机已损坏，所以不会立即尝试 QUIC 连接了。5分钟后，损坏的连接将过期的 QUIC 标记为“最近破坏”。当向服务器发出下一个请求时，Chrome 又将继续让 TCP 和 QUIC 进行竞争。由于QUIC“最近被破坏”，因此将禁用 0-RTT 握手。如果握手再次失败，则 QUIC 将在此次再次标记为该连接已损坏 10 分钟，将 QUIC 标记为已损坏的前一周期的 2 倍，如此往后都会不断的标记为 2 倍。如果握手成功，请求将通过 QUIC 发送，QUIC 将不再标记为“最近损坏”。

并且我现在搞不明白 v2ray 客户端究竟是否支持 WebSocket2 over HTTP/2 ，在连接可用时尝试升级。

Leo-Mu · 2019-04-24T10:26:10Z

不知道 chrome 的 Network Stack 有没有像 V8 一样分离出来可以被调用？如果可以的话那网络传输协议的混淆就完美了。

IceCodeNew · 2019-04-27T11:17:12Z

楼上的朋友们你们偏题的有点过了。和本 Issue 无关的话题希望能另开 Issue 来讨论。
@Leo-Mu

ekenchan · 2019-05-06T09:32:33Z

@IceCodeNew 就算v2ray支持h2c，caddy目前还是不支持h2c proxy

IceCodeNew · 2019-05-07T07:46:08Z

@ekenchan 楼上这位朋友，前端作反代的为什么一定要是 Caddy 呢？我现在选择 Caddy 不过是因为只有 Caddy 才支持 HTTP/2 反代而已。
还有我认为你混淆了 Terminate SSL 和 h2c proxy，你提的这个问题我认为和实际我期望实现的架构完全不相关。

ekenchan · 2019-05-07T07:55:16Z

@IceCodeNew 我尝试过修改v2ray.com/core/transport/http/hub.go让它支持h2c，目前只有haproxy的tcp mode能够工作，在http mode下会退化成http/1.1请求后端的v2ray，这样就不能够通过path做分流。apache2还没试。

ekenchan · 2019-05-09T09:14:29Z

@IceCodeNew apache2的mod_proxy_http2转发h2c不能够工作，但nghttpx可以。如我所说，只要修改v2ray.com/core/transport/http/hub.go就可以，在没有配置tls的情况下，创建一个h2c server处理请求就可以，应该可以达到你的要求。

k79e · 2019-05-11T15:25:33Z

下载文件也走的代理?
你这个问题更像是堵塞控制.

IceCodeNew · 2019-05-17T08:15:37Z

@kxmp 这个不是 TCP 拥塞控制的问题谢谢。

IceCodeNew · 2019-05-17T08:17:49Z

@ekenchan 感谢测试，我其实提这个 issue 的时候就是打的 HAProxy 的算盘，nghttpx 不在考虑范围内。
我会参考你的经验试着自己修改 hub.go 文件来编译 v2ray 服务端的。
当然也希望官方能给这个 issue 提交相应的解决方案。很明显这不是我一个人希望的功能改进。

kslr · 2019-05-17T08:30:44Z

目前短时间内没有人来做这个事情，欢迎你提交PR

k79e · 2019-05-17T09:13:56Z

你下文件如果走的代理然后代理速度卡了就是通道内的网络堵塞了.
tls里面包裹的就是原封不动的流量 web不会去重加密.
你说的第二加密就是v2ray自己的加密这个肯定不会卡的.

IceCodeNew · 2019-05-18T07:41:04Z

@kxmp 老哥你真的理清楚了我这个场景的流程么……
v2ray客户端 -> caddy -> v2ray 服务端，你和我说第二次加密是 v2ray 服务端自己的加密，请问 v2ray 服务端加密了是要发给谁看？而且你怎么就说 v2ray 自己的加密肯定不会卡？请问你比较过 go 官方库加解密的性能和其他非 go 语言实现的加密库的性能吗？？
再请教你的第一段话，代理速度卡了就是通道内的网络堵塞了，请问这里的通道指的啥？是说出口带宽吗？如果是出口带宽的网络堵塞了那我在软件层面上几乎是无能为力的。如果是指的本机到代理之间的数据链路，那么我现在讨论的是服务器上从 nginx 反代到 v2ray 服务端的性能问题，你这里讲的东西就完全偏离话题了。
麻烦你再把你想说的话解释地清楚一些，谢谢。

k79e · 2019-05-19T05:09:35Z

v2自己的加密是当前H2模式要求的 ws没这要求.
当然是v2客户端和v2服务器之间的加密然后这个加密又套了一层tls 也就是web服务器的.
有什么不清楚么.

如果你说web还能再 重新加密 然后发给v2
敢问你这重加密给谁看的? 加密之后的东西没人能解密.
你的tls加密这个数据程序看来都是明文因为数据已经传递到了对端程序看到的都是已经解密过的数据.
所以就是原封不动的数据.

我说的通道是你代理有没有走v2.

@Leo-Mu ws可以走h2的我测试就开的h2的服务器. 但是有没有自动降级我就不清楚了. ws开了的话就必须加upgrade头否则还连不上了.

IceCodeNew · 2019-05-19T11:52:44Z

如果你说web还能再重新加密然后发给v2
敢问你这重加密给谁看的? 加密之后的东西没人能解密.
你的tls加密这个数据程序看来都是明文因为数据已经传递到了对端程序看到的都是已经解密过的数据.
所以就是原封不动的数据.

v2.mydomain.tld {
    root /var/www/v2.mydomain.tld/
    proxy /path_for_v2 https://127.0.0.1:666666 {
        insecure_skip_verify
        header_upstream X-Forwarded-Proto "https"
        header_upstream Host "v2.mydomain.tld"
    }
}

我们还是都不要脑补了，你和我不在一个频道上。
我就请问你为什么这里要写一句 insecure_skip_verify，不写就配不通。我觉得你把这个问题说清楚了就不会反驳说重新加密以后的东西没人能解密了。
你要是还觉得 caddy 到 v2ray 之间传输的是明文，那就请你看看我的抓包结果，然后告诉我 caddyfile 里面 header_upstream X-Forwarded-Proto "https" 这句话是干什么的。

我说的通道是你代理有没有走v2.

我下载文件和访问 YouTube 都是走的同一个代理。不然我就不会以下载文件的时候 YouTube 卡到无法加载来实际说明我对性能问题的体验了。

k79e · 2019-05-19T14:15:29Z

我从来没说v2客户端到v2服务器是明文
我说通道内数据是原封不动的.
X-Forwarded-Proto只是一个头部什么也不是.

可能我没描述明确
我就是说通道内的数据是原封不动的所以如果不是多层一层套一层这种情况
只要程序能收到数据成功读取他看起来都是明文一样的东西. 该是什么就是什么所以叫做原封不动的数据

我只是想说web是不会重加密的. 我要说的说完了你不信就算了.

你这个东西是你的事情啊我又没用过caddy
证书验证跟系统的根证书有关系而且你后端必须配置正确.
都没问题的话是绝对可以验证过去的.
你如果确信你没问题请到caddy他们那里去开issue.

IceCodeNew · 2019-05-19T19:31:08Z

X-Forwarded-Proto只是一个头部什么也不是.

没错，确实是这样。但我是怕你懒得去看抓包的内容所以想用一个实际跑得起来的 caddyfile 配置给你一个简单的证明，说明从 caddy 到 v2ray 服务端的内容是加了密的。

可能我没描述明确
我就是说通道内的数据是原封不动的所以如果不是多层一层套一层这种情况
只要程序能收到数据成功读取他看起来都是明文一样的东西. 该是什么就是什么所以叫做原封不动的数据

我说的通道是你代理有没有走v2.

都说了你和我不在一个频道上了，你看的始终是 v2ray 客户端 -> v2ray 服务端这样从起点直接飞到终点的路线，而我现在讨论的问题是路上的某一个具体环节（服务器端的从本地到本地，从 caddy 到 v2ray 的环节）
另外你如果要拿「程序能收到数据成功读取，看到的内容就是明文一样的东西」来证明「web 是不会重加密的」，那我觉得你干脆不如直接说 v2ray 也是不加密的好了。毕竟反代给 v2ray 的流量确实能被服务端收到并且成功读取（你说的只是读取哦，不需要 v2ray 能够对收到的数据进行解析或者处理不是么）

证书验证跟系统的根证书有关系而且你后端必须配置正确.
都没问题的话是绝对可以验证过去的.
你如果确信你没问题请到caddy他们那里去开issue.

就说了我这里是配通了的……你怎么又开始觉得我连代理都连不上了。

IceCodeNew · 2019-05-19T19:46:15Z

已知：

开启了 TLS 之后 path 参数是被加密的[1]。相信从客户端发出的请求到 caddy 这一段路上的流量是被 tls 加密了的 HTTP2 流量这一点没有人有疑问吧。
caddy 收到 SNI 是 mydomain.tld 的流量时，需要检查到底访问的是什么 Path。如果是根目录，那么就放一个 index.html 给用户看。如果是 /v2ray，那么就反代给 v2ray 服务端。

由 1&2 我们知道 caddy 自己一定要解开了 tls 以后才能看到原本的 HTTP2 流量到底想要访问什么 path

v2ray 目前不支持 h2c 流量，如果你硬要觉得 caddy 解密以后的流量是「原封不动」地发给 v2ray，也就是说这坨流量不再被 TLS 加密的话，欢迎阅读允许HTTP/2使用明文传输 #975

请附上出错时软件输出的错误日志。在 Linux 中，日志通常在 /var/log/v2ray/error.log 文件中。

Failed to start App|Proxyman|Inbound: failed to listen TCP on 10086 > Transport|Internet: failed to listen on address: [::1]:10086 > Transport|Internet|HTTP: TLS must be enabled for http transport.

—— v2ray 不认明文的 HTTP 流量欸，好奇怪哦（棒读

如果你觉得 caddy 发给 v2ray 的是没有被重新用 tls 加密，但是被 v2ray 自己设置的协议加密，所以不算是被重新加密而是自带两层加密……
这个说法很有道理不是么，外面一层是 tls，剥开以后里面是 vmess，tls 归 caddy 管，vmess 归 v2ray 自己管。
——还请阅读上面应用的服务器日志，看看 v2ray 要的究竟是 vmess 协议打包的数据还是 HTTP (HTTPS) 数据报文。

TLS must be enabled for http transport.

[1]. 圣经·《白话文配置指南》

k79e · 2019-05-20T04:24:59Z

对不起你要是再配置加密那就加密三次了 XD
我说的原封不动是原始数据又不是不加密
我一开始就说了这个h2要求加密
failed to listen TCP on 10086 > Transport|Internet: failed to listen on address: [::1]:10086 > Transport|Internet|HTTP: TLS must be enabled for http transport.
这个是众人皆知的你怎么好像在自言自语. 你是不是看不懂我在说什么.

你客户端的请求就是原封不动的数据这个就是tls (那是属于你v2ray发出去的流量然后另一个又是浏览器的流量你肯定搞不清楚这2个. 浏览器的包裹在web tls里面 v2ray的包裹在前面web tls里面) 浏览器自己的那个tls请求不算v2的因为谁都可以访问web服务器.
他是v2 client - v2 server 通过h2传输 h2自己的tls
这个v2的h2又要over web server
这个tls(web-v2)不是web的是web里面包裹的. 就是你看到的那个web的"重加密"
他不是重加密他就是原始的那个数据.
他的加密数据发送方是v2ray 而不是web. 当然web要主动找他协商.
就因为那个web走出来自己去找v2的这个连接就属于他该转发的数据当然是没修改过的所以就是原封不动的数据. 他转发的数据就是你v2ray客户端的那个请求毫无疑问是tls请求
tls请求又分不同应用很多层浏览器拉取url这是一方面 v2自己的又是另一方面.
浏览器走的那个url 属于http头部而v2ray的却属于报文. 这是两码事
你如果说你走tls请求然后web服务器都不知道url 对path一无所知那我只能没话说.
这地方你看不懂只能说明你对这个东西不熟悉.

反正你的115.2那个ip要是你的浏览器ip的话 你问题大了
caddy传输协议配置不正确. 所以会是sslv2 要不然就是抓包的bug识别错误了.

而 v2ray 只负责解开它特有的加密的话（也就是什么 aes-gsm-128），欢迎阅读 #975
根据v2现在的设计 h2模式必须走tls
必须走tls 就是v2特有的加密.(因为这种方式是v2规定的) 否则走h2c也没什么了.
你说的aes128gcm 是vmess的加密
在h2模式里面 h2传输这个地方要求开tls
所以是vmess over v2ray-http2-mode-with-tls-enabled (也就是说相当于v2的h2包了自己的vmess加密当然我推荐你关了这个如果你想要高性能)
所以你又走web相当于加密3次. 但是这个第三次只有路径的一半. 只有浏览器到web.
不会是web再到v2
如上所说 web-v2 的属于 v2ray自己的http2 也就是v2自己的tls.

你的疑问为什么加密后的path web能读取.
前面已经说了通道内的数据就相当于明文.
(相当于不代表等于如同不代表相等. 如露亦如幻不代表是露亦是幻) 就是原封不动的数据.
tls也叫http over tls 里面就是http 你说的这个东西是属于web的流量所以web当然能看见他.
v2能识别他就是因为报文内的数据. 这个报文根url请求头是两码事是不一样的.

k79e · 2019-05-20T04:30:59Z

@Leo-Mu 跑个题
ws模式就是有upgrade头部的就是客户端发送过去的.
所以google肯定可以用

2019-05-20 12:48:19
话说我也感觉h2c挺好的. 加密那么多次也真是浪费算力呢.(不过听说google他们都不打算支持这个 chrome浏览器都不会去支持h2c)

k79e · 2019-05-20T04:35:32Z

你这个问题跟我双图刷新第二个打不开很相似.
但是你这个无非就是 v2发包有问题 web发包有问题要不然就是你网有问题. 瞎猜也无非就是3个可能性
现在你没法证明到底哪里有问题 XD.

我也没法证明哪里有问题我当初用奸商的服务器测试了下发现这样.
自己测了下(本地开服) 也那样(这就是很奇怪了) 第二天又测不出来了
但是没添加延时测试.

你用多路复用了么用了的话关了试试.

2019-05-20 12:58:47
好了关于你说的重加密我不再争论你死不信也没办法啊. 你再怎么回复我也不会再说了.
可能你看见tls就以为是重加密但是是谁加密一般都说的是发送方. 谁发数据多谁就是加密方.(或者更精确的是直接去看证书用谁的证书就是谁的) 接收方更像是在一直解密加密的数据很少. 但是不绝对. 比如用网盘...
不过这个加密的确是相互的但是无论如何也不是web去加密他只是转发数据. 要加密也是v2客户端的事情.

但是你真认为这地方有问题的话. 那里面的流量直接就是v2客户端对v2服务器的. 这个地方其他人好像都没问题呢.

ekenchan · 2019-05-20T09:27:45Z

@IceCodeNew 你可以参考这种改法，写得不完美，只是示意
hub.tar.gz

IceCodeNew · 2019-05-20T11:40:43Z

@ekenchan 嗯，谢谢啦。
我之前还在说整个存储库里面好像就只有一个 v2ray-core/transport/internet/udp/hub.go，你说的修改是不是要另外增加一个文件才行。
今天打包的 tar 包结构算是确认了这个疑惑，感谢。
// 像这样子魔改项目还是第一次，作为一个没写过超过 10 行 Go 代码的垃圾来说还是挺迷茫的。

IceCodeNew · 2019-05-20T11:54:42Z

反正你的115.2那个ip要是你的浏览器ip的话你问题大了
caddy传输协议配置不正确. 所以会是sslv2 要不然就是抓包的bug识别错误了.

你这个问题跟我双图刷新第二个打不开很相似.
但是你这个无非就是 v2发包有问题 web发包有问题要不然就是你网有问题. 瞎猜也无非就是3个可能性
现在你没法证明到底哪里有问题 XD.

你是猴子请来的逗比吧，我抓包的流量都是过滤器筛下来的正常通信的流量，谁让你脑补那是 v2ray 无法解析的数据了。
还我问题大了……

IceCodeNew · 2019-05-20T12:01:24Z

这个是众人皆知的你怎么好像在自言自语. 你是不是看不懂我在说什么.

你看看你说的这句话：

(相当于不代表等于如同不代表相等. 如露亦如幻不代表是露亦是幻) 就是原封不动的数据.

你觉得你说的是人话？我凭什么来理解你和我打的禅机？？？

不然我们再来分析一个句子好了：

你客户端的请求就是原封不动的数据这个就是tls (那是属于你v2ray发出去的流量然后另一个又是浏览器的流量你肯定搞不清楚这2个. 浏览器的包裹在web tls里面 v2ray的包裹在前面web tls里面) 浏览器自己的那个tls

我们把括号注解丢掉来读一读短句啊：“你客户端的请求就是原封不动的数据这个就是tls浏览器自己的那个tls”

“原封不动”是我客户端的请求相对什么“原封不动”了？
tls浏览器是啥？

再来看后半句的”这个“，我姑且是以中文为母语的人，我判断这个“这个”似乎指代前半句的”原封不动的数据“、”客户端的请求“，那么我们就把这个指代关系带入后半句来看：

“客户端的请求”（这个）就是tls浏览器自己的那个tls

我请你说人话好吗？

IceCodeNew · 2019-05-20T12:12:27Z

你如果说你走tls请求然后web服务器都不知道url 对path一无所知那我只能没话说.

web 服务器并不需要一来就看清楚 url 的全貌，因为 http 报文里面有 SNI 这个字段，所以在前期的处理阶段里 web 服务器不需要知道 path，只要看 sni 就行了。
你如果真的觉得自己对这个阶段搞得很清楚，那我就拿流行的 web 应用服务器考考你好了：nginx 的七个处理阶段你给大家讲讲呗。
不然你说一下 web 服务器为什么一上来就要搞清楚 URL 包括 path 的部分好了（你以为 https 保护连接不保护 url 的吗？

IceCodeNew · 2019-07-12T12:34:17Z

感谢 @lucifer9 @xiaokangwang 等开发者的工作！

我在 v2ray/discussion 库下面新开了一个 issue #296，希望和所有关注这个问题的朋友们探讨如何调整 v2ray 和反向代理的配置来支持 h2c。

Leo-Mu mentioned this issue May 5, 2019

[Feature Request] 自动协商底层传输协议并实现 WebSocket Upgrade request #1675

Closed

lucifer9 mentioned this issue Jun 27, 2019

add server-side h2c support #1778

Closed

lucifer9 mentioned this issue Jul 5, 2019

add server side h2c support #1793

Merged

IceCodeNew mentioned this issue Jul 12, 2019

[v4.20+][已解决] 正确配置 caddy 等反向代理以和后端 v2ray 服务建立 h2c 连接 v2ray/discussion#296

Closed

kslr closed this as completed Jul 12, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Feature Request][上游 Golang 已有实现][issue 重开] 允许HTTP/2使用明文传输 #1644

[Feature Request][上游 Golang 已有实现][issue 重开] 允许HTTP/2使用明文传输 #1644

IceCodeNew commented Apr 15, 2019 •

edited

Loading

IceCodeNew commented Apr 15, 2019

kslr commented Apr 15, 2019

IceCodeNew commented Apr 15, 2019 •

edited

Loading

Leo-Mu commented Apr 15, 2019

LeXwDeX commented Apr 17, 2019 •

edited

Loading

Leo-Mu commented Apr 17, 2019

Leo-Mu commented Apr 24, 2019

IceCodeNew commented Apr 27, 2019

ekenchan commented May 6, 2019

IceCodeNew commented May 7, 2019

ekenchan commented May 7, 2019

ekenchan commented May 9, 2019

k79e commented May 11, 2019

IceCodeNew commented May 17, 2019

IceCodeNew commented May 17, 2019

kslr commented May 17, 2019 •

edited

Loading

k79e commented May 17, 2019

IceCodeNew commented May 18, 2019

k79e commented May 19, 2019 •

edited

Loading

IceCodeNew commented May 19, 2019 •

edited

Loading

k79e commented May 19, 2019 •

edited

Loading

IceCodeNew commented May 19, 2019

IceCodeNew commented May 19, 2019 •

edited

Loading

k79e commented May 20, 2019 •

edited

Loading

k79e commented May 20, 2019 •

edited

Loading

k79e commented May 20, 2019 •

edited

Loading

ekenchan commented May 20, 2019

IceCodeNew commented May 20, 2019

IceCodeNew commented May 20, 2019

IceCodeNew commented May 20, 2019

IceCodeNew commented May 20, 2019

IceCodeNew commented Jul 12, 2019

[Feature Request][上游 Golang 已有实现][issue 重开] 允许HTTP/2使用明文传输 #1644

[Feature Request][上游 Golang 已有实现][issue 重开] 允许HTTP/2使用明文传输 #1644

Comments

IceCodeNew commented Apr 15, 2019 • edited Loading

IceCodeNew commented Apr 15, 2019

kslr commented Apr 15, 2019

IceCodeNew commented Apr 15, 2019 • edited Loading

Leo-Mu commented Apr 15, 2019

LeXwDeX commented Apr 17, 2019 • edited Loading

Leo-Mu commented Apr 17, 2019

Leo-Mu commented Apr 24, 2019

IceCodeNew commented Apr 27, 2019

ekenchan commented May 6, 2019

IceCodeNew commented May 7, 2019

ekenchan commented May 7, 2019

ekenchan commented May 9, 2019

k79e commented May 11, 2019

IceCodeNew commented May 17, 2019

IceCodeNew commented May 17, 2019

kslr commented May 17, 2019 • edited Loading

k79e commented May 17, 2019

IceCodeNew commented May 18, 2019

k79e commented May 19, 2019 • edited Loading

IceCodeNew commented May 19, 2019 • edited Loading

k79e commented May 19, 2019 • edited Loading

IceCodeNew commented May 19, 2019

IceCodeNew commented May 19, 2019 • edited Loading

由 1&2 我们知道 caddy 自己一定要解开了 tls 以后才能看到原本的 HTTP2 流量到底想要访问什么 path

k79e commented May 20, 2019 • edited Loading

k79e commented May 20, 2019 • edited Loading

k79e commented May 20, 2019 • edited Loading

ekenchan commented May 20, 2019

IceCodeNew commented May 20, 2019

IceCodeNew commented May 20, 2019

IceCodeNew commented May 20, 2019

IceCodeNew commented May 20, 2019

IceCodeNew commented Jul 12, 2019

IceCodeNew commented Apr 15, 2019 •

edited

Loading

IceCodeNew commented Apr 15, 2019 •

edited

Loading

LeXwDeX commented Apr 17, 2019 •

edited

Loading

kslr commented May 17, 2019 •

edited

Loading

k79e commented May 19, 2019 •

edited

Loading

IceCodeNew commented May 19, 2019 •

edited

Loading

k79e commented May 19, 2019 •

edited

Loading

IceCodeNew commented May 19, 2019 •

edited

Loading

k79e commented May 20, 2019 •

edited

Loading

k79e commented May 20, 2019 •

edited

Loading

k79e commented May 20, 2019 •

edited

Loading