Auteur Sujet: Chrome 41 ouvre 2 connexions TCP systématiquement (une pour Chrome 40) (Lu 7266 fois)

jack · « **Réponse #12 le:** 08 mars 2015 à 00:18:29 »

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 ?

vivien · « **Réponse #13 le:** 08 mars 2015 à 10:30:45 »

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

Premier Get avec un range 1210-1210 :

Deuxième Get avec un range 1210-999999 : (je suis étonné que cela permette de récupérer en entier le fichier de 1Mo)

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

vivien · « **Réponse #14 le:** 08 mars 2015 à 11:16:04 »

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)

Capture 2 :

Capture 3 :

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

vivien · « **Réponse #15 le:** 08 mars 2015 à 11:53:10 »

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)

Capture 2 : (fichier lisible avec Wireshark : 201503_chrome41_5testdebit_win81_2.pcapng.gz)

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)

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

kgersen · « **Réponse #16 le:** 08 mars 2015 à 12:31:07 »

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 ?

vivien · « **Réponse #17 le:** 08 mars 2015 à 12:40:40 »

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...

kgersen · « **Réponse #18 le:** 08 mars 2015 à 12:58:50 »

Citation de: vivien le 08 mars 2015 à 12:40:40

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).

vivien · « **Réponse #19 le:** 08 mars 2015 à 13:12:51 »

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

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

vivien · « **Réponse #20 le:** 17 mars 2015 à 17:15:22 »

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 (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 :

La seconde connexion de secours en entier :

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)