WebSocket
WebSocket-Überwachung
Der Upgrade-Handshake, der Socket ist einen Moment später noch offen, und die erste Nachricht.
Jetzt ausprobieren
Ein Test, von einem Ort, jetzt sofort, und nichts wird gespeichert. Ein Monitor prüft von jedem Standort, den wir betreiben, und bestätigt einen Ausfall von zwei anderen Kontinenten, bevor jemand geweckt wird, was ein einzelner Blick dir nicht zeigen kann.
Wofür es ist
Dein Chat, dein Live-Dashboard, dein Preis-Feed, dein kollaborativer Editor, deine Spiel-Lobby: Alles davon ist ein WebSocket, und es ist der Teil eines Produkts, der ausfällt, während jede darunterliegende Ebene grün bleibt. Die Seite lädt, die API antwortet, das Zertifikat ist in Ordnung, der Port ist offen, und der Socket öffnet sich nie.
Oder er öffnet sich und schließt sich wieder zweihundert Millisekunden später, was aus Sicht des Nutzers ein Bildschirm ist, der stillschweigend aufhört zu aktualisieren und den niemand als Störung meldet. Sie aktualisieren, es funktioniert für eine Minute, sie geben auf. Deshalb hört dieser Check nicht beim Handshake auf: Er beobachtet den Socket einen Moment danach, genauso wie der TCP-Check auf eine Begrüßung bestehen kann, statt sich mit einem offenen Port zufrieden zu geben.
Und der, bei dem Leute tatsächlich Geld verlieren: Der Feed, der verbunden ist und aufgehört hat zu veröffentlichen. Gib uns eine Nachricht zum Senden und ein Muster, das die Antwort erfüllen muss, oder nur ein Muster, und ein stiller Feed ist ein Fehler statt einer gesund aussehenden grünen Zeile.
Wie jeder Check hier läuft er von Amsterdam, New York, Sydney and Singapore, und ein Fehler wird von zwei anderen Kontinenten bestätigt, bevor jemand geweckt wird. Wie das funktioniert.
Was du einstellen kannst
Alles unten steht im Formular, wenn du einen hinzufügst, in jedem Tarif.
- Adresse
- Eine ws://- oder wss://-Adresse, mit dem Pfad. Ein Host und Port ist der TCP-Check, was eine andere Frage ist.
- Dies zuerst senden
- Ein Text-Frame, gesendet sobald der Socket sich öffnet, für einen Endpoint, der antwortet statt veröffentlicht.
- Erwartete Nachricht
- Ein regulärer Ausdruck, den ein Frame erfüllen muss. Ihn auszufüllen macht einen Frame überhaupt erst erforderlich.
- Wie lange darauf warten
- Sekunden. Getrennt vom Verbindungs-Timeout, weil ein Feed, der alle dreißig Sekunden veröffentlicht, gesund ist und eine Handshake-Deadline nicht erfüllen würde.
- Timeout
- Wie lange der Handshake selbst dauern darf.
- Bestätigungen
- Wie viele andere Kontinente zustimmen müssen, bevor jemand geweckt wird.
Fragen
Warum kann ich nicht einfach den HTTPS-Monitor darauf richten?
Weil die gesunde Antwort als Ausfall aufgezeichnet würde. Ein WebSocket beginnt mit einem HTTP GET, das Upgrade: websocket und einen Sec-WebSocket-Key enthält, und ein Server, der auf ein einfaches GET mit 400 oder 426 antwortet, verhält sich genau richtig. Ein HTTPS-Monitor sieht diesen Statuscode und meldet dich als down, obwohl alles perfekt funktioniert.
Was macht der Check eigentlich?
Es schließt den Upgrade-Handshake ab, was eine 101 mit dem Sec-WebSocket-Accept bedeutet, der aus dem gesendeten Key abgeleitet wurde, und hält den Socket dann kurz, um zu sehen, ob er offen bleibt. Danach legt es auf. Es hält keine Verbindung zwischen den Checks, sodass nichts davon wie ein Client für deinen Server aussieht.
Mein Feed ist die meiste Zeit still. Wird das fehlschlagen?
Nein. Ein Socket, der sich öffnet und nichts sagt, ist gesund, es sei denn, du gibst eine erwartete Nachricht an, denn ein Feed ohne Inhalte ist kein kaputter Feed. Gib das an und die Regeln ändern sich absichtlich: Dann wird ein Frame innerhalb der von dir gesetzten Wartezeit benötigt, um den Feed zu erkennen, der verbunden ist und gestoppt hat.
Was ist der Unterschied zwischen 1000 und 1011 bei einem Close?
1000 ist ein normaler Abschluss und 1011 bedeutet, dass der Server auf eine Bedingung gestoßen ist, von der er sich nicht erholen konnte, und beide kommen als ein Socket, der geschlossen wurde. Der Close-Code und der Grund sind im Fehler enthalten, anstatt einfach als disconnected angezeigt zu werden, da sie denjenigen, der es behebt, an zwei verschiedene Stellen führen.
Unterstützt ihr Socket.IO, SignalR, STOMP oder MQTT?
Nein, und wir sagen das, anstatt etwas anderes zu implizieren. Das sind Frameworks, die auf WebSocket aufgesetzt sind, jedes mit seinem eigenen Handshake und seiner eigenen Vorstellung von einem Namespace, und ein Check, der sie halb spricht, wäre schlechter als einer, der es nicht tut. Der rohe Check zeigt dir trotzdem, dass der Transport darunter funktioniert.
Prüft es das Zertifikat bei einer wss:// Adresse?
Ja. Eine wss:// Verbindung wird wie jede andere gegen den öffentlichen Trust Store geprüft, sodass ein abgelaufenes Zertifikat, ein selbstsigniertes oder ein Hostnamen-Mismatch den Check nicht besteht. Die verbleibenden Tage sind eine Frage für einen Zertifikats-Monitor und es lohnt sich, diesen parallel laufen zu lassen.
Kann ich einen Socket in meinem eigenen Netzwerk prüfen?
Nein, und das ist die Ablehnung, über die wir am wenigsten traurig sind. Ein WebSocket zu einer internen Adresse ist ein langlebiger bidirektionaler Tunnel, der von unserer Infrastruktur nach Zeitplan geöffnet wird, was eine schlimmere Version einer serverseitigen Request-Fälschung ist als ein einmaliger Abruf. Die Adresse wird unmittelbar vor der Verbindung aufgelöst und eine private wird abgelehnt.
Mein Client verbindet sich von selbst neu. Warum den Socket trotzdem überwachen?
Das sollte es, und ein Client ohne Retry-Logik ist das größere Problem der beiden, sodass diese Arbeit nicht umsonst ist. Es bedeutet, dass dein Client genau das versteckt, was es wert ist, zu wissen. Ein Socket, der eine Verbindung akzeptiert, sie dreißig Sekunden hält und dann abbricht, lässt einen sich neu verbindenden Client stundenlang fast verbunden aussehen, während jede Nachricht, die in den Lücken gesendet wird, verloren geht. Dieser verbindet sich, schließt den Handshake ab und hält den Socket, sodass ein Server, der auf diese Weise scheitert, den Check nicht besteht, anstatt durch die Retry-Logik auf der anderen Seite überdeckt zu werden.