demande bloquée pendant longtemps dans chrome
La requête Ajax est parfois bloquée pendant longtemps en chrome.
J'ai finalement réussi à le reproduire et à sauvegarder toutes les données connexes nécessaires pour poster ici si quelqu'un pouvait m'aider.
La timeline de Chrome Dev Tool affiche la demande bloquée pendant 42,62 secondes, comme le montre la capture d'écran suivante: 
et dans la page chrome://net-internals/#events (pour le journal des événements, veuillez vous rendre à la fin) que j'ai trouvé le plus de temps est coûté par deux événements:
- + HTTP_TRANSACTION_READ_HEADERS [dt = 21301]
- + HTTP_TRANSACTION_READ_HEADERS [dt = 21304]
les deux reçoivent ERR_CONNECTION_RESET.
Je pense que l'erreur est la raison pour laquelle la demande a calé pendant si longtemps.
Quelqu'un pourrait expliquer les erreurs?
SUIVANT IS LE JOURNAL DES ÉVÉNEMENTS POUR LA DEMANDE, j’exporte également l’ensemble des événements au format json que vous pouvez obtenir de ici puis restaurez-le dans le Chrome chrome://net-internals/#events page. notez que l'URL de la requête est interne, vous pouvez donc peut-être accéder au réseau public:
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_ALIVEEDIT: problème associé Problème 447463: Chrome-network: un délai très long avant qu'un message RST sur des sockets obsolètes ralentisse le chargement de la page.
J'ai déjà rencontré un problème similaire. La cause du problème est que chaque navigateur a une limite au nombre maximal de TCP connexions à un serveur. Pour le chrome, la limite est de six. Le problème est plus évident lorsque vous utilisez un serveur proxy, car toutes les demandes vont au même serveur (le serveur proxy).
Chrome ne vous permet pas de modifier cette limite. Cela ne devrait pas en fait. Si vous voulez en savoir plus sur les raisons de cette limite et sur celles des autres navigateurs, vous pouvez lire cet article .
La raison pour laquelle cette limite pose rarement problème est que plusieurs requêtes HTTP adressées au même hôte sont envoyées la plupart du temps de manière consécutive plutôt que parallèlement, de préférence via la même connexion TCP.
Si ce problème vous arrive fréquemment, alors la raison peut être:
Le serveur ne prend pas en charge la connexion persistante TCP: Si le problème se produit uniquement lors de l'accès à un serveur particulier, la raison peut être que chrome récupère plusieurs ressources (telles que des images, des fichiers CSS, etc.) sur des connexions parallèles. Étant donné que, dans votre cas, le serveur est sur votre réseau local, vous pouvez demander à l'administrateur du serveur d'ajouter la prise en charge des connexions persistantes TCP.
Plusieurs connexions persistantes sont ouvertes: Si vous travaillez derrière un serveur proxy, téléchargez plusieurs fichiers simultanément ou ouvrez des sites qui conservent un TCP. _ La connexion ouverte peut être la cause de votre problème. Pour vous en débarrasser, tout ce que vous pouvez faire est de ne pas télécharger beaucoup de choses en même temps (ou de télécharger dans un autre navigateur, si vous devez le faire).
PS: L'erreur net_error = -101 (ERR_CONNECTION_RESET) n'est pas due. En-têtes non valides, c'est à cause du délai d'attente qui attend la fermeture d'une connexion précédente au serveur.
Un problème similaire se présente ici et il semble qu'après un certain temps, environ 3 minutes, un socket chrome essayant de l'utiliser soit fermé (je suppose) par le système d'exploitation.
Ceci est également répertorié comme un bug dans le forum chrome. Je suppose qu’il n’ya pas de mécanisme de type "garder en vie".: https://code.google.com/p/chromium/issues/detail?id=44746
Mon message d'erreur est légèrement différent, mais cela peut être dû au fait que mon application effectue les appels via SSL. Voici ce que je vois en chrome: // net-internals:
First chrome trouve un socket existant et la requête lui est associée (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
Ensuite, dans (URL_REQUEST), vous verrez le délai expirer, notez le délai de 10 secondes entre t = 1572 et 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)
Il est clair qu'il y a un délai d'attente lorsque chrome tente de régler la taille de la fenêtre du socket existant. Je suppose que cela est dû à l'inactivité du socket.
Je vais essayer d'implémenter une sorte de demande de pulsation à un intervalle de 60 secondes environ pour voir si le problème persiste. Je posterai une mise à jour avec les résultats.
MISE À JOUR:
Ajout du code suivant à javascript chargé sur chaque page. Cela consiste à récupérer un document HTML vide à partir de la racine publique:
$(document).ready(function() {
$.keepalive =
setInterval(function() {
$.ajax({
url: '/ping.html',
cache: false
});
}, 60000);
});
Cela semble avoir aidé à garder le socket ouvert même avec l'exemple ci-dessous montrant environ 6 minutes entre les "vrais" appels:
À 570 milliards de dollars par appel toutes les 60 secondes, l’appel ping ajouterait environ 800 Ko d’utilisation de la bande passante par 24 heures (par session de navigateur). Je ne suis pas sûr de la surcharge de temps processeur sur le serveur.
À titre de comparaison, le AVANT:
Il doit y avoir une meilleure solution mais je n'ai pas encore réussi à en trouver une.