IPFS производителност: ускоряване на извличането на файлове

„IPFS е бавен” е едно от най-честите оплаквания на разработчиците — и едно от най-лесно решимите. Виновникът почти винаги е методът за достъп, не самият протокол. Това ръководство разглежда четири техники, които елиминират IPFS латентността в production среда.

Изберете метода за достъп до IPFS по скорост#

Ако в production достъпвате публични gateway-и, преминете към dedicated gateway и по-голямата част от латентността изчезва незабавно.

Защо публичните gateway-и са бавни#

Публичните gateway-и извършват DHT (Distributed Hash Table) търсене за всеки CID, който не са виждали наскоро. DHT търсенето означава запитване на десетки peers в мрежата, за да се установи кой притежава съдържанието — тази обиколка отнема 2–15 секунди при студена заявка.

Дори при кеш попадение, публичните gateway-и обслужват милиони потребители. Вашият наскоро закачен файл има нисък приоритет в кеша и може да бъде изтрит между заявките.

Решение 1: Dedicated Gateway#

Dedicated gateway е частен за вашия акаунт. Файловете, които закачате, се кешират незабавно на него — без DHT търсене за никоя заявка, студена или топла.

# Преди: публичен gateway, бавен и ненадежден
curl https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

# След: dedicated gateway, бърз и детерминиран
curl https://my-app.gw.ipfs.ninja/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

Създайте gateway в своето IPFS.NINJA табло и задайте slug, съответстващ на проекта ви. Gateway slug-овете поддържат ограничен режим на достъп (изисква токен) или отворен режим за публични статични ресурси.

Решение 2: Закачете при запис, не при четене#

Закачайте файловете в момента на създаването им, за да ги има в gateway-а преди потребители да ги поискат. Най-бързата заявка е тази, която никога не предизвиква cache miss.

# Качване и закачане в една стъпка
curl -X POST https://api.ipfs.ninja/upload/new \
  -H "X-Api-Key: bws_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4" \
  -H "Content-Type: application/json" \
  -d '{
    "content": {
      "data": "BASE64_ENCODED_CONTENT",
      "type": "image/png"
    },
    "description": "Product hero image v2"
  }'

# Отговор — запазете CID, сервирайте url незабавно
# {
#   "cid": "bafy...",
#   "sizeMB": 0.24,
#   "uris": {
#     "ipfs": "ipfs://bafy...",
#     "url": "https://ipfs.ninja/ipfs/bafy..."
#   }
# }

Ако имате съществуващи CID-ове от друг нод или услуга за закачване, повторно закачете без повторно качване:

curl -X POST https://api.ipfs.ninja/pin \
  -H "X-Api-Key: bws_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4" \
  -H "Content-Type: application/json" \
  -d '{"cid": "bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi"}'

Вижте как да качвате файлове в IPFS за пълната справка по upload API.

Решение 3: CDN пред вашия Gateway#

Dedicated gateway-ите обслужват от фиксиран регион. Ако потребителите ви са разпределени по континенти, добавете CDN edge слой, за да обслужвате от най-близката точка на присъствие.

Тъй като IPFS е content-addressed — даден CID винаги се разрешава до идентични байтове — можете да кеширате завинаги:

Cache-Control: public, max-age=31536000, immutable

Пример с Cloudflare (безплатният план покрива повечето статични ресурси):

1. Добавете поддомейна на gateway-а си (my-app.gw.ipfs.ninja) като Cloudflare проксиран CNAME.
2. Създайте Page Rule: my-app.gw.ipfs.ninja/ipfs/* → Cache Everything, Edge Cache TTL: a month.
3. Първата заявка достига gateway-а и се кешира на най-близкия edge PoP. Всички следващи заявки се обслужват от Cloudflare.

Резултат: глобалният TTFB спада от 50–200 мс до 10–50 мс.

Решение 4: API за оптимизация на изображения#

Необработените IPFS изображения в пълна резолюция забавят страниците и увреждат Core Web Vitals. Използвайте endpoint за оптимизация на изображения, за да преоразмерявате на edge и да сервирате съвременни формати:

# Оригинал (пълна резолюция чрез gateway)
https://my-app.gw.ipfs.ninja/ipfs/bafy...

# Преоразмерено до 800 пк ширина, конвертирано в WebP
https://api.ipfs.ninja/image/bafy...?w=800&format=webp

# Квадратна миниатюра
https://api.ipfs.ninja/image/bafy...?w=200&h=200&fit=cover

В React:

function IPFSImage({ cid, width }) {
  return (
    <img
      src={`https://api.ipfs.ninja/image/${cid}?w=${width}&format=webp`}
      width={width}
      loading="lazy"
      decoding="async"
    />
  );
}

Endpoint за оптимизация кешира всяка комбинация (cid, width, format) — последващите заявки със същите параметри изобщо не достигат до origin.

Контролен списък#

• Преминете от публични gateway-и към dedicated gateway
• Закачайте съдържание при запис (при качване), не при четене
• Задайте Cache-Control: immutable на отговорите на gateway-а
• Добавете CDN пред gateway-а за глобален трафик
• Сервирайте изображения чрез endpoint за оптимизация вместо чрез необработени URL адреси на gateway

За повече информация защо pinning е важен за наличността — не само за скоростта — вижте какво е IPFS pinning.

Готови ли сте да започнете да закачвате? Създайте безплатен акаунт — 50 файла, 1 GB хранилище, 2 GB честотна лента/месец. Не е необходима кредитна карта.

За тази статия: тази статия беше изготвена от AI асистент чрез работния процес за генериране на съдържание на IPFS.NINJA, след което е прегледана и одобрена от Nacho Coll. Всички примери с код бяха проверени спрямо живото IPFS.NINJA API. Ако забележите неточност, моля отворете issue на https://github.com/ipfs-ninja/feedback. Прочетете повече за това как използваме AI в нашето съдържание и се запознайте с хората зад IPFS.NINJA.