WebSocket
Monitoraggio WebSocket
L'handshake di upgrade, il socket ancora aperto un momento dopo, e il primo messaggio.
Provalo ora
Un controllo, da un solo posto, subito, e nulla viene salvato. Un monitor controlla da ogni posizione in cui operiamo e conferma un errore da altri due continenti prima che qualcuno venga svegliato, cosa che un singolo controllo non può mostrarti.
A cosa serve
La tua chat, la tua dashboard live, il tuo feed di prezzi, il tuo editor collaborativo, la tua lobby di gioco: tutto questo è un WebSocket, ed è la parte di un prodotto che fallisce mentre ogni livello sottostante rimane verde. La pagina si carica, l'API risponde, il certificato è valido, la porta è aperta, e il socket non si apre mai.
Oppure si apre e si chiude di nuovo duecento millisecondi dopo, che dal lato dell'utente è uno schermo che smette silenziosamente di aggiornarsi e che nessuno segnala come un'interruzione. Ricaricano, funziona per un minuto, si arrendono. Quindi questo non si ferma all'handshake: osserva il socket per un momento dopo, nello stesso modo in cui il controllo TCP può insistere su un saluto piuttosto che accontentarsi di una porta aperta.
E quello su cui le persone perdono davvero soldi: il feed che è connesso e ha smesso di pubblicare. Dacci un messaggio da inviare e un pattern che la risposta deve corrispondere, o solo un pattern, e un feed silenzioso è un fallimento piuttosto che una riga verde che sembra sana.
Come ogni controllo qui, viene eseguito da Amsterdam, New York, Sydney and Singapore, e un errore viene confermato da altri due continenti prima che qualcuno venga svegliato. Come funziona.
Cosa puoi impostare
Tutto ciò che segue è nel modulo quando ne aggiungi uno, su ogni piano.
- Indirizzo
- Un indirizzo ws:// o wss://, con il percorso. Un host e una porta sono il controllo TCP, che è una domanda diversa.
- Invia questo per primo
- Un frame di testo, inviato non appena il socket si apre, per un endpoint che risponde piuttosto che pubblicare.
- Messaggio atteso
- Un'espressione regolare che un frame deve corrispondere. Compilarla è ciò che rende un frame necessario.
- Quanto tempo aspettare
- Secondi. Separato dal timeout di connessione, perché un feed che pubblica ogni trenta secondi è sano e fallirebbe una scadenza a forma di handshake.
- Timeout
- Quanto tempo può durare l'handshake stesso.
- Conferme
- Quanti altri continenti devono essere d'accordo prima che qualcuno venga svegliato.
Domande
Perché non posso semplicemente puntare il monitor HTTPS su di esso?
Perché una risposta valida verrebbe registrata come un outage. Un WebSocket inizia come un HTTP GET con Upgrade: websocket e un Sec-WebSocket-Key, e un server che risponde a un GET normale con 400 o 426 si comporta esattamente come dovrebbe. Un monitor HTTPS vede quel codice di stato e ti segnala offline mentre tutto funziona perfettamente.
Cosa fa effettivamente il controllo?
Completa l'handshake di upgrade, cioè un 101 con il Sec-WebSocket-Accept derivato dalla chiave inviata, e poi mantiene il socket per un momento per vedere se rimane aperto. Poi chiude. Non mantiene una connessione tra i controlli, quindi nulla di questo somiglia a un client per il tuo server.
Il mio feed è silenzioso per la maggior parte del tempo. Fallirà?
No. Un socket che si apre e non dice nulla è considerato valido a meno che tu non inserisca un messaggio atteso, perché un feed senza nulla da pubblicare non è un feed rotto. Inseriscilo e le regole cambiano di proposito: un frame è quindi richiesto entro il tempo di attesa impostato, ed è così che intercetti un feed connesso ma fermo.
Qual è la differenza tra 1000 e 1011 in una chiusura?
1000 è una chiusura normale e 1011 indica che il server ha incontrato una condizione da cui non può riprendersi, e in entrambi i casi il socket si chiude. Il codice di chiusura e la motivazione sono nel fallimento, invece di essere appiattiti in 'disconnected', perché indirizzano chi deve risolvere il problema in due direzioni diverse.
Supporti Socket.IO, SignalR, STOMP o MQTT?
No, e lo diciamo chiaramente invece di lasciare intendere il contrario. Questi sono layer sopra WebSocket, ognuno con il proprio handshake e la propria idea di namespace, e un controllo che li parlasse a metà sarebbe peggiore di uno che non lo fa. Il controllo base ti dice comunque se il trasporto sottostante è attivo.
Controlla il certificato su un indirizzo wss://?
Sì. Una connessione wss:// viene verificata rispetto al trust store pubblico come qualsiasi altra, quindi un certificato scaduto, auto-firmato o con un hostname non corrispondente fallisce il controllo. I giorni rimanenti sono una questione per un monitor di certificati, ed è utile eseguirlo insieme a questo.
Posso controllare un socket sulla mia rete?
No, e questa è l'unica negazione di cui ci dispiace meno. Un WebSocket verso un indirizzo interno è un tunnel bidirezionale di lunga durata aperto dalla nostra infrastruttura a intervalli regolari, che è una versione peggiore di una server-side request forgery rispetto a un fetch singolo. L'indirizzo viene risolto immediatamente prima della connessione e uno privato viene rifiutato.
Il mio client si riconnette da solo. Perché controllare anche il socket?
Dovrebbe, e un client senza logica di retry è il problema più grande tra i due, quindi quel lavoro non è sprecato. Significa però che il tuo client nasconde esattamente ciò che vale la pena sapere. Un socket che accetta una connessione, la mantiene per trenta secondi e poi la chiude farà sembrare un client che si riconnette quasi connesso per ore, mentre ogni messaggio inviato nei vuoti va perso. Questo si connette, completa l'handshake e mantiene il socket, quindi un server che fallisce in questo modo fallisce il controllo invece di essere mascherato dalla logica di retry dall'altra parte.