この記事では、BitTorrent プロトコルで既知のビット位置の用途と割り当て、およびメッセージ識別子について説明しています。
予約ビットの割り当て#
将来の要求に備えて予約されたいくつかのバイナリビット。これらのビットは現行のプロトコルバージョンでは使用されていませんが、将来の拡張性に対応するために予約され、将来の目的に使用されることがあります。予約ビットの割り当ては、IP ヘッダ、TCP ヘッダ、UDP ヘッダなど、プロトコルの特定のフィールドで使用されることが一般的です。これらのビットは将来の標準の更新に使用できるため、将来の仕様やプロトコルは既存のプロトコルを変更する必要はありません。予約ビットの割り当てにより、プロトコルの設計者はプロトコルが将来の拡張性を持つときに後方互換性を維持し、既存のシステムの機能を破壊しないことができます。
reserved[0]（"reserved[0]"はBitTorrentプロトコルメッセージの予約フィールドを指します。元の値は0です。このフィールドは通常、プロトコルの拡張と更新に使用され、将来のバージョンで新機能を追加したり既存の機能を変更したりするために使用されます。以下同様。）
0x80 Azureus Messaging Protocol（Azureus Messaging Protocolは、BitTorrentプロトコルに関連する通信プロトコルであり、P2Pネットワークで情報とデータを交換するために使用されます。Azureusは有名なBitTorrentクライアントソフトウェアであり、初期のバージョンでは独自の通信プロトコルであるAzureus Messaging Protocolを使用してピア間の相互作用と制御を実現しました。 Azureus Messaging Protocolは、BitTorrent関連の機能（ビットストリームのダウンロード、トレントファイルの共有など）をサポートするために使用されることが一般的ですが、クライアント間の通信と協力にも使用できます。 Azureus Messaging Protocolは、多くの現代のBitTorrentクライアントによって置き換えられましたが、BitTorrent技術の進化の重要な一部です。）
reserved[2]
0x08 BitTorrent Location-aware Protocol（BLP）（BitTorrent Location-aware Protocol（BLP）は、BitTorrentプロトコルの拡張であり、より良いダウンロードパフォーマンスと負荷分散を可能にすることを目的としています。このプロトコルはIPアドレスを使用して各ピアの物理的な位置を特定し、距離に基づいて最適なソースを選択します。ただし、現在、このプロトコルを使用しているクライアントはありません。）
reserved[5]
0x10 LTEP（Libtorrent Extension Protocol）（Libtorrent Extension Protocol（LTEP）は、libtorrentライブラリが使用する拡張プロトコルであり、元のBitTorrentプロトコル仕様で定義されていない拡張メッセージの送受信をBitTorrentクライアントに可能にします。これらの拡張メッセージは、新機能の追加やBitTorrentクライアントのパフォーマンスの向上など、さまざまな目的に使用できます。）
0x02 Extension Negotiation Protocol
0x01 Extension Negotiation Protocol（0x02と0x01は、Extension Negotiation Protocolを表すコードです。Extension Negotiation Protocolは、BitTorrentプロトコルの一部であり、プロトコルのハンドシェイク中にピアがサポートする拡張機能を交換するために使用されます。接続を確立すると、各ピアは自分がサポートする拡張機能を含むメッセージを送信します。これらの拡張機能は、ut_metadataやut_holepunchなどの標準的な拡張機能、またはクライアントやアプリケーション固有のカスタム拡張機能のいずれかです。Extension Negotiation Protocolを使用することで、ピアは共通のサポートされる拡張機能を協議して有効にし、ダウンロードの効率と機能性を向上させることができます。）
reserved[7]
0x01 BitTorrent DHT（0x01はBitTorrent DHT（分散ハッシュテーブル）をサポートすることを示します。これにより、BitTorrentクライアントはトラッカーなしで他のクライアントを検索および連絡することができます。）
0x02 XBT Peer Exchange（0x02はXBT Peer Exchangeをサポートすることを示します。これは、トラッカーネットワークの負荷を軽減するために最適化されたP2Pネットワークプロトコルです。）
0x04 suggest、haveall、havenone、reject request、およびallow fast extensions（0x04は、suggest、haveall、havenone、reject request、およびallow fast拡張機能をサポートすることを示します。これらの機能は、haveallとhavenoneメッセージを送信することによってピアに所有または非所有のファイルブロックを通知するなど、ダウンロードの効率を向上させるために使用できます。）
0x08 NAT Traversal（0x08はNAT Traversal拡張機能をサポートすることを示します。これにより、BitTorrentクライアントはNATネットワークトラバーサル技術を使用して他のクライアントに接続できます。）
0x10 hybrid torrent legacy to v2 upgrade（0x10は、hybrid torrent legacy to v2 upgrade拡張機能をサポートすることを示します。これにより、古いバージョンのBitTorrentクライアントと新しいバージョンのクライアントがシームレスに連携できます。）
既知のハッシュ衝突：#
ハッシュ関数には、異なる入力が同じ出力値を生成するという状況が存在します。このような状況はハッシュ衝突と呼ばれます。ハッシュ関数の目的は、任意の長さのデータを固定サイズの出力にマッピングすることです。しかし、入力の不確定性と出力の有限性のため、一部の入力は同じ出力を生成する可能性があります。通常、ハッシュ関数は高度にランダムで複雑なものとして設計されており、ハッシュ衝突の確率は非常に低く、無視できるレベルです。しかし、攻撃者はハッシュ衝突を悪用して悪意のある攻撃を行うことがあります。たとえば、攻撃者はハッシュ衝突を使用してデジタル署名を偽造したり、リプレイ攻撃を実行したり、パスワードを解読したりすることができます。
reserved[0]
0xFF BitComet Extension Protocol
reserved[1]
0xFF BitComet Extension Protocol（0xFFはBitComet Extension Protocolの1つのバイトフラグであり、プロトコルのハンドシェイクメッセージを識別するために使用されます。このプロトコルは、BitTorrentネットワーク上の特殊な拡張プロトコルであり、既存のBitTorrentプロトコルに新機能を追加してより効率的で信頼性の高い転送サービスを提供します。）
reserved[7]
0x01 XBT Metadata Exchange（XBT Metadata Exchangeプロトコルは、トラッカーサーバーを介して他のクライアントからメタデータ情報をダウンロードせずに取得することを可能にするものです。これにより、ダウンロードの効率が向上し、帯域幅が節約される場合があります。XBTクライアントがXBTITトラッカーに接続すると、XBT Metadata Exchangeをサポートするハンドシェイクメッセージをトラッカーに送信できます。このメッセージには、reserved[7]が0x01に設定されています。トラッカーがXBT Metadata Exchangeをサポートしている場合、応答のハンドシェイクメッセージでクライアントに指示されます。その後、クライアントはトラッカーを介して他のXBT Metadata Exchangeをサポートするクライアントからメタデータ情報を取得できます。
「Extension Protocol」、または LibTorrent Extension Protocol（LTEP）は、BitTorrent プロトコルをさらに拡張するための推奨方法です。LTEP は、プロトコルに新機能を追加するための標準化されたメカニズムを提供します。LTEP は、ビットまたはメッセージ ID の衝突を回避するために、新しい拡張ビットを割り当てることなく、すべての拡張を接続開始時に交渉し、一意の識別子を割り当てます。これにより、各拡張には一意の識別子があり、他の拡張と衝突することはありません。同様に、LTEP を使用する場合、メッセージ ID の衝突も不可能になります。これは、メッセージ ID が接続開始時に必要に応じて割り当てられるためです。つまり、各メッセージタイプには一意の ID があり、他のメッセージタイプと衝突することはありません。LTEP を使用する場合、拡張名の衝突は引き続き可能ですが、以前の方法と比較して衝突の可能性ははるかに低くなります。これは、すべての拡張が BitTorrent コミュニティによって登録および追跡されるためです。これにより、新しい拡張が既存の拡張と衝突しないようにすることが保証されます。
予約メッセージ ID#
コアプロトコル:#
0x00 choke
0x01 unchoke
0x02 interested
0x03 not interested
0x04 have
0x05 bitfield
0x06 request
0x07 piece
0x08 cancel
choke と unchoke はアップロード帯域幅を制御するために使用されます。一方のピアが他方のピアを choked した場合、データの送信を停止することを伝えます。unchoked された場合、データのダウンロードを許可します。
interested と not interested は、一方のピアが他方のピアが持っているデータに興味があるかどうかを示すために使用されます。
have と bitfield は、一方のピアが持っているデータを説明するために使用され、他のピアが必要なデータを知ることができます。
request と piece は、実際のデータ転送に使用されます。リクエストには必要なデータブロックのインデックスと長さが含まれ、Piece には実際のデータが含まれます。
cancel は、以前に送信したリクエストをキャンセルするために使用され、ネットワークトラフィックをより効果的に管理することができます。
DHT 拡張:#
0x09 port
port は DHT 拡張に使用され、他のピアにポート番号を公開します。
Fast 拡張:#
0x0D suggest
0x0E have all
0x0F have none
0x10 reject request
0x11 allowed fast
suggest、have all、have none、reject request、および allowed fast はすべて Fast 拡張の一部であり、ダウンロード速度を向上させることができます。
デプロイされたクライアントで使用される追加の ID:#
0x14 LTEP Handshake（libtorrent、uTorrentなどで実装）
LTEP ハンドシェイクは、libtorrent、uTorrent などのクライアントで実装されたハンドシェイクプロトコルであり、ダウンロードを開始する前に必要な手順を実行します。
ハッシュ転送プロトコル:#
0x15 hash request
0x16 hashes
0x17 hash reject
hash request、hashes、および hash reject は、ハッシュ転送プロトコルの一部であり、ピア間でハッシュ値を交換して共有ファイルの完全性を検証するために使用されます。