Протокол HTTP устарел – пришло время распределенной перманентной Сети

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

Объединив усилия с Protocol Labs, Neocities стал первым крупным сайтом, реализовавшим Межпланетную файловую систему (IPFS, InterPlanetary File System) в рабочей среде. Начиная с сегодняшнего дня, все веб-сайты Neocities можно просмотреть, заархивировать и разместить на любых IPFS-узлах в мире. Если один из IPFS-узлов решит разместить у себя сайт от Neocities, эта версия сайта останется доступна даже в том случае, если Neocities прекратит работу или хостинг этого сайта у себя. Чем больше IPFS-узлов обслуживают сайты Neocities, тем доступнее (и избыточнее) эти сайты и тем менее централизована их зависимость от нас.

Что такое IPFS? Вот выдержка из файла README:

«IPFS — это распределенная файловая система, созданная с целью объединить все вычислительные устройства. В некоторых отношениях это похоже на первоначальные цели создателей Web, но на самом деле IPFS больше похожа на торрент-рой, обменивающийся объектами git. IPFS может стать новой важной подсистемой Интернета. Если построить ее правильно, она сможет дополнить или заменить HTTP и не только. Это кажется безумием — так оно и есть».

Разработка IPFS пока продвинулась только до выпуска альфа-версий, так что мы все еще считаем проект во многом экспериментальным. IPFS (пока) не заменила наще существующее хранилище сайтов, и, как и в любую новую сложную технологию, в нее предстоит внести еще много улучшений. Однако IPFS — не vaporware, а рабочая система. Вы уже можете попробовать ее и использовать на своем компьютере, если хотите помочь нам  хранить сайты Neocities и обслуживать их посетителей.

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

Часть 1. Что не так с HTTP?

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

Я люблю HTTP и всегда буду любить. Это действительно одно из величайших и важнейших изобретений всех времен.

И все же, несмотря на то, что HTTP позволил многого достичь, он становится слишком ненадежной основой для распространения и сохранения корпуса человеческих знаний. Способ распространения контента в HTTP фундаментально дефектен, и это не исправить никакой настройкой производительности или заменой скомпрометированных SSL-сертификатов. Попытку исправить ситуацию с помощью HTTP/2 можно только приветствовать, но это всего лишь консервативное обновление технологии, которая уже проявляет признаки старения. Чтобы создать лучшее будущее для WWW, нам нужна не просто улучшенная версия HTTP — нам нужен новый фундамент. Ну а, согласно модели управления киберпространством, это означает, что нам нужен новый протокол. Я очень надеюсь, что им станет IPFS.

HTTP хрупок

Компьютер NeXT Тима Бернерс-Ли в CERN — первый HTTP-сервер в мире. На компьютере виден стикер с предупреждением «Это сервер, не выключайте его!!«

Причина, по которой нельзя выключать веб-сервер, состоит в том, что на опубликованные на нем веб-сайты ссылаются сайты, расположенные на других серверах. Работоспособность любого сайта зависит от существования и доступности серверов с сайтами, на которые ссылаются ссылки с сайта-источника. Если веб-сервер отключить, ссылки перестают работать. Если же сервер выходит из строя или больше недоступен в прежнем месте, все гораздо хуже: цепь между сайтами разрывается, и доступ к их контенту утрачивается навсегда. Стикер на компьютере Тима Бернерс-Ли прекрасно демонстрирует крупнейшую проблему с HTTP: он подвержен «эрозии».

Первый веб-сервер стал музейным экспонатом — но еще и первым из миллионов будущих мертвых веб-серверов.

Наверняка все вы видели такое сообщение:

Даже если вы никогда не читали спецификацию HTTP, вы, вероятно, знаете, что означает 404. Это код ошибки, возвращаемый протоколом HTTP, если сайт больше не находится на сервере в указанном месте. Однако обычно в таких случаях на прежнем месте нет даже сервера, который мог бы ответить вам, что нужного вам контента у него нет и что он не в состоянии помочь вам найти его. Если этот контент не был сохранен в архиве Интернета, вы больше никогда его не найдете. Он утрачен навсегда.

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

В 90-х мне очень нравился сайт Mosh to Yanni, и, заглянув на него сейчас, вы сами убедитесь, насколько плохо HTTP подходит для поддержания ссылок между сайтами. Весь статичный контент, сохраненный на сайте, все еще загружается, и мой современный браузер в состоянии отобразить страницу (в отличие от HTTP, HTML держится вполне неплохо). Но любые ссылки с сайта и ссылки на динамический контент мертвы. Возможно, потеря этого контента — не такая уж и беда, но на каждый такой сайт приходятся бесчисленные примеры невероятно полезного контента, который также давным давно стал недоступен. Является ли такой контент сомнительным мусором или имеет непреходящую ценность, это все же наша история, и мы быстро ее теряем.

Причина, по которой это происходит, проста: центрально управляемые веб-серверы неизбежно рано или поздно покидают сеть. Возможно, владелец домена продает его или оставляет бизнес. Возможно, сервер выходит из строя, а у администратора нет резервной копии контента. Если каждый развернет свой личный HTTP-сервер, это не решит проблему и даже может усугубить ее.

HTTP способствует сверхцентрализации

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

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

Предполагалось, что Сеть должна быть децентрализованной, но Сеть, с которой мы имеем дело сегодня, быстро централизуется по мере того как миллиарды пользователей становятся зависимыми от небольшого количества сервисов. Независимо от того, считаете ли вы это приемлемым, протокол HTTP замышлялся не таким. Организациям вроде АНБ (и нашим будущим роботам-правителям) теперь достаточно перехватывать коммуникации всего лишь в нескольких источниках, чтобы шпионить за нами. Это позволяет государствам легко цензурировать контент на их границах, блокируя для сайтов доступ к централизованным ресурсам, и подвергает коммуникации риску DDoS-атак.

Распределение Сети может подорвать возможности могущественных организаций манипулировать доступом к ней и сделать нас более свободными и независимыми. Кроме того, это сократило бы риск крупного сбоя, способного привести к утрате крупного объема данных.

HTTP неэффективен

На день написания этой статьи ролик Gangnam Style был просмотрен 2 344 327 696 раз. Давайте, посмотрите его еще раз, я подожду:

Выполним кое-какие расчеты. Объем видеоролика составляет 117 МБ. Это означает, что со дня его публикации серверы отправили 274 286 340 432 МБ, или 274,3 ПБ только видеоданных. Если исходить из 1 цента за гигабайт трафика, получается, что на распространение одного лишь этого файла было потрачено 2742 860 долларов.

Это не так уж и плохо… если вы Google. Но если вы управляете меньшим сайтом, расходы на обслуживание такого объема данных сильно ударили бы по вашему карману, особенно если учесть, что для меньших компаний тарифы на пропускную способность начинаются примерно с 12 центов и доходят в Азии до 20 центов за гигабайт. В Neocities я провел много времени, сражаясь с этой проблемой, чтобы сократить расходы на обслуживание нашей инфраструктуры.

Да, HTTP удешевил публикацию контента, но это все равно значительная расходов. Распространять большие объемы контента из центров данных может быть очень дорого, если вы не в состоянии сэкономить благодаря масштабу обслуживания.

Что, если вместо получения этого контента из центров данных мы могли бы добавить каждый компьютер, подключенный к сети интернет-провайдера, в поточную CDN (сеть доставки контента)? Тогда популярное видео вроде Gangnam Style можно было бы полностью скачивать из сети провайдера без передачи многочисленных пакетов по магистралям Интернета. Это лишь один из примеров того, что может улучшить файловая система IPFS.

HTTP создает чрезмерную зависимость от интернет-магистралей

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

Я сам испытал странный вкус такой проблемы несколько месяцев назад, когда автомобильный инцидент привел к замедлению работы Neocities (подозреваемых пока нет, но есть несколько многообещающих зацепок). Я также слышал истории о том, что охотники стреляли в кабели, соединяющие центры данных в восточном Орегоне (огромные центры, хранящие действительно много данных),  — для восстановления связи инженерам пришлось выезжать на ремонт на снегоходах! Совсем недавно появились подробности об атаках на кабели в области залива Сан-Франциско… В общем, интернет-магистрали не совершенны, их легко атаковать, и, чтобы причинить много проблем, достаточно просто перерезать несколько важных кабелей.

Часть 2. Как IPFS решает эти проблемы

Мы обсудили проблемы HTTP (и сверхцентрализации). Давайте теперь поговорим о том, как IPFS может помочь улучшить WWW.

Самое важное в IPFS то, что она фундаментально изменяет способ поиска контента. Используя HTTP, вы ищете места расположения контента. В IPFS вы ищете сам контент.

Позвольте пояснить это на примере. Вот файл на моем сервере: https://neocities.org/img/neocitieslogo.svg. При переходе по этой ссылке ваш браузер сначала находит расположение (IP-адрес) сервера с файлом, а затем запрашивает у сервера сам файл, указывая путь к нему. При такой архитектуре только владелец сервера (я) определяет, какой файл выдать вам в ответ на запрос, и вы вынуждены полагаться на меня в том, что я не перемещу файл и не отключу сервер.

Что, если вместо того, чтобы искать центрально контролируемое расположение и просить у сервера нечто, расположенное по пути /img/neocitieslogo.svg, мы запрашивали бы у распределенной сети из миллионов компьютеров не имя файла, а контент, который должен находиться в файле?

Именно это и делает IPFS.

Когда файл neocities.svg добавляется на мой узел IPFS, он получает новое имя: QmXGTaGWTT1uUtfSb2sBAvArMEVLK4rQEcQg5bv7wwdzwU. На самом деле это криптографический хеш, представляющий содержимое этого и только этого файла. Если я изменю в файле хоть один бит, хеш полностью изменится.

Когда я запрашиваю у распределенной сети IPFS этот хеш, она эффективно — за 20 «скачков» (hops) в случае сети из 10 миллионов узлов — находит узлы с этими данными с помощью распределенной хеш-таблицы (DHT), получает и проверяет их. В любой системе с DHT есть проблемы с атаками Сибиллы, но у нас есть новые способы их решения, и я уверен, что они решаемы (в отличие от проблем с HTTP, которые его погубят).

IPFS — система общего назначения и почти не ограничена в плане объема хранилища. Она может эффективно хранить и возвращать как небольшие файлы, так и крупные. Она автоматически делит крупные файлы на меньшие блоки, что позволяет узлам IPFS скачивать (или получать в поточном режиме) файлы не только с одного, но сразу с сотен серверов. Сеть IPFS — это федеративная распределенная CDN «без доверия» с широкими возможностями точной настройки. Она прекрасно подходит для обслуживания любых данных: изображений, поточного видео, распределенных баз данных, целых операционных систем, блокчейнов, резервных копий дискет и, что для нас важнее всего, статичных веб-сайтов.

Файлы IPFS могут также быть специальными объектами каталогов IPFS, что позволяет использовать понятные людям имена файлов (которые прозрачно ссылаются на другие хеши IPFS). Вы можете загрузить файл index.html каталога так же, как и при работе со стандартным HTTP-сервером. Благодаря объектам каталогов IPFS вы можете создавать статичные веб-сайты так же, как вы делаете сегодня. Добавить веб-сайт на узел IPFS можно одной командой: ipfs add -r yoursitedirectory. После этого сайт доступен с любого узла IPFS, и в HTML-коде вам даже не нужно ссылаться на какие-либо хеши (вот один пример, а вот второй пример с переименованным файлом index.html).

Интеграция данных с помощью IPFS

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

Если небольшие фрагменты контента размещены на большом количестве узлов, их ресурсы быстро суммируются в бОльшее место на диске, бОльшую пропускную способность и лучшую доступность, чем когда-либо сможет предоставить любой централизованный HTTP-сервис. Распределенная веб-сеть может за сравнительно небольшое время стать самым быстрым, самым доступным и крупнейшим хранилищем данных на Земле. В такой системе никто не сможет «сжигать книги», отключая сайты. Александрийская библиотека больше не сгорит никогда.

Скопировать веб-сайт в IPFS, сохранить его и помочь отправлять его контент пользователям совсем несложно. Достаточно ввести одну команду с хешем сайта — ipfs pin add -r QmcKi2ae3uGb1kBg1yBpsuwoVqfmcByNdMiZ2pukxyLWD8, — а об остальном позаботится IPFS.

IPNS

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

IPNS позволяет взять хеш IPFS, представляющий с помощью открытого ключа последнюю версию вашего сайта, и подписать ссылку на него с помощью закрытого ключа. Если вы использовали Биткойн, схема должна быть вам знакома: биткойн-адрес — это тоже хеш открытого ключа. Например, на нашем IPFS-узле Neocities я подписал изображение Пенелопы (маскот нашего сайта), и вы можете загрузить его, используя IPNS-хеш открытого ключа этого узла: QmTodvhq9CUS9hH8rirt4YmihxJKZ5tYez8PtDmpWrVMKP.

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

Теперь нам просто нужно сделать так, чтобы расположения этих сайтов были понятны людям, и у нас есть все, что для этого нужно.

Изменяемая адресация, понятная людям

Хеши IPFS/IPNS — это большие уродливые строки, которые трудно запомнить. Поэтому IPFS поддерживает существующие DNS-имена, чтобы можно было предоставлять понятные ссылки на контент IPFS/IPNS. Для этого следует вставить хеш в TXT-запись на сервере имен (если у вас под рукой командная строка, выполните эту команду: dig TXT ipfs.git.sexy). Вы можете увидеть все в действии, посетив адрес http://ipfs.io/ipns/ipfs.git.sexy/.

Далее у нас есть планы по реализации в IPFS поддержки Namecoin, что теоретически позволяет создать полностью децентрализованную распределенную Сеть без какого-либо центрального авторитета. Только подумайте: никакого ICANN, никаких центральных серверов, никаких политик, никаких дорогостоящих центров сертификации и никаких критических уязвимых мест. Это кажется безумием — так оно и есть. И все же с современными технологиями это вполне возможно!

HTTP-шлюз IPFS: мост между старым и новым WWW

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

Как мы используем IPFS сейчас

Наша первоначальная реализация IPFS является пока экспериментальной и ограниченной. Neocities будет публиковать хеш IPFS раз в день при обновлении сайтов, и он будет доступен из профиля каждого сайта. Этот хеш будет указывать на новейшую версию сайта и будет доступен через наш HTTP-шлюз IPFS. Поскольку хеш IPFS изменяется при каждом обновлении, мы также сможем вести архивную историю всех сайтов — эту возможность мы «автомагически» получаем благодаря особенностям IPFS.

Как мы будем использовать IPNS в будущем

Если все пойдет хорошо, мы хотим использовать IPFS для хранения всех наших сайтов и выпускать ключи IPNS для каждого сайта. Это позволит пользователям публиковать контент на их сайтах независимо от нас. При условии, что мы сделаем все правильно, наши пользователи смогут обновлять свои сайты, даже если Neocities прекратит существование. Мы дробим центральную зависимость пользователей от наших серверов на части, что раз и навсегда подрывает наши потенциальные планы по завоеванию централизованного мира. Как вам это?

Мы все еще в начале пути, и нужно многое сделать, прежде чем замену HTTP системой IPFS перестанут воспринимать как безумие. Но планировать будущее и готовить Интернет к нему нужно уже сейчас. Отнеситесь к призыву Internet Archive серьезно: распределите Веб.

Кайл (kyledrake), 8 сентября 2015 года

Источник: blog.neocities.org

Neocities в Twitter: https://twitter.com/neocitiesweb