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?
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.