TLS over HTTPの提案仕様

TLS over HTTPである。HTTP over TLSではない。

Application-Layer TLS」という提案仕様がCiscoの方より提出されている。(仕様中ではATLSと記述される)

HTTP上でTLSレコードを送受信する仕様である。

TLSレイヤの実装変更はなくレコードをHTTPのボディで送受信できるようにする。なお、httpとhttps両方で使用可能である。

また、TLS1.2とTLS1.3などすべてのTLSバージョンに対応する。

来週からはじまるIETF100でも議論されるようなので、かいつまんで読んで見る。

クライアント

クライアントからの基本的なメッセージは、POSTでJSONを送信する。

Content-Typeにはapplication/atls+jsonを指定する

   POST /atls
   Content-Type: application/atls+json

   {
     "session": "<session-string>",
     "records": "<base64 encoded TLS records>"
   }

サーバ

サーバも基本的には同様である。

   200 OK
   Content-Type: application/atls+json

   {
     "session": "<session-string>",
     "records": "<base64 encoded TLS records>"
   }

正しくないリクエストを受け取った際は400 Bad Requestを返す

ハンドシェイク

各アプリケーションは、内部的に持つTLS実装を用いてセッションを開始する。作成されたレコードはJSON形式に変換されHTTP上で送信される。サーバ側は受け取ったJSONよりTLSレコードを復元しTLS実装に渡し、同様にTLSレコードを送り返す。

f:id:ASnoKaze:20171111223136p:plain

WebSocketの利用

HTTPを利用するとサーバからメッセージを送ることは出来ません。TLS closeメッセージなどサーバから送れるように、WebSocketsに通信をアップグレードすることもできます。

なぜこんなことをするのか

最後になったが、何故このようなことをしているのか、ドラフト中にも書かれている。

f:id:ASnoKaze:20171111230217p:plain
ネットワーク管理者がネットワーク接続をするクライアントに信頼できるルート証明書をインストールさせ、ローカルネットワークの出口などでクライアントとサーバの中間に入ってTLSをほどき、平文を確認し再度TLSセッションを貼り直すような環境を想定している。

そのような環境下でもTLS終端装置(中間装置)を安全に通過できるようにHTTP上でTLSレコードのやりとりをするという話のようだ。

HTTPヘッダに構造定義を与える Structured Headers の提案仕様

HTTPヘッダには、リストや辞書といった構造を表現するのに決まったやり方はありません。

HTTPヘッダ毎にシンタックスや構造が定義されており、そのためパーサーが再利用出来ません。

mnot氏とphk氏の共著で提出された「Structured Headers for HTTP」仕様では、HTTPヘッダに下記の構造を定義しパーサを再利用できるようします。また、新しいHTTPヘッダを標準化する際も個々別のシンタックス定義を不要にしています。

  • Numbers
  • Strings
  • Labels
  • Parameterised Labels
  • Binary Content
  • Items
  • Dictionaries
  • Lists

この仕様はすでに定義されているヘッダを再定義するものではなく、この定義を使用して定義されるヘッダにて使用される想定です

Structured Headers for HTTP

JSON形式を用いるものや、新しい構造を定義して、HTTPヘッダに構造を与える提案仕様は過去にも有りました(IETF97議事録参照)。しかし、どちらも標準化には至っていません。

上記の議論を踏まえて出てきたのが、「Structured Headers for HTTP」という仕様です。

以前の2つに比べ、既存のHTTPの形式に近しい印象です。今月実施される、IETF100(アジェンダ)でも議論される予定です。


以下では定義されている構造について羅列していきます。仕様ではシンタックスとパース方法も書かれていますが割愛

Numbers

整数。IEEE 754倍精度少数。

ExampleNumberHeader: 4.5

パース及び、精度については議論有り。

Strings

ASCII文字列

ExampleStringHeader: "hello world"
Labels

ラベル(小文字のみ)

ExampleLabelHeader: foo/bar
Parameterised Labels

パラメータ付きラベル(順番に意味はない)

ExampleParamHeader: abc; a=1; b=2; c
Binary Content

バイナリデータ(Base64エンコード)

ExampleBinaryHeader: *cHJldGVuZCB0aGlzIGlzIGJpbmFyeSBjb250ZW50Lg
Items

number、string、label、binaryのいずれか

Dictionaries

辞書データ(LabelとItemの組からなる)

ExampleDictHeader: foo=1.23, da="Applepie", en=*w4ZibGV0w6ZydGUK
Lists

Itemのリスト(配列)

ExampleLabelListHeader: foo, bar, baz_45

iframe内の転送量を制限する Transfer Size Policy とは

Webページにソーシャルボタンや広告といったiframeを埋め込むことがあります。

この時、埋め込んだ側はiframeの中で使用されるリソースを制限する方法はありません。例えば動画を再生すればトラフィックとCPUが消費されますし、最近では実はBitcoinの採掘に利用されるということもあるかもしれません。

そのようなリソースの消費は、特にモバイル環境においてWebページのユーザ体験を損ねることになります。

そこで、W3CのWICG及びWebPerf WGでは、Transfer Size Policyという仕様が議論されています。まだまだ議論が始まるところで、たたき台というところかと思います。

この仕様は、TPAC 2017のWebPerf WGのミーティングでも議論されるようで、資料がすでに公開されており、アジェンダより確認できます。

docs.google.com

Transfer Size Policy

Transfer Size Policy の仕様はWICGのリポジトリから確認できます
github.com

この仕様では、iframeの属性に転送上限と、上限に達した際に発火するイベントを登録できます。

下記の例では、300KB以上転送した際に、ontransferexceededイベントが発火しonBigFrameが呼ばれます。

  <script>
    function onBigFrame(event) {
      console.log("Frame id: " + event.target.id + " exceeded its threshold bytes in category: " + event.category);
    }
  </script>

  <iframe id="foo" ontransferexceeded="onBigFrame(event)" transfersize="300" src="...">


また、例えば、自ドメインとの通信は無制限、example.comとはスタイルシートは50KBで合計500KBまでといった指定もできるようになっています。

  transfersizes: {"default":"100", "self":"*", "*.example.com":"style:50, total:500"}

この仕組によって、リソースを消費するiframeを検知できるようになる。また、最悪iframeのdomを消すことで対応することも出来るが、別途提案されているPausing Documentsを使うことで処理を一時停止することもできる。

Pausing Documents

あわせて、著者の個人リポジトリですがPausing Documentsという仕組みもあわせて議論されています。
github.com

この仕様では、フレーム内の読み込み・レンダリングスクリプトの実行を停止できるようにする仕組みです。

await frameElement.pause({loading: true, rendering: false, script: false});
await frameElement.unpause();

Transfer Size Policyの仕組みとあわせて、リソースを大量に消費するframeを一時的に停止することができるようです。

Content Security Policy(CSP) レポートのCORSと、Fetchの仕様変更

WHATWG, Fetch詳しくないので間違いがあればご指摘下さい


Content Security Policy(CSP)やHPKPやExpect-CTでは、ユーザエージェントはセキュリティの違反を検出した際に、指定したURLにレポートを送信できる。

例えば、下記のようにHTTPレスポンスヘッダにreport-uriでレポート先を指定します (詳細は それぞれの仕様及び、Reporting APIの仕様を参照)。

Content-Security-Policy: default-src https:; report-uri /csp-violation-report-endpoint/
expect-ct: enforce;max-age=3600;report-uri=https://example.com/report-uri


もちろん、ブラウザが今開いてるURLとは別ドメインのURLを指定することも出来る。これは、特に証明書に関わるセキュリティ違反が起こったときにレポートを送信するので、そのドメインは信頼できないということもある。

expect-ctに関しては、以前書いたとおり
asnokaze.hatenablog.com

report-uriとCORS

今年 7月のIETF99において、expect-ctの標準化に伴いレポート時のCORSに関するISSUEがとりあえげられた(発表資料はコチラ)。

レポート機能におけるCORSをどうするか、preflightを送るのか?送るのであればoriginヘッダに何を設定するかという話である。

選択肢として

  • a. preflight を送る(Originヘッダはnull)
  • b. ホワイトリストに含まれる text/plain で送る
  • c. CORSを違反する

その後の議論によって、expect-ctの仕様ではなくFetch側での議論に場所を移す。

(余談だが、W3C側のCORSの仕様はFetchの方がデファクトになっているため、廃止が検討されている。Proposed Obsolete for CORS)

Document CORS safelist exceptions

Github場でのIssueもFetch側に移行し

その後、一部のContent-Typeを例外扱いにするプルリクエストが出されている(現時点ではマージされていない)
github.com

そのなかでは、「application/csp-report」「application/expect-ct-report+json」「application/report」「application/ocsp-request」を例外としてしている。

これによってレポートを送る際にCORSは不必要にな方向に向かいそうだ。

今月行われるW3C TPACK 2017のWebAppSec WGのアジェンダにもCORSが上げられているのでそこでも議論されるものと思われる。

QUICとネットワーク管理/オペレーションの話


QUICは新しいトランスポートであり、IETFで標準化が進められています。

UDPベースのプロトコルであり、QUIC Connection IDと呼ばれるIDでコネクションを管理しており、IPアドレス・ポート番号が変わってもコネクションを維持することが出来ます。また、ほとんどのデータが暗号化されているため、ACKや切断要求なども経路上からは観測できません。

このように様々な機能改善が行われており、ファイアウォールといった経路上で機能をもつ装置ではQUICを適切に扱う必要があります。

IETFのQUIC WGでは、QUICトラフィックを管理するネットワークオペレータやミドルウェアの管理者向けに「Manageability of the QUIC Transport Protocol」を出しています。

この文書では、経路上でどのような情報が見え、どのような情報は見えないのか、既存のプラクティスがどのような影響をうけるかについて記述しています。

前半はQUICのワイヤイメージと機能に関して、後半はファイアウォールやDDoS対策などネットワークオペレーションへの注意事項が記述されています。ただしすべき/すべきでないといったプラクティスは環境に依存するため、この文書では書かれていない

かいつまんで紹介する

ワイヤイメージ

QUICのトランスポートを定義する「QUIC: A UDP-Based Multiplexed and Secure Transport」では、ロングヘッダとショートヘッダを定義しています。ロングヘッダはバージョンネゴシエーション、サーバリトライ、0-RTTデータを含むコネクションの最初に使用されます。一方、ショートヘッダはハンドシェイク後に使用され、ヘッダのオーバヘッドを抑えるために殆どのデータパケットで使用されます。

ロングヘッダ

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+
   |1|   Type (7)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       Connection ID (64)                      +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Packet Number (32)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Version (32)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Payload (*)                        ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ショートヘッダ

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+
   |0|C|K| Type (5)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                     [Connection ID (64)]                      +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Packet Number (8/16/32)                ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Protected Payload (*)                   ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: ロングヘッダはヘッダタイプフィールドを持ちます。現在のQUICバージョンは6つのヘッダタイプを定義しており、Version Negotiation, Client Initial, Server Stateless Retry, Server Cleartext, Client Cleartext, 0-RTT Protected です(将来増える可能性があります)。
  • Connection ID: コネクションの識別子。QUICでは、5タプル(送信先/送信元IPアドレス送信先/送信元ポート、IPヘッダのプロトコル)ではなくConnection IDでコネクションを管理します。サーバから採番もできます。ショートヘッダではオプショナルのフィールドです。
  • Packet Number: 各パケットはバケット番号を持ち、送信する毎に増加していきます。乱数で初期化された内部カウンターのうち最下位ビットの8, 16, 32bitのいづれかを長さで格納します。再送の場合でも値は増加すること、値はスキップ出来ることに注意が必要です。
  • Version Number: QUICのバージョンです。バージョンはVersion Negotiationパケットでサポートしているバージョンを送りますが、暗号化されていないため送信者側のサポートしているバージョンは経路上からも確認できます。
  • K(key phase):ショートヘッダはKey Phaseフラグを持ち、暗号化に用いた鍵を識別するのに使用されます。


これらのフィールドの位置は将来のQUICでも固定されているでしょうが、フィールドは増える可能性がある点に注意が必要です。

また、暗号化されていないフィールドにおいてもコネクションが確立した後に値は検証されるため、経路上では1bitも変更はできません。変更した場合は、パケットが破棄されるか、コネクションは切断されます。

バージョンネゴシエーションにおいては、TLSのGREASE拡張のように未知のバージョンを含められる点に注意が必要です。

経路上で出来ること

QUICトラフィックの識別

QUICトラフィックは特別、その他のUDPパケットと区別出来るようには設計されていません。

現在ターゲットなっているアプリケーションプロトコルはHTTPであり、HTTP over QUICは通常UDPポートの443を使用しますが、他のポートも使用できます。

バージョンの識別

上記のように確実ではありませんがパケットがQUICだとして観測するならば、ハンドシェイクを観測することでバージョンを推定できます。バージョン番号を持つClient Initialパケットと、サーバからそのバージョン番号を持つ平文のパケットが送り返されていれば、バージョン番号が受理された事を意味します。

ただしクライアントやサーバのIPアドレスが変わってもコネクションは維持されるため、その際ハンドシェイクは行われません。Connection IDをトラックし、最初のハンドシェイクの情報が必要になります。

不正なパケットの拒否

ネットワークフィルタで、反射攻撃やバックスキャッタといった不正なパケットを拒否したい場合があります。

パケットの最初のバイト(パケットタイプ)に基づくヒューリスティックな手法で、そのパケットタイプが届くことが正しいのか分類することが出来ます。

ただし、パケットタイプは将来のバージョンでは増えたり、異なる意味を有する可能性があります。

コネクション確立の確認

コネクションを確立するには平文のパケットが必要であり、ストリーム0上でTLSハンドシェイクを行います。そのため、TLS over TCPど同じような手法を用いて検出することが出来ます。

通信フローの関連付け

例えば、NATリバインディングIPアドレスの移動などで、クライアントのIP・ポートが変わってもConnection IDは変わらないので前後の通信フローを関連付けできます。

通信フローの切断検出(不可)

QUICはコネクションの終了は経路上からは分かりません。

通信フローが終了した場合、経路上の装置からはパケットが観測されないだけです。NATやファイアウォールのような状態を持つ経路上の装置は内部に持つQUICのフロー状態を消すアイドル時間を設定する必要があります。

ラウンドトリップタイムの計測

QUICではACKも暗号化され経路上では確認できないため、ハンドシェイク中にのみ通信を観測し測定できます。

この振る舞いに関する変更は議論中です。https://github.com/quicwg/base-drafts/issues/631 参照。

パケットロスの計測

QUICパケットは平文でパケット番号を送信します。パケット番号のギャップを観測することで観測点より上流でのロスを推定できますが、通常推奨はされませんがパケット番号を飛ばすことも許可されています。

また、ACKや再送は経路上で観察できないため、観測点より下流でのロスについては正確に推定できません。

ネットワーク経路上の装置への影響

QUICトラフィックの状態を扱う装置

ファイアウォールなどの、QUICトラフィックの状態扱うのはコネクションの確立を観測することで可能です。

ただし、終了は経路上からはわからないので最後の通信からのタイマーや、LRU(Least Recently Used)方式で状態は削除されるべきです。ただし、アプリケーションの要件に依存します。

ネットワークのパフォーマンス測定とトラブルシューティング

QUICトラフィックを受動的に観測することにより、極めて限定された損失とRTT測定が可能です。

サーバと協調したロードバランシング

Connection IDはサーバから払い出すことが出来ます。Connection ID(64bit)は任意のバイト列ですので、特定の情報を埋め込む事もできます。複数ロードバランサがある場合などでも、最初に処理した(通信を復号できる)ロードバランサの識別子などを埋め込んでおくことで、DNSラウンドロビンなどで別のサーバにパケットが届いても、適切なロードバランサにルーティングすることもできます。

ただしクライアントが悪意を持って変更しても大丈夫なように、HMACなどを用いてで不正なパケットを検出できるようにすべきです。

DDoSの検出と緩和

現在のプラクティス通り、正常なトラフィックと異常なトラフィックを分類することになります。

QUICのステートを見ることで不正なパケットを分類できますが、正当なQUICクライアントを用いたDDoS攻撃には意味がありません。

Connection IDを用いたコネクションのマイグレーションを使用すると、5タプルだけでなく多くの情報を保持する必要がありますが、DDoS攻撃の中でコネクションのマイグレーションを受け付ける必要があるかは疑問があるようです。

QoSとECMPのサポート

この文書のQoSに関する記述はまだ推測であると注意書されています。

QUICでは5タプルが同じであれば経路上で同じような処理をうけると仮定しており、多重化せれた全てのストリームのメッセージは同じように輻輳制御をうけます。ネットワークはQoSに5タプルの他にコネクションを用いることも出来ます(MAY)。

QUICはTCPよりもパケットの順番の入れ替わりに耐性があることを考えると、ECMPは必ずしもフローベースである必要はありません。

Mixed Content Level 2の議論

W3CのWeb Application Security WGのco-chairとなった GoogleのMike West氏から、11月に実施されるTPAC 2017に先立って「Mixed Content Level 2」という提案が出されている。

Mixed Content

https://のURLで、http://のリソースを読み込むと警告・もしくはブロックを行うMixed Contentという仕様がある。そのMixed Contentの問題とそれを改善するMixed Content Level 2の議論が始まっている。

まだまだ議論のたたき台ではあるが、簡単に読んでおく。

問題点
  • 仕様でOptionally-blockableとして定義される、必ずしも読み込みがブロックされない画像などのリソースは、未だにhttp://で使用されているケースが有ります。警告などは表示されますが、その割を減らすには効果は弱いようです。
  • https://mixed.badssl.com/といったoptionally-blockableがある場合は、ChromeではURLバーの鍵マークを表示しません。blockable がブロックされた場合は鍵マークが表示されます。blockableとoptionally-blockableの区別をし続け、ユーザにとって区別出来るものでしょうか?
  • HTTPからHTTPSへの移行は大変です。Upgrade-Insecure-Requestsは部分的に問題を解決しますが、開発者がヘッダに指定する必要があります。HSTS PrimingはFirefoxで実装されていますが、その価値は示されていません。
提案
  • ユーザエージェントは、blockable mixed contentをブロックするのではなくアップグレードします。Upgrade-Insecure-Requestsがあるかのように、http://のリソースでもhttps://でアクセスします
  • ユーザエージェントは、optionally-blockable mixed contentをデフォルトでblockableとして扱います。そして上記のようにアップグレードが適応されます。開発者がヘッダなどで明示的にoptionally-blockableとして扱うように指示できるようにすることも検討する。
  • ユーザエージェントは、複雑さを避けるためにUpgrade-Insecure-Requestsを廃止する。
  • ユーザエージェントは、より多くの状況でURLバーの鍵マーク(盾マーク)を消すべきです

また、アップグレードしてもhttpsの接続性がない場合はタイムアウトするまでレンダリングがブロックされる可能性があるため、タイムアウト時間を短した方がいいとMLで意見が出ています。

Akamai Edge 2017 に行ってきた

10月11~13日に、ラスベガスで開催されたAkamai Edge 2017に参加してきました。

英語を聞きながらのメモなので断片的ではあるが、せっかくですので、面白かった所など紹介する。

オープニング・キーノート

Tom Leighton氏から、「Connect to Tomorrow」というイベントのキーフレーズが紹介されるとともに、Akamaiのこれまでとこれからについて紹介されました。

そして4つのテーマについて紹介があり、Akamaiの目指す方向が示されました

  • パフォーマンス
  • メディア
  • セキュリティ
  • DevOps

動画も公開されている
https://edge.akamai.com/ec/us/speakers/tom-keynote-2017.jsp

マルチソース・ストリーミング

中でもマルチソース・ストリーミングビデオプレーヤーのデモは非常に面白かった(現在beta)。

f:id:ASnoKaze:20171023235028p:plain

P2Pキャッシュのデモである

  • 4つのノートPCで動画をストリーミング再生する。緑のPCは、緑枠の画面。といった具合に、PCと対応するモニタが表示されている(赤紫緑黄の4色)。
  • 各モニタ画面右下の各四角は、動画のセグメントがどこから取得されたか示している。
    • オレンジはAkamaiから取得。それ以外は隣接するPC(色に対応)から取得していることを示している。

プレイヤーが判断し、一番早いところ取得するようになっている。(あまり聞き取れなかったので、違うかもしれないがどうやらWebRTCを使ってるよう?)


このデモでは無かったが、単純にマルチCDNで一番早いところからセグメントを取得してストリーミングを再生することも出来るようだ。もちろん、ソース毎の提供割合をコントロールできるようにもなっている

Bot Manager

もう一つ上げるとすればセキュリティーソリューションである。WAFのデモも非常に面白かったが、Bot Managerという製品のデモが面白かった。

ユーザの動作からBotを判別する機能だが、スマホブラウザのあらゆる情報を取得しBotかどうか判別している。
f:id:ASnoKaze:20171024000113p:plain
f:id:ASnoKaze:20171024000116p:plain

デモでは、各種傾きセンサ、タッチ・タップイベントを取っている例が示された。入力や傾き情報などを合わせてBot判定を行うようでかなり複雑な処理を行っていそうであった。

パフォーマンス関連のセッション

Akamaiらしくパフォーマンスに関するセッションは多くあった。手元にあるメモをかいつまんで紹介する。

Web Performance Roadmap 2017

各種サービスの新機能など

  • Image Manager
    • 画像最適化ソリューション。モバイルや回線速度によって、画像サイズやフォーマット(JPEG 2000,WebP... etc)、画像の品質を落とさず最適化を行う。
    • 一つのオリジナル画像を準備しておくだけで、自動で行われる。
    • 60%ほど品質を落とさずデータサイズを小さくした。13%ページの高速化に寄与した。
  • Ion4
    • Webページの最適化。意識せず高速化される。
    • HTTP/2, Brotli, OCSP Stapling, TLS1.3(Comming Soon)
    • Adaptive Learning Engine, Automatic Push: Akamai側が自動で学習し最適に配信する。HTTP/2サーバプッシュも、学習し最適なタイミングで実施される。
    • 近年はページごとのJavaScriptの増えているが、その最適も行う。32%ほどサイズが小さくなることも(Script Management)
  • Mobile App Performance SDK
    • モバイル・アプリケーション向けの最適化ソリューション
    • ネットワークレイテンシのレポート機能
    • 内部的に自動的にリソースのキャッシュ
    • AkamaiのEdgeサーバとの最適通信路の選択
  • Ad Recovery
    • Adブロッカーを回避して、広告を表示できる(AkamaiのURLから配信?仕組みはちょっとよくわからず)。動画広告でも同様の機能がある模様。


HTTP2の最適化の話はもっと詳しく聞きたいところではあった、、、

Faster Bytes is Not Always Enough - Why is The Web Slow? (And What Can We Do About It)

f:id:ASnoKaze:20171024004835j:plain
標準化界隈でも活発に活動されているYoav Weiss氏のセッション。セッション前に少しお話できた。

このセッションでは、パフォーマンス上の問題とその解決の役に立つ技術の紹介的なセッションだった。

  • 動的ページのサーバサイド処理時間
    • HTTP/2サーバプッシュを用いることで、生成中の待ち時間を有効活用できる
  • リソースのディスカバリ
    • rel=preconnect, preload を利用しリソースを早く取得できるようにする
    • preloadのいいところ: クロスオリジンも可、CacheやCookieが使える、コンテンツネゴシエーションが働く、loadとerrorイベントが取れる
    • pushのいいところ: より待ち時間が少ない
    • Early Hints
    • 「rel=prelaod ... as=scripts」指定でpriorityが使えるようになる
  • 画像/JSの肥大化
  • クライアントサイド処理
Media Acceleration and QUIC Optimization

Akamaiでは、動画の配信でGoogle QUICを使用している。

f:id:ASnoKaze:20171024005415j:plain

  • 24%リバッファリングを減少させ
  • 12.5%動画の配信を早くし
  • より高画質な動画を選択出来るユーザが増えた

また、360度映像で、視点の向いているところだけ高画質配信する事例紹介も。


Akamaiの環境では、QUICとTCPの映像配信の優劣比は

  • 60%の環境でQUICが良い
  • 20%はQUICとTCP環境が同等
  • 20%はTCP環境の方が良い

となっており、特定のTCPに最適化されたネットワーク環境下ではTCPの環境のほうが良いとのことだ。


また、ネットワーク環境が遅いところほどQUICの効果が高く、Akamai輻輳制御を改善したTuned QUICのほうが若干高速であることが示されている。
f:id:ASnoKaze:20171024010331j:plain

  • 青がTCP, オレンジがQUIC, 白がAkamaiチューニングQUIC
  • 左右グラフの内3グループあるのは、左が高速、中央が中速、右が低速な環境のグラフである。


現在はAkamaiGoogle QUICをサポートしているが、IETF QUICのサポートももちろん視野に入れているが、IETF版QUICの改版は早いため質とコストを見つつ対応していく予定のようだ。

その他

f:id:ASnoKaze:20171024011048j:plain

その他沢山の機能紹介があった。また、DevOps系のセッションも多く、Configurationのコード化や、フェイルオーバー、等運用にかかわる話も非常に濃かった。

Akamaiの方々にも当日お話させて頂く機会があり大変勉強になりました。
ありがとうございました。

ラスベガス

大変刺激的な街でした
f:id:ASnoKaze:20171024011945j:plain