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

Question

我刚刚在 HTTP 管道上阅读了这个 Wikipedia article，从图中可以看出响应可以在一个连接上同时发送。我误解了图表还是允许这样做？

Section 8.1.2.2 of RFC 2616 状态：

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

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

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

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

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

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

Answer 1

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

但是，服务器不能对一个请求发送多个响应，即请求响应模式仍然适用。 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 保证保持传输消息的顺序，所以我们总是可以将第一个请求与第一个响应联系起来等等。

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