Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
リアルタイム通信を知る
Search
kosuke hino
October 10, 2024
Technology
0
96
リアルタイム通信を知る
リアルタイム通信を知る(勢いでスライド作ったせいでデザインがったがったやすまん)
kosuke hino
October 10, 2024
Tweet
Share
More Decks by kosuke hino
See All by kosuke hino
NotebookLMと散歩
kosukehino
0
16
hinoはhonoを知りたい
kosukehino
0
79
ポモドーロテクニック
kosukehino
0
37
誤差を知ろう
kosukehino
0
69
AtCoder Heuristic Contestを知っているか?
kosukehino
0
100
AIでスライド爆速生成!
kosukehino
0
130
Other Decks in Technology
See All in Technology
DroidKaigi 2025 Androidエンジニアとしてのキャリア
mhidaka
2
300
react-callを使ってダイヤログをいろんなとこで再利用しよう!
shinaps
1
240
Aurora DSQLはサーバーレスアーキテクチャの常識を変えるのか
iwatatomoya
1
1k
RSCの時代にReactとフレームワークの境界を探る
uhyo
10
3.4k
20250910_障害注入から効率的復旧へ_カオスエンジニアリング_生成AIで考えるAWS障害対応.pdf
sh_fk2
3
260
共有と分離 - Compose Multiplatform "本番導入" の設計指針
error96num
2
570
スマートファクトリーの第一歩 〜AWSマネージドサービスで 実現する予知保全と生成AI活用まで
ganota
2
220
Autonomous Database - Dedicated 技術詳細 / adb-d_technical_detail_jp
oracle4engineer
PRO
4
10k
Snowflake Intelligenceにはこうやって立ち向かう!クラシルが考えるAI Readyなデータ基盤と活用のためのDataOps
gappy50
0
240
OCI Oracle Database Services新機能アップデート(2025/06-2025/08)
oracle4engineer
PRO
0
150
会社紹介資料 / Sansan Company Profile
sansan33
PRO
6
380k
バイブスに「型」を!Kent Beckに学ぶ、AI時代のテスト駆動開発
amixedcolor
2
560
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
45
7.7k
How GitHub (no longer) Works
holman
315
140k
Speed Design
sergeychernyshev
32
1.1k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
9
810
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Agile that works and the tools we love
rasmusluckow
330
21k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
139
34k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.9k
Bash Introduction
62gerente
615
210k
Why Our Code Smells
bkeepers
PRO
339
57k
GraphQLとの向き合い方2022年版
quramy
49
14k
Transcript
リアルタイム通信を知る 2024/10/11 檜野浩輔
はじめに 最近のタスクの中でリアルタイム通信を考 える場面があったのと、前職で比較検討み たいな事をして技術選定したなーというの を思い出し、改めて自分の整理も兼ねて LT会の題材にしました。
ポーリング(主にajax) 定期的にクライアントからサーバーにHTTPでリク エストを送りレスポンスの内容に応じて定期的に 画面を更新する手法 メリット JSで定期的にリクエストを送るだけなので非常に 単純で実装が簡単です 最新情報がなくてもリクエストしてしまうのでク ライアント側は通信量が増え、サーバー側は負荷 が増えてしまいます
デメリット リアルタイム性はリクエストを送る間隔やレスポ ンスの速さに依存し本当のリアルタイムを求める には限界があります
ロングポーリング(comet) クライアントからサーバーにHTTPでリクエストを 送り更新があるまでサーバー側でリクエストを保 持し更新があった際にレスポンスする手法 メリット ポーリングであった更新がないのにリクエストを 送らないといけないという問題を解決出来る ロングポーリング用の通信を貼る事になるので短 時間で更新が複数回あると通信を張り直すまで更 新出来ず遅延する場合がある
デメリット ポーリングよりはリクエストは減るがそれでも、 更新の度にリクエストを送る必要がある
ServerSentEvents(SSE) ロングポーリングのデメリットを改善しレスポン スがあっても通信を張り直すことはせずその後も 通信を使い続ける手法 メリット ロングポーリングであった通信を張り直す必要が あった課題を解決し一度通信を張ったらそれを使 い続けることが出来る 片方向通信となりSSE内でクライアントからサー バーへpushする事が出来ない
デメリット HTTP通信を張り続けるのでCPU使用率に影響を与 える(詳しくはわからん)
WebSocket 双方向通信を可能とし専用の通信プロトコルを使 用する事により負荷を軽減する手法 メリット SSEと違い双方向通信が可能で、専用のプロコトル によりCPUへの負荷が軽い HTTPとは別のプロトコルになるので専用の実装が 必要になる デメリット HTTPよりヘッダーの容量がかなり少なく何回も更
新するような画面では通信量を削減する事が出来 る。特にボディが小さい場合に効果的
WebRTC P2Pで双方向通信を行う手法 メリット サーバーを介さないので、サーバーの負荷を軽減 できたりよりリアルタイムな通信を行えたりする サーバーを介さないのでサーバーに過去データを 保存しておく事が出来ない デメリット 特に通信容量が多いカメラ映像等のメディアをリ アルタイムで送受信する際に使われる(Zoomとか
Meetsとかとか)
WebRTC SFU WebRTCのP2Pの間にSFUサーバーを置くことで サーバーを介したWebRTCを可能にする手法 メリット サーバーを介すので過去ログを簡単に残す事が可 能 檜野もよく分かっていないしネットワーク等ミド ルウェアの知識がないと理解して使用する事が出 来ない
デメリット メディアの受信者が多くなった際にも送信側は サーバーにメディアを送るだけなので、ユーザー側 の負担が一定かつ軽くなる
おまけ + 紹介 https://x.com/voluntas/ status/1785608316087136304 上記のURLよりWebRTC SFUを使用した ソフトを提供している時雨堂さんが試され た1080pでの低遅延配信の様子が見れる 個人的に1080pでクライアントの負荷も少
なくリアルタイムで配信出来ている姿にす げーと思った
おまけ + 紹介 定期的に勉強会をやってくれている https://x.com/voluntas/ status/1838933732939673840