Anforderung lange Zeit in Chrom

Question

gesperrt

Ajax Anforderung gelegentlich für eine lange Zeit in Chrom blockiert.

Endlich habe ich es geschafft, es zu reproduzieren und alle relevanten Daten zu speichern, die notwendig sind, um hier zu veröffentlichen, wenn mir jemand helfen könnte.

Die Zeitleiste von Chrome Dev-Tool zeigt die Anforderung für 42.62s wie die folgende Abbildung zeigt ins Stocken geraten:

und innerhalb der chrome://net-internals/#events Seite, die ich am meisten gefunden (für die Ereignisse bitte bis zum Ende log Kopf) Zeit wird durch zwei Ereignisse kosten:

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

erhalten beide ERR_CONNECTION_RESET.

Ich denke, der Fehler ist der Grund, warum die Anforderung so lange ins Stocken geraten.

Jeder könnte die Fehler erklären?

Folgenden sehen Sie die Voraussetzungen für den Antrag LOG, exportiere ich auch die volle Ereignisse wie json Sie von here erhalten können dann innerhalb der Seite Chrome chrome://net-internals/#events wiederherstellen. beachten Sie die URL interner vielleicht kippe Zugang vom öffentlichen Netz ist:

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

EDIT: in Verbindung stehende AusgabeIssue 447463: Chrome-network: Long delay before RST message on stale sockets results in slow page loads.

Answer 1

ich einmal ein ähnliches Problem aufgetreten. Die Ursache des Problems liegt darin, dass für jeden Browser die maximale Anzahl von TCP-Verbindungen zu einem Server begrenzt ist. Für Chrome ist das Limit sechs. Das Problem tritt bei Verwendung eines Proxy-Servers deutlicher hervor, da alle Anfragen auf demselben Server (dem Proxy-Server) laufen.

In Chrome können Sie dieses Limit nicht ändern. Es sollte eigentlich nicht sein. Wenn Sie mehr darüber erfahren möchten, warum dieses Limit existiert und welche Einschränkungen für andere Browser gelten, können Sie this article lesen.

Der Grund, warum dieses Limit selten ein Problem ist, liegt darin, dass mehrere HTTP-Anfragen an den gleichen Host meist nacheinander und nicht parallel, vorzugsweise über dieselbe TCP-Verbindung gesendet werden.

Wenn dieses Problem häufig zu Ihnen kommt, dann könnte der Grund sein:

1. Server nicht persistent TCP-Verbindung unterstützt: Wenn das Problem tritt nur auf, wenn einen bestimmten Server zugreift, der Grund könnte Sei es, dass Chrome mehrere Ressourcen (wie Bilder, CSS-Dateien usw.) auf parallelen Verbindungen holt. Da sich der Server in Ihrem Fall in Ihrem lokalen Netzwerk befindet, möchten Sie möglicherweise den Administrator des Servers bitten, Unterstützung für persistente TCP-Verbindungen hinzuzufügen.

2. mehrere persistente Verbindungen sind offen: Wenn Sie sich hinter einem Proxy-Server arbeiten, dann mehrere Dateien gleichzeitig oder Öffnen Websites herunterzuladen, die eine TCP-Verbindung offen halten könnte die Ursache Ihrer problem.To sein es loszuwerden, Alles, was Sie tun können, ist, nicht viele Dinge gleichzeitig herunterzuladen (oder in einem anderen Browser herunterladen, wenn Sie müssen).

PS: Der Fehler net_error = -101 (ERR_CONNECTION_RESET) nicht aufgrund ungültiger Header ist, es wegen der Zeitüberschreitung ist, für einige vorherige Verbindung zum Server warten, um zu schließen.

Answer 2

Ähnliches Problem hier und es scheint, dass nach einer Weile, ca. 3 Minuten eine Steckdose Chrom versucht zu verwenden ist geschlossen (ich nehme an) durch das Betriebssystem.

Dies ist auch als ein Fehler im Chrom-Forum aufgeführt. Ich vermute, Mangel an einer Art "keep-alive" Mechanismus .:

Meine Fehlermeldung ist etwas anders, aber es könnte aufgrund meiner Anwendung die Anrufe über SSL. Hier ist, was ich in Chrom sehen: // net-internals:

Erster Chrom findet eine vorhandene Steckdose und die Anforderung wird mit ihr verbunden (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 

Dann zurück in (URL_REQUEST) Sie werden sehen, es an der Zeit heraus, notieren sie die 10 Sekunden Ablauf in der Zeit von t = 1572 = 11.573 bis t:

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) 

Offensichtlich gibt es ein Timeout, wenn Chrom die Fenstergröße auf der vorhandenen Steckdose anzupassen versucht. Ich nehme an, dass dies auf Inaktivität am Socket zurückzuführen ist.

Ich werde versuchen, eine Art von Heartbeat-Anfrage bei vielleicht 60 Sekunden Intervall zu implementieren, um zu sehen, ob das Problem weiterhin besteht. Ich poste ein Update mit Ergebnissen.

UPDATE:

addierten die folgenden Code Javascript, die auf jeder Seite geladen wird. Dies wird einen leeren HTML-doc aus dem öffentlichen Stamm Abrufen:

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

Dies scheint die Buchse mit der Probe geöffnet sogar unter zeigt ca. 6 Minuten zwischen „echten“ nennt halten geholfen zu haben:

Bei 570B pro Anruf in 60-Sekunden-Intervallen würde der Ping-Anruf rund 800 KB Bandbreite pro 24 Stunden (pro Browser-Sitzung) hinzufügen. Ich bin mir nicht sicher, wie viel CPU-Overhead auf dem Server dies verursachen würde.

Zum Vergleich: Die VOR:

Es muss eine bessere Lösung sein, aber ich habe nicht in der Lage gewesen, eine noch zu lokalisieren.