HTTP流水线 - 每个连接的并发响应

Sla*_*ish 3 http http-pipelining

我刚刚阅读了关于HTTP流水线的维基百科文章,从图中可以看出,响应可以在一个连接上同时发送.我是否误解了图表或允许这样做?

RFC 2616的8.1.2.2节规定:

服务器必须按照收到请求的顺序发送对这些请求的响应.

虽然该停止短的明确排除并发响应,它没有提到要确保响应不仅要以正确的顺序有关系的请求开始,但也完成正确的顺序.

我也无法想象处理并发响应的实用性 - 客户如何知道接收数据应用于哪个响应?

因此,我对RFC的解释是,虽然可以在处理对第一个请求的响应时进行其他请求,但是客户端不允许发送并发请求或服务器在同一连接上发送并发响应.

它是否正确?我附上了一张图表来说明我的解释.

它可以防止我提到的问题发生,但它似乎与维基百科中的图表完全一致.

HTTP流水线

PoB*_*lek 5

简短回答:是的,客户端和服务器可以同时发送请求和响应.

但是,服务器无法向一个请求发送多个响应,即请求响应模式仍然适用.RFC 2616(以及您所引用的维基百科文章)只是声明客户端不需要等待服务器的响应在同一连接上发送附加请求.所以你的图表中的请求看起来很好:).

但是,服务器不必等待其每个响应完成,然后才能开始传输下一个响应.它可以在收到客户端请求时将响应发送给客户端.(这导致维基百科文章中显示的图表.)

客户如何知道响应适用于哪个请求?

好吧,让我们在这里忽略整个网络延迟一分钟并假设流水线请求或响应消息立即到达但仅在所有这些消息都已发送之后.

  1. 客户端以特定顺序发送其请求(无需等待请求之间的响应).
  2. 服务器以相同的顺序(TCP保证)一次性接收请求.
  3. 服务器接收第一个请求消息,对其进行处理,并将响应存储在队列中.
  4. 服务器接收第二个请求消息,对其进行处理,并将响应存储在队列中.
  5. (你明白了......)
  6. 服务器将该队列的内容发送给客户端.响应按顺序存储,因此对第一个请求的响应位于该队列的开头,然后是对第二个请求的响应,依此类推......
  7. 客户端以相同的顺序接收响应(TCP保证)并将第一个响应与它所做的第一个请求相关联,依此类推.

即使我们不假设我们一次收到所有消息,这仍然有效,因为TCP保证发送的数据以相同的顺序接收.

我们也可以完全忽略网络,只看一下在服务器和客户端之间传输的消息.

客户端 - >服务器

GET /request1.html HTTP/1.1
Host: example.com
...

GET /request2.html HTTP/1.1
Host: example.com
...

GET /request3.html HTTP/1.1
Host: example.com
...
Run Code Online (Sandbox Code Playgroud)

服务器 - >客户端

HTTP/1.1 200 OK
Content-Length: 234
...

HTTP/1.1 200 OK
Content-Length: 123
...

HTTP/1.1 200 OK
Content-Length: 345
...
Run Code Online (Sandbox Code Playgroud)

关于TCP的好处是这个特定的消息流看起来总是一样的.您可以先发送所有请求,然后再收到回复; 您可以先发送请求1,接收第一个响应,发送剩余请求,然后接收剩余的响应; 您可以发送第一个和第二个请求的一部分,接收第一个响应的一部分,发送剩余的请求,接收剩余的响应; 因为TCP保证保持传输消息的顺序,所以我们总是可以将第一个请求与第一个响应相关联,依此类推.

我希望这回答了你的问题...