WebSocketは10年以上前から存在していますが、リアルタイムのウェブは来るずっと前に存在していました。 この前の「リアルタイム」のウェブは、通常、遅く、達成するのが難しかったです。 これは、主にリアルタイムアプリケーション用に構築されていない利用可能なWeb技術をハッキングすることによって達成されました。 Web 環境では、Web 環境での操作に関連するすべての問題に対処できる、TCP/IP ソケット スタイルの機能を備えたソリューションはありませんでした。
ウェブソケット:簡単な歴史
2008 年半ば頃、長年にわたる HTTP 接続を使用する実装の制限と痛みは、特に 2 人の開発者によって感じられます。イアン・ヒクソンとマイケル・カーター W3Cメーリングリストとインターネットリレーチャット(IRC)のコラボレーションに続いて、デュオはウェブ上で近代的でリアルタイムの双方向通信のための新しい標準を導入する計画を考え出し、「WebSockets」という名前を作りました。このアイデアは最終的にW3C HTML標準への道を見つけ、その後マイケル・カーターは記事で彗星コミュニティをWebSocketsに紹介しました。
2010年、Google Chrome 4はWebSocketsのサポートを出荷した最初のブラウザとなり、その直後に他のブラウザが登場しました。 WebSocket プロトコル (RFC 6455) は 2011 年に IETF の Web サイトに公開されました。 今日、ほぼすべての最新のブラウザは、WebSocketを完全にサポートしています。 また、AndroidおよびiOSベースのブラウザは2013年からWebSocketのサポートを開始したため、現在の一般的な状況は、特に2022年にWebSocketを強力にサポートしています。
ウェブソケットとは何ですか?
WebSocket は、単一の TCP 接続を介してサーバーとクライアント間の永続的な全二重通信を提供するコンピューター通信プロトコルです。 WebSockets は、クライアントが要求を行わずに、サーバーでデータが変更された場合に、データをクライアントにプッシュバックする機能を提供します。 この双方向通信は、同時接続と動的コンテンツを持つアプリケーションの応答性にとって非常に重要です。 WebSocket は、リアルタイムのデータ同期と更新、ビデオ会議、VOIP、ライブ テキスト チャット、IoT 制御、および監視に最適です。 例えば、マルチプレイヤーのオンラインゲームは、WebSocketsではるかに優れています。
クライアント/Web ブラウザとサーバーが相互に通信できるようにするには、その間に接続を確立する必要があります。 クライアントは、要求に含まれるアップグレード ヘッダーを使用して HTTP 要求をサーバーに送信することによってプロセスを開始します。 例えば：
GET ws://websocket.dotcom-monitor.com/ HTTP/1.1 Origin: http://example.com Connection: Upgrade Host: websocket.dotcom-monitor.com Upgrade: websocket
この要求は、クライアントが WebSocket 接続を確立することをサーバーに通知します。 また、サーバーが WebSocket をサポートしている場合は、応答でアップグレード ヘッダーを送信してハンドシェイクを受け入れます。 例えば：
HTTP/1.1 101 WebSocket Protocol Handshake Date: Wed, 16 Oct 2013 10:07:34 GMT Connection: Upgrade Upgrade: WebSocket
ハンドシェイクが完了したので、両当事者は互いにデータを送信し始めることができます。 さらに重要なのは、このデータはアプリケーションのデータだけで構成され、ヘッダーなどの HTTP 関連の属性では構成されないので、従来の HTTP 要求と比較すると通信が非常に高速になります。
ウェブソケットと HTTP および AJAX の対
クライアントからの要求でのみ通信する HTTP や AJAX などのプロトコルとは異なり、WebSockets の全二重の性質により、サーバーはいつでもクライアントとの通信を開始できます。 WebSocket プロトコルは、ポーリング ベースの操作に従わない割り込みベースのアプリケーションに似ています。 Web スピークでは、クライアントがサーバーへの通信を継続的に開始し、新しいデータを取得するように要求する必要がある HTTP ベースのトラッピングとパラダイムから移行しています。 HTTP では、サーバーは、状態が変更されてもクライアントに新しいデータをプッシュすることはできませんが、クライアントの要求に基づいてのみ、クライアントにプッシュできることに注意してください。
これは、特にクライアントの要求がスケールアップする場合、リアルタイムアプリケーションにとって非常に偏見です。 WebSockets は、持続的な双方向通信を確立し、サーバーは要求を連続的に必要とせずにクライアントを更新できるようにします。 これにより、クライアントとサーバー間の低遅延接続が実現するだけでなく、サーバーの要求時にクライアントがパケットを送信する必要がなくなり、ネットワーク トラフィックが削減されます。 サーバーは、データが使用可能になった直後、または状態が変化した時点で、クライアントにデータをプッシュするだけです。
WebSocket を使用して構築できるアプリケーションは何ですか?
WebSockets のリアルタイムアプリケーションは無限大です。 今日では、開発者は、リアルタイムのアプリケーションとサービスの基礎として、プレーンな WebSocket を実装しています。 WebSocket がすべての主要なブラウザでますますサポートされるようになったので、長いポーリング フォールバックに基づくソリューションはすぐにその魅力を失っています。 その結果、多くの開発者は現在、WebSockets API を支持してライブラリを放棄しています。 WebSocket は、TCP 接続を介して双方向のリアルタイム機能の基礎として使用できます。 デバイスに信号をすばやくプッシュする機能により、WebSocket は 2 つのデバイス間でデータをプッシュするための優れたソリューションになります。 これにより、WebSockets は、クライアントとサーバーを持つものに対して、モバイルと Web の両方でリアルタイムアプリケーションを開発するための青写真になります。
ウェブソケットの機会
連続接続
WebSocket では、サーバーとクライアントの間の一定の接続が可能です。 これにより、クライアントが要求を送信しなくても、データはどちらの方向でもいつでも中継できます。 これは、サーバー上で発生している内容について、クライアントを比較的迅速に更新する必要がある場合に非常に重要です。
効率
WebSocket は、どちらの方法でもデータを送信する効率的な方法を提供します。 そのデータ フレームは、ヘッダーや Cookie などを含む HTTP 要求とは異なり、適切に編成されており、効率的に送信できます。
低遅延
WebSocket では、応答時間が非常に少ないです。 接続が確立されているため、データを迅速に受信できるため、TCP 接続を作成するために余分なパケットラウンド トリップが必要になることはありません。
ウェブソケットの障害
スケーリングの問題
複雑な作業に見えるかもしれませんが、WebSocket ベースのリアルタイム機能の開発は、課題の 4 分の 1 に過ぎません。 もちろん、合理的な量のユーザーに追いつくことができるWebSocketアプリケーションはたくさんありますが、何億人ものユーザーを誇るLinkedInとFacebookの順序には何もありません。 ユーザーベースが急上昇し始めると、スケーリングと運用上の課題が発生します。 WebSocket を使用しても、信頼性の高いリアルタイム システムの開発とスケーリングには、複雑な手順とオーケストレーションの問題が含まれます。 時間が経つにつれて、あなたの時間とお金の4分の3は、あなたのリアルタイムシステムのスケーリングとメンテナンスによって悩まされる可能性があります。
コストへの影響
運用環境でアプリケーションを成功させるためには、高度な展開、複数の冗長サーバー、新しい種類の監視ツール、維持、およびエンジニアリングメンテナンスが必要です。 アプリケーションが機能し始めると、冗長性、ジオルーティング、地理的なサーバーの分散、高い信頼性、遅延監視を備えたデータストリーミングのためのリアルタイムネットワークを維持することは、あらゆるビジネスにとって大きな財政的負担となります。 リアルタイム アプリケーションを開発および維持するソフトウェア企業は、アプリケーションの価値提案の強化に注力するのではなく、リアルタイム インフラストラクチャの維持に 50% 以上のエンジニアリング作業を費やします。
実装
一般的に、WebSocket は HTTP よりも少し複雑です。 Telnet との HTTP 接続を確立することはできますが、おそらく WebSocket では行いません。 ハンドシェイクの要件を無視した場合でも、送信する必要があるデータを適切にマスクしてフレーム化することはできません。 その結果、サーバーは接続を終了します。
WebSocket がアプリケーションに適しているのはいつですか。
リアルタイムウェブでは、WebSocketは即時性だけではありません。 応答性、同期性、効率性などを提供します。 HTTP と同様に、WebSocket には、プロジェクトの選択肢が適しているシナリオが用意されています。 これらのシナリオには、次のようなものがあります。
- 速い反応時間。 クライアントが変更に迅速に対応する必要がある場合、特に予測できない変更に対しては、WebSocket が役立ちます。 たとえば、複数のユーザーがリアルタイムでチャットできるチャット アプリケーションがあります。 表現状態転送 (REST) とは異なり、WebSocket は、送信または受信した個々のメッセージに対して要求または応答のオーバーヘッドを必要としないため、効率が高くなります。
- 継続的な更新: クライアントがリソースの状態について継続的に更新する必要がある場合、WebSocket は適切に動作します。 クライアントが変更のタイミングを知ることができない場合は特に重要です。
- アドホック メッセージング: WebSocket は、要求-応答プロトコルに従っていません。 接続のどちらの終端でもいつでもメッセージを送信でき、メッセージが別のメッセージに関連していることを示す規定はありません。 これにより、Web ソケットは「火災と忘れ」のシナリオに適しています。
- 小さいペイロードを使用した高周波メッセージング WebSocket は、メッセージを交換するための安定した永続的な接続を提供するため、すべてのメッセージがトランスポートを確立するために追加の税が発生することはありません。 コンテンツ ネゴシエーション、大きなヘッダーの交換、SSL の確立などの税金は、最初の接続の確立時に 1 回だけ課されます。 つまり、個々のメッセージに対する税金はありません。
WebSocket は、Web アプリケーションやモバイル アプリケーションにリアルタイム機能を追加しようとする人にとって、強力なツールです。 全二重双方向通信のギャップを埋めることによって、サーバー通信に関連する最大の頭痛の一部を解決します。 WebSockets は、他のすべての古いメソッドとは異なり、クライアントとサーバーの両方が望むときはいつでもデータを送信できるようにします。 これにより、パフォーマンスが大幅に向上し、データ待ち時間が短縮されます。 WebSockets は、軽量接続を通じて、パフォーマンスを損なうことなく接続を長く維持できます。
WebSocket ベースの Web アプリケーションの監視
オンライン ユーザーが 2 秒未満の読み込み時間を予想する時に、Web プラットフォームのパフォーマンスは今まで以上に重くなっています。 しかし、現代の Web ページに組み込まれた複雑なテクノロジは、負荷テストやパフォーマンス監視を行うのが非常に困難な場合があります。 それでも、Web アプリケーションで障害やダウンタイムが発生しているかどうか、顧客や訪問者ではなく、最初のユーザーにする必要があります。
WebSocket ベースのアプリケーションは、同期または非同期の WebSocket 呼び出しを使用して通信できます。 技術的には、同期呼び出しのパフォーマンスの追跡は簡単です。 サーバーに要求を送信し、応答を待つだけです。 ただし、大規模に行って、負荷の高いパフォーマンス ベンチマークを確立する場合は、困難な作業が必要です。 このような場合、合成監視ソリューションは、アプリケーションのパフォーマンスを継続的に監視するのに役立ちます。 合成 APM は、世界中にあるデバイスや実際のブラウザーから WebSocket ベースのアプリケーションを監視し、スケーリング、パフォーマンス、および応答性に関連する問題を追跡するのに役立ちます。
一方、非同期呼び出しは、クライアントが要求を開始する必要がないため、監視するのが難しい。 ここでは、サーバーは、クライアントに対して、データを単独で送信します。 また、非同期の WebSocket 呼び出しによってインターネットのリアルタイム通知が行われ、監視が重要になります。 合成監視ソリューションは、多くの場合、大規模な非同期 WebSocket 呼び出しのパフォーマンスを測定する高度な独自のメカニズムで構成されているため、ここで唯一実行可能なオプションです。
Web アプリケーションの監視はどのように行われるのか
ウェブアプリケーションをオンラインにすることはビジネスにとって重要ですが、1日24時間の問題をモニターで見つめたり、F5キーをタップしてリロードを試みたりして、うまくいきません。 監視チームを備えたコマンド センターを設置しても、少なくとも中小企業にとっては実現不可能な場合があります。 Web アプリケーションの監視ツールは、問題を特定し、売上を落とす前に正常な Web アプリケーションを維持するために不可欠です。
Web アプリケーションの監視とは、Web ページまたは Web アプリケーションの可用性とパフォーマンスをチェックして、オンライン ユーザーが Web リソースを常に利用できるようにするプロセスです。 ネットワーク、サーバー接続、データベースなどの変数の範囲を網羅します。 監視システムは、コンピューティング プラットフォームとアプリケーションとの対話のパフォーマンス メトリックも記録できます。
Web アプリケーション監視ソリューション
Web アプリケーションで技術的な問題が発生した場合、Web アプリケーションモニターは、Web アプリケーションが正しく読み込まなかったりレンダリングを正しく行わないときに即時に通知を行うアラート・システムとして機能します。 ドットコムモニターの Web アプリケーション監視 ソリューションは 、EveryStep Web レコーダーと呼ばれる Web ベースのスクリプトツールを利用しました。 レコーダーは、後で監視するためにアップロードすることができる簡単かつ迅速にユーザーパスを使用できます。 Web アプリケーション監視ソリューションは、指定した時間間隔 (1 分も) の後に自動オンライン チェックを実行し、アプリケーションがアップ状態になっているだけでなく、エンド ユーザーのビューからコンテンツが正しく表示されていることを確認します。 エラーが検出されるとすぐに、ソリューションは関連するチーム メンバーにアラートを送信し、他の多くのユーザーが影響を受ける前に問題を迅速に修正できるようにします。 エラー情報とともに、レポートには関連するウォーターフォール・グラフとパフォーマンス・データが含まれます。
Web ソケット ベースの Web アプリケーションを監視する理由
さまざまな理由で、Web サイトやアプリケーションが失敗する可能性があります。 ホスティング プロバイダー、ハッキング、または単にデータベースがダウンする問題は、ほんの一部の理由です。 したがって、Web アプリケーションが常にアクセス可能で表示されるように、Web アプリケーションを注意深く監視し続ける必要があります。 Web アプリケーション監視ツールを使用すると、次のような問題を迅速に軽減できます。
- Web アプリケーションをハッキングに対して脆弱にする抜け穴とセキュリティ障害
- Web ホストでのハードウェア障害
- 営業ができない支払いゲートウェイのダウンタイム/アクセス不能
- 潜在的なクライアントをウェブページやオンラインショップから遠ざける可能性のある低速
- 顧客の不満によるあなたのプロのイメージへのダメージ
- 検索ランキングが不十分
ラップアップ: WebSocket アプリケーションの監視
WebSocket をサポートする監視ツールのみを使用して、WebSocket を使用して構築されたアプリケーションのパフォーマンスを監視できることに注意してください。 優れた監視ツールには、次の機能が必要です。
- Web アプリケーションのパフォーマンス監視: 監視ツールは、監視対象の Web ページの応答時間をチェックする必要があります。
- モバイル Web アプリケーションの監視: 監視ツールは、ポータブル デバイス上での Web アプリケーションのパフォーマンスを評価し、重要な調整についてアドバイスする必要があります。
- ページ コンテンツの監視: アプリケーションのコンテンツをチェックし、変更が発生した場合に警告を表示する必要があります。
- 分のチェックまで: Web アプリケーションの監視ツールは、Web アプリケーションを 1 分ごとにチェックする必要があります。
Web アプリケーションの最適なパフォーマンスを保証する最も確実な方法は、完全かつ体系的なチェックを提供する、Dotcom-Monitor の Web アプリケーション 監視ソリューション を採用します。 スクリプトを作成し、WebSocket ベースのアプリケーションを監視する速度を確認します。 Web アプリケーション監視ソリューションを 30 日間無料で試してみてください。
