PubNub Developer Relationsインターネットの急速な普及により、クライアントとサーバー間の通信を強化するリアルタイム技術の需要が高まっている。WebSocketの人気は高まり、現在ではリアルタイム通信を可能にする最も一般的な手法の一つとなっている。しかし、技術の選択は特定のユースケースに依存するため、WebSocketが常に最良の選択肢とは限りません。特定の状況により適した代替オプションは数多くあります。
WebSocketとは何ですか？
WebSocketは、以下の機能を提供するプロトコルです。 全二重通信と双方向通信チャネルを提供するプロトコルです。サーバーに再接続することなく、クライアント側とクライアント・サーバー間でリアルタイムのデータ伝送を可能にします。従来のHTTPプロトコルとは異なり、WebSocketはクライアントとサーバーがいつでも通信を開始し、データを送信できるため、リアルタイムのデータ伝送に最適です。
なぜWebSocketを選ぶのか？
開発者がリアルタイム通信について考えるとき、私たちはほとんどいつもWebSocketを使っています。これはなぜでしょうか？どのようなユースケースであっても、リアルタイム伝送を実現する唯一の／最良の選択なのでしょうか？
簡単に言うと、WebSocketは高度な機能を提供しますが、ユースケースによっては、プロジェクトの複雑さを一気に増大させる多くの欠点があります。これを解決するために、開発者がWebSocketの代替手段を選ぶ理由を考えてみよう。
パフォーマンス：WebSocketはその高度な機能性で最も知られていますが、時には過剰なソリューションをもたらし、パフォーマンスの低下を招くことがあります。WebSocketの使用を決定する際には、ユースケースを考慮することが不可欠である。例えば、高い同時接続数が必要な場合は、WebSocketよりも優れたソリューションがあります。WebSocketコネクションは、クライアントとサーバーの間で生き続けなければならず、規模が大きくなるにつれて、サーバーや基礎となるインフラへの負荷が増大する。
相互運用性：WebSocketは、すべての最新のWebブラウザ/ネットワークでサポートされています。偶然にも、ソフトウェアがレガシー・ブラウザやネットワークで使用されている場合、そのレガシー・システムでWebSocketsがサポートされているかどうかを検討することが不可欠です。さらに、ネットワークやプロキシがWebSocket接続を完全にブロックすることもあるので、どこでソフトウェアを使用するかも考慮すべき要因の一つです。
セキュリティ：WebSocketは、いくつかの代替手段のように安全ではなく、悪意のある行為者が悪用できる脆弱性を持っています。WebSocketが他のプロトコルに比べて安全性が低いとされる理由には、クロスサイト・ウェブソケット・ハイジャッキングやオリジン・スプーフィングなどがあります。
ウェブソケットの代替
ロングポーリング
ロングポーリングは、クライアントがサーバーに HTTP/HTTPS リクエストを送信するアプローチですが、サーバーから即座にレスポンスを受け取る代わりに、HTTP 接続を維持する必要があります。HTTP接続を維持することで、データが利用可能になったときやタイムアウトのしきい値に達したときに、サーバーが後で応答できるようになります。応答を受け取ったクライアントは、すぐに次のリクエストを送信します。
ロングポーリングは、WebSocketが提供する双方向通信チャネルを使用せずにリアルタイム通信を実現します。主な違いは、WebSocketsのように持続的な接続を維持する代わりに、クライアントはサーバーとの接続を再確立するために複数のリクエストを送信することである。
MQTT
MQTTは軽量で、パブリッシュ・サブスクライブ型のマシン・ツー・マシン・ネットワーク・プロトコルであり、ネットワーク帯域幅が限られているデバイスを持つ遠隔地向けに設計されている。スマートセンサー、ウェアラブル、その他のIoTデバイスは、リソースの制約により、通常このようなプロトコルを使用する必要があります。WebSocketは様々なアプリケーションに使用できるが、MQTTは明確にマシン間通信のために設計されているため、このようなユースケースでは代替手段として考えられている。MQTTは、低オーバーヘッド、効率的なメッセージ配信、オフライン操作のサポートなどの機能を提供する。
WebRTC
WebRTCは C++と JavaScriptで書かれた無料のオープンソースプロジェクトで、ウェブブラウザとモバイルデバイスにリアルタイム通信を提供する。WebRTCは 構築されているは、サーバー側の接続や追加のプラグインを必要とせずに、ピアツーピアから直接オーディオとビデオをストリーミングするために構築されています。ライブストリーミング、ビデオ会議、グループ通話などのユースケースでは、WebRTC APIを使用して、HTML5とJavaScriptでこれらの機能を迅速に設計することができます。要約すると、WebRTCのピアツーピアの性質は、これらのユースケースにおいて、サーバーの負荷を軽減し、WebSocketに比べてより効率的で高品質な通信体験を提供するのに役立ちます。
WebTransportとWebSocketの比較
WebTransportは、クライアントとサーバー間で低遅延かつ高スループットの接続を提供する新しいウェブ通信プロトコルです。これは、WebSocketのような従来のプロトコルの制限のいくつかに対処し、今日のWebアプリケーションの需要をよりよく扱うことができる近代的な代替手段を提供するために作成されました。
WebSocketは通常HTTP/1.1アップグレードリクエストとして開始しますが、WebTransportはHTTP/2を含む複数のプロトコルをサポートしています、 HTTP/3および QUICを含む複数のプロトコルをサポートし、UDPベースのトランスポートです。さらに、WebTransportはストリームAPIによる信頼性の高いデータ送信と、データグラムAPIによる信頼性の低いデータ送信をサポートしています。この新しい技術について、WebSocket と比較してどうなのか、また WebTransport プロトコルに切り替える利点は何なのか。
高度な機能性： ウェブソケットの課題は、画像とテキストのような異なるタイプのデータを1つの接続で送信するのが難しいことです。この問題は、TCP接続で送信するために、データをパケットと呼ばれる小さな単位に分割するために発生します。データをパケットに分割する際、データに含まれるプレーン・テキストとエンコードされた画像を区別する方法はありません。これを解決するために、WebSocketではサーバーとクライアントの間で、画像用とテキスト用の2つの接続を行う必要があります。しかし、WebTransportは、多重化として知られる複数のストリームをサポートすることで解決策を提供します。複数のストリームをサポートすることで、開発者は1つの接続で異なるタイプのデータを送信することができ、多数の接続を確立して維持するオーバーヘッドを削減することができます。これは、サーバーが多数のクライアントをサポートする必要がある場合に不可欠となる。WebSocketのようにクライアントごとに複数のコネクションを使用すると、サーバーの規模が大きくなったときに複雑な問題が発生する可能性があります。
パフォーマンスの向上：WebTransportはUDPベースのトランスポート・プロトコルで、WebSocketのようなTCPベースのプロトコルよりもパフォーマンスが優れています。UDPベースのため、エラー訂正や再送はありません。エラー訂正とは、送信データに発生したエラーを検出して訂正することです。再送信とは、失われたり破損したりしたデータ・パケットをネットワーク上で再送信する処理を指します。訂正と再送信のオーバーヘッドがないため、WebTransportの待ち時間が短縮されます。WebTransport には、リクエストのスループットと待ち時間を最適化する WebTransportCongestionControl 設定もあります。次に、QUICハンドシェイクを介したWebTransportによる新規接続の確立は、通常、TCP over TLSよりも高速です。
信頼性：エラー訂正と再送信がないため、開発者はWebTransportがWebSocketsより信頼性が低いと思うかもしれません。WebTransportは設計上、WebSocketよりも信頼性が高く、特に広帯域幅の通信や厳しいネットワーク条件のシナリオで威力を発揮します。WebTransport が提供するのは信頼性の高い一方向データ転送 (WebTransportReceiveStreams) または双方向データ転送 (WebTransportBidirectionalStream) のためのストリーム API を提供します。この API エンドポイントは、WebTransportReliabilityMode などの設定を提供し、信頼性の高いデータ転送が不可欠なシナリオで接続に TCP フォールバックを持たせることができます。
セキュリティ：WebTransport は WebSockets よりも安全なプロトコルを提供します。デフォルトでエンドツーエンドの暗号化を提供し、クライアントとサーバー間のデータが転送中に傍受されたり変更されたりしないようにします。これらのセキュリティ機能の1つは、"Origin "ヘッダーの使用で、サーバーが信頼できるソースからのリクエストであることを確認する方法を提供します。これは、クロスサイトリクエストフォージェリ（CSRF）攻撃を防ぐのに役立ちます。
他の選択肢
サーバー送信イベント
Server-Sent Events (SSE) はサーバープッシュ技術で、サーバーが一つのHTTPコネクション上でクライアントにデータをプッシュすることを可能にします。SSE は、ウェブページやアプリケーションにリアルタイムのアップデートを送信するためのシンプルで効率的なプロトコルであり、特定のユースケースに適しています。従来のHTTPリクエストは1回のレスポンスでコネクションを閉じますが、SSEはサーバーとクライアントの間に長時間のコネクションを開くため、サーバーは同じコネクション上で複数の更新を送信できます。WebSocketの双方向接続に比べ、Server-Sent Eventsは単方向接続です。クライアントは接続を開始し、閉じるだけでよい。しかし、Server-Sent Eventsの限定された機能セットは、実装とデバッグを容易にします。Server-Sent Events は EventSourceAPIの始まりであり、ウェブブラウザでの実装を容易にしている。
PubNubはWebSocketの代替でどのように役立つか
WebSocketプロトコルとWebTransportのようなその代替はすべてリアルタイム通信を処理するための貴重なソリューションです。しかし、どのようなソリューションを選択しても、基盤となるインフラストラクチャの実装に時間が浪費され、スケーリング時に複雑な問題が発生します。例えば、Socket.ioのような特定の技術を使用してWebSocketサーバーを作成する場合、開発者は、各Webサーバーの使用率を管理するためのロードバランサーの背後で、世界中のサーバーを動的に生成する必要があります。
PubNubのリアルタイムデータAPIにより、ユーザーは特定のユースケースに関係なく、すべてのデバイス間でリアルタイム通信を促進する強力なイベント駆動型アプリケーションを開発できる。PubNubは、選択したデバイスとのシームレスな統合を保証するために、Webアプリケーション用のJavaScript SDKやIoTアプリケーション用のC-Core SDKなど、さまざまなSDKを提供しています。PubNubを使用すれば、適切な代替手段を選択したり、リアルタイムソリューションを実装するための根本的な複雑さを心配したりする必要はありません。
これで、WebSocketまたは代替手段を使用するタイミングを理解できました、 無料トライアルに申し込むまたは デモの予約を予約して、PubNubで構築できるものを調べてみてください。
PubNubはどのように役立つのでしょうか？
この記事はPubNub.comに掲載されたものです。
PubNubのプラットフォームは、開発者がWebアプリ、モバイルアプリ、IoTデバイス向けにリアルタイムのインタラクティブ機能を構築、提供、管理できるよう支援します。
私たちのプラットフォームの基盤は、業界最大かつ最もスケーラブルなリアルタイムエッジメッセージングネットワークです。世界15か所以上で8億人の月間アクティブユーザーをサポートし、99.999%の信頼性を誇るため、停電や同時実行数の制限、トラフィックの急増による遅延の問題を心配する必要はありません。
PubNubを体験
ライブツアーをチェックして、5分以内にすべてのPubNub搭載アプリの背後にある本質的な概念を理解する
セットアップ
PubNubアカウントにサインアップすると、PubNubキーに無料ですぐにアクセスできます。
始める
PubNubのドキュメントは、ユースケースやSDKに関係なく、あなたを立ち上げ、実行することができます。
