La Fibre
Hébergeurs et opérateurs pro / entreprises => Hébergeurs et opérateurs pro / entreprises => 
Appliwave => Discussion démarrée par: vivien le 22 avril 2021 à 15:56:39
-
Appliwave m'a passé un serveur ultra-performant, qui va permettre de réaliser des tests de débit fiables, sur un réseau de qualité.
(https://lafibre.info/images/pro/logo_appliwave.webp)
Il est hébergé a Croissy-Beaubourg en Seine-et-Marne et est connecté à internet en... 40 Gb/s !
Sa carte réseau est une Mellanox ConnectX-3 40/56GbE PCIe3.0 x8 8GT/s DP QSFP Adapter.
(https://lafibre.info/images/materiel/201900_mellanox_connect_x-3_2_ports_40gbps.jpg)
$ sudo lspci -v | grep -A 15 Mellanox
03:00.0 Network controller: Mellanox Technologies MT27500 Family [ConnectX-3]
Subsystem: Mellanox Technologies MT27500 Family [ConnectX-3]
Flags: bus master, fast devsel, latency 0, IRQ 38, NUMA node 0
Memory at 92700000 (64-bit, non-prefetchable) [size=1M]
Memory at 91000000 (64-bit, prefetchable) [size=8M]
Expansion ROM at <ignored> [disabled]
Capabilities: [40] Power Management version 3
Capabilities: [48] Vital Product Data
Capabilities: [9c] MSI-X: Enable+ Count=128 Masked-
Capabilities: [60] Express Endpoint, MSI 00
Capabilities: [c0] Vendor Specific Information: Len=18 <?>
Capabilities: [100] Alternative Routing-ID Interpretation (ARI)
Capabilities: [148] Device Serial Number f4-52-14-03-00-26-43-20
Capabilities: [154] Advanced Error Reporting
Capabilities: [18c] Secondary PCI Express
Kernel driver in use: mlx4_core
Kernel modules: mlx4_core
On a réalisé quelques tests, il y a bien 40 Gb/s !
Je finalise la configuration (le contenu des fichiers va changer pour pouvoir plus facilement mettre en évidence des problématique de type anti-virus sur le PC qui fait le test).
Mais ce serveur, le seul de ce type, va clairement être mis en avant et je cherche à éviter les abus.
Savez-vous quel outil permettrait de loguer le volume demandé par chaque IPv4 ou /64 IPv6 et couper automatiquement le flux au-delà d'un certain volume ?
Mon cahier des charges, dans mes rêves, c'est de mettre un maximum de 30 Go de données transférée par période de 8 heures. Cela nécessite une grosse table qui est vidée toutes les 8 heures.
Au-delà de ces 30 Go, l'IP est bloquée par iptables pour une durée de 8h à partir du moment où elle a dépassée le quotas, afin d'éviter que simultanément toutes les IP bloquées soient de nouveau autorisée, ce qui pourrait provoquer une saturation si il y a un script qui boucle.
Pourquoi 8 heures ? Car il est important dans le cadre d'une saturation de faire des tests le soir, sur le créneau 20h-22h30 quand le réseau est chargé et des tests le matin, avant 9h00, quand le réseau est presque vide. Ce créneau de 8 heures permet d'éviter que trop de tests le soirs bloquent les tests du matin.
-
Je vais détailler ce que je souhaite éviter en donnant un exemple concret :
Bouygues Paris :
Débit moyen sur le serveur Bouygues 10 Gb/s de Paris : (les test nPerf et SpeedTest.net n'ont pas été impactés, ils sont sur un autre serveur dans la même baie)
(https://lafibre.info/images/stats/202104_stats_bouygues_serveur_paris.png)
Log le 7 avril à 5h54 du matin : L'IP Google 34.90.56.168 fait en boucle des requêtes de fichier de 10 Go avec Curl :
(https://lafibre.info/images/stats/202104_log_bouygues_serveur_paris.png)
Bouygues Lyon :
Débit moyen sur le serveur Bouygues 10 Gb/s de Lyon :
(https://lafibre.info/images/stats/202104_stats_bouygues_serveur_lyon.png)
Log le 7 avril à 5h54 du matin : L'IP Google 34.90.56.168 fait en boucle des requêtes de fichier de 10 Go avec Curl :
(https://lafibre.info/images/stats/202104_log_bouygues_serveur_lyon.png)
Bouygues Aix-Marseille :
Débit moyen sur le serveur Bouygues 10 Gb/s de Aix-en-Provence :
(https://lafibre.info/images/stats/202104_stats_bouygues_serveur_aix.png)
Log le 7 avril à 5h54 du matin : L'IP Google 34.90.56.168 fait en boucle des requêtes de fichier de 10 Go avec Curl :
(https://lafibre.info/images/stats/202104_log_bouygues_serveur_aix.png)
-
Bouygues Bordeaux :
Débit moyen sur le serveur Bouygues 10 Gb/s de Bordeaux :
(https://lafibre.info/images/stats/202104_stats_bouygues_serveur_bordeaux.png)
Log le 7 avril à 5h54 du matin : L'IP Google 34.90.56.168 fait en boucle des requêtes de fichier de 10 Go avec Curl :
(https://lafibre.info/images/stats/202104_log_bouygues_serveur_bordeaux.png)
Bouygues Lille :
Débit moyen sur le serveur Bouygues 10 Gb/s de Lille :
(https://lafibre.info/images/stats/202104_stats_bouygues_serveur_lille.png)
Log le 7 avril à 5h54 du matin : L'IP Google 34.90.56.168 fait en boucle des requêtes de fichier de 10 Go avec Curl :
(https://lafibre.info/images/stats/202104_log_bouygues_serveur_lille.png)
Scaleway :
Cela ne se limite pas à Bouygues.
Débit moyen sur le serveur Scaleway 10 Gb/s de DC3 :
(https://lafibre.info/images/stats/202104_stats_scaleway_serveur_dc3.png)
-
Le serveur de Paris était plus impacté, car il a été touché par l'URL bouygues.testdebit.info (IP anycast) et par l'url paris.testdebit.info (IP unicast).
Je cherche donc un moyen de supprimer automatiquement ce trafic parasite, sans devoir manuellement bloquer les IP.
Ce trafic dégrade les tests des clients et est un risque pour le réseau. Ici pour Bouygues Telecom, le trafic était sortant alors que Bouygues étant un FAI il a un gros trafic entrant et peu de trafic sortant. Vu le peering avec Google, aucun risque de saturation, mais cela peut-être dégradé la situation coté Google, le serveur en question était visiblement connecté en 100 Gb/s.
Je me suis demandé si n'écouter que en https permettrait de limiter la casse, mais ici on voit bien que certains serveurs étaient attaqués en http (log port 80 dans les logs) et d'autres en https (log port 443 dans les logs)
-
L'extension hashlimit de iptables ?
-
Tu peux déjà signaler a Google pour qu'ils recherchent le coupable. https://support.google.com/code/contact/cloud_platform_report si l'IP est dans leur blocs GCP : https://www.gstatic.com/ipranges/cloud.json (ce qui a l'air d'être le cas). C'est peut-être un compte GCP compromis.
Savez-vous quel outil permettrait de loguer le volume demandé par chaque IPv4 ou /64 IPv6 et couper automatiquement le flux au-delà d'un certain volume ?
y'aura NSpeed bientot...mais effectivement je cherche aussi ce genre de chose. Y'a bien l'option quota d'iptables mais ca ne correspond pas a ton besoin. Je n'ai rien trouvé dans les modules ngnix ou apache ni même avec haproxy. Ce qui est normal car ce genre de suivi peut rapidement saturé la mémoire ou nécessite un fichier sur disque donc impact les performances.
Idéalement il faudrait un petit script qui parse les log du serveur web et calcul les totaux par IP et manipule iptables en conséquence.
Apres si cela n'a pas déjà été fait (ce qui serait étonnant) et comme je dois le faire pour NSpeed je pourrais éventuellement faire une version standalone qui parse un log de serveur. Mais ce n'est pas top prio dans la todo list pour le moment.
Au besoin envois moi un bout de log de serveur pour voir si on ne peut pas faire un script rapide en shell ou python par exemple.
-
Appliwave m'a passé un serveur ultra performant, qui va permettre de réaliser des tests de débit fiables, sur un réseau de qualité.
Il est hébergé a Croissy-Beaubourg en Seine-et-Marne et est connecté à internet en... 40 Gb/s !
Un vrai plaisir ! Si besoin on pourra upgrader ;)
On a encore quelques interco en 10G, mais d'ici cet été, quasiment tout sera en 100G sur au moins le trafic Français. On a déjà Hopus, FranceIX, Cogent, GTT en 100Gb/s.
Si vous remarquez des routes pas top, n'hésitez pas :D
-
Je finalise la configuration (le contenu des fichiers va changer pour pouvoir plus facilement mettre en évidence des problématique de type anti-virus sur le PC qui fait le test).
j'ai pas compris....
-
Je finalise la configuration (le contenu des fichiers va changer pour pouvoir plus facilement mettre en évidence des problématique de type anti-virus sur le PC qui fait le test).
Aujourd'hui quand vous téléchargez un fichier sur des serveurs testdebit.info, c'est une vidéo de vague sur une plage encodée en WebM (codec VP9) qui est utilisée dans différente taille (sauf le fichier de toute petite taille ou c'est sont des photos) quel que soit l’extension du fichier.
Si vous téléchargez le fichier 10G.iso un logiciel qui aura accès au contenu va voir que c'est une vidéo WebM.
Afin de mieux mettre en évidence les anti-virus qui font du man in the middle pour analyser le contenu, je vais complexifier sa tache avec un contenu qui est au format .zip ce qui devrait le pousser à faire une analyse plus approfondie que pour une fichier WebM.
-
L'extension hashlimit de iptables ?
J'utilise depuis plusieurs années iptables -m connlimit pour limiter le nombre de connexions simultanées et je suis extrêmement satisfait. Cela ne protège des slow DOS ouvrant pleins de connexions TCP simultanément et aussi des bug qui font que des PC vont demander établir pleins de connexions.
#!/bin/dash
# Limiter le nombre de sessions tcp par client (un client = une IPv4 ou un /64 en IPv6)
/usr/sbin/iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 50 -m limit --limit 30/hour --limit-burst 1 -j LOG --log-prefix="drop-c-"
/usr/sbin/iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 50 -j REJECT
/usr/sbin/ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 50 --connlimit-mask 64 -m limit --limit 30/hour --limit-burst 1 -j LOG --log-prefix="drop-c-"
/usr/sbin/ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 50 --connlimit-mask 64 -j REJECT
Pour iptables -m hashlimit, il y a peu de documentation, c'est dommage de ne pas plus détailler les choses dans la documentation (https://ipset.netfilter.org/iptables-extensions.man.html#lbAY).
Voici ce que j'ai imaginé : Si une IP dépasse 300 Gb de données échangées (soit 30 secondes à un débit de 10 Gb/s ou 37,5 Go) l'IP est bloquée pendant 2h. Ce calcul est réalisé toutes les 4 secondes (pas besoin de le faire plus souvent, la table pouvant être importante, cela engendre du calcul CPU)
J'ai pensé à ça en ligne de commande :
/usr/sbin/iptables -A INPUT -p tcp -m hashlimit --hashlimit-name Protec4 --hashlimit-mode srcip --hashlimit-above 300gb/hours --hashlimit-htable-max 50000 --hashlimit-htable-expire 7200000 --hashlimit-htable-gcinterval 4000 -j REJECT
/usr/sbin/ip6tables -A INPUT -p tcp -m hashlimit --hashlimit-name Protec6 --hashlimit-mode srcip --hashlimit-srcmask 64 --hashlimit-above 300gb/hours --hashlimit-htable-max 50000 --hashlimit-htable-expire 7200000 --hashlimit-htable-gcinterval 4000 -j REJECT
Je détaille les options ci-dessous, c'est plus lisible :
-m hashlimit : appel de l'extention hashlimit
--hashlimit-name Protec6 : Nom que je donne à l'entrée /proc/net/ipt_hashlimit/foo
--hashlimit-mode srcip : Je me base sur l'IP source (peu importe les ports ou l'IP destination)
--hashlimit-srcmask 64 : Uniquement en IPv6, un /64 est considéré comme un unique client pour éviter les script qui changeraient d'IPv6 à chaque requête. En IPv4, pas de regroupement, une IPv4 = un client.
--hashlimit-above 300gb/hours : La limite au-delà duquel je bloque l'IP : 300 Gb ou 37,5 Go
--hashlimit-htable-max 50000 : Limite de la table de hachage, car ne pas mettre de limite me semble dangereux. 50 000 IP v4 et 50 000 /64 IPv6, cela me semble large sur une durée de 2h.
--hashlimit-htable-expire 7200000 : 7200000ms = 2h. Les entrées sont supprimées après 2 heures.
--hashlimit-htable-gcinterval 4000 : Les données sont calculées toutes les 4 secondes (soit 4000ms).
Ma question est de savoir comment iptables interprète "hashlimit-above 300gb/hours" : C'est vrai dès que l'on dépasse 300gb et que le temps écoulé est de moins d'une heure ou c'est vrai si on dépasse 333 Mb pendant 4 secondes, l'intervalle ou je réalise le calcul ?
Si c'est 333 Mb/4sec, je pense qu'il faut que j'utilise --hashlimit-burst mais si on peut définir une valeur maximum pour le burst, je ne vois rien pour définir la durée du burst.
-
un contenu qui est au format .zip ce qui devrait le pousser à faire une analyse plus approfondie que pour une fichier WebM.
et ?
tu peux creer un ISO avec un zip d'un fichier EICAR ;) je recherche l'utilité d'une telle action.
-
Le serveur de Paris était plus impacté, car il a été touché par l'URL bouygues.testdebit.info (IP anycast) et par l'url paris.testdebit.info (IP unicast).
Je cherche donc un moyen de supprimer automatiquement ce trafic parasite, sans devoir manuellement bloquer les IP.
un truc bête, mais mettre un robots.txt avec des Disallow sur iso, exe, webm, apk ?
ça ne marche peut être pas, mais ça ne dois pas manger beaucoup de pain de tenter..
Google suit le robots.txt non ? (à mettre sur tous les serveurs / sous domaines)
-
--hashlimit-htable-gcinterval 4000 : Les données sont calculées toutes les 4 secondes (soit 4000ms).
GC = garbage collection. ce n'est pas un recalcul c'est juste le nettoyage de la hashmap (visible sous /proc/net/ipt_hashlimit/nom en mettant un --hashlimit-name nom) pour récupérer des ressources inutilisées.
y'a une bonne doc en fr ici:
https://inetdoc.developpez.com/tutoriels/filtrage-iptables/?page=page_11#limitmatch
Je ne suis pas certain que ca puisse faire ce que tu veux...du moins pas en une seul ligne iptables.
-
La doc est un peu ancienne, il y a eu des modifications depuis pour Hashlimit.
Exemple: A hash limit option (--hashlimit-upto, --hashlimit-above) and --hashlimit-name are required.
dans la doc actuelle (https://ipset.netfilter.org/iptables-extensions.man.html#lbAY) (accessible en ligne de commande avec man iptables-extensions)
Mais la doc en FR pointée ne parle pas de --hashlimit-upto ni de --hashlimit-above donc aucun exemple ne va fonctionner.
tu peux creer un ISO avec un zip d'un fichier EICAR ;) je recherche l'utilité d'une telle action.
Il y aura toujours toutes les extensions.
Par contre si une application observe le flux, ce ne sera plus du webm, mais du zip et l'antivirus pourrait faire une analyse plus poussée pour vérifier le contenu du Zip, ce qui devrait se voir. A l'intérieur, il y aura un paquet de fichier intéressant à analyser : ce sont les fichiers de Libre Office portable pour Windows, donc avec des .exe, des .dll,...
Pour une taille de fichier, il y aura deux types de contenu de fichier, afin de pouvoir comparer les performances avec un contenu de fichier aléatoire.
-
Je dois être vieux, de la vieille école mais moi un speedtest ca doit pas aller titiller les process style AV comme tu veux les tester...
Tu peux proposer les 2: du urandom incompressible et ton ISO rempli de libreoffice portable ;) je vois ton idée mais laisser le choix c'est mieux...
-
Je ne pourrais pas doubler tous les fichiers, mais ce sera fait pour trois taille : 100 Mo, 250 Mio (la taille retenue pour les tests Arcep mobile après grosse négociation entre les opérateurs, certains veulent un fichier plus petit et certains veulent un fichier plus gros) et 1 Go.
L'idée est quand même de pouvoir comprendre pourquoi un client a des mauvais débit dans la vraie vie alors qu'un SpeedTest affichera un débit excellent.
C'est un peu l'idée que j'ai creusé avec ces fichiers, même si depuis SpeedTest.net d'Ookla propose un test mono-connexion qui permet déjà de se rapprocher d'une usage plus réel (mais sur un port dédié, le 8080) et nPerf est passé sur le port 443 (mais avec 16 connexions TCP simultanément)
-
même 1 Go max de taille..............
la
bonne
blague !
HAHAHAHAHAHAHA !
avec du 5G théorique de 2.5Gbit/s....
les 250MB torchés en 2/3 secondes au Q d'un pylone.......................
ca me fait penser au vieux test de mire SFR/neuf... http://www.speedzilla.net/
HAHAHAHAHAHAHA !
Tristesse et désolation :-(
-
La représentativité est importante. Ne faire des tests sur des fichiers de grande taille n'est pas représentatif de l'usage du plus grand nombre et entraine des biais, la montée en débit n'est pas la même chez tous les opérateurs par exemple.
-
Comparer c'est avec des choses en commun, si A monte moins en débit que B c'est un élément comparatif.
et question taille si un test de 10 secondes se finit en 3 secondes il n'y a plus de comparaison possible.
Bref. du n'importe quoi.
-
Il reste iperf et les fichier de 10Go pour ça, du calme.
-
La doc est un peu ancienne, il y a eu des modifications depuis pour Hashlimit.
Exemple: A hash limit option (--hashlimit-upto, --hashlimit-above) and --hashlimit-name are required.
dans la doc actuelle (https://ipset.netfilter.org/iptables-extensions.man.html#lbAY) (accessible en ligne de commande avec man iptables-extensions)
Mais la doc en FR pointée ne parle pas de --hashlimit-upto ni de --hashlimit-above donc aucun exemple ne va fonctionner.
Il y aura toujours toutes les extensions.
Les nouveautés c'est juste "--hashlimit" qui a été changé en 2 mode (upto ou above). l'ancienne version c'était donc que le mode 'above'.
Apres c'est juste que ton histoire de 'fréquence de calcul' et 'entrée supprimées apres 2heures' qui ne collent pas.
"hashlimit-htable-expire 2h" supprime les entrées qui n'ont pas été actualisées (c'est ca le point clé) depuis depuis plus de 2 heures.
Si tes hash sont avec l'ip source (hashlimit-mode srcip) (c'est pas l'ip destination plutot d'ailleurs?) ca va donc supprimer de la table les ip qui n'ont pas généré de trafic depuis plus de 2 heures.
et "expire" ne libère pas les ressources, ca marque juste qu'il faut les supprimer. C'est "hashlimit-htable-gcinterval" qui les supprime effectivement.
Donc l'interprétation de "hashlimit-above 300gb/hours" est juste: ca match si il y a eu plus de 300gb sur une heure. c'est instantané et calculé a chaque fois qu'une entrée de la table est crée ou mise a jour donc a chaque paquet tcp (qui reset aussi le timeout du expire donc).
C'est comme ca que je le comprend en tous cas.
-
"hashlimit-htable-expire 2h" est donc nécessaire, si je souhaite qu'en cas de blocage, les IP soient bloquées pendant 2 heures ?
Pendant le blocage , il n'y a plus de nouveau paquets, si la durée est plus courte, l'IP est débloquée, non ?
-
Il reste iperf et les fichier de 10Go pour ça, du calme.
m'ouais... seul la "geek method" est fiable.... m'ouais.
-
"hashlimit-htable-expire 2h" est donc nécessaire, si je souhaite qu'en cas de blocage, les IP soient bloquées pendant 2 heures ?
Pendant le blocage , il n'y a plus de nouveau paquets, si la durée est plus courte, l'IP est débloquée, non ?
y'a pas de notion de blocage pour "x heures" c'est toujours basé sur le débit donc ici "hashlimit-above 300gb/hours". Tant que le trafic d'une IP est supérieur a cette valeur, ca bloque cet IP, s'il descend en dessous cela ne bloque plus. s'il n'y a rien pendant 2 heures ca reset complement cette IP.
la notation /hour n'est d'ailleurs qu'un raccourci, c'est toujours convertit en /second. C'est pour ca que je ne suis pas convaincu qu'on puisse faire ce que tu veux avec iptables.
-
Je suis curieux de savoir si tu as trouvé une solution finalement Vivien ?
-
Non, j'ai plus avancé sur les nouveaux fichiers de test de débit.
Ce sont des fichiers .zip qui font exactement 1 000 000 / 10 000 000 / 100 000 000 / 1 000 000 000 octets et j'ai un peu galéré à avoir ce volume exact sans rajouter du bourrage à la fin du fichier .zip. J'ai donc une liste de 250 applications open source dont je connais exactement le volume compressé en zip et j'aménage ça pour tomber juste en dessous du volume. j'ai ensuite un petit fichier texte que je remplie pour arriver a un zip de la bonne taille, mais il faut faire des dizaines de compressions pour arriver à la bonne taille.
-
pressé de voir le serveur en prod délivrer du traf
-
Non, j'ai plus avancé sur les nouveaux fichiers de test de débit.
J'ai pas l'impression que hashlimit puisse fonctionner pour ce que tu veux faire. Je me demande si ça existe au niveau de Apache ou Nginx, m'enfin c'est sûr que c'est dommage si tu voulais aussi que ça couvre iperf par exemple.
Après tu dois toujours avoir la solution de faire un script qui regarde régulièrement les logs et ban des IP en fonction mais c'est nettement plus compliqué.
-
Il doit bien exister un truc pour faire de la Qos ou du rate limiting comme quand on a "finit" son forfait ...
-
Étant donné qu'il y a plusieurs serveurs différents (Apache, nPerf serveur Ookla server, iPerf3,...) le plus simple serait de le faire avec iptables.
-
Mais sinon, y'a pas une option plus bête genre :
- Une règle IPtables qui log tout (ou un tcpdump, ou du flow) dans une BDD en ram
- Un select ou autre pour additionner les paquets/trafic
- Un déclencheur qui envoie un iptables drop && sleep 3600 && iptables -D
Moi je sais pas faire, mais ptet que d'autres, oui ?
-
Et sinon sans limite non ?
-
Oui, on peu commencer sans limite, mais le problème risque de se poser rapidement et les conséquences pour Appliwave peuvent être plus importantes que pour Bouygues Telecom.
Pour info, voici le trafic sur le serveur de bouygues.testdebit.info ce soir :
(https://lafibre.info/images/stats/202105_stats_bouygues_serveur_paris.png)
Un TCPDump il faut oublier vu les débit obtenus.
Les flow, c'est bien on peut échantillonner (prendre un paquet sur 1000 par exemple) mais cela me semble bien complexe à mettre en place.
Je pensais également que iptables pourrait faire quelques chose, peut être en plusieurs lignes ou en déclenchant un script qui bloque l'IP puis supprimer le blocage après un sleep.
Je suis sur que je ne suis pas le premier à avoir ce type de besoin... c'est étonnant de ne rien trouver.
-
On a de la capa. Genre vraiment. Donc fait toi plaisir on verra plus tard si ça pose problème
-
Ok. j'essaye de le mettre en place demain.
Là, j'ai bloqué le nouveau fauteur de trouble, encore une IPv4 Google : 35.204.171.47
Même version de Curl que la dernière fois, seul l'IPv4 a changé.
35.204.171.47 58870 80 [01/May/2021:22:04:16 +0200] "GET /10G/10G.iso HTTP/1.1" 200 10000000245 "-" "curl/7.55.1"
35.204.171.47 58877 80 [01/May/2021:22:04:35 +0200] "GET /10G/10G.iso HTTP/1.1" 200 10000000245 "-" "curl/7.55.1"
35.204.171.47 58885 80 [01/May/2021:22:05:01 +0200] "GET /10G/10G.iso HTTP/1.1" 200 10000000245 "-" "curl/7.55.1"
-
Ah sinon j'ai eu une idée
Fastnetmon + netflow
Tu dis que tu veux bannir quand un flux passe 1G par exemple, et tu règle le timeout des flows actifs assez haut (genre 15 minutes) -> si l'IP dépasse 1G sur 15 minutes, un script sera déclenché et bloquera l'IP pendant le temps que tu veux
-
Ok. j'essaye de le mettre en place demain.
Là, j'ai bloqué le nouveau fauteur de trouble, encore une IPv4 Google : 35.204.171.47
Même version de Curl que la dernière fois, seul l'IPv4 a changé.
35.204.171.47 58870 80 [01/May/2021:22:04:16 +0200] "GET /10G/10G.iso HTTP/1.1" 200 10000000245 "-" "curl/7.55.1"
35.204.171.47 58877 80 [01/May/2021:22:04:35 +0200] "GET /10G/10G.iso HTTP/1.1" 200 10000000245 "-" "curl/7.55.1"
35.204.171.47 58885 80 [01/May/2021:22:05:01 +0200] "GET /10G/10G.iso HTTP/1.1" 200 10000000245 "-" "curl/7.55.1"
Tu as tenté de joindre Google ?
-
Sinon bannir les IP de google c'est une possibilité aussi, Je ne vois pas d'usage légitime :P
-
Non, je n'ai pas contacté Google, même si kgersen me l'a suggéré :
Tu peux déjà signaler a Google pour qu'ils recherchent le coupable. https://support.google.com/code/contact/cloud_platform_report si l'IP est dans leur blocs GCP : https://www.gstatic.com/ipranges/cloud.json (ce qui a l'air d'être le cas). C'est peut-être un compte GCP compromis.
Le ban a réglé le problème sur les serveurs de province, mais je vois que j'ai encore 8 Gb/s de trafic moyen sur le serveur de Paris les deux IP Google bloquées. Cela semble venir de iperf3 vu que ce n'est pas dans les log Apache.
-
iftop pour trouver l'ip
-
Mon cahier des charges, dans mes rêves, c'est de mettre un maximum de 30 Go de données transférée par période de 8 heures. Cela nécessite une grosse table qui est vidée toutes les 8 heures.
Au-delà de ces 30 Go, l'IP est bloquée par iptables pour une durée de 8h à partir du moment où elle a dépassée le quotas, afin d'éviter que simultanément toutes les IP bloquées soient de nouveau autorisée, ce qui pourrait provoquer une saturation si il y a un script qui boucle.
Attention aux IP partagées quand même.
Pour Free, on peut ajuster pour supporter 4 clients, mais pour SFR et son CGNAT IPv4, ça ne risque pas de poser problème ?
Ou alors il faut un seuil bien plus haut, qui n'attrapera que les utilisations probablement malveillantes comme les IP Google actuellement, et pas les utilisateurs un peu abusifs qui feraient des tests automatiques de manière trop fréquente.
-
Attention aux IP partagées quand même.
Pour Free, on peut ajuster pour supporter 4 clients, mais pour SFR et son CGNAT IPv4, ça ne risque pas de poser problème ?
La probabilité que les 4 abonnés Free fassent plusieurs tests sur le même serveur durant le même intervalle de temps doit être minime.
-
On parle d'un black-listage d'IPv4 ou d'un /64 IPv6 quelques heures.
Les abonnés qui sont en partage d'IPv4 ont presque toujours de l'IPv6, donc ils ne sont pas impactés.
- SFR et Free : Dans les deux cas, les abonnés avec partage d'IPv4 ont de l'IPv6 et ne peuvent pas désactiver IPv6 sur leur box.
- Bouygues Telecom : Le partage d'IPv4 semble au stade de l'expérimentation pour voir d'éventuels retours clients et on peut penser qu'ils on pris les zones où il y a de l'IPv6, pour limiter l'impact (ex: Google qui dit qu'il y a trop de recherche depuis la même IP et qui demande de remplir un captcha).
L'idée serait aussi pour moi de bloquer ceux qui ont mis un SpeedTest toutes les 5 minutes dans leur crontab : Il n'est pas souhaitable de le faire aussi souvent.
Vous contribuez à la saturation avec vos tests de débit réguliers...
PS: Pour hier, le trafic sur Paris était lié au fait que je n'avais pas bloqué la bonne IPv4.
-
Je suis sur que je ne suis pas le premier à avoir ce type de besoin... c'est étonnant de ne rien trouver.
Ah ben les sites d'hébergement de fichiers savent très bien faire ça mais à mon avis ils gèrent ça au niveau de l'applicatif comme ils n'ont qu'un trafic HTTP(S) en général.
-
Les abonnés qui sont en partage d'IPv4 ont presque toujours de l'IPv6, donc ils ne sont pas impactés.
Ils peuvent avoir envie de tester leur débit IPv4, pour voir si le tunnel ou l'équipement CGNAT de l'opérateur tient la charge.
Puisqu'il y a encore beaucoup de sites sans IPv6, ça reste représentatif d'un usage réel.
Bien sûr ça ne concerne probablement qu'une minorité des tests, la probabilité de voir plusieurs abonnés le faire sur la même IP est faible chez Free, mais pour les autre ça va dépendre du nombre de clients par IP.
-
Ah ben les sites d'hébergement de fichiers savent très bien faire ça mais à mon avis ils gèrent ça au niveau de l'applicatif comme ils n'ont qu'un trafic HTTP(S) en général.
Initialement, certains le faisaient sur l'IPv6 complète et pas le préfixe, ce qui faisait que la limite pouvait être contournée.
-
Sur un serveur 40 Gbs il faut mieux mettre en œuvre cette restriction au niveau applicatif qu'au niveau IP (3).
Ca veut dire soit en mettant un reverse proxy qui fait cela , soit en intervenant dans le serveur web (du moins tant que tu conserve un système de mires a base d'un serveur web standard).
Quelques recherches:
- mod_cband pour Apache2 a l'air de faire cela mais on trouve peu d'info et il est assez ancien. voir https://www.howtoforge.com/mod_cband_apache2_bandwidth_quota_throttling_p3
Pas sur que ca prenne en compte IPv6 . (on trouve des forks plus récents sur github mais je n'ai pas cherché plus. ( https://github.com/search?q=mod_cban notamment https://github.com/vobruba-martin/mod_cband ).
- Le programme squish en complément du proxy Squid a aussi ce genre de fonctionnalités mais je ne sais si elle s'appliquent aussi en mode reverse proxy
Dans les 2 cas ce sont des 'vieux' trucs pas forcement maintenus/a jour/bug free mais mod_cband a pas l'air mal (CBandUserLimit semble correspondre a ton besoin)
-
Ouais enfin pour faire du trafic >10G, il vaut mieux éviter de passer par un vieux proxy tout pourri
-
Ouais enfin pour faire du trafic >10G, il vaut mieux éviter de passer par un vieux proxy tout pourri
Je connais peu Squid et je ne le recommanderai pas ici mais des "vieux" proxy comme HAProxy ca tient la route.
Apres son Apache il peut cracher 5000 MB/s (40 Gps) ? ou même son disque aussi vu que c'est un vrai fichier qui est servi ? (a moins qu'il passe par un ramfs ou autre).
Faudrait déja qu'il bench son serveur pour voir ou y'a des limites. Je ne pense pas qu'une seule session tcp puisse atteindre 40 Gbps de toute facon.
-
Certes mais si tu veux proxyfier de l'iperf par exemple, pas dit que ça tienne le débit.
L'idée je pense n'est pas de tenir 40G, plus de pouvoir tenir un test 10G + plusieurs tests 1G
-
Certes mais si tu veux proxyfier de l'iperf par exemple, pas dit que ça tienne le débit.
oui un proxy va surement pas suivre ou alors en bouffant un max de cpu (encore que ca serait intéressant de bench un haproxy devant iperf).
pour iperf on avais un début de solution en 2016 mais Vivien n'a pas poursuivi (enfin je sais plus pourquoi y'a pas eu de suite): https://lafibre.info/iperf/abus-sur-serveur-iperf3-public/
-
mod_cband pour Apache2 a l'air de faire cela mais on trouve peu d'info et il est assez ancien. voir https://www.howtoforge.com/mod_cband_apache2_bandwidth_quota_throttling_p3
Pas sur que ca prenne en compte IPv6 . (on trouve des forks plus récents sur github mais je n'ai pas cherché plus. ( https://github.com/search?q=mod_cban notamment https://github.com/vobruba-martin/mod_cband ).
Il me semble pas que ça fasse ce que Vivien veut, c'est plutôt pour des gens qui font du mutu et qui veulent pouvoir limiter le trafic généré par certains vhost.
-
Il me semble pas que ça fasse ce que Vivien veut, c'est plutôt pour des gens qui font du mutu et qui veulent pouvoir limiter le trafic généré par certains vhost.
Il y'a 3 modes: "per-user, per-virtualhost and per-destination"
CBandLimit c'est par virtualhost
CBandUserLimit c'est par user.
Ce que je ne sais pas c'est si la notion de 'user' peut se ramener a une IPv4/prefix IPv6 ou s'il faut créer des users (au sens "authentification" donc avec un mod_auth...) avant.
-
De ce que j'ai lu la notion d'utilisateur ici n'est pas celle qui intéresse Vivien, ce sont des utilisateurs spécifiques au niveau de "mod_cband" qui permettent de regrouper plusieurs vhost.
-
De ce que j'ai lu la notion d'utilisateur ici n'est pas celle qui intéresse Vivien, ce sont des utilisateurs spécifiques au niveau de "mod_cband" qui permettent de regrouper plusieurs vhost.
ah ok je n'ai pas creusé plus que ca.
-
Savez-vous quel outil permettrait de loguer le volume demandé par chaque IPv4 ou /64 IPv6 et couper automatiquement le flux au-delà d'un certain volume ?
Serveur FTP.
-
Je pense que l'on va faire sans au démarrage.
Je dois être vieux, de la vieille école mais moi un speedtest ca doit pas aller titiller les process style AV comme tu veux les tester...
Tu peux proposer les 2: du urandom incompressible et ton ISO rempli de libreoffice portable ;) je vois ton idée mais laisser le choix c'est mieux...
Il y aura même 3 types de fichiers, je finalise la configuration.
- 1G.zip : A partir de 1Mo, c'est un vrai fichier Zip d'applications Windows open source. Entre 500 Ko et 50 octets, c'est une image (jpeg / png / gif selon les tailles).
- 1G-rand.zip : Données aléatoires (non compressible)
- 1G-zero.zip : Fichier rempli d'octets à la valeur zéro en hexadécimal (très fortement compressible)
Taille et nom des fichiers dans le ramdisque :
10000000000 10G.zip
1000000000 1G-rand.zip
1000000000 1G-zero.zip
1000000000 1G.zip
262144000 250Mi-rand.zip
100000000 100M-rand.zip
100000000 100M-zero.zip
100000000 100M.zip
50000000 50M-rand.zip
50000000 50M-zero.zip
50000000 50M.zip
10000000 10M-rand.zip
10000000 10M-zero.zip
10000000 10M.zip
5000000 5M-rand.zip
5000000 5M-zero.zip
5000000 5M.zip
1000000 1M-rand.zip
1000000 1M-zero.zip
1000000 1M.zip
500000 500k.jpg
500000 500k-rand.jpg
500000 500k-zero.jpg
100000 100k.jpg
100000 100k-rand.jpg
100000 100k-zero.jpg
50000 50k.jpg
50000 50k-rand.jpg
50000 50k-zero.jpg
10000 10k.jpg
10000 10k-rand.jpg
10000 10k-zero.jpg
5000 5k.jpg
5000 5k-rand.jpg
5000 5k-zero.jpg
1000 1k.jpg
1000 1k-rand.jpg
1000 1k-zero.jpg
500 500.png
500 500-rand.png
500 500-zero.png
100 100.png
100 100-rand.png
100 100-zero.png
50 50.gif
50 50-rand.gif
50 50-zero.gif
10 10.exe
10 10-rand.exe
10 10-zero.exe
5 5.exe
5 5-rand.exe
5 5-zero.exe
1 1.exe
1 1-rand.exe
1 1-zero.exe
0 0.exe
0 0-rand.exe
0 0-zero.exe
Ces fichiers seront disponibles dans pleins d'extensions, via des liens réalisé vers le fichier d'origine.
Tous ces fichiers sont en ramdisque (rempli automatiquement au démarrage du serveur), permettant un débit de 40 Gb/s.
J'utilise une archive au format LZ4 (https://en.wikipedia.org/wiki/LZ4_(compression_algorithm)) pour remplir le ramdisque (il y l'ensemble des fichiers dans l'archive LZ4). C'est un format vraiment intéressant, car en décompression il n'utilise presque pas de CPU et il permet donc de gagner en temps CPU et disque.
Comparaison du temps CPU pour un fichier test (https://catchchallenger.first-world.info/wiki/Quick_Benchmark:_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO) :
- gzip compression: 8.1secondes - décompression: 3.5s
- bzip compression: 258.3secondes - décompression: 3.4s
- lzma compression: 31.7secondes - décompression: 6.7s
- lzma -e compression: 4m37secondes - décompression: 5.9s
- xz compression: 32.2secondes - décompression: 7.2s
- xz -e compression: 4m40secondes - décompression: 6.5s
- lz4 compression: 1.3secondes - décompression: 0.4s
- lzop compression: 1.6secondes - décompression: 1.5s
-
Je pense que l'on va faire sans au démarrage.
Il y a des développeurs sur lafibre.info, je pense qu'on doit pouvoir réussir à te faire un module pour Apache2 si nécessaire.
Pour iperf, je pense que la solution développée par kgersen est un bon début qu'il y a toujours moyen d'améliorer si besoin.
-
Je ne suis pas convaincu d'un serveur de mires bâti sur Apache2 ;D
Au moins Nginx ou un truc plus moderne mais Apache2 ::)
Cela dit , il faudrait bencher Apache vs NGinx vs Caddy (vs NSpeed quand stable) pour confirmer tout ca. L'avantage de NSpeed est que les 'fichiers' sont dynamiquement générés en terme de taille et de type ( j'ai même prévu plus tard de pouvoir choisir les 512 premiers octets pour les détecteurs de contenu et autre anti-virus) donc y'a aucune charge cpu & appel système pour lire des fichiers.
Sinon tout les serveurs web peuvent même mettre en cache eux même des fichiers statiques et les "serviront" plus rapidement que via un ramdisk (car ils ne feront plus de 'read' système (syscall) pour lire les données). y'a mod_file_cache par exemple pour Apache il me semble (mais je n'ai jamais benché cela).
Apres si le cpu est surdimensionné pour 40 Gbps ca ne fera pas grande différence a part la température ;) C'est toujours le même combat entre logiciel et matériel: si t'as pas le code optimisé ou qui va bien tu mets du gros matos hardware pour compenser...c'est souvent moins cher, plus simple et rapide à mettre en œuvre d'ailleurs que de développer du code.
-
Apache2 a plusieurs mode de fonctionnement possible.
- prefork
- worker
- event
NGinx avait un vrai avantage à l'époque ou prefork était la seule solution possible, car si prefork convient aux sites qui doivent éviter les threads pour assurer la compatibilité avec les bibliothèques non thread-safe, il est connu pour ne pas pouvoir monter en charge ou consommer beaucoup de ressources.
Le MPM event est un peu une copie du mode de fonctionnement de NGinx et il consomme peu de ressources, même avec des sites a plus de 1000 requêtes par secondes. (exemple: https://ubuntu.lafibre.info/stats/stats_server.html?version=last )
-
Apache2 a plusieurs mode de fonctionnement possible.
- prefork
- worker
- event
NGinx avait un vrai avantage à l'époque ou prefork était la seule solution possible, car si prefork convient aux sites qui doivent éviter les threads pour assurer la compatibilité avec les bibliothèques non thread-safe, il est connu pour ne pas pouvoir monter en charge ou consommer beaucoup de ressources.
Le MPM event est un peu une copie du mode de fonctionnement de NGinx et il consomme peu de ressources, même avec des sites a plus de 1000 requêtes par secondes. (exemple: https://ubuntu.lafibre.info/stats/stats_server.html?version=last )
Je parlais de la perf brut de servir un fichier statique (débit de sortie vs conso cpu).
Y'a peu de benchmarks la dessus car les gens comparent surtout Apache vs NGinx sur le nombre de requêtes servies par seconde, donc le temps de 'réaction' mais pas trop le temps total d'envoi d'un gros contenu statique. Bref sur des critères de comparaison qui ne sont pas pertinents dans ton cas.
C'est peut-être pour ca qu'il serait intéressant d'installer Apache2, NGinx et Caddy sur ton serveur et voir celui qui consomme le moins de ressources pour une requête d'envoi de 10G par exemple.
De toute façon, c'est celui qui administre qui choisi surtout si la différence est minime. Moi si je gérais le serveur je ne prendrais pas Apache mais si tu es a l'aise et préfère Apache autant le garder si la différence de perf n'impacte pas ton usage.
Apres en terme d'évolutivité et 'features' tu trouveras plus de monde pour te faire des modules spécifiques pour Caddy que pour les 2 autres. Et encore plus quand/si y'aura un serveur écrit en Rust (car y'a un effet mode assez fort... :P ).
Concernant Nspeed, ce n'est de toute façon pas prêt pour mettre en production 24/7 même si a terme y'aura peut-être un module iperf3 (via libiperf3 ou un rewrite du protocol), http/3,webrtc dedans.
Comme tu dis, commence par ce que tu connais et maitrise et tu verra a l'usage ou ca pèche.
Si le souci n°1 sont les abus comme tu rencontre: pour iperf3 on peut peut-être faire quelque chose et pour les mires statiques aussi via un simple script d'analyse des logs d'Apache par exemple.
-
Y'a peu de benchmarks la dessus car les gens comparent surtout Apache vs NGinx sur le nombre de requêtes servies par seconde, donc le temps de 'réaction' mais pas trop le temps total d'envoi d'un gros contenu statique. Bref sur des critères de comparaison qui ne sont pas pertinents dans ton cas.
A mon avis c'est très probablement parce qu'aucun ne se démarque particulièrement car dans ce type d'usage le surcoût lié à l'applicatif est faible, la performance est liée avant tout à la bande passante des différents composants (stockage, mémoire vive et réseau).
-
J'utilise une archive au format LZ4 (https://en.wikipedia.org/wiki/LZ4_(compression_algorithm)) pour remplir le ramdisque (il y l'ensemble des fichiers dans l'archive LZ4). C'est un format vraiment intéressant, car en décompression il n'utilise presque pas de CPU et il permet donc de gagner en temps CPU et disque.
Il y a zstd maintenant.
L'avantage de NSpeed est que les 'fichiers' sont dynamiquement générés en terme de taille et de type donc y'a aucune charge cpu & appel système pour lire des fichiers.
D'un autre côté ça empêche d'utiliser sendfile() directement, pour éviter une copie userspace vers kernel, voire d'éviter la copie tout court.
Les données répétées (blocs de 0, ou blocs aléatoires dupliqués) peuvent toujours être copiées en shared memory, et envoyées via une série de sendfile.
-
Il y a zstd maintenant.
Ah zut je n'avais pas vu.
Il est plus performant que LZ4 ? (je pense surtout en décompression)
-
D'un autre côté ça empêche d'utiliser sendfile() directement, pour éviter une copie userspace vers kernel, voire d'éviter la copie tout court.
Les données répétées (blocs de 0, ou blocs aléatoires dupliqués) peuvent toujours être copiées en shared memory, et envoyées via une série de sendfile.
oui c'est un aspect que je n'ai pas encore regardé y'a pas trop de souci de perf en envoi pour le moment. et Go utilise sendfile quand c'est possible.
Faut voir aussi si en HTTPS le chiffrement se fait dans le kernel (voir même dans le driver de la carte) car sinon sendfile ne sert plus trop. C'est d'ailleurs une info que je cherche a diagnostiquer.
-
Ah zut je n'avais pas vu.
Il est plus performant que LZ4 ? (je pense surtout en décompression)
Il est moins rapide à décompresser que LZ4 en général, mais il reste très rapide, et comme il compresse mieux, tout dépend si c'est la source qui limite.
Il sait utiliser plusieurs threads pour compresser (pas encore pour décompresser).
A moins de vouloir dé-dupliquer les données (comme j'avais suggéré avec du btrfs à un moment), un ramdisk ne sert à rien : des fichiers dans un tmpfs c'est plus simple.
Les fichiers aléatoires, ce n'est pas très utile de les compresser.
Sinon, dans ce bench inhabituel, les deux se valent : pour le 1G.iso des serveurs actuels, c'est 0,36s avec zstd, 0,31s avec lz4.
Les vrais zip ne doivent pas être si loin que ça des fichiers aléatoires.
Les fichiers remplis uniquement de 0, on peut les créer avec une simple commande (et sans forcément prendre de place, selon le système de fichiers) : "truncate -s 1000000000 1G-zero.zip".
Sinon, dans ce bench inhabituel, zstd compresse 1Go de 0 en 44Ko au lieu de 4,1Mo (mais ça ne change pas grand chose), et les décompresse en 0,26s contre 0,52s pour lz4.
-
oui c'est un aspect que je n'ai pas encore regardé y'a pas trop de souci de perf en envoi pour le moment. et Go utilise sendfile quand c'est possible.
Faut voir aussi si en HTTPS le chiffrement se fait dans le kernel (voir même dans le driver de la carte) car sinon sendfile ne sert plus trop. C'est d'ailleurs une info que je cherche a diagnostiquer.
Je ne savais pas que ça avait été implémenté pour Linux.
https://www.kernel.org/doc/html/latest/networking/tls.html
C'est effectivement utilisable avec sendfile, avec /dev/zero ça peut être sympa, peut-être même pour envoyer des données aléatoires à un client HTTP.
https://www.kernel.org/doc/html/latest/networking/tls-offload.html
Les seuls drivers que je trouve avec accéléation :
- Mellanox ConnectX-6 Dx
- Chelsio T6
- Netronome NFP4000/NFP6000
Bref, c'est probablement trop cher et exclusif pour trouver ça dans un serveur de test de débit ;D
-
Tiens un serveur 40Gb/s sur NPERF chez Appliwave ;)
Test via FTTO 100mb/s Covage
-
Oui, je n'en ai pas encore parlé car tout n'est pas sec : Il n'est pas disponible en IPv6 chez nPerf et le logo d'Appliwave ne s'affiche pas (il devrait s'afficher à gauche de "choix du serveur"). Cela va être bientôt corrigé.
Si vous souhaitez faire un test à très haut débit, je vous conseille de demander l’accès à la bêta de l'application nPerf pour PC, disponible pour Windows, Ubuntu et MacOS.
=> [Beta-test] Application nPerf pour Windows, Mac, Linux (https://lafibre.info/tester-son-debit/beta-test-application-nperf-pour-windows-mac-linux/).
Le serveur Appliwave est déjà disponible sur SpeedTest.net (Ookla), il suffit de chercher "Appliwave". Le test est réalisé en IPv6 si vous êtes en IPv6.
Là aussi pour de l'ultra haut débit (> 1 Gb/s), l'application installable est conseillée.
Il a été validé par QoSi pour les applications comme "5GMark", "DébitTest" l'application mobile de 60 Millions de consommateur, "QuelDébit" l'application mobile UFC Que choisir et les différentes applications de test de débit régional ("Tu captes" pour la région Hauts-de-France, "KiCapte" pour le département d'Ille-et-Vilaine, "Gigalis" pour le syndicat mixte des Pays de la Loire, celle de la région Bourgogne-Franche-Compté et une application européenne. Il est peut-être déjà en prod, je n'ai pas vérifié, mais ces applications ne permettent pas de choisir son serveur. Le test est réalisé en IPv6 si vous êtes en IPv6.
La demande est en cours de traitement pour IPv6-test (https://lafibre.info/pingtest/).
-
Ah oui quand même !
Merci Vivien ;)
-
Le serveur Appliwave est déclaré sur https://ipv6-test.com/speedtest/
Il ne reste qu'une problématique : Les IPv4 et IPv6 (nom de domaine v4.pa.fr.ipv6-test.com et v6.pa.fr.ipv6-test.com) pointe encore sur l'ancien serveur Bouygues Telecom.
Je fais signe quand tout est ok.
-
Bonjour,
Le serveur @ CBO semble avoir quelques problèmes de latence : http://nperf.as205816.net:1800/cgi-bin/smokeping.cgi?target=ASN-NETWORKS-FRANCE.FR-AS200780-CBO
aled Vivien !
guizmo34
-
C'est corrigé. Je vais vous expliquer ce qu'il s'est passé.
Actuellement, la campagne de test Arcep dans les DROM se prépare et on m'a demandé de tester la performance des serveurs mis en place par les prestataires (il y a des serveurs en France, aux USA pour les caraïbes,...)
J'ai réalisé les tests depuis plusieurs point de tests dont Appliwave. Les tests réalisés depuis Appliwave s'est montré le plus stable.
Aujourd'hui on m'a informé qu'un opérateur suspectait un problème de fenêtre sur un serveur. Le meillur moyen pour comparer les serveurs est de les tester tous à la même latence, soit 110ms la latence entre Appliwave et le serveur de Miami.
J'ai donc modifié mon script de test pour rajouter de la latence (pour OVH, j’ai rajouté 105ms via NetEm, pour Bouygues Paris 109ms, pour Scaleway Amsterdam 97ms, pour New-York 37ms et pour Miami 0ms). Cela a permis de tester tous les serveurs avec une même latence.
Problème : j'ai complètement oublié que je n'étais pas sur un PC connecté à une box, mais sur un serveur et que ces ajouts de latence impactent tous les utilisateurs.
Les tests se sont déroulés de 12h30 à 16h00 et étaient de courte durée, mais à la fin du script la dernière latence restait et visiblement le dernier test était proche de Paris et donc je rajoutais une latence importante qui restait jusqu'au rappel du script 10 minutes plus tard.
Promis, je ne recommencerais plus et bravo à Appliwave pour la qualité de ses peering / transit.
-
T'es tellement transparent que j'arrive à voir à travers. :o