Akamai Diversity

Akamai Japan ブログ

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

UDPとTCP

データの大容量化や、モバイルでのインターネットの閲覧の普及により、より良い品質での通信が求められるようになって来ています。 現在、Webの世界で広く用いられているTCPプロトコルは、厳格な通信プロトコルで、通信環境の悪い所でも、再送制御や輻輳制御を実装する事で、信頼性の高い通信を維持する事が可能です。

TCPでは、"スリーウェイハンドシェイク"で送信、受信側のセッションを確立させた後、データパケットの送受信をACKパケットで確認しながら、データが届かない時はデータを再送信する等の制御を行い確実にデータを届けるプロトコルです。

また、一度に送るデータサイズは、小さなデータよりも大きなデータの方が、送受信の制御パケットの数が少なくできるため、転送効率が良くなります。そのため、TCPでは、送信データサイズを、確実に送信できそうな小さなデータからはじめて(スロースタート)、様子をみながら一度に送るサイズ(ウィンドウサイズ)を少しづつ大きくし、転送効率を上げていくなどの制御が行われています。

一方で、一度に大量のデータを送りすぎると、回線が混雑(輻輳)してしまうため、パケットのロスが起きた時は、一旦ウィンドウサイズを小さくするなどの制御も同時に行われ、データを安全、確実に届けるための様々な工夫が実装されています。 udpvstcp.jpg

TCPは非常に良く考えられたプロトコルですが、このような送信側と受信側のきめ細かなやりとりは、やりとりがきめ細やかな分、距離や回線の品質によりネットワークの遅延が大きい時は、データの送受信にかかる時間に大きな影響をもたらす事になります。

TCPの後に開発されたUDPは、音声や動画通信に向けて、低遅延を目指した設計がされています。TCPで実装されていた細かな送受信制御はそぎ落とされており、パケットロスなどデータの到達性については保証されていません。 UDPは、そのようなデータロスが本質的に大きな影響を及ぼさないIP電話やビデオ電話の世界で広く用いられています。

UDPを利用した新しいプロトコル

時代が進むにつれ、TCPの確実性とUDPの遅延の両方の良い所取りをした新しいプロトコルが求められるようになってきました。とは言え、全く新しいプロトコルを作成するのは既に世界に広がってしまった無数のネットワーク環境がTCP、UDPでの通信を目的に作られている現状を鑑みれば、新しいプロトコルを作成したとしてもネットワークの到達性の観点から現実的な選択肢で無いと言って良いでしょう。 TCPが定義された当時より良いアイディアが出てきたからと言って、単純にTCPに手を加えて実装させると、既存の資産との互換性など、考慮すべき点がいろいろとでてきます。

そこで、様々なベンダーが、縛りの少ないUDPをベースに、UDPより上位のスタックで信頼性を確保するための実装を施した、いろいろなプロトコルを提案してきました。 一例では、Akamai の NetStorage に、オプション設定されているIBM社のAsperaは、巨大なファイルの高速アップロードをUDPをベースにした独自プロトコルfaspにより実現しています。

また、Google社でも同様のUDPベースのプロトコルとしてQUICを提唱し、自社のサービスを使用した実証実験を進めています。 QUICは、自社の巨大なインフラを使った実証実験とSPDY/HTTP2で培ったオープンな手法で、ここに来て新しい標準となりそうなプロトコルとして注目を集めています。

Googleによる実証実験が進むQUIC

もし皆さんがGoogle Chromeブラウザをお使いであれば、GmailやYoutube等のGoogleのサービスを開いた状態で、Chromeのアドレス・バーに以下のように打ち込んでみて下さい。

chrome://net-internals/#quic

google_with_quic.gif

QUICを使用するには、サーバー側とクライアント側の双方で対応が必要ですが、現在、Googleの各種サービスを提供しているサーバーと、Chromeブラウザの間では既にQUICでの通信が行われています。 QUICは、TLS通信が前提となっており、使用されるポートはUDP/443になっています。

GitHubに公開されているソースコードを使用すれば、ライブラリを活用して自身のWebサーバーにQUICを実装する事も可能になっています。 御興味のある方は、サンプルのサーバーとクライアントのソースも公開されているので、自分のQUIC環境を作って遊んでみる事も可能です。

QUICは、現在、IETFでの標準化作業が進められており、2017年の1月には Akamaiの日本のオフィスで QUIC Working Group が開催される等、AkamaiもQUICの標準化に向けたお手伝いをさせて頂いています。

QUICは、TLS接続が前提となり、送信側と受信側のハンドシェイクを減らすための工夫などが盛り込まれています。ただ、現在でも標準化作業中であり、技術的な詳細は今後も変わっていく可能性があるので、ここでは技術詳細については触れないでおきます。

Akamai が描くUDPを使用した通信の将来像

Akamaiでは、ビデオのLive配信、On Demand配信や、ゲームソフトなどの大型のダウンロードファイルに置いて、UDPプロトコルを用いた通信をオプションとして選択できるように計画しています(一部実装済み)。 例えばLive配信におけるビデオEncoderからAkamaiへのUDP通信は、2015年に買収したoctshape社の技術をベースにしたものを採用する予定ですが、Akamai Edge Serverからエンドユーザー間については、前述のQUICが既に幾つかのAkamai製品で使用可能です。

akamai-media-acceleration2.jpg 4K動画は、現状の通信方法でも何とか配信は可能ですが、8K等の高画質や、さらに大きな解像度が要求されるVRデータ(例えば360度の高画質画像を配信しようとすると8Kを大きく超える高画質データが必要になります)などを見据えると、こう言った分野でUDPによる通信は広がっていく可能性があります。

QUICの使用には、前述の通りクライアント側にも対応が必要で、QUICに対応しているChrome系のブラウザを使用するか、iOSとAndroidの端末に関してはSDKを提供しています。

尚、現時点ではQUICを提供できるAkamaiのドメイン名は、*.akamaized.net等のAkamaiのドメイン経由に限られています。

実環境でのAkamai Media Acceleration

Akamai Edge Server-End user間のQUICの効果を実環境で簡単に検証してみました。 数回程度の測定の簡単なテストなので、あくまでご参考程度にご覧下さい。

実験環境は、HLS動画を再生するWebページを作成し、QUICに対応している Google Chromeを使用して、Akamaiの通常のEdge Server経由と、QUIC 対応 Edge Server経由でそれぞれアクセスを行い、HLS動画の各セグメントのダウンロード速度の合計値を比較してみました。

本来はwgetやcurl的なツールを使いブロックサイズ等の条件を変化させて柔軟な測定をしたかったのですが、私のWindows環境でQUIC通信ができる良いコマンドラインツールをみつけられなかったため、繰り返しセグメントをダウンロードしてくれる(テスト回数を稼ぎやすい)動画Player+QUICに対応しているChromeという組み合わせで実験を行っています。

テスト環境のDownload速度を、Speedtestのサイト(www.speedtest.net) を使って測定したものを参考情報として記載しています。構成としては、Webサーバー上にHLSのビデオを配置した単純なOnDemandのビデオ配信の構成です。 また、Akamaiの配信プラットフォームはAMD(Adaptive Media Delivery)を使用しました。 実験は、ユーザー端末とEdge Server間の速度だけを測るため、はじめに数度、動画を再生してEdge Serverに動画のセグメントをキャッシュさせた上で行いました。通信はどちらもHTTPS通信ですが、通常の通信はHTTP/1.1、QUIC側の通信はHTTP/2が使用されています。

環境1: Akamai Japanのオフィス内(有線LAN, Speedtest Download速度 178.50Mbps)

http/1.1 office_without_quic.jpg http/2+quic/35 office_with_quic.jpg セグメントのダウンロード時間比較 office_LAN.jpg Akamai Japanのオフィス内(有線LAN, Download速度 178.50Mbps)で、Chromeを使ってHLS動画を再生してみました。

Waterfallのチャートを比較すると、セグメント全体のダウンロード時間は、Playerが必要な分をバッファリングした後、次のダウンロードを待ってしまっているので、どちらのグラフも殆ど変わっていません。

個別のセグメントファイル毎のダウンロード時間に注目して、最初の11セグメントのダウンロード時間の合計を計算したのが、最後の表になります。 QUICが使用されている場合は、若干速くなっているように見えますが、誤差の範囲かもしれません。

環境2: Akamaiオフィス隣接ビル内(Wirelessルーター, Speedtest Download速度 38.22Mbps)

http/1.1 wireless_withoutquic.jpg http/2+quic/35 wireless_withquic.jpg セグメントのダウンロード時間比較 Wireless_Router.jpg

こちらの結果は、オフィスの環境と違い、モバイルルーターを使ったものです。

Speedtestのサイトを使った測定で、38.22Mbpsを記録しており、回線速度はそこそこ良い良好ですが、実験結果を見る限りQUICを使用した通信の方が短い時間で各セグメントをダウンロードできるという結果になりました。各セグメントのダウンロード時間を示すWarterfall上のバーもQUICの方が短くなっています。

以上の結果を見る限りでは、回線品質が悪いほど、QUICの効果が表れる。という想定通りの結果が出ているように見えます。

また実験中に通常のHTTPS(HTTP1.1)通信からQUICに切り替わる動きも確認できました。Chromeブラウザは、QUICでの通信が上手くいかない場合は通常のHTTPS通信に切り替わるように実装されている事がわかります。Akamaiが提供するSDKを使った場合も同じ動作になり、UDP接続ができないような場合はTCP接続に切り替わります。 TCPUDP_FALLBACK.gif

まとめ

Akamai Edge Server - End user間のQUIC(Akamai Media Accleration)の機能は、Object Delivery、Download Delivery、Adaptive Media Deliveryで、2017年5月初旬から使用可能になりました。

また、前述した通り、現時点ではQUICを使用できるEdgeServerは、*.akamaized.net等のAkamaiのドメイン限定になります。

ブラウザはQUICに対応したChrome、Opera等のブラウザか必要になりますが、モバイルアプリでは、iOSとAndroid向けにSDKを提供しているため、モバイルアプリに組み込んでQUICを試す事ができます。 (2018年8月追記:AkamaiでのSDKの提供は終了致したため、現在では Googleが公開している Cronetの使用をおすすめしています。尚、SDKページで公開されている「Infinite Media Acceleration SDK」は、Infinite Products(旧Octshape社)用の SDK で QUIC を使った製品とは別の製品になりますのでご注意下さい。)

(尚、動画Player向けに提供されているJavaScript SDKは、Akamai Edge Server側の設定を有効にしなくてもQUICの機能を有効にするためのもので、JavaScript SDKを組み込んだ動画Playerを使用した場合でもChrome等の対応ブラウザが必要になります)

Leave a comment