Комментарии 29
И на какой еще планете этот сайт можно открыть?
Ну… maidsafe вроде как отдупляет, и сие интересней, чем то, о чем статья.
А если нужно самый быстрый сайт (из многих точек мира), то есть cloudflare.
Я воспользовался данным сервисом для 24 часового онлайна. Но в малонаселённых пунктах с медленным интернетом сомневаюсь что CloudFlare позаботится поставить свои сервера. Они держатся на слепом доверии что не будут вмешиваться в то что я через них публикую.
IPFS клиенты и соответственно шлюзы могут быть в каждой локальной сети. Считайте это такой народный CDN. Поскольку содержимое идентифицируется мультихешем IPFS может проверить что получает от других клиентов именно то содержимое которое я опубликовал.
По поводу MaidSafe ничего не могу сказать. Я и IPFS недавно только начал изучать.
maidsafe — будет представлять из себя десятки тысяч нод по всему миру, где инфа продублирована несколько раз. Как днс ориентированный хостинг не прокатит, но для анонимного размещения материала и p2p идеи самое то.
На счет cloudflare и населенные пункты — не уверен, что будут ставить, но весь мир и основные города стабильно (а из больших городов есть линки в маленькие). На счет контроля траффика… приведите пример, когда cloudflare вмешались во что-то, они даже радикальный сайт не закрыли.
Я прочитав всю статью целиком, только в конце понял о чем речь.
Я сейчас экспериментирую со связкой IPFS+Webtorrent и мне не очень нравится результат. Напрягает падение самого демона IPFS при высокой частоте запросов к нему. Webtorrent-плеер играет видео через webseed, пока ты первый, кто смотрит его. Webseed-урл в торрент-файле указывает как раз на IPFS-хеш. Всё работает нормально только какое-то время, пока количество range-запросов к IPFS не упирается в какой-то непонятный мне потолок и демон падает. Перезапускается супервизиром, но этот downtime останавливает стрим, плеер получает 502 и ничего больше не работает, нужна перезагрузка страницы. Опытным путём выяснил, что демон очень жадный и хочет весь CPU на моём бедном микроинстансе. Я увеличил CPU/RAM дроплета, стало лучше. Но это пока клиент стримит только одно видео. Моя идея ещё и в том, чтобы webtorrent продолжал раздавать медиа-файл уже своими средствами, в фоне, после переключения воспроизведения на что-то другое. В итоге вопрос — сколько ж нужно IPFS-демону для нормальной жизни, если я уже дважды увеличивал инстанс и больше (по бюджету) не хочу? И вдогонку — есть ли какой-то список публичных шлюзов, чтобы я как-то балансировал нагрузку? Спасибо.
Вы можете прикрыть свой шлюз кеширующим прокси чтобы снизить нагрузку. На данный момент IPFS для WebTorrent бесполезен в виде локального шлюза т.к. в настройках по умолчанию нет разрешения для range запросов. Но стоит добавить локальный шлюз в магнит или торрент на будущее. И инструктировать пользователей как его установить и настроить.
Из публичны шлюзов я знаю только gateway.ipfs.io или ipfs.io. Можно пройтись по пирам в сети и найти с открытым наружу портом шлюза но это не правильное использование IPFS.
Правильное использование сети IPFS это когда у каждого пользователя стоит IPFS клиент.
Я в будущем может пороюсь в клиенте и попробую найти и выключить перепроверку хешей если запрос идёт от WebTorrent и Bittorrent.
Я уже установил nginx в роли прокси, с кешированием. Мне это не особо помогло. Да и хочется быть ближе к основной идее — безсерверному ресурсу.
IPFS с range-запросами работает хорошо. Только падает в итоге :) Клиент у меня сначала пытается достучаться к локальному демону, если его нет — то к шлюзу на моём инстансе. В целом всё оно работает. Но ощущение общей сырости не даёт покоя. Или я что-то делаю не так, или Go-имплементация далека от стабильной версии.
Но если оставить в покое видео и стримить более лёгкий статический контент, то всё прекрасно. Что-то в этом есть.
Для IPNS в текущей версии клиента кеширование не включено. То есть не отдаются хедеры "Etag" и "Cache-Control".
Я исправил у себя отдачу "Etag"
core/corehttp/gateway_handler.go | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/core/corehttp/gateway_handler.go b/core/corehttp/gateway_handler.go
index c35431c..d69d8a9 100644
--- a/core/corehttp/gateway_handler.go
+++ b/core/corehttp/gateway_handler.go
@@ -177,7 +177,7 @@ func (i *gatewayHandler) getOrHeadHandler(w http.ResponseWriter, r *http.Request
return
}
- etag := gopath.Base(urlPath)
+ etag := pbnd.Key().B58String()
if r.Header.Get("If-None-Match") == etag {
w.WriteHeader(http.StatusNotModified)
return
@@ -216,8 +216,10 @@ func (i *gatewayHandler) getOrHeadHandler(w http.ResponseWriter, r *http.Request
// and only if it's /ipfs!
// TODO: break this out when we split /ipfs /ipns routes.
modtime := time.Now()
+
+ w.Header().Set("Etag", etag)
+
if strings.HasPrefix(urlPath, ipfsPathPrefix) {
- w.Header().Set("Etag", etag)
w.Header().Set("Cache-Control", "public, max-age=29030400, immutable")
// set modtime to a really long time ago, since files are immutable and should stay cachedСделал свой релиз.
Я сделал один пул реквест с исправлениями определения скрытых файлов под Windows. Но после того как отправил оказалось что его подписать надо. А потом ещё место с ошибкой нашёл. Пул реквес делал с сайта так как изменений был мизер. Как его поправить теперь не знаю.
Гуглу вон тоже отправил пул реквест и они тутже захотели чтоб я им документик подписал.
Я тоже хотел бы залить свои исправления в главный репозитарий и чтоб их приняли может даже с изменениями. Но мне нужно изучить их бюрократию.
В общем надо изучать эти процессы.
Побочный вопрос:
tk продолжает раздавать бесплатные домены? С продлением за 19$?
В простое от 0 до 15 процентов прыгает. Пока большой блок отдаёт до 50 прыгает на пару секунд. Памяти 720 МБ сьел. Но это при последовательном проигрывании видео в браузере.
При сохранении видео на диск скорость прыгает с 1МБ/с до 5МБ/с. Загрузка процессора прыгает от 10 до 80 пстоянно. Памяти сьел 1ГБ.
При случайной загрузке торентом скорость от 200КБ/с до 700КБ/с. Загрузка процессора от 50 до 90 изретка падая до 0. Память 900МБ.
Видео: Первый день осени
Спасибо!
Я правильно понимаю следующие вещи:
1. Если мой узел IPFS Desktop включен, и файлы у меня лежат на диске, то они не попадут в мусор и будут всегда доступны другим?
2. Что за файлы уже появляются в IPFS Desktop если я еще ничего не импортировал (не добавлял). И уже 30 Мб и постоянно растёт это значение.
Где эти объёмы данных сохраняются? Не на диске "С" случайно? Это служебная какая то информация? Можно ли поменять диск и каталог её сохранения? и как то регулировать этот объем (к примеру динамически выделить место). Дает ли хранение этой служебной информации какие то бонусы? (к примеру что и ты можешь хранить у других столько же закреплять)?
3. Сайт можно разместить только одностраничный? то есть состоящий только из одного файла index.html? А если статичный сайт из нескольких файлов и папок? где и css и js, то как разместить?
По умолчанию добавляемые в IPFS файлы пользователем пинятся и не удаляются при сборке мусора. Так что в теории пока клиент работает файлы должны быть доступны.
Эти 30МБ скорей всего это сам web ui(страница и ресурсы на которой это всё отображается). Если открыть web ui в браузере в адресной строке появится его хеш. Этот хеш можно вставить в текстовое поле на этой странице и посмотреть из чего он состоит и что сколько занимает. Всё что открывается через локальный шлюз скачивается и сохраняется в локальный репозитарий пользователя. В windows он находится по умолчанию по пути "
C:\Users\user_name\.ipfs". Путь к репозитарию можно поменять задав переменную среды IPFS_PATH в которой указать другой диск и путь до репозитария. Объём репозитария задаётся в настройках. При привышении этого обьёма включается сборщик мусора который удаляет из репозитария не запиненые блоки. Бонусы хранения служебной информации наверно только в скорости открытия страницы.Можно размещать и многостраничный. Все эти файлы и папки можно сложить в одну и сделать ссылки на другие страницы относительными текущей страницы (например: ./page1.html).
Спасибо!
2. Я спросил просто про "чужие файлы" потому что вот в этой статье
https://thecode.media/ipfs-2-2/
автор пишет
Правовые нюансы
Если правоохранительные органы изымут ваш компьютер, а на нём будет лежать что-то запрещённое из IPFS-сети, ответственность будет на вас. А появиться оно там может, потому что кто-то другой положил его в IPFS-сеть, а вы у себя развернули IPFS-сервер по доброте душевной. Будьте осторожны с таким.
то есть как бы намекая, что на развернутый IPFS-сервер как то автоматически могут сохраняться файлы других пользователей для репликации в сети.
Но я нигде не нашел в настройках хоть какую то опцию управления такими файлами (место сохранения, объем, динамическое или статическое).
Или IPFS-сервер - это что то другое чем IPFS Desktop?
30 Мб уже увеличились. То есть пока IPFS Desktop включен, то постоянно что то закачивается, даже если сам еще не начал размещать файлы. Просто интересно до каких размеров это может разрастись, и как можно это регулировать (в настройках нет ничего), и самое главное в документации ни слова об этом.
3. Спасибо! а то там же в статье наоборот учат что все ссылки внутри index.html поменять на сгенерированные абсолютные но уже IPFS, а потом уже загружать конечный измененный index.html и на него делать ссылку новую
Насколько я знаю обычный IPFS чужие файлы качает только когда пользователь выполнил какие то действия для этого (скачал файл или папку из IPFS, запинил файл или папку другого пользователя, открыл файл или папку на локальном шлюзе, исследовал файл или папку средствами клиента). Но самостоятельно без действий пользователя обычная IPFS ничего не должна качать.
Возможно имеется ввиду что не стоит давать доступ к локальному шлюзу всему интернету так как запрошенные данные через шлюз скачиваются и сохраняются локально.
Также любой сайт может запросить с вашего локального шлюза просто угадав его адрес (127.0.0.1:8080) нужные ему файлы и они также скачаются из сети IPFS и сохранятся локально. Чтоб такого не произошло можно поменять в настройках порт шлюза на случайный (правда это не спасёт от скана портов). Или как вариант заблокировать браузеру возможность запрашивать что то у локального шлюза при помощи плагинов (например uMatrix) или proxy.pac.
Есть также ipfs-cluster у которого задача как раз распределять данные между узлами кластера. Но я им не пользуюсь так что сказать мне про него нечего.
Пока клиент запущен он поддерживает работу DHT сети которая позволяет IPFS узлам находить друг друга для обмена данными. Возможно именно этот трафик и отображается в клиенте.
Если очень интересно что IPFS делает есть опция дебаг режима (--debug) которая позволяет логировать все действия IPFS.
Спасибо! с IPFS - решается проблема хранения статичного контента для (даже динамичного сайта) даже не простеньком хостинге... Причем малыми силами. По крайней мере файлы подтягиваются в страничку нормально (наполнение), при генерации страницы. ТО есть весь статический контент нормально подтягивается. На сервере можно держать только динамический контент PHP и БД. Думаю как бы это всё теперь объединить в примерно простенький блог. Пока только проделал все в ручную...Смысл в том, что когда кто то загружает файл, надо его через свой IPFS сервер (на любом компе даже с серым непубличным IP, но должен быть онлайн) закидывать в IPFS, генерировать ссылку и уже её вставлять в проект. Причем очень хорошая масштабируемость - любой IPFS сервер, на любом компе, может выполнять эту функцию. и дублировать и расширять, если ресурсов одного не хватает.
Может это можно как то автоматизировать? Нет в IPFS Desktop или протоколе в целом инструмента забирать файл из поля добавления на сайте, импортировать в IPFS и возвращать ссылку (и ссылку со шлюзом).
То есть задача такая (та же): На простеньком хостинге (не мощном и с малым объемом места на дисках) хранится только PHP и динамичный контент (может еще и БД), а весь объёмный медиаконтент (видео, фото, аудио) хранится дома на компе (с серым IP) с установленным IPFS Desktop. Все тяжелые статичные файлы импортированы в IPFS, сгенерированы ссылки и вставлены назад в сайт. (но это то что я добавляю просто). А вот если добавляют пользователи, как автоматизировать? ну кроме дать им инструкцию по поднятию своего IPFS Desktop).
Hidden text
Вчера экспериментировал со всеми вариантами - пришла в голову концепция: создать соц сеть с такой логикой, что все хранят свой контент у себя, но кто к примеру лайкает или делится чужим контентом (то есть считает его важным) сохраняют копию или какую то часть и у себя (то есть делают контент живучим к исчезновению).В итоге будет так - если сам создатель контента в сети, то его контент доступен (деже если никому больше не нравится). Если его контент лайкают, то тоже транслируют, и он будет доступен даже если автор не в сети, а в сети хоть кто то из тех кто лайкнул и тем самым взял на хранение и отдачу тоже. Это будет лучший показатель качества и оценки контента, люди не будут бездумно лайкать, зная что еще и выделяют под это место и мощности (особенно боты всякие и проплаченные). Ну и будут видны реальные "друзья" и единомышленники, потому что нужно будет подтверждать это работой (как в крипте) то есть жертвовать местом на диске и мощностями. Удобство еще и в том. что управляющий сервер можно развернуть на совсем простых мощностях (как трекеры), и трафик и нагрузка и место для них нужно минимум.Остальной контент будет потихоньку исчезать, если сам автор не будет поддерживать его. Это тоже хорошо - меньше мусора, и желание авторов дольше быть в онлайн. Это сделает выше посещаемость и онлайн. В итоге IPFS (для файлов) и PeerTube для видео пока кажутся лучшими решениями. На базе такой соцсети можно сделать и твою систему распространенного хранения контента
Есть Kubo RPC API которое позволяет в том числе и загружать файлы в IPFS.
Добавил новую информацию:
Публикацию через ID нужно использовать когда сайт часто обновляется. IPFS клиент через который публикуется контент должен быть постоянно включен или выключаться на небольшие промежутки времени. За день offline у меня клиент забыл привязку id -> мультихеш. Видимо привязка храниться только в DHT.
Публикуем сайт в межпланетной файловой системе IPFS