v2ray / v2ray-core

A platform for building proxies to bypass network restrictions.
https://www.v2ray.com/
MIT License
45.41k stars 8.95k forks source link

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

Closed Leo-Mu closed 3 years ago

Leo-Mu commented 5 years ago

对于使用云服务的负载均衡器(Azure 或者 Google cloud)以及 CDN 的用户,因为负载均衡器和 CDN 是可以直接接管证书和 TSL 甚至 HTTP/2 、 QUIC 的,所以希望 v2ray 作为客户端使用时也能够支持像浏览器一样自动协商底层传输协议是 HTTP 1.1 还是 HTTP/2 或 QUIC 。相当于在入站协议上提供一个尽量简单、不占资源的 HTTP 类型的底层传输协议,如 #1644 所需求的,再由客户端在出站协议上与负载均衡器自动协商。当然如果入站协议也能够提供一个支持多版本协商的 HTTP 底层传输协议那也再好不过。 以及目前 WebSocket 是直接使用 WebSocket 连接的,与浏览器的 HTTP 协商升级为 ws 的行为有所不同,跟据谷歌云的表述,其只支持 WebSocket Upgrade request from an HTTP(S) client 例如 chrome 可以跟据网络条件在 TCP/UDP 以及各代 HTTP 协议版本之间自动切换。

如果 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 和 WebSocket over QUIC 并在连接可用时尝试升级进行说明。

以及 chrome 的 Network Stack 有没有像 V8 一样分离出来可以被调用?如果可以的话那网络传输协议的智能协商和切换以及模仿浏览器行为的混淆就完美了!

Xyncgas commented 5 years ago

你想要像浏览器一样upgrade to websocket可以用apache nginx等配合v2ray, v2ray已经做到了能够http一来一往以后升级到websocket, http2 标准没有Upgrade to websocket

neco91998 commented 5 years ago

顶!!这样就可以使用很多CDN了,因为大多数CDN不支持ws或者HTTP/2回源

k79e commented 5 years ago

浏览器好像不会自动协商把. http转https都是服务器做的跳转啊.

你放心好了v2的ws规范的不得了 cdn随便用. 反正他流量是有那个upgrade头 cdn认识就够了 我这个回复就是走的cdn反代ws 那个cdn https默认就是h2 所以你应该没啥疑问了吧.

v2直接直连 ws模式都有upgrade头的. 不是你说的直接就跟http一样 没upgrade头部. 反代甚至你不给他插入upgrade头部 v2都不认 根本连不上. (因为反代不知道流量类型 所以要人工指定 给他插入一下) 就跟那人说什么重新加密一样 他搞得那个头部就是能把数据加密了一样(又不是什么中间人代理) 其实只是个连接类型
就是反代去连v2 他去怎么建立连接的意思.

给你补个图 这是第一个get. 2019-05-20_150217

负载均衡自动协商感觉好像不太现实把. 或者我没看懂你说什么. 7层均衡器死的不行 流量类型不对直接就连都连不上. 你这个自动协商是想干什么? 让配置更方便更傻瓜!!? 那这个肯定做不到啊. 那是负载均衡器的事情. v2的流量要是乱变 那更复杂了 负载均衡器你又控制不了 是他跟着你变还是你跟着他变. 这好像还更越来越复杂了.

k79e commented 5 years ago

楼上那人的意思 更像是要让v2支持普通http之类的模式. (或者普通tls 但是不是h2)

这我也不太清楚 不过不支持ws的是绝对连不上的. 但你说的那个ws直接连接 其实就是走的普通http然后加了个头部啊. 在http协商 upgrade到ws之后 服务器才会转为websocket模式 开始发二进制数据. 具体是 客户端http upgrade 服务器 返回101状态码 告诉切换协议 然后双方互相进行ws 握手 这个时候才从http切换到ws的

quic肯定也是服务器给设定了什么东西 浏览器收到了之后才会尝试连接. 浏览器可没那么聪明 自动就能知道各种类型连接.

不过你提到了那个google的ws 他们也没提到的是客户端跟均衡器之间的连接可以那样升级. 没说均衡器跟后端. 不过这个你问下他们客服就知道了.

Leo-Mu commented 5 years ago

浏览器好像不会自动协商把. http转https都是服务器做的跳转啊.

你放心好了v2的ws规范的不得了 cdn随便用. 反正他流量是有那个upgrade头 cdn认识就够了 我这个回复就是走的cdn反代ws 那个cdn https默认就是h2 所以你应该没啥疑问了吧.

v2直接直连 ws模式都有upgrade头的. 不是你说的直接就跟http一样 没upgrade头部. 反代甚至你不给他插入upgrade头部 v2都不认 根本连不上. (因为反代不知道流量类型 所以要人工指定 给他插入一下) 就跟那人说什么重新加密一样 他搞得那个头部就是能把数据加密了一样(又不是什么中间人代理) 其实只是个连接类型 就是反代去连v2 他去怎么建立连接的意思.

给你补个图 这是第一个get. 2019-05-20_150217

负载均衡自动协商感觉好像不太现实把. 或者我没看懂你说什么. 7层均衡器死的不行 流量类型不对直接就连都连不上. 你这个自动协商是想干什么? 让配置更方便更傻瓜!!? 那这个肯定做不到啊. 那是负载均衡器的事情. v2的流量要是乱变 那更复杂了 负载均衡器你又控制不了 是他跟着你变还是你跟着他变. 这好像还更越来越复杂了.

疑?头里有 upgrade 的吗。。。 那为什么我配置 GCP HTTP(S) 负载平衡器后始终无法成功使用 WS 走代理?

Leo-Mu commented 5 years ago

你想要像浏览器一样upgrade to websocket可以用apache nginx等配合v2ray, v2ray已经做到了能够http一来一往以后升级到websocket, http2 标准没有Upgrade to websocket

就是说在客户端这边用 nginx 做一个反代吗?然后就是说实际在网络当中的传输由两端的 nginx (负载均衡器)接管。有道理,这个思路不错!

Leo-Mu commented 5 years ago

楼上那人的意思 更像是要让v2支持普通http之类的模式. (或者普通tls 但是不是h2)

这我也不太清楚 不过不支持ws的是绝对连不上的. 但你说的那个ws直接连接 其实就是走的普通http然后加了个头部啊. 在http协商 upgrade到ws之后 服务器才会转为websocket模式 开始发二进制数据. 具体是 客户端http upgrade 服务器 返回101状态码 告诉切换协议 然后双方互相进行ws 握手 这个时候才从http切换到ws的

quic肯定也是服务器给设定了什么东西 浏览器收到了之后才会尝试连接. 浏览器可没那么聪明 自动就能知道各种类型连接.

不过你提到了那个google的ws 他们也没提到的是客户端跟均衡器之间的连接可以那样升级. 没说均衡器跟后端. 不过这个你问下他们客服就知道了.

哦,你的意思是 GCP 的负载均衡器还不只是一个头那么简单是吧?所以现在 V2Ray WS 还会有问题。

k79e commented 5 years ago

反正具体问问客服是最有效率的了. 他们肯定知道. 问他们cdn到后端支不支持ws连接. 他们自己对外只是说cdn到浏览器支持ws连接.

你如果后端配置的是https访问的话(cdn-v2) 要和v2都匹配才行.

如果cdn要是支持h2的话 你直接用h2不就行了.

neco91998 commented 5 years ago

CDN 基本上都支持H2访问,只是现在没有CDN可以H2回源吧?

github-actions[bot] commented 4 years ago

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days

github-actions[bot] commented 3 years ago

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days