要約

  • 人気ファイルの送信量の多くを、BitTorrentは公開元から同時ダウンロード中の利用者へ移した。ただし通常のWebサーバー、トラッカー、最初の完全なシードは配布経路に残る。
  • Cohenが説明したchokingの互恵策はクライアントの判断であり、ワイヤプロトコルが強制する保証ではない。受け取る以上に送るピアもいれば、自分のダウンロードを速める分だけ送り、完了後に共有を止めるピアもいる。
  • 2007年の研究は、戦略的なクライアントがアップロードを減らしながら個別の性能を上げられる可能性を示した。その結果は当時観測されたスウォームと条件に結び付けて読む必要がある。

転送の負担を誰が持つのか

HTTPでは、配布元サーバーが各利用者にファイルを送る。注目を集めるファイルほど公開元の送信容量が先に制約となり、設備を増やすか、速度低下を受け入れることになる。Bram Cohenが2003年の論文で示した転換点は、受信者を単なる終点にしなかったことだ。同じファイルを複数人が取得している間、彼らは受け取った断片を互いに送り合い、配信側の容量にも加わる。

この発想は、費用を消すというより、負担を置く場所を変える。Cohenは、利用者の上り帯域が多くの場合メーター課金されない環境なら、非常に人気のあるファイルも手頃に配れると論じた。しかし、その前提はすべての接続に当てはまらない。定額でも回線容量や電力は必要であり、利用者が長時間シードを続けることにも運用上の負担がある。

公開元の役割も残る。.torrentメタ情報は通常のWebサーバーに置かれ、トラッカーが同じファイルを取得するピアを見つける助けとなり、完全なファイルを持つシードが配布を開始する。Cohenの説明では、トラッカーとWebサーバーが扱う帯域はファイル本体に比べて小さい一方、シードは少なくとも一つの完全なコピーを送り出さなければならない。分散するのは大きなデータ転送であって、起点そのものではない。

したがって、BitTorrentを「ホスティング費用をなくす仕組み」と呼ぶのは正確ではない。公開元が送るバイト数は減り得るが、請求額への効果は料金体系、送信上限、ピアの実際のアップロード、完全なコピーを保つ期間で変わる。配信能力を参加者へ広げ、その分の責任も分けている。

相互性を強制する中央管理者はいない

Cohenの論文では、各ピアが相手を選んでアップロードするtit-for-tatの一種が説明されている。クライアントは相手への送信を一時的に止めるchokingを行える一方、optimistic unchokeによって未使用の接続も定期的に試す。すでに役立っている相手だけに固定せず、より良い転送先を探る機会を残したわけだ。

ただしCohenは、chokingアルゴリズムがBitTorrentのワイヤプロトコルの一部ではないと明記している。プロトコルが定めるデータや信号の交換と、各クライアントが誰に送るかは別の層だ。「BitTorrentは相互アップロードを保証する」と言い切れば、実装ポリシーを共通規則と混同する。実際の交換量は、ピアが持つ断片、接続の入れ替わり、実装差、余っている上り容量で変わる。

参加するかどうかも公開元が決める。利用者は欲しいファイルを得るためにクライアントを使う。Cohenは、リンクを押して保存先を選ぶだけの使いやすさが普及に大きく寄与し、性能や費用の再配分より重要かもしれないと書いた。ルールの設計だけでなく、参加への入口も採用を左右する。

2007年に見えた余剰容量

Michael Piatek、Tomas Isdal、Thomas Anderson、Arvind Krishnamurthy、Arun Venkataramaniによる2007年のUSENIX研究は、インセンティブがスウォームの頑健性を支えるという見方を検証した。実測トレースを使ったモデルでは、ピアが自分の性能を直接高めないリソースも提供していた。BitTyrantはその余地を利用するため、活動対象のピア集合や各相手への送信量を調整する戦略的クライアントとして実装された。

会議の要約によると、研究者が測定したライブスウォームでは、1 Mbit/sのクライアントが中央値で70%の性能向上を得た。一方、戦略的なクライアントが一斉に広がれば、当時の比較対象よりスウォーム当たりの平均性能を下げるおそれもある。これはtit-for-tatだけで貢献が確実になるという見方への反証だが、現代の全クライアントを測った数字ではない。70%を一般的な性能保証として使うこともできない。

互恵策は交換を調整できても、各参加者の全容量を拠出させる仕組みではなかった。optimistic unchokeや容量差があるため、直接の見返りがない送信も残る。戦略的なクライアントは、その一部を自分の利得に変えようとする。広まったときに特定のスウォームが弱るかどうかは、残る容量と参加者の行動に左右される。

シードが握る最後の安全策

公開元はメタ情報を置き、トラッカーなどの発見手段を用意し、完全なシードを起動して配布を始める。その後のアップロードは、各クライアントが自分で選ぶ。Cohenの設計には、全参加者へ送信量を割り当てる中央の資源配分者はいない。

この分散は、設備投資を抑えられる可能性と、供給の不確実さを同時に生む。公開元が完全なコピーを止めるのが早すぎると、希少な断片の最後の保持者が切断した時にファイルが欠けることがある。rarest-firstの選択は希少断片を先に複製しやすくするが、最後のコピーがなくなった後に復元するものではない。

運用上の問いは、BitTorrentがホスティングを「解決」したかではない。公開元が今も送っている量、ピアが実際に吸収する量、需要が落ちた後も完全なコピーを維持する条件を測るべきだ。Cohenはダウンロード中の利用者を配信者にもした。後の研究は、その能力をあるものと決めつけず、観測し続ける必要を示した。

参考資料