Learn Aria2 - Core Concepts & Main Architecture

#Introduction

After understanding aria2's history in episode 1 — the lightweight project by Tatsuhiro Tsujikawa with the power of multi-connection and multi-source — it's now time to dissect how aria2 works from the inside. This episode is the bridge between "why aria2 exists" and "how to use it," so follow the flow carefully.

Many aria2 users treat it like a photocopier: give it an address, wait for the result. Yet behind a single line like aria2c https://example.com/file.iso sits a fairly sophisticated machine: segment management, parallel connections, control files, and a remote interface. Understanding this machine — like opening the hood before driving — will make you far more confident when results don't match expectations.

#Three Ways to Run aria2c

The main aria2 program is named aria2c, and it can run in three different modes depending on your needs:

aria2c https://example.com/file.iso

aria2c -D https://example.com/file.iso

aria2c --enable-rpc --rpc-listen-port=6800

The simple analogy: foreground is like driving the car yourself, daemon is like handing your truck to a driver who leaves without you, and RPC server is like owning a logistics center that takes orders over the phone. All modes use the same binary and configuration — only the way you control them differs.

#Multi-Connection & Segment-Based Download

The core of aria2's performance lives in one concept: segment-based download. Before downloading, aria2 divides the file into segments (chunks) of a certain size. Each segment is downloaded independently, and when all segments are finished, aria2 reassembles them into one complete file.

The flow:

1. aria2 asks the server for file information (via the Content-Length header).
2. The file is split into segments according to the --split option.
3. Each segment is downloaded over its own connection (governed by --max-connection-per-server).
4. Finished segments are tidied immediately; failed ones are retried.
5. All intact segments are merged into the final file.

Why does this matter? A single TCP connection is like a one-lane toll road — no matter how much bandwidth is available, one vehicle won't use it all. By splitting the file into segments and pulling them over several connections at once, aria2 fills the road with many vehicles simultaneously. It's like a community moving a stack of books: six people carrying six separate stacks is far faster than one person carrying everything.

#The .aria2 Control File

While a download is incomplete, aria2 stores a control file next to the target file — named with the extra extension .aria2. For example, if the target file is named ubuntu.iso, then during the process you'll see:

ubuntu.iso
ubuntu.iso.aria2

The .aria2 file is not part of the file itself — it contains progress metadata: which segments are done, the total size, and the information needed to continue. It's like a bookmark recording the last page you read. When the download finishes, this control file is deleted automatically. When the download interrupts, aria2 reads the control file to continue from the last position without restarting from zero — we'll take full advantage of this in episode 5.

#Main Components

Now that you understand the modes and the segment concept, let's map out the components that make up the aria2 ecosystem:

The config file is the "home" of your habits. Instead of typing options over and over, you can put them there once:

# ~/.aria2/aria2.conf - minimal example configuration
# Applies to all aria2 sessions for this user
 
# Download
dir=/home/user/downloads
max-concurrent-downloads=5
split=5
max-connection-per-server=16
min-split-size=20M
 
# Resume
continue=true
 
# Log
log=/var/log/aria2/aria2.log
console-log-level=warn
summary-interval=60

The format is simple: option=value, one per line, without the -- prefix. Lines starting with # are comments. Values in the config file are defaults — command-line options always win if you override them. This config file can be loaded automatically from the default location, or explicitly with aria2c --conf-path=~/.aria2/aria2.conf.

#Key Options You'll Use Constantly

These five options will accompany you through almost every remaining episode:

Note the default -x = 1: even though -s splits the file into 5 segments, without an -x greater than 1 aria2 still uses only one connection per server — so those segments are downloaded sequentially. The -x 16 -s 16 combination you saw in episode 1 is the common way to release this brake. We'll cover it all in episode 4.

#Closing

In episode 2, you dissected aria2's architecture from the inside: the three ways to run aria2c (foreground, daemon, RPC server), the segment-based download concept that powers its performance, the role of the .aria2 control file, the main components (binary, config file, RPC interface), and the five key options you'll keep using.

Key takeaways:

• aria2c runs in three modes: direct CLI, daemon (-D), and RPC server (--enable-rpc).
• Download is segment-based: the file is split, downloaded in parallel, then reassembled — that's the source of its speed.
• The .aria2 control file stores progress for resume and metadata.
• The ~/.aria2/aria2.conf config file stores defaults; command-line options always win.
• -x (connections/server), -s (segments), -j (concurrency), -i (input file), --enable-rpc (RPC).

In the next episode, episode 3, we start real hands-on work: basic file downloads over HTTP/HTTPS — running your first download, understanding aria2's progress output, setting the destination directory with -d, renaming files with -o, and mastering the progress bar and log output. See you in episode 3!