この記事では、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クライアントと新しいバージョンのクライアントがシームレスに連携できます。）
既知のハッシュ衝突：#
ハッシュ関数には、2 つの異なる入力が同じ出力値を生成するという状況が存在します。この状況はハッシュ衝突と呼ばれます。ハッシュ関数の目的は、任意の長さのデータを固定サイズの出力にマッピングすることです。しかし、入力の不確実性と出力の有限性のため、一部の入力は同じ出力を生成する可能性があります。通常、ハッシュ関数は高度にランダムで複雑なものとして設計されており、ハッシュ衝突の確率は非常に低く、無視できるレベルです。しかし、攻撃者はハッシュ衝突を悪意のある攻撃に利用することがあります。たとえば、攻撃者はハッシュ衝突を使用してデジタル署名を偽造したり、リプレイ攻撃を実行したり、パスワードを解読したりすることがあります。
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をサポートするクライアントからメタデータ情報を取得できます。
「拡張プロトコル」とも呼ばれる 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 は、実際のデータ転送に使用されます。リクエストには必要なデータブロックのインデックスと長さが含まれ、ピースには実際のデータが含まれます。
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 は、ハッシュ転送プロトコルの一部であり、ピア間でハッシュ値を交換して共有ファイルの完全性を検証するために使用されます。