WebSocket
WebSocket-monitoring
De upgrade-handshake, de socket die een moment later nog open is, en het eerste bericht.
Probeer het nu
Eén check, vanaf één plek, direct, en niets wordt opgeslagen. Een monitor checkt vanaf elke locatie waar we draaien en bevestigt een fout vanaf twee andere continenten voordat iemand wordt gewekt, wat één blik je niet kan laten zien.
Waar het voor is
Je chat, je live dashboard, je prijsfeed, je collaboratieve editor, je game-lobby: alles is een WebSocket, en het is het deel van een product dat faalt terwijl elke laag eronder groen blijft. De pagina laadt, de API antwoordt, het certificaat is goed, de poort is open, en de socket opent nooit.
Of hij opent en sluit weer na tweehonderd milliseconden, wat vanuit het perspectief van een gebruiker een scherm is dat stilletjes stopt met updaten en dat niemand meldt als een storing. Ze verversen, het werkt een minuut, ze geven op. Dus dit stopt niet bij de handshake: het houdt de socket een moment daarna in de gaten, op dezelfde manier waarop de TCP-check kan aandringen op een begroeting in plaats van tevreden te zijn met een open poort.
En degene waar mensen echt geld op verliezen: de feed die verbonden is en gestopt is met publiceren. Geef ons een bericht om te sturen en een patroon waar het antwoord aan moet voldoen, of alleen een patroon, en een stille feed is een fout in plaats van een gezond ogende groene rij.
Zoals elke check hier draait het vanaf Amsterdam, New York, Sydney and Singapore, en een fout wordt bevestigd vanaf twee andere continenten voordat iemand wordt gewekt. Hoe dat werkt.
Wat je kunt instellen
Alles hieronder staat op het formulier wanneer je er een toevoegt, bij elk abonnement.
- Adres
- Een ws://- of wss://-adres, met het pad. Een host en poort is de TCP-check, wat een andere vraag is.
- Stuur dit eerst
- Eén tekstframe, verstuurd zodra de socket opent, voor een endpoint dat antwoordt in plaats van publiceert.
- Verwachte bericht
- Een reguliere expressie waar een frame aan moet voldoen. Het invullen hiervan maakt een frame überhaupt verplicht.
- Hoe lang erop te wachten
- Seconden. Los van de verbindingstimeout, omdat een feed die elke dertig seconden publiceert gezond is en zou falen bij een deadline in de vorm van een handshake.
- Timeout
- Hoe lang de handshake zelf mag duren.
- Bevestigingen
- Hoeveel andere continenten het eens moeten zijn voordat iemand wordt gewekt.
Vragen
Waarom kan ik de HTTPS-monitor er niet gewoon op richten?
Omdat het gezonde antwoord zou worden geregistreerd als een storing. Een WebSocket begint als een HTTP GET met Upgrade: websocket en een Sec-WebSocket-Key, en een server die antwoordt op een gewone GET met 400 of 426 gedraagt zich precies zoals het hoort. Een HTTPS-monitor ziet die statuscode en meldt je als down terwijl je perfect werkt.
Wat doet de check eigenlijk?
Het voltooit de upgrade-handshake, wat betekent een 101 met de Sec-WebSocket-Accept afgeleid van de sleutel die het stuurde, en houdt vervolgens de socket even open om te zien of deze open blijft. Daarna verbreekt het de verbinding. Het houdt geen verbinding tussen checks, dus niets hiervan lijkt op een client voor je server.
Mijn feed is meestal stil. Zal dat falen?
Nee. Een socket die opent en niets zegt is gezond, tenzij je een verwacht bericht invult, omdat een feed zonder iets te publiceren geen kapotte feed is. Vul dat in en de regels veranderen met opzet: een frame is dan vereist binnen de wachttijd die je instelt, en zo vang je de feed die verbonden is en gestopt is.
Wat is het verschil tussen 1000 en 1011 bij een sluiting?
1000 is een normale sluiting en 1011 betekent dat de server een situatie heeft bereikt waar hij niet van kon herstellen, en beide komen binnen als een socket die verdween. De sluitcode en reden staan in de foutmelding, in plaats van te worden samengevoegd tot disconnected, omdat ze degene die het oplost naar twee verschillende plekken sturen.
Ondersteunen jullie Socket.IO, SignalR, STOMP of MQTT?
Nee, en we zeggen dat expliciet in plaats van iets anders te impliceren. Dat zijn framings bovenop WebSocket, elk met zijn eigen handshake en eigen idee van een namespace, en een check die ze half ondersteunt zou slechter zijn dan een die dat niet doet. De ruwe check vertelt je nog steeds dat het transport eronder werkt.
Controleert het het certificaat op een wss://-adres?
Ja. Een wss://-verbinding wordt gecontroleerd tegen de publieke trust store zoals elke andere, dus een verlopen certificaat, een zelfondertekend certificaat of een hostname mismatch laat de check falen. Het aantal resterende dagen is een vraag voor een certificaatmonitor en het is de moeite waard om die naast deze te draaien.
Kan ik een socket op mijn eigen netwerk controleren?
Nee, en dit is de weigering waar we het minst spijt van hebben. Een WebSocket naar een intern adres is een langdurige bidirectionele tunnel die door onze infrastructuur op schema wordt geopend, wat een slechtere versie is van een server-side request forgery dan een eenmalige fetch. Het adres wordt direct voor het verbinden opgelost en een privé-adres wordt geweigerd.
Mijn client maakt zelf opnieuw verbinding. Waarom ook de socket monitoren?
Dat zou moeten, en een client zonder retry-logica is het grotere probleem van de twee, dus dat werk is niet verspild. Het betekent wel dat je client precies datgene verbergt wat je zou moeten weten. Een socket die een verbinding accepteert, deze dertig seconden vasthoudt en dan verbreekt, laat een reconnectende client urenlang bijna verbonden lijken, terwijl elk bericht dat in de tussenliggende tijd wordt verzonden verloren gaat. Dit verbindt, voltooit de handshake en houdt de socket vast, zodat een server die op deze manier faalt de check laat falen in plaats van te worden verdoezeld door de retry-logica aan de andere kant.