5 ms·
> I would've expected a single TCP connection to be able to saturate a line There's several factors at play that make this (usually) not the case. Besides phy
by ranger_danger 6d ago
> I would've expected a single TCP connection to be able to saturate a line
There's several factors at play that make this (usually) not the case.
Besides physical latency (which includes those added by any VPNs/tunnels/etc., some of which may be internal to an ISP along the route and outside of your control), there's other things like the TCP window sizes / window scaling option[1] that can affect single stream performance, and those type of parameters can differ by OS/interface type on both ends.
Also for SSH specifically, it has its own fixed buffer size that also limits throughput unless you're using the HPN-SSH fork[2].
[1] https://en.wikipedia.org/wiki/TCP_window_scale_option https://en.wikipedia.org/wiki/TCP_window_scale_option
[2] https://www.psc.edu/hpn-ssh-home/introduction/ https://www.psc.edu/hpn-ssh-home/introduction/
- greaber 6d agoAlso, in syq, a connection is the unit of independent transfer work. Probably it would be possible to get higher bandwidth per TCP connection by some kind of multiplexing, but that architecture would be more complex and probably not have many benefits.
- ranger_danger 6d agoThere's also MPTCP (multipath TCP) which is even supported on mobile devices these days. So for example if your device has both a wifi and a cellular connection, and both ends of the stream support MPTCP, you can increase throughput/failover by combining multiple interfaces.