3 ms·
TCP is far from optimal for tunneling multiple flows, but you can still tweak it a lot by using a recent(ish) linux kernel which will allow you to use FQ_CODEL
by the8472 6y ago
TCP is far from optimal for tunneling multiple flows, but you can still tweak it a lot by using a recent(ish) linux kernel which will allow you to use FQ_CODEL + BBR + NOTSENT_LOWAT to reduce loss sensitivity and minimize the excess buffering in the presence of bulk flows over the tunnel.
Well, and by not using SSH for tunneling, since that brings yet another layer of flow control. If you're on a fixed-bandwidth connection disabling SSR might help too. These are all sender-side changes, so you need to control the remote end of the VPN too.
- Siira 6y agoCan you point to some guide on exactly which bash commands to run for this?
- the8472 6y agoJust to repeat myself, these are sender-side modifications, so if you're the receiver and don't control the sender they won't do any good. https://blog.cloudflare.com/http-2-prioritization-with-nginx/ https://blog.cloudflare.com/http-2-prioritization-with-nginx... (you can replace fq with fq_codel on newer kernels) https://stackoverflow.com/questions/17015611/how-to-disable-tcp-slow-start-in-linux https://stackoverflow.com/questions/17015611/how-to-disable-... And for not using SSH for tunneling, well you could try openvpn for example which offers TCP- and UDP-based transports and if you're stuck with TCP then it merely nests TCP-in-TLS-in-TCP which is only 2 layers of flow control rather than TCP-in-SSH-in-TCP which is 3 layers of flow control. Note that this is not universal network tuning advise. It's meant for bursty or bulk traffic in TCP tunnels over wired connections with low packet loss.