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