LINUX.ORG.RU

IPFS 0.4.18

 , , ,


5

5

Состоялся релиз go-ipfs (эталонной реализации IPFS, написанной на языке Go) версии 0.4.18. Вероятно, это самый значительный релиз в недавней истории; на его подготовку ушло 3 месяца. Со времени предыдущей новости об IPFS на LOR прошло уже более четырёх лет.

IPFS (InterPlanetary File System) — это гипермедийный протокол и распределённая файловая система, созданная с использованием идей, реализованных в Git и BitTorrent, и нацеленная на то, чтобы заменить или дополнить существующий Web. IPFS похож на BitTorrent Swarm, ноды которого обмениваются объектами Git-репозитория. IPFS основан на идее адресации по содержимому — один и тот же блок данных всегда будет иметь один и тот же адрес, вне зависимости от его физического расположения. В отличие от BitTorrent, данные разбиваются на блоки по границе файла, таким образом один и тот же файл может быть переиспользован в разных каталогах без необходимости повторного выделения места на диске. В отличие от Freenet и Perfect Dark, ноды хранят только те данные, которые они явно запросили. IPFS способен интегрироваться с существующими системами разрешения имён — с классическим DNS в настоящее время, с Tor .onion, Namecoin .bit и возможно, некоторыми другими в будущем.

Особенности этого релиза:

Титульные особенности этого релиза — экспериментальная поддержка QUIC, новый алгоритм маршрутизации pubsub-сообщений, возможность подписывания pubsub-сообщений, а также переписанная команда ipfs p2p. Однако всё это лишь вершина айсберга.

QUIC

Прежде всего, со стороны сетевой подсистемы, в этом релизе представлена экспериментальная поддержка протокола QUIC. QUIC — это новый сетевой транспорт, основанный на UDP, который решает много давних проблем, связанных с применением TCP.

Для IPFS это означает (наконец-то):

  • Меньшее потребление системных ресурсов. TCP требует по файловому дескриптору на каждое соединение, в то время как QUIC (и большинство других основанных на UDP транспортов) могут разделять один файловый дескриптор между всеми соединениями. Это может позволить IPFS открывать соединения быстрее и поддерживать больше открытых соединений.
  • Ускоренное установление соединения. Когда аутентификация клиента активирована, QUIC выполняет трёхсторонее согласование подобно TCP. Однако, в отличие от TCP, этот способ согласования с самого начала обеспечивает полностью зашифрованное, аутентифицированное и мультиплексированное соединение. В теории (пока что ещё не на практике), это должно значительно снизить задержки при DHT-запросах.
  • Улучшенная работа на соединениях с потерями пакетов. При мультиплексировании некоторого числа запросов через единственное TCP-соединение, всего один потерянный пакет заставит всё соединение (и все передаваемые через него запросы) ожидать, пока этот пакет будет передан заново. Однако, в силу того, что QUIC осуществляет мультиплексирование внутри себя, потеря единичных пакетов затронет только соответствующий поток.
  • Улучшенное прохождение NAT. В двух словах: пробивание NAT значительно более простое и, во многих случаях, более надёжное с использованием UDP, нежели с TCP.

Однако всё ещё есть к чему стремиться. Хоть разработчики IPFS и поощряют пользователей попробовать его уже сейчас, развиваемый IETF протокол QUIC всё ещё находится в стадии активной разработки и будет меняться. Вы можете найти инструкции по его активации в IPFS здесь.

Pubsub

С точки зрения модели «pubsub», go-ipfs теперь поддерживает алгоритм маршрутизации «gossipsub» и подписывание сообщений.

Алгоритм маршрутизации «gossipsub» значительно более эффективен, чем текущий алгоритм «floodsub». И более того, он полностью обратно совместим — таким образом, вы можете активировать его и по-прежему взаимодействовать с нодами, которые используют алготирм «floodsub». Вы можете найти инструкции по активации «gossipsub» в go-ipfs здесь.

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

Команды

В части новых инструментов, в этом релизе представлены новая подкоманда ipfs cid, предназначенная для обработки идентификаторов содержимого (Content ID, CID), полностью переписанная команда ipfs p2p, потоковое разрешение имён, а также завершённая поддерджка inline-блоков.

Новая команда ipfs cid позволяет пользователям изучать новые CID и конвертировать их в различные форматы разных версий. Например:

# Вывести метаданные CID (с префиксом)
$ ipfs cid format -f %P QmT78zSuBmuS4z925WZfrqQ1qHaJ56DQaTfyMUF7F8ff5o
cidv0-protobuf-sha2-256-32

# Получить хэш sha256 в шестнадцетиричном формате из CID
$ ipfs cid format -b base16 -f '0x%D' QmT78zSuBmuS4z925WZfrqQ1qHaJ56DQaTfyMUF7F8ff5o
0x46d44814b9c5af141c3aaab7c05dc5e844ead5f91f12858b021eba45768b4c0e

# Сконвертировать CID v0 формата base58 в CID v1 формата base32
$ ipfs cid base32 QmT78zSuBmuS4z925WZfrqQ1qHaJ56DQaTfyMUF7F8ff5o
bafybeicg2rebjoofv4kbyovkw7af3rpiitvnl6i7ckcywaq6xjcxnc2mby


Переработанная команда ipfs p2p позволяет перенаправлять TCP-потоки через две IPFS-ноды от одного хоста к другому. Это такой ssh -L, только для IPFS. Вы можете найти документацию здесь.

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

  • IPFS не прекращает прослушивание локальных (перенаправленных) соединений после открытия единичного соединения.
  • Вывод команды ipfs p2p stream ls теперь содержит более полезную информацию. Первый выводимый адрес — это всегда адрес инициатора соединения.
  • Команда ipfs p2p listener ls переименована в ipfs p2p ls
  • Команда ipfs p2p listener close переименована в ipfs p2p close.
  • Имена протоколов предваряются префиксом /x/, и теперь просто передаются libp2p в качестве имени обработчика. Предыдущие версии делали это незаметно для пользователя и с префиксом /p2p/. Теперь есть флаг --allow-custom-protocol, который позволяет использовать любое имя обработчика из libp2p.
  • Команды ipfs p2p listener open и ipfs p2p stream dial переименованы:
    • ipfs p2p listener open p2p-test /ip4/127.0.0.1/tcp/10101 теперь становится ipfs p2p listen /x/p2p-test /ip4/127.0.0.1/tcp/10101
    • ipfs p2p stream dial $NODE_A_PEERID p2p-test /ip4/127.0.0.1/tcp/10102 теперь ipfs p2p forward /x/p2p-test /ip4/127.0.0.1/tcp/10102 /ipfs/$NODE_A_PEERID.

Текст новости слишком объёмный, продолжение в последующих сообщениях...

>>> Официальный сайт

>>> Каталог приложений, созданных на основе IPFS

>>> Дополнение для интеграции IPFS в веб-браузеры

>>> Подробности и полный список изменений

anonymous

Проверено: Shaman007 ()
Последнее исправление: tailgunner (всего исправлений: 2)

Ответ на: комментарий от anonymous

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

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

MrClon ★★★★★
()
Ответ на: комментарий от Einstok_Fair

В ретрошаре тоже файлы по хешу идентифицируются, в чём разница?

В IPFS не нужно искать френдов, чтобы качать файлы. Они могут быть где угодно и у кого угодно. Но зато IPFS не обеспечивает сокрытие источника файла. Но, опять же, зато IPFS на порядки быстрее, чем RS. В общем, у них сильно разные задачи. RS — для анонимной раздачи пиратских копий. IPFS — для всего остального :)

KRoN73 ★★★★★
()
Ответ на: комментарий от MrClon

Да, только я так и не придумал как использовать эту штуку пока нет поддержки в браузерах.

Я хочу использовать для распределённых систем. В первую очередь для форумных аттачей. Сейчас, если больше одной ноды, после постинга аттача нужно одновременно с распространением поста по другим нодам ещё и файлы тащить. Что усложняет процесс, утяжеляет репозитории и т.п. А тут можно на одной ноде сразу аттач в IPFS и в посте только хеш отправлять. А на приёмных нодах показывать через ближайший гейт :) Очень удобно получается.

Если б только не этот жор :)



А, ещё местечковый минус, но тоже связанный с IPFS. IPFS очень нагло и агрессивно ведёт себя в локалке. Шпарит по всем возможным адресам и подсетям в поисках других узлов. И на том же Хетцнере мгновенно срабатывает абуз и, часто, быстрая блокировка «за сканирование сети с, возможно, хакерскими целями».

Эта же фигня сильно вредит ipfs-кластеру на сложных системах. Если у меня на машине несколько десятков сетевых интерфейсов (контейнеры разные), то нода кластера пытается разослать по кластеру все доступные IP. И другие ноды начинают потом стучать по этим десяткам недоступных для них интранет-адресов. И падают, нафиг, с таймаутами, не пройдя выборы. Типа, запустил всё, кластер красиво собрался, полчаса проходит — всё упало и развалилось :) Про это им в issues ругаются уже полгода, а воз и ныне там. Я у себя решил брутально, указанием подниматься каждый раз при падении демона в systemd. Тогда узлы периодически падают, пока не словят устойчивую комбинацию, так и начинают работать :)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Может ты в курсе: локальная нода и гейты умеют (или будет уметь) в httpшные range запросы. Или только выкачивать весь файл целиком? Мне для видео надо. Бить его на чаники дико лениво

MrClon ★★★★★
()
Ответ на: комментарий от MrClon

Может ты в курсе

Не знаю. Но когда фильм начинаешь смотреть через гейт, он начинает показываться раньше, чем весь на гейт выкачается. Т.е. налицо, как минимум, стриминг :)

KRoN73 ★★★★★
()
Ответ на: комментарий от hobbit

кстати,я про QUIC прочитал и вспомнил сагу про ftp и fsp - fsp реально на модемах мог скачать там (без докачек!) где ftp пасовал!

история повторяется ))

mumpster ★★★★★
()
Ответ на: комментарий от KRoN73

До того, как будет доступна возможность нативного использования адресов вида ipfs://, рассматривается вариант с чем-то вроде CID.ipfs.localhost, и ещё один с изменением настроек прокси (https://github.com/ipfs/in-web-browsers/issues/109). Правда, работоспособность первого подхода зависит от настроек nsswitch.conf и используемого DNS-резолвера...

anonymous
()
Ответ на: комментарий от commagray

Абсолютно нужно. Хорошая новость, отличный релиз.

нафига?

anonymous
()

вот это интересно

DILIN ★★★★★
()
Ответ на: комментарий от anonymous

. скорость была слишком медленной из-за особенностей TCP,

Все знают, что TCP - это прошлый век

kto_tama ★★★★★
()
Ответ на: комментарий от KRoN73

Раздаю PAC-скрипты сервиса https://antizapret.prostovpn.org/ через Cloudflare-гейт IPFS уже какое-то время. Версии до 0.4.18 все жрали память и падали, 0.4.18 стабильно работает уже 5 дней. Трафика несколько гигабайт в сутки, Cloudflare со своего IPFS раздает чуть больше терабайта в сутки.

https://pacipfs.antizapret.prostovpn.org/

Предполагаю, что мои PAC-файлы потребляют больше всего трафика на Cloudflare-гейте.

ValdikSS ★★★★★
()
Последнее исправление: ValdikSS (всего исправлений: 1)

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

anonymous
()
Ответ на: комментарий от kto_tama

Интересно, на сколько порядков си-шная реализация окажется более трудоемкой ?

Для сишника ни на сколько, откуда у тебя такой шаблон в голове?

anonymous
()
Ответ на: комментарий от ValdikSS

Трафика несколько гигабайт в сутки

Хм. У меня несколько гигабайт в сутки идёт с пустых репозиториев, транзитно :)

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

Это как Bittorrent — файлы можно скачать только тогда, когда вы их раздаёте. Они не загружаются куда-то автоматически.

ValdikSS ★★★★★
()
Ответ на: комментарий от ValdikSS

У меня уменьшено количество соединений

Это где? В конфиге, вроде, вижу только параметры настройки срабатывания GC по числу соединений: https://github.com/ipfs/go-ipfs/blob/master/docs/config.md#connmgr

и включен режим dhtclient.

У меня и dhtclient, и Reprovider.Interval "0", и profile apply lowpower.

KRoN73 ★★★★★
()
Ответ на: комментарий от kto_tama

на сколько порядков си-шная реализация окажется более трудоемкой

Не будет. Можешь на i2p vs i2pd посмотреть.

devl547 ★★★★★
()
Ответ на: комментарий от devl547

Но i2pd не на си, а на плюсах же.

anonymous
()
Ответ на: комментарий от KRoN73

LowWater, как я понимаю, рекомендованное минимальное количество соединений, которое постоянно поддерживается. Я уменьшал LowWater и HighWater.

ValdikSS ★★★★★
()
Ответ на: комментарий от ValdikSS

Прописал у себя 50/100 вместо дефолтовых 600/900. На трёх машинах где-то в этой области и держится (хотя иногда до 200 скачет, а на одной машине на 15 зависло и держится так), на четвёртой — через 5 минут после рестарта уже 650 соединений и растёт…

KRoN73 ★★★★★
()
Ответ на: комментарий от MrClon

локальная нода и гейты умеют (или будет уметь) в httpшные range запросы. Или только выкачивать весь файл целиком? Мне для видео надо. Бить его на чаники дико лениво

IPFS работает с блоками не больше 256КБ. То есть любой файл больше этого автоматически разбивается на блоки и первичный хэш указывает на multihash. При скачке multihash, все блоки запрашиваются одновременно. В теории HTTPшный range сделать можно, только зачем? Если надо потоковое видео гнать, так наоборот, лучше его нарезать кусками по несколько секунд и так и выставлять.

skliarie
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.