Hi, one of the authors here. Thanks for raising a valid concern. Vimeo in fact already offers FTP uploads for premium users, but helped us write this as the advantages of something HTTP based are significant. We can:<p>- be sure that browsers and servers already speak it (so small additional libraries required on both ends)<p>- gracefully degrade to regular form POSTs should tus support not be possible (IE8, etc)<p>- easily write hooks for progress bars, and e.g. encoding of the uploaded material<p>- use existing holes in firewalls. FTP requires many ports (for PORT, DATA, PASV) that are blocked on airports, public libraries, large corporations<p>- add existing HTTP components to make tus better (loadbalancing, intrusion detection, auth, proxies, etc). Some of these apply to FTP as well, but the HTTP options are more (advanced).<p>Bittorrent is not really client-server oriented, which is what this protocol is trying to solve. Rsync has many the same disadvantages as FTP listed above.<p>As for a single TCP connection with no traffic shaping, tus support splitting up a file into multiple parts and uploading them in parallel (as regular tus uploads, so profiting from checksums, retries, and resumability) and stitching them together on the server-side by issuing a &#x27;concat&#x27;. This means you can have as many connections as you like, and the individual chunks can complete in any order as well.<p>Traffic shaping is not part of the protocol. By default tus should saturate available connections.<p>That said we&#x27;re writing down some recommendations in a separate &#x27;developer guide&#x27; document that offers best practices for implementing and deploying tus, traffic shaping could be part of it. Feel free to weigh in here <a href="https:&#x2F;&#x2F;github.com&#x2F;tus&#x2F;tus-resumable-upload-protocol&#x2F;pull&#x2F;68" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tus&#x2F;tus-resumable-upload-protocol&#x2F;pull&#x2F;68</a>