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

Answer 4

In addition to the explanations above consider a browser can open many parallel connections, usually up to 6 to the same server. For each connection it uses a different socket. For each request-response in each socket it is easy to determine the correlation.

Answer 5

1. In each TCP connection, request and response are sequential. A TCP connection can be re-used after finishing a request-response cycle.
2. With HTTP pipelining, a single connection can be multiplexed for multiple overlapping requests.
3. In theory, there can be any number[*1] of simultaneous TCP connections, enabling parallel requests and responses.
4. In practice, the number of simultaneous connections is usually limited on the browser and often on the server as well.

[*1] The number of simultaneous connections is limited by the number of ephemeral TCP ports the browser can allocate on a given system. Depending on the operating system, ephemeral ports start at 1024 (RFC 6056), 49152 (IANA), or 32768 (some Linux versions).

So, that may allow up to 65,535 - 1023 = 64,512 TCP source ports for an application. A TCP socket connection is defined by its local port number, the local IP address, the remote port number and the remote IP address. Assuming the server uses a single IP address and port number, the limit is the number of local ports you can use.