Chisel – A fast TCP tunnel over HTTP

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:&#x2F;&#x2F;www.quora.com&#x2F;What-is-the-difference-between-HTTP-protocol-and-TCP-protocol" rel="nofollow">https:&#x2F;&#x2F;www.quora.com&#x2F;What-is-the-difference-between-HTTP-pr...</a>)

Looks to be TCP over websockets; which isn&#x27;t really that interesting IMO.

How does this deal with double congestion control?

Annoying that this has the same name as <a href="https:&#x2F;&#x2F;github.com&#x2F;ucb-bar&#x2F;chisel3" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ucb-bar&#x2F;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:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc2616#section-9.9" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;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:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;TCP_hole_punching" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;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.