Is it possible to achieve better data transfer rate with multiple parallel TCP connections in high-latency environment (public internet with large geographical distance assuming no traffic shaping per connection or stuff like that) or can TCP utilize the whole bandwidth with a single connection?
Is TCP sending data as fast as it cans if receiver doesn't report buffer congestion with 0 windows size? So if RTT is for example like 60 seconds it doesn't affect the rate at all? Is there some maximum window size or something else limiting the rate?
On the TCP level the tuple (source ip, source port, destination ip, destination port) must be unique for each simultaneous connection. That means a single client cannot open more than 65535 simultaneous connections to a single server. But a server can (theoretically) serve 65535 simultaneous connections per client.
There are three core metrics that affect the throughput of a TCP connection: round-trip time (RTT), packet loss (p), and the maximum segment size (MSS). A good model that describes the relationship of these three throughput variables is the Mathis Equation.
FTP uses two TCP connections, one for data and another control.
One advantage multiple concurrent connections may give you (subject to the same caveats mentioned by dove and Brian) is you will be able to better overcome the problem of having too small a TCP receive window.
The principle this relates to is bandwidth delay product. (There's a more detailed explanation here).
A brief summary: in high-latency, high-bandwidth environments, reliable communications such as TCP are often limited by the amount of data in flight at any given time. Multiple connections are one way around this, as the bandwidth delay product applies to each connection individually.
In more detail, consider the following: you have an end-to-end bandwidth of 10^8 bits per second (10 megabits/second), and a round-trip delay of 100ms (0.1 seconds). Therefore, there can be up to 10^7 bits (10 megabits = ~1.25 megabytes) of data sent before the acknowledgment of the first bit of data has gotten back to the sender.
This will vary depending on the TCP stack of your OS, but a not-uncommon value for TCP receive window size is 64Kbytes. This is obviously far too small to allow you to make full use of the end to end bandwidth; once 64kbytes (512kbits) of data have been sent, your sending process will wait for a window update from the receiver indicating that some data has been consumed before putting any more data on the wire.
Having multiple TCP sessions open gets around this by virtue of the fact that each TCP session will have its own send/receive buffers.
Of course, on the internet it's difficult to determine the true available end-to-end bandwidth, due to TCP window size, contention, etc. If you're able to provide some sample figures, we may be able to assist more.
The other option you should look into is setting a larger receive window when you create your socket, either globally using an OS setting, or on a per socket basis using socket options.
If you're the only one on the link, it will increase overhead and decrease speed. However, when sharing a fully saturated link with others, it's a way to game the system and increase your overall speed (each connection will be slower than a single one, but the aggregate will be faster as you've now got a larger percentage of "time slots" (what's the technical term? It escapes me now) allocated to you).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With