HTTP3 でpub-subとMQTT-over-QUICの比較をIoTの観点から行った論文の備忘録です。 IoTという文脈で、ネットワークエミュレータに遅延と帯域を設定して、性能(最初のデータが到達するまでの時間、通信終了までの時間やスループット)、ネットワークへのオーバーヘッド(バイト量とパケット数)、リソースの使用状況(CPU使用率、RAM使用量)、の3つを比較しています。 性能面では、H3 pub-subのほうが優れた結果が得られていますが、ネットワークのオーバーヘッドやリソースの使用状況はHTTP3 pub-subのほうが MQTT-over-QUICよりも多くのリソースを使用する結果となったようです。 これらの結果から、IoTという文脈を考えた場合、トレードオフが存在しているということを示唆しています。 元論文は下で読めます。 arxiv.org 実装について H3 pub-s
1.QUIC仕様の公開 以前、「Googleが仕掛ける新プロトコルQUICとは何か」のブログエントリーを書いたのが2月末の事でした。それから4か月経ち、今朝Googleが初めてQUICの公表(Chromium Blog: Experimenting with QUIC)を行いました。 IE11のSPDY/3対応が判明した直後でした。なんというタイミングでしょうか。 また、近いうち(来週?)には HTTP/2.0 の Implementation Draft が公開される予定です。8月上旬には、GoogleやMicrosoft等が集まって初めての HTTP/2.0 の相互接続試験を行う予定です。ただ今HTTP関連のプロトコルが急激に進化する真っ最中です。目が離せません。 2. で、QUICとは何なのか? 先のChromium BlogのエントリーでQUICは、 「Quick UDP Inte
Google が Chrome に新しい通信プロトコル "QUIC" を実装している (François Beaufort のGoogle+ への投稿、TechCrunch Japan の記事より)。 QUIC プロトコルは UDP プロトコルを改良したもので、暗号化、基本的な確実性制御など高機能化したものだそう。QUIC は数日前に Chrome へマージされているのが確認できる (Code Review の Issue)。 2009 年に Google は SPDY を発表し (/.J 記事)、HTTP 2.0 の規格ベースとして SPDY が採用されたが、Google は QUIC も UDP 2.0として規格化していくつもりなのだろうか?
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く