Распределённая хеш-таблица

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

DHT (англ. Distributed Hash Table — «распределённая хеш-таблица») — это класс децентрализованных распределённых систем, которые обеспечивают поисковый сервис, похожий по принципу работы на таблицу хешей, и имеют структуру ассоциативного массива: (ключ, значение), хранящиеся в DHT, а каждый участвующий узел может рационально искать значение, ассоциированное с данным именем. Ответственность за поддержку связи между именем и значением распределяется между узлами, таким образом изменение набора участников является причиной минимального количества разрывов. Это позволяет легко масштабировать DHT и постоянно отслеживать добавление/удаление узлов и ошибки в их работе.

DHT — это инфраструктура, которая может быть использована для построения многих комплексных сервисов, таких как распределенные файловые системы, пиринговое распространение файлов и системы распространения контента, кооперативный web-кэш, многоадресная доставка (multicast), anycast, сервис доменных имен и система мгновенных сообщений. Основные распределенные сети, которые используют DHT, включают в себя сеть I2P, BitTorrent, eDonkey network, YaCy, Tox и Coral Content Distribution Network. Существует возможность создания поисковых машин по сети DHT.

История[править | править исходный текст]

Изыскания в области DHT изначально были мотивированы в частности пиринговыми системами, такими, как I2P, Napster, Gnutella, Freenet, которые использовали распределенные в интернете ресурсы для создания одного единственного приложения. В частности они использовали широкополосный интернет и пространство на жестких дисках для предоставления сервиса распространения файлов. Эти системы различаются тем, как они находили данные пиров:

  • Napster имел центральный индексный сервер: каждый узел, после присоединения, должен отправить список локально хранящихся файлов на сервер, который должен произвести поиск и направить запрос к узлам, содержащим результаты. Этот центральный компонент делал систему уязвимой для атак и рисков.
  • Gnutella и похожие сети двинулись к модели лавинных запросов — в основном, каждый поиск привел бы к сообщению, передаваемому на любую машину в сети. Избегая централизованного отказа, этот метод был значительно менее эффективным, чем Napster.
  • Наконец, Freenet был также полностью распределенным, но маршрутизация работает на базе эвристического ключа, в котором каждый файл имеет ассоциированный с ним ключ, а файлы с похожими ключами имели тенденцию к объединению в кластеры на похожем наборе узлов. Запрос, скорее всего, направлялся таким кластерам без надобности опрашивать всех пиров. Однако Freenet не мог гарантировать, что данные будут найдены.

DHT используют маршрутизацию на базе более структурированного ключа, чтобы достигнуть децентрализации I2P, Gnutella и Freenet, а также эффективности и гарантируемых результатов Napster. Один из недочетов в том, что, как Freenet, DHT поддерживает только поиск по точному совпадению, а не по ключевым словам, хотя эти возможности могут наслаиваться поверх DHT.

Первые четыре DHT — CAN, Chord, Pastry и Tapestry — были введены приблизительно в 2001 году. С тех пор эта область изысканий была достаточно активна. Вне научных кругов DHT-технологию приняли как компонент BitTorrent и Coral Content Distribution Network

Свойства[править | править исходный текст]

DHT характеризуется следующими свойствами:

  • Децентрализация: форма системы коллективных узлов без координации;
  • Масштабируемость: система будет одинаково эффективно функционировать при тысячах или миллионах узлов;
  • Отказоустойчивость: система будет одинаково надежна (в некотором смысле) с узлами постоянно подключающимися, отключающимися и выдающими ошибки.

Ключевая методика достижения цели заключается в том, что любой узел должен скоординироваться только с несколькими узлами в системе — как правило, О (logn), где n — количество участников (смотри ниже) — так, чтобы только ограниченный объем работы был сделан для каждого изменения количества участников.

Некоторые DHT-проекты стремятся обеспечить защиту от вредоносных пользователей и позволять участникам оставаться анонимными, хотя это меньше распространено, чем во многих других P2P-системах (особенно при распространении файлов); см. Анонимные сети.

Наконец, DHT приходится иметь дело с более традиционными распределенными системами, такими как распределение нагрузки, целостность данных и производительность (в частности, гарантируя, что операции, такие как маршрутизация и хранение данных или поиск, завершаются быстро).

Структура[править | править исходный текст]

Структура DHT может быть разбита на несколько основных компонентов. Она основывается на абстрактном пространстве ключей (keyspace), таком как набор 160-битных строк (количество бит может варьироваться). Схема разбиения пространства ключей распределяет принадлежность ключей среди участвующих узлов. Затем оверлейная сеть соединяет узлы помогая найти владельца любого ключа в пространстве ключей.

Когда все компоненты на месте, типичное использование DHT для хранения и выдачи информации происходит следующим образом: Предположим, keyspace составляет 160-битные строки. Чтобы сохранить файл с данным именем и информацией в DHT, находится SHA1 хеш от имени файла, из которого формируется 160-битный ключ k, после чего формируется сообщение put(k, data) и посылается любому участвующему узлу в DHT. Послание идёт от одного узла к другому через оверлейную сеть до тех пор, пока оно не достигнет единственного узла, ответственного за ключ k, в соответствии со схемой разбиения keyspace, где и будет храниться пара (k, data). Любой другой клиент может получить содержание файла сделав ключ (k), т.е. получив хеш имени файла, для того, чтобы найти данные, связанные с ключом, послав сообщение get(k). Сообщение снова пройдёт через оверлей к узлу, ответственному за ключ, который ответит, что нужные данные есть в наличии.

Компоненты разбиения пространства ключей и оверлейной сети описаны ниже с целью представления основных идей обычных для большинства DHT систем. Многие разработки отличаются в деталях.

Разбиение пространства ключей[править | править исходный текст]

Большинство DHT используют различные варианты консистентного хеширования для отображения ключей в узлы. В основе этого способа разбиения лежит функция \delta(k_1, k_2), определяющая абстрактное понятие расстояния между ключами k_1 и k_2, которое не имеет никакого отношения к географическому расстоянию или к сетевой задержке. Каждому узлу присваивается единичный ключ, называемый его идентификатором (ID). Узел с ID i_n владеет всеми ключами k_m, для которых i_n — самый ближайший ID, вычисленный с помощью \delta(k_m, i_n).

Пример. Chord DHT рассматривает ключи как точки на окружности, а \delta(k_1, k_2) — это расстояние, пройденное по часовой стрелке по окружности от ключа k_1 к k_2. Таким образом круг пространства ключей разделён на смежные сегменты, чьи концы являются идентификаторами узлов. Если i_1 и i_2 смежные ID, то узел с ID i_2 содержит все ключи, которые находятся между i_1 и i_2.

Консистентное хеширование имеет основное свойство: удаление или прибавление только одного набора ключей, принадлежащих узлам смежных ID, не влияет на другие узлы.

DHT и BitTorrent[править | править исходный текст]

Карта сети BitTorrent DHT

И DHT, и PEX фактически выполняют основную функцию BitTorrent-трекера — помогают участникам файлообмена узнать друг о друге. Они могут:

  • Помочь участникам быстрее найти друг друга
    Например, на раздаче есть пир X с недоступным портом. К раздаче подключается пир Z, который не может сам начать соединение с X и вынужден ждать, пока Х о нём узнает. Х только что обращался к трекеру и в следующий раз собирается это сделать через час.
    Но вот пир Y в очередной раз обращается к трекеру и узнаёт про нового пира Z. При этом Y сам давно уже соединён и занимается файлообменом с X, поэтому он через PEX сообщает X адрес этого нового пира. Теперь X может начать соединение с Z.
  • Снизить нагрузку на трекер
    Получая адреса пиров через DHT или PEX, клиенты реже обращаются к трекеру, тем самым снижая нагрузку.
  • Поддержать раздачу в периоды недоступности трекера
    Если трекер является единственным источником информации о пирах, то при его неработоспособности раздача постепенно остановится. Используя PEX, клиенты могут обмениваться друг с другом информацией о пирах, с которыми у них были сеансы связи, тем самым замедляя процесс остановки раздачи. DHT же позволяет полностью заменить трекер.
  • DHT позволяет раздавать без трекера
    Такая раздача называется trackerless. Торрент для неё создаётся без адреса трекера и клиенты находят друг друга через DHT. Правда при этом, начавший раздачу должен иметь реальный ip-адрес, доступный извне. При участии в trackerless-раздачах BitTorrent-клиенты приобретают определённое сходство с eMule, использующим сеть Kad.

Private key[править | править исходный текст]

В публичных (открытых) трекерах, где каждый желающий может скачать торрент и участвовать в раздаче, DHT и PEX служат на благо всех участников.

Частным (закрытым) трекерам в первую очередь важно, чтобы в раздачах могли участвовать только зарегистрированные пользователи и чтобы они соблюдали определённые правила. При первом обращении клиента частный трекер имеет возможность не допустить его к раздаче, просто не сообщая ему адреса других клиентов-участников. Поэтому для закрытого трекера важно, чтобы клиенты не получали эти адреса через DHT/PEX.

DHT и PEX появились в клиентах Azureus и BitComet примерно летом 2005 года. Администраторы многих частных трекеров были недовольны такой новой функциональностью и поэтому стали запрещать на трекере эти новые версии клиентов.

Тогда разработчики клиентов предложили новый ключ внутри торрент-файла: private. Если он равен 1, то клиент обязан для этого торрента автоматически отключать DHT/PEX независимо от желания пользователя. Такой торрент называют Secure Torrent.

Практически все современные частные трекеры сами принудительно вставляют private:1 во все торренты, выкладываемые на трекере, а также запрещают несколько устаревших версий клиентов, поддерживающих DHT или PEX, но ещё не знающих про private key. Считается, что пользователи трекера просто не могут на раздачах использовать DHT/PEX, и проблемы нет. На самом же деле для того, чтобы не учитывался рейтинг, достаточно заменить свой passkey на любой другой. И даже не надо его воровать. Достаточно зарегистрировать ещё одну учётную запись, чтобы взять из неё passkey.

DHT и статистика[править | править исходный текст]

Этот раздел касается только закрытых трекеров, на которых private key в торренты принудительно не вставляется, и на некоторых раздачах (в зависимости от того, вставил ли раздающий сам в торрент private key) можно использовать DHT и PEX.

Часто встречается мнение, что включённый в клиенте DHT влияет на учёт статистики клиента трекером, например «раздавал через DHT, значит статистика шла мимо трекера». Это неверно.

Во-первых, DHT/PEX используется только для получения адресов пиров. Ни файлообмена, ни какого-либо учёта статистики по ним не ведётся. Клиент рапортует статистику скачанного и отданного только на трекер.

То есть «раздавал через DHT» фактически означает «о некоторых (или о всех) пирах получил информацию по DHT, и вероятно некоторые пиры тоже нашли меня через DHT»

Во-вторых, хотя клиенты обычно и знают, откуда ими получены адреса пиров, ни один клиент не разделяет трафик на «полученный/отданный DHT пирам» и «полученный/отданный пирам, полученным от трекера». Даже при желании это было бы клиенту сделать затруднительно — некоторые пиры могут быть получены и от трекера и через DHT или PEX, и часто клиент не знает, как его адрес получил пир, сам начинающий к нему соединение.

Клиент рапортует трекеру суммарные данные об объёмах им скачанного и отданного всем пирам, с которыми он общался, независимо от того, узнал клиент об отдельных пирах через трекер, DHT или PEX, или тот пир вообще начал соединение сам. То есть даже если из-за DHT/PEX на раздаче появятся «левые» пользователи (не обращающиеся к трекеру), клиент всё равно сообщит на трекер всё, что у них скачал и отдал.

Правильный учёт статистики зависит только от состояния трекера: работает трекер — статистика учитывается, не работает — не учитывается. Только в случае длительно неработающего трекера DHT/PEX может играть косвенную роль, не давая постепенно затухнуть файлообмену на такой «раздаче без учёта статистики».

Механизм работы DHT[править | править исходный текст]

Реализация распределенной сети в BitTorrent-клиентах основана на варианте DHT, называемом Kademlia. А вообще говоря, DHT (Distributed hash table) означает децентрализованную распределенную систему для объединения большого количества постоянно исчезающих и появляющихся узлов и эффективной передачи сообщений между ними. На основе структур DHT строят разные более сложные системы, такие как файлообмен P2P, кооперативное веб-кеширование, службы DNS и т. п.

DHT использует протокол UDP. Клиенты BitTorrent «слушают» тот же номер порта UDP, который они используют для входящих TCP-соединений. Если вы активно используете DHT, то открытие этого UDP-порта для доступа снаружи желательнo, но не обязательно — DHT будет работать и так.

Каждый подключённый клиент является в сети DHT отдельным узлом. У него есть свой уникальный ID (идентификатор), случайно выбираемый из того же 160-битного пространства, что и infohash’и торрентов.

Каждый узел хранит таблицу маршрутизации, содержащую контактную информацию о многих «ближайших» к нему узлах, и о нескольких более далёких. «Близость» двух узлов вычисляется из «сходства» их ID, и не имеет никакого отношения к их географической близости.

Когда узел хочет найти пиров для раздачи, он сравнивает infohash этой раздачи с ID известных ему узлов, и затем посылает запрос тому узлу, чей ID наиболее похож на этот infohash. Тот узел возвращает ему адрес узла, чей ID ещё ближе к infohash торрента.

Тогда наш узел посылает запрос тому новому узлу, и получает от него адрес следующего узла, чей ID ещё более похож на infohash торрента.

Таким образом, запросы от клиентов, участвующих в раздаче торрента с определённым infohash, постепенно стекаются к узлам, чьи ID наиболее похожи на этот infohash. Эти узлы помнят предыдущие запросы, и всем следующим запрашивающим узлам вернут адреса предыдущих пиров с той же раздачи.

Недостатки[править | править исходный текст]

  1. Существует несколько несовместимых между собой протоколов, которые обслуживают различные сети.
  2. Работа клиента, как DHT-узла, создает большую нагрузку на маршрутизатор (роутер).
  3. Хеши публикуются открыто, что позволяет интерактивно отслеживать раздачи (чем и пользуются правообладатели).[1][2][3]
  4. В имеющейся реализации DHT создает сильный паразитный трафик на компьютер клиента, поскольку сообщения DHT продолжают присылаться клиенту даже в том случае, если компьютер клиента больше не принимает такой трафик (когда программа выключена).

Связанные статьи[править | править исходный текст]

Примечания[править | править исходный текст]

Внешние ссылки[править | править исходный текст]