· Доступность (англ. availability), или distributed copies — количество полных копий файла, доступных клиенту. Каждый сид добавляет 1,0 к этому числу; личеры увеличивают доступность в зависимости от количества скачанного, которого нет у других личеров. К примеру, если на раздаче есть один сид и два личера, скачавшие по 50% файла (скачанные части равны между собой), то доступность равна 1,50.
· Рейтинг (англ. share ratio) — отношение отданного к скачанному.
· Анонс (англ. announce) — обращение клиента к трекеру. При каждом анонсе клиент передаёт на трекер информацию об объёмах им скачанного и отданного, a трекер передаёт клиенту список адресов других клиентов. Обращение клиента к трекеру происходит через определённые интервалы времени, которые определяются настройками клиента и трекера.
· URL анонса (англ. announce URL) — адрес трекера, к которому клиент делает анонс. Во многих клиентах называется «Tracker URL». Может включать «passkey» — уникальный код, назначаемый трекером для аккаунта пользователя, помогающий идентифицировать его на трекере (добавляется к URL анонса в самом *.torrent-файле).
Можно условно выделить четыре основных сегмента функционирования BitTorrent приложений, которые необходимо рассматривать отдельно – это:
· распространение файлов метаданных;
· обмен данными пира с трекером;
· протокол связи между пирами;
· работа сервисных сообщений.
Перед началом скачивания клиент подсоединяется к трекеру, сообщает ему свой адрес и хеш-сумму запрашиваемого файла, на что в ответ клиент получает адреса других клиентов, скачивающих или раздающих этот же файл. Далее клиент периодически информирует трекер о ходе процесса и получает обновлённый список адресов. Клиенты соединяются друг с другом и обмениваются сегментами (блоками) файлов без непосредственного участия трекера, который лишь регулярно обновляет информацию о подключившихся к обмену клиентах и другую статистическую информацию. Для эффективной работы сети BitTorrent необходимо, чтобы как можно больше клиентов были способны принимать входящие соединения. Неправильная настройка NAT или сетевого экрана могут этому помешать. При соединении клиенты сразу обмениваются информацией об имеющихся у них сегментах. Клиент, желающий скачать сегмент, посылает запрос и, если второй клиент готов отдавать, получает этот сегмент. После этого клиент проверяет контрольную сумму сегмента и оповещает всех присоединённых пиров о наличии у него этого сегмента. Каждый клиент имеет возможность временно блокировать отдачу другому клиенту (choke). Это делается для более эффективного использования канала отдачи. Кроме того, при выборе — кого разблокировать, предпочтение отдаётся пирам, которые сами передали этому клиенту много сегментов. Обмен сегментами ведётся по этому принципу симметрично в двух направлениях и в случайном порядке. Клиенты периодически сообщают друг другу об имеющихся у них сегментах. Обмен данными начинается, когда обе стороны в нём заинтересованы, то есть каждая из сторон имеет сегменты, которых нет у другой. Количество переданных сегментов подсчитывается, и если одна из сторон обнаруживает, что передаёт в среднем больше, чем принимает, она блокирует (choke) отдачу. Таким образом, в протокол заложена защита от личеров. При получении полного файла клиент переходит в специальный режим работы, в котором он только отдаёт данные (становится сидом). Клиенты периодически информируют трекер об изменениях в состоянии закачек и обновляют списки IP-адресов.
По умолчанию клиенты соединяются с трекером по протоколу TCP. Входящий порт трекера: 6969. Клиенты соединяются друг с другом, используя протоколы TCP или UDP. Входящие порты клиентов: 6881—6889. Номера портов не фиксированы в спецификации протокола и могут изменяться при необходимости. Более того, большинство трекеров используют обычный для http порт 80, а среди клиентов чаще выбирается случайный входящий порт. В торрент-системе активно используются DHT (Distributed Hash Table — «распределённая хэш-таблица») — это класс децентрализованных распределённых систем, которые обеспечивают поисковый сервис, похожий по принципу работы на таблицу хэшей, и имеют структуру ассоциативного массива: (ключ, значение), хранящиеся в DHT, а каждый участвующий узел может рационально искать значение, ассоциированное с данным именем. Ответственность за поддержку связи между именем и значением распределяется между узлами, таким образом изменение набора участников является причиной минимального количества разрывов. Это позволяет легко масштабировать DHT и постоянно отслеживать добавление/удаление узлов и ошибки в их работе.
DHT-сеть в BitTorrent-клиентах использует протокол UDP. Кроме того, протокол UDP используется UDP-трекерами для соединения клиентов друг с другом через UDP NAT Traversal. Таким образом, простейшие методы блокирования портов здесь совершенно не применимы, и фильтрация, если и может быть осуществлена, то только по конкретным сигнатурам протокола.
Для каждого распространяемого файла создаётся файл метаданных с расширением .torrent, который содержит следующую информацию:
· URL трекера;
· общую информацию о закачиваемом файле (имя, длину и пр.);
· хеш-суммы SHA1 сегментов закачиваемого файла.
Файл метаданных является хэш-таблицей в Bencode формате. Файлы метаданных могут распространяться через любые каналы связи: они (или ссылки на них) могут выкладываться на веб-серверах, размещаться на домашних страницах пользователей сети, рассылаться по электронной почте, публиковаться в блогах или новостных лентах RSS. Получив каким-либо образом файл с метаданными, клиент может начинать скачивание.
Существует огромное количество различных версий клиентов, работающих с BitTorrent, каждая из которых в разной степени отличается друг от друга.
Традиционно BitTorrent, как и большинство P2P-приложений использовало протокол TCP для обмена данными. Однако новые torrent-клиенты, начиная с 2010 года, стали использовать новый протокол uTP, основанный на UDP.
μTP (Micro Transport Protocol) — переимплементация (переопределение) TCP на основе протокола UDP с изменённым контролем за переполнением, который реагирует быстрее, чем соответствующий алгоритм в TCP. Таким образом, при увеличении загрузки канала μTP первым замедляется и отдаёт канал другим приложениям.
Передача файлов в торрент-сетях (а это более 50% мирового трафика) постепенно перешла с протокола TCP на протокол UDP. В версии BitTorrent 2.0 впервые появилась поддержка UDP-трекеров. Для трекера в целом TCP избыточен и требует много лишних ресурсов, поэтому для открытых трекеров переход на UDP обоснован. Например, с начала 2010 года трекер anirena плохо работает по TCP и отвечает далеко не с первого раза, использование DHT запрещёно, а UDP-трекер прекрасно работает. Однако для закрытых трекеров он не подходит, т. к. не позволяет послать passkey, чтобы идентифицировать таким образом качающего. Здесь подразумевается UDP для трекера, а не UDP для обмена данными между пирами (это абсолютно разные вещи, никак друг с другом не связанные). Также в этой версии протокола впервые появился метод обхода некоторых NAT (STUN), что помогло присоединяться большему числу NAT-пользователей.
Основная часть информации в протоколе передаётся в формате Bencode, это способ используется для хранения и передачи данных в сжатом формате. Он поддерживает следующие типы: байтовые строки (byte strings), целые числа (integers), списки (lists) и хэш-таблицы (словари) (dictionaries).
Байтовые строки кодируются следующим образом: <длина строки, кодируемая в десятичной ASCII, в которой есть только символы цифр>:<строковые данные>. Стоит отметить, что здесь не используются фиксированные начальный и конечный разделители.
Целые числа кодируются следующим образом: i<целое число, закодированное в десятичной ASCII>e. Начальный символ i и конечный е - начальный и конечный разделители соответственно. Встречаются закодированные отрицательные числа, такие как i-3e. Целому числу не всегда может предшествовать префикс, состоящий из нулей, как например i04e. Вместе с тем, i0e – это используется в качестве нуля.
Списки кодируются следующим образом: l<bencode-закодированные значения>e. Начальный символ l и конечный е - начальный и конечный разделители соответственно. Списки могут содержать bencode-кодированные значения любых типов, включая целые числа, строки, хэш-таблицы и другие списки.
Хэш-таблицы (словари) кодируются следующим образом: d<bencode-кодированная строка-ключ><bencode-кодированный элемент>e. Начальный символ d и конечный е - начальный и конечный разделители соответственно. Используемые ключи обязательно должны быть bencode-кодированными строками. Значения хэш-таблицы (словаря) могут быть bencode-кодированными значениями любого типа, включая целые числа, строки, списки и другие хэш-таблицы (словари).
Организация гибкой (эффективной) фильтрации BitTorrent подразумевает контроль этой системы по её отдельных элементам, а именно:
· по типу передаваемых файлов данных;
· по версии протокола (это связано с различными ограничениями на работу приложений);
· по наличию/отсутствию отдельных участников раздачи (пиров);
· по указанному и используемому трекеру;
· по хеш-функции файла метаданных (выявить наличие «плохих» хеш-функций для запрета передачи трекеру информации о них);
· по случайно выбираемым протоколом портам;
· по размеру скачанного/отданного трафика;
· по версии используемого клиента.
Результаты исследований выявили три различных направления для реализации подобной фильтрации включающей в себя фильтрацию на основе контроля метаданных, фильтрацию сообщений протоколов работающих с торрент-трекером и фильтрацию собственно BitTorrent протокола, основанную на обмене сообщениями между пирами.
Для фильтрации на основе контроля метаданных существуют простейшие разработки, сформулированы основные критерии и предпосылки. Важнейшим преимуществом такого подхода стало большое число контролируемых функций и режимов работы BitTorrent. Однако данная система на данный момент требует более детальной проверки и тщательного анализа результатов, так как работает до момента получения метаданных и совершенно неэффективна для уже работающей bittorrent-сети.
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
