Outil de Test WebSocket Online
Test de connexion WebSocket online, envoi et réception de messages outil de débogage
Qu'est-ce que WebSocket?
Le test WebSocket se connecte à une URL WebSocket et aide à vérifier si un canal temps réel peut s’ouvrir, envoyer des messages et recevoir des réponses. Les WebSockets servent aux chats, tableaux de bord en direct, notifications, fonctions multijoueur, données de marché, communication d’appareils et autres connexions bidirectionnelles persistantes. L’outil est utile en développement, diagnostic, configuration proxy, contrôle TLS et comparaison entre endpoints ws:// et wss://. Ce n’est ni un test de charge ni un analyseur complet de protocole. Authentification, sous-protocoles, heartbeats, reconnexion, format des messages, backpressure et limites serveur doivent être testés dans le client et l’environnement réels.
Comment utiliser
Comment utiliser
- Saisissez l'adresse du serveur WebSocket dans le champ URL (ws:// ou wss://)
- Facultatif : saisissez les sous-protocoles, séparés par des virgules pour en spécifier plusieurs
- Cliquez sur « Connecter » pour établir la connexion WebSocket
- Saisissez le contenu du message dans le champ de saisie
- Sélectionnez le type de message (Texte ou JSON) ; le format JSON sera validé automatiquement
- Cliquez sur « Envoyer » ou appuyez sur Ctrl + Enter pour envoyer le message
- Consultez les messages envoyés et reçus dans la liste ; cliquez pour copier
Conseils de connexion
- Utilisez wss:// lors des tests depuis une page HTTPS ; les navigateurs bloquent souvent les connexions ws:// non sécurisées depuis des origines sécurisées.
- Exportez ou copiez les journaux de messages importants avant de vous déconnecter, d'actualiser ou de changer de point de terminaison pendant le débogage.
Cas d’utilisation
Principe technique
Le cœur du protocole WebSocket repose sur le mécanisme HTTP Upgrade. Le client envoie d'abord une requête HTTP GET classique, mais avec les en-têtes Upgrade: websocket et Connection: Upgrade ainsi qu'une clé Sec-WebSocket-Key générée aléatoirement. Après validation de ces en-têtes, le serveur répond avec 101 Switching Protocols, incluant la valeur Sec-WebSocket-Accept, qui est le SHA-1 de la clé concaténée avec un GUID fixe, puis encodée en Base64. Après la réponse 101, la connexion TCP bascule d'HTTP vers WebSocket, et les données suivantes sont transmises sous forme de trames WebSocket. L'en-tête d'une trame WebSocket fait au minimum 2 octets, contenant le drapeau FIN, le code d'opération (0x1 pour le texte, 0x2 pour le binaire, 0x8 pour la fermeture, 0x9 pour le ping, 0xA pour le pong) et la longueur de la charge utile. Les trames ping/pong sont utilisées pour la détection de heartbeat ; l'API du navigateur ne les envoie pas automatiquement, c'est donc à la couche applicative de les implémenter. wss:// est l'équivalent de HTTPS+WebSocket, effectuant d'abord une poignée de main TLS puis la mise à niveau WebSocket ; ws:// est en clair, et le navigateur refusera les points de terminaison ws:// sur les pages https pour empêcher les attaques de rétrogradation. Une trame unique est limitée à environ 1 Mo par défaut ; les messages plus longs sont répartis sur plusieurs trames.
- Poignée de main : le client envoie un HTTP GET avec l'en-tête Upgrade: websocket, et le serveur renvoie 101 Switching Protocols pour signaler une mise à niveau réussie
- Sec-WebSocket-Key est une chaîne Base64 de 16 octets générée aléatoirement par le navigateur ; le serveur y concatène un GUID fixe, calcule le SHA-1 et vérifie via Sec-WebSocket-Accept
- Framing : chaque trame transporte un en-tête d'au moins 2 octets, avec FIN, opcode (texte/binaire/ping/pong/fermeture) et la longueur de la charge utile
- ws:// est en clair, wss:// est WebSocket sur HTTPS ; les navigateurs refusent ws:// sur les sites https pour empêcher les attaques de rétrogradation
- Trames ping/pong pour les heartbeats : la RFC 6455 exige un pong en réponse à chaque ping ; le navigateur n'envoie pas automatiquement les heartbeats, l'application doit les implémenter
- Séquence de fermeture : chaque côté envoie une trame de fermeture 0x8 avec un code de statut, le pair répond avec une trame de fermeture correspondante, et seulement alors la connexion TCP est réellement libérée
Exemples
Se connecter à un service Echo public
wss://echo.websocket.org — la poignée de main 101 Switching Protocols réussit, l'envoi de "hello" renvoie immédiatement "hello" en échoDéboguer votre propre service WebSocket
wss://api.example.com/ws — sous-protocole graphql-ws, la connexion réussit, les messages d'abonnement sont reçus normalementReproduire une connexion interrompue
wss://api.example.com/ws — le serveur ferme activement la connexion 30 secondes après son établissement, code de fermeture 1006 (fermeture anormale)FAQ
Que fait le testeur WebSocket ?
Il vous permet de vous connecter à n'importe quel endpoint ws:// ou wss://, d'envoyer et recevoir des messages, et d'inspecter l'échange protocolaire. Utile pour tester les API WebSocket, les brokers MQTT-over-WS, les serveurs de jeux temps réel, les systèmes de chat et les flux de cotations boursières en développement.
Les messages passent-ils par vos serveurs ?
Non. Le navigateur ouvre la connexion WebSocket directement vers l'hôte cible. Pas d'intermédiaire, pas de journalisation de notre côté. L'hôte cible voit votre IP comme n'importe quel autre client.
Pourquoi cela ne se connecte-t-il pas à mon endpoint localhost ?
Règles de contenu mixte : si cette page est servie en HTTPS, les navigateurs bloquent les connexions ws:// (non sécurisées). Utilisez wss:// pour la cible, ou exécutez cette page en HTTP simple pour les tests locaux. La console du navigateur affiche la raison exacte du rejet.
Puis-je envoyer des données binaires ?
Oui. La plupart des builds prennent en charge les trames texte et binaires. L'entrée binaire est généralement en Base64 ou hex ; la page la décode avant l'envoi. L'affichage des réponses binaires utilise hex ou Base64 par défaut.
Comment ajouter des en-têtes personnalisés ?
L'API WebSocket du navigateur n'autorise pas les en-têtes personnalisés — c'est une restriction de la plateforme web. Le seul en-tête que vous pouvez définir est Sec-WebSocket-Protocol (le sous-protocole). Pour l'authentification par jeton Bearer, utilisez un paramètre de requête ou une authentification au premier message ; certains serveurs acceptent un Cookie.
Va-t-il tester la compression et les extensions ?
Les navigateurs négocient automatiquement per-message-deflate avec les serveurs qui l'annoncent. La page affiche typiquement l'extension négociée. Les extensions personnalisées ne sont pas testées — les navigateurs n'exposent pas ce niveau de contrôle.
Pourquoi ma connexion se coupe-t-elle sans cesse ?
Causes courantes : timeout d'inactivité du serveur (souvent 30 à 120 s), timeout de proxy/load-balancer, interruption réseau, ou mise en veille de l'ordinateur. Les WebSockets modernes ont besoin de heartbeats ping/pong ; vérifiez que le serveur envoie des pings, ou faites envoyer à votre client des messages périodiques.