9 ms·
So TCP has slow start, and exponential fall off and shit. but you can get round that in a lot of cases by just having a load of TCP connections in parallel. T
by KaiserPro 2y ago
So TCP has slow start, and exponential fall off and shit.
but you can get round that in a lot of cases by just having a load of TCP connections in parallel.
TCP is cheap and well optimised, especially if you are keeping a bunch of connections open. (opening can be expensive)
so if you have a high latency connection, or a bit of packet loss, and you want to reach line speed without having to figure out cornercases with UDP, just open up 100-1k TCP connections and multiplex them.
bish bash bosh, mostly line speed over a high latency line (mind you this was in the days of 100m-500m cross atlantic internet, you'll probably need more connections to saturate a 10gig line.)
- nh2 2y agoSuch hack is often not necessary. Set larger kernel TCP send and receive buffers and enable BBR congestion control. Speed will usually be good also across high latency links, and no multiplexing logic needed. Especially if you control both sides of the connection.
- KaiserPro 2y ago> Set larger kernel TCP send and receive buffers and enable BBR congestion control I mean yeah, but that requires having access to the kernel config. so for most people multiplexing TCP is a useful way to maximise a link, without having to fiddle with stuff that is a pain to deploy. (politically as well as logistically) I deployed this "technique" before BBR was a thing. It worked well enough for what I needed it to do (move large images from London to California) It was pretty simple to engineer as well (mainly because I didn't have to make a fancy custom error detection/correction/rate limiting system over UDP )