Auteur Sujet: Problème débit - Service Google et OVH  (Lu 17599 fois)

0 Membres et 1 Invité sur ce sujet

kaktuss77

  • Abonné Orange Fibre
  • *
  • Messages: 598
  • Free 8G/700M + Orange 2G/1G <3
    • @kaktuss77
Problème débit - Service Google et OVH
« Réponse #24 le: 10 novembre 2016 à 13:54:31 »
@Pach, Yes j'ai été béta testeur  :P

@Vivien, j'ai ce phénomème aussi bien sur mes machines linux, windows ou encore android.

je vais voir pour trouver une solution définitive

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Problème débit - Service Google et OVH
« Réponse #25 le: 10 novembre 2016 à 13:59:02 »
Tu me disait avoir un bon débit en téléchargement un fichier tel que wget -O /dev/null http://1.testdebit.info/fichiers/1000Mo.dat

Serait-il possible de voir si les paquets sont dé-séquencé ?

Si on comprend pourquoi le problème arrive dans certains cas et pas d'autres on pourra peut être corriger le problème.

Note: Youtube utilise des flux UDP + QUIC dans certains cas avec Chrome en client.




En TCP/IP, la couche 4 est géré par le système d’exploitation et donc pas souvent mis à jour (il reste encore de nombreux Windows XP).
En UDP/QUIC, la couche 4 est géré par le navigateur et donc mis à jour de façon très régulière, ce qui lui permet de profiter des dernières amélioration.


Google veut accélérer Internet avec QUIC

QUIC (Quick UDP Internet Connections, prononcé 'quick' NdT : 'couic' en français) est un protocole de transport multiplexé au dessus d'UDP avec comme but principal de ne pas ajouter de délai de connexion supplèmentaire.

Robbie Shade, un Développeur de Google, a introduit QUIC dans une vidéo récente, avec comme avantages principaux :
- Tous les avantages de SPDY (multiplexage, priorités, etc.)
- Connexions sans délai supplèmentaire
- Régulation de la vitesse d'émission de paquets pour diminuer les pertes
- Propagation de la correction d'erreurs pour réduire les latences de retransmission
- Gestion de congestion adaptative (proche de TCP), diminuant les reconnexions pour les clients mobiles
- Chiffrement équivalent à TLS
- Chrome peut communiquer avec Google par QUIC dès aujourd'hui

QUIC gère la retransmission, les paquets manquants ou dans le désordre, quelque chose qu'UDP ne fait pas par défaut. Le multiplexage dans QUIC siginifie que le protocole utilise plusieurs canaux pour envoyer les données, donc si un paquet est perdu dans un des flux de données, les autres ne sont pas bloqués en attente de celui-ci, comme c'est le cas pour SPDY, qui fait du multiplexage mais sur un seul canal. Cette approche dans QUIC résoud le problème de Head-of-line blocking (blocage d'un ensemble de paquets en attente du premier) qui peut arriver durant les retransmissions TCP, d'après Shade.

Un des bénéfices majeurs de l'utilisation de QUIC est le fait qu'il ne requiert pas de phase de handshake au premier contact entre le client et le serveur, d'une façon plus ou moins proche de TCP Fast Open, qui a été en discussion depuis 2011 mais n'a pas connu de large adoption. Selon Shade, le handshake TCP peut prendre jusqu'à 300 ms sur une connexion transatlantique si TLS est utilisé, alors que QUIC peut réduire cette latence à 100 ms.

Un autre avantage de QUIC est que les canaux de communication ne sont pas définis par le couple IP+port mais par un ID, ce qui permet de continuer une connexion même en changeant de réseau, par exemple quitter une zone Wi-Fi et entrer dans le réseau mobile.

Toutes les connexions QUIC sont chiffrées selon un mécanisme spécifique détaillé dans le QUIC Crypto document.

Quand on lui demande pourquoi ne pas utiliser une version améliorée de TCP + TLS, Shade répond que tandis que TCP et TLS subissent des améliorations, les itérations du protocole et leur déploiement sont très lents, alors que QUIC est déployé au niveau client et non au niveau du noyau, permettant des itérations beaucoup plus rapides - "des semaines plutôt que des années".

D'après Shade, SPDY peut fonctionner au dessus de QUIC dans le futur, le rendant encore meilleur qu'actuellement. Certaines des leçons apprises et testées par Google en pratique avec QUIC pourraient se retrouver dans TCP dans le futur.

Actuellement, il y a un client et un serveur disponible dans Chromium, et QUIC est utilisé par google.com, GMail, YouTube, et d'autres services Google.
[/size]

Source : InfoQ le 15 avr. 2014 par Olivier Bourgain

kaktuss77

  • Abonné Orange Fibre
  • *
  • Messages: 598
  • Free 8G/700M + Orange 2G/1G <3
    • @kaktuss77
Problème débit - Service Google et OVH
« Réponse #26 le: 10 novembre 2016 à 14:01:09 »
le symptome est le même vers youtube quelque soit le navigateur, mais j'ai le meme soucis avec une update d'app sur le playstore par exemple.

Je fais une capture Wireshark avec un transfère complet d'un fichier de 10Mo

kaktuss77

  • Abonné Orange Fibre
  • *
  • Messages: 598
  • Free 8G/700M + Orange 2G/1G <3
    • @kaktuss77
Problème débit - Service Google et OVH
« Réponse #27 le: 10 novembre 2016 à 14:05:58 »
je joins la capture 201611_capture_bonding_6_lignes_adsl.pcap

Voici le rendu au shell

wget -O /dev/null http://1.testdebit.info/fichiers/10Mo.dat
--2016-11-10 14:03:17--  http://1.testdebit.info/fichiers/10Mo.dat
Résolution de 1.testdebit.info (1.testdebit.info)… 194.158.102.114, 2001:860:f70b:200::2
Connexion à 1.testdebit.info (1.testdebit.info)|194.158.102.114|:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 10000000 (9,5M)
Enregistre : «/dev/null»

100%[======================================>] 10 000 000  1,80MB/s   ds 5,5s

2016-11-10 14:03:23 (1,73 MB/s) - «/dev/null» enregistré [10000000/10000000]

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Problème débit - Service Google et OVH
« Réponse #28 le: 10 novembre 2016 à 14:27:14 »
Dans la capture on voit que les paquets arrivent dans un désordre complet, mais limité (les paquets en retard mettent moins de 200ys a arriver)

Il n'y a pas de retransmission TCP ici.

J'imagine que quand le débit est moindre, l'èmetteur a un comportement différent et il ré-èmet les paquets arrivés en retard, non ? (un même paquet est dans ce cas la visible deux fois)


kaktuss77

  • Abonné Orange Fibre
  • *
  • Messages: 598
  • Free 8G/700M + Orange 2G/1G <3
    • @kaktuss77
Problème débit - Service Google et OVH
« Réponse #29 le: 10 novembre 2016 à 14:33:13 »
je peux te faire une capture similaire avec un débit bloqué a 1méga pour une raison inconnue

Symbol

  • AS52075 Wifirst
  • Expert
  • *
  • Messages: 349
Problème débit - Service Google et OVH
« Réponse #30 le: 10 novembre 2016 à 14:46:38 »
Je vous joint les captures d'écrans pour 2 vidéos Youtube et les traceroutes vers les serveur respectif

traceroute to 173.194.5.28 (173.194.5.28), 30 hops max, 60 byte packets
 4  po115.sbg-g2-a75.fr.eu (188.165.9.73)  29.367 ms  42.345 ms  22.320 ms
 5  10.95.48.8 (10.95.48.8)  68.306 ms  34.220 ms 10.95.48.10 (10.95.48.10)  37.264 ms
 6  mad-3-4m.es.eu (91.121.215.219)  39.315 ms  27.574 ms  54.184 ms
 7  * * *
 8  108.170.244.161 (108.170.244.161)  46.946 ms  34.808 ms 108.170.244.225 (108.170.244.225)  35.256 ms
 9  209.85.251.155 (209.85.251.155)  35.214 ms 209.85.251.157 (209.85.251.157)  35.647 ms  34.644 ms
10  173.194.5.28 (173.194.5.28)  34.795 ms  41.848 ms  39.198 ms
Ce serait intéressant de savoir pourquoi tu es dirigé vers un serveur qui se trouve à Madrid...
Le DNS utilisé est-il le bon ou pas...

D'autre part il est toujours utile de désactiver le QUIC dans chrome://flags/

kaktuss77

  • Abonné Orange Fibre
  • *
  • Messages: 598
  • Free 8G/700M + Orange 2G/1G <3
    • @kaktuss77
Problème débit - Service Google et OVH
« Réponse #31 le: 10 novembre 2016 à 14:48:27 »
@Symbol: cela fait bien longtemps que je me sert plus de chrome mais merci pour l'info :)

Les serveurs DNS était ceux de OVH ISP, j'ai remit ceux de google, je testerais ce soir pour voir si c'est mieux

buddy

  • Expert
  • Abonné Free fibre
  • *
  • Messages: 15 098
  • Alpes Maritimes (06)
Problème débit - Service Google et OVH
« Réponse #32 le: 10 novembre 2016 à 19:44:18 »
Ce serait intéressant de savoir pourquoi tu es dirigé vers un serveur qui se trouve à Madrid...
Le DNS utilisé est-il le bon ou pas...

D'autre part il est toujours utile de désactiver le QUIC dans chrome://flags/

oui .. c'est bien un serveur google ?
Car je ne crois pas qu'OVH peere avec Google à madrid..  et au vu du saut 6, çà ressemble à un routeur OVH à Madrid, (sauf si le reverse est faux ... )

Hugues

  • AS2027 MilkyWan
  • Modérateur
  • *
  • Messages: 12 424
  • Lyon (69) / St-Bernard (01)
    • Twitter
Problème débit - Service Google et OVH
« Réponse #33 le: 10 novembre 2016 à 20:03:21 »
Ils peerent ensemble sur l'Espanix :)

buddy

  • Expert
  • Abonné Free fibre
  • *
  • Messages: 15 098
  • Alpes Maritimes (06)
Problème débit - Service Google et OVH
« Réponse #34 le: 10 novembre 2016 à 20:09:48 »
Ok, je pensais qu'ils utilisaient préférentiellement les 2 PNIs de Paris. (TH2 et GSW)

BadMax

  • Client Free adsl
  • Expert
  • *
  • Messages: 3 481
  • Malissard (26)
Problème débit - Service Google et OVH
« Réponse #35 le: 11 novembre 2016 à 09:36:48 »
C'est vrai qu'on dirait un problème de DNS/GeoLoc : Google semble envoyer en Espagne.

Chez Free, je pars sur un GGC pour cette vidéo.