How BitTorrent Works

Every time someone downloads a Linux ISO, a game patch, or a scientific dataset via BitTorrent, they participate in one of the most elegant distributed systems ever deployed on the public internet. BitTorrent turns the fundamental scaling problem of file distribution on its head: instead of a single server buckling under load as demand increases, every downloader simultaneously becomes an uploader, and the swarm grows stronger with each new participant. Understanding how BitTorrent works means understanding peer-to-peer networking, distributed hash tables, incentive-compatible mechanism design, and the TCP and UDP transport layers that carry it all.

The .torrent File and Info Hash

A BitTorrent transfer begins with metadata. The original mechanism uses a .torrent file — a small file encoded in bencode (a simple serialization format using ASCII delimiters for strings, integers, lists, and dictionaries). The .torrent file contains two main sections:

The info dictionary is the critical part. BitTorrent divides the target file (or files) into fixed-size pieces, typically 256 KB to 4 MB each. The .torrent file stores the SHA-1 hash (20 bytes) of every piece. When a peer downloads a piece, it computes the SHA-1 hash and compares it to the expected value. If they do not match, the piece is discarded and re-requested. This is how BitTorrent guarantees data integrity without trusting any individual peer.

The info hash is the SHA-1 hash of the entire bencoded info dictionary. It serves as the globally unique identifier for the torrent. Two .torrent files with different announce URLs but the same info dictionary produce the same info hash and refer to the same content. The info hash is 20 bytes (160 bits) and is the value peers use to find each other — it is the key that ties the entire swarm together.

BEP 3: The Original Protocol Specification

The BitTorrent protocol is specified in a series of BitTorrent Enhancement Proposals (BEPs). BEP 3 is the foundational specification, written by Bram Cohen, that defines the .torrent file format, the tracker protocol, and the peer wire protocol. Nearly every BitTorrent feature in use today builds on or extends BEP 3. The specification is intentionally minimal — the original protocol has just a handful of message types — which is why it has been so easy to implement and extend across dozens of clients.

The Tracker Protocol

Trackers are HTTP (or UDP) services that help peers find each other. They do not transfer any file data — they are coordination servers that maintain a list of peers participating in a given torrent.

HTTP Tracker Protocol

The original tracker protocol is HTTP-based. A client sends a GET request to the announce URL with parameters including:

GET /announce?info_hash=%ab%cd...&peer_id=...&port=6881&uploaded=0&downloaded=0&left=524288000&event=started

The tracker responds with a bencoded dictionary containing a list of peers (IP addresses and ports) and an interval value telling the client how often to re-announce. A typical interval is 30 minutes. The tracker may return a compact peer list (6 bytes per peer: 4 for IPv4 + 2 for port) or a verbose format with peer IDs.

UDP Tracker Protocol (BEP 15)

Because HTTP announces carry significant overhead (TCP handshake, HTTP headers, TLS in many cases), BEP 15 introduced a UDP-based tracker protocol. The UDP protocol uses a simple connection ID mechanism: the client sends a connect request, receives a connection ID, then sends announce requests using that ID. The entire exchange is typically two round trips, versus the multiple round trips required for HTTP+TLS. Large public trackers serve millions of peers and overwhelmingly prefer UDP for the reduced resource consumption.

Tracker Peer A Peer B Peer C Seed Peer D Tracker announce Peer data exchange

The Peer Wire Protocol

Once a client has a list of peers from the tracker (or from DHT, PEX, or a magnet link), it establishes TCP connections to them and begins the peer wire protocol. This is where the actual data transfer happens.

Handshake

Every peer connection starts with a handshake. The initiating peer sends a 68-byte message:

<1 byte: pstrlen = 19>
<19 bytes: pstr = "BitTorrent protocol">
<8 bytes: reserved (extension flags)>
<20 bytes: info_hash>
<20 bytes: peer_id>

The receiving peer responds with the same format. Both peers verify that the info hash matches — if it does not, the connection is dropped. The 8 reserved bytes are used as feature flags: clients set specific bits to advertise support for extensions like DHT (bit 0 of the last byte), Fast Extension (bit 2), and the Extension Protocol (bit 20 from the right).

Message Types

After the handshake, all communication uses length-prefixed messages. The core messages are:

The choke/unchoke and interested/not-interested messages form a two-axis state machine. Each end of a connection has two bits of state about the other end: am I choking them? and are they interested in me? Data only flows when the sender is unchoking and the receiver is interested. This mechanism is the foundation of BitTorrent's incentive system.

Piece Selection: Rarest First

When a peer can request pieces from multiple sources, choosing which pieces to download first has enormous impact on swarm health. BitTorrent uses the rarest-first algorithm: the client maintains a count of how many peers have each piece (learned from bitfield and have messages) and preferentially requests the pieces that the fewest peers possess.

Rarest-first serves two purposes. First, it replicates rare pieces quickly, preventing a situation where some pieces are abundant while others exist on only one or two peers. If the sole seeder of a rare piece goes offline before that piece has been replicated, the entire swarm stalls permanently — nobody can complete the download. Second, it increases the diversity of pieces across the swarm, which means any two peers are more likely to have pieces the other needs, improving overall download speed.

There is one exception: when a peer first joins and has nothing, it uses random first piece selection. A brand-new peer needs to acquire its first complete piece as quickly as possible so it has something to offer in exchange. Requesting a common piece (which many peers have) gets the new peer uploading faster than requesting a rare piece that only one slow peer can provide.

Piece Distribution Across 4 Peers Piece 0 Piece 1 Piece 2 Piece 3 Piece 4 Peer A Peer B Peer C Peer D 4 copies 2 copies 1 copy 2 copies 0 copies Rarest first: request Piece 2 first

Tit-for-Tat Choking Strategy

BitTorrent's choking algorithm is its most ingenious contribution. It solves the free-rider problem — the tendency for users to download without uploading — through a mechanism borrowed from game theory: tit-for-tat.

Every 10 seconds, a downloading peer re-evaluates which peers to unchoke. It selects the top 4 peers (by default) that are uploading data to it at the highest rate, and unchokes them. Everyone else is choked. This creates a reciprocal exchange: if you upload to me quickly, I will upload to you quickly. Peers who refuse to upload receive nothing in return.

The choking algorithm runs on a 10-second timer. At each interval:

  1. Sort all interested peers by their upload rate to us (how fast they are sending us data)
  2. Unchoke the top 4 (the "regular unchoke" slots)
  3. Choke everyone else

This creates a natural market: peers that have desirable pieces and upload bandwidth gravitate toward each other, forming efficient exchange clusters. Free-riders who download without uploading get choked by everyone and receive very slow download speeds.

Optimistic Unchoking

Pure tit-for-tat has a bootstrapping problem: a new peer that has no pieces yet cannot upload anything, so nobody would unchoke it, and it could never get started. BitTorrent solves this with optimistic unchoking: every 30 seconds, the client randomly unchokes one additional peer, regardless of that peer's upload rate. This gives new peers a chance to receive their first pieces and start participating in the economy.

Optimistic unchoking also serves as exploration. The current top-4 peers might not be the best available — there might be a faster peer that has not been tried yet. The random optimistic unchoke slot provides a continuous probe of the peer population, allowing the client to discover better trading partners.

Choking Algorithm (every 10s) Our Client Upload to us Peer 1 500 KB/s UNCHOKED Peer 2 320 KB/s UNCHOKED Peer 3 210 KB/s UNCHOKED Peer 4 80 KB/s UNCHOKED Random Peer Optimistic unchoke (every 30s) Top 4 by upload rate

Seeder Choking Strategy

A seeder (a peer that has the complete file) uses a different choking algorithm. Since it does not need to download anything, tit-for-tat makes no sense — there is no reciprocal exchange to optimize. Instead, seeders typically unchoke peers that it has been uploading to the fastest, favoring peers with the most available bandwidth. Some clients rotate unchoke slots more frequently for seeders, every 10-20 seconds, to distribute pieces to as many peers as possible and maximize swarm health.

Endgame Mode

As a download nears completion, a problem arises: the last few pieces may only be available from slow peers, and a single slow peer can make the entire download stall at 99%. BitTorrent addresses this with endgame mode.

When all remaining pieces have been requested (i.e., there are no pieces left that have not been requested from at least one peer), the client enters endgame mode and sends requests for all remaining blocks to all peers that have them. As each block arrives from the first peer to respond, the client sends cancel messages to all other peers that were asked for the same block. This creates some bandwidth waste from duplicate requests, but it dramatically reduces the time spent waiting on the last few pieces. Endgame mode is only active for a brief period at the very end of the download, so the overhead is minimal.

Piece Verification: SHA-1 Hashing

Trust in BitTorrent is based on cryptographic hashes, not on trusting individual peers. The .torrent file contains a SHA-1 hash for every piece. After downloading all blocks of a piece, the client computes the SHA-1 hash of the assembled piece and compares it to the expected hash. If the hash does not match:

  1. The entire piece is discarded
  2. The peer(s) that sent blocks for that piece may be flagged
  3. The piece is re-requested from other peers

This mechanism makes it impossible for a malicious peer to inject corrupted data — any corruption is detected and discarded. However, it means a malicious peer can waste bandwidth by repeatedly sending bad data. Some clients implement banning heuristics: if a peer is the source of multiple bad pieces, it is disconnected and blacklisted.

The SHA-1 hash provides 160 bits of collision resistance. While SHA-1 is no longer considered secure for digital signatures (theoretical collision attacks exist), it remains sufficient for piece verification in BitTorrent because the attack model is different — an attacker would need to find a second preimage (a different piece that hashes to the same value), which is far harder than finding a collision. BitTorrent v2 (discussed below) migrates to SHA-256 for additional security margin.

Magnet Links

Magnet links eliminate the need for .torrent files. A magnet link encodes the info hash directly in a URI:

magnet:?xt=urn:btih:a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2&dn=Example+File&tr=udp://tracker.example.com:6969

When a client opens a magnet link, it only has the info hash. It contacts the tracker (if provided) or uses DHT to find peers for that info hash, connects to them, and downloads the metadata (the info dictionary from the .torrent file) via BEP 9 (the metadata extension). Once it has the metadata — including piece hashes — it can begin downloading and verifying pieces normally.

Magnet links are how most torrents are shared today. They are small enough to embed in a webpage, tweet, or text message, and they do not require hosting a .torrent file anywhere.

Distributed Hash Table (DHT)

The tracker is a single point of failure: if it goes down, new peers cannot discover the swarm. DHT (BEP 5) eliminates this dependency by implementing a distributed, decentralized peer discovery mechanism based on the Kademlia algorithm.

In BitTorrent's DHT, every participating client maintains a routing table of other DHT nodes, organized by their distance (XOR metric) from the node's own ID. To find peers for a given info hash, a node performs an iterative lookup: it asks the nodes closest to the target hash in its routing table, which respond with nodes even closer, until the closest nodes are found. Those closest nodes store the peer lists for torrents with nearby info hashes.

DHT makes BitTorrent fully decentralized. Even if every tracker in the world went offline simultaneously, existing swarms would continue functioning, and new peers could still discover them through DHT. In practice, modern clients use both trackers and DHT simultaneously for maximum reliability.

Peer Exchange (PEX / BEP 11)

Peer Exchange (PEX), specified in BEP 11, allows peers to exchange peer lists with each other directly, without contacting a tracker or DHT. Once a peer is connected to the swarm, it periodically sends the list of peers it knows about to its connected peers. This creates a gossip-like protocol where peer discovery information propagates organically through the swarm.

PEX is particularly valuable because it provides faster peer discovery than tracker re-announces (which happen every 30 minutes) and is more bandwidth-efficient than DHT lookups. A peer that just connected through a tracker can learn about dozens of additional peers within seconds via PEX messages from its initial connections.

uTP: Micro Transport Protocol

Traditional BitTorrent runs over TCP, which works but has a problem: TCP's congestion control treats all connections equally, meaning BitTorrent traffic competes aggressively with web browsing, video calls, and other interactive traffic on the same connection. This is one reason ISPs historically throttled BitTorrent.

uTP (Micro Transport Protocol, BEP 29) is a transport protocol built on top of UDP that implements LEDBAT (Low Extra Delay Background Transport). LEDBAT is specifically designed to use only "leftover" bandwidth — it monitors one-way delay and backs off when it detects that it is adding queuing delay to the network path. This means uTP traffic automatically yields to interactive traffic.

uTP measures the minimum observed one-way delay as a baseline, and targets adding no more than 100 milliseconds of additional delay. When the measured delay exceeds this target, uTP reduces its sending rate. When delay is below the target, it slowly increases. The result is a transport that saturates idle links but immediately backs off when other traffic is present.

Most modern BitTorrent clients (including libtorrent-based clients like qBittorrent and Deluge) use uTP by default, making BitTorrent a much better network citizen than it was in the mid-2000s. This is also relevant to NAT traversal — uTP's use of UDP allows techniques like UDP hole punching to establish connections between peers behind NAT gateways without requiring port forwarding.

Protocol Encryption (MSE/PE)

In the mid-2000s, many ISPs began using deep packet inspection (DPI) to identify and throttle BitTorrent traffic. The peer wire protocol's handshake (starting with the fixed string "BitTorrent protocol") was trivially identifiable. In response, clients implemented Message Stream Encryption (MSE), also called Protocol Encryption (PE).

MSE uses Diffie-Hellman key exchange (768-bit by default) to establish a shared secret, then encrypts the stream using RC4. The encryption is not designed to provide strong security against a determined attacker — RC4 is considered cryptographically broken — but it makes the traffic opaque to DPI appliances that look for fixed byte patterns. The handshake itself is randomized to avoid statistical fingerprinting.

Most clients support MSE in three modes: disabled, enabled (prefer encrypted but accept plaintext), and forced (only connect to peers that support encryption). In practice, ISP-level BitTorrent throttling has become less common as uTP reduced the congestion impact and as ISPs shifted to usage caps instead of protocol-specific throttling.

BitTorrent v2 (BEP 52)

BitTorrent v2, specified in BEP 52, is a significant protocol upgrade that addresses several limitations of the original protocol:

SHA-256 and Per-File Merkle Trees

The most fundamental change is replacing SHA-1 with SHA-256 for piece hashing, and switching from a flat hash list to a Merkle tree per file. In v1, the .torrent file stores one SHA-1 hash per piece, and pieces can span file boundaries in multi-file torrents. In v2, each file has its own Merkle tree of SHA-256 hashes with a fixed leaf size of 16 KB (the same as the block request size).

This architecture has several advantages:

Hybrid Torrents

To ease the transition, BEP 52 defines hybrid torrents that contain both v1 and v2 metadata. A hybrid torrent has both the traditional SHA-1 piece hashes and the new SHA-256 Merkle trees. V1-only clients can still participate using the legacy hashes, while v2-capable clients use the new format. The info hash for v2 uses SHA-256 (32 bytes) instead of SHA-1 (20 bytes).

Web Seeding

Web seeding (BEP 19 and BEP 17) allows a standard HTTP server to act as a seed in a BitTorrent swarm. The .torrent file includes one or more HTTP URLs alongside the tracker announce URL. BitTorrent clients can download pieces from the HTTP server using standard HTTP GET requests with Range headers, while simultaneously downloading from regular peers.

This is particularly useful for the initial seeding phase: instead of requiring a BitTorrent client to be running, the content creator can simply host the file on a web server. As peers download from the HTTP seed and begin uploading to each other, the BitTorrent swarm bootstraps itself. Many Linux distributions use web seeding — the ISO is available via both direct HTTP download and BitTorrent, and the BitTorrent swarm can pull pieces from the HTTP mirror.

Super Seeding

Super seeding (BEP 16) is a mode for the initial seeder — the peer that has the complete file and is seeding it for the first time to an empty swarm. In normal seeding, the seeder uploads pieces to random peers, which may result in the same piece being uploaded multiple times before rarer pieces are seeded even once. Super seeding pretends to be a regular peer that only has a few pieces (via a selective bitfield), and only reveals a new piece to a peer after confirming that a previously given piece has been forwarded to another peer.

This ensures maximum piece diversity in the initial seeding phase: each piece uploaded by the initial seeder ideally propagates to other peers before the seeder uploads any piece a second time. Super seeding can reduce the initial seeder's upload requirement to approximately 1.0x the file size (each piece uploaded exactly once) compared to the 1.5-2.0x typical without it.

Real-World Traffic Patterns and ISP Throttling

BitTorrent traffic once constituted 25-35% of all internet traffic (estimates varied, with some reports claiming as high as 50% in certain regions during 2008-2010). ISPs responded with a variety of traffic management techniques:

Today, BitTorrent's share of overall internet traffic has declined significantly (estimates place it at 2-5% of total traffic as of the mid-2020s), largely displaced by streaming services. However, it remains the dominant protocol for large file distribution where no single entity wants to bear the full bandwidth cost. The relationship between BitTorrent traffic and ISP networks is fundamentally a routing and interconnection problem — heavy BitTorrent usage between peers in different autonomous systems generates cross-network traffic that someone must pay to carry.

Legitimate Uses

BitTorrent is a general-purpose file distribution protocol with many significant legitimate applications:

The BitTorrent protocol's network traffic traverses the same BGP routing infrastructure as all other internet traffic. Peers in a swarm connect across autonomous system boundaries, and the performance of those connections depends on the peering and transit relationships between the networks involved. A peer downloading from a seed in the same ISP will typically see faster speeds than one downloading across multiple transit hops — this is exactly the kind of path information visible in a BGP looking glass.

The Full BitTorrent Connection Lifecycle

Putting it all together, here is the complete sequence from opening a .torrent file to completing a download:

  1. Parse metadata — read the .torrent file or resolve the magnet link to obtain the info hash and piece hashes
  2. Contact tracker — send an announce request to get an initial peer list, and/or query DHT for peers
  3. Connect to peers — establish TCP (or uTP) connections and perform the protocol handshake
  4. Exchange bitfields — learn which pieces each peer has
  5. Request pieces — using rarest-first selection, send request messages for 16 KB blocks
  6. Verify pieces — after downloading all blocks of a piece, verify its SHA-1 hash
  7. Announce new pieces — send have messages to all connected peers for each verified piece
  8. Choking algorithm — every 10 seconds, re-evaluate which peers to unchoke based on upload reciprocity
  9. PEX — periodically exchange peer lists with connected peers to discover new peers
  10. Endgame — when all remaining pieces are already requested, send duplicate requests to all eligible peers
  11. Seed — after completing the download, continue uploading to other peers

This lifecycle, driven by a handful of simple message types and a few carefully designed algorithms, produces a system that scales effortlessly from two peers to tens of thousands, all without any central coordination beyond an optional tracker. The protocol's TCP connections are routed through the internet's BGP infrastructure, crossing autonomous system boundaries and traversing NAT gateways — the same network fabric that this looking glass lets you explore.

See BGP routing data in real time

Open Looking Glass
More Articles
How WebSockets Work
How WebRTC Works
What is BGP? The Internet's Routing Protocol Explained
What is an Autonomous System (AS)?
What is a BGP Looking Glass?
How to Look Up an IP Address's BGP Route