アカデミック

【初学者向け】マルチメディア通信<トランスポートプロトコル詳細編>

この記事では,マルチメディア通信に関わる知識を簡単にまとめていきたいと思います。ただし,全ての知識が詳しく網羅されている訳ではありません。また,分かりやすいように多少意訳した部分もあります。ですので,参考程度におさめていただければ幸いです。

間違えている箇所がございましたらご指摘ください。随時更新予定です。他のマルチメディア通信に関する記事はコチラのページをご覧ください。

トラスポートプロトコル

トランスポート層におけるプロトコルとしては,TCPとUDPが代表的です。これらについては,こちらの記事[TCP/IP編]とこちらの記事[UDP/RTP編]でお伝えしています。以下では,他のトランスポートプロトコルである「SCTP」「DCCP」についてお伝えしていきます。

SCTP

SCTP(Stream Control Transmission Protocol)は,TCPとUDPの両方の特徴を兼ね備えたモデルです。一対一通信を規定し,複数のIPアドレスを利用できるほか,IPv4とIPv6の混在や障害時の経路選択,チャンクを単位とした転送,TCPと同じような再送・輻輳制御による信頼性,Partial reliability拡張による実時間性への対応などが特徴です。

SCTPはもともとIPネットワークで音声通話を行うためのプロトコルを意図して設計されましたが,TCPとUDPの美味しいとこ取りをしていることに後から気付いたらしいです。

SCTPの説明はこちらのサイト[外部リンク:SCTPによるネットワーキングの向上]が詳しいです。SCTPを特徴づける用語としては「マルチホーミング」「マルチストリーミング」「チャンク」「Partial Reliability」があります。

マルチホーミングは,複数のインターフェースによる通信を「association」という概念で可能にしています。マルチストリーミングは,associationの中に複数のstreamを持つ特徴のことを指します。TCPでは複数のconnectionを張ってしまうと,データ転送待ちが他のconnectionに影響を与える問題(Head-of-Line Blocking)が起こることがあります。一方で,SCTPではそれを回避します。

SCTPでは,TCPにおける「バイト列としてデータを送受信する」という特徴と,UDPにおける「データの構造を保持しながら送受信する」という特徴を兼ね備える「チャンク」というデータの論理的な塊を単位としてデータを送受信します。チャンクごとに有効期限を指定することで実時間性を考慮するのが「Partial Reliability」です。

他にも,接続開始の「3-way handshake」が「4-way handshake」に置き換わりました。サーバ側へのDos攻撃を防ぐためにcookie入りのINITパケットやECHOパケットを導入しています。また,接続終了時の処理は「4-way」が「3-way」に置き換わりました。これは,終了の合図を出してからもデータの送信を行える「ハーフクローズ状態」を不用意に作り出さないようにするためです。

DCCP

DCCP(Datagram Congestion Control Protocol)は,UDPにTCPの輻輳制御を組み合わせたようなプロトコルで,一対一通信を規定します。輻輳制御アルゴリズムとしては「Compatible Congestion Control」と「Friendly Congestion Control」があります。

DCCPでは,接続開始時(コネクション確立時)にCCID(Congestion Control IDentifier)と呼ばれる識別子を交換することで,転送中に使用する輻輳制御アルゴリズムを決定します。

現状としては,ほとんどのアプリケーションでTCPが使用されています。UDPは限定的にしか用いられておらず,SCTPやDCCPはほぼ用いられていません。というのも,TCPはNAT(Network Address Translation)との相性がいいのです。新しいプロトコルとしては,TCPを複素おアドレスによる複数経路をもつように拡張した「MPTCP」や,TCP・TLS・HTTP/2の一部を1往復で実装した「Google QUIC」などがあります。

QoS制御

IPネットワークに関するプロトコルでは,サービス品質(QoS:Quality of Service)のパラメータを考慮することも大切です。QoSを決定するのは,主に「帯域」「遅延とその変動幅(ジッタ)」「パケットロス率」です。

ここで,QoS制御は必ずしも「高品質を目指す」という意味で用いられるわけではないことに注意が必要です。例えば,IP電話では「帯域は数十kbps」「遅延は一定値以下」「パケットロスとロジッタは小さく」という要求があります。IP電話では「超高音質の話し声」を聞きたいのではなく,内容が漏れなく確実に伝わればOKという特徴があるからです。

遅延やパケットロス率に大きく関わる要因として,「キュー(キューイング)」がありあす。キューとは基本的なデータ構造の1つで,ここではデータを溜め込んでおくバッファのようなものです。

例えば,単純なルータでは入力のパケットを1つのキューに入れて順番に出力していきます。「優先キューイング」では,優先度ごとにキューを作って優先度の高いキューからパケットを取り出していきます。しかし,優先度が低いキューがいつまでたっても出力されないという問題が起こり得ます。

「重み付き公平チューイング」では,フローごとにキューを作って重み付きのラウンドロビン方式(順番を割り振っていく方式)でパケットを出力します。しかし,フローの数だけキューが必要となり,大規模なネットワークへの適用が難しいという問題がありました。「クラスベースキューイング」では,フローではなくクラスごとにキューを作ることで重み付き公平キューイングの問題を克服しようとします。

帯域制限

帯域制限とは,レストランの予約席のように,ネットワークの帯域を貸し切ることでデータ通信を担保しようという考えです。QoSのうち,帯域制御に関するアイディアとして「シェーピング」「ポリシング」があります。

シェーピングは,帯域上限を超えたパケットを「キューに待機させる」方式です。対して,ポリシングは帯域上限を超えたパケットを「廃棄する」方式です。前者はキューを利用するため遅延が生じる可能性があり,後者は遅延は発生しません。

ここで登場する用語に「バースト性」があります。バースト性とは,ネットワークに一時的に大量のデータ,もしくは送受信要求が流入することを指します。シェーピングはバーストを平滑化します。

フロー(IPアドレスとポート番号によって識別されるトラフィックの単位。IPv6ではヘッダ内にフロー番号がある。)ごとにシェーピングとポリシングを実装しようとすると,シェーピングはカウンタを加えるだけで実装可能である一方で,ポリシングはフローごとにバッファとなるキューが必要となるため,実装が困難であるという特徴があります。

フローごとにQoS制御を行う枠組みとして「IntServ(Integrated Service)」,フローをまとめたクラスごとにQoS制御を行う枠組みとして「DiffServ(Differentiated Service)」があります。

バケットによりモデル化されたアルゴリズム

シェーピングとポリシングによってネットワークへの流入量を調節するアルゴリズムは,バケツを使ってモデル化されます。「Leaky Bucket」は,流入量に上限を設けることでバーストを平滑化します。バケツの底に穴があり,そこから出る水の量には上限があるというモデルです。

「Token Bucket」は,流入量の平均に制限を設けることである程度のバーストを許容します。バケツには仮想的な水が追加されていき,バケツにどれだけの仮想的な水が入っているかによって,新たに入ってきたパケットを破棄するか送り出すかを決めるモデルです。

実際には「Leaky Bucket↔︎シェイピング」「Token Bucket↔︎ポリシング」などと対応しているわけではなく,例えばToken Buvketをシェイピングに応用することも原理的には可能です。

参考文献

[1] Evans, John William, and Clarence Filsfils. Deploying IP and MPLS QoS for multiservice networks: Theory and practice. Elsevier, 2010.

COMMENT

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です