HTTP persisted connection with pipeline. How multiple files are divided in segments by TCP

Question

I have a very simple question which answer seems impossible to find as I want it. Let’s suppose I have a tcp connection between a client and a sever and the client made a request for a page that contains 2 files. We assume that the http connection is persisted and with pipeline so the 2 requests for the files are send in one tcp segment to the from the client to the server. Now suppose the files that the client wants are like 4500 bytes and 3000 bytes and the MSS of tcp is 1460 bytes because we are using ethernet, so the first file should be divided in 3 segments of 1460 and one of 120 while the second file is divided in 2 segments of 1460 and one of 80 (at least this is what happen if tcp send one file only). In this situations how many segments tcp will send? The first 4 of the first file and the 3 of the second file or it will “merge” the 2 file together at first and then send that file divided? In the second case we would have a file of 7500, 5 MSS + 200 bytes.

I can’t find anywhere informations about this problem. So in the end my question how is the pattern of the segments send by tcp:

3 MSS -> 120 bytes -> 2 MSS -> 80 bytes Or 5 MSS -> 200 bytes

I can’t understand how tcp could send a segment containing bytes of 2 different files.

Answer 1

I can’t understand how tcp could send a segment containing bytes of 2 different files.

From the perspective of a user application TCP is just a byte stream and nothing is known how these bytes were delivered in packets. At the TCP itself there is no idea of files or HTTP requests and responses. The distinction between these is done at the application level instead, i.e. in this case at the level of the HTTP protocol.

The HTTP protocol defines that each request and response consists of a header and a body which are distinguished by an empty line. The size of the body or body parts are known up-front, i.e. either given in the header (using the content-length field) or given before each body chunk (with transfer-encoding: chunked). This way the end of the body and thus the beginning of the next request/response can be determined by the HTTP protocol parser. And it does not matter at all how these data are packetized at the underlying TCP layer.