C'est un modem-routeur SpeedTouch 716v5 qui assure ma connexion à l'internet
en adsl et cet appareil est configuré pour répondre au ping sur toutes ses
interfaces. De l'intérieur du réseau local je peux « pinguer » mon adresse
externe et le serveur de degrouptest le peut également, mais pas les deux
correspondants à qui j'ai demandé de tenter le ping depuis leurs ordinateurs
(sous Linux Mageia 2).
Qu'est-ce qui peut bien expliquer ces échecs ?
Si si, elle n'a pas changé depuis hier soir. Par contre, je viens de faire ce qui est indiqué ici : http://www.dslreports.com/forum/r19717047-How-to-make-SpeedTouch-546-pingable
[...]
Qu'est-ce que ça donne à présent ? (Même IP qu'hier.)
A présent ça répond.
geo cherchetout a écrit :
Si si, elle n'a pas changé depuis hier soir. Par contre, je viens de faire
ce qui est indiqué ici :
http://www.dslreports.com/forum/r19717047-How-to-make-SpeedTouch-546-pingable
[...]
Qu'est-ce que ça donne à présent ? (Même IP qu'hier.)
Si si, elle n'a pas changé depuis hier soir. Par contre, je viens de faire ce qui est indiqué ici : http://www.dslreports.com/forum/r19717047-How-to-make-SpeedTouch-546-pingable
[...]
Qu'est-ce que ça donne à présent ? (Même IP qu'hier.)
A présent ça répond.
geo cherchetout
Le 30/12/2012 12:05, *Pascal Hambourg* a écrit fort à propos :
A présent ça répond.
OK, merci. :-) Ça répond aussi depuis chez un linuxien abonné chez SFR, mais avec un délai moyen de 70 ms.
Le 30/12/2012 12:05, *Pascal Hambourg* a écrit fort à propos :
A présent ça répond.
OK, merci. :-) Ça répond aussi depuis chez un linuxien abonné chez SFR, mais
avec un délai moyen de 70 ms.
Le 30/12/2012 12:05, *Pascal Hambourg* a écrit fort à propos :
A présent ça répond.
OK, merci. :-) Ça répond aussi depuis chez un linuxien abonné chez SFR, mais avec un délai moyen de 70 ms.
geo cherchetout
Le 29/12/2012 21:48, *Pascal Hambourg* a écrit fort à propos :
Tu es sûr pour le ping depuis Degrouptest ? Si c'est lors du test de débit, ce ne serait pas plutôt ton navigateur qui enverrait un ping vers leur serveur ?
Je viens de réaliser une capture avec wireshark lors d'un test de débit sur le site degrouptest.com et aucun paquet du type ICMP n'y figure. En revanche j'y vois 10 paquets HTTP contenant « GET /ookla/speedtest/latency/.txt?x= suivi de la date au format epoch ». Que dois-je en conclure ?
Le 29/12/2012 21:48, *Pascal Hambourg* a écrit fort à propos :
Tu es sûr pour le ping depuis Degrouptest ? Si c'est lors du test de
débit, ce ne serait pas plutôt ton navigateur qui enverrait un ping vers
leur serveur ?
Je viens de réaliser une capture avec wireshark lors d'un test de débit sur
le site degrouptest.com et aucun paquet du type ICMP n'y figure. En revanche
j'y vois 10 paquets HTTP contenant « GET /ookla/speedtest/latency/.txt?x=
suivi de la date au format epoch ».
Que dois-je en conclure ?
Le 29/12/2012 21:48, *Pascal Hambourg* a écrit fort à propos :
Tu es sûr pour le ping depuis Degrouptest ? Si c'est lors du test de débit, ce ne serait pas plutôt ton navigateur qui enverrait un ping vers leur serveur ?
Je viens de réaliser une capture avec wireshark lors d'un test de débit sur le site degrouptest.com et aucun paquet du type ICMP n'y figure. En revanche j'y vois 10 paquets HTTP contenant « GET /ookla/speedtest/latency/.txt?x= suivi de la date au format epoch ». Que dois-je en conclure ?
Le Forgeron
Le 30/12/2012 23:12, geo cherchetout nous fit lire :
Le 29/12/2012 21:48, *Pascal Hambourg* a écrit fort à propos :
Tu es sûr pour le ping depuis Degrouptest ? Si c'est lors du test de débit, ce ne serait pas plutôt ton navigateur qui enverrait un ping vers leur serveur ?
Je viens de réaliser une capture avec wireshark lors d'un test de débit sur le site degrouptest.com et aucun paquet du type ICMP n'y figure. En revanche j'y vois 10 paquets HTTP contenant « GET /ookla/speedtest/latency/.txt?x= suivi de la date au format epoch ». Que dois-je en conclure ?
A quoi sert le ping ? (grosso modo) 1. à vérifier l'existence d'une machine 2. à connaître la route entre deux machines 3. à connaître la latence (du réseau) entre deux machines
Le point 1, dans le cas de degrouptest.com, on s'en tape (vu que c'est l'utilisateur qui fait la demande depuis sa machine... ça tourne à la Lapalissade) Le point 2 n'est pas non plus l'objet de l’intérêt du site. Reste le point 3... et là il y a un gros obstacle pour M. Michu : les NAT et autres firewalls dans le réseau des FAI. Faire de l'ICMP, c'est prendre le risque d'une mauvaise image auprès de ses utilisateurs, dans le cas où ça ne marcherait pas. ("Rah, trop nul ce site... " (paille & poutre habituelles)) Alors qu'avec une ouverture de connexion TCP normale, on obtient la même information(*) et que lui va traverser sans soucis les NAT et les firewalls (vu que l'initiateur est la machine de l'utilisateur, on passe donc d'un domaine "de confiance" (chez l'abonné) à la jungle (Internet), donc le FAI n'a pas de raison de ne pas autoriser cette connexion).
*: à l'ouverture d'une connexion TCP, il y a un premier paquet qui part de chez l'utilisateur vers le serveur, celui-ci répond avec un paquet qui déclenche l'envoi d'un second paquet de la machine de l'utilisateur. Le serveur n'a plus qu'à mesurer le temps entre l'arrivée des deux paquets pour connaître la latence du réseau.
L'horodatage de l'URL sert probablement a éviter les DoS (Deny of Service) par répétition (bof...)
Le 30/12/2012 23:12, geo cherchetout nous fit lire :
Le 29/12/2012 21:48, *Pascal Hambourg* a écrit fort à propos :
Tu es sûr pour le ping depuis Degrouptest ? Si c'est lors du test de
débit, ce ne serait pas plutôt ton navigateur qui enverrait un ping vers
leur serveur ?
Je viens de réaliser une capture avec wireshark lors d'un test de débit
sur le site degrouptest.com et aucun paquet du type ICMP n'y figure. En
revanche j'y vois 10 paquets HTTP contenant « GET
/ookla/speedtest/latency/.txt?x= suivi de la date au format epoch ».
Que dois-je en conclure ?
A quoi sert le ping ? (grosso modo)
1. à vérifier l'existence d'une machine
2. à connaître la route entre deux machines
3. à connaître la latence (du réseau) entre deux machines
Le point 1, dans le cas de degrouptest.com, on s'en tape (vu que c'est
l'utilisateur qui fait la demande depuis sa machine... ça tourne à la
Lapalissade)
Le point 2 n'est pas non plus l'objet de l’intérêt du site.
Reste le point 3... et là il y a un gros obstacle pour M. Michu : les
NAT et autres firewalls dans le réseau des FAI. Faire de l'ICMP, c'est
prendre le risque d'une mauvaise image auprès de ses utilisateurs, dans
le cas où ça ne marcherait pas.
("Rah, trop nul ce site... " (paille & poutre habituelles))
Alors qu'avec une ouverture de connexion TCP normale, on obtient la même
information(*) et que lui va traverser sans soucis les NAT et les
firewalls (vu que l'initiateur est la machine de l'utilisateur, on passe
donc d'un domaine "de confiance" (chez l'abonné) à la jungle (Internet),
donc le FAI n'a pas de raison de ne pas autoriser cette connexion).
*: à l'ouverture d'une connexion TCP, il y a un premier paquet qui part
de chez l'utilisateur vers le serveur, celui-ci répond avec un paquet
qui déclenche l'envoi d'un second paquet de la machine de l'utilisateur.
Le serveur n'a plus qu'à mesurer le temps entre l'arrivée des deux
paquets pour connaître la latence du réseau.
L'horodatage de l'URL sert probablement a éviter les DoS (Deny of
Service) par répétition (bof...)
Le 30/12/2012 23:12, geo cherchetout nous fit lire :
Le 29/12/2012 21:48, *Pascal Hambourg* a écrit fort à propos :
Tu es sûr pour le ping depuis Degrouptest ? Si c'est lors du test de débit, ce ne serait pas plutôt ton navigateur qui enverrait un ping vers leur serveur ?
Je viens de réaliser une capture avec wireshark lors d'un test de débit sur le site degrouptest.com et aucun paquet du type ICMP n'y figure. En revanche j'y vois 10 paquets HTTP contenant « GET /ookla/speedtest/latency/.txt?x= suivi de la date au format epoch ». Que dois-je en conclure ?
A quoi sert le ping ? (grosso modo) 1. à vérifier l'existence d'une machine 2. à connaître la route entre deux machines 3. à connaître la latence (du réseau) entre deux machines
Le point 1, dans le cas de degrouptest.com, on s'en tape (vu que c'est l'utilisateur qui fait la demande depuis sa machine... ça tourne à la Lapalissade) Le point 2 n'est pas non plus l'objet de l’intérêt du site. Reste le point 3... et là il y a un gros obstacle pour M. Michu : les NAT et autres firewalls dans le réseau des FAI. Faire de l'ICMP, c'est prendre le risque d'une mauvaise image auprès de ses utilisateurs, dans le cas où ça ne marcherait pas. ("Rah, trop nul ce site... " (paille & poutre habituelles)) Alors qu'avec une ouverture de connexion TCP normale, on obtient la même information(*) et que lui va traverser sans soucis les NAT et les firewalls (vu que l'initiateur est la machine de l'utilisateur, on passe donc d'un domaine "de confiance" (chez l'abonné) à la jungle (Internet), donc le FAI n'a pas de raison de ne pas autoriser cette connexion).
*: à l'ouverture d'une connexion TCP, il y a un premier paquet qui part de chez l'utilisateur vers le serveur, celui-ci répond avec un paquet qui déclenche l'envoi d'un second paquet de la machine de l'utilisateur. Le serveur n'a plus qu'à mesurer le temps entre l'arrivée des deux paquets pour connaître la latence du réseau.
L'horodatage de l'URL sert probablement a éviter les DoS (Deny of Service) par répétition (bof...)
geo cherchetout
Le 31/12/2012 08:46, *Le Forgeron* a écrit fort à propos :
*: à l'ouverture d'une connexion TCP, il y a un premier paquet qui part de chez l'utilisateur vers le serveur, celui-ci répond avec un paquet qui déclenche l'envoi d'un second paquet de la machine de l'utilisateur. Le serveur n'a plus qu'à mesurer le temps entre l'arrivée des deux paquets pour connaître la latence du réseau.
L'horodatage de l'URL sert probablement a éviter les DoS (Deny of Service) par répétition (bof...)
En somme Degrouptest pratique le ping sans utiliser la commande ping ? C'est bien ce que je croyais comprendre mais ton explication ne me satisfait pas complètement. La latence mesurée engloberait les deux sens de transmission et le temps de réaction de mon ordinateur ?
Le 31/12/2012 08:46, *Le Forgeron* a écrit fort à propos :
*: à l'ouverture d'une connexion TCP, il y a un premier paquet qui part
de chez l'utilisateur vers le serveur, celui-ci répond avec un paquet
qui déclenche l'envoi d'un second paquet de la machine de l'utilisateur.
Le serveur n'a plus qu'à mesurer le temps entre l'arrivée des deux
paquets pour connaître la latence du réseau.
L'horodatage de l'URL sert probablement a éviter les DoS (Deny of
Service) par répétition (bof...)
En somme Degrouptest pratique le ping sans utiliser la commande ping ? C'est
bien ce que je croyais comprendre mais ton explication ne me satisfait pas
complètement. La latence mesurée engloberait les deux sens de transmission
et le temps de réaction de mon ordinateur ?
Le 31/12/2012 08:46, *Le Forgeron* a écrit fort à propos :
*: à l'ouverture d'une connexion TCP, il y a un premier paquet qui part de chez l'utilisateur vers le serveur, celui-ci répond avec un paquet qui déclenche l'envoi d'un second paquet de la machine de l'utilisateur. Le serveur n'a plus qu'à mesurer le temps entre l'arrivée des deux paquets pour connaître la latence du réseau.
L'horodatage de l'URL sert probablement a éviter les DoS (Deny of Service) par répétition (bof...)
En somme Degrouptest pratique le ping sans utiliser la commande ping ? C'est bien ce que je croyais comprendre mais ton explication ne me satisfait pas complètement. La latence mesurée engloberait les deux sens de transmission et le temps de réaction de mon ordinateur ?
Nicolas George
geo cherchetout , dans le message <50e15322$0$1405$, a écrit :
complètement. La latence mesurée engloberait les deux sens de transmission
C'est inévitable : à moins que les deux ordinateurs soient réglés sur une heure commune largement plus précise que la latence (horloge atomique ou récepteur GPS ; NTP estime la latence donc ne convient pas), il faut bien mesurer la latence au même point pour avoir la même heure.
et le temps de réaction de mon ordinateur ?
Ça aussi, c'est inévitable. On peut arguer que la réactivité d'une couche réseau basse est meilleure que la réactivité d'une grosse application userland, mais dans les bonnes conditions ça devrait être nettement inférieur à la latence.
geo cherchetout , dans le message
<50e15322$0$1405$ba4acef3@reader.news.orange.fr>, a écrit :
complètement. La latence mesurée engloberait les deux sens de transmission
C'est inévitable : à moins que les deux ordinateurs soient réglés sur une
heure commune largement plus précise que la latence (horloge atomique ou
récepteur GPS ; NTP estime la latence donc ne convient pas), il faut bien
mesurer la latence au même point pour avoir la même heure.
et le temps de réaction de mon ordinateur ?
Ça aussi, c'est inévitable. On peut arguer que la réactivité d'une couche
réseau basse est meilleure que la réactivité d'une grosse application
userland, mais dans les bonnes conditions ça devrait être nettement
inférieur à la latence.
geo cherchetout , dans le message <50e15322$0$1405$, a écrit :
complètement. La latence mesurée engloberait les deux sens de transmission
C'est inévitable : à moins que les deux ordinateurs soient réglés sur une heure commune largement plus précise que la latence (horloge atomique ou récepteur GPS ; NTP estime la latence donc ne convient pas), il faut bien mesurer la latence au même point pour avoir la même heure.
et le temps de réaction de mon ordinateur ?
Ça aussi, c'est inévitable. On peut arguer que la réactivité d'une couche réseau basse est meilleure que la réactivité d'une grosse application userland, mais dans les bonnes conditions ça devrait être nettement inférieur à la latence.
Pascal Hambourg
Le Forgeron a écrit :
Le 30/12/2012 23:12, geo cherchetout nous fit lire :
Je viens de réaliser une capture avec wireshark lors d'un test de débit sur le site degrouptest.com et aucun paquet du type ICMP n'y figure. En revanche j'y vois 10 paquets HTTP contenant « GET /ookla/speedtest/latency/.txt?x= suivi de la date au format epoch ». Que dois-je en conclure ?
A quoi sert le ping ? (grosso modo) 1. à vérifier l'existence d'une machine 2. à connaître la route entre deux machines
Ping ne permet pas de déterminer un chemin. C'est plutôt traceroute.
3. à connaître la latence (du réseau) entre deux machines
[...]
Reste le point 3... et là il y a un gros obstacle pour M. Michu : les NAT et autres firewalls dans le réseau des FAI. Faire de l'ICMP, c'est prendre le risque d'une mauvaise image auprès de ses utilisateurs, dans le cas où ça ne marcherait pas.
Je crois plutôt tout simplement qu'un navigateur est incapable de faire autre chose que du HTTP et donc ne peut émettre un ping ICMP. Alors il se débrouille pour faire une espèce de ping en HTTP.
*: à l'ouverture d'une connexion TCP, il y a un premier paquet qui part de chez l'utilisateur vers le serveur, celui-ci répond avec un paquet qui déclenche l'envoi d'un second paquet de la machine de l'utilisateur. Le serveur n'a plus qu'à mesurer le temps entre l'arrivée des deux paquets pour connaître la latence du réseau.
L'ennui, c'est que tout ça se passe au niveau de la couche TCP/IP, de façon transparente pour les applications.
L'horodatage de l'URL sert probablement a éviter les DoS (Deny of Service) par répétition (bof...)
Je crois plutôt que c'est cet horodatage qui permet de calculer la latence.
Le Forgeron a écrit :
Le 30/12/2012 23:12, geo cherchetout nous fit lire :
Je viens de réaliser une capture avec wireshark lors d'un test de débit
sur le site degrouptest.com et aucun paquet du type ICMP n'y figure. En
revanche j'y vois 10 paquets HTTP contenant « GET
/ookla/speedtest/latency/.txt?x= suivi de la date au format epoch ».
Que dois-je en conclure ?
A quoi sert le ping ? (grosso modo)
1. à vérifier l'existence d'une machine
2. à connaître la route entre deux machines
Ping ne permet pas de déterminer un chemin. C'est plutôt traceroute.
3. à connaître la latence (du réseau) entre deux machines
[...]
Reste le point 3... et là il y a un gros obstacle pour M. Michu : les
NAT et autres firewalls dans le réseau des FAI. Faire de l'ICMP, c'est
prendre le risque d'une mauvaise image auprès de ses utilisateurs, dans
le cas où ça ne marcherait pas.
Je crois plutôt tout simplement qu'un navigateur est incapable de faire
autre chose que du HTTP et donc ne peut émettre un ping ICMP. Alors il
se débrouille pour faire une espèce de ping en HTTP.
*: à l'ouverture d'une connexion TCP, il y a un premier paquet qui part
de chez l'utilisateur vers le serveur, celui-ci répond avec un paquet
qui déclenche l'envoi d'un second paquet de la machine de l'utilisateur.
Le serveur n'a plus qu'à mesurer le temps entre l'arrivée des deux
paquets pour connaître la latence du réseau.
L'ennui, c'est que tout ça se passe au niveau de la couche TCP/IP, de
façon transparente pour les applications.
L'horodatage de l'URL sert probablement a éviter les DoS (Deny of
Service) par répétition (bof...)
Je crois plutôt que c'est cet horodatage qui permet de calculer la latence.
Le 30/12/2012 23:12, geo cherchetout nous fit lire :
Je viens de réaliser une capture avec wireshark lors d'un test de débit sur le site degrouptest.com et aucun paquet du type ICMP n'y figure. En revanche j'y vois 10 paquets HTTP contenant « GET /ookla/speedtest/latency/.txt?x= suivi de la date au format epoch ». Que dois-je en conclure ?
A quoi sert le ping ? (grosso modo) 1. à vérifier l'existence d'une machine 2. à connaître la route entre deux machines
Ping ne permet pas de déterminer un chemin. C'est plutôt traceroute.
3. à connaître la latence (du réseau) entre deux machines
[...]
Reste le point 3... et là il y a un gros obstacle pour M. Michu : les NAT et autres firewalls dans le réseau des FAI. Faire de l'ICMP, c'est prendre le risque d'une mauvaise image auprès de ses utilisateurs, dans le cas où ça ne marcherait pas.
Je crois plutôt tout simplement qu'un navigateur est incapable de faire autre chose que du HTTP et donc ne peut émettre un ping ICMP. Alors il se débrouille pour faire une espèce de ping en HTTP.
*: à l'ouverture d'une connexion TCP, il y a un premier paquet qui part de chez l'utilisateur vers le serveur, celui-ci répond avec un paquet qui déclenche l'envoi d'un second paquet de la machine de l'utilisateur. Le serveur n'a plus qu'à mesurer le temps entre l'arrivée des deux paquets pour connaître la latence du réseau.
L'ennui, c'est que tout ça se passe au niveau de la couche TCP/IP, de façon transparente pour les applications.
L'horodatage de l'URL sert probablement a éviter les DoS (Deny of Service) par répétition (bof...)
Je crois plutôt que c'est cet horodatage qui permet de calculer la latence.
geo cherchetout
Le 31/12/2012 10:46, *Pascal Hambourg* a écrit fort à propos :
Je crois plutôt que c'est cet horodatage qui permet de calculer la latence.
J'ai envie de le croire mais j'ai besoin d'aide pour imaginer le mécanisme de cette mesure...
Le 31/12/2012 10:46, *Pascal Hambourg* a écrit fort à propos :
Je crois plutôt que c'est cet horodatage qui permet de calculer la latence.
J'ai envie de le croire mais j'ai besoin d'aide pour imaginer le mécanisme
de cette mesure...
