請求在Chrome中偶爾長時間停頓

Question

Ajax請求在Chrome中偶爾會停頓很長時間。

我終於設法轉載它，並保存所有必要的相關數據，如果有人可以幫助我。

從Chrome瀏覽器開發工具的時間表顯示停滯42.62s如下面的屏幕截圖請求顯示：

和內chrome://net-internals/#events（對於事件日誌，請前往年底）頁面，我發現最時間由兩個事件成本：

• + HTTP_TRANSACTION_READ_HEADERS [DT = 21301]
• + HTTP_TRANSACTION_READ_HEADERS [DT = 21304]

均得到ERR_CONNECTION_RESET。

我認爲錯誤是爲什麼要求停頓了這麼久的原因。

任何人都可以解釋錯誤？

以下是本次活動的日誌記錄，我還將全部事件導出爲您可以從here獲得的json，然後在Chrome的chrome://net-internals/#events頁面中恢復。注意請求URL是從公共網絡內，所以也許着訪問：

193486: URL_REQUEST 
 
http://qa.tieba.baidu.com/release/getReleaseHistory?projectId=fum1.0.593 
 
Start Time: 2015-01-02 17:51:05.323 
 

 
t= 1 [st= 0] +REQUEST_ALIVE [dt=42741] 
 
t= 1 [st= 0] URL_REQUEST_DELEGATE [dt=0] 
 
t= 1 [st= 0] +URL_REQUEST_START_JOB [dt=42740] 
 
         --> load_flags = 339804160 (BYPASS_DATA_REDUCTION_PROXY | MAYBE_USER_GESTURE | REPORT_RAW_HEADERS | VERIFY_EV_CERT) 
 
         --> method = "GET" 
 
         --> priority = "LOW" 
 
         --> url = "http://qa.tieba.baidu.com/release/getReleaseHistory?projectId=fum1.0.593" 
 
t= 2 [st= 1]  URL_REQUEST_DELEGATE [dt=0] 
 
t= 2 [st= 1]  HTTP_CACHE_GET_BACKEND [dt=0] 
 
t= 2 [st= 1]  HTTP_CACHE_OPEN_ENTRY [dt=0] 
 
t= 2 [st= 1]  HTTP_CACHE_ADD_TO_ENTRY [dt=0] 
 
t= 2 [st= 1]  HTTP_CACHE_READ_INFO [dt=0] 
 
t= 2 [st= 1]  URL_REQUEST_DELEGATE [dt=0] 
 
t= 2 [st= 1]  +HTTP_STREAM_REQUEST [dt=2] 
 
t= 4 [st= 3]  HTTP_STREAM_REQUEST_BOUND_TO_JOB 
 
          --> source_dependency = 193488 (HTTP_STREAM_JOB) 
 
t= 4 [st= 3]  -HTTP_STREAM_REQUEST 
 
t= 4 [st= 3]  +HTTP_TRANSACTION_SEND_REQUEST [dt=0] 
 
t= 4 [st= 3]  HTTP_TRANSACTION_SEND_REQUEST_HEADERS 
 
          --> GET /release/getReleaseHistory?projectId=fum1.0.593 HTTP/1.1 
 
           Host: qa.tieba.baidu.com 
 
           Connection: keep-alive 
 
           Accept: application/json, text/plain, */* 
 
           User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36 
 
           Referer: http://qa.tieba.baidu.com/project/ 
 
           Accept-Encoding: gzip, deflate, sdch 
 
           Accept-Language: en-US,en;q=0.8 
 
           Cookie: [268 bytes were stripped] 
 
t= 4 [st= 3]  -HTTP_TRANSACTION_SEND_REQUEST 
 
t= 4 [st= 3]  +HTTP_TRANSACTION_READ_HEADERS [dt=21301] 
 
t= 4 [st= 3]  HTTP_STREAM_PARSER_READ_HEADERS [dt=21301] 
 
          --> net_error = -101 (ERR_CONNECTION_RESET) 
 
t=21305 [st=21304]  HTTP_TRANSACTION_RESTART_AFTER_ERROR 
 
          --> net_error = -101 (ERR_CONNECTION_RESET) 
 
t=21305 [st=21304]  -HTTP_TRANSACTION_READ_HEADERS 
 
t=21305 [st=21304]  +HTTP_STREAM_REQUEST [dt=3] 
 
t=21307 [st=21306]  HTTP_STREAM_REQUEST_BOUND_TO_JOB 
 
          --> source_dependency = 193494 (HTTP_STREAM_JOB) 
 
t=21308 [st=21307]  -HTTP_STREAM_REQUEST 
 
t=21308 [st=21307]  +HTTP_TRANSACTION_SEND_REQUEST [dt=3] 
 
t=21308 [st=21307]  HTTP_TRANSACTION_SEND_REQUEST_HEADERS 
 
          --> GET /release/getReleaseHistory?projectId=fum1.0.593 HTTP/1.1 
 
           Host: qa.tieba.baidu.com 
 
           Connection: keep-alive 
 
           Accept: application/json, text/plain, */* 
 
           User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36 
 
           Referer: http://qa.tieba.baidu.com/project/ 
 
           Accept-Encoding: gzip, deflate, sdch 
 
           Accept-Language: en-US,en;q=0.8 
 
           Cookie: [268 bytes were stripped] 
 
t=21311 [st=21310]  -HTTP_TRANSACTION_SEND_REQUEST 
 
t=21311 [st=21310]  +HTTP_TRANSACTION_READ_HEADERS [dt=21304] 
 
t=21311 [st=21310]  HTTP_STREAM_PARSER_READ_HEADERS [dt=21304] 
 
          --> net_error = -101 (ERR_CONNECTION_RESET) 
 
t=42615 [st=42614]  HTTP_TRANSACTION_RESTART_AFTER_ERROR 
 
          --> net_error = -101 (ERR_CONNECTION_RESET) 
 
t=42615 [st=42614]  -HTTP_TRANSACTION_READ_HEADERS 
 
t=42615 [st=42614]  +HTTP_STREAM_REQUEST [dt=12] 
 
t=42627 [st=42626]  HTTP_STREAM_REQUEST_BOUND_TO_JOB 
 
          --> source_dependency = 193498 (HTTP_STREAM_JOB) 
 
t=42627 [st=42626]  -HTTP_STREAM_REQUEST 
 
t=42627 [st=42626]  +HTTP_TRANSACTION_SEND_REQUEST [dt=2] 
 
t=42627 [st=42626]  HTTP_TRANSACTION_SEND_REQUEST_HEADERS 
 
          --> GET /release/getReleaseHistory?projectId=fum1.0.593 HTTP/1.1 
 
           Host: qa.tieba.baidu.com 
 
           Connection: keep-alive 
 
           Accept: application/json, text/plain, */* 
 
           User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36 
 
           Referer: http://qa.tieba.baidu.com/project/ 
 
           Accept-Encoding: gzip, deflate, sdch 
 
           Accept-Language: en-US,en;q=0.8 
 
           Cookie: [268 bytes were stripped] 
 
t=42629 [st=42628]  -HTTP_TRANSACTION_SEND_REQUEST 
 
t=42629 [st=42628]  +HTTP_TRANSACTION_READ_HEADERS [dt=112] 
 
t=42629 [st=42628]  HTTP_STREAM_PARSER_READ_HEADERS [dt=112] 
 
t=42741 [st=42740]  HTTP_TRANSACTION_READ_RESPONSE_HEADERS 
 
          --> HTTP/1.1 200 OK 
 
           Date: Fri, 02 Jan 2015 09:51:48 GMT 
 
           Content-Type: application/json; charset=UTF-8 
 
           Transfer-Encoding: chunked 
 
           Connection: keep-alive 
 
           Cache-Control: no-cache 
 
           tracecode: 31079600320335034634010217 
 
           tracecode: 31079600320537995786010217 
 
           Server: Apache 
 
t=42741 [st=42740]  -HTTP_TRANSACTION_READ_HEADERS 
 
t=42741 [st=42740]  HTTP_CACHE_WRITE_INFO [dt=0] 
 
t=42741 [st=42740]  HTTP_CACHE_WRITE_DATA [dt=0] 
 
t=42741 [st=42740]  HTTP_CACHE_WRITE_INFO [dt=0] 
 
t=42741 [st=42740]  URL_REQUEST_DELEGATE [dt=0] 
 
t=42741 [st=42740] -URL_REQUEST_START_JOB 
 
t=42741 [st=42740] URL_REQUEST_DELEGATE [dt=0] 
 
t=42741 [st=42740] HTTP_TRANSACTION_READ_BODY [dt=0] 
 
t=42741 [st=42740] HTTP_CACHE_WRITE_DATA [dt=0] 
 
t=42741 [st=42740] HTTP_TRANSACTION_READ_BODY [dt=0] 
 
t=42741 [st=42740] HTTP_CACHE_WRITE_DATA [dt=0] 
 
t=42742 [st=42741] -REQUEST_ALIVE

編輯：相關的問題Issue 447463: Chrome-network: Long delay before RST message on stale sockets results in slow page loads.

Answer 1

我曾經遇到過類似的問題。問題的原因是每個瀏覽器都有一個到服務器的最大TCP連接數的限制。對於鉻，限制是六。當您使用代理服務器時，問題更加突出，因爲所有請求都轉到同一臺服務器（代理服務器）。

Chrome不允許您更改此限制。事實上它不應該。如果您想了解更多關於此限制存在的原因以及其他瀏覽器的限制，請參閱this article。

該限制很少成爲問題的原因是因爲對同一主機的多個HTTP請求大多是連續發送的，而不是並行發送，最好是在同一個TCP連接上發送。

如果頻繁發生給你這個問題，那麼原因可能是：如果只訪問特定服務器時，該原因可能出現問題：

1. 服務器不支持持續的TCP連接是鉻在並行連接上獲取多個資源（如圖像，CSS文件等）。因爲在你的情況下，服務器位於你的本地網絡上，所以你可能要求服務器的管理員增加對永久TCP連接的支持。

2. 多個持久連接打開：如果您正在使用代理服務器，然後同時下載多個文件或打開它保持TCP連接開放可能是你problem.To事業擺脫它的網站，你所能做的就是不要同時下載很多東西（或者在不同的瀏覽器中下載，如果你需要的話）。

PS：錯誤net_error = -101（ERR_CONNECTION_RESET）不會因無效的頭，那是因爲超時，等待一些以前的連接到服務器關閉。

Answer 2

類似的問題在這裏，它似乎是一段時間後，約3分鐘一個套接字鉻試圖使用關閉（我假設）的操作系統。

這也被列爲鉻論壇的錯誤。我猜缺乏某種「保持活着」的機制。： https://code.google.com/p/chromium/issues/detail?id=447463

我的錯誤消息是稍有不同，但它可能是由於我的應用程序通過SSL進行調用。下面是我在Chrome中看到：//網內部：

首先鉻找到現有的插座和請求與它（HTTP_STREAM_JOB）相關：

t=1572 [st=0] HTTP2_SESSION_POOL_FOUND_EXISTING_SESSION 
        --> source_dependency = 1347215 (HTTP2_SESSION) 
    t=1572 [st=0] HTTP_STREAM_JOB_BOUND_TO_REQUEST 
        --> source_dependency = 1348612 (URL_REQUEST) 
    t=1572 [st=0] -HTTP_STREAM_JOB 

然後回（URL_REQUEST），你會看到它超時時，請注意10秒經過從t時間= 1572至t = 11573：

t= 1572 [st= 0] HTTP2_SESSION_SEND_DATA 
         --> fin = true 
         --> size = 48 
         --> stream_id = 3 
    t= 1572 [st= 0] HTTP2_SESSION_UPDATE_SEND_WINDOW 
         --> delta = -48 
         --> window_size = 2147483551 
    t=11573 [st=10001] HTTP2_SESSION_CLOSE 
         --> description = "Failed ping." 
         --> net_error = -352 (ERR_SPDY_PING_FAILED) 

很明顯，有鉻時試圖將現有插座上調整窗口大小的超時。我認爲這是由於插座不活動。

我打算嘗試在60秒間隔內實施某種心跳請求，以查看問題是否仍然存在。我將發佈更新結果。

更新：

將以下代碼添加到每個頁面上加載的javascript。這是從公共根檢索一個空的HTML文檔：

$(document).ready(function() { 
     $.keepalive =  
       setInterval(function() { 
        $.ajax({ 
         url: '/ping.html', 
         cache: false 
        });   
       }, 60000);  
    }); 

這似乎有助於保持套接字打開，即使下面顯示大約之間「真正的」 6分鐘樣品要求：

在60秒間隔內，每次呼叫570B時，ping呼叫會增加每24小時約800kb的帶寬使用量（每個瀏覽器會話）。我不知道這會導致多少CPU的開銷。

相比之下，BEFORE：

必須有一個更好的解決辦法，但我一直沒能找到一個還沒有。