A Pure HTTP/3 Alternative to MQTT-over-QUIC in Resource-Constrained IoT の備忘録 - neko--suki’s blog
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
「HTTP/3」がHTTP-over-QUICの新名称に。IETFのQUICワーキンググループとHTTPワーキンググループで合意 － Publickey
現在IETFで仕様策定が進められている、UDPをベースに効率的で高速な通信を実現するためのプロトコル「QUIC」をトラスポート層に用いる新しいHTTPの名称が「HTTP/3」になることが決まりました。 HTTP/3のベースはGoogleが開発したQUIC。IETFで標準化へ もともとQUICは、Googleが高速なHTTPの通信を実現するためのプロトコルとして2013年に発表し、同社のChromeブラウザやクラウドサービスなどに実装してきました。 QUICは、従来のHTTPでトランスポート層に用いられているTCPの代わりに、UDPを用いています。 TCPはエラー訂正機能などを備え信頼性の高い通信が可能な一方、比較的オーバーヘッドの大きなプロトコルです。そこでTCPの代わりに通信の信頼性は保証されないもののオーバーヘッドの小さいUDPを用い、独自に一定の信頼性を保つ実装を組み込みつつHTTP
GoogleのQUICプロトコル：TCPからUDPへWebを移行する | POSTD
QUIC（Quick UDP Internet Connections）プロトコルは、TCPではなくUDPをベースとして開発された、全く新しいWeb向けのプロトコルです。 （冗談で） TCP/2 と呼ぶ人までいます。 私がQUICについて知ったのは数週間前のことです。 SysCast Podcastのcurlとlibcurlについてのエピソード を聞いていた時でした。 QUICプロトコルの本当に面白い点は、UDPへの移行というところだと思います。 現在、Webの伝送プロトコルは、信頼性を確保するため、TCP上に構築されています。このTCP接続を開始するためには、 3wayハンドシェイク が行われています。つまりこれは、接続を開始するたびにラウンドトリップ （ネットワークパケットの往復） が追加されるということであり、新たな接続先に対し大幅な遅延を生じさせているのです。 （出典： UDPを介
HTTP 2.0 and QUIC - Protocols of the (near) future
HTTP 1.1 forced both developers and browser vendors to invent different tricks in order to make sites to load and run faster. HTTP 2.0 and QUIC will provide many significant improvements overt HTTP 1.1. In this talk I will give an introduction to both protocols and emphasize why are they so important for the Web development workflow and performance.
なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes
Intro Google が SPDY の開発を始めたのは 2009 年で、 2012 年に HTTP2.0 のドラフトとして採用されたあたりからちょっと話題になりました。 翌 2 月には新たなプロトコル QUIC の存在が Chromium のソースからリークしたのですが、しばらくは音沙汰なく。 6 月に入ってやっと Google から公式アナウンスとドキュメント類が出ました。 去年から今年にかけて立て続けに出てくる新しいプロトコルの話。 なぜ今 Web のプロトコルが見直されるのか？ 何が問題で、なぜ Google はそれらを作り変えるのか？ SPDY や QUIC は Google の独自プロトコルだけど、それは本当にただの独自プロトコルで終わらせていいのか？ 20% ルールで作ってみた Play プロジェクトでしかないのか？ こうした新しい動きには、かならず「それまで」と「今」を踏
Googleの新プロトコルQUICを試す - ぼちぼち日記
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 が UDP を高速化した QUIC プロトコルを開発 | スラド IT
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として規格化していくつもりなのだろうか？
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RELIABLE UDP PROTOCOL draft-ietf-sigtran-reliable-udp-00