Chrome在向同一资源发出多个请求时会停滞不前？ [英] Chrome stalls when making multiple requests to same resource?

问题描述

我试图首次实现长轮询，并且我使用XMLHttpRequest对象来完成它。到目前为止，我在Firefox和Internet Explorer 11中获得了成功，但奇怪的是这次奇怪的是。

我可以加载一个页面，它运行得很好。它立即发出请求并开始处理和显示事件。如果我在第二个标签中打开该页面，则其中一个页面开始看到接收事件的延迟。在开发工具窗口中，我可以看到多种请求：

Stalled的范围可能高达20秒。它不会发生在每一个请求，但通常会发生在一个连续的几个请求，并在一个选项卡。

起初我认为这是我的问题服务器，但后来我打开了两个IE选项卡和两个Firefox选项卡，并且它们都连接并接收相同的事件而不会停滞。只有Chrome浏览器有这种麻烦。

我认为这可能是我提出或提供请求的方式的问题。作为参考，请求标题如下所示：

 连接：保持活动状态
 Last-Event-Id：530 
用户代理：Mozilla / 5.0（Windows NT 6.1; WOW64）AppleWebKit / 537.36（KHTML，如Gecko）Chrome / 39.0.2171.71 Safari / 537.36 
接受：* / * 
 DNT： 1 
接受编码：gzip，deflate，sdch 
接受语言：en-US，en; q = 0.8 
  

响应如下所示：

  HTTP / 1.1 200 OK 
 Cache -Control：no-cache 
 Transfer-Encoding：分块
内容类型：text / event-stream 
过期时间：2014年12月16日星期二21:00:40 GMT 
服务器：Microsoft-HTTPAPI / 2.0 
日期：2014年12月16日星期二21:00:40 GMT 
连接：关闭
  

尽管涉及到头文件，我并没有使用浏览器的本机EventSource，而是使用了polyfill来设置额外的头文件。 polyfill在封面下使用了XMLHttpRequest，但在我看来，不管请求是怎么做的，它都不应该停顿20秒。

什么可能导致Chrome浏览器崩溃？

编辑：Chrome的chrome：// net-internals /＃events页面显示超时错误涉及：

  t = 33627 [st = 5] HTTP_CACHE_ADD_TO_ENTRY [dt = 20001] 
  - > net_error = -409（ERR_CACHE_LOCK_TIMEOUT）
  

错误消息是指六个月前添加到Chrome的补丁 https://codereview.chromium.org/345643003 ），当相同的时间实现20秒的超时资源被多次请求。实际上，修补程序尝试修复的其中一个错误（错误号46104 ）指的是类似的情况，补丁的目的是减少等待的时间。

这可能是答案（或解决方法）这里只是为了让请求看起来不同，尽管也许Chrome可以尊重我设置的no-cache头。 解决方案

是的，此行为是由于Chrome锁定了缓存，并在再次请求相同资源之前等待查看一个请求的结果。答案是找到一种使请求独一无二的方法。我为查询字符串添加了一个随机数，现在一切正常。

为了将来的参考，这是Chrome 39.0.2171.95。

编辑：由于这个答案，我明白了Cache-Control：no-cache并没有达到我认为的效果。尽管它的名字，可以缓存这个头的响应。我还没有尝试过，但我想知道是否使用缓存控制：无存储，哪些会阻止缓存，可以解决问题。

I'm trying to implement long polling for the first time, and I'm using XMLHttpRequest objects to do it. So far, I've been successful at getting events in Firefox and Internet Explorer 11, but Chrome strangely is the odd one out this time.

I can load one page and it runs just fine. It makes the request right away and starts processing and displaying events. If I open the page in a second tab, one of the pages starts seeing delays in receiving events. In the dev tools window, I see multiple requests with this kind of timing:

"Stalled" will range up to 20 seconds. It won't happen on every request, but will usually happen on several requests in a row, and in one tab.

At first I thought this was an issue with my server, but then I opened two IE tabs and two Firefox tabs, and they all connect and receive the same events without stalling. Only Chrome is having this kind of trouble.

I figure this is likely an issue with the way in which I'm making or serving up the request. For reference, the request headers look like this:

Connection: keep-alive
Last-Event-Id: 530
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36
Accept: */*
DNT: 1
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8

The response looks like this:

HTTP/1.1 200 OK
Cache-Control: no-cache
Transfer-Encoding: chunked
Content-Type: text/event-stream
Expires: Tue, 16 Dec 2014 21:00:40 GMT
Server: Microsoft-HTTPAPI/2.0
Date: Tue, 16 Dec 2014 21:00:40 GMT
Connection: close

In spite of the headers involved, I'm not using the browser's native EventSource, but rather a polyfill that lets me set additional headers. The polyfill is using XMLHttpRequest under the covers, but it seems to me that no matter how the request is being made, it shouldn't stall for 20 seconds.

What might be causing Chrome to stall like this?

Edit: Chrome's chrome://net-internals/#events page shows that there's a timeout error involved:

t=33627 [st=    5]      HTTP_CACHE_ADD_TO_ENTRY  [dt=20001]
                --> net_error = -409 (ERR_CACHE_LOCK_TIMEOUT)

The error message refers to a patch added to Chrome six months ago (https://codereview.chromium.org/345643003), which implements a 20-second timeout when the same resource is requested multiple times. In fact, one of the bugs the patch tries to fix (bug number 46104) refers to a similar situation, and the patch is meant to reduce the time spent waiting.

It's possible the answer (or workaround) here is just to make the requests look different, although perhaps Chrome could respect the "no-cache" header I'm setting.

解决方案

Yes, this behavior is due to Chrome locking the cache and waiting to see the result of one request before requesting the same resource again. The answer is to find a way to make the requests unique. I added a random number to the query string, and everything is working now.

For future reference, this was Chrome 39.0.2171.95.

Edit: Since this answer, I've come to understand that "Cache-Control: no-cache" doesn't do what I thought it does. Despite its name, responses with this header can be cached. I haven't tried, but I wonder if using "Cache-Control: no-store", which does prevent caching, would fix the issue.

这篇关于Chrome在向同一资源发出多个请求时会停滞不前？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！