当并行发送多个请求时（在获得响应之前），我无法理解 HTTP 的工作原理。有两种情况：
1) With Connection: Keep-Alive.
根据HTTP规范 http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html:
支持持久连接的客户端可以“管道”其
请求（即发送多个请求而不等待每个请求
回复）。服务器必须将其响应发送到
收到请求的顺序相同。
这种方式似乎很难实施和维护。服务器必须跟踪请求的顺序并必须以正确的顺序响应。它不仅可能不容易实现，而且会对性能造成影响：如果稍后发出快速请求，则必须等到慢速请求得到处理。
此外，如果我们谈论负载均衡器，那么代理必须跟踪哪个请求发送到哪个服务器，以便当它们返回时，它可以将它们放入队列并按顺序响应。那么为什么不首先这样做呢？ IE。客户提出的听起来更自然、更容易（例如）IDheader，服务器处理请求并用相同的响应IDheader 以便客户端可以将请求与响应进行匹配。这更容易实现，并且不会引入排队请求的问题（如果有必要，由客户端来跟踪请求的顺序）。
所以问题是：以指定方式指定管道的原因是什么？
2) 没有Connection: Keep-Alive.
我找不到有关该案件的任何信息。假设客户端发出两个请求 A 和 B。如果没有 keep-alive，服务器将在处理完请求后关闭连接。这显然引入了竞争条件。那么它应该如何表现呢？它应该放弃第二个请求吗？
1) 保持活动状态：
根据这篇维基百科文章（http://en.wikipedia.org/wiki/HTTP_pipelined http://en.wikipedia.org/wiki/HTTP_pipelining）恰恰相反：服务器端的实现实际上非常简单。我相信这个断言是基于这样的假设：单个线程用于处理单个连接的所有请求（这当然是设计此机制时的一般情况），因此同一连接上的多个请求由该线程顺序处理（并且由于 TCP 保证有序传送，因此自然会按照处理它们的顺序接收响应）。今天在非阻塞服务器实现上可能会有所不同。
2）没有保活：
如果没有保持活动状态，您就不会管道请求，因此我看不到竞争条件。您有两个单独的连接用于请求 A 和 B，每个连接在请求完成后关闭。
如果客户端尝试在没有保持活动状态的情况下管道请求，我相信规范的以下部分适用：
立即采用持久连接和管道的客户端
连接建立后应该准备重试
如果第一次管道尝试失败，则连接。如果客户这样做
重试，在知道连接已建立之前不得进行管道传输
执着的。客户还必须准备好重新发送请求，如果
服务器关闭连接在发送所有之前
相应的回应。
我的解释是服务器必须合法地丢弃第二个请求并只响应第一个请求，因为响应是 FIFO 的。由客户端重新发送第二个请求。
请记住：这主要是我的假设，我希望它们对您有意义！
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
