Looking at the structure of a TCP packet, such as discussed here: What is the internal structure of a mobile phone call packet/datagram?, this indicates that a TCP packet size is 192 bytes excluding data.
From an answer on StackOverflow (https://stackoverflow.com/questions/2613734/maximum-packet-size-for-a-tcp-connection), I see that the size of the data is variable with a hard maximum of 64KB, but in practice can't go beyond 1500B (according to one of the answers) - which I assume is on a reasonably good network.
Then on Wikipida (https://en.wikipedia.org/wiki/Maximum_segment_size) I see that for practical reasons TCP data packets limited to smaller sizes will avoid IP fragmentation - which I guess is desirable for poorer network qualities.
If I had a mobile device on a network with a high latency (400ms), is there a way to estimate the number of TCP packets that will be required to transmit an HTTP payload of 1MB?
My understanding of networks is then that you could calculate the time it takes for all the packets to be delivered over such a connection.
i.e. 1000 packets * 400ms latency (i.e. 400ms RTT - I understand latency to usually refer to RTT) = at least 400 seconds to deliver the HTTP payload.
But this doesn't take into account throughput.. If that calculation (at least in principle) is correct, how would increasing throughput (i.e. upgrading a connection from 1mbps to 10mbps) effect the delivery of a 1MB HTTP payload?
Would it allow for increasing the TCP segment size? And, if so, is this done automatically via the TCP application?