How does non persistent parallel HTTP connections work?

Discussion in 'CCENT / CCNA' started by shivaji, Jun 4, 2022.

  1. shivaji

    shivaji Bit Poster

    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.



    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:

  2. FlashDangerpants

    FlashDangerpants Byte Poster

    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.
    Certifications: MCITP Exchange 2010, MCSA Svr 2012
    WIP: Exchange 2013
    shivaji likes this.
  3. shivaji

    shivaji Bit Poster

    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.

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.