![[узлы к узлам]](https://habrastorage.org/getpro/habr/post_images/590/ffa/1d9/590ffa1d92f892c50c2c05afc343009c.png)
IPFS не совсем ещё сделалась хорошо известной технологией, даже в Кремниевой долине многим она ещё не известна, однако вести о ней быстро расходятся из уст в уста в сообществе открытого исходного кода. И многие рады потенциальным возможностям IPFS в области улучшения передачи файлов и ускорения потокового вещания их по Интернету.
С моей личной точки зрения, однако же, IPFS в действительности гораздо важнее этих возможностей. IPFS избавляет сайты от необходимости использовать центральный сервер-первоисточник и поэтому, вероятно, это наш лучший шанс полностью переменить архитектуру Интернета прежде, чем она развалится от внутренних противоречий.
Как и почему это? Для ответа на этот вопрос придётся вдаваться в подробности.
Почему наша Всемирная Паутина медленна, непрочна и забывчива
IPFS является новым p2p-гипермедийным протоколом, цель которого — дополнять собою (или даже, может быть, заменить) протокол передачи гипертекста (HTTP), сейчас господствующий в WWW. Вот в чём проблема HTTP: сегодня, когда вы посещаете сайт, ваш браузер должен напрямую связываться с серверами, на которых этот сайт работает, даже когда серверы эти далеко, а процесс передачи требует немалой пропускной способности.
Провайдеры несут расходы, потому что между сетями заключены пиринговые соглашения, так что пересылка данных из сети в сеть стоит денег провайдеру и расходует пропускную способность канала. Хуже того, файл по HTTP скачивается всего лишь с одного компьютера вместо того, чтобы одновременно получать части файла с разных компьютеров.
Вот почему и вот в каком положении дел мы застряли: медленный и дорогостоящий Интернет, цена которого ещё возрастает в силу хищничества провайдеров «последней мили» (по меньшей мере, в США), и с ускоряющимся ростом запросов на соединение с мобильных устройств. Он не просто медленный и дорогостоящий, но и ненадёжный. Если хотя бы одно звено
Переделываем Интернет посредством IPFS
IPFS (InterPlanetary File System, то есть межпланетную файловую систему: это название — дань памяти идеям
IPFS — это P2P-распределённая файловая система, стремящаяся соединить все вычислительные устройства одной общей системою файлов; как таковая, она способна превзойти возможности HTTP в нескольких отношениях. Из них два (как сообщил мне Хуан в недавнем разговоре) являются ключевыми:
«Мы используем контентную адресацию, поэтому контент приобретает независимость от серверов первоисточника и может храниться отдельно и долговременно. Это значит, что контент может храниться и раздаваться очень недалеко от потребителя — быть может, даже компьютером из той же самой комнаты. Контентная адресация также позволяет и проверять данные, полученные от других (не доверенных) хостов вместо первоисточника. А когда контент попадает на устройство пользователя, его там можно кэшировать сколько угодно».
IPFS также устраняет некоторые проблемы безопасности, досаждающие нашему основанному на HTTP Интернету: основанная на контенте адресация (и последующая верификация) защищает основанные на IPFS сайты, распределённость IPFS делает
Главнейшим же из достоинств IPFS служит децентрализованная раздача контента, так что к контенту из Интернета можно обращаться в обстоятельствах нерегулярного доступа к Интернету и даже брать его из оффлайнового кэша. «Мы создаём сайты
Появление альфа-версии IPFS в прошлом феврале ужe повлекло за собою множество экспериментов среди ранних восприёмников её (early adopters). Например, 8 сентября хостинг Neocities стал первым крупным сайтом, пользующимся IPFS для хранения контента, то есть последовавшим призыву Internet Archive о необходимости распределённого WWW. В настоящее время все мы претерпеваем непрестанную утрату всё новых и новых сайтов, год за годом покидаемых и закрываемых их создателями, и в этом нарастающем кризисе нашей коллективной интернетовской памяти для нас важен даже малый шаг в сторону перманентной Паутины.
А сайты, принадлежащие крупным корпорациям, последуют ли примеру Neocities, начнут ли внедрение ещё не полностью протестированного протокола — особенно когда даже простое упоминание P2P способно привести их в ужас? А вот тут я подхожу к последнему пункту статьи.
Почему IPFS весьма значим для будущего интернет-бизнесов
Как я разъясняю в моей новой книге (публикация которой ещё впереди), мы быстро приближаемся к той точке, за которою стоимость доставки контента опередит полезность — и финансовую выгоду. Крупнейшие компании Интернета ужe изо всех сил стараются не отстать от нашего спроса на контент, целые армии инженеров заняты одной этой задачею и в Akamai, и в Google, и в Amazon.
Скоро их положение ухудшится. Благодаря быстрой продаже дешёвых смартфонов в ближайшее десятилетие в онлайн выйдут целые континенты новых потребителей. Интернет Вещей также обещает усугубить эту проблему, ведь биллионы устройств с их собственными запросами приналягут на быстро истощающиеся возможности наших каналов связи.
Нам ужe до крайности необходимо ограничение того эффекта, который я называю микросингулярностью: быстрое «вирусное» привлечение пристального внимания биллионов пользователей Интернета к одному и том же событию угрожает удушить собою всю систему. (Перебои в работе сети теоретически угрожают и жизни, когда микросингулярностью становится катастрофа, авария или другое явление того же рода.)
Netflix недавно приступил к исследованию технологии крупномасштабного потокового
Улучшая связность, IPFS поможет Интернету становиться той системою, которою мы всегда стремились видеть его в наших идеализациях, но которой с нынешними протоколами стать он не мог: истинно способною соединить всех в мире (даже находящихся в оффлайне) перманентным, но постоянно развивающимся выражением того, кто мы такие и к чему мы стремимся.
Послесловие от переводчика
Хабрахабр — это даже не Кремниевая долина, так что и здесь, как можно предполагать, к началу октября 2015 года не все ещё читатели составили для себя достаточное представление об IPFS. Следовательно, окончив перевод статьи из TechCrunch, мне придётся также приложить к ней определённое разъясняющее послесловие; и прилагаю, облекая его в форму вопросов и ответов.
— Что такое IPFS?
— Распределённая файловая система с контентной адресацией.
— В каком смысле система IPFS является распределённою?
— В смысле P2P-файлообмена. Скачав файл, пользователь становится его источником для других скачивающих.
— В каком смысле система IPFS является файловой системою?
— В прямом: если ваша операционная система является юниксоподобною, то при помощи FUSE можно подключиться к IPFS таким способом, чтобы видеть файлы IPFS по адресу
— В каком смысле система IPFS является контентно-адресуемою?
— Хэш файла зависит только от содержимого файла. Если файл имеет другое имя или лежит в другом подкаталоге, то это всё равно тот же файл. (Это выгодно отличается, например, от битторрентовского хэша BTIH, который изменяется в зависимости от названия и взаимного расположения файлов.) Если тот же самый файл раздаётся под другим именем или в составе другого подкаталога, раздачи автоматически объединятся, не потребуется удвоение усилий, траффика, пространства на диске.
— Есть ли в файловой системе IPFS подкаталоги?
— Есть; это списки имён (и хэшей) файлов и подкаталогов. Например, для открытия адреса
— Как узлы IPFS знают, у каких из них есть желаемый файл?
— Используется DHT (наподобие Kademlia, но с большей устойчивостью
— Как сайт нынешней Всемирной Паутины может сослаться на файл, лежащий в распределённой файловой системе IPFS?
— Автор сайта ставит себе IPFS и кладёт файл в IPFS. Затем он записывает
— А читатели, у которых поддержка IPFS установлена?
— А у них появляется личный гейт из IPFS. Остаётся только поставить такое дополнение для Firefox или расширение для Chrome, которое будет «127.0.0.1:8080» автоматически подставлять вместо «ipfs.io» в таких URLах.
— Каким образом IPFS спасает в случае нарушений в работе сети?
— Если иллюстрации (и другие файлы) с самого начала публиковать не по сайтовому адресу, а в IPFS, то тогда, даже если сайт упадёт, читатель всё равно может получать файлы по известному адресу, только не из сайтового кэша IPFS, а из кэша у соседа. (И сосед не сможет подменить файл, потому что будет проверяться соответствие файла хэшу.)
— Каким образом IPFS помогает сайтам экономить траффик?
— Если иллюстрации (и другие файлы) с самого начала публиковать не по сайтовому адресу, а в IPFS, то тогда, даже если вдруг случится микросингулярность и на сайт очень быстро придёт биллион зрителей, всё равно бoльшая часть их будет по IPFS стучаться не на сайт, а в кэш своим соседям по биллиону, успевшим чуть раньше. Так что сайт не приляжет. (Конечно, для этого сперва среди зрителей должна распространиться мода на IPFS, а не то вместо сайта приляжет
— Каким образом IPFS помогает сайтам в случае гибели диска?
— Если иллюстрации и другие статические файлы с самого начала публиковать не по сайтовому адресу, а в IPFS, то тогда можно будет пропавшие картинки (и другие файлы) скачать по IPFS из кэшей читателей сайта в случае чего.
— Каким образом IPFS помогает читателям в случае государственной цензуры?
— Если иллюстрации и другие статические файлы с самого начала публиковать не по сайтовому адресу, а в IPFS, то тогда можно будет запрещённые иллюстрации (например, иллюстрации к ранобэ «???????») и другие запрещённые файлы получать по IPFS в обход блокировки (из кэшей читателей сайта, успевших получить файлы до вступления цензуры в силу).
He said: “I'd use #IPFS
To keep ????* off my ass.”
___
* Нарочито «кавайная» запись фамилии Е.Б.Мизулиной; сатира на её роль в #антианиме.
— Mithgol (@FidonetRunes) 14 сентября 2015— Каким образом IPFS помогает сайтам экономить дисковое пространство?
— Если иллюстрации с самого начала публиковать не по сайтовому адресу, а в IPFS, то тогда можно через некоторое разумное время стирать их из кэша IPFS, высвобождая пространство и надеясь на то, что иллюстрации продолжат быть доступными для читателей, которые просто будут в дальнейшем получать их из кэша IPFS друг у друга.
— То есть это реальная альтернатива для тех хостингов картинок и для имиджборд, которые сейчас действуют жёстко и после определённого времени просто стирают файлы невозвратно?
— Совершенно верно. (Я предлагал эту альтернативу на Иичане, например.)
— Есть ли прямо сейчас пример такого хостинга картинок, который складывает картинки в IPFS?
— Есть, ipfs.pics.
— Есть ли прямо сейчас пример такого хостинга произвольных файлов, который складывает их в IPFS?
—
— Означает ли контентная адресация, что в IPFS можно хранить только статический (неизменный) контент?
— В общем-то да. Впрочем, есть система имён IPNS для сайтов, позволяющая ставить каждому имени IPNS в соответствие свой хэш каталога IPFS, а затем по мере нужды изменять это соответствие. То есть выложить на такой сайт некоторое статическое содержимое, но новое.
— Может быть, придумать новую схему URLов для IPFS? Это позволит записывать их короче, чем длинноватый адрес
— Две недели обсуждали и решили остановиться
— Почему не сделали две раздельные схемы «ipfs:» и «ipns:»?
— Для удобства пользователей юниксоподобных систем, которым теперь достаточно стереть
— Будут ли адреса «fs:» поддерживаться в гипертекстовом Фидонете?
— Будут; для этого достаточно трёх строк на языке ECMAScript 6. Вот пример фидонетовской блогозаписи, сперва снабжённой иллюстрацией из IPFS, а затем транслированной по RSS в LiveJournal.
— Можно ли добавить поддержку открытия
Можно:
GroupURL IPFS
URLEngine PCRE
URLScheme /ipfs/[1-9A-HJ-NP-Za-km-z]+
URLHandler start "" "https://ipfs.io@url"
EndGroupURL
— Работает ли IPFS под Windows?
Нынешняя альфа-версия под Windows работает довольно скверно, но предыдущая вообще переставала запускаться, так что можно надеяться на дальнейшее улучшение положения дел в будущем, и надеюсь.
Комментарии (83)
Meklon
05.10.2015 18:41+3Спасибо. Интересная альтернатива чистому p2p интернету, в котором будет работать только статика нормально. В этом варианте можно использовать смешанное содержимое, которое позволит снять часть нагрузки.
kahi4
05.10.2015 19:45+3— Хэш файла зависит только от содержимого файла. Если файл имеет другое имя или лежит в другом подкаталоге, то это всё равно тот же файл. (Это выгодно отличается, например, от битторрентовского хэша BTIH, который изменяется в зависимости от названия и взаимного расположения файлов.) Если тот же самый файл раздаётся под другим именем или в составе другого подкаталога, раздачи автоматически объединятся, не потребуется удвоение усилий, траффика, пространства на диске.
Я немного совершенно не понял — как они собираются бороться с коллизиями?так и вижу, как на серьезном сайте вместо фотографии крупного директора загружается пони или котики или что по-хуже потому что коллизия
Bal
05.10.2015 20:04+1Там очень большие хеши. Боюсь, что вероятность коллизии будет много ниже вероятности того, что, например, упомянутого крупного диктора просто собьет машина на улице…
el777
06.10.2015 19:12Тем не менее вероятность !=0.
Случайно может будут редкие совпадения. Но с теми же хешами есть разные варианты атак, поэтому важна криптостойкость, а не только длина.
PsyHaSTe
08.10.2015 17:28В таком случае вам не рекомендуется использовать гуиды во всех проявлениях.
el777
08.10.2015 18:29Кто-то использует guid как криптоподпись?
PsyHaSTe
09.10.2015 01:23Как ID в распределенной системе — легко. А к чему может привести коллизия уникальных идентификаторов — кто знает, от простой пропажи одной записи в БД до отказа в обслуживании и сливания всей инфы на сторону.
el777
09.10.2015 09:25Как id — понятно.
А вот как подпись?
Во, т кстати, совсем скоро увидим коллизиии — habrahabr.ru/post/268495
То есть подменить файл и чисто количественно задавить раздачу вполне реально.
Но еще лучше подменить адреса машин, откуда узлы должны узнавать друг про друга — т.е. просто развалить сеть на части.
Mithgol
09.10.2015 10:25На всякий случай сообщаю, что по адресу
http://habrahabr.ru/post/268495/ речь идёт о поиске коллизийв SHA-1, тогда как IPFS,во-первых, использует более современныйхэш SHA-2, а во-вторых, употребляет вокруг него такую обёртку (в видемультихэша), которая позволит в случае необходимости перейти (по общему согласию) от употребленияSHA-2 к употреблению ещё более современного хэша, вовсе не трогая остальную логику работы системы(и, весьма вероятно, с некоторым переходным периодом, когда оба хэша будут приниматься к употреблению, но только более новый будет создаваться для дальнейшего употребления).
icCE
05.10.2015 19:52+1Получается при заходе на страницу я ее буду качать и хранить у себя как некий кэш, который у меня потом могут взять другие или файл. OK
Что делать если у меня мало место?
При изменении динамики, насколько быстро распространится изменения.
Будет ли полная перекачка файла или только изменения файла?
Как распределяются права к файлам? Можно ли сделать больше одного человека, который имеет RW права на папку?
Как быть, если кто-то удалил все файлы в каталоге или сам каталог?
Как быть с коллизиями?Bal
05.10.2015 20:08+1Если Вы простой посетитель с одним только браузером, то Вы просто скачаете картинку через гейт по обычному http.
Чтобы получить p2p, нужно ставить локальный софт. Очевидно, что настройки объема локального хранилища там должны быть.
Mithgol
05.10.2015 21:58+1Мало места — мало кэша.
Изменения динамики распространяются по мере повторных заходов.
Будет полная перекачка файла.
Никто не имеет RW-права на папку, потому что по факту там WORM: изменённые файлы и папки рассматриваются как новые.
Коллизий нет.
lair
06.10.2015 00:12+4Коллизий нет.
Это невозможно. Коллизии могут быть маловероятными, но совсем исключить вы их не можете.Mithgol
06.10.2015 16:48Там хэшем служит
SHA2-256, то есть, как я понимаю,32-байтовое (256-битовое) число.
Вероятность коллизий ничтожна (что-то порядка квадратного корняиз 10?77, если я это правильно понимаю), так что я не верю, что они есть.lair
06.10.2015 17:02Вероятность коллизии в 0.5 достигается после 4 ? 1038 файлов (да здравствует «парадокс» дней рождений). Называть это ничтожным я бы не стал.
Mithgol
06.10.2015 17:34Ну да, именно из-за парадокса дней рождений я и заговорил именно о квадратном корне.
А что касается 4?1038(2128) файлов, то это очень много. Рассудим теоретически:
- для записи одного из двух различных файлов достаточно однобитной длины,
- длина файла от одного до двух битов позволяет записать один из 21+2? различных файлов,
- длина файла от одного до трёх битов позволяет записать один из 21+2?+2? различных файлов,
так что если у нас есть 2128 различных файлов, то их длина варьируется (по меньшей мере) от битадо 264 битов, причём файловразмером 264 битов около половины, так что и средняя длинагде-то там.
Следовательно, суммарный размер этих файлов —что-то около 2128?264 битов = 2192 битов = 2189 байтов = 2179 килобайтов = 2169 мегабайтов = 2159 гигабайтов = 2149 терабайтов = 2139 петабайтов = 2129 эксабайтов = 2119 зеттабайтов = 2109 иоттабайтов… дальше понятно.Mithgol
06.10.2015 17:42Хотя нет, что это я несу. Последние два абзаца предыдущего рассуждения на самом деле должны были быть вот какими:
…так что если у нас есть 2128 различных файлов, то их длина варьируется (по меньшей мере) от битадо 64 битов, причём файловразмером 64 бита (26 битов) около половины, так что и средняя длинагде-то там.
Следовательно, суммарный размер этих файлов —что-то около 2128?26 битов = 2134 битов = 2131 байтов = 2121 килобайтов = 2111 мегабайтов = 2101 гигабайтов = 291 терабайтов = 281 петабайтов = 271 эксабайтов = 261 зеттабайтов = 251 иоттабайтов… дальше понятно.
- для записи одного из двух различных файлов достаточно однобитной длины,
icCE
06.10.2015 01:08Ну тогда тут вопрос спорный, зачем оно надо. Гложут сомнения что это взлетит.
ZoomLS
06.10.2015 03:02+1Минимум — защита от цензуры.
Areso
06.10.2015 06:56+1Насчет цензуры есть несколько вопросов. Протокол ведь будет отдавать IP адреса всех, у кого есть этот контент? Всех можно и взять будет (до кого дотянутся) за распространение. И второе, про гейт. Гейт отдает только IP адреса централизованно?
icCE
06.10.2015 11:59Для этого лучше подходят мех сети и я думаю лучше их развивать. Например Cjdns. hyperboria.net
Foxcool
06.10.2015 16:33+1Имхо, одно другому не мешает. Кеширование статики может работать как поверх обычного интернете так и поверх CJDNS — ведь она по сути придоставляет IPv6. Параноики могут раздавать кеш только через интерфейс tun от cjdns. В идеале бы людям, которые способны установить одно, ставить и другое, но для того как раз раскручивание на хабре. Надеюсь, когда тут был цикл статей о меш сетях, многие не поленились и поставили ноду (тем более под убунту это ставится из пакетов). Я еще купил и прошил роутер под это дело и жду соседей (:
vvnab
06.10.2015 10:10+1Никаких изменений. Любое изменение = новый файл.
Kain_Haart
08.10.2015 12:51почему вы так считаете?
Bal
12.10.2015 18:01Потому что идентификатор файла в IPFS — его содержимое. Это, кстати, позволяет более эффективно использовать популярные файлы, они хранятся только один раз в кеше.
Kain_Haart
12.10.2015 19:27Хранятся не файлы, хранятся блоки, которые могут быть реиспользованы в различных версиях файла:
IPFS files can be represented by both lists and blobs
Kain_Haart
08.10.2015 12:50Как я понял, используется «Git Merkle DAG 2 object model» и при изменении файла будет скачивание только изменений, а не всего нового файла.
Bal
05.10.2015 20:02+4Присматривался к ipfs для раздачи статики на своем сайте. Остановило неумение раздавать целые каталоги прямо с диска. Т.е. мне для раздачи нужно каждый файл залить в локальное хранилище ipfs и по факту имеет две копии: одна копия в обычной fs (ибо ipfs не обеспечивает весь локальный функционал), вторая — в ipfs. Когда файлов — сотни гигабайт, такое дублирование становится расточительным и бессмысленным :—/
А в остальном система очень понравилась. Ещё бы чисто браузерную реализацию (js, webrtc), чтобы простой юзер мог бы качать минуя гейт, но при этом не устанавливая дополнительный софт, цены б ей не было :)
ivlis
05.10.2015 20:24+1А что мне мешает на гигабитном канале сделать dd if=/dev/urandom of=/ipfs/flood_file bs=1G count=1000000 и уложить всю сеть?
Bal
05.10.2015 20:44+3А кто будет ЭТО качать? p2p — это не когда тебе подсовывают всё, что не нужно. Это когда ты у других берёшь то, что нужно.
ivlis
05.10.2015 20:53+1Так если оно не дублицируется, тогда зачем нужно. Ну и атаку на хештаблицу можно устроить так же.
Bal
05.10.2015 21:17+3ipfs — это не распределённое хранилище. Это распределённый транспортный протокол с попутным кешированием. p2p-транспорты не менее, а скорее более востребованы, чем [анонимные] p2p-хранилища.
icCE
06.10.2015 01:12+4Ну и получим мы в итоге, что будет кэш только самого популярного и востребованного. Мы это и наблюдаем в текущий реализации торрентов, когда нужно скачать что-то и сидишь ждешь когда появится кто-то у кого оно есть.
Но подход понятен, это как у MS с обновлениями по P2P, хочешь не хочешь а будишь раздавать.
ValdikSS
08.10.2015 12:57О-о-о, т.е. это совершенно не замена тому же tahoe-lafs?
Bal
12.10.2015 18:03Нет. Tahoe — это хранилище. IPFS — транспорт (хотя и с локальным кеш-хранилищем, но не распределённым, как tahoe). В принципе, они могут быть хоть совмещены. tahoe как средство распределённого хранения, а ipfs — транспорт для передачи клиенту (не требующий, в отличие от tahoe установки клиента)
mdevils
05.10.2015 20:28+5Все хорошо в этом переводе, кроме стилистики, которая забирает на себя больше внимания, чем следовало бы.
remal
05.10.2015 22:11+6Мне казалось или в p2p сетях обычно долгое ожидание начала загрузки? Если они не решат эту проблему, то протокол уже мертв.
Экономия трафика — прекрасно, но не в ущерб скорости загрузки.
TimsTims
06.10.2015 10:42+8+1
Пока дождешься установления соединения, потеряется всякий интерес к старнице.
Многие исследования говорят, что если веб-страница не загрузилась за 3-5секунд, то среднестатистический пользователь её закрывает.
Протокол уже мертв.
Про кэширование на устройстве: ну незнаю, насколько это хорошая идея, ведь есть сайты, на которых контент меняется очень-очень часто — всякие чаты, доски обновлений, популярные форумы. Кэширование будет создавать эффект, что на этом сайте ничего не происходит, выдвигаемый контент будет опаздывать, итд итп. Да, сайт может поставить какой-нибудь псевдо-флаг «не кэшировать», но тогда теряется вся суть «СПАСИТЕЛЯ ИНТЕРНЕТА». Я молчу про то, больше половины пользователй интернета сидят с телефонов и планшетов.
Насчет Ддос: всю тяжесть ддосов будут нести не владельцы сайтов, а пользователи, на которых схэшировалось довольно много файлов. Если у пользователя узкий канал, или он играет в онлайн игры, или у него нет SSD, то всё для него будет весьма печально- страницы будут загружаться медленнее из-за высокой отдачи, онлайн-игры будут лагать и вырастут пинги, если всё у пользователя крутится на одном HDD то о нормальной работе на ПК можно забыть — HDD будет постоянно занят, снижая свою производительность, т.е. все программы будут запускаться гораздо дольше.
«И всё ради чего?» -спросит себя пользователь, и снесет всю эту лабуду, чтобы нормально пользоваться СВОИМ компьютером, а не для того, чтобы всякие владельцы сайтов снижали с себя расходы.Kain_Haart
08.10.2015 12:58Кэшироваться с адресацией по контенту будет только статика. Для изменяемых частей сайта используется адресация через ipns
Kain_Haart
08.10.2015 13:00+1Полагаю, что реализация ноды будет позволять настроить количество используемых ресурсов, а не как вы предположили, отбирать у пользователся всю производительность его компьютера
Bal
06.10.2015 19:46+1ipfs интересен тем, что в нём реально получается небольшое время ожидания. Что-то типа tor. Не сравнить с i2p или freenet/gnunet.
И речь именно о холодном ожидании. Как закачалось в кеш — отдаётся мгновенно.
Master255
07.10.2015 00:34-1Я изучал причины задержки p2p протоколов на примере nmdc и пришёл к выводу, что причины в плохой реализации. Если использовать более продуманный протокол, то задержки будут минимальны, если вообще будут.
Например, есть способ вообще гарантированно увеличить скорость передачи данных, а не вносить задержки. Но это зависит от реализации. Проще говоря — тут надо не думать, а делать.
remal
07.10.2015 21:42Задежки уровня tor подойдут только для видео. Для картинок они уже будут слишком большими.
Bal
12.10.2015 18:07Если быть совсем точным, то задержки _холодных_ данных в ipfs сравнимы с задержкой _горячих_ данных в tor. Горячие же данные в ipfs отдаются с обычной для web'а скорость. Ну, вот, чтобы не быть голословным, залитая мной картиночка в ipfs: gateway.ipfs.io/ipfs/QmTUeRKutKfbTRmoXsgRTv4r9zKJyFVrX3NVLQctRmoa1v
lockywolf
05.10.2015 23:49+3Всё-таки неплохо было бы перечитывать перед публикацией. Биллион — это миллиард, да и ещё мелочи цепляют глаз.
По теме же, кажется, время этой системы ушло, не наступив. Кэширование на локальной машине — это неплохо, но в связи со всё уменьшающейся «толщиной» юзерских машин, кажется, не случится.
Могу понять мечту об анархизме, но без скоростных И дальнобойных каналов «точка-точка» никакого анархизма не случится. А как пропустить через радиоэфир гигабиты — не представляю.
Mox
06.10.2015 00:00Нужно придумать все таки систему управления правами и авторством. Иначе это никак не поможет ютубу тому же.
Master255
06.10.2015 00:44-5Украли мою технологию Peering cloud :-) Я подошёл немного с более приземлённого решения использовать nmdc протокол и его хабы. В дальнейшей перспективе — это так же превратиться в протокол передачи данных. А сегодня это помогает мне раздавать статику. Исходный код здесь: https://github.com/master255/ImmortalPlayer
Рабочая программа здесь: https://play.google.com/store/apps/details?id=com.medialibrary.mycollection
Должен заметить, эта технология может совместно сосуществовать с другой моей очень обсуждаемой (http://habrahabr.ru/post/267329/) технологией DoubleDomain.
stagnantice
06.10.2015 12:22Интересная вещь, возможно найдет свое место в корпоративных сетях, но вот в качестве замены интернету нет.
Тут уже писали, про то, что есть коллизии… Теоретически я могу насоздавать у себя кучу файлов с текстами этих хешей… и тогда мне не нужно будет кого то там DDOS ить, вирус люди скачают себе сами.
Возможно эта штука будет полезна для больших сетей, раздающих контент, таких как youtube, vk. Если все большие контент хранилища перейдут на этот протокол, то возможно интернет уже почувствует облегчение. От пользователя к пользователю — это долго, не безопасно и не нужно, есть торрент в конце концов.Mithgol
06.10.2015 13:38+1Попробую объяснить на примере.
Допустим, что по хэшу«QmQZB43ePCwDsow74gehT8v74M2tKtTs9FCbH4wpoUksfF» находится текстовый файл, состоящий из единственного слoва «Хабрахабр» (в UTF-8 с сигнатурою).
Внимание, вопрос: сколько лет придётся работать над достижением цели «вирус люди скачают себе сами» (то есть над достижением коллизии), если строка «QmQZB43ePCwDsow74gehT8v74M2tKtTs9FCbH4wpoUksfF» состоит из 46 символов в формате base58, являющихся мультихэш-обёрткою вокругSHA2-256? Mithgol
06.10.2015 13:50Прибавлю, что хэши SHA-256 используются и в Bitcoin, так что, если бы коллизии и впрямь были такой проблемою, то сперва их первооткрыватели немало озолотились бы, а затем биткоины резко обесценились бы. Мы не видим ни того, ни другого.
icCE
06.10.2015 14:17Вопрос времени и необходимости. Мир уже не один раз проходил стадию, вот мы сделаем и теперь точно хватит на всегда!
lair
06.10.2015 14:52+2Вопрос вычислительной сложности. Сейчас, если я ничего не путаю найти коллизию в SHA-256 можно за 265 операций, но это просто коллизия. Семантическая коллизия (т.е., подбор такого исходника, который выполняет нужную вам функцию, и который бы совпадал по хэшу с другим исходником, выполняющим другую нужную вам функцию) не факт, что вообще возможна.
Mithgol
06.10.2015 16:32Понятно, что конкретный хэш
(SHA-256) не навсегда. В том числе поэтому существует обёртка в форме мультихэша, которая позволит в случае чего перейти к употреблению другого конкретного хэша в IPFS, не трогая ничего более в логике работы файлообмена.stagnantice
08.10.2015 20:53Вот я создам 2^65 файлов (сейчас вряд ли, но когда нибудь в будущем) где будет строка s = 'Уникальный хеш'. То есть получается я переберу все варианты из 2^65. (Хеш в исходнике может не совпадать с хешем самого файла). Ну даже если не 2^65, а меньше… все равно будет вероятность, что мой код будут считать за другой файл.
Mithgol
09.10.2015 10:40Это замечание по сути верно, но по формулировке не совершенно справедливо, так что я выскажу к нему две поправки.
Во-первых, хэшSHA-256 является (насколько я его понимаю)256-битным, так что вместо265 файлов понадобится2256 файлов, а это гораздо больше.
Во-вторых, как упоминалосьнесколько выше, даже для хранения2128 различных файлов потребуется?251 иоттабайтов, то есть не менее квадриллиона иоттабайтов.
(Это для хранения, но задача их генерации также никак не может быть названа простейшею.)
Kain_Haart
09.10.2015 12:34Так, для сравнения, оценка количества атомов во вселенной ?1080,
а 2256 всего на три порядка меньшеstagnantice
09.10.2015 12:42Ну в статье приводится вполне конкретный хеш:
QmcXx5mKDQAc7tCWLq84Hn7XFxWfBdZpvogJk3tNXQRFiv
вот и возник такой вопрос.Mithgol
09.10.2015 14:21Этот хэш состоит из сорока шести пятидесятивосьмеричных цифр.
Kain_Haart
08.10.2015 13:05Файлы передаются блоками от разных пользователей
stagnantice
08.10.2015 20:54ну у блока тоже есть какой то размер, вполне вероятно что мой файл скачают сразу весь и от меня.
sebres
06.10.2015 15:16Вот ведь копирайтеры-то обрадуются: каждый «клиент» в таком p2p-интернете есть распространитель контента — это просто подарок им: «письма счастья — в каждый дом».
Законодательно исключить такой p2p-интернет, чтобы логика не попадала под распространение с нарушением авторского права (aka copyright law, Urheberrechtsgesetz и иже с ними) — та еще проблема, имхо.
По крайней мере в известных своей бюрократией странах.
Где-то читал около-юридическую статью на похожую тему — реально обсуждалась идея с хранением origin. Чтобы значит копирайтера туда отправлять. Про-то как технически реализовать такой бред… лучше не здесь, а то сильно толсто получится.Mithgol
06.10.2015 17:48Думаю, что лессиговский принцип «code is law» будет действовать, то есть трудновато будет в связи с появлением новой программы буквально каждого читателя Сети бросить за решётку или штрафовать (сейчас провайдеров не сажают же и не штрафуют за распространение, например).
sebres
06.10.2015 18:25К сожалению, вы не правы, и во многих странах уже несколько лет как штрафуют, поэтому пользоватся p2p (тот же торрент) ой как небезопасно для собственного кармана.
А штрафы кстати не маленькие: ~ 800 за фильм или ~ 300 за песню (в вечнорастущих).
К тому же право как правило прецедентное или близко к тому, то есть судья и не силно долго разбирается, и если просто из принципа попробовать все же в суде, еще и все судебные издержки в случае очень вероятной неудачи оплачивать.
А провайдер вообще не причем, он просто тупо сливает (ибо обязан) домашний адрес «распростронителя» по IP+timestamp адвокату «потерпевшей» стороны, по предьявлению им прокурорской авизо.
И это например в тех же Европах поставлено на поток, т.е. дело нескольких минут.Master255
06.10.2015 23:52а есть ли прув на пример такого дела из-за торрент раздачи? И как можно систематизировано проверять торрент раздачи, если файлы раздаются частями, ссылки на эти файлы находятся на каких-то не понятных форумах, а в раздаче попеременно участвуют сотни ip адресов.
Что, неужели на поток поставили отслеживание всех торрент трекеров в интернете???
Если да, то как :-)?
Что с другими п2п сетями? Например dc++? Там вроде всегда было больше контента, чем в торрентах.sebres
07.10.2015 13:22Прувов в сети немерено, гуглить по Abmahnung Filesharing «Urheberrechte verletzt» (это если на немецком например).
Без разницы, какая p2p сеть — filesharing есть filesharing.
По поводу остального как-то отвечал уже на хабре. Но с тех пор все гораздо хуже (строже).
Foxcool
07.10.2015 15:30-2я уже не раз говорил, что введение подобных фич в странах типо нашей просто приведет к тому, что в торрент-клиент будут встраивать тот же CJDNS или тор. Т.е. активно внедряться механизмы скрытия своего адреса. Если в Европе в контексте данной ситуации мораль рабов выигрывает (проще заплатить за каждую лицензию не по разу, чем заморачиваться), то у нас после девальвацией уже есть резон вникнуть и установить.
CJDNS вообще отлично получается — скорость максимальная, нет специального прогона трафика где-попало, но при этом бегать по цепочке нод ради каждого раздающего, чтобы найти его обычный айпишник — нафиг кому-то надо. Особенно если этот умник еще и счастливчик, и у него часть трафика ходит через реальным меш!
lybin
11.10.2015 19:03+1— Есть ли прямо сейчас пример такого хостинга произвольных файлов, который складывает их в IPFS?
— Есть, ipfs.stadja.net/upload
Уже нет :D fucking russians :D :D
guai
12.10.2015 15:51+1А что с провайдерами будет? Сейчас, наверняка, есть некие оптимизации. Юзеры обычно отдают мало, качают много, причем основной траффик известно с каких сайтов. А тут появится куча траффика там, где отродясь не водилось. Ну, если появится, конечно, если взлетит.
Mithgol
13.10.2015 08:12Провайдерам регионального уровня это будет выгодно, потому что больше траффика будет переходить в локалку из глобалки, так что меньше придётся тратиться на доступ к магистральному каналу. (Пример 2010 года:
решение ОАО «ЮТК» о бесплатном и обязательном безлимите между абонентами Краснодарского края, принятое силою моего убеждения.)
ragequit
Я уже боялся, что про г-т фидонет ничего не будет.
Mithgol
В конце блогозаписи про юбилей Фидонета былтизер-трейлер про внедрение IPFS в Фидонете, так что вот теперь я раскрыл ту тему, на которую тогда намекал.
maxp
Несомненно, ключевым аргументом ipfs в статье смотрится фрагмент конфига Голого Деда. Куда же сейчас без него!
При всем моем уважении, упоминанине Фидонета в подобных случаях выглядит как проявление некоей латентной некрофилии. Сильно плохого в этом ничего нет, однако, рецидивы настораживают.
Искренне ваш,
ex. 2:5070/44
Mithgol
Это не некрофилия, потому что Фидонет в известной мере жив. Жизнь эта будет нарастать в нём.