fre*_*ish 12 pipeline http response request
我无法理解当多个请求并行发送时(在获得响应之前)HTTP如何工作.有两种情况:
1)有Connection: Keep-Alive.
根据HTTP规范:
支持持久连接的客户端可以"管道化"其请求(即,在不等待每个响应的情况下发送多个请求).服务器必须按照收到请求的顺序发送对这些请求的响应.
这种方式似乎很难实现和维护.服务器必须跟踪请求的顺序,并且必须以正确的顺序响应.不仅可能不容易实现,而且还有性能损失:快速请求必须等到处理慢速请求(如果稍后发出).
此外,如果我们讨论负载均衡器,那么代理必须跟踪哪个请求被发送到哪个服务器,因此当它们返回时它可以将它们放入队列并按顺序响应.那么为什么不首先这样做呢？即,客户端(例如)ID标头听起来更自然,更容易,服务器处理请求并使用相同的ID标头进行响应,以便客户端可以将请求与响应进行匹配.这更容易实现,并且不会引入排队请求的问题(如果有必要,由客户端跟踪请求的顺序).
所以问题是:以指定方式指定流水线的原因是什么？
2)没有Connection: Keep-Alive.
我找不到有关该案件的任何信息.假设客户端发出两个请求A和B.如果没有keep-alive,服务器将在处理请求后关闭连接.这显然引入了竞争条件.那应该怎么做呢？它应该丢弃第二个请求吗？
1) 保持活动状态：
根据这篇维基百科文章（http://en.wikipedia.org/wiki/HTTP_pipelined），情况恰恰相反：服务器端的实现实际上非常简单。我相信这个断言是基于这样的假设：单个线程用于处理单个连接的所有请求（这当然是设计此机制时的一般情况），因此同一连接上的多个请求由该线程顺序处理（并且由于 TCP 保证有序传送，因此自然会按照处理它们的顺序接收响应）。今天在非阻塞服务器实现上可能会有所不同。
2）没有保活：
如果没有保持活动状态，您就不会管道请求，因此我看不到竞争条件。您有两个单独的连接用于请求 A 和 B，每个连接在请求完成后关闭。
如果客户端尝试在没有保持活动状态的情况下管道请求，我相信规范的以下部分适用：
在连接建立后立即采用持久连接和管道的客户端应该准备好在第一次管道尝试失败时重试连接。如果客户端进行此类重试，则在知道连接是持久的之前不得进行管道传输。如果服务器在发送所有相应响应之前关闭连接，客户端还必须准备好重新发送请求。
我的解释是服务器必须合法地丢弃第二个请求并只响应第一个请求，因为响应是 FIFO 的。由客户端重新发送第二个请求。
请记住：这主要是我的假设，我希望它们对您有意义！