Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 60
Автор, похоже в https://t.me/Yggdrasil_ru меня забанили, как туда попасть?
Огромное спасибо за статью! Теперь понял, что такое CKR и зачем он нужен.
Если сделали новые крейты то опубликуйте их в git и на crates.io
Дело, похоже, полезное. Ну не люблю я Go.
P.S. ночью надо спать
Yggdrasil переписан, конечно, не весь. Только то что нужно непосредственно в проекте. Просто по объёму кода понятно.
Да, я не стал добавлять транспорты QUIC и WS, о добавлении которых автор yggdrasil-go уже жалеет.
Добавь, пожалуйста, автопиринг. Без него - беда-печаль-огорчение.
Ну WS-транспорт может быть полезным чтобы подольше от DPI прятаться. Другие варианты имеют уж очень приметные сигнатуры, а QUIC бывает целиком отсыхает из-за РКН - вот тут да, в наших реалиях он бесполезен.
Да, "это не цель Yggdrasil" (c), но все же если что-то работает - оно имеет право на жизнь.
По теме - мне надо обязательно найти время пощупать. Отсутствие CKR в go-реализации - это то, из-за чего у меня боль-дырка-задница
Поверх go реализации отлично строятря GRE и GIF туннели с ipv4/ipv6 внутри. Учитывая что MTU на yggdrasil интерфейсе большой (на порядки больше 1500 байт), то туннели не страдают от низкого MTU. Все работает идеально
Да понятно, что можно руками настроить любых туннелей, причем благодаря mesh-у даже GRE становится вполне себе отказоустойчивым без всяких цисковых приблуд - ибо поиск маршрута до remote-точки туннеля перекладывается на сам mesh - значит пока хоть какой-нибудь путь есть туда - живём(пусть и не быстро).
Хотелось бы встроенного функционала, чтоб не конфигурять в куче мест, но я понимаю - "не цель" :-)
ygg довольно зрел, просто из возраста
хватает разного готового и полуготового в сети
yggdrasil-go это сетевое ядро, там и не должно быть встроено всякое пользовательское, наоборот там можно местами и срезать для оптимизации а то хвататает старых "костылей" особено в админ-режиме
если вам именно "простая отказоостойчивость" то есть например вот пирменеджер https://github.com/voluminor/ratatoskr/tree/main/mod/peermgr что бы ковровые баны и прочее не сильно вляли на ваш вход в сеть (что есть основной причиной нестабильности)
потому как чистый мультикаст это просто превосходный вектор атаки и такое катит только для доверенных локальных сетей (есть хорошее иследование на эту тему https://ceur-ws.org/Vol-3790/paper10.pdf) и лучше таки переключатся и искать среди добавленых ручками в которых ты уверен
Кстати, в последнем релизе Yggdrasil-ng появились ws://, wss:// и quick:// пиринги ;)
Последняя версия Yggdrasil-ng, 2 компа в одной локальной сети(один вайфай роутер) подключены проводом, через ygg скорость iperf3 - 30мбит в обе стороны. Напрямую и через nebula скорость упирается в канал. ЦПУ нагрузка около 0.
yggdrasil peers показывает что трафик идет напрямую (найден локальный пир и трафик идет к нему).
Скорость до компов в интернете больше.
Слишком мало информации для диагностики.
С одной стороны win11 с другой win2019. Пиров нет, только локальное обнаружение. Подключены в один коммутатор проводами.
iperf3 -c <ip> [-R] показывает 30мбит
[ 5] 4.01-5.01 sec 3.75 MBytes 31.4 Mbits/sec
[ 5] 5.01-6.00 sec 3.62 MBytes 30.6 Mbits/sec
[ 5] 6.00-7.01 sec 3.75 MBytes 31.1 Mbits/sec
[ 5] 7.01-8.00 sec 3.62 MBytes 30.7 Mbits/sec
[ 5] 8.00-9.01 sec 3.75 MBytes 31.3 Mbits/sec
[ 5] 9.01-10.01 sec 3.75 MBytes 31.4 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.01 sec 37.1 MBytes 31.1 Mbits/sec sender
[ 5] 0.00-10.01 sec 36.9 MBytes 30.9 Mbits/sec receiverНапрямую и через другой впн - 94мбит.
Ну так всё зависит от процессора ещё. И попробуйте без обнаружения, по линку tcp, для чистоты эксперимента.
Процессоры райзен и i9, они точно не причина низкой скорости.
Без обнаружения один слушает другой подключается, других пиров нет, скорость 30мбит. То есть тоже самое.
Если подключить одинаковых внешних пиров и попробовать скорость до разных сайтов то у них почему то разная скорость получается, причем сильно. До одних сайтов один быстрее до других другой и разница может быть в десятки мбит.
а как насчет пиров через сокс?
А какие с ним проблемы? У меня на одной публичной ноде (рф) 25% QUIC и 27% WS клиентов.
QUIC работает в РФ не везде и не у всех, а как поднял WS транспорт жалоб на него не было
На другой ноде (в Азии) почти 31% QUIC соединений (там WS не настроено)
Я сам обычно QUIC использую и проблем с ним не замечал.
Прелесть WS в том что оно отлично замаскировано если ygg-go работает как бэк для nginxа где еще и сайты крутятся (у меня такие инсталляции тоже есть, но это не публичные ноды)
Я лично замечал когда HTTP/3 подымал на своих сервисах - что браузеры начинают "болеть" при доступе на них на некоторых провайдерах. Сервера как в РФ, так и зарубежом, провайдеры разные, но все в РФ. При этом если пробовать достучаться до зарубежного сервера с других места(не из РФ) - всё тип-топ. А самая дичь - что это непостоянно и не везде такие проблемы, что добавляет увлекательности отладке. Глазеть на то, что значительная часть пакетов по UDP/443 не долетает до точки назначения - веселого мало.
But why?
Интересно, пишите ещё :)
Я бы почитал про pathfinder и вообще про сходимость сети подробнее.
Отличная работа! С точки зрения выбирания что дальше - интересно всё, но в данный момент больше интересует CKR на практике ввиду новых ограничений, ну и так же очень рассчитываю на полную транспортную совместимость в перспективе с go версией
ох уж это неутомимое желание переписать всё на раст...
особенно с помощью ллмки
Каковы минусы?
Теперь есть зависимость от Claude Code в написании? Предыдущие контрибьюторы не смогут продолжать участвовать в проекте? После беглого прочтения как минимум эти два пункта отметил.
Почему это? Язык программирования вдруг сменился чем-то нечитаемым, что ли?
Давайте "обстучим" мнение об нейтрального/нейронного арбитра. Вот что отвечает LLM, если попросить расписать какие могут быть минусы перехода вашего проекта на Rust:
1. Точка зрения "Контрибьюторы и Сообщество"
Это, вероятно, самый болезненный аспект перехода.
Потеря текущего пула контрибьюторов: Оригинальный
yggdrasil-goнаписан на Go, который известен своей простотой и низким порогом входа. Многие текущие контрибьюторы (особенно из "энтузиастской" среды, сетевых инженеров и Go-разработчиков), скорее всего, не владеют Rust. Рерайт фактически заставит их либо изучать новый язык (что требует времени), либо уйти из проекта
Читать целиком
Проблема "Псевдо-активных контрибьюторов": Автор рерайта (Yggdrasil-ng) честно признался, что не писал код сам, а давал задания нейросети Claude. Если основная масса "новых" контрибьюторов будет генерировать код через LLM, в проекте резко возрастет количество кода, который компилируется, но содержит логические ошибки. Это приведет к падению качества ревью, так как поддерживать и проверять такой код сложнее, чем написанный вручную.
2. Точка зрения "Стабильность и Логические Ошибки"
В отличие от memory safety ошибок, Rust не спасает от ошибок логики и многопоточности (data races), которые являются бичом сетевых протоколов.
Пример из практики (Гонка таймеров): В ходе переписывания на Rust была совершена классическая ошибка — изменение замыкания переменной в асинхронном потоке. Автор подсчитал время RTT для пиров неправильно (один раз в момент старта читателя), из-за чего задержка росла с каждой секундой работы сети. Этот баг не проявился на малых тестовых сетях, но убивал большую публичную сеть через час работы.
Парадокс: Rust безупречно управляет памятью, но для сетевых протоколов критична математика состояний. Проверка borrow checker не нашла бы проблему, которая убивала сеть через 60 минут.
Сложность отладки в распределенных системах: Yggdrasil — это не монолит, а распределенный маршрутизатор с DHT, Spanning Tree и CRDT-подходами. Баги, которые в Go можно было отловить дебаггером и
panic()с стектрейсом, в Rust при неправильном использованииunwrap()илиexpect()приведут к тихому падению узла, что в распределенной системе диагностировать крайне трудно.
3. Точка зрения "Поддержка и Сопровождение"
Проект Yggdrasil имеет сложную кодовую базу, основанную на акторной модели (фреймворк phony).
Миграция "Бездны": Полный рерайт — это не перевод синтаксиса 1:1. Языки имеют разные парадигмы конкурентности. Go использует горутины и каналы (свой акторный фреймворк). Rust использует async/await (tokio) или акторные крейты (actix, ractor). Переписывать логику акторов, управляющих маршрутизацией, нужно вручную. Малейшее различие в порядке обработки сообщений приведет к рассинхронизации с протоколом оригинальной сети.
Долг перед совместимостью: Rust-версия должна быть байт-код-совместима с Go-версией по wire-протоколу. Как показала практика, это очень тонкая работа: даже реализация хеширования FNV-128 или алгоритма конвертации ключей Ed25519->Curve25519 должна идеально совпадать, иначе ноды не увидят друг друга в DHT.
Документация vs Код: Go версия уже много лет является "черным ящиком" со сложной матчастью, где оригинальный автор признавался, что документирует мысли "в виде каши". Rust версия, написанная нейросетью, рискует стать еще более сложной для понимания будущими сопровождающими, которые не участвовали в "магии" конвертации ключей и алгоритмов.
4. Точка зрения "Технический долг и Цикл разработки"
Инкрементальные улучшения против "Big Rewrite": В разработке ПО известен анти-паттерн "полного переписывания". Go-версия, хоть и имеет свои недостатки (сборщик мусора, который мешает встраиванию в другие языки), работает и стабильна в продакшене (игрушечный проект вырос в рабочую сеть). Переписывание замораживает развитие функциональности на годы (пока Rust-версия не догонит Go по возможностям).
Проблема с Embedded-разработкой (Ironwood): Рерайт на Rust был мотивирован созданием Android-мессенджера Mimir. Однако текущая архитектура Go изначально плохо подходит для мобильных платформ без накладных расходов на CGO и GC. Rust решает эту проблему (компиляция в lib, отсутствие рантайма). Но: поддержка Rust на мобильных платформах (iOS/Android) сложнее, чем Go. Собирать
.soи.aбиблиотеки и биндить их через FFI (Foreign Function Interface) в Swift/Kotlin — технически сложная задача, требующая специфического DevOps-скилла.
5. Точка зрения "Архитектура протокола"
Проблема GC не так страшна: Основная причина рерайта — "GC мешает интеграции". Однако в сетевых overlay-сетях главным тормозом обычно является не GC, а системные вызовы (syscalls) чтения/записи в TUN/TAP интерфейс и копирование пакетов в пространстве пользователя. Оригинальный автор явно указывал, что накладные расходы Go на TUN очень высоки. Rust может это исправить, но также может и оптимизированная Go-библиотека. Переписывать весь проект ради "ускорения в 2 раза", рискуя "полным падением сети каждые 2 часа", — сомнительная экономия.
И выводы (картинкой для красоты)
Важно: данная статья учитывалась в ответе.
как человек что изредка контрибютит в yggdrasil-go по мелочи могу сказать что сам код yggdrasil-go изначально не защищен от проблем или ошибок. Постоянно что то всплывает
Плюс оптимизации, некоторые места прям очень тонко заточены чисто под Го-фишки ради производительности. Просто навайбкодить подобие "в лоб" хорошая отправная точка, но как проект это по сути будет совершенно другой yggdrasil с совершенно другими проблемами и особеностями
Как по мне если бы хотели таки раст, то просто сам yggdrasil-go собрать в динамическую библиотеку и подключать в расте. Так было бы лучше на долгой дистанции для проекта
Ну а я сделал в лоб, а потом даже добавил всякие разные оптимизации, которых нет в гошной версии, но при этом не теряя совместимости с ней.
а оптимизации на глаз или с тестами?
я вот две с гаком недели нон стоп тестировал в разных позах свое решение что бы поймать все тонкие места (и поймал изрядно)
Причем yggdrasil-network ведет себя абсолютно по разному как с разными типами трафика, так и с количеством и качеством нод (мой кластер дальше 200 нод не заходил в тестах, по наблюдениям для проверки горячего хватает и десятка нод)
Причем некоторые веши вообще не очевидны и "трутся" об железячные/драйверные или сторонние используемые решения в процессе построения yggdrasil-network, а не об сами косяки реализации yggdrasil
А еще часть явно "опасных" или проблемных мест это не ошибка, а осознаное архитектурное решение, так как "безопасная реализация" режет пропускную способность
С тестами, конечно. Например, завёз туда реализацию Salsa20 на SIMD повышающую скорость обработки до 4х на некоторых устройствах.
Другую реализацию очереди и congestion control...
вот тулинга под конкретные процы и CGO в изначальном ygg не хватает это да
а вот за определние маршрутов и прочее - до сих пор же воюют в эту сторону и никак не могут прийти к оптимальному решению. А бы это вообще не трогал так как "оптимальность" в одном может ломать всю сеть в целом потому что для других ванильных нод у вашей будут другие цифры и от того поползут алгоритмы
это плюс и минус yggdrasil - его зрелость. Минус в том что любые работы над ядром нужно делать с оглядкой на поддержку легаси
то есть поставить этот через гайд ацетона не получится?
переписал Yggdrasil на Rust за 3.5 дня
:рукалецо:
Третий день пытаюсь навайбкодить простейшую гуи утилитку для установки yggdrasil на шиндоус комп. Установить/добавить пиров/запустить итп одной кнопкой.
У меня правда мистраль-кли вместо клода и джемини вместо кодекса, но и задача как будто бы не сложная.
Видимо придется подключать еще и глубоко больного китайца с илоном маском в команду мечты.
В сети ygg есть тор мосты, так что можно сделать себе на компе тор без постоянно попадающих в бан мостов, вместе с фильтрующим ркн-списками прокси получается вполне годное решение, я уже опробовал вручную - всё нормально работает.
держи - простая оббертка вокруг ядра как раз для нормального использования как го-модуль (потому как yggdrasil-go не расчитан на нормальное встраивание как модуль, это сетевое ядро в первую очередь) https://github.com/voluminor/ratatoskr
для вайбкодинга вот есть скилл https://www.skills.sh/voluminor/skill-yggdrasil/yggdrasil
Спасибо за статью! Пробовал ставить Ygg несколько лет назад, но неудобная настройка и неустойчивая работа отбивали энтузиазм. Теперь еще раз попробую, рад что проект развивается и совершенствуется.
Задам вопрос еще раз (ранее писал где-то глубоко в комментариях):
Реально ли интегрировать в подобные проекты криптоэкономическую модель, где владельцы узлов получают вознаграждениеза фактическую ретрансляцию трафика (Proof-of-Bandwidth или как)? Думается, это поможет равномерному пространственному распределению пропускной способности (владельцы будут заинтересовааны размещать узлы в узких местах), повышению устойчивости сети к блокировкам, автоматическому балансированию нагрузки
Еще когда смотрел видео про gonka ai, подумал о чем-то подобном, а тут на, децентрализованная сеть для обхода блокировок уже считай есть, осталось прикрутить монету
Реально ли интегрировать в подобные проекты криптоэкономическую модель, где владельцы узлов получают вознаграждениеза фактическую ретрансляцию трафика (Proof-of-Bandwidth или как)?
Нет, нереально, так как доказать, что какая-то нода прогнала какое-то количество легитимного трафика невозможно. Ну либо каждый на свою ноду закидывает монеты, и они ими обмениваются в реальном времени. И если на твоей ноде заканчиваются монеты, тебе никто трафик бесплатно не маршрутизирует. Только так :)
У yggdrasil есть серьезная проблема при работе через мобильную сеть в условиях чебурнета. Трафик мобильных операторов ходит по очень странным маршрутам, если телефон находится во владивостоке то трейс показывает что первый хоп - низкий пинг, а второй очень высокий, то есть трафик заходит в местную локальную сеть оператора, а дальше уходит в провайдерский туннель и выныривает где то в 7000км в условном Омске, и дальше обычно идет в москву где расположены все русские сайты и точки обмена трафиком. Для обычного интернета это не создает серьезных проблем но с пирингом и глушилками любые пиры показывают +- такой вот результат.
Добавлять локальные пиры бесполезно, трафик в любом случае будет бегать тысячи километров туда сюда обратно и по дороге его будут еще и глушить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Yggdrasil-ng: как я переписал Yggdrasil на Rust за 3.5 дня и неделю фиксил один баг