Aria2 с несколькими соединениями на сервер для быстрых загрузок ISO и торрентов

Канал в дата-центре может быть гигабитным, а загрузка образа всё равно ползёт на три мегабайта в секунду. Причина не в кабеле: один поток HTTP упирается в лимиты на соединение, которые расставляют зеркала и CDN ради равномерной нагрузки. aria2 решает задачу иначе: файл делится на сегменты, каждый сегмент качается своим соединением, а список протоколов не ограничивается HTTP и включает FTP, BitTorrent и Metalink.

Разберём ключевые параметры параллельности, живой сценарий с образом дистрибутива Linux, пакетные списки заданий, работу с BitTorrent-протоколом для официальных раздач и собственных архивов и восстановление после сбоев.

Пределы одного потока и выигрыш от параллельности

Одиночное соединение TCP ограничено окном передачи и задержкой до сервера, а зеркала часто режут скорость на одно подключение, чтобы обслужить больше клиентов. Поэтому классический загрузчик с одного зеркала показывает стабильные несколько мегабайт в секунду, даже когда канал позволяет в сотню. aria2 разбивает файл на части и запрашивает их диапазонами HTTP Range, держа на сервере несколько соединений одновременно. Сервер должен поддерживать запросы диапазонов: если он отдаёт файл целиком, загрузка идёт одним соединением, и об этом честно сообщает вывод.

Математика проста: пропускная способность одного соединения ограничена окном TCP и временем оборота пакета. При задержке в 100 мс даже щедрое окно даёт десятки мегабит, и канал быстрее не станет. Несколько соединений суммируют окна, и суммарная скорость растёт почти линейно, пока сервер не начнёт ограничивать клиента. Отдельный бонус Metalink-формата: в одном файле перечислены десятки зеркал, и aria2 качает с нескольких серверов сразу, перекладывая сегменты на живые адреса, когда одно зеркало тормозит.

Проект развивается с 2006 года, распространяется по лицензии GPLv2 и ставится из репозиториев всех основных дистрибутивов. Утилита работает в двух ролях: как загрузчик прямых ссылок и как клиент BitTorrent, причём обе роли смешиваются в одном сеансе. Поддержка протоколов шире, чем у многих собратьев: HTTPS, FTP, SFTP, BitTorrent и Metalink в одном исполняемом файле с общими лимитами. Конфигурация живёт в аргументах командной строки и в файле ~/.aria2/aria2.conf, что удобно для серверов без графики.

Число соединений, сегменты и минимальный размер части

Три флага управляют параллельностью. -x, он же --max-connection-per-server, задаёт число соединений на один сервер, по умолчанию 1, потолок 16. -s, он же --split, определяет, на сколько сегментов делится файл, по умолчанию 5. -k, он же --min-split-size, задаёт минимальный размер сегмента, по умолчанию 20 МБ: файл на 100 МБ при -s 5 даст пять частей по 20 МБ.

aria2c -x16 -s16 -k1M \
  https://mirror.example.com/iso/ubuntu-24.04.2-desktop-amd64.iso

Чем мельче сегменты, тем ровнее заполняется канал, но тем больше соединений открывается. Поднимать -x стоит с оглядкой: у зеркал бывают лимиты на клиента, при превышении начинают приходить ответы 429, а часть администраторов режет слишком настойчивых клиентов вовсе. Практический максимум для одного надёжного зеркала это 8-16 соединений при -k от 1 МБ. Небольшая арифметика помогает выбрать размер части: файл на 1 ГБ при -k 1M и -s 16 разобьётся на сегменты по 64 МБ, и все шестнадцать соединений работают до конца. При -k 20M те же настройки дадут части по 20 МБ, и после исчерпания первых 320 МБ соединения начнут простаивать. Поэтому -k обычно опускают до мегабайта на крупных образах и держат побольше на множестве средних файлов.

Независимые файлы одновременно считает флаг -j, по умолчанию пять загрузок, а --lowest-speed-limit=100K выбрасывает зависшие соединения и перераспределяет сегменты между живыми. Для кучи мелких файлов есть режим -Z: утилита принимает произвольное число адресов и качает их параллельно без разбивки на сегменты. Предельные настройки хранят в конфиге: пара строк max-connection-per-server=16 и min-split-size=1M в ~/.aria2/aria2.conf освобождает от набора флагов при каждом запуске.

Загрузка образа дистрибутива и проверка целостности

Живой сценарий: скачать образ Ubuntu для нового сервера за минуты и убедиться, что биты не повредились. Рядом с образами публикуются файлы SHA256SUMS, и проверка должна стать привычкой: повреждение при скачивании редко видно глазом, а расходуется оно потом на установки и отладку.

aria2c -x16 -s16 -k1M -c \
  https://mirror.example.com/iso/ubuntu-24.04.2-desktop-amd64.iso
sha256sum -c SHA256SUMS 2>&1 | grep -v ': OK$' || echo "все суммы сходятся"

aria2 умеет проверять целостность сама: опция --checksum=sha-256=<сумма> сверяет хеш по ходу скачивания, и порча ловится до записи на диск, а не после. а --check-integrity, коротко -V, пересобирает испорченные части, если сервер отдаёт контрольные суммы. Для Metalink-файлов проверка встроена в формат, и зеркала крупных дистрибутивов отдают именно их. Ключ -c продолжает прерванную загрузку с места остановки, и параллельная схема здесь дружит с докачкой: каждая часть хранится отдельно, а служебный файл .aria2 запоминает прогресс.

Рядом с образами публикуют и подписи GPG, и проверка подписи файла с суммами закрывает вопрос о подмене на зеркале. Порядок ответственной загрузки образа выглядит так:

1. взять ссылку на образ из официального списка дистрибутива;
2. запустить aria2c с -x16, -s16 и -c;
3. скачать рядом файл контрольных сумм;
4. сверить сумму командой sha256sum -c;
5. записать образ на носитель или передать на сервер.

Файл заданий и пакетная загрузка

Десяток образов удобнее не набирать вручную, а перечислить в файле и отдать через -i. Каждая запись списка это адрес, а опции задаются и общими флагами, и построчно: отступ с начала строки превращает строку в параметры конкретной загрузки.

# urls.txt
https://mirror.example.com/iso/ubuntu-24.04.2-desktop-amd64.iso
  out=ubuntu.iso
https://mirror.example.com/iso/debian-12-amd64-netinst.iso
  out=debian.iso

aria2c -i urls.txt -j 2 -x8 -c --save-session=aria2.session

Флаг -j ограничивает число одновременных загрузок, чтобы десять файлов не дрались за канал. --save-session пишет незавершённые задания в файл, и после сбоя сервера список восстанавливается тем же -i. Построчное имя через out= спасает, когда адреса на зеркале длинные и вложенные, а локально нужны короткие имена. Для ночных обновлений пары образов хватает cron-строки, для сложных расписаний лучше systemd-таймер с OnCalendar. Строки-параметры понимают referrer=, check-integrity=true и другие ключи конфигурации, полный перечень живёт в описании формата входного файла. Построчные опции понимают и заголовки: строка header=Authorization: Bearer <токен> открывает доступ к закрытому зеркалу с образами своей команды, а out= раскладывает содержимое по нужным именам. Список генерируют и на лету: вывод ls с адресами через awk превращается в urls.txt, и пакетные обновления перестают быть ручной работой. Сессию можно вести в один файл между запусками, и очередь накапливается: утром сервер дожимает всё, что было запланировано за ночь.

BitTorrent протокол для дистрибутивов и своих архивов

Многие дистрибутивы официально распространяют образы по BitTorrent: это снимает нагрузку с их зеркал и часто даёт скорость выше HTTP. aria2 принимает .torrent-файл как аргумент и качает сразу от нескольких участников, а список адресов берёт из самого файла. Тот же протокол удобен для собственных задач: большой архив между двумя офисами или раздача собранного образа внутри команды. Мультиисточниковость работает и в обратную сторону: один образ качается одновременно по HTTP и через BitTorrent, и aria2 собирает его из обоих источников, добирая у более быстрого.

aria2c --seed-ratio=1.0 --seed-time=120m --check-integrity \
  ubuntu-24.04.2-desktop-amd64.iso.torrent

Флаг --seed-ratio=1.0 просит раздать скачанное минимум в том же объёме, --seed-time держит раздачу два часа, и только затем aria2 завершается. Проверка --check-integrity сверяет части по хешам из .torrent, поэтому испорченный кусок перекачивается, а не молча пишется на диск. Диапазон входящих портов настраивает --listen-port, число участников на раздачу ограничивает --bt-max-peers, а --enable-dht включает распределённый поиск участников для открытых раздач. Для обмена между своими серверами он не нужен, адресов из файла достаточно, и закрытая раздача получается и быстрой, и управляемой. Внутри .torrent с набором файлов качают и выборочно: aria2c --show-files перечисляет содержимое с номерами, а --select-file=1,3 берёт только нужные позиции. Для сборки из десятка образов это экономит и место, и время. Входящий порт стоит держать открытым на фаерволе: закрытый порт снижает число участников, и раздача ползёт на десятках килобайт.

Продолжение после сбоя и файловые операции

Крупная загрузка переживает сбои сети, если настроено продолжение. Ключ -c работает и для HTTP, и для BitTorrent, контрольные файлы .aria2 остаются рядом с содержимым и удаляются по завершении. Предвыделение места через --file-allocation=falloc экономит время на файловых системах с экстентами, вариант none пропускает выделение вовсе, что удобно на дисках небольшого объёма.

aria2c -c -x16 -s16 --file-allocation=falloc \
  --max-tries=0 --retry-wait=10 \
  --max-overall-download-limit=50M \
  https://mirror.example.com/iso/big-image.iso

--max-tries=0 означает терпеливые попытки без предела, --retry-wait=10 паузу между ними, и загрузка на флуктуирующем канале заканчивается сама, без участия человека. Ограничение --max-overall-download-limit не даёт фоновому скачиванию занять весь канал, симметричный предел для раздачи задаёт --max-overall-upload-limit. Код выхода отличает успешное завершение от прерванного, и скрипт с set -e честно падает, если образ так и не доехал. Служебные файлы .aria2 чистят по завершении: find -name "*.aria2" -delete после успешного прогона, иначе они накапливаются рядом с готовыми образами. Коллизии имён контролирует --auto-file-renaming=false: без него повторная загрузка молча создаст копию с суффиксом .1, и сценарий проверит не тот файл. Контроль места сводится к регулярной ротации старых версий образов и к общему лимиту скорости, который не даёт фоновым задачам отбирать канал у рабочих служб. Отдельный случай это квота на конкретную загрузку: --max-download-limit ограничивает темп одного файла, когда общий лимит не подходит.

RPC интерфейс и управление из скриптов

aria2 умеет работать как фоновая служба с JSON-RPC интерфейсом на порту 6800, и это превращает её в бэкенд собственной загрузочной панели. Запуск с --enable-rpc и --rpc-secret=<токен> открывает управление: добавление заданий, опрос прогресса, снятие задач.

aria2c --enable-rpc --rpc-listen-all=false --rpc-secret=local-token
curl http://localhost:6800/jsonrpc -d \
  '{"jsonrpc":"2.0","id":"q","method":"aria2.tellActive"}'

Добавление задания без захода на сервер выглядит так:

curl http://localhost:6800/jsonrpc -d \
  '{"jsonrpc":"2.0","id":"a","method":"aria2.addUri","params":["token:local-token",["https://mirror.example.com/iso/new.iso"]]}'

Внутри локальной сети этого достаточно для дашборда, наружу порт открывают только с ограничением по адресу и свежим токеном. Пара методов tellActive и tellWaiting даёт живую картину очереди, addUri добавляет новую загрузку не вставая с места, а pause и unpause управляют порядком. В связке с -i, расписаниями и журналом получается полноценная служба загрузок без графического интерфейса: сервер качает сам, а человек лишь заглядывает с проверкой. Постоянную службу ставят под systemd-юнит: Restart=on-failure поднимает её после сбоя, а секретный токен передаётся через Environment и не светится в истории команд. Такой комплект превращает любой домашний или офисный сервер в аккуратную станцию загрузки с параллельностью на шестнадцать соединений и честной проверкой каждого байта.