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

　　Today I knows that the server never send a request to a client! It just make response~

　　So,if the browser always want to get the newest data in the Server, it must regularly send request(always by AJAX) to the Server to get the resouce.

　　There comes to a important problem: when AJAX is communicting  in the background，How does the browser know which response belongs to which request???

　　from StackOverFlow,I got an excellent answer! 阮一峰的文章也给了很多启发。

 

　　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.