HTTPUpgrade transport still requires support from the CDN provider to pass WebSocket

[zirconpl]

v2ray v5.10.1 of has introduced a new HTTPUpgrade transport protocol, described as:

It is a reduced version of WebSocket Transport that can pass many reverse proxies and CDNs without running a WebSocket protocol stack.

After testing, when the CDN provider's WebSocket feature is turned off, it's not possible to pass data normally because the first action of HTTPUpgrade is to request an upgrade to WebSocket. It seems that HTTPUpgrade transport cannot be used with CDN providers that do not support WebSocket, so compared to the previous WebSocket transport, HTTPUpgrade transport does not seem to have a clear advantage.

[xiaokangwang]

HTTPUpgrade does not require either client to server to support websocket protocol stack, thus allow them to decrease resource usage, simplify implementation, improve speed and make it possible to control packet length precisely.

It still use the same underlying mechanic of WebSocket to create a bidirectional channel, so it would works only on the platforms WebSocket works, and this is expected. Meek can pass CDN that does not support websocket, although it is kind of slow so it is not designed as a daily driver protocol.

[zhu327]

@xiaokangwang Can HTTP Upgrade be used in a 0-RTT manner, similar to WebSocket, to reduce the latency of the first packet?

[xiaokangwang]

@xiaokangwang Can HTTP Upgrade be used in a 0-RTT manner, similar to WebSocket, to reduce the latency of the first packet?

This is possible but currently unimplemented.

[github-actions[bot]]

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