В последнее время в хабрасообществе довольно активно обсуждаются темы, связанные с пиратством, закручиванием правительствами всевозможных гаек и прочим беспределом. Обсуждаются варианты противодействия политике контроля, цензуры и деанонимизации сети.
Странно, что на всем этом фоне не было ни одного поста о таком занимательном проекте, как Netsukuku. Цель которого, ни много ни мало — построить свой интернет с шахматами и администраторшами.
Бред? Не совсем.
Начнем с основ. Всеми любимый нами интернет изначально создавался как военная система, к которой предъявлялись жесткие требования к надежности и отказоустойчивости. В идеале, сеть должна была работать даже после потери части узлов и в случае ядерной войны. Ну это мы и так знаем :)
На деле же, все замкнулось на бюрократию. Будучи отказоустойчивой по натуре, сеть основана на магистралях и централизованных службах вроде InterNIC, IANA и всецело зависит от них. Российский интернет долгое время вообще был сконцентрирован практически в одной точке (М9), отказ которой привел к сетевой катастрофе несколько лет назад.
Помимо сугубо технических проблем, существуют еще и политические — каждое мало мальски определившееся государство стремится если не управлять, то контролировать свой трафик. В особо запущенных случаях, это выражается в полнейшей блокаде всего контента, кроме богоугодного. Под эгидой борьбы с пиратством придумываются всевозможные законы, распускающие руки юристам, спецслужбам и прочим приятным конторам. Да и сами провайдеры отнюдь не стремятся предоставить пользователю максимум удобств — и трафик режется, и порты блочатся.
Ну и?
В противовес всему этому, горячими итальянскими парнями был основан проект с японским названием — Netsukuku. Это проект реализации отказоустойчивой, распределенной, самоорганизующейся сети, построенной на базе существующих сетевых технологий, таких как TCP/IP и WiFi. Сам софт крайне нетребователен к ресурсам и может выполняться даже на embedded устройствах, вроде точек доступа и SOHO маршрутизаторов.
Основной особенностью данной технологии является то, что она позволяет строить меш сети с динамической маршрутизацией размером до 2128 узлов (!). Причем строить это громко сказано — достаточно запустить на устройстве демон, а остальное произойдет автоматически.
В отличие от Freenet, N зависит от Интернета только частично и в перспективе вообще может от него отказаться. Следует отметить так же, что Netsukuku работает на 3-ем уровне модели OSI и подразумевает построение независимой физической сети передачи данных. То есть, это не еще один прикладной протокол поверх интернета, а самостоятельная сеть.
Хм… А подробнее?
Итак, по порядку. Основой всей сети Netsukuku является узел. Узел — это сетевое устройство (точка доступа либо ПК пользователя) с выполняющимся на нем софтом, обеспечивающем маршрутизацию. Все узлы равноправны между собой, нет никаких различий между конечным узлом пользователя и маршрутизатором, объединяющем несколько смежных подсетей. Сама сеть подразумевает использование беспроводных технологий, как наиболее удобных в плане масштабирования и подключения.
Как только пользователь запустил на своем устройстве демон Netsukuku, его узел начинает кидать широковещательные пакеты с целью обнаружить соседей. Как только сосед обнаружен, происходит обмен маршрутной информацией, назначение адреса и прочие дела; после этого наш клиент становится полноправным членом сети и может незамедлительно начать ею пользоваться — для пользовательских приложений все происходит совершенно обыденно и прозрачно.
С технической точки зрения — это большая локалка с динамической маршрутизацией и собственными серверами имен. Маршрутизацию обеспечивает демон, руля таблицей маршрутизации ядра. Остальное остается как есть.
Ключом ко всей идее является квантовый протокол маршрутизации QSPN(англ.) а так же иерархическая топология сети, которые вместе обеспечивают быстрый и вычислительно легкий способ поиска маршрута между двумя произвольными узлами, по эффективности близкого к наилучшему.
Топология сети
Маршрутизация в сети интернет — дело непростое. Магистральные маршрутизаторы представляют собой эдаких монстров с огромным (с точки зрения домашнего маршрутизатора) количеством памяти и сумасшедшей производительностью. Все потому, что они являются узким местом сети — весь региональный трафик прет через ограниченное количество каналов. Выбор подходящего машрута осуществляется с применением сложных алгоритмов на графах. Все это не способствует простоте построения современных сетей и их управления.
Если попытаться построить сеть размером с интернет по принципу «каждый с каждым» используя обычные технологии, то это потребовало бы огромных расходов памяти, не говоря уже о производительности. Даже если бы мы хранили всего один маршрут от одного узла до другого, и даже если бы эта информация занимала всего один байт, то для современного Интернета (порядка 109 узлов) потребовался бы 1 гигабайт памяти. На каждый узел!
Сеть Netsukuku строится иерархическим образом: каждые 256 узлов объединяются в т. н. групповой узел (gnode); 256 групповых узлов составляют уже группу более высокого порядка (ggnode) и так далее. Поскольку каждая групповая нода является таким же полноправным узлом сети, протокол QSPN может работать одинаково на всех уровнях иерархии. При этом, при поиске маршрута, в каждом случае он оперирует максимум 256 узлами, что делает сам поиск очень легким.
Наконец, для хранения самих маршрутов применяется фрактальный подход — из-за высокого самоподобия сети получается возможным упихать всю информацию всего в несколько килобайт (4К для 232 узлов).
Обнаружение маршрутов и трассировка
Основой протокола QSPN является трейс пакет (TP). Это пакет, который содержит в себе идентификаторы узлов, через которые он прошел. Этот пакет не отправляется кому-то конкретно. Вместо этого, устраивается натуральный трейс флуд. Когда мы говорим, что «узел А отправил TP пакет», это значит что «узел А начал трейс флуд».
За сессию, трейс пакет проходит каждую ноду только единожды. Приняв TP, нода отправляет его всем своим соседям (разумеется, кроме соседа-источника), дописывая себя в него. Однажды поучаствовав в сессии флуда, нода больше не будет пересылать приходящие TP, относящиеся к этому же флуду.
Таким образом получается, что каждая нода, принявшая TP получает полную информацию о маршруте до узла отправителя, а так же до каждого из узлов-посредников. Поскольку изначально узел А отправляет несколько TP (каждому из своих непосредственных соседей), то в каждый момент времени, в сети существует несколько версий TP, относящихся к одному и тому же флуду, называемых «букетом».
Произвольный узел Х, приняв первый TP от узла А и заглянув внутрь пакета — внезапно получает кратчайший маршрут с минимальным RTT до узла А, а так же всех узлов цепочки :) Последующие пришедшие пакеты будут уже альтернативными маршрутами, соответственно, более длинными. Таким образом, маршрутная информация собирается автоматически, причем на основании реальной топологии сети и задержек.
Конец первой части
В заключение хотелось сказать пару слов о текущем положении дел в проекте. Во-первых, как уверяют разработчики, проект живет и здравствует. На данный момент написана документация и реализация демона на Питоне, которая должна заменить устаревшую версию на Си. Во-вторых, полноценного запуска сети еще не осуществлялось, но очень надеюсь, что он произойдет в скором времени.
Информацию по теме можно найти на официальном сайте проекта; существует так же вики, а так же FAQ (+ версия на русском)
P.S.:
Ну вот и все на сегодня :) Хотел написать больше, да глаза уже слипаются и голова не соображает.
В следующей части я напишу более детально о типах трассировочных пакетов и о важном механизме разрешения коллизий IP адресов. Пару слов будет сказано и о системе именования хостов — аналогу обычного DNS. Возможно так же, места хватит и на взаимодействие сети с Интернетом.
Разумеется, если у вас есть вопросы и предложения — милости просим. Постараюсь ответить. Да, и еще: я не являюсь (пока?) разработчиком этой системы и не представляю всех тонкостей алгоритмов. Но информация есть и желание ее освоить тоже.
