これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
CTC 教育サービス
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
前回に続いて、2016年に公開された学術記事「BBR: Congestion-Based Congestion Control」をもとにして、Googleが開発した、ネットワーク通信における新しい輻輳制御の仕組みを解説します。前回は、ネットワーク経路を水道管にたとえる方法で、BBRの考え方を説明しました。水道管の長さに相当するRTpropと太さに相当するBtlBwの値を推定して、送信中のパケットの総量がちょうど水道管の容量である「RTprop✕BtlBw」に一致するように、パケットの送信頻度を調整するという考え方でした。
今回は、RTprotとBtlBwを推定する方法について、より具体的な解説をすすめます。
冒頭の記事では、TCP通信において、RTpropとBtlBwを推定するコードの例が紹介されています。まず、RTpropの方は単純です。あるパケットを送信した後、そのパケットに対する受信確認（ACK）パケットを受け取るまでの時間であるRTT（Round Trip Time）を計測します。そして、過去数十秒間に計測された、複数のパケットに対するRTTの中で、最小の値をRTpropの推定値とします。ここで最小値を選択するのは、受信側の理由でACKの送信が遅れるなどの可能性があるためで、そのような、RTpropと無関係な遅延を含む場合を除外することが目的です。前回の図2のグラフから分かるように、一切の遅延がなく、最速でパケットが戻ってきた場合の時間がRTpropになるので、それを過去数十秒間における最小値で代替しているわけです。
ここで、いくつかの疑問がわいている方がいるかも知れませんので、少し補足説明を加えておきます。まず、最小値を取る範囲を過去数十秒の範囲に限定するのは、ネットワーク経路の変化により、RTpropが変化する可能性があるためです。特に、RTpropが大きくなった場合、ずっと昔の最小値で推定したRTpropを使い続けるのは問題があるので、古い情報は使用しないようになっています。また、パケット送信頻度が高すぎて、ネットワーク経路上のパケットバッファが利用されている状態では、RTTは必ずRTpropよりも大きくなってしまいます。そこで、RTpropの推定値がしばらく変化しなかった場合は、一定期間（200ミリ秒程度）パケット送信頻度を強制的に落とす処理が行われます。この間に計測されたRTTの最小値により、RTpropが正しく推定されることになります。
そして最後に、RTTは、パケットの往復時間を表わすものですので、これは片道の長さに相当するRTpropには一致しないような気もします。これはその通りです。ただし、この後で説明するように、パケットの送信頻度を調整する際は、この点を考慮に入れた処理が行われます。
BtlBwは、単位時間あたりのデータ送信量（デリバリーレート）の最大値として推定することができます。こちらも前回の図2から分かるように、十分な通信量がある状態でのデリバリーレートが、BtlBwに一致します。そこで、まずは、デリバリーレートを計測するために、ネットワーク通信のコード内部で、これまでにACKパケットを受け取ったすべてのパケットに含まれるデータの総量を変数deliveredに保持しておきます。簡単に言うと、ACKパケットを受け取るごとに、対応する送信パケットのデータ量をdeliveredに加えていきます。
そして、あるパケットを時刻t0に送信した後、対応するACKパケットを時刻t1に受け取ったとします。このタイミングで、deliveredの値は、このパケットのデータ量の分だけ増加するわけですが、この間に、t0以前に送信したパケットのACKパケットも受信しているはずですので、その分も含めてdeliveredの値は増加しています（図1）。この状態で、「t0〜t1におけるdeliveredの増加/(t1-t0)」を計算すれば、これがデリバリーレートの推定値となります。
図1 デリバリーレートの計算方法
そして、RTpropと同様に、過去の一定期間（RTTの10倍程度）における、デリバリーレートの最大値をBtlBwの推定値として採用します。ただし、アプリケーションが十分な量のパケットを送信しなければ、デリバリーレートはBtlBwに達しませんので、アプリケーションの通信量が少ない場合（現段階で推定されている「RTprop✕BtlBw」を埋めるだけのパケット送信がない場合）は、BtlBwの推定値の更新は行いません。また、ネットワーク経路の変化により、BtlBwの値が変化する場合があります。特に、BtlBwが大きくなった場合は、あえてパケットの送信量を増やさないと、それを検知することができません。そこで、定期的に、パケット送信頻度を少しだけ増やしてデリバリーレートが増加するかを確認する処理が行われます。
RTpropとBtlBwの値が推定できれば、パケット送信頻度の調整は簡単です。現在、送信済みのパケットの中で、まだ、ACKパケットを受け取っていないものについて、そのデータ量の総量を計算します。この値が「RTprop✕BtlBw」を超えそうになった場合は、パケットの送信を一時的に保留します。これで、ネットワーク経路の上には、「RTprop✕BtlBw」に相当する量のパケットが常に存在することになります。
ここで、先に触れたRTpropの推定値がRTTによってなされている点、つまり、ネットワーク経路の片道よりも大きくなっている点について説明しておきます。まず、一般に、ネットワーク経路上の帯域は、図2のように、場所によって大きくなったり小さくなったりします。BtlBwは、もっとも帯域が小さい部分の太さに相当します。BBRが実現する、最適な通信状態というのは、この最も細い部分に合わせて通信量を調整した状態です。一見すると、太い部分の帯域が無駄に見えますが、これは仕方がありません。これよりパケット送信量を増やしても、結局は、細い部分の直前にパケットが詰まって（すなわち、パケットバッファにパケットが溜まって）遅延が発生するだけのことになります。
図2 ネットワーク経路上の帯域変化
次に、インターネット上のネットワーク通信環境では、サーバーからの動画配信のように、一方向の通信量が極端に大きい場合が大多数で、BBRのような輻輳制御が必要となるのは、大量のデータを送信する側のサーバーです。この場合、サーバーから見た戻り経路は、通信データ量が少ないので、実質的に十分な帯域を持った経路とみなすことができます。そこで、図3のように、往復のネットワーク経路をつなげて考えてみます。この図では、相手側に届いたパケットは同じデータ量のままで復路も通過するものと仮定した上で、往復の長さをRTpropとして、往復の経路上の全データ量が「RTprop✕BtlBw」になるように調整しています。
図3 復路を含めたネットワーク経路の模式図
実際には、復路のパケットのデータ量は、往路とは異なりますが、復路は帯域が十分にあるので、その点は問題にはなりません。これによって、往路に存在する、最も帯域が小さい部分のBtlBwに合わせて、全体の通信量が調整されることになります。先に説明したパケット送信量の調整方法は、ちょうどこの考え方に一致していることがわかります。
ちなみに、ここまでの説明は、ネットワーク経路を単一の通信が専有しているという前提になっていました。実際のネットワーク環境では、当然ながら、複数のサーバーによる同時通信が行われます。この点は、何か問題にならないのでしょうか？ この場合、他の通信によって帯域の一部が使用されているとして、その残りの帯域がBtlBwとして検出されることになります。もちろん、他のサーバーがこちらの存在を無視して大量のパケットを送信すると、こちらから見たBtlBwはほぼ0になり、適切な通信はできなくなります。ただし、一般には、他のサーバーも何らかの輻輳制御を行うので、こちらが使用できる帯域がまったくなくなるという事はありません。特に面白いのは、すべてのサーバーがBBRで帯域制御を行った場合の結果です。図4の実験結果では、すべてのサーバーが平等に同じ帯域を使用するという結果が得られています。
図4 BBRを用いた複数サーバーによる同時通信（記事より抜粋）
今回は、BBRの内部の仕組みについて解説を行いました。冒頭の記事では、実際のソースコードのサンプルのほか、定期的にパケット送信量を増減させてBtlBwの変化を検知する仕組みについて、より詳細な挙動の説明が加えられています。興味のある方は、ぜひそちらの内容も参考にしてください。
次回は、Googleが開発した、RPC（Remote Procedure Call）のフレームワークである、gRPCに関する話題をお届けします。
Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
