WebSocket
Surveillance des WebSockets
La poignée de main d'upgrade, le socket toujours ouvert un instant plus tard, et le premier message.
Essaie-le maintenant
Un test, depuis un endroit, tout de suite, et rien n'est sauvegardé. Un monitor vérifie depuis chaque emplacement où on est présent et confirme une panne depuis deux autres continents avant de réveiller quelqu'un, ce qu'un simple test ne peut pas te montrer.
À quoi ça sert
Ton chat, ton tableau de bord en direct, ton flux de prix, ton éditeur collaboratif, ton lobby de jeu : tout cela est un WebSocket, et c'est la partie d'un produit qui échoue alors que toutes les couches en dessous restent au vert. La page charge, l'API répond, le certificat est valide, le port est ouvert, et le socket ne s'ouvre jamais.
Ou il s'ouvre et se referme deux cents millisecondes plus tard, ce qui, du point de vue de l'utilisateur, est un écran qui cesse discrètement de se mettre à jour et que personne ne signale comme une panne. Ils actualisent, ça marche une minute, puis ils abandonnent. Donc cela ne s'arrête pas à la poignée de main : ça surveille le socket un moment après, de la même manière que le check TCP peut exiger un message d'accueil plutôt que de se contenter d'un port ouvert.
Et celui sur lequel les gens perdent vraiment de l'argent : le flux qui est connecté mais a cessé de publier. Donne-nous un message à envoyer et un modèle auquel la réponse doit correspondre, ou juste un modèle, et un flux silencieux est un échec plutôt qu'une ligne verte qui semble saine.
Comme chaque vérification ici, elle s'exécute depuis Amsterdam, New York, Sydney and Singapore, et un échec est confirmé depuis deux autres continents avant que quelqu'un soit réveillé. Comment ça marche.
Ce que tu peux configurer
Tout ce qui suit est dans le formulaire quand tu en ajoutes un, sur chaque forfait.
- Adresse
- Une adresse ws:// ou wss://, avec le chemin. Un hôte et un port, c'est le check TCP, ce qui est une question différente.
- Envoyer ceci en premier
- Une trame texte, envoyée dès que le socket s'ouvre, pour un point de terminaison qui répond plutôt que de publier.
- Message attendu
- Une expression régulière qu'une trame doit correspondre. La remplir rend une trame obligatoire.
- Combien de temps attendre
- En secondes. Séparé du délai d'expiration de connexion, car un flux qui publie toutes les trente secondes est sain et échouerait à un délai de type poignée de main.
- Timeout
- Combien de temps la poignée de main elle-même peut durer.
- Confirmations
- Combien d'autres continents doivent être d'accord avant de réveiller quelqu'un.
Questions
Pourquoi ne puis-je pas simplement pointer le monitor HTTPS dessus ?
Parce qu'une réponse saine serait enregistrée comme une panne. Un WebSocket commence par un HTTP GET avec Upgrade: websocket et un Sec-WebSocket-Key, et un serveur qui répond à un GET simple avec 400 ou 426 se comporte exactement comme il devrait. Un monitor HTTPS voit ce code de statut et te signale comme hors ligne alors que tout fonctionne parfaitement.
Que fait réellement le check ?
Il complète le handshake d'upgrade, ce qui signifie un 101 avec le Sec-WebSocket-Accept dérivé de la clé qu'il a envoyée, puis il garde le socket un moment pour voir s'il reste ouvert. Ensuite, il raccroche. Il ne garde pas la connexion entre les vérifications, donc rien de tout ça ne ressemble à un client pour ton serveur.
Mon flux est silencieux la plupart du temps. Cela échouera-t-il ?
Non. Un socket qui s'ouvre et ne dit rien est sain sauf si tu définis un message attendu, parce qu'un flux sans rien à publier n'est pas un flux cassé. Si tu le fais, les règles changent exprès : une trame est alors requise dans le délai que tu as défini, ce qui te permet de détecter un flux connecté mais arrêté.
Quelle est la différence entre 1000 et 1011 dans une fermeture ?
1000 est une fermeture normale et 1011 signifie que le serveur a rencontré une condition dont il ne pouvait pas se remettre, et les deux arrivent comme un socket qui s'est fermé. Le code et la raison de fermeture sont dans l'échec, plutôt que d'être réduits à déconnecté, parce qu'ils orientent celui qui répare vers deux endroits différents.
Tu prends en charge Socket.IO, SignalR, STOMP ou MQTT ?
Non, et on le dit plutôt que de laisser entendre le contraire. Ce sont des couches au-dessus de WebSocket, chacune avec son propre handshake et sa propre idée d'un namespace, et un test qui les parle à moitié serait pire qu'un test qui ne les parle pas. Le test brut te dit toujours si le transport en dessous est opérationnel.
Est-ce qu'il vérifie le certificat sur une adresse wss:// ?
Oui. Une connexion wss:// est vérifiée par rapport au store de confiance public comme n'importe quelle autre, donc un certificat expiré, auto-signé ou avec un hostname qui ne correspond pas échoue au test. Les jours restants sont une question pour un monitor de certificat, et ça vaut le coup de le faire tourner en parallèle de celui-ci.
Je peux vérifier un socket sur mon propre réseau ?
Non, et c'est le refus dont on est le moins désolé. Un WebSocket vers une adresse interne est un tunnel bidirectionnel de longue durée ouvert par notre infrastructure selon un planning, ce qui est une version pire d'une falsification de requête côté serveur qu'une requête unique. L'adresse est résolue juste avant la connexion et une adresse privée est refusée.
Mon client se reconnecte tout seul. Pourquoi surveiller aussi le socket ?
Ça devrait, et un client sans logique de retry est le plus gros problème des deux, donc ce travail n'est pas perdu. Mais ça veut dire que ton client cache exactement ce qu'il faudrait savoir. Un socket qui accepte une connexion, la garde trente secondes et la coupe fera croire à un client qui se reconnecte qu'il est presque connecté pendant des heures, alors que tous les messages envoyés dans les intervalles sont perdus. Celui-ci se connecte, complète le handshake et garde le socket, donc un serveur qui échoue de cette façon échoue au test au lieu d'être masqué par la logique de retry de l'autre côté.