Sommaire
Salut nal,
T'as rien compris au titre ? C'est normal.
ATTENTION: Je vais pas te faire un cours de réseau complet. Déjà, parce que c'est pas mon domaine. Et puis parce que j'ai juste assez de connaissances pour faire « oui-oui » de la tête quand j'ai lu l'article original en anglais, mais pas assez pour avoir vraiment bien tout compris de A jusqu'à Z (et donc te réexpliquer).
apenwarr a récemment publié un article (en anglais) sur son blog nommé « A little bump in the wire that makes your Internet faster », soit « Une petite bosse dans le fil qui rend ton Internet plus rapide ».
En gros, ça part du constat que les routeurs xDSL fournis par nos escrocs préférés (les FAI) sont optimisés dans leur config pour une connexion correspondant au débit théorique maximum, celui que les départements marketing nous foutent sous le nez à longueur de temps.
Or, quand on atteint pas en pratique ce débit pour lequel les queues sur le routeur ont été optimisées, cela amène à une grande augmentation de la latence sur les sessions TCP. Si ça ne t'est jamais arrivé sur ta connexion, tant mieux !!!!! Moi perso, ça m'arrive souvent (plusieurs heures par jour) de même pas pouvoir poster un formulaire HTTP (genre ouvrir une issue sur Github) tellement la connexion est saturée (une connexion ADSL pour 40 personnes). D'où mon intérêt pour la solution présentée…
Du coup, notre amiE propose de mettre en place un petit appareil sur le réseau qui va mettre en place un certain nombre de queues et de règles de façonnage de trafic (trafic shaping en VO). Cet appareil sera placé entre la box ADSL et le réseau local. De son côté, ça se passe sur un routeur D-Link DIR-825… mais tout ça peut se faire sur n'importe quelle machine avec en gros deux ports ethernet à disposition.
Logiciellement, la solution mise en place est fq_codel. C'est un mélange entre FQ et CoDel :
- FQ (Fair Queuing) met en place une queue par flux réseau et alterne équitablement entre elles, en privilégiant les petits flux réseaux. Par exemple, une session interactive SSH (petit flux) sera privilégiée par rapport à un transfert de fichier en scp (gros flux)
- CoDel (Controled Delay) ralentit les flux réseaux (en jetant des paquets) en fonction du temps que le flux met à traverser le réseau, sans attendre que la queue soit pleine (souvent, un routeur ne jette des paquets que quand sa queue est pleine)
Il paraît que tout ça est intégré à nos distros préférées, et qu'il existe un paquet SQM sur OpenWRT/LEDE (← les deux projets ont refusionné). Il faut juste spécifier manuellement la capacité de ta ligne, et c'est parti :
Après, l'article original décrit comment configurer son routeur pour séparer clairement le WAN, un port qui donne accès uniquement en LAN pour la configuration du routeur, et un port bridgé avec le WAN qui donne accès à Internet passant par la "bosse" fq_codel. Mais comme j'ai dit que je ferais pas un cours de réseau, je vais pas détailler tout ça.
Si tu parles anglais, je te renvoie vers l'article original, sinon j'espère que d'autres libristes qui s'y connaissent bien en réseau sauront francophoniquement éclairer ta lanterne dans un autre journal.
Conclusion
Voici les résultats de test de débit que apenwarr a pris avant et après la mise en place de sa bosse.
| Situation | Download (Mbit/s) | Upload (Kbit/s) | Latence (ms) |
|---|---|---|---|
| Avant | 4.6 | 72 | 80 |
| Après | 3.2 | 360 | 31 |
On voit que si la vitesse en download a été réduite de plus de 1Mbit/s, la latence est passée de 80ms à 30ms, et l'upload de 70Kb/s à 360Kb/s. Ce qui en pratique permet des connexions beaucoup plus rapides ! Car de nombreuses applications et de nombreux protocoles (dont le web) requièrent de faire un certain nombre d'allers-retours (roundtrips) et dans ces cas là la latence devient souvent le facteur limitant.
En gros, pour un usage moyen d'internet (d'autres usages sont possibles !) une connexion en fibre optique en gigabit ne te servirait à rien du tout si elle avait la latence d'une connexion satellite.
Bon, moi je vais essayer de me trouver un routeur compatible OpenWRT pour mettre en place ça chez moi. Si t'as une idée d'où trouver un routeur comme ça (gratuit ou d'occas) autour de Paris, fais moi signe dans les commentaires :)
Après la Brique Internet, voici donc venue la Bosse Internet. Peut-être ce concept peut-il intéresser des camarades de la FFDN pour intégrer ce genre de solutions à leur brique ? Ou pour prendre en considération dans la configuration des routeurs des abonnéEs ? N'hésite pas à en parler à l'équipe de ton FAI local, que ça soit autour d'une bière ou d'un jus de pomme !
Est-ce que t'en as besoin ?
Au final, j'ai tellement gratté du français que j'ai même oublié de glisser le mot « bufferbloat » (en anglais) dans le journal. C'est le terme générique qui désigne les queues et buffers mal configurées causant des problèmes de latence sur le réseau. D'après Wikipedia, la première étude sur les bufferbloats remonte à 1985… Autant dire que si beaucoup de choses ont changé sur le réseau depuis, ce problème est toujours omniprésent. D'où le projet bufflerbloat.net qui regroupe des gens travaillant sur la question, des routeurs aux drivers wifi de nos laptops.
Alors, est-ce que tu es toi aussi victime de bufferbloat? Le projet bufflerbloat.net propose des tests. En gros, le plus simple pour tester ça en deuspi c'est de lancer en arrière-plan un ping, et en même temps un test de connexion (par exemple sur speedtest.net). Si le test de connexion fait monter ton ping (dans mon cas passant de 25ms à plus de 100ms), alors tu peux toi aussi te lancer dans la chasse au bufferbloat !
# Mais pourquoi j'ai fait le test :S
Posté par Manozco . Évalué à 8.
Voila voila, je viens de faire le test du ping et mon ping passe de 12 a 90ms pendant un speedtest…
Du coup maintenant je vais devoir passer mes nuits a réparer mon réseau…. :S
[^] # Re: Mais pourquoi j'ai fait le test :S
Posté par kowalsky . Évalué à 2.
J'ai lu en diagonal, mais on dirait un boîtier qui va bufferiser les connexions TCP et essayer d'avoir la meilleure fenêtre TCP possible (TCP window). Du coup, ping n'est pas impacté par cette méthode.
[^] # Re: Mais pourquoi j'ai fait le test :S
Posté par cmal (site web personnel) . Évalué à 1. Dernière modification le 16 août 2018 à 16:13.
Je crois pas. En fait il s'agit d'optimiser les queues sur le réseau ce qui impacte tous les flux et pas que TCP. Après le fait que TCP a besoin de faire des allers-retours pour confirmer que l'information est bien arrivée fait que tu verras en pratique de plus grandes différences de performances sur des flux TCP (genre formulaires HTTP).
[^] # Re: Mais pourquoi j'ai fait le test :S
Posté par Julien L. . Évalué à 1. Dernière modification le 17 août 2018 à 09:48.
En gros c'est comme limiter la vitesse à 70km/h sur autoroute pour éviter les bouchons
# Terminologie
Posté par benoar . Évalué à 8. Dernière modification le 10 août 2018 à 15:41.
Le terme « bump-in-the-wire » devrait plutôt être traduit, je pense, par « élévation sur la ligne », ou un truc du genre. Ça vient du monde IPsec, cf. https://en.wikipedia.org/wiki/Bump-in-the-wire qui référence la RFC 4301 https://tools.ietf.org/html/rfc4301 mais on peut remonter à la RFC 2767 https://tools.ietf.org/html/rfc2767 qui cite un papier de 1996 (sur une implémentation MS-DOS d'IPsec !!). On en parle par opposition au « bump-in-the-stack », ou « élévation dans la pile », dans lequelle c'est la pile logicielle qui est modifiée pour inclure l'amélioration ; de sécurité dans le cas d'IPsec, ici de réactivité, même si le « bump » est lié à l'ajout d'un header IPsec AH/ESP dans le premier cas et n'a pas ici vraiment de sens. On en parle également dans les différentes méthode de transition IPv4/IPv6.
Quant au bufferbloat, on pourrait éventuellement dire « ballonnements dû aux tampons » ; bon, je suis vraiment mauvais en francisation je crois.
Le pire est que l'industrie des télécoms toute entière refuse toujours obstinément de reconnaître ce problème, et le poids de l'existant est tellement énorme qu'il est en effet aujourd'hui impossible d'avoir une infrastructure DSL avec des tailles de buffer correctes, tellement c'est enraciné dans les équipements et les gens.
[^] # Re: Terminologie
Posté par Kerro . Évalué à 5.
Je dirais
dos d'âneouralentisseur, ce qui semble correspondre à la signification originale.[^] # Re: Terminologie
Posté par benoar . Évalué à 2.
Non, c'est l'inverse, le but n'est pas de dire qu'un ralentisseur ralentit ton trafic, mais qu'un mécanisme « élève » (du verbe « to bump ») ton trafic réseau (le titre original est « A little bump in the wire that makes your Internet faster »). Ça a moyennement du sens ici pour la modification de scheduling, mais à l'origine c'était pour l'ajout d'un header IPsec (qui élève le contenu du paquet original).
[^] # Re: Terminologie
Posté par Kerro . Évalué à 1. Dernière modification le 16 août 2018 à 17:59.
to bumpsignifiefaire une bosse, toucher, heuter. Pas de trace d'élévation à ma connaissance.Pour IPSec, le bump dont tu parles est le bump-in-the-stack qui consiste à garder le code de la pile IP, et de n'ajouter qu'une partie qui va gérer le cas spécifique d'IPSec lors que son en-tête est détecté.
La partie ajoutée est qualifiée de bump, une sorte de greffon sans mécanisme de greffon.
[^] # Re: Terminologie
Posté par cmal (site web personnel) . Évalué à 0.
J'avoue que a posteriori, cela a beaucoup plus de sens que « bosse ». Je n'avais pas pensé à interpréter « bump » comme un « speed bumb » (ralentisseur), mais de fait cela me semble correspondre à ce que la solution accomplit… C'est un dos d'âne numérique pour éviter les embouteillages sur les petites routes des Internets :D
[^] # Re: Terminologie
Posté par oinkoink_daotter . Évalué à 5. Dernière modification le 10 août 2018 à 16:44.
J'aurais plutôt traduit "bump" par "dos d’âne" ou "nid de poule" ou "cahot" ?
edit : grilled by Kerro<
# I got that reference
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 3.
He said, uh, "The answer's not in the box, it's in the band."
# Pour les décideurs pressés
Posté par TilK . Évalué à 6.
Bon, je me suis tapé l'article, et voila petit résumé pas trop technique :
Après, j'ai l'impression qu'en France, certains opérateurs pensent aux joueurs et proposent déjà des modes pour améliorer le ping (Fastpath ou Patate chez free, le profil "Jeux" chez SFR…) et que cela fait longtemps qu'il n'y a plus de course à la plus grosse bande passante en ADSL (au final le réseau est le même, et donc il n'y a rien à comparer). Donc je ne sais pas si c'est vraiment efficace ou si ce n'est pas déjà implémenté .
[^] # Re: Pour les décideurs pressés
Posté par GG (site web personnel) . Évalué à 6.
Il y a aussi la solution de bloquer les traqueurs et la publicité : https://greboca.com/La-securite-la-pub-et-le-traqueur.html
Cela fait une très grosse différence, en terme de résolution DNS, de download etc.
Ci après un exemple pour la page d'accueil du site Libération:
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Pour les décideurs pressés
Posté par barmic . Évalué à 1.
La résolution DNS ne se fait pas en parallèle ? Pour le download, le sujet c'est justement que le débit n'est pas forcément le plus important.
Ton graphe est intéressant, mais j'irais bien voir un chronographe pour voir pourquoi ça se retarde.
[^] # Re: Pour les décideurs pressés
Posté par Benoît Sibaud (site web personnel) . Évalué à 5. Dernière modification le 13 août 2018 à 10:41.
Parallèle ou pas, plus y a de résolutions DNS, plus la réponse la plus lente est lente, plus tu attends la fin du chargement de ta page. Et sur les sites bloatware, y a beaucoup de résolutions à faire (souvent en dizaine(s) de fois plus).
Et si non parallèle c'est encore pire, évidemment.
[^] # Re: Pour les décideurs pressés
Posté par barmic . Évalué à 2.
Mais du coup 1, 2 ou 3000, c'est toujours la requête la plus longue et rien ne me pousse à croire que c'est plus rapide pour les domaines de libé que ceux de nos amis publicitaires. D'une part ils ont des infra qui sont probablement plus costauds mais en plus ils ont des chances d'être dans les caches.
J'ai pas trouvé de moyen d'exporter les chronogrammes (c'est nul c'était possible avec firebug…), donc c'est assez relou pour faire une analyse.
Avec la pub, en 4.44s j'ai bien 2s sans aucun accès réseau.
Rien à voir mais c'est assez marrant, je perds pas mal de temps sur des requêtes bloquées vers leur CDN. Ils font une trentaine de requêtes (2 fois 15 requêtes). Ils gagneraient à passer à HTTP2 pour multiplexer ça.
[^] # Re: Pour les décideurs pressés
Posté par GG (site web personnel) . Évalué à 2. Dernière modification le 13 août 2018 à 23:20.
Oui et non, ils veulent savoir quelle partie de la page tu affiches, et, avec du javascript peuvent même savoir comment tu déplaces ton pointeur.
Ici, il n'est question que de ce qui est téléchargé, et pas envoyé.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Pour les décideurs pressés
Posté par barmic . Évalué à 0.
Hein ? Les domaines md0.libe.com et md1.libe.com retournent des images. Bien sûr ça n'empêche pas pas de faire du tracking, mais le faire avec son domaine static (que j'ai appelé à tord CDN en effet, je ne connais pas leur infra). Ça n'est pas du tracking et si c'était ça ce serait très mal fait, la moitié de leur requêtes sont bloquées pendant un temps par firefox juste parce que firefox limite le nombre de connexions parallèles à un domaine donné. Donc oui ça gagnerait à être multiplexé.
Je comprends que j'ai pas étais assez précis, mais t'a quand même était bien imaginatif. C'est rigolo comme des mots sont tabous et dès que j'ai écris CDN, tu as pensé tracking et drak pattern… De ce que j'ai pu voir les annonceurs de libé n'utilisent pas des masses de CDN, j'ai vu un cloudfront passer (en rapport avec https://www.sharethefacts.co, je sais pas ce que c'est).
Le moniteur réseau de firefox (ce que je tente d'utiliser) te montre toutes les connexions. Pas que ce qui descends.
[^] # Re: Pour les décideurs pressés
Posté par GG (site web personnel) . Évalué à 2.
Alors, certes, j'ai été rapide en conclusion, mais je parlais d'une manière générale.
Et, avec traqueurs activés, il y a toujours un petit flux qui passe, et qui ne permet pas de savoir de combien d'éléments la page est faite, sauf en l'arrêtant volontairement après un certain délai.
Pourquoi autant d'éléments différents, de toutes petite taille sur cette page d'accueil? Je n'ai pas cherché à savoir. C'est souvent utilisé pour du tracking. En autorisant qu'une toute petite part des connexions, on a le texte et les images, nickel!
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # J'ai testé
Posté par cmal (site web personnel) . Évalué à 3.
J'ai mis ça en place lundi midi dans un gros bâtiment ou plusieurs dizaines de personnes partagent une connexion ADSL. Résultat 100% heureux. Depuis lundi, finis les embouteillages et la QoS gérée par Bouygues qui permet à trois personnes de regarder une vidéo Youtube/Whatsapp et empêcher les autres d'envoyer un simple formulaire HTTP.
Au final, je ne vois pas tant que ça de différence au niveau du ping (en heure de pointe il continue de monter autour de 100ms), mais en terme d'utilisabilité c'est juste sans comparaison. Avant, pour pouvoir poster un journal ou envoyer un mail, il me fallait soit passer par ma 3G, soit attendre une heure d'accalmie. Depuis lundi, je n'ai rencontré aucune erreur de timeout sur un envoi de formulaire HTTP. Ça fait plaisir :)
# Test
Posté par ted (site web personnel) . Évalué à 1.
Je viens de faire le test: je passe de 17ms à plus de 300ms de ping quand je fais un Speedtest en parallèle (config: laptop en wifi n, connexion «fibre» Numericable).
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Test
Posté par Crao . Évalué à 0.
Je suis passé de 10ms à 17ms avec un Speedtest à 900Mbps (fibre free).
# latence ou debit en upload
Posté par PLuG . Évalué à 2.
on parle beaucoup de la latence dans cet article, la latence est prépondérante et incontounable surtout pour les jeux.
Pour le web tant qu'à ajouter un boitier sur le réseau ne pas hésiter à faire tourner un cache DNS local, voir un cache web … c'est quasiment magique.
Enfin ne pas sous-estimer l'importance du debit en upload. Depuis que je suis passé en vdsl et que j'ai 6Mbps en upload tout va bien mieux…
[^] # Re: latence ou debit en upload
Posté par Harvesterify (site web personnel) . Évalué à 4.
Un cache Web à l'heure où l'HTTPS est majoritaire, quelle est l'utilité ?
Mes messages engagent qui je veux.
[^] # Re: latence ou debit en upload
Posté par PLuG . Évalué à 3.
sur la latence c'est surtout le cache DNS qui joue.
si t'es tout seul sur ta liaison ADSL le cache web de ton navigateur suffit. Sinon aujourd'hui on cache encore pas mal d'info dans les proxy le tout https n'est pas en place … et les proxy savent faire du man in the middle.
[^] # Re: latence ou debit en upload
Posté par voxdemonix . Évalué à 1.
Cela sous entends quand même créer une autorité de certification et la propager dans tout les périphériques connectés au réseau LAN.
Déjà ce n'est pas faisable en deux clics, mais en prime cela est impossible avec l'IOT mal codée et avec le partage de connexion *1.
*1 Tes invités avec leur smartphone vont juste voir que ça ne va pas et trouver "ton truc chelou" quand tu vas vouloir ajouter ton autorité de certif. Dans un cadre "familiale/maisonnée" sa signifie que la personne qui gère le serveur peut épier tout les autres.
# Anciens algos
Posté par Astaoth . Évalué à 1.
Ça me rappelle un projet sur lequel j'avais travaillé pour l'INRIA. Le projet portait plutôt sur le wifi, pour justement gérer de façon plus efficace les cas où on est utilisateurs par borne (typiquement dans une école, quand un prof demande d'aller chercher le pdf du tp sur son site). Le but était donc d'implémenter des solutions pour améliorer l'usage de ce wifi.
De mémoire on avait 2 algo. Un premier visait justement à privilégier les sessions transférant de petites données par rapport aux grosses. Comme ça on gagne justement un peu de latence. On a donc l'illusion d'une connexion plus rapide, même si le voisin profite du tp pour faire ses mises à jours. Et il me semble que le second algo visait à faire, en gros, une file de donnée par utilisateur pour alterner équitablement entre eux. En bref, on a travaillé sur le FQ décrit dans l'article. C'est sympa de voir qu'une solution utilisant ces algos est commercialisée, je suis curieux de savoir si ca améliore vraiment les choses !
Emacs le fait depuis 30 ans.
# Possible aussi avec OpenBSD
Posté par Taurre . Évalué à 3.
Salut,
Ce journal me rappelle un billet récent sur undeadly.org qui présente comment régler ce problème sous OpenBSD. Il référence à ce sujet un article intéressant.
# En vrai derrière c'est du cake
Posté par Florent Fourcot . Évalué à 10.
Si l'auteur original en parle dans l'article, mais le journal n'en fait pas mention, donc je me permet de compléter.
Cake est un projet pour rendre (notamment) la QoS facilement configurable sous Linux. Du coup d'ailleurs c'est pas le même algorithme fq_codel qui est utilisé que celui « classique » du noyau Linux, mais une variante (cobalt). Et cake a pour objectif de faire beaucoup de choses, notamment :
Cake a été mergé récemment (après 18 versions proposées des patchs !), et sera en version 4.19. Si vous voulez un peu d'histoire, lwn en parle.
Également sur lwn, c'est relié mais pas complètement, un article sur les problèmes de latence en WiFi avec Linux.
[^] # Re: En vrai derrière c'est du cake
Posté par cmal (site web personnel) . Évalué à -1.
Effectivement, cake était mentionné dans l'article mais tellement brièvement que cela ne me semblait être qu'une forme de packaging autour de fq_codel. Merci pour ce complément d'information ! :)
[^] # Re: En vrai derrière c'est du cake
Posté par Anonyme . Évalué à 2.
Pas lu l'article encore, mais un premier truc qui peut réduire la latence en WiFi c'est de désactiver la mise en veille de la carte :
iw dev wlan0 set power_save off.# ack sur serveur carracho
Posté par bunam . Évalué à 3.
On utilisait http://www.carracho.com pour faire des "échanges de fichiers" dans les années 2000, c'est un genre de FTP et il y avait un chat intégré, c'était comme Hotline HQ mais en bien plus rapide au niveau réseau. Trop rapide qu'il y avait un étranglement des paquets ack (les paquets qui disaient en gros "j'ai bien reçu" en retour d'un paquet de données envoyé)
Une "connaissance" à finit pas faire un logiciel pour limiter les envois pour laisser passer les paquets de retour, http://intrarts.com/throttled.html
Activer ou désactiver le soft avait un effet immédiat comme on peut le voir sur les graphiques.
# Et sans routeur ?
Posté par Yves (site web personnel) . Évalué à 1.
Si on n’a pas de routeur, est-il possible de paramétrer la même chose sur chaque kernel de PC Linux individuellement ?
[^] # Re: Et sans routeur ?
Posté par bobo38 . Évalué à 2.
Disclaimer: j'y connais rien…
Sans routeur, sur un poste unique, je pense que ces techniques vont permettre de pouvoir faire les tâches qui réclament peu de bande passante plus confortablement lors de gros téléchargement. Basiquement tu devrais avoir un meilleur ping dans le test de la fin
En revanche, en cas de postes multiples utilisant le même point d'accès internet, chaque machine n'est pas immunisée contre les usages en download d'une autre machine
[^] # Re: Et sans routeur ?
Posté par Yves (site web personnel) . Évalué à 1.
Logique, en effet. Et donc a priori faisable si c’est un petit LAN de confiance, avec uniquement du Linux dessus, ce qui est mon cas :-)
[^] # Re: Et sans routeur ?
Posté par bobo38 . Évalué à 1.
Ça pourrait répondre au besoin d'un pote qui ne pouvait plus browser le web lors de mise à jour de Ubuntu. Je n'ai aucune idée de la marche à suivre pour activer ce genre de fonctionnalité sur un laptop ou un poste fixe
J'ai un peu regardé openwrt hier, ça donne des idées de bricolage: j'ai eu des soucis récurrents de connexion wifi pour ma compagne… Ça a l'air de s'être calmé. Un routeur wifi branché à la box pourrait le faire. J'ai l'impression qu'aucun matos supporté n'est capable de gérer une connection par cable, c'est bien dommage
Il y a du matos à pas trop cher (plus ou moins ~50€) qui est supporté, il faut faire attention à l'espace dispo en mémoire flash (4Mb et moins c'est l'image tiny qui est à utiliser, ce qui peut limiter les bricolages possibles: NAS etc… et ce n'est pas clair si l'interface web est utilisable ou non sur du matos comme ça, j'ai l'impression que non)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.