在收到回复之前发出多个请求 [英] issuing multiple requests before getting response

问题描述

当多个请求被并行发送（在获得响应之前）时，我无法理解HTTP的工作原理。有两种情况：

I'm having trouble understanding how HTTP works when multiple requests are send parallely (before getting a response). There are two cases:

1）使用连接：Keep-Alive 。

根据 HTTP规范：

支持持久连接的客户端可以管道其
请求（即，发送多个请求而不等待每个
响应）。服务器必须按照收到请求的
相同的顺序发送对这些请求的响应。

A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.

这种方式似乎很难实施和维护。服务器必须跟踪请求的顺序，并且必须以正确的顺序响应。它不仅可能不容易实现，而且还会受到性能影响：快速请求必须等到处理缓慢的请求（如果它们稍后发布）。

That way seems to be quite difficult to implement and maintain. The server has to keep track of the order of requests and has to respond in correct order. Not only it might not be easy to implement but there's a performance hit: fast requests have to wait until slow requests are processed if they were issued later.

如果我们是在讨论负载均衡器时，代理必须跟踪哪个请求被发送到哪个服务器，因此当它们返回时，它可以将它们放入队列并按顺序响应。那么为什么不首先这样做呢？即客户端（例如） ID 标头听起来更自然，更容易，服务器处理请求并使用相同的 ID 标头，以便客户端可以将请求与响应匹配。这更容易实现，并且不会引入排队请求的问题（如果有必要，由客户端跟踪请求的顺序）。

Also if we are talking about a load balancer then the proxy has to keep track of which request was send to which server so when they come back it can put them in queue and respond in order. So why not make that way in the first place? I.e. it sounds more natural and easier that a client puts (for example) ID header, the server processes the request and responds with the same ID header so that the client can match request with response. That is a lot easier to implement and it does not introduce problems with queueing requests (it is up to the client to track the order of requests if it is necessary).

所以问题是：以指定方式指定流水线的原因是什么？

So the question is: what's the reason to specify pipelining in the way it was specified?

2）没有连接：Keep-Alive 。

我找不到有关该案例的任何信息。假设客户端发出两个请求A和B.如果没有keep-alive，服务器将在处理请求后关闭连接。这显然引入了竞争条件。那应该怎么做呢？它应该丢弃第二个请求吗？

I couldn't find any info about that case. Let's say that a client issues two requests A and B. Without keep-alive the server will close the connection after processing the request. This obviously introduces a race condition. So how should it behave? Should it discard the second request?

推荐答案

1）使用Keep-Alive：

1) With Keep-Alive :

根据这篇维基百科文章（ http://en.wikipedia.org/wiki/HTTP_pipelining）相反：服务器端的实现实际上非常简单。我相信这个肯定是基于这样的假设：单个线程用于处理单个连接的所有请求（这当然是设计此机制时的一般情况），因此该线程按顺序处理同一连接上的多个请求（并且由于TCP保证有序传递，响应自然会按照处理它们的顺序接收）。今天在非阻塞服务器实现上可能会有所不同。

According to this wikipedia article (http://en.wikipedia.org/wiki/HTTP_pipelining) it is the opposite : implementation on the server side is actually very simple. I believe this affirmation is based on the assumption that a single thread is used to handle all requests for a single connection (which was certainly the general case when this mechanism was designed) and thus several requests on the same connection are handled sequentially by this thread (and as TCP guarantees ordered delivery, responses are naturally received in the same order they are processed). It might be different today on a non-blocking server implementation.

2）没有Keep-alive：

2) Without Keep-alive :

没有keep-alive，你没有管道请求，所以我没有看到竞争条件。对于请求A和B，您有两个单独的连接，每个连接在请求完成时关闭。

Without keep-alive, you do not pipeline requests, so I do not see the race condition. You have two separate connections for requests A and B, each connection is closed when the request has been completed.

如果客户端尝试在没有keep-alive的情况下管道请求，我相信规范的以下部分适用：

If the client tries to pipeline requests without keep-alive, I believe the following section of the specification applies :

连接建立后立即假定持久连接和管道
的客户端应该准备好如果第一次流水线尝试失败，请重试其
连接。如果客户端重试这样的
，它必须在它知道连接是
persistent之前才进行管道传输。 客户还必须准备好重新发送他们的请求，如果
服务器关闭连接，然后再发送所有
相应的响应。

Clients which assume persistent connections and pipeline immediately after connection establishment SHOULD be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it MUST NOT pipeline before it knows the connection is persistent. Clients MUST also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.

我的解释是服务器必须合法地丢弃第二个请求，并且只响应第一个请求，因为响应是FIFO。客户端重新发送第二个请求。

My interpretation is that the server must legitimately discard the second request and only respond to the firts one, as responses are FIFO. It's up the client to resend the second request.

请记住：这主要是我的假设，我希望它们对你有意义！

Keep in mind : this are mostly suppositions on my side, I hope they make sense to you!

这篇关于在收到回复之前发出多个请求的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！