BitTorrent はファイルを配布するためのプロトコルです。これは URL を使用してコンテンツを識別し、Web ネットワークとシームレスに統合されることを目的としています。単純な HTTP ダウンロードに対して、その利点は、複数のユーザーが同じファイルを同時にダウンロードする際に、これらのユーザー間でファイルのブロックを相互にアップロードできることです。複数のユーザーがファイル転送に参加し、単一のファイルサーバーに依存するのではありません。これにより、ファイルソースは多数のユーザーが同時にダウンロードできるようになり、自身の負荷に対して小さな影響を与えることができます。
BitTorrent ファイル配布は以下の要素で構成されています：#
- 通常の Web サーバー
- 静的な metainfo ファイル
- BitTorrent トラッカー
- 原始ダウンローダー
- ウェブブラウザ
- BT ダウンロードクライアント
- 理想的な状況下で多くの最終ユーザーが共有ダウンロードできるファイル。
サービスを開始するには、ホストは以下の手順を実行する必要があります：#
- トラッカーを起動する（または既に実行中のものを使用する）。
- 通常の Web サーバーを起動する（例えば Apache、または既に実行中のものを使用する）。
- 彼らの Web サーバー上で拡張子 .torrent を MIME タイプ application/x-bittorrent に関連付ける（または既にそうしている）。
- 提供するサービスの完全なファイルとトラッカーの URL を使用して metainfo (.torrent) ファイルを生成する。
- metainfo ファイルを Web サーバーに置く。
- 他のウェブページから metainfo (.torrent) ファイルへのリンクを作成する。
- 完全なソースファイルを持つダウンローダーを起動する。
ダウンロードを開始するには、ユーザーは以下の操作を実行します：#
- BitTorrent クライアントをインストールする。
- インターネットをサーフィンする。
- .torrent ファイルのリンクを開く。
- ローカルにファイルを保存する場所を選択するか、続行する部分ダウンロードを選択する。
- ダウンロードが完了するのを待つ。
- ダウンロードクライアントを終了する（終了指示を受け取るまでアップロードを続けます）。
Bencode エンコーディング#
Bencode エンコーディングは、任意のデータ型の値をシリアライズ（「直列化」とも呼ばれる）してバイトストリームに変換し、ネットワーク上で転送したりディスクに保存したりするために使用されます。Bencode エンコーディングは、文字列、整数、リスト、および辞書の 4 つの基本データ型をサポートしています。
- 文字列型の場合、長さプレフィックスとコロンの形式で表されます。例えば「spam」は 4 とエンコードされます。
- 整数型の場合、文字「i」で始まり、その後に 10 進数で表された整数と文字「e」が続きます。例えば 3 は i3e とエンコードされ、-3 は i-3e とエンコードされます。
- リスト型の場合、文字「l」で始まり、その後にリスト内の各要素の Bencode エンコーディングが続き、最後に文字「e」で終了します。例えば [‘spam’, ‘eggs’] は l4:spam4 とエンコードされます。
- 辞書型の場合、文字「d」で始まり、その後にキーの ASCII コードでソートされたキーと値のペアの B エンコーディングが続き、最後に文字「e」で終了します。例えば {‘cow’: ‘moo’, ‘spam’: ‘eggs’} は d3:cow3:moo4:spam4 とエンコードされます。すべての辞書型のキーは文字列でなければならず、元の文字列の順序でソートされる必要があります。
Bencode エンコーディングは、さまざまなデータ型のシリアライズとデシリアライズ操作に適したシンプルでコンパクトで読みやすいデータシリアライズスキームを提供します。
Metainfo ファイル#
MetaInfo ファイル（.torrent ファイルとも呼ばれる）は、bencoding エンコーディングを使用している辞書で、以下のキーを含みます：
announce
トラッカーの URL アドレス。
info
このキーは、以下に説明するキーを含む辞書にマッピングされます。
テキストを含む .torrent ファイル内のすべての文字列は、UTF-8 エンコーディングを使用する必要があります。
info 辞書#
BitTorrent がダウンロードファイル時に使用するメタデータ情報です。これは複数のキーと値のペアを含み、各キーは特定の属性を表します。例えば、推奨されるファイル名、ファイルブロックのサイズ、ハッシュ値などです。これらの属性は、クライアントがファイルを正しくダウンロードして組み立てるのに役立ちます。
いくつかの重要な属性には以下が含まれます：
- name：推奨されるファイル名で、純粋に提案のために提供され、強制力はありません。
- piece length：ファイルが固定サイズのブロックに分割される際、この属性は各ブロックのサイズを指定します（通常は 2 の累乗）。
- pieces：各ブロックに対応するハッシュ値で、ファイルの完全性を検証するために使用されます。
- length：ファイルの長さ（単一ファイルの場合のみ）、またはすべてのファイルを連結した総長です。
単一ファイルをダウンロードする場合は、name と length 属性のみを使用する必要があります。複数のファイルの場合は、files リストを使用してファイルのディレクトリ構造を表現し、各ファイルは length と path 属性を含む辞書で表されます。
trackers#
トラッカーの GET リクエストには以下のキーワードが含まれます：
info_hash：メタ情報ファイル内の info 値の bencoded 形式の 20 バイト SHA1 ハッシュ値。この値はほぼ確実にエスケープが必要です。これはメタ情報ファイルのサブストリングであることに注意してください。info-hash は .torrent ファイル内のエンコード形式のハッシュ値でなければならず、メタ情報ファイルを bencoded デコードして info 辞書を抽出し、それをエンコードするのとまったく同じである必要があります。bencoded エンコーディングが入力を完全に検証した場合（例えば、キーのソート、先頭ゼロの欠如など）、これを行う必要があります。そうでない場合、クライアントは無効なメタ情報ファイルを拒否するか、サブストリングを直接抽出する必要があります。無効なデータに対してデコード - エンコードの往復を実行することはできません。
peer_id：このダウンローダーの ID として使用される長さ 20 の文字列。各ダウンローダーは新しいダウンロードを開始する際に自分の ID をランダムに生成します。この値もほぼ確実にエスケープが必要です。
ip：オプションのパラメータで、このピアが存在する IP アドレス（または DNS 名）を指定します。通常はソースアドレスに使用され、ソースがトラッカーと同じコンピュータにある場合はこのパラメータを使用します。
port：このピアがリッスンしているポート番号。一般的な動作は、ダウンローダーがポート 6881 をリッスンしようとし、そのポートが使用中の場合は 6882、6883 などのポート番号を試み、6889 以降は放棄することです。
uploaded：これまでにアップロードされた総量を 10 進数 ASCII エンコーディングで示します。
downloaded：これまでにダウンロードされた総量を 10 進数 ASCII エンコーディングで示します。
left：このピアがまだダウンロードする必要があるバイト数を 10 進数 ASCII エンコーディングで示します。注意すべきは、これは downloaded とファイル長から計算できないことです。なぜなら、これは復元ダウンロードであり、ダウンロードされたデータの一部が完全性チェックを通過せず、再ダウンロードが必要な可能性があるからです。
event：これはオプションのキーワードで、started、completed、または stopped（または存在しない場合は空）にマッピングされます。存在しない場合は、定期的な通知の 1 つです。ダウンロードが開始されたときは、started を使用して通知を送信します。ダウンロードが完了したときは、completed を使用して通知を送信します。ファイルが開始時に完了している場合は、completed を送信しません。ダウンローダーがダウンロードを停止すると、stopped を使用して通知を送信します。
トラッカーの応答は bencoded 辞書です。トラッカーの応答に failure reason キーワードがある場合、そのキーワードは人間が読める文字列にマッピングされ、クエリが失敗した理由を説明し、他のキーワードは必要ありません。そうでない場合、interval という 2 つのキーワードを持っている必要があり、これはダウンローダーが定期的に再リクエストする間に待機すべき秒数にマッピングされます。そして peers は、各辞書がピア ID、IP、およびポートの 3 つのキーワードを含むピアリストの辞書にマッピングされます。これらはそれぞれ、ピアの自己選択 ID、IP アドレスまたは DNS 名、ポート番号を示します。イベントが発生したり、より多くのピアが必要な場合、ダウンローダーは非定期的な時間に再リクエストすることがあります。
より一般的には、トラッカーはピアリストの圧縮表現を返します。トラッカーがコンパクトなピアリストを返す場合を参照してください。
メタ情報ファイルやトラッカーのクエリに対して何か拡張を行いたい場合は、すべての拡張が互換性があることを確認するために Bram Cohen と調整してください。
通常、UDP トラッカー プロトコルを介して通知を行うこともできます。
ピアプロトコル#
BitTorrent のピアプロトコルは、TCP または uTorrent トランスポートプロトコルを介して実行されます。BitTorrent では、ダウンローダーとアップローダーは対等であり、データはそれらの間で相互に流れることができます。データは多くの小さなブロックに分割され、複数のソースから同時にダウンロードされることで、ダウンロード速度と転送の信頼性が向上します。ダウンローダーがファイルのブロックのダウンロードを完了し、ハッシュ値が一致することを確認すると、そのブロックの情報をすべてのピアにブロードキャストします。
接続状態には 2 つのカテゴリがあります：ブロックまたは非ブロック；興味ありまたは興味なし。ブロックはデータが送信されないことを示し、ブロックが解除されるまで待機します。データ転送は、一方が興味を持ち、もう一方が非ブロックの場合にのみ発生します。正しいデータ転送を実現するために、ダウンローダーは興味のある状態を維持し、タイムリーに更新する必要がありますが、ブロックの影響を受けます。データを転送する際、ダウンローダーは良好な TCP パフォーマンスを得るために複数のブロックのリクエストをキューに保持し、リクエストが即座に TCP バッファに書き込まれない場合は、メモリ内にキューに保持して、ブロックが発生したときにすべてを破棄します。
ピアプロトコルは、ハンドシェイクプロセスと永続的な長さプレフィックスメッセージで構成されています。ハンドシェイクは 19（10 進数）文字で始まり、その後に「BitTorrent プロトコル」という文字列が続きます。2 つのノードを接続する前に、必要な情報を交換するためにハンドシェイクを行う必要があります。ハンドシェイクが開始されると、送信者は受信者に固定のハンドシェイクメッセージを送信し、これにはプロトコルバージョン、予約バイト、メタデータハッシュ値、ノード ID が含まれます。受信者はこれらの情報を検証し、それらが期待される値と一致するかどうかを確認します。一致しない場合、接続は切断されます。ハンドシェイクが成功すると、双方はデータの交換を開始します。データは一連の長さプレフィックスとメッセージを介して転送されます。長さプレフィックスはメッセージの長さを示し、その後に実際のメッセージ内容が続きます。
ピアメッセージ#
すべての非アクティブメッセージは単一のバイトで始まり、以下にそのタイプを示します。
可能な値は：
- 0 – choke
- 1 – unchoke
- 2 – interested
- 3 – not interested
- 4 – have
- 5 – bitfield
- 6 – request
- 7 – piece
- 8 – cancel
‘choke’, ‘unchoke’, ‘interested’, and ‘not interested’ には有効なペイロードがありません。
bitfield メッセージ：このメッセージは最初のメッセージとしてのみ送信されます。そのペイロードはビットフィールドで、各ダウンローダーが送信するインデックスが 1 に設定され、残りのインデックスは 0 に設定されます。データがないダウンローダーはこの「bitfield」メッセージをスキップできます。ビットフィールドの最初のバイトはインデックス 0-7（高位から低位）に対応し、次に 8-15 というように続きます。末尾の余分なビットは 0 に設定されます。
have メッセージ：このメッセージのペイロードは、ダウンローダーが完了し、ハッシュ値を確認したインデックスを示す単一の数字です。
request メッセージ：このメッセージにはインデックス、オフセット、および長さが含まれます。最後のパラメータは通常 2 の累乗であり、ファイルの末尾に達していない限りそうです。すべての現在の実装は 2^14（16 kiB）を使用し、この制限を超えるリクエストの接続を閉じます。
cancel メッセージ：リクエストメッセージと同じ有効なペイロードを持ちます。これらは通常、ダウンロードが終了したときにのみ送信され、いわゆる「エンドゲームモード」の間に行われます。ダウンロードがほぼ完了したとき、最後の数部分は通常、単一のホースモデムラインからダウンロードされ、時間がかかります。最後の数ブロックが迅速に入手できるようにするために、指定されたダウンローダーがまだ受け取っていないすべての部分のリクエストが現在保留中である場合、ダウンローダーはダウンロード中のすべての人にリクエストを送信します。このプロセスが非常に非効率的になるのを防ぐために、各作品が到着するたびに、他の人にキャンセルを送信します。
piece メッセージ：インデックス、開始、およびフラグメントを含みます。これらはリクエストメッセージと暗黙的に関連しています。ブロックとキャンセルブロックメッセージが迅速に連続して送信される場合や、転送速度が非常に遅い場合、予期しないフラグメントが発生する可能性があります。
まず、ダウンローダーは通常、ファイルの異なる部分をランダムにダウンロードし、特定のダウンローダーが他のダウンローダーのサブセットまたはスーパーセットを持つ状況を回避します。次に、各ダウンローダーが一貫したダウンロード速度を得るために、アップロード速度を制限する操作（「チョーキング」とも呼ばれる）が必要です。このアルゴリズムは、ダウンローダー間で「目には目を」という戦略を使用して、安定したダウンロード速度を確保します。最後に、現在使用されているチョーキングアルゴリズムは、新しいアルゴリズムがさまざまなネットワーク環境で良好に機能する重要性を強調しています。
まず、良好な TCP パフォーマンスを確保するために、アルゴリズムは同時にアップロードする接続数を制限する必要があります。次に、頻繁に choke と unchoke を行わないように、アルゴリズムはアップロード対象を安定して選択する必要があります。さらに、ある程度は自分のダウンロードを助けてくれたピアに報いるべきです。最後に、アルゴリズムは未使用の接続を利用してダウンロード速度を向上させることを試みるべきで、これを「楽観的なアンチョーク」と呼びます。
現在展開されているチョーキングアルゴリズムは、これらの目標を達成するためにいくつかの措置を講じています。頻繁な変化を避けるために、アルゴリズムは 10 秒ごとにどのピアがチョークされるかを変更します。他の人に報いるために、アップロード接続の数を制限し、アルゴリズムはダウンロード速度が最も良好で興味のある最初の 4 つのピアを選択してアンチョークします。もし他のピアのアップロード速度が良好で興味がない場合、そのピアもアンチョークされる可能性があります。興味が突然生じた場合、最もダウンロード速度が悪いピアはチョークされます。もしあるダウンローダーがファイルを完全にダウンロードした場合、彼はアップロード速度を使用してどのピアをアンチョークするかを決定します。
楽観的なアンチョークに関しては、アルゴリズムは 30 秒ごとに 1 つのピアを選択してアンチョークします。アップロード速度に関係なく（興味があればダウンローダーと見なされます）。ローテーション中、新しい接続は現在の楽観的なアンチョークの位置に 3 倍の確率で配置され、完全なデータブロックをアップロードする機会を十分に与えられます。