How does non persistent parallel HTTP connections work?

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

I have asked similar question earlier here as well, but at that time I wasn’t very clear about my question and my question was unclear, long and vague and I guess because of that many skipped that question.


Now I am 100% clear about my question.






Here

1. First RTT is for TCP connection establishment


2. Second RTT is to request the webpage and response(few bytes that gives structure of the page). Say the base file contains 2 elements called element1 and element2.


3. Third RTT could be to establish the TCP Connection again


4. Fourth RTT could be to request for the element1 and receive its response.


But it is receiving multiple responses, I don't understand how?


And when do the TCP Connections close, in which order?


This is how I believe it should be occurring:

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Think back to previous lessons on TCP vs UDP, they will have made a big point about UDP being good if the application layer is handling stuff like dropped packets and so on. I think this is a similar discussion.

The point of the parallel / Non-persistent thing is that teh application is going to open fresh http channels for each new thing it does. So if the first connection gets a token and a list of endpoints for an API, then each GET or PUT to the endpoints will present that bearer token, but at TCP level, each one is a new handshake and a new session which closes at the end of the task.

So if you upload a 100GB file to AWS S3, that session will begin with you putting an object into the bucket, but then you will have to open at least 20 TCP sessions to do the multipart upload into that object (5GB max chunks). Each of those sessions will run in parallel and then close itself, but they all needed metadata that was generated in the first session.

 

there are lots of terms here which are not in the level of studies that i require at the moment. i figured out that you could send multiple requests in just a single request message and that's why there are multiple received objects. i haven't seen this thing in rfc, but this came from huawei engineers so i have to be confident in it.