C'est une tâche courante de vérifier la «qualité» du réseau - latence, nombre de paquets perdus, etc. Mais «ping» a un certain nombre d'inconvénients: - Il utilise ICMP. De nombreux FAI ont différents shapers pour le trafic ICMP et TCP, donc 'ping' affichera une latence de 10 ms, mais les connexions TCP connaîtront 1000 ms +. - Il envoie une très petite quantité de paquets. Par défaut, un paquet par seconde. Étant donné que le protocole TCP tolère la perte de paquets (il peut très bien fonctionner si des demi-paquets sont perdus - c'est normal), il n'est absolument pas clair si la "perte de 30% de paquets" de ping tue la connexion ou si c'est absolument normal.
Alors, existe-t-il une alternative au ping qui utilise une connexion TCP au lieu d'ICMP et vérifie la qualité de la connexion Internet?
la source
Réponses:
Indépendamment du fait que TCP peut tolérer des problèmes de perte / commande de paquets, une perte de ping de 30% est encore assez importante si la "population" est suffisamment grande - c'est-à-dire plus de 100 pings.
Mais pour répondre à la question, vous pouvez regarder nmap. Je suis sûr que des exemples arriveront bientôt :)
Plus important encore, vous ne voulez pas seulement un temps d'aller-retour, vous voulez vraiment voir les performances de votre machine vers le serveur et revenir à chaque saut (possible).
Vous pouvez le faire avec
traceroute- cependant la version la plus courante de cela se fait en utilisant ICMP ou UDP, mais rechercheztcp traceroute- et commencez par là.Voici quelques outils amusants à essayer pendant que vous y êtes ...
Voici un exemple avec
lft...la source
Netcat Power Tools décrit comment exécuter TCP Ping avec netcat. Plus précisément, chaque paquet ACK non sollicité doit renvoyer RST.
la source
Je suis personnellement un grand fan de mtr ( http://www.bitwizard.nl/mtr/ ), mtr est un clone traceroute basé sur ncurses qui peut fonctionner à la fois avec icmp et udp. Il vous montre les points faibles de votre lien avec un certain hôte et n'est donc pas intrusif.
En ce qui concerne vraiment certains tests de charge, j'irais avec iperf (qui est client / serveur).
la source
Pour Windows, vous pouvez utiliser quelque chose comme tcping:
http://www.elifulkerson.com/projects/tcping.php
Et pour Linux est le meilleur utilitaire, déjà mentionné,
hping.la source
Les paquets ICMP sont généralement livrés plus lentement (s'il y a une différence), car la plupart des réseaux les priorisent, en particulier les paquets ping. En général, si vous voyez des résultats aussi divergents des réponses ICMP et TCP, le problème est soit un serveur surchargé, soit une mise en forme TCP spécifique sur un pare-feu en cours de route.
Vous devez enquêter sur
traceroute -P tcp,tcptraceroute,lftet bien sûrtelnet.la source
mtrà divers emplacements sur le net et vous remarquerez assez souvent que divers réseaux ont des problèmes de livraison de paquets ICMP à différents points.Vous pouvez utiliser une application QoS pour mesurer ce type de paramètres réseau. Par exemple:
NetPerf (www.netperf.org/netperf/): Netperf est une référence qui peut être utilisée pour mesurer les performances de nombreux types de réseaux différents. Il fournit des tests pour le débit unidirecitonal et la latence de bout en bout. Les environnements actuellement mesurables par netperf comprennent:
OU
IPerf (sourceforge.net/projects/iperf) Iperf a été développé par NLANR / DAST comme une alternative moderne pour mesurer les performances maximales de la bande passante TCP et UDP. Iperf permet le réglage de divers paramètres et caractéristiques UDP. Iperf signale la bande passante, la gigue de retard, la perte de datagramme.
la source
consultez hping puis jetez un oeil à bing
la source
TCP ne peut pas "tolérer" la perte de paquets de 50%. Il s'arrêtera tout simplement, pour une raison simple: il adapte sa vitesse de transmission en fonction de la perte de paquets. Lorsque des paquets sont perdus, ils sont censés indiquer une congestion. Si vous supprimez 50% des paquets (par exemple, avec une règle de pare-feu à suppression aléatoire ) quel que soit le trafic, la disponibilité de la bande passante diminuera.
De plus, je doute que les FAI façonnent ICMP vs TCP. Certains pourraient le faire, car il y a des gens vraiment stupides, mais cela n'a pas beaucoup de sens de le faire. La plupart façonneront l'ensemble de la connexion ou se "façonneront" à cause de la congestion. Dans les deux cas, les paquets sont généralement supprimés de manière aléatoire.
Cela étant dit, vous pouvez faire un ping avec TCP, mais il y a plusieurs mises en garde. La première consiste à simplement envoyer le paquet initial dans une connexion TCP, ce qui provoquera une réponse d'un serveur avec un port ouvert, mais sera considéré comme une tentative de connexion. Idéalement, vous pouvez utiliser le service "echo" (port TCP 7) ... mais en fait vous ne pouvez pas car il est désormais désactivé par défaut partout. Quoi qu'il en soit, si vous pouvez demander à quelqu'un de l'activer pour vous sur la machine que vous souhaitez tester, un programme pourrait l'utiliser pour vérifier le temps rond pour les paquets à l'intérieur d'une connexion TCP.
Cela étant dit, vous avez probablement installé la commande "tracepath" sur votre machine; il est similaire à traceroute mais n'utilise ni TCP ni ICMP, mais UDP. Pour TCP, il existe différents utilitaires, vous pouvez essayer hping .
la source
L'alternative au ping, vous pouvez utiliser 'netstat'
Options: 1.netstat -antp 2.netstat -anup
-a = tout, -n = adresse et numéro de port de l'extrémité locale du socket, -t = tcp, -p = programme
-u = udp.
la source