Хеши и магнитные ссылки: что именно проверяется при скачивании торрента

Когда вы открываете магнитную ссылку или добавляете торрент-файл, клиент почти мгновенно начинает поиск источников — хотя вы не указали ни адрес сервера, ни имя файла. Вся эта магия держится на хешах: коротких отпечатках, которые однозначно идентифицируют раздачу и позволяют проверить каждый скачанный байт. В этой статье разберём, какие именно хеши существуют в BitTorrent-системе, что каждый из них проверяет, где они хранятся и почему иногда клиент «доскачивает» файл, который у вас уже есть.

Два уровня проверки: раздача целиком и её части

В BitTorrent проверка целостности работает на двух уровнях, и путать их не стоит.

Первый уровень — идентификация раздачи. Хеш здесь отвечает на вопрос «та ли это раздача вообще». Он не проверяет содержимое файла, а служит уникальным именем, по которому клиент находит пиров и метаданные.

Второй уровень — проверка данных. Это уже контроль целостности: сверка скачанных байтов с эталонными хешами частей. Именно благодаря ему клиент знает, какой кусок файла пришёл повреждённым, и запрашивает его заново у другого участника.

Оба уровня используют одну и ту же криптографическую идею — хеш-функцию, которая превращает любой объём данных в короткую строку фиксированной длины. Изменение даже одного байта даёт совершенно другой результат, поэтому подменить данные, сохранив хеш, практически невозможно.

Info-hash: главный идентификатор раздачи

Когда вы создаёте торрент, клиент формирует структуру метаданных — так называемый info-словарь. В нём записаны:

• имя раздачи;
• список файлов с их размерами (если файлов несколько);
• размер части (piece length);
• хеши всех частей файла;
• при необходимости — приватный флаг и другие служебные поля.

Info-hash — это хеш именно этого словаря. В классическом протоколе BitTorrent v1 для его вычисления используется SHA-1, результат — 20 байт, которые обычно записывают как 40 шестнадцатеричных символов. Например, в магнитной ссылке фрагмент xt=urn:btih:… содержит именно его.

Что из этого следует практически:

• Две раздачи с одинаковым info-hash — это одна и та же раздача, даже если в разных каталогах она называется по-разному.
• Если релизер пересобрал торрент (изменил размер части, состав файлов, добавил служебные данные), info-hash изменится, и клиенты увидят это как другую раздачу.
• Имя в магнитной ссылке (dn=) — лишь текстовая подсказка для отображения. На идентификацию оно не влияет и проверке не подлежит: раздачу определяет только btih-хеш.

Отсюда частый практический вывод: если вы хотите продолжить докачку из другого источника, совпадение названия файла ничего не гарантирует — совпадать должен info-hash.

Хеши частей: как проверяется каждый скачанный байт

Внутри info-словаря лежит поле pieces — длинная последовательность, в которой подряд записаны хеши всех частей раздачи. Часть (piece) — это блок фиксированного размера, например 256 КБ, 1 МБ, 4 МБ или больше в зависимости от общего объёма раздачи. Каждый такой блок при создании торрента прогоняется через SHA-1, и результат попадает в этот список.

Когда клиент получает блок данных от пира, он вычисляет хеш полученного фрагмента и сравнивает его с эталонным из метаданных. Совпал — блок считается валидным и записывается на диск. Не совпал — блок отбрасывается, а источник помечается как отдающий повреждённые данные.

Это решает сразу несколько задач:

• Целостность. Повреждения при передаче, ошибки диска, обрывы соединения не приводят к битому файлу — испорченный кусок просто перекачивается.
• Защита от подмены. Участник не может отдать вам произвольные данные вместо фрагмента фильма или программы: они не пройдут проверку.
• Точность докачки. Клиент знает, какие части уже валидны, и не перекачивает весь файл заново.

Важный нюанс: проверка идёт на уровне части, а не отдельного файла. Если в раздаче несколько файлов, они делят части между собой — граница части может проходить по двум файлам сразу. Поэтому «доскачать только один файл из раздачи» клиент может, лишь если нужные части полностью покрываются этим файлом.

Что проверяется в магнитной ссылке

Магнитная ссылка — это не файл, а короткая строка с параметрами. Классический вид выглядит примерно так:

magnet:?xt=urn:btih:ХЕШ&dn=ИМЯ&tr=АДРЕС_ТРЕКЕРА

Разберём, что здесь реально участвует в проверке, а что — нет.

• xt=urn:btih:… — единственный обязательный и проверяемый элемент. Это info-hash раздачи. По нему клиент находит пиров через DHT и трекеры.
• dn — отображаемое имя. Чисто косметический параметр: его можно стереть, и раздача не изменится.
• tr — адреса трекеров, вспомогательные источники пиров. Их наличие не обязательно и на целостность не влияет.
• xl — предполагаемый размер, подсказка. Не является гарантией.

Ключевое следствие: магнитная ссылка не содержит хешей частей. Она содержит только идентификатор раздачи. Хеши частей клиент получает позже — из метаданных, которые выкачивает у пиров (этот процесс называется получением метаданных через расширение протокола, в интерфейсах клиентов он часто виден как «получение метаданных» или «поиск источников»). Пока метаданные не получены, проверить нечего — клиент даже не знает размер и состав файлов.

Именно поэтому магнитную ссылку нельзя «проверить заранее» так, как торрент-файл: торрент-файл можно открыть и посмотреть содержимое до начала загрузки, а магнитная ссылка сначала подключает вас к сети, и только потом вы видите, что именно качаете.

BitTorrent v2: что изменилось в проверке

В протоколе версии 2, который постепенно поддерживается современными клиентами, схема проверки переработана:

• Хеш-функция SHA-1 заменена на более стойкую SHA-256.
• Появились два уровня хеширования: каждая часть разбивается на блоки по 16 КБ, и хеши считаются для блоков, а затем для частей из хешей блоков. Это позволяет проверять данные мельче и точнее.
• Хеширование ведётся отдельно для каждого файла, поэтому докачка и проверка отдельных файлов работают корректнее, чем в v1.
• Идентификатор раздачи (btih в магнитной ссылке) вычисляется уже из хешей файлов по правилам v2.

Существуют и гибридные торренты, совместимые одновременно с v1- и v2-клиентами: они содержат данные для обеих версий. Практический смысл для обычного пользователя простой: если раздача и клиент поддерживают v2, проверка целостности строже, а защита от коллизий — выше. Но базовая логика «идентификатор раздачи + хеши частей» сохраняется.

Проверка уже скачанных файлов и докачка

Хеши частей дают полезную возможность: клиент может проверить файлы, которые у вас уже есть на диске, и докачать только недостающее. Это называется повторной проверкой (force re-check, «проверить локальные данные»). Она полезна в нескольких ситуациях:

• вы прервали загрузку и хотите убедиться, что скачанное не повреждено;
• вы скопировали файлы с другого диска или от другого человека и хотите докачать раздачу без полной загрузки;
• после сбоя питания или ошибок диска нужно выяснить, какие части испорчены.

Порядок действий типовой:

1. Добавьте торрент-файл или магнитную ссылку в клиент (info-hash должен совпадать с исходной раздачей).
2. Укажите папку, где лежат имеющиеся файлы, — важно, чтобы имена файлов совпадали с указанными в раздаче.
3. Запустите принудительную проверку локальных данных.
4. Дождитесь результата: клиент сверит каждую часть с эталонными хешами и докачает только несовпадающие.

Если проверка показывает почти полный прогресс, а загрузка не идёт — возможно, раздача «мёртвая»: пиров с полными данными нет. Хеши тут ни при чём, проверять нужно активность раздачи.

Что хеш НЕ проверяет: ограничения, о которых стоит помнить

Хеш гарантирует, что вы получили именно те байты, которые были в исходной раздаче. Но он ничего не говорит о содержании этих байтов. Это принципиально важно понимать.

• Хеш не проверяет безопасность. Если релизер собрал торрент из файла с вредоносной программой, все части будут идеально совпадать с хешами — и файл пройдёт проверку на 100%. Целостность и безопасность — разные вещи.
• Хеш не подтверждает качество и подлинность. Перекодированное видео, обрезанный архив или переупакованная программа будут «валидными», если релизер посчитал их хеши от того, что выложил.
• Совпадение имени не гарантирует совпадение хеша. Одинаковое название файла в двух раздачах не означает, что это одни и те же данные.
• Хеш в магнитной ссылке не раскрывает содержимое. По btih-строке нельзя узнать, что за файл, — только найти его в сети.

Поэтому при загрузке программ и архивов из открытых источников разумная привычка — сверять хеш файла (например, SHA-256, указанный автором распространения) отдельными средствами после загрузки, если такая контрольная сумма опубликована. Это независимая от BitTorrent проверка, и она закрывает то, что хеши раздачи не проверяют: соответствие содержимого замыслу автора.

Типичные вопросы и ошибки

«Клиент пишет, что данные не прошли проверку. Что это значит?»

Часть файла на диске не совпадает с эталонным хешем. Причины: повреждение на диске, ошибка при копировании, изменение файла после загрузки (например, плеер или архиватор что-то дописали), реже — сбой самого клиента. Решение — принудительная проверка с последующей докачкой испорченных частей. Если раздача активна, файл восстановится; если пиров нет — восстановить будет не из чего.

«Магнитная ссылка не находит метаданные. Хеш неверный?»

Скорее всего, нет. Info-hash может быть корректным, но раздача не имеет активных участников, а DHT и трекеры из ссылки не отвечают. Проверьте, включены ли в клиенте DHT и обмен пирами, добавьте рабочие трекеры, попробуйте позже. Хеш сам по себе «не работает» только если он был скопирован с ошибкой — например, обрезан при копировании строки.

«Можно ли по хешу узнать, что внутри раздачи?»

Нет. Хеш — это отпечаток, а не описание. Узнать состав можно только получив метаданные от пиров или открыв торрент-файл, где метаданные записаны явно.

«Два торрента с разными хешами — это точно разные файлы?»

Не обязательно разные файлы, но точно разные раздачи. Один и тот же фильм может быть выложен несколькими релизерами с разным размером части или составом файлов — тогда info-hash будет разным, хотя итоговый видеофайл совпадает байт в байт. Пиры между такими раздачами в классической схеме не объединяются.

«Зачем сверять хеш, если клиент и так всё проверяет?»

Клиент проверяет соответствие данных раздаче, но не даёт вам информации о том, кому вы доверяете эту раздачу. Если источник публикации сомнительный, проверка целостности пройдёт, а проблема останется. Сверка хеша файла с контрольной суммой от первоисточника (сайта разработчика, автора) — отдельный и более значимый рубеж для программ и документов.

Краткая шпаргалка: какой хеш за что отвечает

Хеш	Где находится	Что проверяет	Когда используется
Info-hash (btih)	Магнитная ссылка, торрент-файл, DHT	Идентичность раздачи целиком	Поиск пиров, объединение источников, докачка из другой раздачи
Хеши частей (pieces)	Метаданные раздачи	Целостность каждого блока данных	При получении каждого фрагмента, при повторной проверке
Хеши блоков (v2)	Метаданные раздачи v2	Целостность мелких блоков внутри части	Более точная проверка в протоколе v2
Контрольная сумма файла (например, SHA-256)	Публикуется автором отдельно	Соответствие файла оригиналу автора	Ручная проверка после загрузки программ и архивов

Что делать дальше: практические ориентиры

Главный принцип: хеши в торренте отвечают за «точно те же данные», но не за «безопасные и нужные данные». Отсюда простая последовательность действий при работе с раздачами:

1. Берите магнитные ссылки и торрент-файлы из источников, которым есть основания доверять: именно выбор источника, а не криптография, определяет, что вы скачаете.
2. Перед докачкой сверяйте info-hash, а не название файла — совпадение btih-строки означает ту же раздачу.
3. После сбоя или прерывания загрузки запускайте принудительную проверку локальных данных, а не удаляйте файлы.
4. Для программ и архивов, если автор публикует контрольную сумму, сверяйте её после загрузки независимо от клиента.
5. Не считайте успешную проверку на 100% признаком безопасности содержимого: она подтверждает только целостность.

Если запомнить одно: магнитная ссылка проверяет только «паспорт» раздачи — info-hash, а целостность данных обеспечивают хеши частей, которые клиент получает вместе с метаданными. Всё, что находится за пределами этих двух проверок — источник, безопасность, качество, — оценивается уже вашими собственными критериями выбора, а не математикой хешей.