4K/低遅延ライブは実現できるか　アカマイが導き出したベストプラクティス

4K/低遅延ライブベストプラクティス

時光潤氏：本日はお時間をいただいて、「4K/低遅延ライブベストプラクティス」と題してお話をさせていただきます。

私は、Engagement Managerと呼ばれるRoleとして、お客様から有償のサポートサービスのご契約をいただいて、お客様ごとに技術的なサポート、コンサルティングをさせていただいています。

動画業界だけではなく、いろいろな業界のお客様を担当させていただいているのですが、今回は動画関係にフォーカスし、皆様の業務の1つにお役立ていただける知識を1つでも持って帰っていただけたら幸いです。

まず、本日のアジェンダです。

Agendaですが、初めにEncoding Best Practice。インターネットを通して動画配信を行う場合には、Encodingに気をつけていただくことがあると思います。そこに関する1つのベスト・プラクティスについてお話しさせていただきます。

その後、4K配信の現在。

その次は、低遅延を実現するためにどのようなところに気をつけるべきか。

次にQUICへの弊社の取り組みについて話をさせていただき、最後のおまけで簡単な宣伝をさせていただきます。

Akamai Encoding Best Practice

ではまず、Encoding Best Practiceのお話しをさせていただきます。

みなさん、動画配信されるときにもちろんEncodingは気にされていると思うのですが、AkamaiではEncoding Best Practiceというマニュアルを公開しています。

その中の式を1つ紹介させていただきます。

Resolution frameのHeight・Width・Frame RateとMotion_Factorと呼ばれる1つの係数を本式に当てはめることで、ベースとなるBitrateを算出することができるようになります。

アクション映画やスポーツ中継のように、動きの激しい動画であれば、Motion_Factorをできるだけ小さくしたBitrateを使用することで、効果的なBitrateとなります。本式を活用することで各動画に対して、より効率的なBitrateの基準を算出することができるのです。

つまり動画といっても一概に同じBitrateがすべての動画に対して最適とは限らないのです。

アクション映画のような非常にモーションが大きいものであったり、ドラマのような室内の暗い映像が多いものもあるので、各動画に対して大きいBitrateが必要かどうか、一度気にしてみるといいかもしれません。

Netflix社が調査した例を挙げさせていただきます。Netflix社は100個の動画を1つの1080Pサイズの映像ソースで、一定のクオリティパラメータに固定し、Bitrateのみを変えて、Encoding結果の品質をPlotした調査結果を公開しています。

品質はPSNR（ピーク信号対雑音比）と呼ばれる、ノイズがどれぐらい入っているかという動画の品質評価指標のもと、評価した結果になります。

グラフの縦軸がクオリティを示すPSNR、横軸がBitrateです。結果を見ていただくとわかるのですが、1つのBitrateを取って見ても、Bitrateを上げたからといって、必ずしも動画品質が向上するという結果にはつながらないことがわかります。

映像ソースごとに、どのようなBitrateでどのようなRendition ladderを組むことを検討することがユーザにとって効果的か、ということがグラフからもわかると思います。

How to construct an optimum ladder

では、次にどうすれば最適なRendition ladderを組めるのかということにフォーカスして考えてみます。

ひとつの例を紹介させていただきます。

まずは現実的に配信したい映像サイズをピックアップします。その次に、一定のQualityではなく、はっきりと違いがわかるQualityレベルのパラメーターを設定いただき、Encodeした上で動画の品質評価を行います。

それを、先ほどのグラフのように（PSNRの測定結果を）BitrateからPlotしていきます。

結果のPlotから評価値の最大値の曲線を取ると、実際に効率的なRendition ladderが組めるようになります。

実際にグラフに書いてみます。

例えば今回の場合、いくつかResolutionの中でも、720×480、1280×720、フルHD（1920×1280）の3種類のladderを考えたとします。

そこでいくつか評価してみると、まず720×480で動画の品質をBitrateで評価した場合、このような（グレーの曲線の）Plotになります。

次にHDとフルHDです。最大曲線をConvex Hullと言うのですが、そこを組もうとすると、実際にこのような赤文字のラインが組めることがわかります。

そうすると、ここの中で効率的なRenditionはどこなのかを考えると、Bitrateを上げた分、必ず品質が上がるようにしていきたいということであれば、三角（スライド図▲）のラインからRendition ladderを組むことが非常に有効だとわかります。

この中から必要に応じて画角を考慮した上で、Rendition 選択することで、Bitrateの向上に対して、効果的な品質の向上が見込まれるRendition Ladderとなります。

とはいえ、みなさん業務の中で動画を1つしか使っているわけではなく、多種多様なタイトルを扱っていただいているので、タイトルごとにやるのは非常に手間だと思います。実際、先ほどの8個のRenditionを決定するのに14回もEncodeが必要になっています。

なので、1つのやり方をsuggestionさせていただくと、いろいろな動画を配信されている中で、カテゴリごとに最適なRendition ladderを検討することが現実的にとれる効果的な改善策かと思います。

どのようにすればいいかというと、Fixed CRFでのEncodingを行い、カテゴリ内の全動画コンテンツのAverage Bitrateを算出することで、その動画の複雑さを測ることができます。

そこで、カテゴリー内の全動画コンテンツの、複雑さをAverage Bitrateから算出することで、どのように最適なRendition ladderを組めばいいのかという動画カテゴリ内での1つの指標にすることができます。

Rendition ladderの適用例と動画の評価指標

BITMOVIN社が出していた適用例のデータを紹介させていただきます。

あるタイトルのRendition ladderを、先程紹介したやり方で組み、実際に動画の品質を評価した結果となります。

本結果は、一部のRendition、ResolutionBitrateでは、非常に効果的にActual Bitrateを下げつつ、PSNR・動画品質を向上させることができたという結果が出ています。

今のEncodingのやり方について、少しサマリをさせていただくと、今回はPSNRという指標でご紹介はさせていただきましたが、動画の評価指標はほかにもいろいろと出てきています。

現在はSSIM、VMAF（Netflix社が提唱、gitに公開）なども出てきていて、みなさんのサービスで配信されている動画も、そのような品質評価指標をどこまでされているのか、あらためて振り返っていただけたらと思います。

見直しをすることによって、ユーザーがより快適に、もっと高品質な動画を視聴することができるかもしれません。

ただし、ここに示されているPSNRやSSIM、VMAFはあくまで動画全体のAverageの評価指標が出てくるので、すごく変化の少ない映像だけれども、一部急に映像が激しくなったりするようなのもありますので、やはり最後に主観評価していただくことも重要になってきます。

今回のやり方を1つの方法として捉えていただいて、自分たちが配信している動画の品質は、果たして最適なBitrateで作成されているかということをぜひ見直していただけるといいかなと思います。

4K配信の現在

次に、今回のタイトルにもなっている4K配信についてお話をさせていただきます。

4Kの配信のテストは日々行われています。こちらは総務省が定期的に出しているデータの一部ですけれども、各社TV局といろいろな試みしています。

一般家庭に4Kテレビは普及するのか

少し聞いてみたいんですけど、お家に4K TVやモニタをお持ちの方はどれくらいいらっしゃいますか？

（会場挙手）

……2名。本日出席されているみなさんはわりと動画業界の方々とは思うのですが、意外と手が挙がらないところを見ると、やはり4Kデバイスの普及は、まだまだこれからなのかなという印象を受けます。

2年前に某テレビ局様で聞いたときには、誰も手が挙がりませんでした（笑）。今回は2人手が挙がったということで、少し普及が進んできたのかなと思います。

今、私が申し上げたとおり、4Kのテレビはなかなか普及が進んでないのが現状です。

なので、VoDではサービスとして、さまざまなコンテンツが4Kで用意されているのですけれども、ユーザー環境という意味では、そこまで整ってきていません。

なぜかというと、1つ考えられるとしたら、やはりエンドユーザー側の帯域が用意できていないということがあると思います。今だと、20Mbps程度必要になってしまいます。

Liveをイベントなどで使う分には非常にいいのですが、これからもっと普及させるためには、やはりH.256（HEVC）であったり、VP9、AV1などの高圧縮のコーデックの準備がどうしても必要になってきます。

もちろん今のままでも、4Kの配信はPublic Viewingなどでは効果的に使えます。ただし、Hybridcastを使って、ユーザー体験をどんどん上げていくような試みをすることで、4K映像をよりリアルに感じていただくために必要になってくる施策なのかなと考えています。

先ほど申し上げた、帯域についてですが、H.264での4K配信は非常に帯域を必要とします。では、VP9はどうだろうということで少し確認してみると、4KだとH.264の21.2Mbpsに対して、VP9は17.3Mbpsまで抑えることができます。

ただフルHDになってくると、逆にH.264のほうが圧縮効率が良い部分もあったりするので、安易にコーデックを全部切り替えると判断するのは、なかなか難しいかと思います。

では現状の「ゴールデンタイム」に、日本のISPはどれぐらいスピードが出てるのかというところですけれども、一番帯域が出ているISPでも4Mbps程度しか出ていません。

そう考えると、せっかく高いお金を出して買った4Kのテレビで、結局観れないという話になってしまうので、なかなか悔しい結果なのかなと思います。なので、今後の高圧縮なコーデックは非常に重要な役割もっていると思います。

4K配信に欠かせない、エンコード技術「HEVC」の現状

ではまず高圧縮コーデックの中でも、HEVCにフォーカスして見ていきます。HEVCは歴史は長いものの、なかなかbrowser supportが進んでいないのが現状です。

ハードウェアの対応や処理できるチップも必要になります。一部のIEやSafariでは動くようになっています。また最近のMacOS High Sierraでも動くようになっています。

インターネットサービスプロバイダが提供している限られた帯域の中で、HEVCの効果はどうでしょうか。例えば、H.264だと720pのResolutionでしか提供できない帯域でが、H.265（HEVC）を使うとフルHDで視聴できるようになります。8Mbpsの帯域が見込める場合はどうかというと、8MbpsではフルHDが限界です。2Kのものでもまだ配信するには足りないというのが現状のHEVCの圧縮効率です。

ただし、同じフルHDでもH.264よりH.265のほうが動画のノイズは少ないということがVMAF評価値からわかっています。

なので、フルHDまでのResolutionにおいて、より圧縮効率を高めたい、より高品質な動画を配信したいということであれば、H.264からHEVCへ移行する価値は高いのかなと思います。

H.264とH.265で同じResolutionにて、それぞれ画質評価を行ったところ、H.265はH.264の結果を上回るという結果が見られています。

（スライド）一番右のVMAF deltaというのは、Netflixが提唱している画質評価指標で確認したもので、6以上差が付いたものは、人間の目で見て明らかに品質が上がっていると感じられるレベルです。

なので、非常に小さいResolutionほど画質の評価が高いということですので、とくにモバイルユーザーには、良い効果が見られるのかなと思います。

とはいえ、HEVC使用時の負荷はどうなのか、気になると思います。そちらも少しデータがありまして、Apple devicesで調べると、やはり若干のCPUの負荷の上昇が見られるそうです。しかし、全体的に見ると劇的にCPU負荷が上がるわけではないので、とくに問題はありません。

これらの結果が出ているのに、なぜHEVCの対応デバイスがもっと加速していかないのか気になると思うのですが、みなさんご存知のとおり、HEVCはDecodeに対するRoyalty料もSubscriptionとPPVに対するRoyalty料も定義されています。

このようなこともあって、意外とみなさんから「乗り換える気がない」という回答をしています。

動画業界の方々がどのようなプランをお持ちかというと、AV1やVP9はもう少し情報が整って実装されることを待っているという結果も出ています。

HEVCの対抗馬としてのAV1の可能性

今後、AV1がHEVCに対抗するコーデックとして成長してくるのではないかということが、現状見られる業界全体のトレンドなのかなと考えています。

2018年1月には、AV1を規格しているAlliance for Open MediaへApple社も加入しているので、またハードウェア対応の加速が期待できます。

まだあまり知られていないのかなと思うのですけれども、AV1の圧縮効率の評価はどうなのかというところです。

こちらはモスクワ大学が調べた評価になります。

真ん中右にあるH.264のEncodingを100パーセントした場合に、どれぐらいBitrateを抑えることができるかという圧縮率が縦軸のパーセンテージになるのですが、AV1は約半分程度まで抑えることができるようになります。

こちらは非常に革新的な圧縮効率の良さだと思います。左から4番目のVP9でも、72パーセントの圧縮効果が見られています。

なので、AV1はVP9をさらに超える高圧縮なコーデックとして、期待できそうです。

では、なぜ早く現場に出てこないのかというと、AV1はまだ専用ハードウェアチップが開発されていないので、全部ソフトウェアでの処理が必要です。

このような試験をやるときも、Encoding自体は全部ソフトウェアでやっているので、普通にハードウェアでEncodingをやるよりも、数千倍時間がかかってしまうということがあるので、実用的ではないというのが現状です。

VP9とAV1のサポート体制

VP9はどこまでサポートされているかというと、Googleが軸足になって開発していたものなので、Browser側の普及は早いですけれども、Apple側は対応していません。

それに対して、当然ですがAV1の公式サポートブラウザはまだありません。

もし試したいのであれば、FirefoxのNightly、もしくはGoogle Chrome Canaryでは、すでにAV1のdecodeが実装されています。BITMOVIN社はサンプルのAV1の動画を置いていますので、実際に同じぐらいのBitrateの動画との品質の違いを体感いただくことができます。

現状のAV1の開発ステータスです。もともとは3月にCode Freezeをして、ハードウェア版の開発を始めたいという話だったんですけど、2018年6月現在、Code Freezeに至っていないというのが現状です。

5月31日に至ってもまだドラフトの状態となっています。

当初、2019年にはモバイル向けのデコード用の専用チップ等が出てきて、AV1はデファクトスタンダードに成長していくのではないかと言われていたものの、若干開発が遅れることも考えられます。

ということで、4K配信の部分のサマリです。4Kの配信については、各社がCodecの検討含め、いろいろなチャレンジをしているという現状です。

ただ、業界の方がこれだけ集まっていても、4Kが視聴できるデバイスがそこまで大きく普及していないところもあって、これから4Kの普及を進める為にも4Kの価値を高めていくことが重要だと考えています。

また4K配信を本格的にやりたいとなった場合、やはり高圧縮なコーデックを検討する必要があります。現状だとVP9やHEVCが選択肢に上がると思うのですが、AV1はデファクトスタンダードに成長する可能性が非常に高いと思われます。

ただ、HEVCのRoyalty料も非常に高く、当社もビジネスモデルが古いのではないかと言われていますので、今後このビジネスモデルも変わっていくのではないかと思います。

主要なブラウザであるFirefoxやChromeなどで日々AV1の準備が進んでいる状態です。YouTubeとNetflixは「AV1を押していく」と宣言しているので、そのようなところにも注目だと思います。

おそらくAppleもAlliance for Open Mediaに入っているので、デバイス等の普及も進むかと考えています。

参考までに、Akamaiの取り組みをご紹介します。

我々は配信側なので、どのようにコーデックが選択されるかはそこまで気にしていません。我々が今取り組んでいることは、もう少し先のところです。VRになってくると、8Kレベルのものを配信していかないといけないという課題があります。

そのような課題に対して、TILEDMEDIA社と協力して、8K画質の多角的なものをどれぐらい、どのようなフォーマットで配信するのがいいのかというところも含めて、頭を悩ませて日々検証させていただいているところです。

低遅延配信を実現するために

次に「低遅延配信を実現するために」です。

高画質なものを配信したいけれども、やはりLiveになってくると、遅延も気になるものだと思います。最近の遅延は小さくなっていく推移が非常に早くて、数年前までは、インターネットでLive配信する場合、45秒〜1分ぐらいは遅延するものがみなさん常識と思っていたと思います。

しかし、去年の暮れぐらいからは、20秒〜30秒ぐらいで配信できないと、インターネットの配信としては納得してもらえる品質ではないという状況になってきています。

では、Live配信のフォーマットがどのように変わってきたかというと、当初はAdobeが出していたRTMPが主流でした。そのときはインターネットを介していても、3秒〜5秒の遅延が主流でした。

弊社側でもやらせていただいていたのは、HLS DASHに変換する取り組みです。よりHTTPに特化していくことで、CDNによる配信効率を上げたり、視聴できる環境を広げたかたちになります。ただ、それによって若干遅延が伸びてしまったという現状もあります。

それに対して、WebSocketを使って、さらに遅延を縮めようと試みられた部分もありますし、HLS/DASHではSegment長を縮めることで6-8秒遅延での配信を実現しています。

最近では、1対1の通信であれば、WebRTCという話も最近出てきています。

なので、今はエンドユーザーの選択肢として、配信のやり方はこれだけあります。

出力フォーマットの比較という意味では、やはりいろいろと差分はあります。WebRTCはなかなか良いんですけど、スケールの話であったり、シンプルにABRには対応していなかったりする部分もあるので、ユーザー環境を考えて使うのであれば、一番選択しやすいのは、HLS/DASH、もしくは CMAFです。

低遅延を実現するためのポイント8つ

では、どうすれば低遅延にできるかというベストプラクティスを1つずつ見ていきたいと思います。

若干当たり前のことを書いているとは思うのですけれども、今一度あえて1つずつ見ていきます。まずEncoderでの遅延を減らすことが重要です。

Encoderでの遅延は、意外と気にされてない方もいらっしゃるのではないかと思うので、こちらについてはまた後ほどお話しします。

QualityとEncoding Speedは、Trade offになります。高画質のものを出そうとすると、どうしてもEncodingのスピードが落ちてしまうので、うまく効率的に配信するというTrade offを取ることが重要になります。

Segment Durationを小さくすることも重要です。今では2秒でもStableに配信できます。ただ、1秒になってくるとPlayerなどの視聴環境側でいろいろとチューニングが必要になってきます。

インターネットを通して配信するので、Ingestするところの遅延も気にする必要があります。

なので、Ingestを受けるClusterをできるだけEncoderの近く設置し、Ingestすることが重要になってきます。

さらに、CDNでの転送時間をできるだけ短くしましょう。こちらは我々の取り組みなのですけれども、CDN内ではできるだけ高速に確実な配信が実現できるよう設計されています。

Last Mileの部分では、RTTをできるだけ短くする必要があります。また、配信サーバ（Edge server）をできるだけエンドユーザーの近くから配信することも重要になってきます。

そのユーザーがデータをダウンロードした後、Startupに必要なプレイヤー側のBufferを限りなく短くすればするほど、Low Latencyでの再生が実現できます。

ただし、みなさんもすぐわかると思うんですけど、もちろんRebufferingを生んでしまうリスクもありますので、ABR(Adpative Bit Rate)の動きをチューニングすることでそのリスクをより小さくする必要があります。

また、Chunked TransferによるCMAFセグメントの利用を検討することも1つのやり方としてあります。

最後に非常に重要な部分です。Low Latencyとはいえ、配信が止まってしまっては元も子もないので、冗長化構成を組むことが必要になります。

各コンポーネントにおける遅延の目安

AkamaiのMedia Services Live 4 (MSL4)では、Akamaiのプラットフォーム内はすべて冗長化されています。今だと2msで、約10秒ぐらいの遅延で配信することができます。

内部のプラットフォームは500ms以内にすべて切り替わるように設計されていますので、非常に強固な配信プラットフォームとしてご利用いただくことが可能です。

とは言え、遅延はどこを目安として見たらいいのかということを挙げさせていただきます。

Encorder、First-mile、CDN、Last mile、最後のPlayerの部分と見たときに、10秒セグメント、トータル50秒ぐらいの遅延で配信するときに、これぐらいの内訳で考えていただければいいのかなと思います。

2秒セグメントのときはどうなのかというと、トータル11秒ぐらいということで、これぐらい縮まります。

もしこれよりも大幅に外れる部分があれば、チューニングの余地があるということで、先ほど申し上げた部分を再度見直していただくことでより低遅延の配信が実現できると思います。

Encoderの設定における留意点

先ほど少し申し上げた、Encoderの部分について、どう設定すべきかという1つの見解をお話しさせていただきます。

HLSの場合、弊社側でサポートしている2秒セグメントでやってみましょう。

Manifestに含めるChunk数は3とします。HLSの仕様に即さずに思い切ってしまうのであれば、2つに縮めることもできます。

次に、みなさんはおそらく30fps程度のFrame Rateを使っていらっしゃるのかなと思うのですが、その場合にKeyframeを挿入する間隔を30にしておく必要はなく、60にしておくことで2秒のセグメントの中に1つのKeyframeを挿入する形になります。

このKeyframeを入れる処理は、Encoder上では負荷が高い処理になるので、入れるタイミングをセグメントごとに1回で済ませると、処理速度が改善される可能性があります。

また、AdvancedのCPU処理も、Encoderのパワーを消費しますので、一部画質のTrade Offになる可能性もありますが、できるだけLow Latencyで出したいということであれば、こちらを思い切ってOffにすることで恩恵を得ることができるかもしれません。

さらに、利用される可能性の低い、必須ではないLow Bitrateを見直してください。そのようなBitrateが含まれていると、Encoderの処理が重くなりますので、そのようなものをできるだけ排除することが重要になってきます。よりBitrateの小さいStreamを作ろうとすると、より圧縮を頑張るEncoderは負荷が大きくなります。

そしてもう1つ上げるとすれば、あえてBフレームを使用しないということです。

Client側でのPのdecodeには、最初のIとBのデータが両方必要になりますので、decodeの処理待ち時間をできるだけ短くする意味だと、あえて予測の入っているBフレームを使わずに配信してしまうのも1つの手です。

今申し上げたのは、Low Latencyを目標にした場合の話なので、一部画質とのTrade Offになるケースもあります。

なので、打ち上げようとした動画がどれくらいの画質になっているか。今までやっているものに対して、どれくらい差があるのかを見極めていただきながら、Encoderの設定をどうするのか検討していただく必要がありますので、ご注意をお願いします。

LiveにおいてQUICはどこの段階から必要になるか

次は、LiveにおいてQUICはどこの段階から必要になるかという話です。

QUICはユーザー環境のLast mileの環境が悪ければ悪いほど効果があって、使っていただくのはもちろんベターなのですが、どこから必須となるかという観点でお話しします。これはTCPの再送制御の視点からのお話です。

Windows 10のTCPの再送処理タイマ(RTO)の初期値は3秒です。

さらに再送を繰り返していくと、ネットワーク環境は非常に悪いと判断され、再送時間タイマはどんどん伸びていきます。

そうすると、プレイヤー側のBufferは2秒chunkだと6秒、1秒chunkになると3秒しか持てません。

RTOが3秒しかない場合、1秒chunkだと再送するまでにRebufferingが発生して、破綻してしまいます。

なので、2秒chunkの場合には必須ではないけれども、1秒chunkのときには必須になってくるということが1つの見解として挙げられます。

2秒chunkの場合でも、Manufestに含めるBufferの数を3つではなく、2つにしていく場合には、このようなQUICの取り組みが非常に重要になってくるのかなと思います。

あともう1個挙げるとすれば、CMAFのChunked contributionの恩恵を受けることで、よりスタートアップタイムが早くなります。

このあたりを実験していただくこともできる環境は整ってきていると思いますので、ぜひお試しいただければと思います。

もうみなさん30秒から45秒のLatencyのところにいる必要はなくて、DASHのパススルーでも2秒セグメントで配信することで、15秒〜18秒ぐらいまでいけます。

さらにCMAFを使ったり、HLS/DASHの1秒セグメントを使うことで、10秒を切るようなLatencyも実現することができますので、ぜひみなさんぜひトライしていただければと思います。

サマリとしては、小さいセグメントサイズは、Latencyを下げるのには有効です。

有効なのですけれども、プレイヤーの動きのチューニングは必須になります。縮めれば縮めるほどBufferingのリスクは上がりますので、プレイヤーはうまくハンドリングできるような実装が必要になってきます。

とくにスタートアップを縮めるためには、このようなポイントが必須になってきます。

ぜひ今後、CMAFへの取り組みにも積極的にトライしていただきたいですし、最近はWebRTCなども出てきています。今は1対1の通信の話がメインで取り組んでいると思うのですけれども、1対多にスケールできる話になってくると、非常におもしろくなってくるのかなと思います。

最後に忘れずに、Low Latencyを実現する際にも、冗長化は必須になります。

次世代プロトコルQUICの取り組みと登場背景

最後にQUICの話を少しさせていただきます。

みなさんご存知の方は多いかと思うのですが、もともとTCPレイヤーの上でHTTP/2で通信をすることで、配信をしていたのですけれども、そこの再送処理や効率的に配信する部分の話を、全部QUICのレイヤーでやってしまおうということがQUICの取り組みの概要になります。こちらは弊社のPrincipal Architectのエンジニアが実際にQUICの一部のDraftを執筆中です。

QUICが使われるのはどこなのかと、現状Last mileの部分でQUICが使えるようになってきています。ここをUDPの通信にして、できるだけ早くエンドユーザー様にデータを転送することによって、より低遅延で効率の良い配信をしようというのがQUICの取り組みになります。

なぜQUICが出てきたかというと、Connection確立のオーバーヘッドであったり、転送の順番が詰まってしまうという問題があったりましたので、それらの問題を解決するためにQUICが出てきてたという流れになります。

ではAkamaiのQUICは何をベースに実装されているのかと言うと、Google QUICでも使われているChromiumというプロジェクトのコードをベースにしています。

IETFの会合でいろいろと決まったことがあると、Chromiumのコードが更新されますので、Akamai側のコードもそのたびに順次アップデートされています。

今後、Google QUICもIETFで定義されているQUICに向かっていきます。

Akamai側でQUICを動かす条件はGoogle社と違うところがあります。Akamaiでは、Chromium側のコードのアップデートとは別に、Akamai側のTCP、QUICのプロトコルに特化して、サーバーでどれだけ効率的に転送ができるかということに注力しているProtocol Optimizationチームがおり、そこのチームがどの条件でQUICを動かすかを詳細にチューニングしています。

もともとAkamaiのTCPは非常に高速で、すごくうまくチューニングされています。なので、Akamaiからの配信の場合、QUICだから単純に高速通信ができるようになるわけではありません。

あくまでAkamaiが使っているTCPは高速なので、UDPのQUICを使ったほうが早いと判断したときにだけ、UDPのQUICを動かすような処理を目指して日々チューニングを行っています。

逆に、UDPが使える状況でも、TCPじゃないと効率が落ちてしまうような場合には、TCPを優先して使うような判定を目指しています。

なお現状の予定では、7月16日より一部Akamaiの配信Solutionにて、プラットフォーム側で自動的にQUICがONになるような動きをするようになります。

AkamaiとGoogleにおけるQUIC開始の違い

こちらは何を示しているかというと、左側はアメリカのIPSプロバイダ。右側はEUのISPプロバイダです。

これらの棒グラフは、QUICの通信がTCPに比べてどれぐらい転送効率が上がったかというグラフになっているのですが、一番右の青い棒グラフは、Akamaiがきちんとネットワークごとに輻輳制御をチューニングした結果、単純にQUICを使用するよりもはるかに転送効率のよいQUICの通信を実現していることが示されています。

真ん中の紫色の棒グラフの7パーセントはQUICのDefaultの輻輳制御、一番左の赤い20パーセントというのは、AkamaiのQUICのDefault値を使った場合です。

このように、きちんと制御をしないと、効果的なパフォーマンスアップは見られないので、このあたりはAkamai側も非常にセンシティブに日々チューニングを行っています。

次にQUICのNegotiationの開始はどのようにされるかというところにフォーカスして見ていきます。

今、IETFで定義されている方法が2つあります。

2018年6月現在、その2つのうち、Google社とAkamaiはともにHTTPの”alt-svc”ヘッダを使ってQUICのNegotiationをしています。

AkamaiでのQUICの開始はどのように始まるのかというと、ある程度TCPのレイヤーで通信をして、HTTPSの通信をいくつかしたあとに結果としてQUICで通信したほうがが効率が良いネットワーク完了であると判定された場合、QUICに切り替えます。そのときのalt-svcのmax-ageは1時間で出しています。

同様の内容をGoogle社のQUICと比較してみました。半月ぐらい前に確認した結果なので、今も同じかどうか、みなさんもやってみたらおもしろいかなと思います。

TCPのセッションが確立した直後、HTTPSの通信が始まると同時にQUICのHelloが飛んでいます。

さらにalt-svcのmax-ageが長めの1ヶ月と出ていますので、GoogleのドメインではQUICの通信が多い傾向にあるということが頷けます。

Google社が通信している内容と我々が配信している内容はけっこう違いまして、Google社は自社サービス、自社ドメインでQUICを動かしているのですけれども、我々はお客様のトラフィックを転送させていただいているので、より効率的にできるようにということに注意を払いながら、よりセンシティブにチューニングを続けています。

先ほども申し上げたとおり、IETFで日々QUICの議論がされているのですが、まだまだ議論中のトピックが残っています。

TCPだとPasseive RTT（latency）を計測するためのSpin Bitが入っているんですけど、QUICではそれが定義されていないということで、同様の機能をもたせたSpin Bitと呼ばれるFieldを定義しようという話が出ていますが、実装するかどうかは今後のバージョンで考えるとなっている状況です。

また、現状のQUICは、HPACKと呼ばれるHTTP/2でのヘッダ圧縮方式が使われているのですが、今後はQPACKと呼ばれるQUICの新しいヘッダ圧縮方式に変わっていくと思われます。

あとはネットワークが変わっても、同じコネクションを継続できるようにということで、Source IDとDestination IDの2つを持つことで、できるだけスムーズに通信を継続できるようにする、という実装が議論されています。

ECNは提案はされているのですが、現状では実装されないかもしれません。

最後は、クライアント側のQUIC対応です。

JavaScriptのプレイヤー向けには、AkamaiからMedia Acceleration SDKが提供されています。iOS、Android向けのQUIC対応には、Chromium Library（Cronet）が公開されていますので、こちらを使うことで非常に容易に実装できるようになってきています。