Vérificateur de Port TCP (Ping)
Vérifiez si un port TCP d'un hôte public est ouvert et mesurez la latence de la connexion.
Chargement de Vérificateur de Port TCP (Ping)… Si rien ne se passe, activez JavaScript.
Le ping est l'un des outils de diagnostic réseau les plus fondamentaux, utilisé pour déterminer si un hôte distant est joignable et pour mesurer le temps d'aller-retour d'une connexion réseau. La commande 'ping' classique utilise les messages de demande d'écho (Echo Request) et de réponse d'écho (Echo Reply) d'ICMP (Internet Control Message Protocol), qui circulent au niveau de la couche IP, sous TCP et UDP. Les ingénieurs réseau s'appuient sur lui quotidiennement pour confirmer que routeurs, serveurs et équipements sont en ligne, pour mesurer des références de latence et pour détecter la perte de paquets indiquant une liaison congestionnée ou peu fiable. Le temps d'aller-retour (RTT) rapporté par le ping est l'une des mesures clés de toute analyse de performance réseau.
Questions fréquentes
Quelles données cet outil envoie-t-il à vos serveurs ?
Pourquoi cet outil utilise-t-il TCP au lieu d'ICMP comme un vrai ping ?
La vérification expire alors que le serveur est en service, qu'est-ce que cela signifie ?
Que signifient les différents statuts de résultat ?
Y a-t-il des limites de fréquence sur le nombre de vérifications que je peux exécuter ?
Comment cela se compare-t-il à l'exécution de 'ping' ou 'nc' dans un terminal ?
Puis-je vérifier des adresses IP privées ou internes ?
Cet outil enregistre-t-il les hôtes que je vérifie à des fins d'analyse ou de publicité ?
Quels numéros de port sont couramment associés aux services standard ?
De nombreux pare-feu bloquent l'ICMP, cela signifie-t-il que le ping est inutile ?
À propos de Vérificateur de Port TCP (Ping)
Les administrateurs système utilisent le ping pour vérifier rapidement qu'un serveur est de nouveau en ligne après un redémarrage, ou pour confirmer qu'une modification d'une règle de pare-feu n'a pas bloqué par inadvertance la connectivité. Les développeurs testent l'accessibilité et la latence des serveurs d'API. Les clients d'hébergement web vérifient si l'IP de leur serveur répond après une panne signalée. Les équipes de sécurité utilisent des vérifications d'accessibilité au niveau du port pour confirmer que les règles du pare-feu appliquent les bonnes politiques d'autorisation et de refus, en confirmant par exemple que le port 22 (SSH) est fermé à Internet tandis que le port 443 (HTTPS) est ouvert. Même les joueurs utilisent les mesures de latence pour choisir la région de serveur de jeu offrant la latence la plus faible.
Comme le ping ICMP standard nécessite des privilèges système élevés qui ne sont pas disponibles dans les environnements d'hébergement mutualisé, cet outil effectue une connexion via la poignée de main en trois temps de TCP vers le port que vous indiquez, plutôt que d'envoyer des paquets ICMP. Le résultat vous donne la même information essentielle, l'hôte accepte-t-il les connexions ?, tout en étant plus utile sur le plan opérationnel pour des vérifications propres à un service : vous pouvez tester le port 80 pour HTTP, le port 443 pour HTTPS, le port 25 pour SMTP, le port 22 pour SSH, et ainsi de suite. Le nom d'hôte est résolu côté serveur à l'aide du DNS public, et les plages d'IP privées (RFC 1918), la boucle locale (loopback) et les points de terminaison de métadonnées dans le cloud sont bloqués afin d'éviter les abus. La latence est mesurée comme le temps écoulé entre le SYN de TCP et l'achèvement de la poignée de main.
Pour interpréter les résultats, une connexion réussie avec une faible latence (moins de 50 ms pour des serveurs proches) indique que le port est ouvert et que le service répond. Une erreur de 'connexion refusée' signifie que l'hôte est joignable mais que rien n'écoute sur ce port, ce qui diffère d'un délai d'attente dépassé (timeout) ; un timeout signifie généralement qu'un pare-feu rejette les paquets en silence plutôt que de refuser activement la connexion. Si vous diagnostiquez une panne de service, testez à la fois le port attendu et le port 443/80 pour distinguer une défaillance du service d'un blocage au niveau du réseau. Une latence constamment élevée (au-dessus de 200 ms) mérite d'être examinée avec traceroute pour rechercher des anomalies de routage.
Du « sonar de sous-marin » au débogage réseau en 40 ans
La commande ping a été écrite par Mike Muuss en décembre 1983 comme outil de débogage pour étudier un comportement étrange sur un réseau qu'il administrait. Il l'a nommée d'après le son que produit le sonar d'un sous-marin lorsqu'il renvoie une impulsion sonore sur un objet ; l'analogie étant qu'un ping réseau envoie un signal et écoute un écho pour déterminer si quelque chose se trouve « là-bas ». Muuss a écrit l'implémentation originale en une seule soirée, et le programme s'est révélé si utile qu'il s'est rapidement répandu sur l'ARPANET pour finalement devenir un utilitaire standard sur tous les systèmes d'exploitation. Muuss est décédé dans un accident de voiture en 2000, sans avoir jamais déposé de marque ni commercialisé l'outil qui porte sa métaphore sonore.
L'ICMP, le protocole qu'utilise le ping traditionnel, a été défini dans le RFC 792 par Jon Postel en septembre 1981. Il fonctionne au niveau de la couche IP plutôt que de la couche transport (TCP/UDP), ce qui en fait le mécanisme de signalisation et de signalement d'erreurs intégré d'Internet. L'ICMP sert à plus que le ping : il transporte aussi les messages de TTL-dépassé de traceroute, les signaux de découverte du MTU de chemin et les réponses de « destination injoignable » qui informent les applications que leurs connexions ont échoué. Le champ TTL (Time to Live) des paquets IP a été spécialement conçu pour empêcher que des boucles de routage ne fassent circuler les paquets indéfiniment ; chaque routeur le décrémente de un, et l'ICMP le signale lorsqu'il atteint zéro.
Le passage du ping ICMP aux vérifications d'accessibilité basées sur TCP reflète une évolution plus large de la philosophie des réseaux au fil des décennies. La conception initiale d'Internet supposait des participants de confiance et coopératifs et rendait l'infrastructure réseau aussi transparente que possible. Les réseaux modernes traitent les sondes externes comme des vecteurs d'attaque potentiels, ce qui conduit à des pare-feu qui bloquent l'ICMP par défaut et à des groupes de sécurité qui n'autorisent le trafic que sur des ports d'application spécifiques. C'est pourquoi les équipes d'exploitation mesurent de plus en plus l'accessibilité au niveau applicatif, puis-je effectuer une poignée de main HTTPS ?, plutôt que l'accessibilité réseau brute, car un serveur qui répond aux requêtes des applications est fonctionnellement actif même s'il rejette en silence toutes les sondes ICMP.