是否可以使用 HTTP 接收乱序响应? [英] Is it possible to receive out-of-order responses with HTTP?
问题描述
"服务器必须以与请求相同的顺序发送对请求的响应已收到".
"A server MUST send its responses to requests in the same order that the requests were received".
所以，我想，如果我从浏览器发出多个 AJAX 请求，它们仍然会按照服务器收到它们的顺序进行处理.
So, I thought, if I send out multiple AJAX requests from my browser, they will still be processed in the order in which they were received by the server.
但后来，我正在阅读 Alex Maccaw 的这篇帖子，他说:
But then, I was reading this post from Alex Maccaw, where he states :
最后一个问题是并行发送的 Ajax 请求.如果用户创建一条记录，然后立即更新同一条记录，会发出两个ajax请求同时，一个POST和一个PUT.但是，如果服务器处理更新"请求在创建"一个之前，它会吓坏了.它不知道哪些记录需要更新，因为记录尚未创建.
"The last issue is with Ajax requests that get sent out in parallel. If a user creates a record, and then immediately updates the same record, two Ajax requests will be sent out at the same time, a POST and a PUT. However, if the server processes the 'update' request before the 'create' one, it'll freak out. It has no idea what record needs updating, as the record hasn't been created yet.
对此的解决方案是通过管道传输 Ajax 请求，串行传输它们.脊柱默认情况下执行此操作，排队 POST、PUT 和 DELETE Ajax 请求，以便向它们发送一个一次.只有在前一个请求成功返回后才会发送下一个请求."
The solution to this is to pipeline Ajax requests, transmitting them serially. Spine does this by default, queuing up POST, PUT and DELETE Ajax requests so they're sent one at a time. The next request sent only after the previous one has returned successfully."
那么，我如何以编程方式创建 Alex Maccaw 提到的场景?
So, how can I programmatically create the scenario that Alex Maccaw mentions ?
推荐答案
我认为简而言之，您的问题的答案是是".
I think in short, the answer to your question is "yes".
HTTP 1.1 不禁止向同一个服务器打开多个 TCP 连接(实际上它推荐两个)，所有现代浏览器都这样做(实际上，大多数都这样做了六个或更多).请参阅浏览器中的最大并行 http 连接数?.请求-响应周期可以在这些连接中的每一个上进行，并且由于各种原因，某些请求-响应周期可能比其他周期快得多.网络拥塞、请求的复杂性、处理您的请求的特定工作人员"的速度和负载等.这意味着稍后启动的请求的请求-响应周期很容易比启动的请求周期更早完成早些.
HTTP 1.1 does not forbid opening multiple TCP connections to the same server (in fact it recommends two), and all modern browsers do so (in fact, most do six or more). See Max parallel http connections in a browser? . A request-response cycle can be going on on each of those connections, and some of the request-response cycles can be much faster than others, for various reasons. Network congestion, complexity of the request, speed of and load on the particular "worker" your request is processed by, etc. This means that a request-response cycle for a request started later could easily finish sooner than a cycle for a request started earlier.
"服务器必须以与请求相同的顺序发送对请求的响应已收到".
"A server MUST send its responses to requests in the same order that the requests were received".
该语句仅适用于管道化多个 http 请求，即通过一个 TCP 连接发送多个请求，而不等待每个请求的响应.它不适用于打开到同一服务器的多个 TCP 连接.
This statement solely applies to pipelining multiple http requests, i.e. sending multiple requests over one TCP connection, without waiting for a response for each request. It does not apply to opening multiple TCP connections to the same server.
通常，每个 tcp 连接同时只有一个请求.客户端等待响应，当它得到响应时，可能会为新请求重用连接.因此，就常规(非流水线)http 而言，甚至没有响应顺序"的概念，因为 TCP 连接上只有一个请求-响应循环.
Normally, you have only one request per tcp connection going on at the same time. The client waits for response, and when it gets response, perhaps reuses the connection for a new request. Thus, as far as regular (non-pipelined) http is concerned, there isn't even a concept of "order of responses", because there's only a single request-response cycle going on on a TCP connection.
通过流水线，在一个 TCP 连接上触发多个 http 请求.按顺序返回响应很重要，因为这是响应与其原始请求匹配的方式.(匹配对请求的响应可以以不同的方式完成，例如通过在每个响应上提供完整请求的哈希值，但这是无关紧要的).
With pipelining, multiple http requests are fired of on one TCP connection. It's important to get the responses back in order, because that's the way responses are matched to their original requests. (Matching responses to requests could have been done differently, for example by providing a hash of the full request on each response or so, but that's beside the point).
另外，很高兴知道(默认)对 HTTP 流水线的支持并不广泛.Chromium 项目不愿意启用它:https://insouciant.org/tech/status-of-http-pipelining-in-chromium/ .Firefox 仍然没有启用它.https://bugzilla.mozilla.org/show_bug.cgi?id=264354
Also, it's good to know that (default) support for HTTP pipelining is not broad. Chromium project is reluctant about enabling it: https://insouciant.org/tech/status-of-http-pipelining-in-chromium/ . Firefox still doesn't have it enabled either. https://bugzilla.mozilla.org/show_bug.cgi?id=264354
另一方面，Apple 在 IOS5 的 safari 中启用了对它的支持，可能是因为移动设备上的请求-响应延迟是一个更大的问题.http://www.guypo.com/mobile/ios5-top10-performance-变化/Android 股票浏览器也是如此.至少是 Chrome 之前的版本.http://www.guypo.com/mobile/http-pipelining-大移动/
Apple on the other hand has enabled support for it in safari on IOS5, probably because request-response latency on mobile is a bigger problem. http://www.guypo.com/mobile/ios5-top10-performance-changes/ Android stock browser does too. At least the pre-Chrome version. http://www.guypo.com/mobile/http-pipelining-big-in-mobile/
Alex Maccaw 在您引用的关于 Spine 的帖子中写道:
Alex Maccaw wrote in the post about Spine you cite:
解决这个问题的方法是管道 Ajax 请求，串行传输它们.
The solution to this is to pipeline Ajax requests, transmitting them serially.
我认为在这种情况下，管道这个词有点令人困惑.首先，Spine 所做的流水线"与 HTTP 中流水线请求的可能性完全不同.其次，我想我会称之为 Spine 请求队列的这个特殊功能.Spine 将请求排队，并按添加顺序处理队列中的项目.
I think the term pipeline is somewhat confusing in this context. First of all, the "pipelining" that Spine does is something wholly different than the possibility of pipelining requests in HTTP. Secondly, I think I'd call this particular feature of Spine request queuing. Spine queues requests, and processes the items in the queue in order they were added.
总的来说，我认为术语流水线"最适合用于有目的地加快速度的情况，而排队"最适合用于有目的地减慢速度(以防止竞争条件或减轻处理器的负载)例如排队的项目).
In general, I think the term "pipelining" is best used for when things are made purposively faster, while "queuing" is best used when making things purposively slower (to prevent race conditions, or to lighten load on the processor of the queued items, for example).
这篇关于是否可以使用 HTTP 接收乱序响应?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
