Testeur WebSocket

Connectez-vous à tout endpoint ws:// ou wss://, envoyez/recevez des messages en direct, voyez l'historique complet avec horodatage. Pour déboguer chat, subs GraphQL, MQTT-sur-WS.

Vous avez des commentaires ? Signalez des bugs, suggérez des fonctionnalités ou partagez vos idées — nous lisons tout

Testeur WebSocket - Vérifier vos connexions temps réel

WebSocket est le protocole qui a finalement donné aux navigateurs une communication bidirectionnelle en temps réel, standardisé en 2011 sous RFC 6455 et désormais omniprésent : chaque app de chat moderne, widget sportif en direct, éditeur collaboratif (Figma, Google Docs), flux de cotations trading, abonnement GraphQL, lobby de jeu multijoueur, et la plupart des systèmes de notifications temps réel tournent dessus. Contrairement au cycle requête-réponse HTTP, une connexion WebSocket reste ouverte après le handshake initial, permet à l'une ou l'autre partie d'envoyer une trame à tout moment, et survit aux proxies et pare-feu d'entreprise car elle commence comme une requête HTTP Upgrade normale avant de changer de protocole. Déboguer des apps WebSocket est plus difficile que déboguer HTTP — l'onglet réseau du DevTools montre le handshake mais visualise mal le flux de messages dans le temps. Ce testeur comble cette lacune. Tapez n'importe quelle URL ws:// ou wss://, cliquez sur Connecter, et vous avez un canal direct persistant : envoyez des messages texte ou JSON arbitraires avec le bouton Envoyer, voyez chaque trame envoyée par le serveur apparaître en temps réel avec un horodatage précis, et identifiez la direction du message (envoyé/reçu/événements système comme open/close/error) par couleur dans le journal. Utile pour bidouiller echo.websocket.org pendant un tutoriel, valider que la boucle de broadcast de votre backend atteint réellement les clients connectés, reproduire des conditions de course, ou observer le trafic heartbeat d'un service avec lequel vous intégrez.

Qu'est-ce qu'un WebSocket ?

WebSocket est un protocole permettant une communication bidirectionnelle permanente sur une seule connexion TCP. Contrairement à HTTP (requête/réponse), WebSocket offre :

- Communication temps réel dans les deux sens
- Connexion persistante entre client et serveur
- Latence réduite par rapport au polling
- Transmission continue idéale pour les apps interactives

Cas d'usage :
- Messageries et chats
- Flux et notifications live
- Jeux multijoueurs temps réel
- Co-édition
- Scores sportifs instantanés
- Cotations boursières

Les URL WebSocket commencent par ws:// (non chiffré) ou wss:// (sécurisé).

Comment tester un WebSocket ?

Étapes :

1. Entrez l'URL du serveur (ws:// ou wss://)
2. Cliquez sur "Se connecter" pour établir la connexion
3. Attendez l'état "Connecté"
4. Rédigez votre message
5. Appuyez sur "Envoyer" pour le transmettre
6. Suivez les réponses dans l'historique
7. Cliquez sur "Se déconnecter" lorsque vous avez terminé

Serveurs de test populaires :
- ws://echo.websocket.org (revoie vos messages)
- wss://echo.websocket.org (version sécurisée)

Chaque message est enregistré avec un horodatage et une étiquette (envoyé, reçu ou système).

Différence entre ws:// et wss:// ?

C'est l'équivalent de http:// versus https:// :

ws:// (WebSocket) :
- Connexion non chiffrée
- Port 80 par défaut
- Données en clair
- Idéal en développement local

wss:// (WebSocket Secure) :
- Connexion chiffrée via TLS/SSL
- Port 443 par défaut
- Données protégées
- Obligatoire pour les sites en HTTPS
- Recommandé en production

Les navigateurs modernes exigent wss:// si la page est servie en HTTPS.

Pourquoi certaines connexions échouent-elles ?

Plusieurs raisons possibles :

1. CORS/Sécurité : le serveur bloque les connexions navigateur
2. Authentification : en-têtes ou tokens manquants
3. SSL/TLS : contenu mixte (ws:// depuis une page HTTPS)
4. Serveur hors ligne
5. Pare-feu bloquant le port WebSocket
6. URL ou port incorrect

Conseils :
- Vérifiez le format de l'URL
- Utilisez wss:// depuis une page HTTPS
- Assurez-vous que le serveur tourne
- Vérifiez la configuration CORS
- Testez avec echo.websocket.org
- Lisez la console du navigateur pour les détails

Testeur WebSocket — Connectez-vous à tout endpoint ws:// ou wss://, envoyez/recevez des messages en direct, voyez l'historique complet avec — **Testeur WebSocket**

Quels types de données envoyer ?

Cet outil envoie des messages texte. WebSocket peut transmettre :

Texte :
- Texte brut
- Chaînes JSON
- XML
- Toute chaîne encodée

Binaire :
- ArrayBuffer
- Blob
- Fichiers (non gérés ici)

Formats courants :
- JSON : {"type": "message", "text": "Hello"}
- Texte : "Hello, World!"
- Commandes : "/join salon123"

La plupart des API WebSocket attendent du JSON structuré.

En quoi WebSocket diffère-t-il de Server-Sent Events (SSE) et long-polling ?

Les trois livrent des pushes serveur vers un navigateur sans polling, mais avec des compromis différents. (1) WebSocket : full duplex (les deux côtés parlent à tout moment), faible surcharge par message (en-tête de trame 2-14 octets), payloads arbitraires texte ou binaire, protocole d'application personnalisé. Mieux pour chat, jeux multijoueurs, édition collaborative — tout ce qui est vraiment interactif. (2) Server-Sent Events : unidirectionnel uniquement (serveur → client), API plus simple (EventSource dans les navigateurs), reconnexion automatique, texte UTF-8 uniquement. Mieux pour les flux en direct où le client ne reparle jamais : prix boursiers, tickers d'actualités, streaming de logs serveur. SSE passe par HTTP/2 brut donc est plus convivial avec les proxies intermédiaires. (3) Long-polling : le client fait une requête HTTP que le serveur maintient ouverte jusqu'à l'arrivée de données, puis rouvre immédiatement. Latence et surcharge les plus élevées mais fonctionne partout car c'est du HTTP brut. Les apps modernes optent par défaut pour WebSocket ; retombent sur SSE pour les flux unidirectionnels ; long-polling ne compte que pour les environnements legacy sans support de proxy approprié.

Quelle est la taille de message maximale et le débit que je peux pousser à travers un WebSocket ?

Le protocole lui-même permet des trames jusqu'à 2^63 octets — effectivement illimité. Les vraies limites viennent de votre stack runtime. Les navigateurs plafonnent les messages individuels à environ 64 Mo avant d'avertir ou de déconnecter ; le point idéal pratique pour les messages au niveau application est sous 1 Mo pour éviter d'étouffer les event loops JavaScript single-thread. La bibliothèque 'ws' de Node.js par défaut 100 Mo maximum mais c'est configurable. Pour le débit, le matériel moderne soutient 100 000+ petits messages par seconde par connexion WebSocket sur localhost, descendant à des milliers/sec sur l'internet public selon le RTT. Si vous avez besoin de plus de débit, regroupez les petites mises à jour en messages périodiques plus gros (ex. cadence 16ms pour clients 60fps), utilisez du framing binaire (ArrayBuffer) au lieu de JSON pour sauter le parsing de chaîne, et envisagez WebTransport (le successeur basé sur HTTP/3 conçu pour les flux unreliable à faible latence) pour le trafic style jeu. Évitez d'envoyer des blobs massifs encodés en base64 sur WebSocket ; utilisez un upload HTTP séparé et signalez l'achèvement via le socket.

Mes données sont-elles protégées ?

Consignes de sécurité :

- Les connexions vont directement de votre navigateur au serveur
- Nous ne relayons, ne stockons ni n'analysons vos messages
- Utilisez wss:// pour chiffrer les échanges
- Évitez d'envoyer des données sensibles vers des serveurs non fiables
- Les serveurs de test publics peuvent consigner vos messages

Bonnes pratiques :
- Préférez wss:// en production
- N'envoyez pas de mots de passe ou secrets
- Vérifiez l'identité du serveur
- Utilisez des comptes ou tokens dédiés au test