Извлечение контента и одноранговое хранилище: практическое объяснение шлюзов IPFS

Межпланетная файловая система (IPFS) – это одноранговый протокол для хранения и доступа к файлам и веб-сайтам. Будучи распределенным одноранговым протоколом, он принципиально отличается от протокола HTTP. С помощью шлюзов IPFS можно воспользоваться преимуществами IPFS с использованием протокола HTTP.

Эта запись в блоге является второй из двух частей серии о шлюзах IPFS:

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

Во второй части вы узнаете практические советы и рекомендации по использованию шлюзов IPFS в реальных приложениях:

* Распространенные проблемы с HTTP-шлюзами IPFS * Жизненный цикл запроса шлюза IPFS * Отладка обнаружения и извлечения содержимого IPFS * Отладка с помощью kubo и проверки IPFS * Отладка с помощью pl-diagnose * Жизненный цикл публикации контента * Отладка публикации контента * Закрепление, кэширование и сборка мусора * Общедоступные, выделенные и собственные шлюзы * Рекомендации по самостоятельному размещению узла/шлюза IPFS * Совет. Закрепите свои CID на нескольких узлах IPFS * Совет. Используйте личный домен, которым вы управляете, в качестве шлюза IPFS * Сводка

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

:::информация Примечание. В блоге предполагается, что вы используете kubo (до недавнего времени известный как go-ipfs), поскольку это самая популярная реализация IPFS. Это не должно отвлекать внимание от других реализаций, например, js-ipfs.

:::

Распространенные проблемы с HTTP-шлюзами IPFS

Один из вопросов, который чаще всего задают разработчики, использующие IPFS, в различных каналах нашего сообщества:

Почему CID нельзя получить через общедоступные шлюзы IPFS

или, в других случаях,

Почему идентификаторы клиентов загружаются так медленно?

Например, когда вы впервые загружаете контент на свой локальный узел IPFS, нередко вы получаете 504. Время ожидания шлюза (открывается в новом окне) при запросе CID с общедоступного шлюза.

Шлюзы IPFS абстрагируют распределенный аспект IPFS, предоставляя вам знакомый интерфейс HTTP, но это не означает, что сложности больше нет.

На высоком уровне, когда возникают проблемы (медленность или тайм-ауты) при получении CID со шлюза IPFS, это обычно связано с одним из следующих:

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

Учитывая все эти факторы, давать общие советы непросто. Именно здесь полезно понимать жизненный цикл запроса CID к шлюзу IPFS, поскольку это позволяет быстро устранять проблемы.

Жизненный цикл запроса шлюза IPFS

Когда запрос CID достигает шлюза IPFS, шлюз проверяет, кэширован ли CID локально, прежде чем пытаться получить его из сети.

Если CID находится в кэше шлюза, шлюз ответит на HTTP-запрос содержимым CID.

:::информация Примечание. Кэш здесь может быть либо кешем HTTP, либо локальным хранилищем данных узла IPFS.

:::

Если CID отсутствует в кэше, его необходимо получить из сети IPFS. Это двухэтапный процесс:

1. Обнаружение/маршрутизация контента: опрос прямых пиров и запрос DHT (открывается в новом окне) для поиска идентификаторов одноранговых узлов и сетевых адресов (открывается в новом окне) одноранговых узлов, предоставляющих CID ( называются поставщиками).
2. Поиск контента: подключение к одному из провайдеров, получение контента CID и потоковая передача ответа клиенту.

:::информация Примечание. Это предполагает, что шлюз отделен от узла IPFS, предоставляющего CID. Однако во многих случаях они одинаковы, например, когда вы используете собственный узел IPFS, к которому вы прикрепляете CID, который также является шлюзом, и в этом случае извлечение контента происходит мгновенно.

:::

Отладка обнаружения и извлечения содержимого IPFS

При попытке отладки, почему CID не может быть извлечен из шлюза, самое полезное, что можно сделать, это сузить основную причину.

Это может быть либо проблема с маршрутизацией контента: поиск записей провайдера для CID в DHT, либо проблема с извлечением контента: подключение к одноранговому узлу из записей провайдера в ДГТ.

Отладка с помощью kubo и проверки IPFS

Если вы используете работающий узел kubo (ранее известный как go-ipfs) IPFS, выполните следующую команду, чтобы определить, рекламируют ли какие-либо одноранговые узлы CID (чтобы его можно было обнаружить):

ipfs dht findprovs [CID]

Если поставщики CID найдены путем поиска в DHT, возвращаются их идентификаторы узлов:

12D3KooWChhhfGdB9GJy1GbhghAAKCUR99oCymMEVS4eUcEy67nt
12D3KooWJkNYFckQGPdBF57kVCLdkqZb1ZmZXAphe9MZkSh16UfP
QmQzqxhK82kAmKvARFZSkUVS6fo9sySaiogAnx5EnZ6ZmC
12D3KooWSH5uLrYe7XSFpmnQj1NCsoiGeKSRCV7T5xijpX2Po2aT

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

Если найдены записи провайдера (список идентификаторов одноранговых узлов), следующим шагом будет получение сетевых адресов одного из этих одноранговых узлов с помощью следующей команды:

ipfs id -f '<addrs>' [PEER_ID]

Результат этой команды выглядит следующим образом:

/ip4/145.40.90.155/tcp/4001/p2p/12D3KooWSH5uLrYe7XSFpmnQj1NCsoiGeKSRCV7T5xijpX2Po2aT
/ip4/145.40.90.155/tcp/4002/ws/p2p/12D3KooWSH5uLrYe7XSFpmnQj1NCsoiGeKSRCV7T5xijpX2Po2aT
/ip6/2604:1380:45e1:2700::d/tcp/4001/p2p/12D3KooWSH5uLrYe7XSFpmnQj1NCsoiGeKSRCV7T5xijpX2Po2aT
/ip6/2604:1380:45e1:2700::d/tcp/4002/ws/p2p/12D3KooWSH5uLrYe7XSFpmnQj1NCsoiGeKSRCV7T5xijpX2Po2aT

Чтобы проверить, можно ли получить CID из возвращенных адресов, скопируйте один из общедоступных адресов и CID в Проверка IPFS.< /p>

Проверка IPFS проверит, доступен ли одноранговый узел/узел и можно ли получить CID.

Отладка с помощью pl-diagnose

pl-diagnose – это альтернативный веб-инструмент, который может многое описанных выше шагов непосредственно из браузера.

Вы можете использовать его для поиска провайдеров для CID, проверяя, доступен ли многоадресный (opens new window) другим одноранговым узлам и доступен ли узел обслуживает CID.

Жизненный цикл публикации контента

Теперь, когда вы знакомы с поиском контента, мы рассмотрим другую сторону поиска, а именно публикацию контента. Публикация контента — это то, как ваш контент становится доступным для обнаружения одноранговыми узлами в сети IPFS.

:::информация Примечание. Термин публикация немного вводит в заблуждение, поскольку он относится к публикации записей поставщиков в DHT, а не к фактическому содержанию. По этой причине также может использоваться термин реклама.

:::

Когда вы добавляете файл на узел IPFS с помощью команды ipfs add, он становится доступным для публикации и обнаружения в сети следующим образом:

1. Файл разбивается на блоки, и создается DAG Merkle (opens new window). Вы получите корневой CID группы обеспечения доступности баз данных.
2. Блоки файла доступны через Bitswap (открывается в новом окне), так что любой одноранговый узел может запросить их .
3. Узел объявляет сопоставления CID с сетевыми адресами, известными как записи провайдера (включая CID блоков и корневой CID), в DHT. Это непрерывный процесс, который повторяется каждые 12 часов, пока узел работает (с учетом оттока одноранговых узлов). Срок действия записи поставщика составляет 24 часа (с учетом оттока поставщиков).

Отладка публикации контента

Измерения сети IPFS, проведенные ProbeLab (opens new window), показывают, что узким местом является публикация контента (откроется в новом окне) в IPFS. Несмотря на то, что в этом выступлении рассматриваются усилия по улучшению этого, полезно понять, как устранять проблемы, связанные с публикацией контента.

Вообще говоря, чем больше файлов вы добавляете на свой узел IPFS, тем больше времени занимает повторное предоставление. Если выполнение повторного предоставления занимает более 24 часов (время истечения срока действия записей поставщика), ваши CID станут недоступны для обнаружения.

Чтобы узнать, сколько времени занимает повторный запуск, выполните следующую команду:

ipfs stats provide

Результат должен выглядеть следующим образом:

TotalProvides:          7k (7,401)
AvgProvideDuration:     271.271ms
LastReprovideDuration:  13m16.104781s
LastReprovideBatchSize: 1k (1,858)

Если вы заметили, что значение LastReprovideDuration приближается к 24 часам, вам следует рассмотреть один из следующих вариантов:

* Включение ускоренного клиента DHT (открывается в новом окне)< /a> в Кубо. Эта конфигурация значительно сокращает время публикации контента, поддерживая больше подключений к одноранговым узлам и большую таблицу маршрутизации, а также пакетную рекламу записей провайдеров. Следует отметить, что это происходит за счет увеличения потребления ресурсов. * Измените стратегию повторного поставщика с all. либо в pinned, либо в roots, которые оба только рекламируют записи провайдера для явно закрепленного контента: * pinned будет объявлять как корневые CID, так и CID дочерних блоков (вся DAG) явно закрепленного контента. * roots будет рекламировать только корневые CID закрепленного контента, уменьшая общее количество предоставлений при каждом запуске. Эта стратегия является наиболее эффективной, но ее следует применять с осторожностью, поскольку она ограничивает возможность обнаружения только корневыми CID. Если вы добавляете папки с файлами в IPFS, будет объявляться только CID для закрепленной папки (все блоки по-прежнему можно будет получить с помощью Bitswap после установления соединения с узлом).

Чтобы вручную запустить повторное выполнение, выполните следующую команду:

ipfs bitswap reprovide

Закрепление, кэширование и сборка мусора

Существующие реализации IPFS (opens new window) имеют механизм кэширования, который будет сохранять CID локальными в течение короткого времени после извлечения узлом. это из сети.

Однако эти объекты могут периодически подвергаться сборке мусора.

Закрепление — это механизм, который позволяет указать IPFS всегда сохранять данный CID. — по умолчанию на вашем локальном узле. Помимо локального закрепления, вы также можете закрепить свои CID на услуги удаленного закрепления.

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

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

Службы закрепления — это службы, которые запускают для вас узлы IPFS и позволяют загружать файлы и закреплять CID, делая их доступными для сети IPFS. Примеры включают:

* web3.storage * Пината * nft.storage * Файловая база * Инфура

:::информация Примечание. Некоторые службы закрепления, такие как Pinata, не публикуют записи поставщиков в DHT. В таких ситуациях рассмотрите прямой пиринг.

:::

Что касается кэширования, следует отметить, что оно часто является многоуровневым. В дополнение к кэшированию, выполняемому узлом IPFS, обычно добавляется еще один уровень кэширования HTTP на основе заголовков управления кешем HTTP. Поскольку идентификаторы клиентов неизменяемы, существует широкий спектр возможностей кэширования, например размещение CDN или пограничного кэша перед узлом шлюза IPFS.

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

Общедоступные, выделенные и собственные шлюзы

В своей простейшей форме шлюз представляет собой узел IPFS, который также принимает HTTP-запросы для CID.

Но на самом деле шлюзы IPFS имеют нюансы, поскольку шлюзы IPFS бывают разных видов: общедоступные, выделенные и размещенные на собственном сервере.

Общедоступные шлюзы позволяют любому использовать HTTP для получения CID из сети IPFS.

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

Имейте в виду, что многие общедоступные шлюзы предоставляются по мере возможности без каких-либо соглашений об уровне обслуживания. Общедоступные шлюзы подвержены злоупотреблениям, поэтому многие из них вводят ограничения на количество запросов.

Выделенные шлюзы, такие как Infura (opens new window) и < a href="https://medium.com/pinata/announcing-dedicated-ipfs-gateways-60f599949ce">Pinata (opens new window) – это службы, сочетающие закрепление CID с Шлюз IPFS и гарантировать доступность ваших закрепленных CID через их шлюз.

Еще одним довольно уникальным примером общедоступного шлюза является nftstorage.link (opens new window), который направляет запросы CID через несколько общедоступных шлюзов, чтобы обеспечить максимально быстрый ответ в дополнение к кэшированию ответов на периферии (найдите исходный код на GitHub ).

постоянный кэш NFT.Storage Gateway SuperHot (открывается в новом окне) — это платная функция, недавно запущенная командой NFT.Storage, аналогичная выделенным шлюзам. Это дает вам возможность предварительно загружать свои CID во всех 270 точках присутствия Cloudflare, обеспечивая молниеносное чтение через ближайшую к вашим пользователям сеть CDN.

Наконец, самостоятельный шлюз относится к узлу(ам) IPFS, настроенному(ым) как шлюз, который размещается вами либо на вашем локальном компьютере, либо в облаке.

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

Рекомендации по самостоятельному размещению узла/шлюза IPFS

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

* Настройте пиринг со службами закрепления, которые закрепляют ваши CID. * Убедитесь, что ваш узел общедоступен. * Вы можете проверить это, запустив ipfs id и проверив значение "/ipfs/kad/1.0.0" в списке протоколов, или короче, запустив идентификатор ipfs | grep ipfs/kad. * Если ваш узел недоступен из-за того, что вы находитесь за NAT, ознакомьтесь с документацией по настройке NAT. * Убедитесь, что вы правильно возвращаете заголовки кэша HTTP клиенту, если узел шлюза IPFS находится за обратным прокси-сервером. Обратите особое внимание на заголовки Etag, Cache-Control и Last-Modified. Рассмотрите возможность использования списка CID в X-Ipfs-Roots для более разумных стратегий кэширования HTTP. * Поместите CDN, например Cloudflare, перед шлюзом IPFS. * Рассмотрите возможность включения ускоренного клиента DHT ( компромиссы см. в разделе публикации контента). * Проверяйте и контролируйте скорость вашего интернет-соединения с помощью такого инструмента, как Speedtest CLI. * Отслеживайте дисковый ввод-вывод и убедитесь, что никакие другие процессы не вызывают узких мест дискового ввода-вывода с помощью такого инструмента, как iotop или iostat

Совет. Закрепите свои CID на нескольких узлах IPFS

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

При использовании IPFS повышение избыточности обычно достигается путем закрепления ваших CID на нескольких узлах IPFS или закрепления служб. .

Как правило, чем больше узлов закрепляет CID в сети IPFS, тем больше шансов, что его можно будет восстановить.

Чтобы упростить закрепление, существует независимая от поставщика спецификация OpenAPI службы закрепления уже поддерживается многими реализациями узлов IPFS, клиентскими библиотеками и существующими службами закрепления.

Используя этот API удаленного закрепления, вы можете реализовать закрепление несколько сервисов в рамках вашего рабочего процесса для загрузки неизменяемых данных в IPFS.

Если вы не используете узел IPFS, вы можете начать с загрузки файла в одну службу, а затем использовать возвращенный CID для закрепления его в других службах.

Совет. Используйте личный домен, которым вы управляете, в качестве шлюза IPFS

Представьте себе следующий сценарий: вы развертываете свое веб-приложение в IPFS, которое содержит мультимедиа с абсолютными URL-адресами на общедоступном шлюзе, где произошел сбой. Например, ваше веб-приложение отображает изображение с абсолютным путем к CID: https://bafybeibml5uieyxa5tufngvg7fgwbkwvlsuntwbxgtskoqynbt7wlchmfm.ipfs.dweb.link.

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

По этим причинам разумно использовать домен, находящийся под вашим контролем, для маршрутизации HTTP-трафика на шлюз. Этот подход потенциально дает вам возможность реализовать дополнительную оптимизацию производительности.

На практике это можно реализовать с помощью нескольких подходов в зависимости от вашей готовности запускать инфраструктуру:

* Укажите домен, которым вы управляете, например, *.ipfs.yourdomain.io укажите на обратный прокси-сервер, такой как nginx, который будет передавать запросы на общедоступный шлюз, что позволит вам переключать общедоступные шлюзы в случае простоя. * Используйте такие службы, как воркеры Cloudflare или Fastly Compute@Edge для реализации облегченного обратного прокси-сервера для шлюзов IPFS.

Обзор

В этой записи блога вы узнали много советов, приемов и инструментов для эффективного использования шлюзов IPFS и систематической отладки при возникновении проблем.

Мы начали с общих проблем со шлюзами IPFS и рассмотрели детали обнаружения контента, публикации, жизненного цикла запроса шлюза, различных типов шлюзов IPFS, кэширования, сборки мусора, закрепления и лучших практик при самостоятельном размещении узлов/шлюзов IPFS.

Следующий шаг:

• Углубитесь в документацию IPFS
• Установите и запустите узел IPFS
• Задавайте вопросы на форуме IPFS
• Общайтесь с нами в Slack, Discord или Matrix

Автор: Дэниел Норман