XTLS
Browser dialer: High-performance passthrough rewrite
This PR is currently a draft.
It is a complete rewrite of the browser dialer to utilize pass-through without any processing on the browser side, reaching its theoretical maximum performance. A control socket will be used to instruct the browser dialer to initiate relaying.
The JS side, Appat, is currently being built. I'll post a built version of it and unmark this as a draft once it's done.
The incomplete half-duplex methods for XHTTP should be all implemented. We can begin trials once the WebSocket forwarder is finished.
Since the fallback logic isn't yet implemented, the new browser dialer currently requires Chromium 124+ to be able to operate, yet 0 processing in the browser should unlock the speed potential if it also works in non-isolated test environments.
感谢 PR，新的 JS 没有可读性，原本的文件留一下吧，新文件可以命名为 dialer_new.html 之类的，~否则你消失了的话可能难以维护~
新旧接口完全不兼容 换模式了 现在是一个conn传递控制信息 别的只传代理数据(js没法像go一样读一点header出来再io copy 只能直接对拷)
@RPRX It will be tricky to include the source files here, which is why I resorted to build an implementation-agnostic solution outside with proper JS build tools, then paste the results here. The source code of that is located here: https://github.com/team-cloudchaser/appat
I can include the source files here (it's MIT anyway), but that wouldn't be of any use without the inclusion of JS build tools.
Another question: Should the browser dialer add fallbacks to make it at least work on browsers/runtimes without streaming support, even though it very likely will have a noticeable impact on performance? For now this only runs on Chromium 124+ and Deno.
without any processing on the browser side, reaching its theoretical maximum performance
是因为用了流式 API 吗？~~话说如果只考虑 Chrome 的话 stream-up 也可以兼容了~~
@RPRX Due to the use of streaming APIs, yes.
Upload streaming is also viable, however it would be tricky to tell the browser dialer when the upload ends. Moreover, Chromium currently has no intention to support bidirectional streaming.
Like I wrote here in the Appat README, since Firefox is still observing what to do next, it's possible that we can push Firefox to achieve bidirectional streaming to reduce the headaches somewhat.
Streamed bidirectional WebSocket support is being added.
Edit: Somehow the PR is still closed. Do I need to start a new draft PR?