Web ソケット、Web ワーカー、サービス ワーカー…これらは、読んだり聞いたりしたことがある用語です。 すべてではないかもしれませんが、おそらく少なくともそのうちのXNUMXつです。 また、フロントエンド開発に精通している場合でも、その意味を調べる必要がある可能性は十分にあります。 または、あなたは私のようで、時々それらを混同します。 用語はすべて見た目も音もひどく似ており、混乱するのは本当に簡単です.

それでは、それらをまとめて、Web ソケット、Web ワーカー、およびサービス ワーカーを区別してみましょう。 深く掘り下げてそれぞれを実際に体験するという本質的な意味ではなく、次回ブックマークするための小さなヘルパーのようなものです I リフレッシュが必要です。

クイックリファレンス

簡単に比較対照できるように、ハイレベルな概要から始めます。

Webソケット

Web ソケットは双方向通信プロトコルです。 これは、どちらかが電話を切ることを決定しない限り終了しない、あなたとあなたの友人の間の進行中の通話のようなものだと考えてください。 唯一の違いは、あなたがブラウザであり、あなたの友人がサーバーであることです。 クライアントはサーバーにリクエストを送信し、サーバーはクライアントのリクエストを処理して応答します。

コミュニケーションはイベントに基づいています。 あ WebSocket オブジェクトが確立されてサーバーに接続し、サーバー間のメッセージがそれらを送受信するイベントをトリガーします。

これは、最初の接続が行われると、接続が開始され、クライアントまたはサーバーのいずれかが送信して終了することを選択するまで、接続が維持されるクライアント-サーバー通信があることを意味します。 CloseEvent. そのため、Web ソケットは、クライアントとサーバー間の継続的かつ直接的な通信を必要とするアプリケーションに最適です。 私が見たほとんどの定義は、一般的なユース ケースとしてチャット アプリを呼び出します。メッセージを入力し、サーバーに送信し、イベントをトリガーすると、サーバーはサーバーに何度も ping を実行することなくデータで応答します。

このシナリオを検討してください: 外出先で、Google マップに切り替えることにしました。 Google マップがどのように機能するかは既にご存知かもしれませんが、アプリに接続すると自動的に現在地が検出され、どこにいても追跡されます。 この接続が有効である限り、リアルタイムのデータ転送を使用して現在地を追跡します。 これは、データを最新の状態に保つために、ブラウザーとサーバーの間で永続的な双方向通信を確立する Web ソケットです。 リアルタイムのスコアを表示するスポーツ アプリも、このように Web ソケットを利用する場合があります。

Web Sockets と Web Worker (および、後で説明する Service Workers) の大きな違いは、DOM に直接アクセスできることです。 Web ワーカー (およびサービス ワーカー) は個別のスレッドで実行されますが、Web ソケットはメイン スレッドの一部であり、DOM を操作する機能を提供します。

Web Socket 接続の確立と維持に役立つツールとサービスには、次のものがあります。 ソケットクラスター, 非同期API, カウボーイ, WebSocket キング, チャンネル, ゴリラ WebSocket. MDNには 他のサービスを含む実行リスト.

Web ソケットの詳細情報

ウェブワーカー

DOM に変更を加えると同時に、一連の複雑な計算を実行する必要があるシナリオを考えてみましょう。 JavaScript はシングルスレッド アプリケーションであり、複数のスクリプトを実行すると、変更しようとしているユーザー インターフェイスや実行中の複雑な計算が中断される可能性があります。

ここで、Web ワーカーの出番です。

Web Worker では、スクリプトがバックグラウンドで別のスレッドで実行され、メイン スレッドでスクリプトが相互にブロックされるのを防ぐことができます。 これは、集中的な操作を必要とするアプリケーションのパフォーマンスを向上させるのに最適です。これらの操作は、レンダリングによるユーザー インターフェイスに影響を与えることなく、別のスレッドでバックグラウンドで実行できるためです。 ただし、Web ソケットとは異なり、Web ワーカーはメイン スレッドの外側で独自のスレッドで実行されるため、DOM へのアクセスはあまり得意ではありません。

Web ワーカーは、スクリプト ファイルを使用してスクリプト ファイルを実行するオブジェクトです。 Worker タスクを実行するオブジェクト。 そして、労働者について話すとき、彼らは次の XNUMX つのタイプのいずれかに分類される傾向があります。

• 献身的な労働者: 専用ワーカーは、それを呼び出すスクリプトによってのみ手の届くところにあります。 マルチスレッド スクリプトなど、一般的な Web ワーカーのタスクを引き続き実行します。
• 共有労働者: 共有ワーカーは専用ワーカーの反対です。 複数のスクリプトからアクセスでき、ワーカーと同じドメインに存在する限り、Web ワーカーが実行するすべてのタスクを実質的に実行できます。
• サービスワーカー: Service Worker は、アプリ、ブラウザー、およびサーバー間のネットワーク プロキシとして機能し、ネットワークがオフラインになった場合でもスクリプトを実行できるようにします。 これについては、次のセクションで説明します。

Web ワーカーの詳細情報

サービスワーカー

開発者として制御できないことがいくつかありますが、そのうちの XNUMX つはユーザーのネットワーク接続です。 ユーザーが接続するネットワークは、それが何であるかです。 アプリを最適化するために最善を尽くすだけで、たまたま使用される接続で最高のパフォーマンスを発揮します。

Service Worker は、アプリのパフォーマンスを段階的に強化するためにできることの XNUMX つです。 Service Worker は、アプリ、ブラウザー、およびサーバーの間に位置し、別のスレッドでバックグラウンドで実行される安全な接続を提供します。これは、ご想像のとおり、Web Workers のおかげです。 前のセクションで学んだように、サービス ワーカーは XNUMX 種類の Web ワーカーの XNUMX つです。

では、アプリとユーザーのブラウザーの間に Service Worker を配置する必要があるのはなぜでしょうか? 繰り返しますが、ユーザーのネットワーク接続を制御することはできません。 なんらかの理由で接続が切断されたとします。 これにより、ブラウザとサーバー間の通信が中断され、データがやり取りされなくなります。 Service Worker は、ネットワーク接続が失われた後でも、要求をインターセプトしてタスクを実行できる非同期プロキシとして機能し、接続を維持します。

これは、よく言われることの主な原因です。 「オフラインファースト」開発. ネットワークではなくローカル キャッシュにアセットを保存し、ユーザーがオフラインになった場合に重要な情報を提供し、ユーザーが必要なときに準備できるようにプリフェッチし、ネットワーク エラーに対応してフォールバックを提供できます。 それらは完全に非同期ですが、Web ソケットとは異なり、独自のスレッドで実行されるため、DOM にはアクセスできません。

Service Worker について知っておくべきもう XNUMX つの重要な点は、アプリからのすべてのリクエストとレスポンスをインターセプトすることです。 そのため、いくつかのセキュリティへの影響があり、最も顕著なのは、同一オリジン ポリシーに従っていることです。 つまり、CDN またはサードパーティ サービスから Service Worker を実行しないということです。 また、安全な HTTPS 接続も必要です。つまり、実行するには SSL 証明書が必要です。

Service Worker の詳細情報

包み込む

これは、Web ソケット、Web ワーカー、およびサービス ワーカーの相違点 (および類似点) の超高レベルの説明です。 繰り返しますが、用語と概念は互いに混同されるほど似ていますが、うまくいけば、これらを区別する方法についてのより良いアイデアが得られます.

クイック リファレンス テーブルから始めました。 これは同じものですが、より厚い比較を描画するためにわずかに拡大されています.

• コインスマート。 ヨーロッパで最高のビットコインと暗号通貨取引所。ここをクリック
• Platoblockchain。 Web3メタバースインテリジェンス。 知識の増幅。 こちらからアクセスしてください。
• 情報源： https://css-tricks.com/the-difference-between-web-sockets-web-workers-and-service-workers/