発表日：2015年7月18日 AITC女子会 イベント名：最新技術を学ぶ～Web編～ タイトル：Ajax/Comet/WebSocket/MQTT 概要紹介 発表者：アドソル日進株式会社 荒本道隆 案内URL：http://aitc.jp/events/20150718-Women/info_v2.html

1. Ajax / Comet / WebSocket / MQTT
概要紹介
2015年7月18日
先端IT活用推進コンソーシアム
クラウド・テクノロジー活用部会
リーダー 荒本道隆

2. 最初に
 1995年頃から2015年の現在まで、Webアプリ開発で
よく使われている通信方式を紹介します。
 最適な通信方式を選択すれば、実装が楽になります。
 よくあるWebでのチャット画面を例に説明します。
◦ http://aramoto.sakura.ne.jp/chat/index1.php
◦ http://aramoto.sakura.ne.jp/chat/index2.html
◦ 注：かなり手抜きな実装です
2

3. Ajax (2005年頃)とは
 Google Maps で一躍有名になった手法
◦ それ以前にも使われていた
◦ XMLを使わない事も多い
 最近はJSONがとても多い
 ページの遷移をせず、Webサーバと通信できる
◦ 状態を継続させる手間が要らない
Ajax（エイジャックス[1][2]、アジャックス[3]、アヤックス[要出典]）は、ウェブブラウザ
内で非同期通信とインターフェイスの構築などを行う技術の総称[4]。
XMLHttpRequest（HTTP通信を行うためのJavaScript組み込みクラス）によ
る非同期通信を利用し、通信結果に応じてダイナミックHTMLで動的にページ
の一部を書き換えるというアプローチを取る[5]。
AjaxはAsynchronous JavaScript + XML の略で、2005年2月18日に米国の
インフォメーションアーキテクトであるJesse James Garrettにより名付けられ
た[5][6][7]。
ウィキペデアより
3

4. Ajax以前のWebアプリ
 Webサーバに全パラメータを送り、全部を返す
4
前ページ
次ページ
画面全体のHTMLを返す
使わないパラメータを含め、
全部を送る 全パラメータを
次ページに引き継ぐ
一部分だけ
変わっている
前ページと同じ状態を
再現しておかないと、
誤操作を誘発する
Webサーバ

5. Ajax以前のWebアプリの不満
 毎回、全パラメータを送らなきゃならない
◦ 画面に項目が増えるたびに、沢山の修正が発生
 HTML、JavaScript、サーバ側のコード、すべてが影響を受ける
 パラメータを受け渡すだけのコードがドンドン増える
◦ 通信が大量に発生
 通信負荷大、サーバ負荷大
 画面の状態を保持するのが大変
◦ text, select, ckeckbox, radio, 独自作成した部品
◦ <input type=“hidden”> を大量に書くことに
 画面全体を再描画
◦ 応答が遅いと、思考が中断される
◦ 「前回の操作の続き」が完全には再現できない
5

6. Ajax を使えば
 更新したい部分のデータだけを取得
◦ 送信するデータ量が少ない
◦ 受信するデータ量が少ない
◦ 画面全体を再描画しないで済む
6
ページ移動しない
データだけを返す
必要なパラメータだけを送る
データからHTMLを
生成する
画面の一部だけを
書き換える

7. Ajax を使うメリット
 画面に関してはHTMLとJavaScriptだけで記述できる
◦ Webサーバ側は、データやAPIを提供するだけ
◦ Webサーバ側は、環境によって使える言語が違う
 状態の引きまわしをしなくてすむ
◦ 画面の項目数が増えるほど、メリット大
 他のWebサーバのデータやAPIも利用できる
◦ 他のWebサーバ側でクロスドメイン制約を許可（CORS）
 HTTPヘッダで「データを利用しても良いサイト」を指定
 Access-Control-Allow-Origin: *
7

8. Ajax に対する不満
 Webサーバ側からのイベントを通知できない
◦ ユーザーは最新の状況を見たい
 ブラウザの更新ボタンを押さなくても、自動更新して欲しい
◦ 以前は、一定周期にポーリングすることで対応
◦ →クライアントの数だけアクセスが発生
例：100台が毎秒ポーリングすると、100リクエスト／秒になる
◦ →→サーバの負荷が異常に増大
8

9. Comet (時期不明)の出現
 通信回数が減少
◦ 通信負荷、サーバ負荷が減少
◦ イベント発生時には、最短で通知
 既存のブラウザ、Webサーバで実現可能
◦ 実装が少し複雑
Comet（コメット）とは、Web アプリケーションを構築する際に利用される技術
で、この技術を使うと、サーバで発生したイベントをクライアントからの要請な
しにクライアントに送信することができる。
Comet はこのような通信を実現するための複数の手法をまとめた概念である。
これらの手法はブラウザにプラグインを追加することなく、（JavaScript のよう
な）デフォルトの機能で実現されるものである。理論的には Comet は、ブラウ
ザがデータを要求する形の既存のウェブのモデルとは異なっている。実際は
Comet アプリケーションは Ajax と Long polling を使用してサーバ上の新規
データを取得する。
ウィキペデアより
9

10. Comet の仕掛け
 Ajax で呼んでも、すぐにはデータを返さない
◦ イベントが発生したら、返す
◦ 一定時間が経過したら、返す
 ずっと応答を返さないと回線断が検出できないため
10
ページ移動しない
データだけを返す
必要なパラメータだけを送る
画面の一部だけを
書き換える
イベント発生
イベントが起こるまで、
応答を保留

11. Comet に対する不満
 実装が複雑になってしまう
◦ イベントを漏れなく全て伝えるのは、かなり大変
 応答から次のリクエストまでの間に変化があった場合
 連続してイベントが発生した場合
 通信量が減ったことで
◦ 画面に表示しないHTTPヘッダの割合が大きくなった
◦ もっともっと通信量を減らしたい
11
通信例：HTTPヘッダ部
リクエスト：778Byte
レスポンス：356Byte
データが数十Byte程度だと、
データ以外が十倍以上となる

12. WebSocket (2011年頃)の出現
 ブラウザとWebサーバを接続したままにする
◦ 通信が連続しているので、実装が簡単
 連続したイベントの通知も、とても速く送れる
◦ HTTPヘッダのやり取りは、最初の１回だけ
 通信量は、実際に送りたいデータ＋4Byte程度
 ただし、既存のブラウザ、サーバでは実現不可
◦ 一番多いApacheは「接続したまま」が想定外
WebSocket（ウェブソケット）は、コンピュータ・ネットワーク用の通信規格の1
つである。インターネットの標準化団体であるW3CとIETFがウェブサーバーと
ウェブブラウザとの間の通信のために規定を予定している双方向通信用の技
術規格であり、APIはW3Cが、WebSocket プロトコルはIETFが策定に関与し
ている。プロトコルの仕様は RFC 6455。TCP上で動く。
ウィキペデアより
12

13. WebSocket の仕掛け
 ブラウザとWebサーバを接続したままにする
◦ ブラウザ→Webサーバは、いつでも送信できる
◦ Webサーバ→ブラウザは、いつでも送信できる
◦ 回線切断を検出するために、ハートビートを行う
13
ページ移動しない
必要なデータだけを返す
必要なパラメータだけを送る
画面の一部だけを
書き換える
イベント発生

14. WebSocket に対する不満
 毎回、サーバ側を実装しなければならない
◦ サーバ側が違うので、クライアント側も毎回違う
◦ 「イベントでデータを配信」と、汎用化できるはず
 既存のクライアント・サーバが使えない
◦ HTTPではないので、困る事が多い
 会社のProxyを通過することができない、など
 WebSocketを使うためのハードルがちょっと高い
◦ HTTPを使ったRESTのAPIも提供することで、別途対応？
14

15. MQTT (2014年頃)の出現
 仕様が最初に書かれたのは、1999年
 Topicに基づいて、メッセージを配信
◦ 「このデータが欲しい」という指定方法が、標準化
◦ サーバ側アプリを専用に開発しなくても、使える
 IoTでの通信プロトコルとして注目されている
◦ 軽量、QoSレベル、1対N
MQ Telemetry Transport(Message Queue Telemetry Transport、略称
MQTT)は、メッセージ指向ミドルウェアのアプリケーション層で使用される、
TCP/IPによるPub/Sub型データ配信モデルの軽量なメッセージキュープロト
コルです。
非力なデバイスやネットワークが不安定な場所でも動作しやすい様にメッセー
ジ通信電文が軽量に設計されている事が特徴です。
Pub/Sub型メッセージング·パターンには、メッセージブローカーが必要です。
ブローカーは、メッセージのTopicに基づいて、それを必要としているクライア
ントにメッセージ配信をしています。
ウィキペデアより
15

16. MQTT の仕掛け
 汎用のMQTTサーバをそのまま使用
◦ Topicベースで、欲しいデータを指定
 /a1/b11/text
 /a1/b11/# （/a1/b11 以下全部）
 /-/-/text （３階層目のtext全部）
16
Topic
├─a1
│ ├─b11
│ │ ├─text
│ │ └─score
│ └─b12
├─a2
│ ├─b21
│ │ ├─text
│ │ └─news
│ └─b22
ページ移動しない
Topicのデータだけを返す
Topic「/a1/b11/text」を指定
画面の一部だけを
書き換える
イベント発生
サーバアプリの
開発が不要

17. まとめ
 Ajax は必須の技術
◦ 余計なコードを書かなくて済む
 Webサーバ側の実装無しで、Webアプリが作成可能かも
 クライアント側での処理に集中できるので、開発が楽
◦ クライアント：便利なライブラリが豊富
◦ サーバ：HTMLではなく、データを返す
 どの方式を使えば良いのか？
◦ Comet：リアルタイムを実現、だけど処理が複雑
◦ WebSocket：通信量が減って実装が楽、だけどHTTPじゃない
◦ MQTT：IoTで注目、サーバ側の実装が不要、だけどHTTPじゃない
17
特別な場面でのみ使用