BitTorrent の Extension Protocol は、BitTorrent のダウンロードプロトコルの機能を拡張および強化するためのメカニズムです。このプロトコルでは、クライアントは標準プロトコルとは異なるメッセージを送受信することで通信を行うことができます。これらのメッセージによって、DHT（分散ハッシュテーブル）の交換、PEX（ピアエクスチェンジ）およびより高度な暗号化のサポートなど、新しい機能を実現することができます。
Extension Protocol は、BitTorrent プロトコルにおいて非常に重要な役割を果たしています。これにより、クライアントはより効率的かつ信頼性の高いデータ交換が可能となり、プライバシーやセキュリティの向上も図られます。例えば、DHT はトラッカーなしでネットワークに接続されている他のピアを検索することができます。また、PEX はクライアントが直接他のクライアントと通信することを可能にし、データ交換をより安定させることができます。
プロトコルの概要#
このプロトコルの目的は、BitTorrent プロトコルの拡張に対してシンプルで軽量な転送方法を提供することです。このプロトコルをサポートすることで、他のクライアントに影響を与えることなく、BitTorrent プロトコルを個別に拡張およびカスタマイズすることができます。
BitTorrent プロトコルでは、自身を他のサポートクライアントに広めるために、予約されたバイトの中の 1 バイトを使用します。その中で、拡張プロトコルのバイトは右から数えて 20 番目のバイトです（0 から数えます）。したがって、式（reserved_byte [5] & 0x10）を使用して、クライアントが拡張メッセージの送信をサポートしているかどうかを確認することができます。この式の意味は、予約されたバイトの 5 番目のバイトと 0x10 をビットごとの AND 演算し、結果が 0 でない場合、クライアントは拡張メッセージをサポートしていることを示します。
プロトコルのサポートを確立した後、クライアントは 1 つの新しいメッセージをサポートする必要があります：
| name | id |
|---|---|
| extended | 20 |
このメッセージは他の BitTorrent メッセージと同様に、4 バイトの長さプレフィックスと 1 バイトの識別子（この場合は 20）で送信されます。ペイロードの先頭には、1 バイトのメッセージ識別子があります。この識別子は異なる拡張メッセージを参照することができますが、ID は 0 のみを指定します。ID が 0 の場合、このメッセージはハンドシェイクメッセージであり、後述します。一般的な拡張メッセージのレイアウトは次のようになります（BitTorrent プロトコルで使用されるメッセージヘッダを含む）：
| size | description |
|---|---|
| uint32_t | 長さプレフィックス。メッセージ全体のバイト数を指定します。（ビッグエンディアン 1） |
| uint8_t | BitTorrent メッセージ ID、= 20 |
| uint8_t | 拡張メッセージ ID。0 = ハンドシェイク、>0 = ハンドシェイクで指定された拡張メッセージ。 |
ハンドシェイクメッセージ#
ハンドシェイクメッセージのペイロードは、bencoded 辞書です。辞書内のすべての項目はオプションです。クライアントは辞書内の未知の名前を無視する必要があります。辞書内のすべての部分は大文字と小文字を区別します。辞書では、次の項目が定義されています：
| name | description |
|---|---|
| m | サポートされている拡張メッセージの辞書は、各拡張メッセージの名前を拡張メッセージ ID にマッピングします。これらの ID には、2 つの拡張メッセージが同じ ID を共有することはできないという唯一の要件があります。拡張メッセージの ID を 0 に設定すると、その拡張がサポートされていない / 無効であることを意味します。クライアントは認識しない拡張名を無視する必要があります。拡張メッセージ ID は、このハンドシェイクを送信するピアへの拡張メッセージの送信に使用されます。つまり、これらの ID はこの特定のピアのローカル ID に固有です。 |
以下に、実装がサポートする可能性のあるいくつかの項目を示します：
| name | description |
|---|---|
| p | ローカル TCP リッスンポート。各パーティは他方の TCP ポート番号を知ることができます。受信側はこの拡張メッセージを送信する必要はありません。なぜなら、そのポート番号は既知だからです。 |
| v | クライアントの名前とバージョン（UTF-8 文字列として）。これはピア ID エンコードに依存するよりも信頼性の高いクライアントの識別方法です。 |
| yourip | あなたの IP アドレスをコンパクトな表現で含む文字列です。つまり、これは受信側の外部 IP アドレス（ポートを含まない）を表します。IPv4（4 バイト）または IPv6（16 バイト）アドレスのいずれかです。 |
| ipv6 | このノードが IPv6 インターフェースを持っている場合、これはそのアドレスのコンパクトな表現（16 バイト）です。クライアントは IPv6 アドレスを使用して接続することを好む場合があります。 |
| ipv4 | このノードが IPv4 インターフェースを持っている場合、これはそのアドレスのコンパクトな表現（4 バイト）です。クライアントは IPv4 アドレスを使用して接続することを好む場合があります。 |
| reqq | 未完了のリクエストメッセージの数を表す整数。メッセージが失われることなく、クライアントがサポートする数を示します。libtorrent では、デフォルト値は 250 です。 |
ハンドシェイク辞書には、暗号化ヘッダのサポートやその他の可能な内容など、拡張ハンドシェイク情報も含まれる場合があります。
以下は、ハンドシェイクメッセージのペイロードの例です：
| Dictionary | |
|---|---|
| m | Dictionary / LT_metadata······1 / ut_pex··················2 |
| p | 6881 |
| v | “µTorrent 1.2” |
エンコード形式では、次のようになります：
d1:md11:LT_metadatai1e6:µT_PEXi2ee1:pi6881e1:v13:\xc2\xb5Torrent 1.2e
拡張名が誤って衝突するのを避けるために、拡張メッセージの名前の前にクライアントが導入した 1〜2 文字のコードを付けるべきです。これは、拡張メッセージの名前だけでなく、トップレベルの辞書に含まれる他の情報にも適用されます。この仕様で定義されていない限り、すべての 1 バイトおよび 2 バイトの識別子は無効です。
このメッセージは、この拡張プロトコルをサポートするノードに対して、標準の BitTorrent ハンドシェイクの直後に即座に送信する必要があります。接続の全体のサイクルで、ハンドシェイクメッセージを複数回送信することができ、送信側は接続を切断するべきではありません。実装は、後続のハンドシェイクメッセージ（またはその一部）を無視することを選択することができます。
その後のハンドシェイクメッセージは、接続を再起動せずに拡張を有効化 / 無効化するために使用することができます。拡張をランタイムで変更する場合は、m 辞書が累積されることに注意する必要があります。実際の変更が拡張リストをカバーしていれば十分です。LT_metadata のサポートをランタイムで無効にするが、他の拡張には影響を与えない場合は、このメッセージを送信する必要があります：d11 。前述のように、値 0 は拡張を無効にするために使用されます。
各ノードは拡張 ID を保存する必要があります。なぜなら、同じ拡張を持つノードでも異なる ID を持つ可能性があるからです。
この仕様では、ノード交換やメタデータ交換などの特定の拡張を指定していません。このプロトコルは、実際の BitTorrent プロトコルの拡張のための転送方法であり、上記の例で名前が付けられた拡張（例：p）は単なる例です。