BitTorrent 协议规范1.0版

Bittorrent Protocol Specification v1.0

Identification

BitTorrent is a peer-to-peer file sharing protocol designed by Bram Cohen. Visit his pages at http://www.bitconjurer.org. BitTorrent is designed to facilitate file transfers among multiple peers across unreliable networks.

Purpose

The purpose of this specification is to document version 1.0 of the BitTorrent protocol specification in detail. Bram's protocol specification page http://www.bitconjurer.org/BitTorrent/protocol.html outlines the protocol in somewhat general terms, and lacks behaviorial detail in some areas. The hope is that this document will become a formal specification, written in clear, unambiguous terms, which can be used as a basis for discussion and implementation in the future.

This document is intended to be maintained and used by the BitTorrent development community. Everyone is invited to contribute to this document, with the understanding that the content here is intended to represent the current protocol, which is already deployed in a number of client implementations.

This is not the place to suggest feature requests. For that, please go to the mailing list.

Scope

This document applies to the first version (i.e. version 1.0) of the BitTorrent protocol specification. Currently, this applies to the torrent file structure, peer wire protocol, and the Tracker HTTP/HTTPS protocol specifications. As newer revisions of each protocol are defined, they should be specified on their own separate pages, not here.

Related Documents

http://www.bitconjurer.org/BitTorrent/protocol.html - The official protocol specification.
BitTorrentWishList - A wish list for developers and end users alike.
BitTorrentTrackerExtensions - Describes the various extensions of the Tracker protocol that are in use.

Conventions

In this document, a number of conventions are used in an attempt to present information in a concise and unambiguous fashion.

• peer v/s client: In this document, a peer is any BitTorrent client participating in a download. The client is also a peer, however it is the BitTorrent client that is running on the local machine. Reader of this specification may choose to think of themselves as the client which connects to numerous peers.
• piece v/s block: In this document, a piece refers to a portion of the downloaded data that is described in the metainfo file, which can be verified by a SHA1 hash. A block is a portion of data that a client may request from a peer. Two or more blocks make up a whole piece, which may then be verified.
• defacto standard: Large blocks of text in italics indicates a practice so common in various client implementations of BitTorrent that it is considered a defacto standard.

In order help others to find recent changes that have been made to this document, please fill out the change log (last section). This should contain a brief (i.e. one-line) entry for each major change that you've made to the document.

bencoding

Bencoding is a way to specify and organize data in a terse format. It supports the following types: byte strings, integers, lists, and dictionaries.

byte strings

Byte strings are encoded as follows: <string length encoded in base ten ASCII>:<string data>
Note that there is no constant beginning delimiter, and no ending delimiter.
Example: 4:spam represents the string "spam"

integers

Integers are encoded as follows: i<integer encoded in base ten ASCII>e
The initial i and trailing e are beginning and ending delimiters.
You can have negative numbers such as i-3e. You cannot prefix the number with a zero such as i04e. However, i0e is valid.
Example i3e represents the integer "3"

lists

Lists are encoded as follows: l<bencoded values>e
The initial l and trailing e are beginning and ending delimiters.

Lists may contain any bencoded type, including integers, strings, dictionaries, and other lists.

Example: l4:spam4:eggse represents the list of two strings: ["spam", "eggs"]

dictionaries

Dictionaries are encoded as follows: d<bencoded string><bencoded element>e
The initial d and trailing e are the beginning and ending delimiters.

Note that the keys must be bencoded strings. The values may be any bencoded type, including integers, strings, lists, and other dictionaries. Keys must be strings and appear in sorted order (sorted as raw strings, not alphanumerics).

Example: d3:cow3:moo4:spam4:eggse represents the dictionary { "cow" => "moo", "spam" => "eggs" }
Example: d4:spaml1:a1:bee represents the dictionary { "spam" => ["a", "b"] }

Metainfo File Structure

All data in a metainfo file is bencoded. The specification for bencoding is defined above.

The content of a metainfo file (the file ending in ".torrent") is a bencoded dictionary, containing the keys listed below. All character string values are UTF-8 encoded. Keys not marke