Différence entre ping avec et sans http: //
J'essaye de cingler mon site Web http://www.example.com/ et il se résout en une adresse IP inconnue et expire.
PING http://www.example.com/ (198.105.254.228): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
mais quand je ping example.com cela fonctionne
Qu'est-ce que je manque ici?
J'essaye de cingler mon site Web http://www.example.com/ et il se résout en une adresse IP inconnue et expire.
PING http://www.example.com/ (198.105.254.228): 56 data bytes
Request timeout for icmp_seq 0
L'argument de ping est un nom d'hôte (ou une adresse IP).
Donc, tout ce qui suit fonctionnera:
ping example.com
ping www.example.com
ping 127.0.0.1
D'autre part,
ping http://www.example.com/
ne fonctionnera pas car http://www.example.com/ est un HTTP Uniform Resource Locator (URL) n'est pas un nom d'hôte valide (même s'il en fait partie).
Une URL HTTP est composée de 4 parties:
- Scheme - toujours présent
- Nom d'hôte - toujours présent
- Path ou Stem - toujours présent mais parfois nul
- Paramètres - optionnel
Normalement, Ping ne reconnaîtra pas les URL en tant que nom d’hôte de destination valide.
Notes :
Toutes les URL n'ont pas le format mentionné ci-dessus.
Une URL complète consiste en un spécificateur de schéma de nommage suivi d'une chaîne dont le format est fonction du schéma de nommage.
Le format d'une URL est défini dans la spécification IETF Localisateurs de ressources uniformes (URL)
piratage DNS
Une exception à ce qui précède peut se produire si le serveur DNS (qui résout les noms d'hôte en adresses IP) est configuré pour renvoyer une adresse IP valide même si un nom d'hôte non valide est fourni.
Cela peut arriver si un fournisseur de services Internet pirate vos requêtes DNS.
D'après la réponse Pourquoi le ping est-il résolu en IP 198.105.254.228 pour tout nom d'hôte aléatoire que je tape? par Michael Hampton :
Ils essaient d'être "utiles" en redirigeant les demandes de domaines inexistants vers un service en marque blanche fournissant des résultats de recherche et des publicités, desquels tout le monde, sauf vous, obtient une réduction du revenu.
Heureusement, ils ont une page de préférences sur laquelle vous pouvez supposément la désactiver.
Lorsque vous exécutez la commande ping avec une chaîne qui n'est pas une adresse IP, elle doit d'abord résoudre l'adresse IP de l'hôte que vous essayez d'envoyer.
Quand tu cours:
$ ping example.com
Le serveur DNS renvoie l'adresse IP du serveur qui héberge le site Web.
Toutefois, lorsque vous préfixez le protocole et le chemin d'accès, vous créez une URL http standard qui est entièrement envoyée au serveur DNS pour être résolue.
Ainsi, au lieu que le serveur DNS trouve l'enregistrement pour example.com, il recherche l'enregistrement http://example.com/ qui n'est pas un nom d'hôte valide.
Beaucoup de serveurs DNS reviendront sans rien. Dans ce cas, la commande ping générera une erreur de résolution DNS.
Cependant, votre serveur DNS renvoie l'adresse IP 123.456.789.000. L’adresse semble être un service de suggestion de Time Warner Cable pour aider les utilisateurs qui ont mal entré l’URL dans leur navigateur.
Mais la commande ping prend cela à la lettre et pense que le nom d’hôte http://example.com/ (qui n’est pas un nom d’hôte valide) est résolu en adresse 123.456.789.000.
La raison pour laquelle la commande ping expire après cela est que 123.456.789.000 ne répond pas aux demandes ICMP.
Le http: // signifie Hyper Text Transfer Protocol, le protocole utilisé pour accéder aux pages Web. La commande ping d'un serveur n'utilise pas HTTP, mais consiste en un message ICMP (protocole de message de contrôle Internet). Par conséquent, http: // n'a pas de sens dans ce contexte.
Pourquoi voudriez-vous utiliser 'ping' de toute façon? Cela ne fonctionnera pas s'il existe un pare-feu bloquant le trafic "ping".
À mon avis, si vous allez tester un serveur Web, il est préférable d'utiliser "telnet", vous pouvez alors tester l'hôte et le port sur lequel il doit écouter.
exemple: pour tester votre serveur Web telnet www.mywebserver.com 80 à l'écran vide, saisissez 'get' puis 'enter' et vous devriez obtenir une pile de réponses http renvoyées par le serveur Web. ( par exemple: HTTP/1.1 400 Requête incorrecte ... )
Cela me dit que non seulement le serveur est "actif", mais qu'il écoute et répond également sur le port 80. (J'attendrais également d'un pare-feu que le port 80 laisse passer le port 80 sur mon serveur Web)
De même, "telnet" fonctionne également pour tester les serveurs de messagerie, ftp et à peu près tout le reste.