Tests de connectivité avancés avec cURL
Maintenant que vous comprenez les tests de connectivité de base, explorons les fonctionnalités plus avancées de cURL qui peuvent aider au dépannage et aux tests détaillés.
Utilisation du mode verbose pour un débogage détaillé
Le mode verbose (option -v) est inestimable pour le dépannage des problèmes de connectivité car il affiche l'ensemble du processus de requête et de réponse :
curl -v https://example.com
La sortie sera complète, montrant la résolution DNS, la poignée de main TLS, les en-têtes de requête, les en-têtes de réponse, et plus encore :
* Trying 93.184.216.34:443...
* Connected to example.com (93.184.216.34) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server accepted h2
* Server certificate:
* subject: C=US; ST=California; L=Los Angeles; O=Internet Corporation for Assigned Names and Numbers; CN=www.example.org
* start date: Nov 24 00:00:00 2022 GMT
* expire date: Nov 24 23:59:59 2023 GMT
* subjectAltName: host "example.com" matched cert's "example.com"
* issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS RSA SHA256 2020 CA1
* SSL certificate verify ok.
* using HTTP/2
* h2 [:method: GET]
* h2 [:path: /]
* h2 [:scheme: https]
* h2 [:authority: example.com]
* h2 [user-agent: curl/7.81.0]
* h2 [accept: */*]
* Using Stream ID: 1
> GET / HTTP/2
> Host: example.com
> user-agent: curl/7.81.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200
< age: 587269
< cache-control: max-age=604800
< content-type: text/html; charset=UTF-8
< date: Tue, 28 Mar 2023 12:40:01 GMT
< etag: "3147526947+ident"
< expires: Tue, 04 Apr 2023 12:40:01 GMT
< last-modified: Thu, 17 Oct 2019 07:18:26 GMT
< server: ECS (nyb/1D2B)
< vary: Accept-Encoding
< x-cache: HIT
< content-length: 1256
<
<!doctype html>
<html>
<head>
<title>Example Domain</title>
<!-- More HTML content -->
</head>
<body>
<div>
<h1>Example Domain</h1>
<p>This domain is for use in illustrative examples in documents...</p>
<!-- More content -->
</div>
</body>
</html>
* Connection #0 to host example.com left intact
Cette sortie détaillée vous aide à identifier exactement où une connexion pourrait échouer.
Test de différentes méthodes HTTP
Testons une requête POST vers un point de terminaison API de test :
curl -X POST -d "name=test&email=test@example.com" https://httpbin.org/post
Cette commande :
-X POST : Spécifie une requête POST-d "name=test&email=test@example.com" : Envoie des données de formulaire dans la requête
Vous devriez recevoir une réponse JSON montrant vos données soumises :
{
"args": {},
"data": "",
"files": {},
"form": {
"email": "test@example.com",
"name": "test"
},
"headers": {
"Accept": "*/*",
"Content-Length": "32",
"Content-Type": "application/x-www-form-urlencoded",
"Host": "httpbin.org",
"User-Agent": "curl/7.81.0",
"X-Amzn-Trace-Id": "Root=1-642295b1-0d2340ef34f2e8ea6270241a"
},
"json": null,
"origin": "198.51.100.42",
"url": "https://httpbin.org/post"
}
Test avec des en-têtes personnalisés
De nombreuses API nécessitent des en-têtes spécifiques pour l'authentification ou pour spécifier le type de contenu. Testons cela :
curl -H "User-Agent: MyCustomAgent" -H "Authorization: Bearer test-token" https://httpbin.org/headers
Cette commande :
-H "User-Agent: MyCustomAgent" : Définit un en-tête User-Agent personnalisé-H "Authorization: Bearer test-token" : Définit un en-tête Authorization
La réponse affichera les en-têtes envoyés dans votre requête :
{
"headers": {
"Accept": "*/*",
"Authorization": "Bearer test-token",
"Host": "httpbin.org",
"User-Agent": "MyCustomAgent",
"X-Amzn-Trace-Id": "Root=1-642295c3-73cac0a73b34b1c93a8ce520"
}
}
Test des temps de réponse pour différents points de terminaison
Créons un script pour comparer les temps de réponse de différents serveurs :
nano response_time.sh
Ajoutez le contenu suivant :
#!/bin/bash
echo "Testing response times..."
for site in google.com bing.com baidu.com duckduckgo.com yahoo.com; do
echo -n "$site: "
curl -s -o /dev/null -w "%{time_total}s" "https://$site"
echo ""
done
echo "Testing complete!"
Enregistrez le fichier et rendez-le exécutable :
chmod +x response_time.sh
Exécutez le script :
./response_time.sh
La sortie affichera le temps de réponse pour chaque site :
Testing response times...
google.com: 0.187s
bing.com: 0.232s
baidu.com: 0.412s
duckduckgo.com: 0.298s
yahoo.com: 0.342s
Testing complete!
Ceci est utile pour comparer les performances de différents serveurs ou pour surveiller les performances d'un serveur au fil du temps.
Test de la connectivité TCP à des ports spécifiques
Parfois, vous devez tester si un port spécifique est ouvert sur un serveur. cURL peut également être utilisé pour cela :
curl -v telnet://example.com:80
Si le port est ouvert, vous verrez un message de connexion réussie :
* Trying 93.184.216.34:80...
* Connected to example.com (93.184.216.34) port 80 (#0)
Appuyez sur Ctrl+C pour terminer la connexion.
De même, vous pouvez tester les connexions sécurisées :
curl -v https://example.com:443
La sortie verbose montrera si la connexion a réussi ou s'il y a eu des problèmes.
