title: How does sshuttle avoid of TCP-over-TCP curse?
body: <p><a href="http://sshuttle.readthedocs.io/en/stable/how-it-works.html" rel="noreferrer">sshuttle claims</a> that it solves much <a href="https://serverfault.com/questions/630837/under-what-circumstances-is-tcp-over-tcp-performing-significantly-worse-than-tcp">discussed problem</a> of <a href="http://sites.inka.de/~W1011/devel/tcp-tcp.html" rel="noreferrer">TCP-over-TCP meltdown</a>.</p>
  
  <blockquote>
    <p>sshuttle assembles the TCP stream locally, multiplexes it statefully over an ssh session, and disassembles it back into packets at the other end. So it never ends up doing TCP-over-TCP. It’s just data-over-TCP, which is safe.</p>
  </blockquote>
  
  <p>But from the point of view of a program it maintains a TCP connection to a target server with all that comes with it (read exponential timeouts), which is layered about other TCP session since SSH doesn't yet just work on <code>udp</code>. This very much looks like TCP-over-TCP. </p>
  
  <p>What is the trick here? Is the problem really solved by sshuttle?</p>
  
  <p>I tried reading <a href="https://github.com/apenwarr/sshuttle" rel="noreferrer">source code</a>, but so far didn't find the answer.</p>
  
  <p>More importantly, how exactly do they do it? If one wants to reimplement it in barebones, where one should look for inspiration?</p>