3

我刚刚阅读了这篇关于 HTTP 流水线的Wikipedia 文章，从图中可以看出，响应可以在一个连接上同时发送。我是误解了图表还是允许这样做？

RFC 2616 的第 8.1.2.2 节指出：

服务器必须以与接收请求相同的顺序发送对这些请求的响应。

虽然这没有明确排除并发响应，但它没有提到需要确保响应不仅必须以与请求相关的正确顺序开始，而且还必须以正确的顺序结束。

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

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

它是否正确？我在下面附上了一张图表来说明我的解释。

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

HTTP 流水线

4

1 回答 1

5

简短回答：是的，客户端和服务器可以同时发送请求和响应。

但是，服务器不能对一个请求发送多个响应，即请求响应模式仍然适用。RFC 2616（以及您引用的 Wikipedia 文章）只是声明客户端无需等待服务器的响应即可在同一连接上发送附加请求。所以你图中的请求看起来不错:)。

但是服务器不必等待它的每个响应都完成，然后它就可以开始传输下一个响应。它可以在接收到客户端的请求时将响应发送给客户端。（这导致维基百科文章中显示的图表。）

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

好吧，让我们在这里暂时忽略整个网络延迟的东西，并假设流水线请求或响应消息立即到达，但只有在所有这些消息都已发送之后。

  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
...

服务器 -> 客户端

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

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

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

TCP 的伟大之处在于这个特定的消息流看起来总是一样的。您可以先发送所有请求，然后接收响应；可以先发送请求1，接收第一个响应，发送剩余请求，接收剩余响应；您可以发送第一个请求和第二个请求的一部分，接收第一个响应的一部分，发送剩余的请求，接收剩余的响应；等等 因为 TCP 保证保持传输消息的顺序，所以我们总是可以将第一个请求与第一个响应联系起来，依此类推。

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

于 2014-02-26T13:12:53.990 回答