IMFile

IMFile

A Free And Unlimited BT / HTTP / HTTPS / eD2k Download Software From Singapore

Peer Exchange (PEX) ピアエクスチェンジ(PEX)は、私たちに何をもたらしてくれるのでしょうか?

Peer Exchange (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)>
  }

フラグの定義は次のとおりです:

Bitwhen set
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 メッセージで削除する必要があります。

同じ 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 を使用する際には、セキュリティとプライバシーの問題を考慮し、具体的な状況に応じて設定と調整を行う必要があります。

参考リンク#

読み込み中...
文章は、創作者によって署名され、ブロックチェーンに安全に保存されています。