The BitTorrent Protocol
To turn "sharing makes it faster" into reality, BitTorrent builds meticulous strategy into piece selection, bandwidth allocation, and verification. Let's look inside the protocol, and at the wide range of legitimate uses it enables.
The .torrent file and magnet links: identifying a swarm by info hash
The unit of distribution is the metadata (.torrent file) recording the piece size and each piece's hash. The hash of this metadata (the info hash) identifies the swarm, and peers holding the same info hash are found via trackers, the DHT, and PEX (peer exchange). With magnet links, even the metadata itself is fetched from peers (BEP 9).
A .torrent file is written in a simple binary format called Bencode. Its central info dictionary holds the file name, the piece length (typically 256 KB to 16 MB, chosen based on overall file size), and a pieces field that concatenates the SHA-1 hash of every piece. The info hash is the 20-byte SHA-1 hash of that entire info dictionary; embedding it in a URL as magnet:?xt=urn:btih:<info-hash> lets a client join a swarm without ever distributing or storing a .torrent file.
Piece selection: the wisdom of rarest first
- Random first piece: a newcomer first grabs any single piece quickly to have something to trade. Rarity data is still too thin to be meaningful at this stage, so the choice is random by design.
- Rarest first: thereafter, prioritize the piece with the fewest holders in the swarm. This prevents piece extinction (a file becoming permanently incompletable if the sole seeder holding a piece leaves) and equalizes the piece distribution, maximizing trading opportunities.
- Endgame mode: near completion, request the final pieces from multiple peers in parallel so the last piece is never held hostage by one slow peer. Redundant copies that arrive after a piece is already complete are cut off with a
Cancelmessage to avoid wasting bandwidth.
The very first seeder distributing to a large number of downloaders may instead use a technique called super-seeding, deliberately handing out pieces in a planned order rather than at random. During the launch phase, when only one seeder exists, it releases just one copy of each piece at a time to encourage peer-to-peer trading, conserving the seeder's own upload bandwidth while speeding up the swarm's overall completion.
Choking: how the currency of bandwidth is spent
Each peer uploads to only a handful of peers at once (typically 4) and chokes the rest. The criterion for unchoking is whoever uploaded to me fastest recently, which is the implementation of tit-for-tat. Upload rates are typically re-evaluated on a roughly 10-second cycle, swapping out the ranking while keeping the top performers. Every 30 seconds, one slot is also opened to a random peer via optimistic unchoke, giving newcomers their first chance. Together these two rules create a market where contribution pays, with no central arbiter.
- Anti-snubbing: if a peer goes unchoked by no one for an extended period (roughly 60 seconds), it concludes it has been "snubbed" and self-detects the stall by, for example, narrowing the number of peers it is uploading to and prioritizing the search for new partners.
- Seeders: a seeder has nothing left to download, so it switches criteria: instead of "whoever uploads to me fastest," it favors "whoever I have unchoked least recently," preserving fairness among downloaders.
Trackers, DHT, and PEX: triple-redundant peer discovery
BitTorrent peer discovery does not rely on a single mechanism. It combines a centralized tracker (a server that distributes the swarm's participant list over HTTP/UDP), the serverless DHT (BEP 5, the Mainline DHT), and PEX (Peer Exchange, BEP 11), where peers already connected to each other trade peer lists directly. Together, this gives the swarm the resilience to keep functioning on DHT/PEX alone even if the tracker goes down.
| Mechanism | How it works | Strengths | Weaknesses |
|---|---|---|---|
| Tracker | Announces to a central server over HTTP/UDP to fetch the participant list | Simple to implement; easy to collect statistics and enforce policy | Can be a single point of failure; carries operating costs |
| DHT (BEP 5) | Looks up peer info keyed on the info hash via a Kademlia-family DHT | No tracker needed; strong censorship resistance | Queries are observable; initial peer discovery can be slower |
| PEX (BEP 11) | Already-connected peers periodically exchange peer lists | Complements both tracker and DHT, speeding up discovery | Useless with zero existing connections |
uTP and congestion control
uTP (LEDBAT, Low Extra Delay Background Transport) improves congestion control so that background transfers do not crowd out foreground traffic. Where classic TCP treats packet loss as the congestion signal, uTP's distinguishing feature is using a rise in one-way delay as an early congestion signal, throttling its own send rate before other TCP traffic on the same link (web browsing, for example) is affected. This is what keeps "BitTorrent slowing down the whole household's internet" from happening. uTP is implemented on top of UDP, handling ordering and retransmission itself.
What changed in BitTorrent v2 (BEP 52)
Standardized in 2020, BitTorrent v2 made several important changes to hashing and file structure.
- A new hash function: SHA-256 replaces v1's SHA-1 (whose collision resistance has been broken in practice), strengthening the cryptographic guarantees.
- Per-file Merkle trees: where v1 concatenated the hashes of all pieces into one flat list, v2 builds an independent Merkle tree (a "piece layer") per file. This makes it far easier to detect and deduplicate the same file when it appears across multiple torrents.
- More efficient partial verification: the Merkle tree structure lets a client verify just part of a file efficiently, lowering the cost of re-fetching data after corruption is detected.
- Hybrid torrents: a "hybrid torrent" carries both a v1 and a v2 info hash, letting old and new clients alike join the same swarm.
Legitimate uses: more than just "illegal file sharing"
BitTorrent is often discussed as a distribution channel for infringing content, but the protocol itself is a general-purpose, use-case-agnostic distribution technology, and it is widely used for legitimate large-scale data distribution.
| Domain | Notable examples | Why it is used |
|---|---|---|
| Linux distribution images | Install ISOs for distributions such as Ubuntu and Debian | Reciprocal uploading among users offsets the bandwidth cost of official mirror servers |
| Game and software delivery | Distributing large patches and update files | Even under a rush of demand right after a release, downloaders themselves add distribution capacity, easing congestion |
| Academic archives | Large public datasets, such as those released by the Internet Archive | A permanent redistribution channel that does not depend on any single operator |
| Internal infrastructure | Software distribution within large data centers | Avoids concentrating simultaneous access on a central server, scaling distribution horizontally |
What all of these examples share is BitTorrent's self-scaling property: the more demand concentrates, the more distribution capacity becomes available. The protocol's technical merits are ultimately a separate question from whether a given use is lawful, and the defenses against abuse covered in attacks and defenses coexist perfectly well with all of these legitimate uses. For the research lineage of P2P distribution, see the references.