LT_04_Server-Client_HTTPSSEWebSocket
>100 Views
August 01, 25
スライド概要
関連スライド
各ページのテキスト
サーバークライアント通信技術解説 〜HTTP/SSE/WebSocket〜 発表者：yamapan Genspark で作成
目次 1 サーバークライアント通信の基本 2 HTTP通信の仕組み 3 ポート開放の意味 4 SSEとは・活用事例 ※本発表では各通信技術の基本から応用まで、実務に役立つポイントを解説します 5 WebSocketとは・活用事例 6 技術比較と使い分け 7 最新動向・今後の展望 8 実務活用ポイント・まとめ Genspark で作成
サーバークライアント通信とは インターネット上でのデータ通信の基本構造です。サーバとクライア ントという2つの役割が連携することで、Webサイト表示やアプリの 動作などが実現されます。 サーバ：情報やサービスを提供する側。常に稼働し、クライアン トからのリクエストを待機 クライアント：情報やサービスを利用する側。必要に応じてサー バにリクエストを送信 通信の流れ：クライアントからのリクエスト → サーバからのレス ポンス リクエスト クライアント レスポンス サーバ 図：サーバークライアント通信の基本的な流れ 専門用語解説 サーバ：コンピュータネットワークにおいて、他のコンピュータにサービス クライアント：ネットワーク上でサーバからサービスを受ける側のコンピュ を提供するコンピュータやソフトウェア ータやソフトウェア ※実際のインターネット通信では、複数のクライアントが同時に一つのサーバにアクセスすることが一般的です Genspark で作成
ポート番号の役割 ポート番号は、1台のサーバで複数のアプリケーションを同時に稼働 させ、適切に通信を振り分けるための「仕分け番号」です。 役割：同一IPアドレスで複数のサービスを区別するための識別子 範囲：0〜65535の整数値（全部で65,536個） 種類：Well-Known Ports (0-1023), 登録済みポート (1024-49151), 動的ポート (49152-65535) 代表的なWell-Knownポート HTTP: 80番 Webサイト閲覧 SSH: 22番 セキュアシェル Webブラウザ 80 Webサーバ メールクライアント 443 HTTPS 22 SSH 53 DNS SSHクライアント サーバ 192.168.1.10 HTTPS: 443番 暗号化Web通信 DNS: 53番 名前解決サービス 図：同一サーバ上の複数アプリケーションとポート番号の関係 専門用語解説 ポート番号：コンピュータネットワークにおいて、特定のアプリケーション Well-Known Ports：0〜1023番のポート。主要なインターネットサービス用 やサービスを識別するための数値。IPアドレスと組み合わせて使用される に予約されており、通常は特権プロセスのみが使用可能 ※実際のサーバでは、不要なポートは安全のため閉じておくことがセキュリティ上重要です Genspark で作成
ネットワークとポート開放の仕組み インターネットと自宅LANをつなぐルータは、限られたグローバルIP アドレスを複数デバイスで共有するための重要な役割を果たします。 グローバルIP：インターネット上で一意に特定できる住所。各家 庭・会社に通常1つだけ割り当て プライベートIP：LAN内でのみ有効な住所（例：192.168.x.x）。 外部からは直接アクセス不可 NAPT/NAT：グローバルIPとプライベートIPを変換し、複数デバイ スの通信を可能にする仕組み ポート開放：外部からLAN内の特定デバイスに通信を許可する設 定。サーバ公開に必須 インターネット (WAN) 203.0.113.1 グローバルIP ポート開放 ルータ NAPT機能 自宅LAN (192.168.1.x) PC 192.168.1.2 サーバ 192.168.1.3 スマホ 192.168.1.4 図：自宅LAN/ルータ経由での通信とポート開放の仕組み 専門用語解説 NAPT（Network Address Port Translation）：1つのグローバルIPアドレ ポート開放/ポートフォワーディング：外部からのリクエストを内部の特定デ スを複数のプライベートIPアドレスで共有するための技術。送信元/宛先IPと バイスに転送する設定。ルータでグローバルIP:ポート番号→プライベートIP: ポート番号の組み合わせを変換する ポート番号のマッピングを行う ※セキュリティリスクを考慮し、必要最小限のポートのみを開放することが推奨されます Genspark で作成
HTTP通信の基本 HTTPは「HyperText Transfer Protocol」の略で、Webブラウザとサ ーバー間でデータをやり取りするための通信規約です。クライアント からのリクエストとサーバーからのレスポンスのセットで構成されま す。 HTTPリクエスト クライアント HTTPレスポンス 主要なHTTPメソッド GET：情報の取得。URLにパラメータを付与してサーバーにリクエスト。 図：HTTP通信の基本的な流れ POST：情報の送信。データはボディに格納され、サーバーに送信。 通信の流れ 1. クライアントがHTTPリクエスト送信 2. サーバーがリクエスト処理 3. サーバーがHTTPレスポンス送信 4. クライアントがレスポンス処理 サーバー スタートライン HTTPメッセージの構造 GET /index.html HTTP/1.1 ヘッダー Host: example.com Accept: text/html User-Agent: Mozilla/5.0 ... ボディ（省略可能） name=value&message=hello 専門用語解説 HTTP：WebサーバとクライアントがHTML文書などのハイパーテキストをや ステートレス：HTTPは各リクエスト/レスポンスが独立しており、前後の通 り取りするための通信プロトコル 信内容を記憶しない特性 ※HTTPはWebブラウザだけでなく、APIを介したアプリケーション間通信でも広く使用されています Genspark で作成
HTTP通信とポート開放の関係 実務的な注意点 不要なポートは開放しない（セキュリティリスク） WAF（Webアプリケーションファイアウォール）の併用を検討 社内/テスト環境では非標準ポート（8080等）も活用 クラウド環境では「セキュリティグループ」で制御 インターネット ルーター 80/443 ルーォウアイァフ サーバーをインターネットに公開するには、特定のポートを「開放」 する必要があります。特にHTTP通信では、標準で80番ポートが使用 されます。 80番ポート：WebサーバーがHTTP通信を受け付けるための標準 ポート 443番ポート：HTTPS（暗号化通信）用の標準ポート ポート開放の仕組み：ルーターやファイアウォールの設定で、外 部からの接続を特定のサーバーに転送 その他ポート Webサーバー サーバーのポート 80 443 22 図：HTTP通信のためのポート開放とファイアウォールの関係 専門用語解説 ポート開放：ルーターやファイアウォールの設定で、特定のポート番号宛て ファイアウォール：不正アクセスやサイバー攻撃からネットワークを守るた の通信を内部ネットワークの特定サーバーに転送すること めに、通信を監視・制御する仕組み ※クラウド環境では「セキュリティグループ」や「ファイアウォールルール」で同様の制御を行います Genspark で作成
Server-Sent Events（SSE）の概要 SSE（Server-Sent Events）とは、サーバーからクライアントへの一 方向のリアルタイムデータ配信を実現する技術です。HTTP接続を利 用し、サーバーから継続的にデータを送信できます。 一方向リアルタイム通信の特徴 HTTPプロトコルベースで実装が簡単（標準のJavaScript APIが利用可能） 一度接続するとサーバーから自動的にデータを受信（ポーリング不要） 接続が切れた場合の自動再接続機能を標準サポート イベントID管理によるメッセージの追跡と復旧が可能 テキストベースでファイアウォールフレンドリー HTTP vs SSE vs WebSocket 比較 HTTP（従来のポーリング） リクエスト（データある？） クライアント 繰り返しの往復通信 サーバー SSE（Server-Sent Events） 接続要求（1回のみ） クライアント WebSocket サーバーからの継続的なデータ送信 サーバー 双方向のリアルタイム通信 クライアント サーバー ストリーミング通信の概念 図：各通信方式の特徴比較 専門用語解説 ストリーミング：データを断片的に継続して送信 EventSource API：ブラウザ標準のJavaScript する通信方式。一度にまとめて送受信するのでは API。SSEのクライアント側実装に使用される なく、少しずつデータを流す 一方向通信：片方向のみのデータ送信を行う通信 方式。SSEはサーバー→クライアントのみ データを一度にまとめて送るのではなく、小さな単位で継続的に送信する通信方 法。SSEでは、サーバーがチャンク（小さな断片）単位でデータを送り続け、クラ イアントはそれをリアルタイムで受信・処理します。 ※SSEの実用例：ChatGPTの文章生成表示、株価・天気などのリアルタイム更新、通知システムなど Genspark で作成
SSEの仕組みと実装例
Server-Sent Events（SSE）は、サーバーからクライアントへの一方
向ストリーミングを実現する技術です。
通信フロー：クライアントが接続を確立し、サーバーが継続的に
データを送信
接続維持：一度の接続で複数のイベントを受信可能
データ形式：テキストベースで data:, event:, id:, retry: フ
ィールドを持つ
EventSource API (クライアント側実装)
オブジェクトの作成
// EventSource
const evtSource = new EventSource('/events');
①接続リクエスト
②接続確立
ブラウザ
サーバーサイド実装例 (Node.js)
app.get('/events', (req, res) => {
// SSE
res.setHeader('Content-Type', 'text/event-stream');
res.setHeader('Cache-Control', 'no-cache');
res.setHeader('Connection', 'keep-alive');
接続のためのヘッダー設定
イベント受信時の処理
受信データ
イベント送信
エラー処理
//
setInterval(() => {
res.write(`id: ${Date.now()}\n`);
res.write(`data: ${JSON.stringify({time: new Date()})}\n\n`);
res.flush(); //
}, 1000);
});
//
evtSource.onerror = () => {
console.error('
');
};
接続エラー
✓
Chrome
サーバ
図：Server-Sent Eventsの通信フロー
//
evtSource.onmessage = (event) => {
console.log('
:', event.data);
};
主要ブラウザのSSEサポート状況
③イベント送信
データをすぐに送信
✓
Firefox
✓
Safari
✓
Edge
✓
Opera
専門用語解説
EventSource：SSEの接続を管理するJavaScript API。再接続ロジックが組み イベントストリーム：サーバーからクライアントへの継続的なデータ配信の
込まれている
流れ
※SSEはHTTP上で動作するため、既存のロードバランサーやプロキシと互換性が高い
Genspark で作成
SSE活用ユースケース Server-Sent Eventsは、サーバーからクライアントへの一方向データ 送信に最適なため、様々なリアルタイム用途で活用されています。 リアルタイム通知 新着メッセージ、システム警告、アクティビティ更新など、ユーザーに即 時通知が必要なケース ライブログ・ダッシュボード 運用ログ、スポーツ実況、イベントの状況更新など、リアルタイムに情 報を表示するケース ChatGPTのようなリアルタイム文字生成 質問：Webソケットとは何ですか？ SSEを使うと文字が順次表示される体験を実現できます 金融・株価データ配信 市場価格、取引情報、経済指標などの継続的な更新を表示する金融アプ リケーション WebSocketは、サーバーとクライアント間の双方 向通信を可能にするプロトコルです。HTTP接続を 介して開始され、その後は独立した双方向チャネル として機能します。 リアルタイム株価データ AIテキスト生成 ChatGPTのような文字列生成AIのリアルタイム表示（タイピング中のよ うな体験提供） 技術選択時のポイント 単方向通信が十分な場合、WebSocketより軽量なSSEが適切 標準APIのサポートがある（EventSource）ため実装が容易 再接続機能内蔵で、ネットワーク切断時に自動で復帰 09:00 10:30 12:00 13:30 SSEで最新の株価データをリアルタイムに配信 15:00 HTTP標準のため、ファイアウォールやプロキシと互換性が高い 同時接続数に注意（サーバー側リソース管理が必要） IE非対応だが、polyfillライブラリで解決可能 ※SSEはリアルタイム性・実装の簡易さ・HTTPとの互換性で優れていますが、クライアントからサーバーへの通信が必要な場合は他の技術と組み合わせる必要があります。 Genspark で作成
WebSocketの概要 WebSocketとは、クライアントとサーバー間で双方向リアルタイム 通信を可能にするプロトコルです。一度接続を確立すると、継続的に データをやり取りできます。 双方向通信：サーバーからクライアントへのプッシュ配信が可能 で、リクエスト/レスポンスの繰り返しが不要 常時接続：接続を維持したまま必要な時に即座にデータ送受信 低オーバーヘッド：HTTPヘッダーが少なく、通信効率が高い リアルタイム性：遅延が少なく、即時性が求められるアプリに最 適 HTTP通信 リクエスト クライアント レスポンス サーバー (接続は各リクエスト後に終了) WebSocket通信 HTTP接続からWebSocketへ切替 クライアント 双方向リアルタイム通信 (単一接続を維持したまま継続的に通信可能) 低レイテンシ・高効率 サーバー 図：HTTPとWebSocketの通信パターン比較 専門用語解説 WebSocketプロトコル：HTTPをベースにした拡張プロトコルで、TCP接続 双方向通信：クライアントとサーバーの両方が、いつでもデータを送信でき 上で全二重通信を実現。RFC 6455で標準化されています。 る通信方式。従来のHTTP通信では、常にクライアントからリクエストが必要 でした。 ※WebSocketは「ws://」または暗号化された「wss://」（WebSocket Secure）のURLスキームを使用します Genspark で作成
WebSocketの仕組みと実装例
WebSocketハンドシェイク
クライアントサイド実装例
接続を開始
// WebSocket
const ws = new WebSocket("ws://example.com/socket");
クライアント
サーバー
1. HTTP接続要求 (Upgrade: websocket)
ws.send("Hello Server");
});
2. 接続承認 (101 Switching Protocols)
//
メ セ ジ受信時のイベント
サーバーサイド実装例（Node.js）
3. WebSocket通信確立
通信フロー
クライアント
接続確立時のイベント
接続確立
//
ws.addEventListener("open", () => {
console.log("
!");
const WebSocket = require('ws');
メッセージ送信
サーバー
サーバーを作成
// WebSocket
const wss = new WebSocket.Server({
port: 8080
});
//
メッセージ受信
接続イベント
wss.on('connection', function connection(ws) {
l
l
('
クライアント接続')
接続終了
主要WebSocket API
new WebSocket(url)：接続を作成
ws.send(data)：メッセージ送信
ws.onmessage：メッセージ受信時のイベント
ws.onopen：接続確立時のイベント
※WebSocketプロトコルは、RFC 6455で規定されており、ほとんどの主要なブラウザでサポートされています
ws.onclose：接続終了時のイベント
ws.close()：接続を閉じる
Genspark で作成
WebSocket活用ユースケース
WebSocketは双方向リアルタイム通信を可能にする技術として、様々
な分野で活用されています。特に「即時性」「双方向性」「継続的な接
続」が求められる場面で真価を発揮します。
代表的なユースケース
チャットアプリケーション：メッセージの即時配信、既読状態の同期
オンラインゲーム：プレイヤー位置の同期、リアルタイム対戦
コラボレーションツール：複数人での同時編集、カーソル位置共有
IoTデバイス制御：センサーデータのリアルタイム監視、遠隔操作
金融取引プラットフォーム：株価・為替レートのリアルタイム配信
実運用時の注意点
⚠️ 接続維持コスト：多数の接続を維持するサーバリソースの確保
⚠️ 再接続処理：ネットワーク切断時の自動再接続と状態回復の実装
⚠️ スケーラビリティ：負荷分散、水平スケーリングの設計
⚠️ プロキシ対応：一部の環境でWebSocketがブロックされる可能性
チャットアプリ
オンラインゲーム
リアルタイムのメッセージ配信と既
読状態の同期を実現。
プレイヤー位置、ゲーム状態をミリ
秒単位で同期。
socket.on('message', (data) => {
displayMessage(data);
sendReadReceipt(data.id);
});
socket.emit('move', {
x: playerX,
y: playerY,
action: 'running'
});
コラボレーション
IoTデバイス制御
同時編集、カーソル共有でシームレ
スな共同作業。
センサーデータのリアルタイム監視
と遠隔操作。
socket.on('cursor-move', (data) => {
showUserCursor(data.user, data.pos);
});
socket.on('sensor-update', (data) => {
updateDashboard(data.temp, data.humid);
});
技術選定のポイント
WebSocketに適した場面：
低遅延が重要なリアルタイム通信
頻繁なデータ更新
サーバー→クライアント方向の即時
通知
他の技術が適する場面：
更新頻度が低い場合（ポーリング）
一方向通知のみ必要な場合（SSE）
P2Pでの通信が必要な場合
（WebRTC）
実装事例：Socket.IO
WebSocketを簡単に扱えるJavaScriptライブラリ。自動再接続やフォールバック機能、ルーム機能など実用的な機能を提供し、実務で広く利用されています。
サーバー側
// クライアント側
npm install socket.io
//
npm install socket.io-client
※WebSocketはHTTP/2、HTTP/3との併用時に注意が必要です。状況によってはServer-Sent EventsやWebTransportも検討しましょう。
Genspark で作成
HTTP・SSE・WebSocketの技術比較 比較項目 HTTP クライアント→サーバー (リクエスト/レスポンス) 短期 (リクエストごとに切断) 高め (毎回接続確立が必要) 簡単 (標準的なWeb開発) 一般的なWebサイト CRUD操作 RESTful API Server-Sent Events サーバー→クライアント (一方向) 長期 (サーバーからの更新を待機) 低め (接続確立済みで更新) やや易しい (EventSourceオブジェクト) 通知、ライブログ 株価・スコア更新 AI文章生成 トランスポート層 TCP TCP バイナリ対応 対応 (ファイル送受信など) テキストのみ (JSONなど) 通信方向 接続維持 レイテンシ 実装難易度 適用場面 技術選択の指針 HTTP Server-Sent Events 定期的な更新（数分単位） RESTful設計のAPI 単純なCRUD操作 頻繁な双方向通信が必要 低遅延が重要 複数ユーザー間のリアルタイム連携 サーバーからの更新通知 HTTP リアルタイム双方向通信 SSE 単純 → 複雑 双方向 (全二重通信) 長期 (明示的に閉じるまで維持) 最低 (オーバーヘッド最小) やや複雑 (接続管理、エラー処理) チャット、オンラインゲーム コラボレーションツール IoTリアルタイム制御 TCP (WebTransportはUDP) 対応 (画像・音声・動画など) WebSocket サーバーからの一方向通知 クライアント→サーバー通信が少ない テキストベースのリアルタイム更新 データの即時取得・更新 WebSocket WebSocket リアルタイム性 UP ※技術選定の際は、要件（リアルタイム性、双方向性、接続数）とインフラ環境（プロキシ、ファイアウォール）を考慮しましょう Genspark で作成
最新リアルタイム通信技術動向 インターネットでのリアルタイム通信技術は2025年も進化し続けています。 HTTP/3、QUIC、WebTransportなどの新技術により、より高速・低遅延・柔軟な通信が実現されています。 QUIC（UDPベースの高速通信プロトコル） HTTP/3（QUICベース） Webアプリ MOQT WebTransport リアルタイムゲーム IoTデバイス 低遅延・高信頼性の基盤技術 QUIC QUIC & HTTP/3 UDPベースで接続確立が高速（1-RTTのみ） HoLブロッキング問題を解決、複数ストリームが独立 2024年現在、Webサイトの約26%で採用済み 暗号化が標準で組み込まれ、プライバシー向上 WT WebTransport QUICベースの双方向低遅延通信API データグラム/ストリームの両方に対応 WebSocketより低遅延で信頼性制御が柔軟 リアルタイムゲーム・クラウドゲーミングに最適 MoQT Media over QUIC Transport リアルタイム映像・音声通信のための新プロトコル WebRTCの課題を解決する次世代規格 2025年に標準化が進行中、実装が増加 導入 実用化の現状（2025年） 大手クラウド事業者がHTTP/3を標準サポート WebTransportがゲーム業界で採用拡大 多くのCDNがHTTP/3によるパフォーマンス向上を提供 モバイルアプリでのQUIC採用が増加傾向 専門用語解説 QUIC：Googleが開発したUDPベースの転送プロトコル。TCPと違い接続確 HoLブロッキング：Head-of-Line Blocking。先頭のデータが遅延すると後続 立が高速で、暗号化が標準組込み のデータも遅延する問題 Genspark で作成
今後の展望と技術選定のヒント リアルタイム通信の未来予測 低遅延化の追求：WebTransportやQUICベースの技術が主流に HTTP/3の普及：TCPからUDPへの移行が進み、HoLブロッキング問題が解 消 エッジコンピューティングとの融合：リアルタイム処理の分散化 AIとの連携：生成AIなどのストリーミング出力がSSEで標準化 WebRTCの進化：P2P通信の簡素化と高機能化 技術選択時の判断基準 リアルタイム性の要件：許容遅延に応じた技術選定 通信方向：単方向 vs 双方向の必要性 スケーラビリティ：同時接続数と負荷分散の考慮 互換性：サポートブラウザやレガシー環境の制約 開発難易度：チームのスキルセットと学習コスト 運用コスト：サーバリソース消費と保守性 ユースケース別推奨技術 ユースケース 推奨技術 理由 双方向メッセージング、即時応答 WebSocket チャットアプリ 性 SSE 通知システム サーバーからの一方向通知に最適 ドキュメント共同 WebSocket 変更のリアルタイム反映、衝突解 編集 決 ストリーミング出力に最適、実装 AIレスポンス生成 SSE が容易 株価/仮想通貨表示 SSE 高頻度の一方向データ配信 オンラインゲーム WebTransport 低遅延、UDP活用、信頼性調整可 能 ビデオ会議 WebRTC P2Pメディア送受信、NAT対応 HTTP/Polling 低頻度更新、実装容易、互換性高 簡易IoT監視 トレンド: WebTransport/HTTP3への移行が加速（2025年） 専門用語解説 HoLブロッキング：Head of Line Blocking。パケット損失時に後続のデータ WebTransport：HTTP/3上に構築された新しい低遅延双方向通信API。信頼 転送がブロックされる問題。HTTP/3とQUICはこれを解消 性と速度のトレードオフを調整可能 ※技術選定は要件だけでなく、チームの技術力や運用体制も考慮して総合的に判断することが重要です Genspark で作成
実務活用ポイント（Tips） 通信技術を実務で活用する際に知っておくべき重要なポイントと対策について解説します。 セキュリティ対策 WebSocketは必ずwss://（TLS暗号化）を使用 SSEでもhttps://を使用し通信を暗号化 接続時に認証トークンの検証を実装 WebSocketでのOrigin検証による不正接続対策 パフォーマンス最適化 WebSocketメッセージのバイナリ形式活用（JSON対比で軽量） SSE通信では送信データ圧縮を検討 WebSocketのPingフレーム間隔を適切に設定（30秒前後） データを一括送信（バッチ化）して通信回数を削減 スケーラビリティ WebSocketサーバーはロードバランサー配下で構成 複数サーバー間でRedis Pub/Subなどを活用した連携 同時接続数増加に備えたオートスケール構成の検討 サーバーリソース（メモリ/CPU）に合わせた接続数上限設定 よくある落とし穴と対策 WebSocket接続の切断検知と自動再接続の実装 企業ネットワークによるプロキシ・ファイアウォール対策として標準ポ ート（443）の利用 バックプレッシャー対策：クライアントの処理能力を超えるメッセージ 送信を抑制 ブラウザによる同時接続数制限（HTTP/1.1）への対応 実務ポイント 通信技術の選択では、要件の優先順位（リアルタイム性・信頼性・運用コスト）を明確にすることが重要です。環境（社内/社外）や利用端末（PC/モバイ ル/IoT）に合わせた最適解を検討しましょう。 Genspark で作成
まとめと今後の学習のヒント 重要ポイントの振り返り 次に学ぶべきキーワード HTTP通信：リクエスト・レスポンス型の標準的通信 ポート開放：外部からサーバへのアクセスに必要な設定 SSE：サーバからクライアントへの一方向リアルタイム通信 WebSocket：双方向リアルタイム通信の実現 技術選択：ユースケースに応じた適切な選択が重要 おすすめ学習リソース Mozilla Developer Network (MDN) - Web API ドキュメント O'Reilly - 「Webソケット」「SSE実践ガイド」 Udemy - 「リアルタイムWebアプリケーション構築」 GitHub - Socket.IO、ws、EventSourceライブラリ WebTransport HTTP/3 QUIC Socket.IO WebRTC GraphQL Subscriptions gRPC SockJS nginx Proxy WebSocket Security Redis Pub/Sub Kafka Streams 実務での活用ポイント HTTPは一般的なWeb通信に最適 SSEは更新通知・ログストリーミングに最適 WebSocketはチャット・リアルタイム操作に最適 技術選定はリアルタイム性・双方向性の要件で判断 常にフォールバックとエラー処理を考慮 ご清聴ありがとうございました 質問等ございましたらお気軽にどうぞ Genspark で作成