【レポート】ストリーム配信体験

目的

　Webカメラを用いてリアルタイムストリームサーバを構築し、ネットワークの混み具合（帯域変動）などにより画像の品質が変化する様子を体験し観察する。

実験システムの構成および実験方法

・実験システム

実験システムを図１として以下に示す。

・実験方法

（１）Webカメラのストリーミングサーバを構築した。

（２）パケットシュミレータ（今回はethBLOCKを使用）により帯域制限やパケット遅延を発生させ、その度合いにより画像の見え方がどのように変わるかを観察した。

基本測定項目により実験

測定内容

　パケットシュミレータを通常状態にし、映像をTCPとUDPの２つプロトコルでストリームを配信し、以下の４観点からストリームの状態を観測した、また、エンコーダのビットレートは1128Kbpsとした。

            (a)映像の状態(S1～S7)

            (b)受信の平均通信量(Kbps)

            (c)送信の平均通信量(Kbps)

(d)サーバとノートPC間での映像の遅延時間(秒)

(a)映像の状態(81~87)の内容を表1として以下に示す。

表１：状態一覧

測定結果

　通常状態において、映像をTCPとUDPでストリームを配信したときの４観点の内容を表２として以下に示す。

表２　通常状態におけるTCPとUDPの通信状態

分析と考察

　　表２より、TCPの場合の受信平均通信量は１１３０Kbps、UDPの場合は１１３０Kbpsであることがわかる。今回、ビットレートを１１２８Kbpsに設定している中で微小な誤差を除けば、受信平均通信量のTCPとUDPどちらにおいても、正常な送受信が行われと言える。

　　また、UDPの送信平均通信量がないのに対し、TCPでは２３Kbpsであった。さらに、遅延時間はUDPが１０秒に対し、TCPでは１３秒遅い２３秒であった。TCPは受信側から送信側にパケットが無事に届いたことを知らせるACKと呼ばれるものを送る。UDPはこの作業がなく一方的にパケットを送り続ける。この為、TCPの方が遅延時間が長いのである。

ネットワークの帯域に制限をかけることによる通信状態の変化による実験

観点（目的）と測定内容

パケットシュミレータの設定を変更し、ネットワークの帯域に人為的に制限をかけた。

この帯域制限の値の変化により、映像の見え方などの違いを測定した。

測定結果

　　TCPとUDPの場合で２０～１６００Kbpsの範囲でネットワークの帯域制限を行った結果を表３，４として以下に示す。

表３　TCPにおけるネットワークの帯域制限に伴う通信状態

表４　UDPにおけるネットワークの帯域制限に伴う通信

分析と考察

　今回、パケットの種類ごとに、使用できる回線容量(通信速度)を制限する帯域制限が、小さくなるにつれてTCPは遅延時間が長くなるに対して、UDPは、ほとんど変化が見られない。これは、TCPは一度に送れないデータは再送しているのでその分、遅延時間がかかるのに対して、UDPは一方的にデータを送り続けているので遅延時間に変化はなかったと考えられる。

次に、帯域制限を小さくするにつれて、今回の実験ではビットレートを１１２８Kbpsとしたが、これ以下になると、映像の状態を見ても分かる通り、映像が乱れている。これは、ビットレートに対して帯域制限が小さすぎると、一度に送れるデータが少なくなり、映像データを送るのに時間がかかりすぎてしまうため、映像が時たま停止したり、キーフレーム転送状態になったり、映像は映らないが音声のみが聞こえるなどといった映像の乱れが生じると考えられる。キーフレームとはビデオクリップに一定の間隔で挿入される完全なビデオフレームであり、キーフレーム間のフレームには、キーフレーム間で発生する動きやシーンの変化に関する情報が入っている。

次に、TCPとUDPにおいて、どちらも帯域制限を小さくすると受信平均、送信平均は小さくなっていった。これは、帯域制限が小さくなると一度に送受信できる量も減ることになるからだと考えられる。

また、ビットレートが１１２８Kbpsなので帯域制限を１１２８Kbpsより小さい、今回だと１０００Kbpsにすると十分なデータの送受信ができなくなってしまうので、TCPとUDPの二つにおいての１４００Kbpsと１０００Kbpsの受信平均の差が大きい原因が分かる。さらに、受信平均の差が大きくなるということはその分、受信する時間かかることになるので１４００Kbpsと１０００Kbpsにおいての遅延時間の差が大きいことも分かる。

パケット破棄率の変化による通信状態の変化による実験

観点（目的）と測定内容

パケットシュミレータの設定を変更し、通信路を通るパケットを一定の割合で削除するようにした。この破棄率の変化により、映像の見え方の違いを観測した。

測定結果

　TCPの場合は２～１５％の範囲で、UDPの場合は２～４５％の範囲でパケットの破棄を行った結果を表５，６に示す。

表５　TCPにおけるパケットの破棄に伴う通信状態

表６　UDPにおけるパケットの破棄に伴う通信状態

分析と考察

表５より、TCPの場合ではパケット破棄率６%までは映像の状態はＳ１であったが、８％以上になると一気に映像の状態が悪くなり、受信平均も減少していくのがわかる。つまり、TCPではパケットが破棄されてしまうと、その分映像に影響してしまうことがわかる。このことは、TCPはパケットがきちんと送信できた場合、ACKパケットが返ってくるが、もし送信中にパケットが破棄されてACKが返ってこない場合、再送機能によって再送され、そしてその分の時間がかかるということからも言える。

　一方、表６より、UDPの場合ではパケットの破棄率１５％まで映像の状態がＳ１であった。これは、パケットの破棄による再送機能がなく、次々にパケットが送信されるため破棄率が高くなっても映像を配信することができたのだと考えられる。

パケット遅延時間の変化による通信状態の変化による実験

観点（目的）と測定内容

　パケットシュミレータの設定を変更し、通信路を通るパケットをパケットシュミレータによって人為的に遅延を発生させた。

測定結果

　TCPの場合は１００～２０００msの範囲で、UDPの場合は１００～４０００msの範囲でパケットの遅延を行った結果を表７、８に示す。

表７　TCPにおけるパケットの遅延に伴う通信状態

表８　UDPにおけるパケットの遅延に伴う通信状態

分析と考察

　表７，８から、パケット遅延時間を増やすことによって、映像状態が悪くなっていき、パケットの送受信も減少することが分かった。しかしパケット遅延時間を増やすことによって、TCPは遅延時間が大きくなっていったのに対してUDPでは遅延時間に変化がほとんど見られなかった。これは、TCPでは、パケットを送信したときACKパケットが返ってこなければ次のパケットを送ることはできない。パケット遅延時間を長くしていくとACKが返ってくる時間も遅くなるため遅延時間が伸びたと考えられる。しかしUDPでは遅延時間に変化がなかった。これはUDPの仕組みとしてパケット送信はサーバ側とは関係なく次々に送るということに関係があると考えられる。パケット遅延時間を増やしておいくことで初めに送ったパケットがクライアント側に届くのが遅れる。しかし届くのを確認しないためサーバ側は随時パケットを送信している。これによりクライアント側も随時パケットを受信することになるので上記のような結果になったと考えられる。

片方の回線のみの制限をした場合の通信状態の変化による実験

観点(目的)と測定内容

　　（１）ethBLOCKで上り回線（ノートPC→サーバ）のパケット破棄率を１００％した時のTCPとUDPによる違いを観察した。

　　（２）ethBLOCKで上り回線（ノートPC→サーバ）のパケット遅延を最大４０００msとした時のTCPとUDPよる違いを観察した。

　　　また、（１）、（２）の観察は動画再生の前後で行った。

測定結果

　　TCPとUDPの場合の（１）における動画再生前後の変化を表９、１０として、（２）における動画再生前後の変化を表１１、１２に示す。

表９　TCPにおけるパケット破棄率を１００％にしたときの動画再生前後の変化

表１０　UDPにおいてパケット破棄率を１００％にしたときの動画再生前後の変化

表１１　TCPにおいてパケット遅延を最大値４０００msにしたときの動画再生前後の変化

表１２　UDPにおいてパケット遅延を最大値４０００msにしたときの動画再生前後の変化

分析と考察

　表９、１０は上り回線にパケット破棄率１００％をかけた時であるが、表９、１０での違いは動画再生の映像状態でTCPの場合すぐに画像が止まったのに比べ、UDPも画像が止まったがしばらく画像が安定していたところがある。今回、上り回線をかけているので、TCPの場合、きちんと届いたことを知らせるACKパケットが破棄されるわけだが、ACKパケットが破棄されたらサーバ側は再送されるわけだが、ACKパケットが毎回破棄されてしまい、ずっと再送を繰り返してしまう。そうなるとサーバ側がクライアント側はもう見ていないと判断し、接続が遮断されてしまうのですぐに画像がとまってしまうことが分かる。一方、UDPの場合、一方的にパケットをクライアント側に送信してさらに定期的にサーバ側に届いていることを知らせることを行っているプロトコルのRTPがあり、上り回線にパケット破棄率１００％をかけると届いていることの知らせがサーバ側に届かなくなり、それが何回も繰り返すとサーバ側がクライアント側はもう見ていないと判断し、接続が遮断されてしまうがTCPと違い、届いていることの知らせは定期的なので画像はしばらくたってから消えた。

まとめ

　今回の実験は条件付きのストリーミング配信においてTCPとUDPの２つのプロトコルを使って帯域制限、パケット破棄、遅延時間など状態を変化させることで通信状態がどのように変化するのかを観察した。どの場合でも状態を悪く設定すればTCP、UDPともに映像の状態、遅延時間、平均受信、平均送信、遅延時間が悪くなるということが分かった。またUDPの方がストリーミング配信が適していることがいえる。

【参考文献】

実験指導書D2

D1,D2参考

D2実験手順の詳細

信頼性のある通信を実現するTCPプロトコル　http://www.atmarkit.co.jp/ait/articles/0312/25/news001.html