Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
リアルタイム通信を知る
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
kosuke hino
October 10, 2024
Technology
110
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
リアルタイム通信を知る
リアルタイム通信を知る(勢いでスライド作ったせいでデザインがったがったやすまん)
kosuke hino
October 10, 2024
More Decks by kosuke hino
See All by kosuke hino
NotebookLMと散歩
kosukehino
0
33
hinoはhonoを知りたい
kosukehino
0
99
ポモドーロテクニック
kosukehino
0
49
誤差を知ろう
kosukehino
0
81
AtCoder Heuristic Contestを知っているか?
kosukehino
0
120
AIでスライド爆速生成!
kosukehino
0
150
Other Decks in Technology
See All in Technology
Code4Lib JAPANカンファレンス2026 開会挨拶 / Code4Lib JAPAN Conference 2026: Opening Remarks
ykiyota
0
310
Amazon S3 Tablesに全部任せてみた結果——コンパクション/スナップショット管理は本当に手放せるか
shigeruoda
1
460
リージョンの壁を越える、 ちょっと変わったAWSサービスの話
falken
PRO
1
300
DEFCON34-Write-up_HYCu-MYCu
daikiokazaki
0
140
20260912_スクフェス三河
kgnkhkr
0
250
「重なり」は迎える側がつくる ― 人もAIエージェントも歓迎するプロダクトエンジニアリング ―
go0517go
PRO
0
280
クロスボーダーM&AのValue Upを支えるプロダクト開発。日米チームのハブになったプロダクトエンジニアの実践 / Product Engineering Conference 2026
genda
0
110
AI時代のAPI品質を支えるガードレール / API Guardrails for API quality in the AI era
yokawasa
1
210
推論の観測、できていますか? 〜 Google Cloud Gemini Enterprise Agent Platformで 3つの Gemini モデルを実測して踏んだ、評価の罠 〜
shukob
PRO
0
180
2026-09-11 【Snowflake World Tour Tokyo 2026】Snowflakeを起点に、AI Agentが自律稼働し続ける未来へ / Driving AI Agents with Snowflake
civitaspo
0
270
多層防御と最⼩権限で実現する、安全なAIエージェント設計パターン
lycorptech_jp
PRO
1
250
OpenTelemetryのメトリクスをCloudWatchに送ってPromQLで見てみた
ota1022
0
120
Featured
See All Featured
Data-driven link building: lessons from a $708K investment (BrightonSEO talk)
szymonslowik
1
1.3k
How to Build an AI Search Optimization Roadmap - Criteria and Steps to Take #SEOIRL
aleyda
1
2.2k
Groundhog Day: Seeking Process in Gaming for Health
codingconduct
0
340
The State of eCommerce SEO: How to Win in Today's Products SERPs - #SEOweek
aleyda
2
11k
DevOps and Value Stream Thinking: Enabling flow, efficiency and business value
helenjbeal
1
380
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.8k
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
4
3k
Building the Perfect Custom Keyboard
takai
2
870
The Art of Programming - Codeland 2020
erikaheidi
57
14k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
Between Models and Reality
mayunak
4
450
The Organizational Zoo: Understanding Human Behavior Agility Through Metaphoric Constructive Conversations (based on the works of Arthur Shelley, Ph.D)
kimpetersen
PRO
0
440
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