ピアエクスチェンジ（PEX）は、スワーム（ノードの集まり）に代替のノード発見メカニズムを提供し、ノードは DHT やトラッカーアナウンスなどの他のメカニズムによって誘導されます。
PEX は、他のソースよりもリアルタイムなスワームビューを提供し、他のソースを頻繁にクエリする必要性を減らします。
規格ノードの優先度と組み合わせて使用すると、スワーム接続グラフを迅速にランダム化する方法を提供します。
プロトコル拡張#
PEX は、新しいメッセージ ut_pex を導入するためのプロトコル拡張を行います。
ハンドシェイクで追加されるメッセージの交渉：
{
m: {
ut_pex: <implementation-dependent local message ID (positive integer)>,
...
},
...
}
拡張メッセージ自体は、BitTorrent / 拡張メッセージヘッダと後続の bencoded エンコードペイロードで構成されます：
{
added: <one or more contacts in IPv4 compact format (string)>
added.f: <optional, bit-flags, 1 byte per added IPv4 peer (string)>
added6: <one or more contacts IPv6 compact format (string)>,
added6.f: <optional, bit-flags, 1 byte per added IPv6 peer (string)>,
dropped: <one or more contacts in IPv6 compact format (string)>,
dropped6: <one or more contacts in IPv6 compact format (string)>
}
フラグの定義は次の通りです：
| Bit | 設定された場合 |
|---|---|
| 0x01 | プリファードエンクリプション、例えばハンドシェイクの e フィールド |
| 0x02 | シード / アップロードのみ |
| 0x04 | uTP をサポート |
| 0x08 | ノードは ut_holepunch をサポートし、ハンドシェイクで示される |
| 0x10 | アウトバウンド接続、ノードにアクセス可能 |
ノードは、接続が成功した後にのみ「added」フィールドに含まれる必要があり、接続が切断された場合は「dropped」フィールドに含まれる必要があります。ノードが追加された場合、クライアントは適切なタイミングで対応する「dropped」イベントを送信する必要があります。「added」信号のみを他のノードに送信し、「dropped」操作を行わない場合、仕様に準拠していません。
理由 1：PEX は、クライアントの現在の接続ノードを反映することを目的としており、これにより PEX は他のノード発見メカニズムよりもリアルタイムな情報を提供します。理由 2：検証済みのノードのみを伝播することで、BitTorrent スワームを悪用して分散型のサービス拒否攻撃を行う攻撃者の機会を減らすことができます。
相互通信するクライアントは、バッチ更新の頻度を 1 分に制限する必要があります。
ハンドシェイク後すぐに PEX メッセージを送信する必要はありません。たとえば、トレントの起動中にクライアントは、送信された PEX メッセージが価値を持つまで、十分な接続が確立されるまで待機する場合があります。
追加または削除される連絡先には重複が含まれていてはなりません。
正確性に影響を与えない限り、一時的な接続 - 切断イベントまたは切断 - 再接続イベントを更新メッセージ間で省略することができます。
実装の詳細：接続されている各ノードに対して、まだ送信されていない接続 / 切断イベントをキューに入れ、メッセージを生成する際に重複と一時的な接続を無視することは、シンプルな方法です。メモリをより節約する方法としては、各トレントに接続 / 切断イベントのタイムラインを記録し、各ノードには送信済みイベントのタイムスタンプを指すポインタを保存する方法があります。PEX メッセージを作成する際には、ポインタを進めるだけで、重複を除去し、一時的な接続を省略することに注意するだけです。
同じメッセージ内で追加された連絡先を削除してはいけません。
初期の PEX メッセージ以外では、追加された ipv4/ipv6 の連絡先の合計は 50 個を超えてはいけません。これは、削除されたエントリにも適用されます。
メッセージには、added、added6、dropped、dropped6 のいずれかのフィールドが少なくとも 1 つ含まれている必要があります。クライアントは、これらの制約を厳密に遵守しないノードを切断する場合があります。
未使用のリストを埋める
次の組み合わせを含む
- ネットワーク接続要件を満たす必要があります
- ノードがシード状態で他のピアノードとの接続を切断する必要があります
- IPv4 と IPv6 の間で同じノード ID に基づいて重複ノードの接続を切断する必要があります
これにより、added または added6 リストが十分に活用されない場合があります。PEX プロトコルを使用すると、シードリストに接続ノードが少なすぎる場合があります。シードノードには伝播できる接続ノードがなく、他のノードには他のシードノードに伝播できる接続ノードしかない場合、PEX の効果は大幅に低下し、シードリストの接続ノード数が不十分になります。IPv4 が主導するシードスワームでは、IPv6 の接続ノードを取得するのが困難な場合もあります。なぜなら、IPv6 の接続ノードは既に確立された IPv4 の接続と重複していると見なされ、PEX を介した伝播が阻止されるためです。
この問題を解決するために、BitTorrent プロトコルでは、接続を非アクティブな状態と見なし、終了するタイミングを決定するための「アクティビティ要件」が指定されています。ただし、特定のアドレス範囲（例：IPv4 または IPv6）に接続されているクライアントが 25 個未満の場合、このアクティビティ要件は緩和されます。代わりに、クライアントは、そのアドレス範囲に対して最大 25 個の最近接続および完全ハンドシェイクされた接続のリストを保持し、切断の理由を記録します。これらの理由により、リモートの連絡先が「added」または「added6」リストに含まれる資格が与えられます。これらのリストは、特定のアドレス範囲の信頼できるまたは許可されたリモートホストのリストを指す場合があります。最近の接続のリストを維持し、切断の理由を記録することで、クライアントは接続をより良く管理し、信頼性の高い安定したノードとの接続を維持できます。
- 同じノード ID が異なるアドレス範囲で接続されている場合
- 2 つのピアノードがお互いに接続して共有ファイルセグメントを交換することができない場合
- グローバルな接続数の制限など、ローカルのリソース制限
PEX メッセージは、最近切断された連絡先を含む場合、次のメッセージから「最近見たリスト」からその連絡先を削除する必要があります。一時的な接続 - 切断イベントによってリストが再度埋められる場合、必要な条件がすべて満たされている場合、これらのイベントは次のメッセージに含まれる可能性があります。言い換えれば、「最近見たリスト」を初期の PEX メッセージで埋めると同時に、クライアントは一部の接続 - 切断イベントをスキップすることができ、より効率的に PEX メッセージを構築することができます。要するに、ノードが他のピアノードとの接続を切断した場合、それは削除され、次の PEX メッセージには含まれません。ただし、ノードがネットワークに再接続し、特定の条件を満たす場合、ノードは再びそのノードの PEX メッセージに表示される可能性があります。さらに、クライアントは不要な接続および切断イベントをスキップして、より効率的に PEX メッセージを構築することができます。
最近見た連絡先は現在の接続であるとは限らないため、次の PEX メッセージで削除する必要があります。
同じ PEX メッセージで同じアドレスを追加および削除することはできません。この制限は依然として適用されます。
アクティブな接続が 25 個未満であり、最近見た連絡先が 25 個を超えないようにすることで、最大 2 つの削除可能な連絡先の PEX メッセージを累積することができます。また、十分なアクティブな連絡先が PEX メッセージを埋めることができない場合にのみ、古い情報が送信されます。
これらの免除ルールは、IPv4 および IPv6 それぞれに個別に適用できます。IPv4 のアクティブな接続が十分であっても、IPv6 関連のリストの数が不足している場合、クライアントは最近見た IPv6 連絡先を PEX メッセージに含めることができます。その逆も同様です。
セキュリティ上の注意事項#
受信した PEX メッセージは信頼できないと見なす必要があり、悪意のあるものである可能性があります。攻撃者は、他のノードと協力してスワームに対して偽の情報フラッディング攻撃などを行うことを試みるかもしれません。
PEX はまた、BitTorrent クライアントが被害者の IP 範囲に接続を試みるように誘導することによって、分散型サービス拒否攻撃（DDoS）を実行するために使用することもできます。これにより、これらの IP アドレスのネットワークトラフィックが急増し、ネットワークの混雑やサービスの利用不能が引き起こされます。
これらの問題を緩和するために、クライアントは単一の PEX ソースからすべての接続候補を取得することを避けるべきです。重複する IP アドレス（例：異なるポートを持つ IP アドレス）は無視する必要があります。また、規格ノードの優先度を使用することで、接続試行を多くのサブネットに分散させ、潜在的な被害者サブネットへの影響を軽減することができます。
まとめ#
PEX は、BitTorrent プロトコルの拡張機能です。それは、BitTorrent クライアントがお互いの知っている他のユーザーの IP アドレスとポート情報を交換することによって、ノードリストを拡張し、ネットワーク接続を強化するために使用されます。
PEX により、クライアントは直接他のクライアントと通信し、ノード情報を交換することができます。これにより、他のノードをより速く発見し、接続することができ、ダウンロード速度を向上させ、トラッカーの負荷を軽減し、ネットワークの信頼性とタイムリネスを向上させることができます。
注意すべきは、PEX 機能は無効または制限される可能性があるため、BitTorrent プロトコルの仕様に制約されず、偽のノード攻撃、プライバシーの漏洩などの問題を引き起こす可能性があることです。したがって、PEX を使用する際には、セキュリティとプライバシーの問題を考慮し、具体的な状況に応じて設定と調整を行う必要があります。