是否有可能接收乱序响应与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.
但后来，我读这帖子从亚历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请求所以他们派单 的时间。接下来的请求只有previous一个人成功返回后发送。
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."
那么，如何以编程方式创建方案亚历克斯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.
通过流水线，多个HTTP请求在一个TCP连接解雇的。重要的是要得到的答复回来秩序，因为这是响应匹配到原来的请求的方式。 （匹配响应请求本来可以做不同的，例如，通过提供对每个响应左右完整的请求散列，但这是题外话）。
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管线支持不广泛。铬项目是不愿意关于启用它： https://insouciant.org/高科技/地位HTTP流水式铬/ 。火狐还没有启用它无论是。 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
苹果另一方面使支持它在Safari上的IOS5，可能是因为在移动请求响应延迟是一个更大的问题。 http://www.guypo.com/mobile/ios5-top10-performance-更改/ Android的股票浏览器也会做。至少，pre-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/
亚历克斯Maccaw约脊柱后写道你举：
Alex Maccaw wrote in the post about Spine you cite:
的解决方案，这是对管线Ajax请求，串行地发送它们。
The solution to this is to pipeline Ajax requests, transmitting them serially.
我觉得长期管道是在这种情况下有些混乱。首先，在流水线即脊柱确实是除在HTTP管线请求的可能性完全不同。其次，我想我会打电话脊柱请求排队这个特定的功能。脊柱队列请求，并且为了它们添加处理在队列中的项目。
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.
在一般情况下，我认为，流水线一词，最好使用当事情有目的地更快做出的，而排队最好使事情有目的地较慢（时prevent的比赛条件下使用，或以减轻负担的排队项所述处理器，例如）。
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屋！
