La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Navigateurs web => Discussion démarrée par: vivien le 07 mars 2015 à 08:46:02
-
Chrome 41 est en cours de déploiement et il apporte une nouveauté que je n'ai pas vu mentionné : Il ouvre 2 connexions TCP dés le démarrage vers chaque destination, même si il a un seul fichier a télécharger.
Exemple en téléchargeant un fichier de 50 Mo : http://1.testdebit.info/fichiers/50Mo.dat
Chrome 40 : L'ouverture de la connexion TCP est entourée en rouge
(https://lafibre.info/testdebit/windows7/201503_chrome40_1connexion_tcp.png)
Chrome 41 : L'ouverture des 2 connexions TCP est entourée en rouge
(https://lafibre.info/testdebit/windows7/201503_chrome41_2connexions_tcp_1.png)
La seconde connexion est inutilisée et sera fermée à la fin du téléchargement :
(https://lafibre.info/testdebit/windows7/201503_chrome41_2connexions_tcp_2.png)
La première connexion TCP, elle est utilisée pour le téléchargement :
(https://lafibre.info/testdebit/windows7/201503_chrome41_2connexions_tcp_3.png)
Environnement :
- Hardware : Dell Inspiron 660, 8Go DDR3 et Core i3-2120 @3,3 Ghz
- OS : Windows 7 Édition Familiale Premium SP1 64bits pré-installé par Dell
- Réseau : Bbox ADSL Sagem F@st 3965b IPv4 uniquement
- Anti-virus : Microsoft Security Essentiales
- Navigateur : Chrome 40 64bits puis mise à jour vers Chrome 41 64bits
-
Bizarre, Windows 7 64bit Chrome 41 ici aussi et je n'ai qu'une seule connexion.
T'es sur que c'est Chrome qui ouvre les 2 connexions ? (fait une capture dans Chrome lui meme par exemple)
C'est général a toutes les connexions ou juste les téléchargements ?
-
J'ai fais pas mal de téléchargement et c'est systématique depuis Chrome 41.
Attention : j'ai la version 64bits de Chrome, la version par défaut proposée est toujours la version 32 bits.
Avec des OS serveurs plus anciens, comme le serveur bouygues.testdebit.info qui est sous Ubuntu 12.04 LTS, le serveur s’inquiète de ne pas voir de demande sur la seconde connexion ouverte et il va faire des retransmissions d’acquittement. On se retrouve entre le client et le serveurs qui se font régulièrement d'acquittements de rien, vu que rien n'a été envoyé ou demandé.
-
Donc c'est que les download pas le chargement des pages ? t'as pas une extension particulière ?
Il faut vraiment s'assurer que c'est Chrome qui ouvre les 2 connexions (avec TCPView (https://technet.microsoft.com/en-us/library/bb897437.aspx)par exemple ou "netstat -bn").
-
J'ai surtout étudié le download (les téléchargements de pages, il y de nombreuses connexions)
Cela fonctionne pour des fichiers plus petit comme http://1.testdebit.info/fichiers/1Mo.dat
C'est également le cas en https https://1.testdebit.info/fichiers/50Mo.dat (il y a alors un peu de trafic sur la seconde connexion pour ouvrir le SSL)
C'est un chrome sans extension, utilisé uniquement pour les tests.
Pour toi, la capture Wireshark n'est pas suffisante pour montrer la double ouverture de connexion ?
-
Peut-être que la 2e connexion est utilisée dès que la permière est coupée, pour ne pas interrompre le download.
-
Tu crois?
En général les serveurs n'aiment pas attendre une requête et ferment rapidement la connexion s'il n'y a rien.
-
Tu crois?
En général les serveurs n'aiment pas attendre une requête et ferment rapidement la connexion s'il n'y a rien.
Cette 2e connexion est bien initiée dans un but précis, en tout cas. D'ailleurs, il y a du keep-alive dessus ?
Par ex, tu as des situations où le débit chute à 0 Kbps et la connexion est toujours ouverte. Le navigateur peut rebalancer une requête sur la 2e avec du "Content-Range" pour reprendre le download.
Par défaut, le timeout sur Apache est de 300s. Moi j'ai l'habitude de baisser ça à 5s ou 10s, mais c'est pas le cas de tout le monde.
-
Pour toi, la capture Wireshark n'est pas suffisante pour montrer la double ouverture de connexion ?
La capture ne sait pas quel processus ouvre une connexion donc Wireshark ne "prouve" pas que c'est Chrome qui ouvre la 2eme connexion.
pour en etre sur: télécharge TCPLogView ( http://www.nirsoft.net/utils/tcp_log_view.html ), lance le en admin. puis fait un téléchargement. Ca indiquerait clairement quel programme fait quel connexion.
-
Voici la capture du fichier de 1Mo http://1.testdebit.info/fichiers/1Mo.dat
Il y a bien 2 connexions ouvertes dés le démarrage par Chrome.
La seconde connexion TCP n'est pas utilisée et sera fermée à la fin du téléchargement.
Le navigateur est Chrome 41 64 bits.
Pour changer, le système d'exploitation est Windows 10 Pro Technical Preview (Build 9926)
Le fichier lisible directement avec Wireshark : 201503_chrome41_testdebit_win10preview.pcapng.gz (https://lafibre.info/testdebit/windows10/201503_chrome41_testdebit_win10preview.pcapng.gz)
(https://lafibre.info/testdebit/windows10/201503_chrome41_testdebit_win10preview_1.png)
On remarque que si le serveur DNS ne répond pas très rapidement (26ms), une seconde requête DNS est envoyée, provoquant une seconde réponse :
(https://lafibre.info/testdebit/windows10/201503_chrome41_testdebit_win10preview_2.png)
Environnement :
- Hardware : HP Compaq 6510b, 4Go DDR2 et Core 2 Duo T8100 @2,1 Ghz
- OS : Windows 10 Pro 64bits Technical Preview (Build 9926)
- Anti-virus : Microsoft Security Essentiales
- Navigateur : Chrome 41 64bits
-
Test avec un petit site web : https://ip.lafibre.info/
Il y a bien 2 connexions ouvertes dès le démarrage par Chrome.
La seconde connexion TCP est utilisée et 2 autres seront ouvertes.
La 4ème et dernière connexion ouverte sera inutilisée.
Chrome ouvrirait toujours une connexion d'avance et donc aurait une connexion inutilisée ?
Le fichier lisible directement avec Wireshark : 201503_chrome41_old-linux_win10preview.pcapng.gz (https://lafibre.info/testdebit/windows10/201503_chrome41_old-linux_win10preview.pcapng.gz)
(https://lafibre.info/testdebit/windows10/201503_chrome41_old-linux_win10preview_1.png)
C'est quoi ces nombreuses requêtes NBNS envoyée vers le pauvre serveur web ?
(https://lafibre.info/testdebit/windows10/201503_chrome41_old-linux_win10preview_2.png)
Environnement :
- Hardware : HP Compaq 6510b, 4Go DDR2 et Core 2 Duo T8100 @2,1 Ghz
- OS : Windows 10 Pro 64bits Technical Preview (Build 9926)
- Anti-virus : Microsoft Security Essentiales
- Navigateur : Chrome 41 64bits
-
Tres curieux. je ne pense pas que ce soit 'normal' et ca serait 'too much' en terme de charge sur les serveurs si tout les Chrome 41 de la planète faisaient ca (meme non utilisée ouvrir une connexion a un cout coté serveur). Chez moi ca ne le fait pas en tout cas.
Chrome fait du prédictif mais la ca n'est pas vraiment la meme chose (le prédictif se désactive dans les paramètres avancés, section confidentialité,'Prélire les ressources pour charger les pages plus rapidement'). Mais je ne vois pas en quoi ca serait lié.
A part un test A/B auquel tu participes sans le savoir (c'est fréquent avec Google) je ne vois pas d'ou ça peut venir. Chrome étant très utilisé et particulièrement surveillé lors de la sortie d'un patch, si tu n'es pas le seul au monde à avoir ce comportement de Chrome 41, je pense d'ici quelques jours on en saura plus.
J'ai rien vu a ce sujet dans le bug tracker (https://code.google.com/p/chromium/issues/list) pour le moment en tout cas.
Essais avec Chrome Canary (https://www.google.com/chrome/browser/canary.html) sur le meme poste pour voir si ca fait pareil ( Canary peut s'installer sans pertuber le Chrome existant).
Fait aussi une capture interne a Chrome avec chrome://net-internals/#capture et regarde si on voit les 2 connections dedans.
-
J'ai le même comportement sous Chromium 41 amd64;
J'ai également le même comportement sous Chromium 40;
Au passage (c'est hors sujet!), je note que dans Chromium 41, il fait un premier GET avec un Range: bytes=3846-3846
Pourquoi ne pas faire un HEAD ?
-
Serveur : Ubuntu Server 14.10 64bits
Client : Chrome 41 64bits sous WIndows 8.1 64bits
Je confirme ce comportement quand il a déjà téléchargé le fichier mais que le cache a été vidé.
Voici ce que donne le téléchargement de http://1.testdbeit.info/fichiers/1Mo.dat pour la seconde fois (je suis obligé de vider le cache sans quoi il ne le télécharge pas une seconde fois)
J'applique le filtrage tcp.connection.syn || http.request || tcp.connection.fin qui permet de voir les connexions TCP, les get et la fermeture de la connexion.
Le fichier directement lisible avec Wireshark : 201503_chrome41_1testdebit_win81.pcapng.gz (https://lafibre.info/testdebit/windows8/201503_chrome41_1testdebit_win81.pcapng.gz)
Premier Get avec un range 1210-1210 :
(https://lafibre.info/testdebit/windows8/201503_chrome41_1testdebit_win81_1.png)
Deuxième Get avec un range 1210-999999 : (je suis étonné que cela permette de récupérer en entier le fichier de 1Mo)
(https://lafibre.info/testdebit/windows8/201503_chrome41_1testdebit_win81_2.png)
Caractéristique du serveur Ubuntu 14.10 64bit utilisé :
# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.10
Release: 14.10
Codename: utopic
# apache2 -v
Server version: Apache/2.4.10 (Ubuntu)
Server built: Jul 25 2014 10:24:21
# uname -a
Linux 1 3.16.0-31-generic #41-Ubuntu SMP Tue Feb 10 15:24:04 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Environnement du client :
- Hardware : Dell Inspiron 3847, 16Go DDR3 et Core i3-4150 @3,5 Ghz
- OS : Windows 8.1 64bits pré-installé par Dell
- Anti-virus : Microsoft Security Essentiales
- Navigateur : Chrome 41 64bits
-
Serveur : Ubuntu Server 12.04 64bits LTS
Client : Chrome 41 64bits sous Windows 8.1 64bits
Voici le comportement d'un Linux un peu plus ancien (Ubuntu 12.04 LTS avec noyau Linux 3.2) ! http://4.testdbeit.info/fichiers/1Mo.dat
Le serveur est étonné de l'absence de trafic sur la seconde connexion après l'ouverture et il renvoi un acquittement.
C'est systématique comme le montre ces 3 captures réalisées avec un serveur Ubuntu 12.04 LTS et un client Windows 8.1 + Chrome 41 64bits :
Capture 1 : (fichier lisible avec Wireshark : 201503_chrome41_4testdebit_win81_1.pcapng.gz (https://lafibre.info/testdebit/windows8/201503_chrome41_4testdebit_win81_1.pcapng.gz))
(https://lafibre.info/testdebit/windows8/201503_chrome41_4testdebit_win81_1.png)
Capture 2 :
(https://lafibre.info/testdebit/windows8/201503_chrome41_4testdebit_win81_2.png)
Capture 3 :
(https://lafibre.info/testdebit/windows8/201503_chrome41_4testdebit_win81_3.png)
Caractéristiques du serveur Ubuntu 12.04 utilisé :
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 12.04.5 LTS
Release: 12.04
Codename: precise
$ apache2 -v
Server version: Apache/2.2.22 (Ubuntu)
Server built: Jul 22 2014 14:35:25
$ uname -a
Linux 4 3.2.0-77-generic #112-Ubuntu SMP Tue Feb 10 15:22:22 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Environnement du client :
- Hardware : Dell Inspiron 3847, 16Go DDR3 et Core i3-4150 @3,5 Ghz
- OS : Windows 8.1 64bits pré-installé par Dell
- Anti-virus : Microsoft Security Essentiales
- Navigateur : Chrome 41 64bits
-
Serveur : CentOS 5 64bits
Client : Chrome 41 64bits sous Windows 8.1 64bits
Voici le comportement d'un Linux encore un peu plus ancien (CentOS 5 avec noyau Linux 2.6.18) !
Le serveur est étonné de l'absence de trafic sur la seconde connexion après l'ouverture et il renvoi 2 acquittements.
C'est systématique comme le montre ces 3 captures réalisées avec un serveur CentOS5 et un client Windows 8.1 + Chrome 41 64bits :
Capture 1 : (fichier lisible avec Wireshark : 201503_chrome41_5testdebit_win81_1.pcapng.gz (https://lafibre.info/testdebit/windows8/201503_chrome41_5testdebit_win81_1.pcapng.gz))
(https://lafibre.info/testdebit/windows8/201503_chrome41_5testdebit_win81_1.png)
Capture 2 : (fichier lisible avec Wireshark : 201503_chrome41_5testdebit_win81_2.pcapng.gz (https://lafibre.info/testdebit/windows8/201503_chrome41_5testdebit_win81_2.pcapng.gz))
(https://lafibre.info/testdebit/windows8/201503_chrome41_5testdebit_win81_2.png)
Capture 3 :
Ici, Chrome décide de ne pas télécharger le fichier qu'il a déjà téléchargé quelques seconde avant.
Il va quand même ouvrir deux connexions pour rien.
Voici la capture Wireshark complète des connexions avec le serveur sans filtrage : (fichier lisible avec Wireshark : 201503_chrome41_5testdebit_win81_3.pcapng.gz (https://lafibre.info/testdebit/windows8/201503_chrome41_5testdebit_win81_3.pcapng.gz))
(https://lafibre.info/testdebit/windows8/201503_chrome41_5testdebit_win81_3.png)
Caractéristiques du serveur CentOS 5 utilisé :
# lsb_release -a
LSB Version: :core-4.0-amd64:core-4.0-ia32:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-ia32:printing-4.0-noarch
Distributor ID: CentOS
Description: CentOS release 5.8 (Final)
Release: 5.8
Codename: Final
# httpd -v
Server version: Apache/2.2.3
Server built: Jun 6 2012 10:00:42
# uname -a
Linux srv001014 2.6.18-308.8.1.el5 #1 SMP Tue May 29 14:57:25 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
Environnement du client :
- Hardware : Dell Inspiron 3847, 16Go DDR3 et Core i3-4150 @3,5 Ghz
- OS : Windows 8.1 64bits pré-installé par Dell
- Anti-virus : Microsoft Security Essentiales
- Navigateur : Chrome 41 64bits
-
y'a 2 sujets distincts, double connexion et le 'range' du GET.
Pour la double connexion c'est, a priori mais a vérifier, un mécanisme propre a Chrome quand il détecte des mauvaises conditions de réseau: il ouvre un connexion de secours (backup) de facon a ne pas devoir attendre le timeout (3 secondes) de la première si jamais.
Il y une explication ici : https://insouciant.org/tech/connection-management-in-chromium/#tcp_backup_connect_jobs (c'est le blog d'un dev de Chromium)
C'est, a priori, implèmenté dans Chrome depuis assez longtemps d'ailleurs.
Pour l'autre sujet, le GET range , c'est pas du au prefetch ?
-
La connexion de secours ne serait qu'en cas de mauvaise connexion ? Comment il teste la connexion ?
Les tests Windows 8 et Windows 10 ont été réalisé en WiFI avec une Bbox 100 Mb/s.
Les tests Windows 7, c'est de l'ADSL avec une connexion Ethernet.
Le GET range, ce n'est pas lié au prefetch, mais au fait qu'on a déjà téléchargé le même fichier avant.
Moi aussi, il me semble qu'un HEAD semble fait pour cet usage...
-
La connexion de secours ne serait qu'en cas de mauvaise connexion ? Comment il teste la connexion ?
aucune idée sur ce point. Le code source de Chrome est assez 'lourdingue' a lire ;)
Je ne sais pas si c'est par 'host' ou de facon globale.
Par contre le blog précise bien qu'il n'y a qu'un backup par 'host' (n+1 connexions et pas n*2 connexions donc).
-
C'est bien ce que l'on voit avec le téléchargement de la petite page : https://old-linux.com/
Quand la 2ème connexion est utilisée, une 3ème est ouverte.
Quand la 3ème connexion est utilisée, une 4ème est ouverte (qui sera inutilisée)
Le fichier lisible directement avec Wireshark : 201503_chrome41_old-linux_win10preview.pcapng.gz (https://lafibre.info/testdebit/windows10/201503_chrome41_old-linux_win10preview.pcapng.gz)
Connexion TCP 1 ouverte à T = 0 ms avec le port source 50399
=> Téléchargement de / à T = 582ms
=> Téléchargement de /images/old-linux.css à T = 616ms
=> Téléchargement de /images/header_bg.png à T = 681ms
=> Téléchargement de /favicon.ico à T = 698ms
Connexion TCP 2 ouverte à T = 0 ms avec le port source 50400
=> Téléchargement de /images/old-linux.png à T = 682ms
Connexion TCP 3 ouverte à T = 681 ms avec le port source 50401
=> Téléchargement de /images/container_bg.png à T = 697ms
Connexion TCP 4 ouverte à T = 689 ms avec le port source 50402
=> Inutilisée
-
Serveur : Ubuntu Server 14.04 64bits LTS
Client : Firefox 36.0.1 sous Windows 8.1 64bits
J'ai repéré de temps en temps le même comportement avec Firefox 36.0.1 : Une connexion de secours (backup) est ouverte pendant 5 seconde après la demande de téléchargement, probablement pour ne pas devoir attendre le timeout (3 secondes) de la première si jamais il y avait un souci.
A noter que Firefox ferme la seconde connexion après 5 secondes, alors que le téléchargement du fichier de 50 Mo prend 95 secondes avec ma connexion à 5 Mb/s
Chrome, dans la même situation, laisserait la seconde connexion ouverte toute la durée du téléchargement.
Le fichier lisible directement avec Wireshark : 201503_firefox36_3testdebit_win7.pcapng.gz (https://lafibre.info/testdebit/windows7/201503_firefox36_3testdebit_win7.pcapng.gz) (j'ai limité le fichier aux 3000 premiers paquets, mais la durée totale de la première connexion est de 95 secondes)
Ce qui est entouré en rouge concerne la seconde connexion de secours :
(https://lafibre.info/testdebit/windows7/201503_firefox36_3testdebit_win7_1.png)
La seconde connexion de secours en entier :
(https://lafibre.info/testdebit/windows7/201503_firefox36_3testdebit_win7_2.png)
Environnement :
- Hardware : Dell Inspiron 660, 8Go DDR3 et Core i3-2120 @3,3 Ghz
- OS : Windows 7 Édition Familiale Premium SP1 64bits pré-installé par Dell
- Anti-virus : Microsoft Security Essentiales
- Navigateur : Firefox 36.0.1 (32bits)
- Réseau : Bbox ADSL Sagem F@st 3965b IPv4 uniquement connexion Ethernet (lien 1 Gb/s Ethernet entre le PC et la Bbox)
- Ligne ADSL : 5 Mb/s sans CRC (correction de pertes de paquet au niveau des couches basses)