QUIC is expected to be a game-changer in improving web application performance. In this paper, we conduct a systematic examination of QUIC's performance over high-speed networks. We find that over fast Internet, the UDP+QUIC+HTTP/3 stack suffers a data rate reduction of up to 45.2% compared to the TCP+TLS+HTTP/2 counterpart. Moreover, the performance gap between QUIC and HTTP/2 grows as the underl
2020/04/28 追記 仕様の名前が少々変わりましたが、WG Draftとなり作業は引き続き続けられています。 「Specification of DNS over Dedicated QUIC Connections」 QUICの標準化とアプリケーションレイヤ IETFでQUICの標準化が活発に行われており、トランスポート・TLS・HTTP各レイヤのドラフト仕様の改定が進められております。 標準化を行うにあたって当初より、DNSのトランスポートとしてQUICを使用したいという話題は出ていましたが、QUICワーキンググループのチャーターでは、まずはQUICのアプリケーションレイヤとしてHTTPの標準化を行ってから他のアプリケーションプロトコルについて進める旨書かれている。 とはいえDNS over QUICをやりたい人はいるようで、4/11にインターネットドラフトが出されている。共著者
2. 自己紹介 • 大津 繁樹 • 株式会社 インターネットイニシアティブ • プロダクト本部 アプリケーション開発部サービス開発2課 • NodeJS Technical Committee メンバー • (主にTLS/CRYPTO/OpenSSLバインディングを担当） • IETF httpbis WG で HTTP/2相互接続試験等仕様策定に参画。 • ブログ： http://d.hatena.ne.jp/jovi0608/ 3. はじめに • HTTP/2とQUICの概要を学んでいただきます。 • HTTP/2はTLSと異なり必要となる要素技術の数は少ないです。 ですがヘッダ圧縮仕様HPACKを完全に理解しないと概要以上の レベルの技術は見につきません。 • QUICは、TCP/TLSの技術要素の集まりです。これをきちんと理 解するには相当の努力が必要です。 • 残念ながら2時間の
HTTP 0.9 RFC (rfc:1945) は1996年 (HTTP 1.0と同じRFCで説明されてる) 最初の HTTP。GET メソッドしかなかった。レスポンスヘッダもない (ボディーだけ)。 HTTP 1.0 RFC (rfc:1945) は1996年 メソッドに GET POST HEAD が追加された ヘッダが追加された HTTP 1.1 RFC (rfc:2068 → rfc2616) は1997年 HTTP 1.0 に Keep Alive とかを追加したやつ。 バーチャルホストに対応 (Host ヘッダが必須に) Keep Alive が可能 1つのTCPセッションで複数のファイルのやりとりができる リクエストパイプラインが可能 リクエストを複数個レスポンスを待たずに送ることができる サーバ側で対応が必要なのであまり有効活用されてない HTTPS RFC (rfc:28
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
