Ça rame ! Petite histoire d’un problème de réseau
Depuis plusieurs jours, ça rame chez moi. Ça arrive à tout le monde, on est en Calédonie et j’ai une éligibilité à 4Mb/s, donc je ne m’attends pas à des miracles, mais je ressens cette lenteur de façon intermittente beaucoup plus souvent que d’habitude, alors j’ai décidé d’investiguer. Mon premier réflexe, parce que c’est le plus simple, c’est d’aller sur fast.com pour vérifier mon débit avec un speedtest simple qui m’indique que mon débit est de… 170kbps.
Clairement, c’est lent ! Je vérifie mon éligibilité sur le site de l’OPT en entrant juste le numéro de téléphone de ma ligne :
Avec mon éligibilité à 4Mb/s, je devrais avoir un résultat en gros à 4Mb/s, ou en tous cas au moins à 1Mb/s si c’est en période de forte utilisation du réseau le soir par exemple (mais là c’est le matin, il n’y a pas de raison que ça soit si lent !). Avant de de m’énerver contre mon fournisseur d’accès à internet et contre l’OPT, je vais essayer d’en savoir un peu plus.
Le diagnostic
Est-ce mon PC qui est lent ? Est-ce le réseau local? Est-ce le routeur, le modem, la ligne, l’OPT, mon fournisseur d’accès, le câble sous-marin, un ou des serveurs distants ? Je pars généralement du plus proche (mon PC) pour commencer mes investigations, car c’est là que j’ai le plus de possibilités, alors que de l’autre côté, je n’ai pas beaucoup de moyens de tester et d’agir sur l’OPT ou le réseau international par moi-même. Si le problème ne semble pas s’y trouver, j’avance élément par élément du plus proche vers le plus éloigné.
Mon PC
Même si le problème semble lié au réseau, je préfère toujours m’assurer que ce n’est pas simplement mon PC qui ralentit. Pour vérifier, il suffit de noter à quelle moment la lenteur se fait ressentir, si cela correspond à une utilisation du réseau ou à un logiciel, et de regarder les autres logiciels qui tournent pendant les ralentissement. Dans mon cas, c’est clairement lors de l’utilisation du réseau (avec le navigateur ou en ligne de commande SSH), alors qu’aucun autre logiciel n’est lancé. Je passe donc à la suite du diagnostic avec le réseau local.
Le réseau local
Il y a plusieurs choses à vérifier au niveau du réseau, le premier test c’est de vérifier si le problème apparaît en wifi comme en câble. Je suis câblée habituellement, mais le problème apparaît de la même façon en wifi, ça ne vient donc pas de la connexion entre mon PC et le routeur. Les autres PC du réseau subissent les mêmes ralentissements, et au même moment, ça semble donc être un problème qui affecte tout le réseau, et pas un problème au sein du réseau.
Pour valider mon hypothèse, j’ai effectué un traceroute, qui me permet de connaître la latence (le ping) entre mon PC et une IP distante, pour chacun des équipements entre les 2 . Je fais généralement le test vers le serveur DNS public de Google à l’adresse 8.8.8.8 pour avoir un hôte distant assez sûr et assez loin pour tester jusqu’en dehors de la Nouvelle-Calédonie :
mtr 8.8.8.8
On observe grâce à cette commande que le problème de lenteur est en fait un problème de latence. Les paquets mettent moins d’un millième de seconde pour accéder à mon routeur, et mettent ensuite presque 2 secondes pour arriver jusqu’à mon FAI. La suite du traceroute ne semble être qu’une conséquence de cette partie du réseau, c’est normal que tout ce qui est après soit également très lent. Et en plus, je perds entre 25 et 40% des paquets à partir de mon routeur.
Le routeur et le modem
L’hypothèse la plus probable à ce stade est une défaillance du modem. Dans mon cas, le routeur et le modem sont 2 boîtiers séparés, mais ils sont très souvent combinés en un modem-routeur.
La connexion ADSL en Nouvelle-Calédonie se fait en PPPoE, le modem n’est pas un équipement « visible » sur le réseau TCP/IP. Il peut être à l’origine des ralentissements, et c’est généralement de ce côté qu’il y a un problème. J’ai donc commencé par changer le modem, sans aucune amélioration. J’ai également changé le filtre ADSL, et le câble RJ11 reliant le modem au filtre ADSL : aucune amélioration non plus.
Le routeur est au cœur du réseau, il peut très bien être à l’origine des ralentissements, en plus c’est à partir de lui que tout se ralentit. J’ai commencé par changer le câble ethernet reliant le routeur au modem, sans amélioration. Puis j’ai fait un reset de mon routeur, que j’ai ensuite reconfiguré avec les paramètres les plus basiques pour m’assurer que ça n’est pas un problème de configuration : pas mieux. J’ai fini par changer le routeur par un autre : toujours la même chose.
La ligne ADSL et le FAI
Logiquement, je me suis tournée vers mon FAI pour lui demander des explications. Il m’a assuré qu’il n’avait aucun problème sur ses équipements, qu’il ne voyait aucun défaut sur ma ligne, et que la connexion PPPoE entre mon modem et ses équipements était stable. Je le crois volontiers, puisqu’il y a des moments où tout fonctionne parfaitement, j’ai un débit à l’international proche de mon éligibilité et où tout se passe bien, et si mon FAI avait des problèmes sur ses équipements, je ne serais pas la seule à m’en plaindre !
Le réseau international
Dans mon cas actuel, le réseau international semble être hors de cause puisque j’ai pu constater que la latence apparaît entre mon routeur et mon FAI. Cependant, quand les lenteurs ne sont pas à cet endroit du réseau, il peut être intéressant d’investiguer plus loin pour vérifier si les lenteurs ne sont pas dues au service auquel on souhaite accéder sur internet. On peut avoir une bonne idée en faisant un traceroute vers différents serveurs (et se rendre compte par la même occasion que les services en Europe sont à plus de 300ms de nous, alors que l’Australie est 10 fois moins loin en termes de latence réseau !)
Et alors, c’est quoi le problème ?
J’ai tout vérifié et rien trouvé. C’est souvent comme ça, on ne trouve pas du premier coup, mais cette première étape du diagnostic permet de passer à la suite avec déjà beaucoup plus d’informations sur le problème. Voilà ce que je sais :
- j’ai des problèmes de latence, de façon intermittente
- mon réseau local ne pose pas de problèmes
- la latence apparaît à partir de mon routeur
- mes équipements ne sont pas défaillants (tout a été changé)
- il n’y a pas de problèmes sur ma ligne et chez mon FAI
Si le problème apparaît de façon intermittente, et que ça n’est pas un problème matériel ou de configuration, alors cela ressemble à un problème lié à l’utilisation du réseau. Pour vérifier, je vais voir les graphs d’utilisation sur l’interface de mon routeur, tout en faisant un ping continu vers la première IP de mon FAI pour vérifier sur le graph à quel moment la latence apparaît :
Dans ce graph, le rose correspond au Rx (octets reçus = download), et le violet au Tx (octets transmis = envoyés = upload). Les périodes de ralentissement correspondent au moment où le routeur envoie beaucoup de données vers internet. Je remarque aussi que le débit maximum d’envoi (825kb/s) dépasse largement l’éligibilité théorique de ma ligne (512kb/s), et plutôt que de m’en réjouir, je me dis que c’est peut être une piste : ça ne devrait pas aller aussi haut !
C’est quoi ce trafic ?
Ma première interrogation, c’est tout de même de savoir ce qui est envoyé. Je n’ai rien sur mon réseau qui est censé envoyer autant de données, et mon routeur ne me dit pas d’où vient ces envois (il aurait pu me le dire si j’avais un seul équipement par port, mais j’ai un switch et tout vient du même port). Je vais donc utiliser une technique très sophistiquée pour en savoir plus : je débranche un par un les équipements du réseau dès que les ralentissements apparaissent.
En quelques minutes à peine, j’ai trouvé le coupable : un des PC du réseau, qui semble pourtant assez banal, je n’aurais pas parié dessus. Les ralentissements cessent à la seconde où je le débranche, et j’ai testé plusieurs fois pour être sûre. Reste maintenant à savoir ce qu’il envoie, et vers où. Le PC est sous Linux, je peux voir assez rapidement ce qui se passe sur le réseau grâce à la commande iftop :
sudo iftop -i interface1
whois 1e100.net Domain Name: 1E100.NET Registry Domain ID: 1570253561_DOMAIN_NET-VRSN Registrar WHOIS Server: whois.markmonitor.com Registrar URL: http://www.markmonitor.com Updated Date: 2010-09-15T17:45:17Z Creation Date: 2009-09-25T05:40:03Z Registry Expiry Date: 2019-09-25T05:40:03Z Registrar: MarkMonitor Inc. Registrar IANA ID: 292 Registrar Abuse Contact Email: abusecomplaints@markmonitor.com Registrar Abuse Contact Phone: +1.2083895740 Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited Domain Status: clientRenewProhibited https://icann.org/epp#clientRenewProhibited Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited Domain Status: serverDeleteProhibited https://icann.org/epp#serverDeleteProhibited Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited Domain Status: serverUpdateProhibited https://icann.org/epp#serverUpdateProhibited Name Server: NS1.GOOGLE.COM Name Server: NS2.GOOGLE.COM Name Server: NS3.GOOGLE.COM Name Server: NS4.GOOGLE.COM DNSSEC: unsigned URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/ >>> Last update of whois database: 2017-12-25T23:07:09Z <<<
Bon, pas super clair comme réponse. Une recherche m’en apprend plus, directement chez Google :
C’est donc un serveur Google. Quelques recherches plus loin, et il apparaît que c’est Google Chrome qui envoie des données à Google. Au delà des considérations éthiques peu rassurantes sur le respect de la vie privée, ces uploads ne m’arrangent pas, mais je ne peux pas les contrôler. Et ça n’explique pas pourquoi ça ralentit autant.
Trop d’upload tue la latence ?
Bon, avec ce que je sais désormais, l’hypothèse la plus logique semble être qu’essayer d’uploader trop de données d’un coup est la cause des ralentissements de ma connexion internet. Avant d’agir, je veux m’assurer que c’est bien le cas. Je vais donc mettre en place un test d’upload où je contrôle vitesse d’upload.
Tout d’abord, je lance un ping vers la 1ère IP de mon FAI pour observer les changements de latence au fur et à mesure des tests :
ping ip1.fai 64 bytes from ip1.fai: icmp_seq=1 ttl=254 time=8.32 ms 64 bytes from ip1.fai: icmp_seq=2 ttl=254 time=8.21 ms 64 bytes from ip1.fai: icmp_seq=3 ttl=254 time=7.87 ms 64 bytes from ip1.fai: icmp_seq=4 ttl=254 time=8.31 ms
Quand il ne se passe rien d’autre sur le réseau, j’ai une latence d’environ 8ms, c’est donc ma valeur de référence.
J’ai la chance de disposer d’un serveur dédié en Nouvelle-Calédonie avec lequel je peux faire des tests, ce qui m’assure de ne pas subir les éventuelles latences vers l’international. Sur ce serveur, j’ouvre un port (au hasard le 8888) en écoute avec netcat (nc) pour recevoir n’importe quelles données, que je mets directement à la poubelle dans /dev/null (les données en elles-même ne m’intéressent pas, j’essaye juste de saturer la bande passante de ma connexion) :
nc -l -p 8888 > /dev/null
Sur mon PC dans mon réseau local, je choisis un gros fichier quelconque (ici une image Raspbian) que je vais envoyer à mon serveur avec netcat également, mais en contrôlant la vitesse d’upload avec pv. Pour le premier test, j’envoie à 20ko/s, ce qui correspond à 160kb/s. Mon éligibilité est de 512kb/s, ça devrait donc largement passer :
pv -r -L20k RaspberryPi/RaspBian.iso.gz |nc monserveur 8888
Aucun problème de latence avec ce premier test, je monte à 60ko/s = 480kb/s, soit juste en dessous de mon éligibilité :
pv -r -L60k RaspberryPi/RaspBian.iso.gz |nc monserveur 8888
Côté latence, ça augmente un peu (bon 10 fois plus qu’au repos, certes), mais ça reste très acceptable, et surtout assez peu perceptible humainement :
64 bytes from ip1.fai: icmp_seq=258 ttl=254 time=95.7 ms 64 bytes from ip1.fai: icmp_seq=259 ttl=254 time=94.8 ms 64 bytes from ip1.fai: icmp_seq=260 ttl=254 time=93.9 ms 64 bytes from ip1.fai: icmp_seq=261 ttl=254 time=92.4 ms 64 bytes from ip1.fai: icmp_seq=262 ttl=254 time=90.9 ms 64 bytes from ip1.fai: icmp_seq=263 ttl=254 time=92.8 ms
J’augmente la vitesse à 65ko/s = 520kb/s, soit juste au dessus de mon éligibilité :
pv -r -L65k RaspberryPi/RaspBian.iso.gz |nc monserveur 8888
64 bytes from ip1.fai: icmp_seq=392 ttl=254 time=8.54 ms 64 bytes from ip1.fai: icmp_seq=393 ttl=254 time=18.3 ms 64 bytes from ip1.fai: icmp_seq=394 ttl=254 time=182 ms 64 bytes from ip1.fai: icmp_seq=395 ttl=254 time=233 ms 64 bytes from ip1.fai: icmp_seq=396 ttl=254 time=197 ms 64 bytes from ip1.fai: icmp_seq=397 ttl=254 time=250 ms 64 bytes from ip1.fai: icmp_seq=398 ttl=254 time=280 ms 64 bytes from ip1.fai: icmp_seq=399 ttl=254 time=317 ms 64 bytes from ip1.fai: icmp_seq=400 ttl=254 time=348 ms 64 bytes from ip1.fai: icmp_seq=401 ttl=254 time=481 ms 64 bytes from ip1.fai: icmp_seq=402 ttl=254 time=541 ms 64 bytes from ip1.fai: icmp_seq=403 ttl=254 time=563 ms 64 bytes from ip1.fai: icmp_seq=404 ttl=254 time=724 ms 64 bytes from ip1.fai: icmp_seq=405 ttl=254 time=738 ms 64 bytes from ip1.fai: icmp_seq=406 ttl=254 time=776 ms 64 bytes from ip1.fai: icmp_seq=407 ttl=254 time=828 ms 64 bytes from ip1.fai: icmp_seq=408 ttl=254 time=858 ms 64 bytes from ip1.fai: icmp_seq=409 ttl=254 time=799 ms 64 bytes from ip1.fai: icmp_seq=410 ttl=254 time=839 ms 64 bytes from ip1.fai: icmp_seq=411 ttl=254 time=903 ms 64 bytes from ip1.fai: icmp_seq=412 ttl=254 time=960 ms 64 bytes from ip1.fai: icmp_seq=413 ttl=254 time=1054 ms 64 bytes from ip1.fai: icmp_seq=414 ttl=254 time=1186 ms 64 bytes from ip1.fai: icmp_seq=415 ttl=254 time=1227 ms 64 bytes from ip1.fai: icmp_seq=416 ttl=254 time=1316 ms 64 bytes from ip1.fai: icmp_seq=417 ttl=254 time=1409 ms 64 bytes from ip1.fai: icmp_seq=418 ttl=254 time=1491 ms 64 bytes from ip1.fai: icmp_seq=419 ttl=254 time=1545 ms 64 bytes from ip1.fai: icmp_seq=420 ttl=254 time=1597 ms 64 bytes from ip1.fai: icmp_seq=421 ttl=254 time=7.69 ms
Le résultat est sans appel, la latence augmente rapidement, se revient à sa valeur de base dès que j’arrête le transfert. À 65ko/s, ça met une vingtaine de secondes à atteindre plus d’une seconde de latence, mais si j’augmente encore la vitesse la latence augmente beaucoup plus rapidement. En testant avec 100ko/s = 800kb/s, on l’atteint en moins de 6 secondes :
pv -r -L100k RaspberryPi/RaspBian.iso.gz |nc monserveur 8888
64 bytes from ip1.fai: icmp_seq=714 ttl=254 time=8.26 ms 64 bytes from ip1.fai: icmp_seq=715 ttl=254 time=147 ms 64 bytes from ip1.fai: icmp_seq=716 ttl=254 time=554 ms 64 bytes from ip1.fai: icmp_seq=717 ttl=254 time=644 ms 64 bytes from ip1.fai: icmp_seq=718 ttl=254 time=671 ms 64 bytes from ip1.fai: icmp_seq=719 ttl=254 time=746 ms 64 bytes from ip1.fai: icmp_seq=720 ttl=254 time=1024 ms 64 bytes from ip1.fai: icmp_seq=721 ttl=254 time=1470 ms 64 bytes from ip1.fai: icmp_seq=722 ttl=254 time=1938 ms
L’hypothèse se vérifie bien : trop d’upload génère une grosse latence sur ma connexion. Je n’ai pas l’explication exacte pour comprendre le phénomène, je penche pour un buffer qui se remplit sur le routeur et qui ne lui permet plus de traiter les paquets comme il faut.
La solution : limiter la bande passante sur le routeur
L’idée est donc de limiter la bande passante réellement envoyée par le routeur sur la ligne ADSL pour que ça ne dépasse jamais l’éligibilité de la ligne. Mon routeur est un Mikrotik, je peux m’y connecter en telnet et le configurer avec cette ligne de commande :
/queue tree add name="Upload" parent=pppoe-out1 packet-mark=no-mark limit-at=480k max-limit=500k
On la retrouve dans l’interface web sous le menu « Queues » :
Pour tester que cela fonctionne, je refais le même test que pour diagnostiquer le problème : j’essaye d’uploader des données à une vitesse plus élevée que mon éligibilité, disons à 100ko/s = 800kb/s au lieu de 512kb/s, tout en effectuant un ping pour surveiller la latence :
pv -r -L100k RaspberryPi/RaspBian.iso.gz |nc monserveur 8888 [57,8KiB/s]
L’upload reste un peu en dessous de 60ko/s = 480ko/s, soit la vitesse que j’ai demandé à mon routeur de respecter.
Côté latence, elle augmente un peu mais reste très raisonnable :
64 bytes from ip1.fai: icmp_seq=3291 ttl=254 time=204 ms 64 bytes from ip1.fai: icmp_seq=3293 ttl=254 time=171 ms 64 bytes from ip1.fai: icmp_seq=3295 ttl=254 time=117 ms 64 bytes from ip1.fai: icmp_seq=3296 ttl=254 time=190 ms 64 bytes from ip1.fai: icmp_seq=3299 ttl=254 time=162 ms 64 bytes from ip1.fai: icmp_seq=3300 ttl=254 time=186 ms 64 bytes from ip1.fai: icmp_seq=3301 ttl=254 time=215 ms 64 bytes from ip1.fai: icmp_seq=3302 ttl=254 time=198 ms 64 bytes from ip1.fai: icmp_seq=3303 ttl=254 time=195 ms 64 bytes from ip1.fai: icmp_seq=3304 ttl=254 time=240 ms 64 bytes from ip1.fai: icmp_seq=3305 ttl=254 time=185 ms
Le problème est résolu ! Même si Google Chrome continue à envoyer tout ce qu’il peut à Google, les ralentissements sur le réseau local ne devraient plus se faire sentir de façon aussi importante. Globalement, l’utilisation de l’upload ne va plus perturber toute la connexion internet, sans avoir aucun autre inconvénient puisqu’on a seulement limité la bande passante en upload a ce dont la ligne était capable de supporter.
Vous rencontrez un problème similaire ?
N’hésitez pas à me contacter si vous avez besoin d’aide pour un problème similaire, je serai ravie de vous aider à le résoudre !