WebSocket
WebSocketモニタリング
アップグレードハンドシェイク、少し後にまだ開いているソケット、そして最初のメッセージ。
今すぐ試してください
1回のチェックを1か所から今すぐ実行しますが、何も保存されません。モニターはすべての拠点からチェックを行い、2つの他の大陸からも障害を確認してから通知します。単一のチェックではそれを確認できません。
用途
チャット、ライブダッシュボード、価格フィード、共同編集ツール、ゲームロビー: これらすべてがWebSocketであり、下層がすべて正常である間に失敗する製品の一部です。ページは読み込まれ、APIは応答し、証明書は有効で、ポートは開いていますが、ソケットは開きません。
または、200ミリ秒後に再び開いて閉じることがあります。これは、ユーザー側から見ると、静かに更新が停止する画面であり、誰も障害として報告しません。ユーザーはリフレッシュし、一時的に動作し、最終的に諦めます。そのため、これはハンドシェイクで終わりません。その後もソケットを監視します。これは、TCPチェックが開いているポートだけで満足せず、挨拶を要求するのと同じ方法です。
そして、実際に人々が損失を被るケース: 接続されているが配信を停止したフィードです。送信するメッセージと返信が一致する必要があるパターン、または単なるパターンを指定してください。静かなフィードは、正常に見える緑の行ではなく、失敗と見なされます。
ここにあるすべてのチェックと同様に、Amsterdam, New York, Sydney and Singaporeから実行され、障害が発生した場合、他の2つの大陸から確認されてから通知されます。その仕組み。
設定できる内容
以下のすべては、どのプランでも追加時のフォームに含まれています。
- アドレス
- ws://またはwss://アドレスとパスです。ホストとポートはTCPチェックであり、別の質問です。
- 最初にこれを送信
- ソケットが開くとすぐに送信される1つのテキストフレームで、配信ではなく応答するエンドポイント用です。
- 期待されるメッセージ
- フレームが一致する必要がある正規表現です。これを入力することで、フレームが必要になります。
- 待機時間
- 秒単位です。接続タイムアウトとは別で、30秒ごとに配信するフィードは正常であり、ハンドシェイク形式の期限には失敗する可能性があります。
- タイムアウト
- ハンドシェイク自体にかかる時間。
- 確認
- 誰かが起こされる前に、他の大陸がどれだけ同意する必要があるか。
質問
なぜHTTPSモニターをそのまま指すことができないのですか？
正常な応答が障害として記録されるからです。WebSocketは、Upgrade: websocketとSec-WebSocket-Keyを含むHTTP GETとして開始され、通常のGETに対して400または426で応答するサーバーは正しく動作しています。HTTPSモニターはそのステータスコードを検出し、正常に動作しているにもかかわらずダウンとして報告します。
チェックは実際に何をしますか？
送信されたキーから派生したSec-WebSocket-Acceptを含む101でアップグレードハンドシェイクを完了し、その後ソケットが開いたままかどうかを確認するために一瞬保持します。その後、切断します。チェック間で接続を保持しないため、これがサーバーにとってクライアントのように見えることはありません。
私のフィードはほとんどの時間静かです。それは失敗しますか？
いいえ。何も送信しないソケットは、期待されるメッセージを設定しない限り正常です。公開する内容がないフィードは壊れているわけではありません。それを設定すると、意図的にルールが変更されます。その場合、設定した待機時間内にフレームが必要となり、接続されているが停止しているフィードを検出できます。
1000は正常な切断で、1011はサーバーが回復不能な状態に陥ったことを示しています。どちらもソケットが切断された状態として届きます。切断コードと理由は失敗の中に含まれており、単に切断とまとめられるのではなく、修正する人を異なる原因に導きます。
1000は正常な切断で、1011はサーバーが回復不能な状態に陥ったことを示しています。どちらもソケットが切断された状態として届きます。切断コードと理由は失敗の中に含まれており、単に切断とまとめられるのではなく、修正する人を異なる原因に導きます。
Socket.IO、SignalR、STOMP、MQTTには対応していません。対応しているかのような誤解を与えることもありません。これらはそれぞれ独自のハンドシェイクと名前空間の概念を持つWebSocket上のフレームワークであり、それらを中途半端に扱うチェックは、対応しないチェックよりも悪い結果を招きます。ただし、これらの上位プロトコルの下にあるトランスポートが正常であるかどうかは確認できます。
いいえ、そしてその点を明確にお伝えします。それらはWebSocketの上にレイヤー化されたフレームワークであり、それぞれ独自のハンドシェイクと名前空間の概念を持っています。それらを中途半端に扱うチェックは、対応しないチェックよりも悪い結果を招きます。ただし、これらの上位プロトコルの下にあるトランスポートが正常であるかどうかは確認できます。
はい。wss://接続は他の接続と同様に公開トラストストアに対して検証されます。そのため、有効期限切れの証明書、自己署名証明書、またはホスト名の不一致がある場合、チェックは失敗します。残りの有効日数は証明書モニターの対象であり、このモニターと併用する価値があります。
はい。wss://接続は他の接続と同様に公開トラストストアに対して検証されます。そのため、有効期限切れの証明書、自己署名証明書、またはホスト名の不一致がある場合、チェックは失敗します。残りの有効日数は証明書モニターの対象であり、このモニターと併用する価値があります。
いいえ、そしてこれについては最も後悔していない拒否です。内部アドレスへのWebSocketは、スケジュールに基づいて当社のインフラストラクチャによって開かれる長時間接続の双方向トンネルであり、単発のフェッチよりもサーバーサイドリクエストフォージェリのリスクが高まります。接続前にアドレスが即座に解決され、プライベートアドレスは拒否されます。
いいえ、そしてこれについては最も後悔していない拒否です。内部アドレスへのWebSocketは、スケジュールに基づいて当社のインフラストラクチャによって開かれる長時間接続の双方向トンネルであり、単発のフェッチよりもサーバーサイドリクエストフォージェリのリスクが高まります。接続前にアドレスが即座に解決され、プライベートアドレスは拒否されます。
それは必要ですし、再接続ロジックのないクライアントの方がより大きな問題ですので、その作業は無駄ではありません。ただし、クライアントがまさに知るべき問題を隠してしまう可能性があります。接続を受け入れ、30秒間保持して切断するソケットは、再接続するクライアントを数時間ほぼ接続されているように見せかけますが、その間に送信されたメッセージはすべて失われます。このモニターは接続し、ハンドシェイクを完了し、ソケットを保持します。そのため、このように失敗しているサーバーは、再接続ロジックによって隠されるのではなく、チェックに失敗します。
その通りです。再試行ロジックのないクライアントの方がより大きな問題ですので、その作業は無駄ではありません。ただし、クライアントがまさに知るべき問題を隠してしまう可能性があります。接続を受け入れ、30秒間保持して切断するソケットは、再接続するクライアントを数時間ほぼ接続されているように見せかけますが、その間に送信されたメッセージはすべて失われます。このモニターは接続し、ハンドシェイクを完了し、ソケットを保持します。そのため、このように失敗しているサーバーは、再接続ロジックによって隠されるのではなく、チェックに失敗します。