Akamai Diversity

Akamai Japan ブログ

通信品質が悪い環境におけるQUIC(Akamai Media Acceleration)の有用性について

-->

2017年8月にGoogleはQUICに関する論文をコンピュータ科学分野の国際学会(ACM: Association for Computing Machineryにて発表しました。

 

QUICによる通信のTrafficはインターネットの7%を占めていると推測され、Googleがユーザに配信する
Trafficの3割はQUICが用いられています。

        "The QUIC Transport Protocol:Design and Internet-Scale Deployment"より翻訳して転記

 

※論文はACMのホームページより閲覧できます

 

QUICについてはAkamaiも取り組んでおり、本Blogにおいて以前にも取り上げております。

「UDP/QUICを使用した高速化 - Akamai Media Acceleration」

 

今回はQUICの有用性を確認するためサーバ⇔クライアント間の通信に負荷(レイテンシ、パケットロス)を発生させ、TCPとAkamai Media Acceleration(以降QUIC)における違いを比較し、通信品質が悪い環境におけるQUICの有用性を確認してゆきます。

<!--

検証概要

TCP、及びQUICプロトコルでファイルダウンロードを行い、ダウンロードに要した時間を計測します。

取得に要した時間と取得したファイルサイズをもとにスループット(Mbps)を算出します。

単純なファイルダウンロードではなく動画視聴を想定し、HLSプロトコルを用いて動画プレイヤーでコンテンツ(.ts)をリクエストします。

 

通信品質を劣化させる環境を模倣するためLinuxのTCコマンドを用いてInbound(サーバ→クライアントへのTraffic)、Outbound(クライアント→サーバへのTraffic)にそれぞれレイテンシやパケットロスを与え検証を行います。

TCコマンドによってクライアントNICにキューイングされたパケットは指定時間のWait(レイテンシ)、指定割合の破棄(パケットロス)が処理されます。

  

検証環境

クライアントディストリビューション Fedora 26
ブラウザ Chrome 60
回線環境 モバイルWIFIルータ(速度計測サイトで38Mbpsを記録)
プレイヤー AkamaiMediaPlayer V2.69.18(AkamaiのSDKで作成された動画プレイヤー)

 

検証内容

3.6~5.0MBの15個のファイル(6MbpsのHDコンテンツ相当)にリクエストを発行し1つのファイルを何秒で取得できたかを元にMbpsの値を計算します。

値は同じ試験を3回実施(計45個のファイルダウンロード)した際の平均値を利用します。

 

回線環境の変動を加味し、負荷(レイテンシorパケットロス)を掛けた状態→通常状態→負荷状態...と交互に計測を行います。

 

レイテンシは100msec、パケットロスは1%の割合で発生させます。

 

今回は以下の検証パターンを計測します。

QUIC Test Patternv2.png

検証結果

以下はInbound Traffic(サーバ→クライアント)に対して負荷を掛けた場合のTCP(http1.1)とQUIC利用時の計測値となります。

青色棒グラフは通常時、橙色棒グラフは負荷時の計測値を示し、両者の差分が無いほど負荷の影響を受けていない事を表します。

QUICの検証結果図1v2.png 
QUICの検証結果図2v2.png  

以下はOutbound Traffic(クライアント→サーバ)に対して負荷を掛けた場合のTCP(http1.1)とQUIC利用時の計測値となります。 

QUICの検証結果図3v2.png
QUICの検証結果図4v2.png

以下は各計測値をまとめた表であり、スループット低下率は通常時と負荷時を比較し、何%下がったかを示します。

つまりスループット低下率が小さな値ほど影響を受けていない事を示します。

 

水色網掛け部はQUIC利用時の値となります。

Table1. TCPとQUICでの計測結果まとめ

QUICの検証結果表v2.png

TCPと比べQUICでの通信を行った場合、Inbound x パケットロスのパターンを除きスループットの低下率は1/3以下の数値に収まる事が分かりました。

(低下率はクライアントや通信地点の環境によって変動するため、全ての環境で1/3以下になるとは限りません)

総じて、負荷が掛かった環境においてはTCP(http1.1)と比べQUICが影響を受けにくい事が分かりました。

  

これらの結果が得られた背景にはQUICでUDP通信となった事、ロスリカバリの仕組みが変わった事が影響していると考えられます。

 

TCP通信では信頼性を得るためデータ送信、ACK返信を繰り返します。

パケットロスが発生すればACKを待つ時間が発生し、次のデータ送信が行われません。
(HOLブロッキング:正確にはもう少し深い話になりますが、ここでは割愛します)

レイテンシが発生すればACKの受信が遅れ、付随して次のデータ送信が遅れてゆきます。

UDPを用いる事でTCPのようにサーバ/クライアント間で何度もやりとりしなくなり、通信が減少する事に伴い、レイテンシの影響も減少してゆきました。

 

QUICではUDPでデータを送りつけ、パケットロスが発生した場合のロスリカバリはTCPとは違う方式を用います(TCPのロスリカバリでネックとなっていた問題を解決)。

 

上記についてはIETFのQUICドラフトドキュメントを参照すると詳細に記載されております。

draft-ietf-quic-recovery-07
QUIC Loss Detection and Congestion Control

 

まとめ

モバイルデバイスの浸透により、動画視聴のみならず様々な場所、時間にてコンテンツの取得が行われております。

そしてコンテンツ取得を行う環境(移動する電車の中、混雑する人混み、ピークタイム等)においては必ずしも全てのデバイスが良好な通信環境にあるとは限りません。

 

これまでのTCP(http1.1)の通信と比較して、QUICは通信品質が悪い中でも影響を受けにくくし、エンドユーザの動画視聴やリッチコンテンツの閲覧などユーザ体験を今まで以上に向上してくれるものと考えます。
(今までの体験では満足できない新たなユーザを取り込む、今まで以上のユーザ体験を提供しユーザを逃がさない)

冒頭に述べた通り、既にインターネットの7%はQUICで通信されていると言われ、今後も普及は進んでいくものと考えられます。

 

QUICの利用に際してはAkamaiで配信する事により、お客様のWEBサーバに特別な実装をする必要はありません。

(ユーザ側のクライアントにはAkamaiが提供するSDKを組み込む必要があります)

また、Akamaiでの配信はQUICの利用のみならず、Akamaiによる輻輳制御の恩恵も受けられ最大のパフォーマンスを引き出せます。

QUICはAkamaiのObject Delivery、Download Delivery、Adaptive Media Deliveryの配信製品で利用する事ができます。

既にAkamaiをご利用されている皆様、QUICによる配信を手軽に行いたい皆様、是非ご検討をいただけますと幸いです。

 

10/11-13にかけてラスベガスにてAkami Edgeというイベントが開かれましたが、その際にもQUICの話が出ました。

Akamaiコミュニティにログインする必要がありますが、以下から資料の閲覧が可能ですので是非ご覧下さい。

Akamai Edge資料ページ

資料名:Media Acceleration and QUIC Optimization

 

Leave a comment