はじめに
Webブラウザでのリアルタイム通信技術について調査した。
TCPとUDPの長所短所については知っていることを前提とする。
軽い調査なので、「らしい」という言葉遣いが多い。
筆者環境の結論
2024年時点ではWebSocket(HTTP/2)を第一候補とする。
2～5年くらいに再検討するとWebTransportが第一候補になるかもしれない。
HTTPバージョンの歴史
1997年～ HTTP/1.1
2015年～ HTTP/2(≒SPDY対応)
2022年～ HTTP/3(≒TLS1.3とQuic対応)
※1.0以前は省略
双方向通信（サーバー ←→ Webブラウザ）
双方向通信ができるのであって双方向通信しなければならないわけではない。
そのため、これらを一方向通信として使用するのもあり。
WebSocket(HTTP/2)
TCP
筆者環境においては双方向通信を採用する場合、このWebSocketが最有力か。
理由：HTTP/2の安定性、TCPの信頼性が必要であるため。また、歴史が10年以上あるため安定している。
WebSocket(HTTP/3)
それっぽい情報は見つかるが、実現可能なのかはよくわからなかった。
これを調査して採用するくらいなら、WebTransport採用を目指したほうがよさそう。
WebTransport
HTTP/3、QUIC、UDP
2024年時点ではブラウザを用いたリアルタイム双方向通信では最新技術。
UDPであるが、QUICで信頼性を担保しているためTCP程度の信頼性はあるらしい。
つまり謳い文句通りであるなら、UDPの速度とTCP相当の信頼性のいいとこどりができるということ。
登場してからあまり時間がたっていないため、採用する場合は自前でちゃんと検証したほうがよさそう。そのコストを払ってでもメリットを享受できるなら有力候補。
筆者環境では様子見としておく。
WebRTC
P2P通信。P2Pなのでこの記事の対象外かもしれないが記録に残しておく。
実装が複雑で使いまわしにくいらしい。
小規模ならサーバー-クライアントっぽく実装できそうだが、大規模スケールは苦しいらしい。
一方向通信（サーバー → Webブラウザ）
Server Sent Event
ChatGPTの回答がリアルタイムでヌルヌル表示されるのはこれを使っているらしい。つまり大手が採用している。
ちゃんとした実装の一方向通信を採用する場合は、最有力候補。
HTTP/2 Server Push
最新版Chromeではすでに廃止済みであるため新規案件では使うな！
javascriptでタイマー＋リロード
タイマーでページリロードをして自動で再取得する。
更新間隔が数秒以上でよく、通信の無駄を許容できるならあり。
余計なものを入れなくていいので単純。
この記事の趣旨とは少し違うが、筆者は昔の案件でこれを実装したことがあるので記録に残しておく。
Polling / Long Polling
javascriptで実装できるらしい。
詳細は未調査。
参考