Why TCP over websockets? You can just use the HTTP bodies as a stream in both direction. Which means the proxy just has to strip or add HTTP headers before forwarding. The overhead afterwards is 0 -> you just write to the socket.
Hold on, hold on, hold on. Let me get this straight: you took an application layer protocol (HTTP) that runs on top of TCP and ...reimplemented TCP over it!?<p>(see: <a href="https://www.quora.com/What-is-the-difference-between-HTTP-protocol-and-TCP-protocol" rel="nofollow">https://www.quora.com/What-is-the-difference-between-HTTP-pr...</a>)
Annoying that this has the same name as <a href="https://github.com/ucb-bar/chisel3" rel="nofollow">https://github.com/ucb-bar/chisel3</a>
And no reference to the <i>standard</i> mechanism for HTTP tunnels, which has only existed for 18 years.<p><a href="https://tools.ietf.org/html/rfc2616#section-9.9" rel="nofollow">https://tools.ietf.org/html/rfc2616#section-9.9</a>
Many superlatives, which immediately raise suspicions.<p>If you are trying to solve the problem of NAT traversal and such, I suggest you rather attempt to do this:<p><a href="https://en.wikipedia.org/wiki/TCP_hole_punching" rel="nofollow">https://en.wikipedia.org/wiki/TCP_hole_punching</a>
Is there any difference with corkscrew? Either way, really keen to test the perfomance of it for getting out of restricted proxies where corkscrew saves me life.