> 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

[2] https://www.psc.edu/hpn-ssh-home/introduction/

▲

greaber 2 hours ago | parent [-]

Also, 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 2 hours ago \| parent [-]
		There'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.