Пользователь
0,0
рейтинг
26 января 2011 в 16:15

Разработка → Тёмная материя интернета

Иногда я открываю окно торрент-клиента и просто смотрю, как он раздает файлы… Это завораживает даже больше, чем дефрагментация или гейзеры и вулканы в трехлитровой банке с домашним квасом. Ведь я помогаю множеству незнакомых мне людей качать нужные им файлы. Мой домашний компьютер — маленький сервер, ресурсами которого я делюсь со всем интернетом. Наверное, похожие чувства побуждают тысячи добровольцев по всему миру участвовать в проектах вроде folding@home.

Ни один файловый сервер не справился бы с тем объемом раздачи, который обеспечивают миллионы маленьких компьютеров по всему миру, используя лишь небольшую часть своих ресурсов. Вот если бы я мог так же легко поделиться ресурсами с любым понравившимся мне сайтом! Если бы затраты на хостинг при росте аудитории росли не линейно, а логарифмически, за счет «добровольного ботнета» из компьютеров посетителей. Насколько меньше рекламы я бы увидел? Сколько интересных стартапов избавились бы от головной боли по поводу масштабирования? Сколько некоммерческих проектов могли бы перестать зависеть от благосклонности меценатов? И насколько труднее было бы кибергопникам или спецслужбам DDoS-ить такой сайт!

Цена вопроса


Сейчас в мире больше полутора миллиардов компьютеров, подключенных к интернет. Из них около 500 миллионов имеют широкополосное подключение. Если предположить, что средний возраст домашнего компьютера — около двух лет, то можно считать, что у него простенький двухъядерный процессор, 1 -2 гигабайта памяти и винт на 500 гигабайт. Для определенности предположим также, что средняя скорость широкополосного соединения — 10 мегабит/сек.

Много это или мало? Что будет, если нам удастся добраться до этой скрытой массы ресурсов? Прикинем на глазок. Допустим, что если оставлять эти компьютеры включенными круглосуточно, то не меньше трех четвертей их ресурсов будут простаивать (это более, чем осторожная оценка, в Википедии фигурирует средняя нагрузка на сервер в 18%!). Если же загрузить компьютер как следует, то вырастет энергопотребление, скажем на 70 ватт на один компьютер, или на 50 киловатт-часов в месяц. При средней цене электричества в мире около 10 центов за киловатт-час — это $5 в месяц. Плюс возникает вопрос повышенного износа. Вопрос довольно спорный, большинство комплектующих серьезных производителей безнадежно устаревают морально гораздо раньше, чем ломаются, кроме того, есть мнение, что постоянные включения-выключения и связанные с ними нагрев-остывание и другие переходные процессы приводят к выработке ресурса быстрее, чем круглосуточная работа. Тем не менее, включим в расчет лишние 150 долларов на ремонт, размазанные, скажем, на 4 года эксплуатации. Это еще чуть больше 3 долларов в месяц. Итого — 8 долларов в месяц или 100 долларов в год дополнительных расходов. С другой стороны, если три четверти ресурсов, за которые мы уже заплатили в момент покупки компьютера, сейчас простаивает, то при средней цене системника в 500 долларов — 375 мы выбрасываем на свалку. Если учесть, что эти 375 мы потратили сразу, то при распределении этой суммы на 4 года эксплуатации, получаем как раз те же 100 долларов в год. Еще, пожалуй, стоит упомянуть, что компьютер, даже когда использует 10% своей мощности, потребляет электричества вовсе не в 10 раз меньше, а всего раза в два. Но не будем крохоборствовать. Ведь 99% людей, у которых есть дома компьютер и высокоскоростной интернет, принадлежат к «золотому миллиарду», так что плюс-минус несколько долларов в месяц большой роли не играют.

Итак, соберем все вместе. 1 гигабайт памяти, полтора ядра на частоте 1.5 — 2 гигагерца, 350 гигов на винте, канал 7 мегабит/сек умножим на пол-миллиарда:
  • + 500 петабайт оперативки
  • + 750 миллионов ядер
  • + 175 000 петабайт дискового пространства
  • + 3.5 петабит/сек полосы пропускания
  • — 300 Тераватт-часов электричества (около 0,3% мирового потребления электричества)
  • — 100 миллиардов долларов в год, из которых 50 мы уже заплатили в момент покупки компьютера

Критически настроенный читатель (а я надеюсь, таких здесь большинство) может потребовать пруфлинки ко всем цифрам в предыдущем абзаце. Я рискнул их не приводить, так как это были бы несколько десятков ссылок на разрозненные куски статистики разной степени достоверности за последние несколько лет, которые сильно засорили бы текст. Для раскрытия темы статьи важен порядок величин, так что особая точность не нужна. Тем не менее, если у кого-то есть готовая достоверная статистика из той же оперы, и она сильно отличается от моих цифр, буду рад её увидеть.

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

Фрагменты мозаики


Самая большая проблема, с которой приходится иметь дело при «размазывании» сайта по неопределенному множеству клиентских компьютеров — динамический контент. Распределенное хранение и раздача статических страниц мало чем отличается от раздачи любых других файлов. Вопрос целостности и подлинности страниц решается с помощью хэшей и цифровых подписей. К сожалению, эпоха статических сайтов на чистом HTML закончилась раньше, чем распределенные сети и протоколы созрели и широко распространились. Единственная ниша, где просто нет других альтернатив — анонимные зашифрованные сети сети вроде FreeNet или GNUnet. В них создать нормальный веб-сервер с постоянным адресом невозможно по определению. «Сайты» в этих сетях как раз состоят из наборов статических страниц или сообщений, объединенных в форумы. Кроме того, чем больше трафик шифруется и анонимизируется, тем быстрее полоса пропускания таких сетей стремится к нулю, а время отклика — к бесконечности. Большинство людей не готово терпеть такие неудобства ради анонимности и приватности. Подобные сети остаются уделом гиков, политических диссидентов и всякой нечисти вроде педофилов. Когда я стал писать о приватности, абзац настолько разросся и так сильно выпирал из окружающего текста, что я оформил его отдельным топиком. Так что вот вам лирическое отступление.

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

Гораздо интереснее системы распределенного кэширования и CDN. О Coral CDN слышали многие. Хотя распределенная сеть Coral базируется на серверах PlanetLab, а не на пользовательских компьютерах, её архитектура представляет большой интерес. Одна из главных фишек сети — помощь маленьким сайтам в моменты пиковой нагрузки под слэшдот- или хабраэффектом. Достаточно дописать справа от URL ресурса «волшебные слова» .nyud.net, и весь трафик пойдет через Coral. При обращении по ссылке сеть ищет нужный ресурс по хэшу запроса, используя модифицированный вариант DHT — sloppy DHT. Слово «sloppy» означает, что информация о пирах «размывается» по нескольким узлам с близким значением хэша, снижая нагрузку на самый близкий к хэшу ресурса узел (если вы ничего не поняли в последнем предложении, то вот здесь понятным языком изложены основы архитектуры Distributed Hash Table). Кроме того, Coral разбивает таблицу хэшей на кластеры, в зависимости от пинга между узлами, чтобы уменьшить время отклика — ведь если при скачивании фильма можно и подождать минутку, пока DHT найдет достаточно пиров, то при загрузке страницы лишние несколько секунд сильно раздражают. Вот более подробное описание.



Еще два маленьких шажка в сторону распределенных веб-сайтов — BitTorrent DNA и FireCoral. DNA работает на основе BitTorrent, и предназначен для раздачи тяжелого контента. Он требует установки на клиентскую машину загрузчика, который собственно качает файлы или видео. Принцип действия загрузчика мало чем отличается от обычной торрентокачалки, за исключением того, что потоковое видео всегда грузится последовательно, чтобы можно было начинать смотреть, не дожидаясь полной загрузки. Загруженные файлы хранятся в кэше и раздаются другим клиентам. Мне уже пару раз попадались DNA-загрузчики, когда я качал какие-то драйвера. Работает это все пока только под Windows.

FireCoral — это младший родственник Coral CDN, дополнение для FireFox, которое должно работать на базе клиентских компьютеров, а не серверов PlanetLab. Толком погонять его мне не удалось, так как на момент написания статьи скачали это дополнение всего 1404 человека. А использовал его аж 1 человек за последние сутки.
Вот подробное описание архитектуры FireCoral. В двух словах: FireCoral перехватывает HTTP-запросы, и, если в кэше браузера нет ничего подходящего, обращается к трекеру (1). Трекер либо сообщает(2) клиенту адреса пиров, у которых в кэше есть нужный файл (3), либо отправляет его на сервер-источник, если запрос еще никто не кэшировал, или версия в кэше просрочена (4). Подлинность всего, что FireCoral скачал с пиров, удостоверяется цифровой подписью, которую предоставляет доверенный сервер подписей (5). Завершив обработку запроса, FireCoral сообщает трекеру, что теперь у него тоже есть копия (6).



Недостатки существующих систем распределенного кэширования очевидны и довольно существенны. Кэширование происходит без участия (более того, без ведома!) сервера. Это затрудняет сбор статистики посещений, контроль над распространением контента и создает потенциальные угрозы безопасности как для сервера, так и для клиента. С точки зрения сайта, подобная P2P-сеть очень похожа на открытый прокси-сервер. Справиться с этими трудностями возможно, только если сайт знает о существовании распределенного кэша и контролирует его. В терминах архитектуры FireCoral это значит, что сервер-источник одновременно служит и трекером и доверенным сервером подписей. Если сейчас веб-сервер самостоятельно делает всю работу по обслуживанию клиентов, то в такой архитектуре ему остается только роль «надсмотрщика», который управляет пирами, делающими всю черную работу.

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

С хранением проще всего. Криптография позволяет хранить любые данные в облаке или на сервере, не доверяя ему. Так работает, например, Wuala — один из конкурентов Dropbox. Wuala позволяет увеличивать доступное место для хранения своих файлов не только за счет своих датацентров, но и за счет дискового пространства пользователя. То есть программа-клиент использует мой компьютер, как часть облачного хранилища. Я расплачиваюсь за хранение своих файлов в облаке не деньгами, а ресурсами своего диска и интернет-соединения. Все файлы шифруются, так что я не знаю, кто и что хранит на моем винте, более того, файлы хранятся не целиком, а по частям, это фактически распределенная файловая система. То есть шансы, что кто-то соберет по кусочкам и расшифрует мои файлы исчезающе малы.

К сожалению, Wuala не особо продвигает эту фишку, но их можно понять. Громко и внятно предлагать пользователям увеличивать доступное место бесплатно — значит пилить сук, на котором сидишь. Чтобы продвигать сервис синхронизации и хранения в P2P-облаке, нужна другая бизнес-модель. Например, биржа ресурсов — столько-то терабайт спроса на еще сколько-то предложения. Нужно включить в это уравнение деньги, например, у меня есть 100 гигабайт свободного места, а для того чтобы компенсировать файлы, которые я храню в облаке, нужно 150. Вместо недостающих 50 гигабайт я расплачиваюсь деньгами. Сервис берет маленькую комиссию. А если наберется достаточно много пользователей, и баланс спроса и предложения позволит, то можно будет продавать ресурсы на сторону.

Возвращаясь к распределенным веб-серверам, можно представить систему вроде Flattr, но вместо денег в ней будут распределяться гигабайты и мегабиты, а оцениваться будут не конкретные куски контента, а сайты целиком.

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

Вопрос доверия невозможно решить «в лоб» на клиентском компьютере. Обфускация кода клиента, всяческие античит-мониторы — это громоздкий неудобный костыль. Создатели всяких MMORPG воюют с этим постоянно. Рано или поздно все можно пропатчить. Вернее, почти все. Есть такая штука — trusted computing. Добро пожаловать в прекрасный новый мир! Кошмар Ричарда Столлмана, мечта Большого Брата — в каждом компьютере стоит чип, который следит за тем, чтобы мы делали только то, что нам положено, когда положено и как положено. Такой вариант решения гораздо хуже самой проблемы.

Реально работает другой метод. Он давно и успешно используется матушкой-природой. Это иммунитет. Любой организм весьма эффективно обнаруживает враждебные или неправильно работающие клетки и уничтожает их. Подобные системы придуманы и для P2P-сетей.

Например, платформа для распределенных вычислений BOINC, на которой базируются проекты «что-нибудь@home». В ней используется метод консенсуса. Один и тот же фрагмент данных отдается на вычисление нескольким участникам, а результат заносится в базу только если все вернули одинаковые данные. Если нет, значит кто-то ошибся или сжульничал. Исправить ошибку можно двумя основными способами — если есть доверенный сервер, вычисление спорной порции данных поручается ему, и все, кто дал другой ответ, идут лесом. Если сеть полностью распределенная и одноранговая, то правильным считается ответ, который дало большинство участников, этот способ известен под названием «quorum consensus». Кроме того, возможен промежуточный вариант — для каждого узла по результатом предыдущей работы вычисляется репутация. Ответ узлов с большей репутацией имеет больший вес при разрешении конфликта.

Как это все применимо к распределенным веб-сайтам? Любые данные, которые отдает веб-сервер можно разделить на четыре группы:
  1. Данные, раскрытие и несанкционированное изменение которых абсолютно недопустимо — пароли, номера кредитных карт, личные сообщения и файлы. Их можно хранить и передавать только в зашифрованном виде.
  2. Данные, которые могут видеть все, но их произвольное изменение недопустимо. Например, JavaScript на странице. Такие данные должны быть в обязательном порядке проверены и подписаны доверенным источником.
  3. Данные, несанкционированный просмотр которых нежелателен, но не является катастрофой. Например, содержимое закрытых блогов здесь, на Хабре.
  4. Данные, несанкционированное изменение которых может быть легко исправлено впоследствии. Например, статья в Википедии, которую починить гораздо легче, чем испортить. Ради большей децентрализации можно допустить проверку и публикацию таких данных без участия доверенного сервера, методом quorum consensus.

Итак, сегодня уже существует принципиальная возможность дотянуться до «темной материи» ресурсов глобальной сети. Однако действительно массовым пока стал только файлообмен. Наверное, дело в том, что полноценная и безопасная работа P2P-сайта требует серьезного пересмотра основ сайтостроения — очень сильно меняется архитектура, подход к контролю доступа, возникают новые риски. Ну и конечно, вечная проблема курицы и яйца. Распределенных сайтов нет, потому что нет инфраструктуры, инфраструктуры нет, потому что нет распределенных сайтов.

Сейчас самая перспективная, на мой взгляд, попытка разорвать этот порочный круг со стороны рспределенных сайтов, а не инфраструктуры— проект Diaspora. Хотя пока что разработка в стадии альфа-версии, им удалось привлечь к себе внимание широкой публики и собрать кучу денег на kickstarter.com Даже Марк Цукерберг внес свою лепту в финансирование проекта. Создатели Диаспоры не замахиваются на решение проблемы распределенного хостинга в общем виде, а делают социальную сеть, которая по своей природе хорошо ложится в архитектуру P2P. Главный «пряник», которым они привлекают людей — полный контроль над своими данными. Диаспора — не единственный проект такого рода, есть еще GNUsocial, Appleseed, Crabgrass, но никому из них не удалось стать настолько популярным.

Диаспора — это веб-приложение на Ruby on Rails. Чтобы поднять свой сервер Диаспоры, нужен Linux или MacOS X, поверх них thin и nginx (тут возможны варианты). До Windows пока руки авторов не дошли. Создание простого установщика для не-гиков — в планах на будущее. В архитектуре Диаспоры используется ботаническая терминология: сервер — это «стручок» (pod), аккаунт пользователя — «зерно» (seed). Каждый стручок может содержать одно или несколько зерен. Пост — фотография, сообщение и т. д. — может принадлежать одному или нескольким «аспектам». Аспект — группа пользователей, например «родственники», «работа», «друзья». Диаспора использует криптографический контроль доступа. Что это такое?

Привычные модели контроля доступа, такие, как ACL или RBAC, целиком и полностью полагаются на доверенный сервер, который решает, кого пускать, а кого нет. Как сторожевая собака. Если наши данные хранятся где попало, мы уже не можем рассчитывать, что на каждом сервере есть достаточно злая собака, которая добросовестно охраняет секреты. Её там может вообще не быть, или собака может путать своих и чужих. В таких условиях нам придется запирать каждый кусочек информации на замок, чтобы только тот, у кого есть ключ, мог получить доступ. Это и есть криптографический контроль. Мы управляем доступом к любой информации, шифруя её, и раздавая ключи тем, кому считаем нужным.

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

То что мы не можем сделать однажды опубликованную информацию недоступной на 100%, не означает, что не стоит даже пытаться. 99% — это тоже неплохо. Однако, перешифрование и раздача новых ключей — весьма ресурсоемкий и медленный процесс. Если число членов группы, из которой мы хотим исключить кого-то, не очень велико, и нас устраивает 99% гарантия успешного «отлучения», то мы таки перешифруем все и раздадим новые ключи. Если же группа очень велика, и информации много — то овчинка не стоит выделки, и можно ограничиться только заменой ключей, так что исключенный пользователь сохранит доступ к старой информации, но не к новой.

Как конкретно выглядит процесс криптографического управления доступом? Пусть нам надо дать доступ группе из N пользователей. Информация шифруется случайным ключом симметричным алгоритмом. Этот ключ, в свою очередь, шифруется открытыми ключами каждого из N. Зашифрованная информация + N по-разному зашифрованных экземпляров случайного ключа упаковываются, подписываются и раздаются членам группы. Чтобы исключить кого-то из группы, надо повторить весь процесс с N-1 ключами, и пометить старый экземпляр зашифрованного файла для удаления на всех пирах. Или, если мы можем смириться, с тем, что старая информация останется доступной, достаточно просто в дальнейшем шифровать случайный ключ к новой информации N-1 ключами пользователей. Если же мы наоборот, хотим дать доступ новому члену группы, нам достаточно прислать ему ключи от всех старых файлов.

Это самый прямолинейный способ реализации криптографического контроля. Чтобы уменьшить количество распространяемых ключей, можно использовать разнообразные иерархические системы производных групповых ключей. Вместо N можно обойтись O(logN) ключами, но это сильно усложняет схему. В пределе, когда N — очень большое число, а возможность замены ключей отсутствует в принципе, получается такой монстр, как AACS — основа DRM. Оставляя за скобками юридические, социальные и этические аспекты DRM, устройство AACS — штука невероятно увлекательная. Subset difference tree system чем-то похожа на квантовую механику — если вы думаете, что понимаете её, значит вы её не понимаете. По крайней мере я прошёл сквозь три или четыре уровня ложного понимания, пока разбирался с её работой (может их и больше, но к сожалению, у меня не настолько много свободного времени, чтобы продолжать копать глубже). Подробнее о криптографическом контроле доступа можно почитать вот здесь, см. главу 2.3 в документе по ссылке, только осторожно, там толстый PDF!.

Фантазии и домыслы


Что нужно, чтобы распределенные веб-сайты стали обычным делом?

Во-превых, инфраструктура. Программа-клиент, вроде uTorrent, или плагин к браузеру, вроде FireCoral, или поддержка функций веб-сервера браузером, вроде Opera Unite. Какие функции должна обеспечивать эта инфраструктура?
  1. Неявное автоматическое распределенное кэширование сайтов, которые я посещаю. (Примеры — FireCoral, BitTorrent DNA)
  2. Явное предоставление ресурсов моего компьютера тем сайтам, которые я хочу поддержать. (Примеров пока нет. Единственное, что приходит в голову — недавние события вокруг Wikileaks, когда сочувствующие вручную создали сотни зеркал сайта)
  3. Публикация или хранение в P2P-облаке моих собственных ресурсов. (Примеры — Diaspora, Opera Unite, Wuala)

Во-вторых, архитектура веб-приложения.
  1. Веб-сервер должен стать трекером собственной P2P-сети и центром сертификации.
  2. Реляционные БД подходят плохо. В распределенной среде слишком накладно собирать веб-страницу из маленьких кусочков данных, разбросанных по разным таблицам. Нужны более крупные денормализованные фрагменты, чтобы можно было обойтись всего несколькими простыми запросами. Документ-ориентированные БД и хранилища key-value соответствуют задаче гораздо лучше. Именно документы таких БД, а не целые страницы, лучше всего хранить в распределенном кэше.
  3. Криптографический контроль доступа, и вообще повсеместное обязательное использование криптографии.
  4. Широкое использование модели распространения данных Push on change вместо Pull on demand.

Представим, как мог бы работать, например, Хабрахабр, будь он распределенным. Допустим, что вся инфраструктура уже существует и работает. Заходя на главную, я получаю от сервера только актуальный список пиров, с которых могу скачать собственно страницу, и её хэш. Сама страница тоже не совсем обычна. Если кэшировать её целиком, то из-за часто меняющихся фрагментов, таких, как «Прямой эфир», или числа комментариев под каждым топиком, она будет устаревать практически мгновенно. Поэтому первым делом качается статический каркас страницы — шапка, подвал, стили и JavaScript, который после загрузки подтянет динамические куски ещё несколькими запросами. Причем сами эти куски тоже сильно отличаются по скорости обновления. Если «Прямой эфир» может обновляться несколько раз в минуту, то «Лучшее за 24 часа» меняется довольно редко.

Собственно, именно так сейчас выглядит правильно организованное кэширование на стороне сервера. Почти любая динамическая страница на 99% состоит из таких вот более-менее статических кусков. Разница в том, что готовая страница будет собираться из этих кусков на стороне клиента, а сами куски будут находится в P2P-сети.

Как будут распространяться обновления данных? Допустим, кто-то написал комментарий к этому топику. При каждом запросе, будь то создание комментария, оценка или просто обновление страницы, клиент обновляет список пиров у себя и у того узла, к которому он обратился. Чем активнее я участвую в обсуждении, тем актуальнее мой список пиров, и тем быстрее я получаю свежую информацию. То есть все обновления распространяются прежде всего локально, в том «рое», который сейчас жужжит вокруг топика. Обновления подписываются хабраюзером, так что подделать или испортить что-либо достаточно трудно. В крайнем случае, если, например, несколько узлов сговорятся и начнут намеренно искажать информацию, безобразие будет длиться недолго — центральный сервер «заглядывает к нам на огонек» каждые несколько минут, сохраняет свежие комментарии и оценки и проверяет их подлинность и валидность. В эту схему отлично выписывается технология pubsubhubbub (смешнее всего это слово произносят японцы).

В принципе, сайт может временно или постоянно работать вообще без центрального сервера. Он необходим только на этапе первоначального роста сети и формирования ядра аудитории. В дальнейшем сервер просто ускоряет и упрощает работу, и позволяет хозяевам сайта управлять развитием проекта. Если использовать систему учета репутации, то несколько десятков самых авторитетных узлов могут играть роль трекеров и центров сертификации, поддерживая стабильность сообщества и целостность распределенной БД. Чтобы уничтожить или взять под контроль такую сеть, надо одновременно захватить большинство авторитетных узлов, что гораздо труднее, чем отключить центральный сервер.

Чтобы сделать такой сайт вообще неубиваемым, остается придумать децентрализованный аналог DNS. Или можно заменить DNS децентрализованной поисковой системой. Например, когда у Wikileaks один за другим отбирали домены, сайт продолжал висеть первым в выдаче Google, причем вместо доменного имени некоторое время красовался голый IP-адрес. Да и чайники, которые вообще не знают, что такое домен, а просто набирают слово «вконтакте» и щелкают по первой сверху ссылке — это не фантазия, а реальность. Неизвестно только что труднее создать и внедрить — децентрализованную DNS, или децентрализованный Google?

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

Заключение


Кому-то этот топик может показаться слишком уж утопичным. Большая часть технологий еще выглядит довольно сыро и ненадежно. Но! Вернитесь к цифрам в самом верху. Если есть хоть какой-то шанс дотянуться до всех этих петабайтов, которые сейчас простаивают, разве не стоит хотя бы попытаться? Ведь это будет революция не хуже массового файлообмена и облачных вычислений! Изменения уже витают в воздухе. Базы данных и доступ к файловой системе переползают в браузеры, JavaScript лезет на сервера, NoSQL СУБД набирают обороты, стирается разница между скоростью локальной сети и интернета, очередной проект децентрализованной социальной сети собирает 200 000 долларов без единой строчки кода, только потому, что людям очень хочется в него поверить. Может время уже пришло?


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


UPD2: Тут в соседнем топике всплыла идея, которая очень хорошо ложится на мои фантазии.


Список для дальнейшего чтения

Интересные документы, которые нашлись в процессе написания статьи, но которым не досталось ссылок в тексте. Почти везде — прямые ссылки на PDF:

Cryptographic Access Control for a Network File System

Cryptographic Access Control in Remote Procedure Call

XPeer:A Self-organizing XML P2P Database System

Flexible Update Management in Peer-to-Peer Database Systems

A Flexible Architecture for a Push-based P2P Database

A BitTorrent-based Peer-to-Peer Database Server

A Survey of Broadcast Encryption (осторожно, жёсткий матан!)

Список публикаций проекта Coral CDN

Attacks on Peer-to-Peer Networks

Design of a Cheat-Resistant P2P Online Gaming System

Securing Content in Peer-to-Peer File Systems

Building secure systems on & for Social Networks

Secure Peer-to-peer Networks for Trusted Collaboration
Илья Сименко @ilya42
карма
524,7
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (131)

  • +3
    Спасибо, отличная статья. Хочется верить, что это будущее уже близко :)
    • +7
      И мне очень хочется. Я написал так много букв во многом потому, что когда заинтересовался этой темой, не нашел почти ни слова по-русски. Сами видите — почти все материалы на английском. Хочется, чтобы мы не получили очередную технологию из-за бугра в готовом виде, а придумали что-то сами. Если статья подтолкнет кого-то заняться разработкой в этой области, я буду считать свою миссию выполненной
      • +1
        Супер! Я буквально в понедельник это «придумал» и начал искать ссылки на проекты, которые уже в этом продвинулись. А тут и ваша статья прямо в тему! Мне видится революционным именно сочетание децентрализованного аналога DNS и распределенного хранения данных — прям вообще без центрального сервера, чтобы отрубить не могли :) И если за DNS основатели Pirate Bay уже взялись, то здесь — да, простор для творчества.
        • +2
          У меня и про DNS мысли были, но когда в OpenOffice перевалил за 10 странниц этого топика, я понял, что лучше как-нибудь попозже напишу: )
      • 0
        Идея витает в воздухе довольно давно, применений — море.
        Около полугода назад сделал bothq.com/, но из за кучи навалившихся других дел не хватило времени довести до готовности, да и даже до статьи о возможностях использования.
        Спасибо за отличную статью, надеюсь, она всё-таки сподвигнет меня довести задуманное до ума.
  • –12
    Статья конечно интересная но было бы лучше такие объемы информации делить на несколько статей.
    • +6
      Я сам был в шоке, когда заканчивал писать: ) Просто я писал не последовательно, а параллельно, до конца не будучи уверенным, с чего начну, а чем закончу, и уточняя многие детали по ходу дела.
      • 0
        Оригинальный способ написания, но читается на одном дыхании! Мне хочется верить в такое устройство интернета будущего. Существующие (создающиеся) модели PaaS и IaaS не вызывают восторга, т.к. там есть «крайний». Некий холдер который может «перекрыть кран». В такой p2pIaaS этого не случится!!! Я думаю первопроходцами в этом деле должны стать простые http-сервера. Пусть пока статичный контенте станвится распределенным… северные технологии обеспечивающие динамический контент подтянутся.
    • +1
      А толку?
  • +1
    Вы конечно хорошо поработали написав такую объемную статью :)Очень интересно! Спасибо.
  • +11
    Чтение статьи завораживает не меньше, чем смотреть в торрент-клиент работающий))
  • 0
    Хостинг на ботах уже давно существует. Тоже p2p.
    В некоторых случаях нужно не мечтать, а делать.
    • +2
      А вы расскажите поподробней, а?
      • 0
        Ну человек написал:
        >И насколько труднее было бы кибергопникам или спецслужбам DDoS-ить такой сайт!
        Хотя как раз кибергопники это и придумали, используют и будут использовать. Если не ошибаюсь первые сообщения об этом появились три года назад, может раньше. На сколько знаю, архитектура практически идентична описаной в статье, хотя встречаются и исключения. И действительно система практически непотопляема.
        Ссылками делиться не буду, это к гуглу с запросом: «хостинг на ботах».
        • +2
          Вы только не подумайте ничего. Ваша статья чудесна.
        • 0
          Ну дык кто к нам с DDoSом придет, тот от DDoSа и погибнет. В том и фишка. А вообще очень хотелось бы, чтобы кто-то из хакеров поделился информацией. У них действительно есть такой опыт.
        • 0
          тут почитал — ничего не понял. Можете на пальцах объяснить?
          • 0
            Я ж не владелец этого чуда, откуда мне знать?

            Вот ссылка на средней паршивости материал: spamtrackers.eu/wiki/index.php/Botnet_hosting
          • +1
            Это лажа. Суть — ботнет прокси серверов к вашему серверу.
            • +1
              В смысле не лажа, а немного другое. Не то что имел ввиду автор топика, да и цели другие.
    • +1
      I2p
      ru.wikipedia.org/wiki/I2P
      en.wikipedia.org/wiki/I2P (полнее)
      habrahabr.ru/blogs/infosecurity/97827/ — «I2P — Проект Невидимый Интернет»
      • +1
        Да, есть такая штука. Но всё-таки анонимные сети — довольно узкая ниша. Хочется чего-то подоступнее.
        • 0
          Анонимность тут — как дополнение. Никто не запрещает её убрать.
  • +2
    очень здравые мысли,
    и почему утопия?
    имхо, вроде как все реально, вопрос только в реализации и стандартизации
  • +2
    Спасибо за развитие темы. Ссылки пока не осилил — после работы.
    Какие мысли возникли:
    1. Затраты (вычислительные и трафика) на шифрование, дешифрование, контроль и наказание в большинстве случаев будут превышать затраты на хостинг, который скорей всего будет дешеветь.
    2. 99% подойдут далеко не всем проектам — отбрасываем все сайты компаний, новостные, платежные, сервисы. Остаются по большей части развлекательные, скажем блоги (хотя они уже приравниваются к новостным), домашние странички, анекдоты, видеохостинги, порно…
    3. Все-таки не понятен вопрос с динамическим контентом. Вернее с потоком контента. Отправленный комментарий уходит куда? Где собирается страница (список новых комментариев)? Как остальные узнают, что появился новый комментарий?
    4. Система рейтинга (кармы), имхо, пока не достаточно честная/прочная/надежная (см. Хабр). Есть большая вероятность коллективного намеренного (или ненамеренного, скажем вирус) вредительства.

    Пока всё — ещё мысли роятся…
    • +1
      1. Тут нужно считать. Например, BitTorrentDNA как раз снижает затраты на хостинг.
      2. Ну дык понятно, что не всем. Корпорациям естественно будет удобнее и спокойнее держать свой хостинг, благо денег хватает. Насчет новостей — почему бы и нет. Или, например, Википедия.
      3. Думайте о кусках динамического контента, как о маленьких файликах в P2P-сети. Страница собирается на клиенте. Остальные могут узнавать об обновлениях например, через pubsubhubub.
      4. Возможно, но при наличии центрального сервера это вообще не проблема, а без него — придется придумывать что-то. Вредительство не сильно опасно, если есть контроль версий, как в Википедии.
  • 0
    Статья читается почти как научная фантастика, спасибо.
    Представил распределенный хабр. И так иногда попадаешь с комментарием — вроде и быстро его пишешь, а уже кто-то в ту же секунду аналогичную мысль выразил первым.
    А при указанном методе обновления такое начнется-)
    • 0
      Мне кажется, этот вопрос можно решить. Ведь обновления могут распространяться прежде всего локально, я об этом писал. Нужна, конечно, какая-то синхронизация по времени между узлами, чтобы можно было определить, кто написал раньше.
  • +2
    Думаю и динамический контент можно хранить распределенно. Современный DHTML на JavaScript может обеспечить вполне приемлемый функционал. Страница будет собирать данные с пиров и окончательно монтироваться на клиентской стороне.
    В общем я считаю, что современные технологии это позволяют. Дело за проработкой идеологии, схемы таких механизмов, и самое главное — их реализацией.
    • 0
      Да. Забыл присоединить свое спасибо за статью :)
      И за ссылки на материалы по теме.
    • 0
      Во-во! Именно это я имел виду! Приятно, когда тебя понимают :)
  • 0
    Теперь я буду грезить будущим.
  • 0
    Кибергопники могут посылать неверные данные. Клиент скачает их, по хешу не сойдется, клиент заново скачает и это может продолжаться очень долго, если у кибергопников ботнет. Передача неверных данных иногда используется копирастами, именно по этой причине скачанного бывает сильно больше, чем размер файла. Эту проблему надо как-то решить.
    • 0
      Да, есть такая угроза. Возможно, система репутации может помочь — если ты постоянно толкаешь испорченные данные, то быстро исчезаешь из виду. Примерно как здесь с кармой и троллями.
  • 0
    Круто. Многое из упомянутого уже не первый год живёт в голове, но не представляю, как можно было бы поучаствовать в создании такого «следующего Интернета» на коммерческой основе, получая за это деньги. Ведь это именно технологии, стандарты, платформы, которые нельзя продавать напрямую, но можно на их основе построить новый, лучший Интернет ))

    Что касается терминов и источников, см. также термин «GRID». Как и TCP/IP, эта группа технологий зародилась в CERN и уже используется для хранения и обсчёта результатов LHC. Наиболее вероятно, что со временем эти технологии перейдут сначала в бизнес, а затем в быт.

    Спасибо за статью и успехов.
    • 0
      А мне вот один человек из Питера уже написал написал по скайпу — говорит, делают подобную штуку. Я ему инвайт послал, может скоро здесь объявится.
      • 0
        Хотелось бы этим деньги зарабатывать.
        • 0
          Мне тоже: )
          • +1
            Вы не задумывались, что проприетарный подход себя не оправдывает? Чтобы сеть была популярной — она должна быть доступной без каких-либо условий. Зарабатывать надо на сопутствующих вещах, а не на технологии. А то будет как сейчас в сети с флешом и h.264 — вроде бы хорошие вещи, но тормозит их проприетарность с лицензированием. Нужен public domain и никак иначе. Те же проблемы с копирайтом и p2p сетями — люди считают, что продукт произведения человечества, принадлежит всему человечеству, а вот старый мир не готов к новому мышлению и отсюда проблемы. Современные люди уже мыслят другими категориями, которые шибко конфликтуют со старыми подходами.
            • 0
              Ну так я о том и пишу, что такие проекты (инфраструктурные) очевидно нужно делать открытыми — создавать платформы. В закрытом виде они просто не получат нужного распространения. Поэтому и встаёт вопрос: как мне зарабатывать деньги, создавая такое ПО (квалификация есть)?
            • +1
              Полностью поддерживаю! Маленькая компания, оказывающая дополнительные услуги поверх гигантской бесплатной экосистемы, которую она создала и поддерживает — вот что круто! Типа 37signals
              • 0
                Ну тогда значит мы с вами на одной волне мыслим :)
              • 0
                Ну, компания может быть и не такой уж и маленькой. Тот же гугл старается использовать открытость в своих целях. И SUN, пока жива была.
                И мы целимся.
                • +1
                  Ну, с ростом компании экспоненциально растет опасность погрязнуть в корпоративном маразме и превратиться в динозавра…
      • +7
        Да, делаем систему распределённой обработки запросов с множеством всяких интересных вещей. Сайты смогут запускаться в одноранговой сети состоящей, в том числе и из сторонних узлов. С точки зрения пользователя такой сайт выглядит просто как обычный http сервер — модификация браузера не требуется.
        Помимо серьёзного ускорения динамики получаем практически линейное масштабирование и динамическое кеширование.
        В одном комментарии описать как это работает трудно — в скором времени будем выкладывать материалы.
        Если хабрасообществу будет интересно, как только будет запуск, напишу подробную статью о том, что и как работает. А если понравится, то и несколько статей.
  • +5
    Похоже скоро произойдёт «эффект сотой обезьянки» — ваша статья полный клон мыслей в моей голове за последние полтора-два года. :) Большую часть ссылок в вашей статье я нашёл сам в поисках ответа на мои мысли. Это тоже подтверждает, что течение в эту сторону началось… У нового поколения людей с приватностью покончено судя по взрыву социальных сетей — люди делают общественным достоянием свою приватную жизнь и такое понятие как «приватность» постепенно начинает стираться. Может быть следующий виток — это когда люди сделают общим достоянием свои личные неиспользуемые доступные ресурсы, а не только мысли и образ жизни? Т.е. они попросту перестанут быть собакой на сене имея 8ми ядерные процессоры которые простаивают до 80%… Интернет изменил человечество и я думаю — это ещё не предел. Уверен, что в обозримом будущем операционные системы будут иметь предустановленные не отключаемые компоненты, которые каждый компьютер будут превращать в вычислительно-хранительную ячейку распределённой глобальной сети… Будущее никогда не было так близко. :)
    • 0
      А вот правда, очень странное такое чувство, когда видишь, что кто-то настолько близко придумал то же самое, что у тебя в голове варилось? С одной стороны приятно, а с другой досадно как-то, что не ты первый. Я так антибуки придумал один в один, атомы QuickTime, паттерн «Компоновщик», и еще кучу всего: )
      • +2
        Именно это и принято называть эффектом сотой обезьянки… :) goo.gl/c5BnH
        • 0
          Ух ты, я про это читал в книжке Карла Сагана «Драконы Эдема». Только там это никак не называлось, Фразу «эффект сотой обезьяны» вижу впервые. Спасибо!
        • +2
          • 0
            Перечитал внимательнее. Таки да, туфта. Наверное именно поэтому в книжке Карла Сагана «Драконы Эдема» это никак не называлось. Книжка-то вполне толковая. И теперь я припоминаю, что там не о бататах речь шла, а о зерне…
          • 0
            Вашему якобы пруфу можно верить ровно на столько же верить на сколько и моей ссылке. :) Ваш пруф «авторитетно» ссылается на сведения вида «В середине 80-х _кем-то_ из учёных была поднята та изначальная работа японских специалистов...». Лично я не уверен на 100% ни в оригинальности эффекта сотой обезьянки, ни в вашем пруфе, но ваше высказывание «туфте» свидетельствует о жёсткой позиции :) И вообще мы все сами все выбираем во что верить :) Правда она знаете-ли двулика и у каждого своя :)
            • +2
              А тут дело не в авторитете вовсе. В двух словах объяснить не смогу, но я в этом топике давал ссылки про стандарты журналистики и список когнитивных искажений. Их комбинация, при вдумчивом чтении и некотором навыке применения, создает в голове довольно таки точный детектор туфты. Так что все-таки туфта, увы.
              • +2
                Фиг с ними обезьянками :) Туфта и туфта. Термин и его происхождение вполне наверняка высосаны из пальца, однако явление явление в той или иной степени в природе существует под разными видами. Давайте назовём это более привычным: «критической массой» — термином из уважаемого сейчас раздела науки — ядерной физики. Именно этот термин и можно применить к разным процессам в мире, которые достигнув своей критической массы просто продолжают развиваться дальше в виде самоподдерживающейся цепной реакции. Пусть духовные гуру это называют своим ученикам эффектом сотой обезьянки, а физики критической массой… Суть-то та же… да и ваще все наши современные знания и формулировки фигня — буквально пятьсот лет назад жгли на кострах за попытку доказать, что земля круглая и вращается вокруг солнца, а сейчас некоторые лупят себя в грудь учебником по теории относительности и квантовой физике доказывая суть мироздания… Может через 500 лет физики мира будут обсуждать законы мироздания именно отталкиваясь от этой сотой обизянки или тасячного муравья. :) Вобщем это ненужная полемика, но надеюсь вы меня поняли :) Давайте остановимся на критической массе вместо обизянок :)
                • 0
                  В таком виде — согласен. Собственно, я в этом смысле сначала и думал о 100 обезьянах.
                • +1
                  как мем — этот «эффект сотой обезянки» весьма ярок для обозначения накопления критической массы предпосылок в информационном контексте. Но к сожалению он слишком ярко намекает на ноосферу и телепатию, и слишком явно отрицает наличие нормального общего информационного контекста.
      • 0
        Эти идеи витают в воздухе уже лет 5 (см. GRID), но их развитие крайне невыгодно нынешней контент-индустрии: все посредники тогда просто вымрут, когда настанет эпоха децентрализованного псевдонимного интернета.
        • 0
          развитие Linux наверное тоже не выгодно, тем не менее своим знакомым негикам я поставил более полугода назад ubuntu и они в целом не собираются возвращаться на windows :) — т.е. это как показатель того что он уже немного вышел за уровень «только для красноглазиков»
    • +1
      ещё одна обезьянка, сам вынашиваю абсолютно такие же идеи уже несколько лет.
      строил математические модели по модификации существующих протоколов DHT, писал криптопротоколы, продумывал архитектуру верхних уровней сети, даже начинал писать код, но нехватка времени и заинтересованных людей его убила.

      предлагаю обсудить проблемы и возможность совместной разработки в конференции peercloud@conference.jabber.ru
  • 0
    Самая великолепная статья, прочитанная мною на хабре.
    Прочитал её самым первым, но поскольку был на вождении и читал с телефона, компенсирую лишь сейчас.
    Такие подробные рассуждения, подпитка фактами, неплохо сочетается с фантазиями.
    Думаю, в эту ночь я не засну- мой мозг будет судорожно обрабатывать прочитаное в этой статье.
    Вау! Потрясно!
    Другогих слов не найти.
    Сколько потратили времени на написание сего произведения?
    • 0
      *комментирую лишь сейчас.
      +добавлю, что статья была прочитана мною на одном дыхании.Может быть, даже меньше.
      • +3
        Выдыхай, бобёр, выдыхай!
    • 0
      Точно не скажу. Мысли-то давно бродили в голове. Конкретно написание заняло в пересчете на чистое рабочее время несколько дней. Конечно, ссылки до этого собирались несколько месяцев. Между прочим, последней каплей, чтобы таки начать писать, как раз было то, что спать не мог из-за мыслей: )
      • 0
        :)
        Одинаково мыслим ;)
  • 0
    Удивительно интересная и приятно изложенная статься.
    Большущее Вам спасибо!
  • 0
    Статья отличная — все наконец-то собрано воедино, со ссылками. В такие минуты я жалею что не имею к веб-девелопменту никакого отношения.
  • 0
    «Достаточно дописать справа от URL ресурса «волшебные слова» .nyud.net, и весь трафик пойдет через Coral.»
    Охренеть!) Я открыл в двух вкладках главную страницу одного и того же проекта: напрямую, и с дописанным ".nyud.net" после имени домена. Затем вырубил веб-сервер, и обновил вкладки. Первая, как и полагается, не открылась, а вторая продолжила работать!
    • +2
      Шайтан, да?: ) Было бы еще классно устроить научно-исследовательский флеш-моб с FireCoral. Договориться в определенное время включить плагин, и вот так вот погонять тестовый сайт.
  • 0
    … вырастет энергопотребление, скажем на 70 ватт в час
    Я сноб, но энергопотребление измеряется в ваттах, а не в ваттах в час. >:|
    • 0
      ...50 киловатт/час
      А потребленную энергию можно измерять в (кило)ваттах×час, а никак не в (кило)ваттах/час.
      • 0
        Спасибо за бдительность, поправил.
  • +3
    Так зарождался SkyNet…
  • 0
    Отменная статья, молодец автор! Уже не в первый раз возникает идея скрестить HTTP и торрент. Помнится, я тоже уже предлагал такую идею на рутрекере, но меня завалили ссылками на нетсукуку и Tor… =) Буду теперь сидеть и переваривать написанное, может, что и выйдет в итоге на уровне концепта…
  • 0
    Интересно, как это будет сочетаться с семантическим вебом.

    Уже сейчас есть SPARQL endpoints, к которым можно делать федеративные запросы (объединяющие сведения из нескольких источников). Осмелюсь предположить, что трансформируется само понятие источника.

    Думаю, источником будет не тот, кто раздаёт данные, и даже не тот, кто контролирует раздачу. Контролировать, что идёт с раздачи, будет сам приёмник: что захочет, на то и отправит запрос. Что не даст один, раздадут другие. Возможно, источником будет считаться лишь тот, кто когда-то сбросил данные в сеть. Однократно. Не будет нужды и смысла держать сайт. Сайтов не будет :) «Сайт» означает «место». В распределённой системе место не имеет значения. Вы когда-нибудь интересовались, кто конкретно порадовал вас фильмом с торрента, выложив его первый раз? Вот именно.

    Более того, даже это понятие источника не всегда будет применимо. Некоторая информация будет возникать как логический вывод (OWL reasoning как пример) на основании информации из разных источников. То, что сейчас делают аналитики, будет делать сама сеть.
    • +1
      Более того, со всеми этими децентрализованными технологиями сохранять анонимность в интернете станет намного проще. Копирасты взвоют.
      • 0
        А вот как раз в этом я серьёзно сомневаюсь. Просто станет меньше точек контроля. Исчезнет возможность отслеживать юзера на дальних подступах — на серверах, на пограничных каналах. Но точки контроля непосредственно вблизи самого юзера — провайдеры — останутся. Распределённая сеть тут ничего не изменит.

        Настоящую анонимность тут могут дать только предельно дешёвые, в идеале одноразовые, точки доступа в сеть. Подобрал пачку карточек с чипами на улице, поюзал — сжёг, пепел разжевал и проглотил, запил растворителем :) И то, если кругом натыкать камер, юзера отследят по координатам. Надо будет ходить толпой и в одинаковых масках :)
        • 0
          Слышали про Netsukuku?
          • 0
            Теперь да :)

            Похоже на решение проблемы. Если ещё и быстро перемещаться (в толпе, в транспорте, настроившись на быструю смену узлов, дабы игнорировать подсаженные жучки), то отследить, что вы получаете и от кого практически невозможно.

            Остаётся только одно узкое место — непосредственно ваш аппарат :) Поэтому я и упомянул одноразовые устройства.
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              Большая часть привычных сейчас технологий была когда-то исследовательскими проектами. Пусть исследуют. Если они сами не запустят такую сеть, кто-то другой на базе их исследований сможет.
              • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      У меня тоже возникли мысли по поводу Semantic Web.

      Но тут остро встает проблемма производительности. Во-первых, данные (в данном случае RDF-триплеты) сильно фрагментированны, следовательно, будет очень много запросов по сети. Кроме того БД для RDF тоже не могут похвастаться скоростью. Во-вторых, обрабатывать данные тоже нужно будет больше — это вам не отдать пару файлов. А логический вывод вообще может целую вечность длиться.
      • 0
        Данные дублируются, логический вывод параллелится и кешируется… будущее неизбежно :)

        Это уж не говоря о том, что производительность растёт геометрически. Объём данных тоже, конечно, но, имхо, логический вывод будет делаться в основном на статистических обобщениях и локальных подмножествах. Человек, когда думает, тоже не весь архив в оперативку загружает :))
      • +1
        У меня аж мурашки по коже пошли — я вот чего подумал: если совместить идею semantic web с методикой Push on change, то сеть может и не дожидаться запроса, а сама в фоновом режиме начать генерить ответы. То есть думать.
        • 0
          Вообще-то я отдавал эту привилегию персональным агентам. Но агенты будут общаться между собой, а значит — думать сообща. Это не существо, как пишут фантасты, порождённое сетью, несчастное в своём одиночестве и судорожно ищущее личных контактов. И не враждебный параноик, вообще не личность.

          Это сообщество. Мои мурашки передают привет вашим :)

          А если посерьёзнее… думаю, ризонинг уже делается в фоновом режиме, по мере добавления данных, на давно уже работающих экспертных системах. Т.е. они готовят ответы раньше, чем зададут вопросы. Если это означает «думать», то «думатель» уже изобрели и реализовали, причём с коммерческим успехом :)
          • 0
            Swarm intelligence, только вместо муравьев и пчел мы…
            • 0
              Скорее наши отражения. Та частичка каждого из нас, которую мы сумеем оцифровать и пропихнуть в сеть. Там они начнут мутировать, брать от соседей то, на что мы их изначально настроим… Далее процесс выходит из под нашего контроля. Аватар только арендует у нас жилплощадь и платит за электричество. Что он там думает — хрен его знает. На вопросы отвечает, жить помогает — ну и бох с ним, пущай живёт рядом. Он кстати ещё подумает, с кем рядом жить. У кого ядер побольше и синусоида питания правильнее. И кто глупыми вопросами не слишком часто достаёт :))

              Фантастика фантастикой, а я сейчас занят прозой жизни, пишу десктопный базолаз к триплетным данным (локальные .rdf/.owl, триплетные базы типа Jena TDB, удалённые sparql endpoint). Поражает практически полное отсутствие конкуренции. Надеюсь, когда продукт будет доведён до беты, спрос появится. Впрочем, может быть я его и сформирую? :)
              • 0
                Скажите, а вы встречали движки для логических выводов (inferations) на популярных ЯВУ (особенно хорошо, если на каком-нибудь javascript)?
                • 0
                  Смотря что считать логическим выводом, и что считать популярным ЯВУ. Я вообще не специалист в этой области, и пока не стремлюсь им стать. Если вы о ризонерах, то я немножко работал лишь с Jena и HermiT. Вроде бы и то, и другое на Java (и open source). Посмотрите тут, не знаю уж, оно не оно: http://en.wikipedia.org/wiki/Semantic_reasoner. Оттуда есть ещё ссылка на список от W3C.
    • 0
      У меня были мысли по поводу некой распределенной Вики, где каждая статья будет посвящена какому-нибудь ресурсу в интернете, который будет идентифицироваться хэшем. Этим ресурсом может быть любой файл, веб-сайт, картинка, сообщество. Что-то вроде глобального совместно редактируемого трекера или системы DNS со встроенными аннотациями.
      • 0
        DBpedia (не зря похоже на Wikipedia, оттуда ноги растут). Довольно знаменитый проект (есть HTTP доступ, есть SPARQL endpoint). Пропагандируется как точка кристаллизации в интернете, вокруг которой нарастёт семантический веб. Есть и ещё подобные.

        Идентификация ресурсов только не хешами, а URL'ами.

        Танцуется это всё от теоретической печки, на которой написано «онтология». Впрочем, воплощений на практике всё больше. Для примера запрос к той же DBpedia: http://dbpedia.org/page/Ontology_%28information_science%29. Писать запросы самому на SPARQL, конечно, куда интереснее.
  • 0
    Уже несколько человек, прочитав топик, сознались в том, что вынашивают (а некоторые уже и реализуют) коварные планы по созданию проектов, подозрительно похожих на фантазии автора. Предлагаю всем, у кого есть какие-то наработки обмениваться здесь (для начала) опытом и идеями. Авось что-нибудь интересное из этого выйдет!

    Присоединяйтесь!
  • 0
    Ух… класс… не зря я защитил магистерский диплом на тему «оптимизация и разработка алгоритмов поиска в DHT сетях (на примере Kademlia)»…
    Об DHT сайтах я тоже уже давно думал, сразу как понял что такое DHT.
  • 0
    Статья замечательная. Хорошо систематизирует те идеи, которые буквально витают в воздухе и приближает их реальизацию. Я верю, что примерно так оно когда-нибудь и будет, не заменив, но дополнив существующий интернет.
    Немного побрюзжу:
    Ну нельзя вот так тупо брать и складывать:
    — Дисковое пространство, потому что любая подобная система предполагает значительную избыточность и чем она сложне тем большая избыточность требуется. Все эти сотни тысяч петабйт на самом деле вовсе не сотни тысяч.
    — Полосу пропускания. Без комментариев.
    (Это и Ежу понятно. Эй, Ёж! — крикнул он в пространство. — Тебе понятно? — Мне все понятно, — отозвался из пространства некто Ёж.)(с)
    • 0
      Насчет избыточности — полностью согласен, но прикидывать, сколько раз в среднем нужно дублировать информацию — дело совершенно безнадежное. Некоторые вещи стоит хранить в десятках экземпляров, а некоторые наоборот дедуплицировать. Поэтому я просто написал голую цифру без учета избыточности.
  • –3
    «Насколько меньше рекламы я бы увидел?»
    Как затрахал этот социализм в голове автора статьи.
    Лучше чтобы наоборот рекламы (полезной, поведенческой, ненавязчивой) было больше, и чтобы она не просто была, но ещё и доходы от неё получали все участники процесса согласно своему вкладу в проект (в виде автора, в виде раздачи файлов и т.д.).
    Реклама — двигатель прогресса, и лучше денег ничто в мире лучше не мотивирует.
    • +1
      Как рекламодатель боюсь с Вами согласиться.
      Но как потребитель (невольный) рекламы склоняюсь больше к качественным тематическим каталогам. Понадобилось мне найти что-то — пошел на спец. сайт.
      Опять же как рекламодатель я знаю, что покупки (наиболее выгодные продавцам) совершаются спонтанно, т.е. увидел я баннер с «супер-классной-штукой» и кликнул-купил.
      Вобщем зря Вы так категорично — надо искать здоровую середину.
  • 0
    «При средней цене электричества в мире около 10 центов за киловатт-час — это $5 в месяц.»
    В Москве киловатт уже 3.8р, что есть 13 центов, а это уже почти $7, 200 рублей.
    Ну и самое главное шум, стоимость безшумного компьютера как минимум на $150-$200 выше.

    «175 000 петабайт дискового пространства»
    не учтено, что на каждом HDD свободно обычно 10%.
    И эта цифра — фигня, каждый из сотовых операторов В ДЕНЬ пишет 1петабайт логов. Гугл обрабатывает 20Пб в день.
    • 0
      У нас в Харькове пока 3-4 цента: ) Шум, конечно, присутствует. Где-то я видел статистику, что в США 50% людей не выключают комп на ночь, в Европе — 25%.

      Насчет 10% — ну не знаю… У меня — не меньше 50% Плюс, большая часть занятого места — всякий мусор, типа прошлого сезона какого-нить сериала, который я держу только ради рейтинга на трекере. Нет, конечно если вы занимаетесь видео или еще чем нибудь, что требует много места, то вам и несколько Терабайт занять ничего не стоит. А в остальных случаях, при нынешних скоростях просто нет смысла хранить коллекции фильмов или mp3, как раньше.

      А сотовые операторы (я так понимаю, вы имеете в виду крупных) или Гугл — это ведь гиганты. Естественно и цифры у них гигантские.
  • 0
    В США эти самые 50% людей имеют дом на 300 квадратных метров, и вопрос шума по ночам у них не стоит.
    • 0
      Зато у них стены из фанеры и гипсокартона :) Впрочем, вы правы, конечно, но порядок цифр это не меняет.
  • 0
    Так и не понял, а где будет работать так называемая «бизнес-логика», особенно когда она должна работать практически в реалтайме. Возьмём, например, браузерную MMOG с «тиком» в одну секунду (про настоящий реалтайм даже не думаю), пускай онлайн 1000 человек, то есть любое действие любого из этих людей должно не только транслироваться остальным 999 с опозданием максимум в секунду, но и проходить проверку на допустимость такого действия в эту же секунду, равно как отдаваемая пользователю инфа должна проходить строгую авторизацию (то что пользователь секунду назад имел доступ, не значит, что он имеет доступ сейчас, как и наоборот, секунду назад не имел, а сейчас имеет). Естественно проводить такую проверку c помощью браузерного кода (DHTML+JS как писали выше) нельзя. Репутация, консенсус, кворум тоже работать не будут, поскольку даже единичная ошибка практически недопустима, а ситуация, когда большинство узлов, включая живущие на этом «сайте» годами с соотвествующей репутацие, выдадут неверный ответ вполне реальна.

    Как такая система будет выглядеть в p2p облаке? Каждый «клиент» из 1000 посылает запрос на действие 1000 «серверам» (включая себя), получает ответы от всех (включая себя), сравнивает их друг с другом и при обнаружении малейшего несоответствия (легко проверяется сравнением подписи ответа своим открытым ключом) выкидывает эксепшен и не работает до тех пор пока админ не придёт и не разберётся, кто читор, а кто нет? И как быть с тем, что пользователь не должен получить информацию со своего «сервера», к которой он не имеет доступа?
    • 0
      Если даже единичная ошибка недопустима, и нужна быстрая реакция, то, естественно, эта схема работать не будет. У каждой технологии есть границы применимости. Если нужна или скорость, или безошибочность, то уже возможны варианты. Если не нужно ни то ни другое (при условии возможности исправить ошибку), например на сайте вроде Википедии — все должно работать без проблем. Всё-таки жесткий реалтайм+нетерпимость к ошибкам — не самый распространенный сценарий. Кроме игр приходят в голову разве что всякие финансовые и биржевые инструменты, но эта технология в принципе не для них.
      • 0
        Жаль, думал пропустил какую-то киллер-фичу. Но вообще я правильно модель выполнения бизнес-логики понял — каждый «сервер» (части пользователей — сидов) хранит копию сервера приложений и выполняет запросы других клиентов, пользуясь распределенным криптографически защищенным хранилищем? Если да, то для обработки этих данных, сервер сида должен получить ключ доступа к ним, если получает сервер сида, то получает и сам сид (локальный сниф трафика, дампы памяти, выполнение по дебагером и т. п.), а значит сервером, обрабатывающим запрос должен быть сид, который и так имеет доступ к этим данным? А для обработки приватных данных (например, телефон для смс-уведомлений о событиях в той же соцсети) единственный вариант самому быть сидом, иначе просто некому их будет обрабатывать?
        • 0
          Правильно. Обработкой он может заниматься, только если имеет право доступа. Например, как в folding@home — исходные данные для расчетов секретом не являются. Если же такого права нет, то нет и ключа. Нигде — ни в памяти, ни на диске. сервер сида в этом случае — только перевалочный пункт, он может хранить пакет, может раздавать его, но заглянуть внутрь — не может. Ключи есть только у создателя пакета, и у тех, кому он их сам дал. Так что обработка — да, только сам, а хранение и раздача — кто угодно.
          • 0
            Всё-таки кажется, что без «центральных» (заведомо доверенных) узлов в такой схеме не обойтись — для той же соцсети может потребоваться получить доступ к приватным данным когда свой «сервер» (домашний комп) по каким-то причинам не доступен. То есть работа с публичными данными может вестись любым узлом, а с приватными или своим, или этими «центральными», то есть доверять им как сейчас доверяем владельцам соцсетей и их хостерам. Да и с публичными может случиться ситуация, когда добровольных сидеров нет онлайн. Да и проверка прав доступа остаётся, особенно если не ограничиваться no access/full access, а добавить хотя бы read only. Кто в случае, например, хабра будет проверять могу я запостить этот коммент, не могу в принципе, или смогу только через 5 минут, но при этом читать всегда могу.
            • 0
              Обходиться без центральных серверов — это не самоцель. Главная идея — снизить на них нагрузку, тем самым многократно уменьшив затраты на хостинг. В принципе, можно работать абсолютно без центрального сервера, как во FreeNet. Можно использовать центральный сервер вначале, как центр кристаллизации, для придания нужного импульса, а потом пустить проект в автономное плавание. Можно всё время работать с центральным сервером.

              Если домашний комп не доступен, а нужны приватные данные, можно воспользоваться двухступенчатой схемой, например, хранить ключ от приватных данных в каком-нибудь LastPass.

              Права доступа могут проверять окружающие сиды. В случае, если это не критично (ну никто же не умрет, если вы один раз напишите комментарий через 3 минуты, а не через пять) — можно им доверять. Если критично, то должен проверять либо центральный, либо кто-то из нескольких авторитетных серверов.
              • 0
                Вот именно. Задача не полностью перенести инфраструктуру сети на те ресурсы, что в статье описаны, а задействовать их.
                • 0
                  Теперь всё понятно, а как-то по тексту показалось, что задача — создать полностью децентрализованный интернет
                  • 0
                    В перспективе и полностью децентрализовать интернет можно. Это как один из вариантов имеющий свои плюсы и минусы.
    • 0
      будут игры в условиях «зыбкой реальности», которая задним числом умеет подправлять всевозможные мелочи ;)
      это тож прикольно. (кста, чем-то похоже на фантазии Леонида Кудрявцева в его циклах о мирах снов)
      • 0
        Тоже показалось, что с требованиями по реалтайму и валидацией запросов как для финансовых систем я несколько переборщил :)

        Но вот проблема «микроавторизации» (постоянно изменяющихся прав доступа к отдельным документам и к отдельным их полям) остаётся. Нужно генерировать, хранить и обмениваться кучей пар ключей на все случаи жизни.
        • 0
          Это не так страшно, как кажется. Во-первых, любая открытая информация вовсе не нуждается ни в каких ключах, а только в подписи. Большие объемы чувствительной к разглашению информации крутятся, в основном, в enterprise — секторе. И там же часто приходится менять уровни доступа пользователей и отделов. В типичном профиле участника соцсети, например, информации на порядки меньше, да и друзей из одной группы в другую он будет перекидывать редко.
    • 0
      Абсолютно не обязателен принцип 1 клиент=1 сервер. А если нагрузка реально требует работы 1000 серверов, то как по другому вы это организуете? Централизованное хранилище не предлагать т.к. нагрузка на него будет такая, что без распределения и, опять таки, синхронизации не обойтись.
      • 0
        Распределение и синхронизации нагрузки по 1000 заведомо доверяемых клиентом и друг другу серверам я думаю на порядки проще ситуации, когда никто друг другу не доверяет. Более того, некоторые схемы взаимодействия в такой ситуации без наличия серверов, которым все заведомо доверяют просто исключены, по-моему, или сильно затруднены. Возвращаясь к примеру игр: Я строю себе армию, о ней никто не должен знать до момента столкновения, значит обрабатывать процесс постройки может контролировать только мой сервер, т. к. это тайна для всех остальных. На меня нападают, тут мой сервер должен взаимодействовать с сервером нападающего (его армия тоже тайна для всех), один из них подсчитывает результаты боя и отдает другму (или оба считают, а потом сверяются). Что мне мешает хакнуть свой сервер и передать заведомо неверную инфу серверу противника?
        • 0
          Всё-таки игра — очень специфический пример. Самоорганизация в распределенных системах работает очень хорошо, если предположить, что большинство узлов не имеет злых намерений и хочет сотрудничать, а не конкурировать. В случае Хабра или Википедии — это действительно так. В случае игры — у игроков всегда есть сильная мотивация надуть друг друга любой ценой. При сильной конкуренции не обойтись без центральной власти.
  • 0
    Это можно решить с помощью ACL на данные. Какие-то данные приватные, какие-то публичные, какие-то с особыми правилами/обработчиками. А независимый подсчёт можно устроить путём сверки с предварительным обменом хешей ключевых данных. Это в качестве примера т.е. архитектурно проблема решается достаточно просто.
    • 0
      Прошу прощения, это к комментарию VolCh выше (http://habrahabr.ru/blogs/p2p/112491/#comment_3607795). Не туда вставилось.
    • 0
      А ну-ка с этого места поподробнее, я правильно понял, что участники могут периодически обмениваться «промежуточными» хэшами своих приватных данных, не раскрывая сам данные, чтобы потом любой мог повторить расчет противника и проверить, что вся обработка данных велась по правилам? Интересная идея.
      • 0
        Всё верно. Только это — идея реализации приложения, а не платформы т.е. об этом само приложение игры должно заботиться. Данные в этом примере для сети не важны — достаточно, что о них знают два «противника». А по результатам сверки «противники» публикуют результаты в сеть для всех т.к. от этих данных могут зависеть результаты вычислений других узлов (например статистика).
      • 0
        Ага, интересная. Можно пойти ещё дальше и скидывать зашифрованные закрытым ключом изменения состояний всех объектов в хранилище с таймстампом (по сути линейная, без ветвлений, версионность или даже просто логи событий) и потом предъявлять открытый ключ «администрации» для проверки. Как вариант сразу шифровать открытым ключом «администрации», чтобы они могли проверять корректность в реалтайме или близко к нему — мощности для обсчёта логов 1000 игроков нужны заведомо меньшие, чем для обсчёта их в режиме нормально игры (если пренебречь мощностями на дешифрование), как, например, на юнит-тесты модели нужны мощности меньшие, чем на функциональные тесты всего приложения.
  • 0
    Спасибо за статью. Обощение разрозненного материала уже немалая работа.
    Было бы неплохо продолжить собирать и систематезировать материалы по этой теме на хабре.

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

    По моим скромным представлениям, распределённые системы да хоть просто хранения, утяжелённые хорошей криптографией, будут иметь очень значительное время отклика. Это как-то решаемо?

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

      Криптография нужна далеко не везде, зачем, например шифровать открытый контент? Да и накладные расходы на неё не такие уж большие. https у вас сильно тормозит?

      Насчет Большого Брата — если сам сайт поддерживает работу с анонимными клиентами, то поддержка анонимности в такой сети — вообще не проблема, достаточно добавить несколько «перевалочных» анонимизирующих пиров в цепочку взаимодействия — и вот уже почти Tor или FreeNet. Можно просто в настройках клиента выставлять степень паранойи — 0 обычная работа без анонимизации, 10 — куча промежуточных пиров, все шифруется со страшной силой.
      • 0
        Даже если контетнт на близких пирах и не шифруется, пирам тем не менее нужно нас аутентифицировать, а чтобы это сделать надежно нужна третья доверенная сторона, вот и задержка. Оптимизации безусловно помогут, но с ростом распределённых аспектов сети (ДНС, сайты, поиск, маршрутизация, сертиффикация) отклик будет расти. Тоесть для критичных ко времени задач, наверное, схема значительной децентразации плохо применима.

        Под большим братом я понимаю человека посередине с возможностью контроля каналов и влияния на «третью доверенную сторону». История про железки, для органов, снифающие многомегабитные https потоки я надеюсь вам знакомы, потому что пруф я в 4 утра искать не возьмусь, лучше спать поду.
        • 0
          А зачем меня аутентифицировать? Если речь идет просто о раздаче открытых вещей, достаточно знать хэш фрагмента. Если речь о контенте с ограниченным доступом, то да, накладные расходы более заметны. Вот здесь я уже писал про компромисс между скоростью и безошибочностью, это как раз ответ и на часть вашего вопроса.

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

          Про железки для органов не слышал, пойду гуглить :)
        • +1
          Для задач, требовательных ко времени отклика, можно придумать решения. Смотреть нужно по конкретным требованиям. Разумеется, у каждого способа реализации есть свой потолок оптимизации. Если скорость действительно так важна (читал, что автоброкеры даже покупают сервера в стойках поближе к биржевым — для ускорения отклика путём уменьшения расстояния, которое нужно пройти сигналу физически, со скоростью света), то придётся что-то своё придумывать. Но, в таком случае, и любая другая неспециализированная технология не обеспечит вам нужного времени отклика. А для того, чтобы вам не приходилось ждать даже одну секунду при загрузке страницы, P2P со всеми авторизациями хватит.
  • +1
    Гораздо хуже обстоят дела с вычислениями. Мы не можем просто так позволить неизвестно кому манипулировать нашими данными на своей машине. Если шифрование позволяет хранить любую инфромацию где попало, не опасаясь за её конфиденциальность, а подписи и сертификаты дают возможность кому попало распространять нашу информацию, исключая возможность подделки, то обрабатывать и модифицировать эту информацию в зашифрованном и подписанном виде невозможно.

    Есть «гомоморфное шифрование», о котором можно почитать например в статье Брюса Шнайера Прорыв в гомоморфном шифровании<a/>.
    • 0
      Спасибо! Только пока это очень-очень отдаленная перспектива, насколько я понял. Но сама теоретическая возможность впечатляет.
  • 0
    Вот это не видели? Упоминается здесь.
    • 0
      Спасибо, гляну.
  • 0
    Вот еще три ссылки примерно на тему поста, но намного более многообещающе (все об одном: Ethereum):
    techcrunch.com/2015/08/01/vapor-no-more-ethereum-has-launched
    blog.ethereum.org/2015/06/21/ethereum-messaging-masses-including-fathers-via-infographic
    github.com/ethereum/wiki/wiki/White-Paper

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.