How does a browser know which response belongs to which request?

Question

Suppose when we request a resource over HTTP, we get a response as shown below:

GET / HTTP/1.1
Host: www.google.co.in

HTTP/1.1 200 OK
Date: Thu, 20 Apr 2017 10:03:16 GMT
...

But when a browser requests many resources at a time, how can it identify which request got which response?

Answer 1

when a browser requests many resources at a time, how can it identify which request got which response?

A browser can open one or more connections to a web server in order to request resources. For each of those connections the rules regarding HTTP keep-alive are the same and apply to both HTTP 1.0 and 1.1:

• If HTTP keep-alive is off, the request is sent by the client, the response is sent by the server, the connection is closed:

  Connection 1: [Open][Request1][Response1][Close]
  

• If HTTP keep-alive is on, one "persistent" connection can be reused for succeeding requests. The requests are still issued serially over the same connection, so:

  Connection 1: [Open][Request1][Response1][Request3][Response3][Close]
  Connection 2: [Open][Request2][Response2][Request4][Response4][Close]
  

With HTTP Pipelining, introduced with HTTP 1.1, if it is enabled (on most browsers it is by default disabled, because of buggy servers), browsers can issue requests after each other without waiting for the response, but the responses are still returned in the same order as they were requested.

• This can happen simultaneously over multiple (persistent) connections:

  Connection 1: [Open][Request1][Request2][Response1][Response2][Close]
  Connection 2: [Open][Request3][Request4][Response3][Response4][Close]
  

Both approaches (keep-alive and pipelining) still utilize the default "request-response" mechanism of HTTP: each response will arrive in the order of the requests on that same connection. They also have the "head of line blocking" problem: if [Response1] is slow and/or big, it holds up all responses that follow on that connection.

• Enter HTTP 2 multiplexing: What is the difference between HTTP/1.1 pipelining and HTTP/2 multiplexing?. Here, a response can be fragmented, allowing a single TCP connection to transmit fragments of different requests and responses intermingled:

  Connection 1: [Open][Rq1][Rq2][Resp1P1][Resp2P1][Rep2P2][Resp1P2][Close]
  

It does this by giving each fragment an identifier to indicate to which request-response pair it belongs, so the receiver can recompose the message.

Answer 2

I think you are really asking for HTTP Pipelining here. This is a technique introduced in HTTP/1.1, through which all requests would be sent out by the client in order and be responded by the server in the very same order. All the gory details are now in RFC 7230, sec. 6.3.2.

HTTP/1.0 had (or has) a comparable method known as Keep Alive. This would allow a client to issue a new request right after the previous has been answered. The benefit of this approach is that client and server no longer need to negotiate through another TCP handshake for a new request/response cycle.

The important part is that in both methods the order of the responses matches the order of the issued requests over one connection. Therefore, responses can be uniquely mapped to the issuing requests by the order in which the client is receiving them: First response matches, first request, second response matches second request, … and so forth.

Answer 3

I think the answer you are looking for is TCP,

HTTP is a protocol that relies on TCP to establish connection between the Client and the Host

In HTTP/1.0 a different TCP connection is created for each request/response pair,

HTTP/1.1 introduced pipelining, wich allowed mutiple request/response pair, to reuse a single TCP connection, to boost performance (Didnt work very well)

So the request and the corresponding response are linked by the TCP connection they rely on,

It's then easy to associate a specific request with the response it produced,

PS: HTTP is not bound to use TCP forever, for example google is experimenting with other transport protocols like QUIC, that might end up being more efficient than TCP for the needs of HTTP