Три бюро, эту штуку правда пилить с нуля — сложность вообще не в том, чтобы «написать форвардер», а в том, чтобы «вывезти кучу грязной и тяжёлой работы».
Примерно вот эти кучи:
-
Проектирование протокола
как делать рукопожатие
как делать аутентификацию
нужна ли мультиплексация
как единообразно обработать UDP, TCP, DNS
сначала ради простоты, потом почти всегда переписывают из‑за расширяемости -
Кроссплатформенный сетевой стек
Windows / Linux / macOS / Android / iOS ведут себя совершенно по‑разному
TUN/TAP, системный прокси, маршрутизация, перехват DNS — везде разные
по‑настоящему мерзко именно совместимость платформ, а не те несколько строк socket-кода -
Производительность
как только соединений много — проблемы сразу вылезают
buffer, copy, конкуренция за lock, планирование корутин, фрагментация памяти, накладные расходы syscall
то, что одно соединение летает, не значит, что в реальности оно «потащит» -
Стабильность
переподключение после разрыва
переключение сети
сон/пробуждение
NAT / IPv6 / MTU / фрагментация
когда инцидентов много, от логов можно словить PTSD -
Шифрование и безопасность
обмен ключами
защита от повторов (replay)
прямая секретность (forward secrecy)
восстановление сессии
безопасная доставка конфигурации
тут самое страшное — «придумывать криптографию самому»: это значит сознательно усложнить себе жизнь -
Стратегия трафика и инкапсуляции
как резать пакеты
как прятать header
как сделать так, чтобы сигнатуры не были слишком фиксированными
это не про «лишь бы общалось», а про «чтобы долго не взрывалось» -
Обработка DNS
локальное разрешение или удалённое
DoH / DoT / чистый UDP
отравление, кэш, консистентность, утечки
куча проблем «вроде подключилось, но как-то странно» почти всегда упирается в DNS -
Маршрутизация и раздельная проксировка
глобально, по правилам, по домену, по IP, по процессу
GeoIP / GeoSite / пользовательские правила
система правил со временем всё больше становится похожа на половину интерпретатора -
Наблюдаемость (observability)
логи
tracing
состояние соединений
панель статистики
без этого отладка превращается в мистику и «искренне верь — и заработает» -
Система конфигурации
горячие обновления
совместимость конфигов
миграция версий
проверка schema
пользователи обожают писать конфиг как попало, а потом ругать ядро за нестабильность -
Клиентская экосистема
GUI
подписки
импорт/экспорт конфигурации
интеграция с системой
когда делаешь продукт, объём кода ядра не всегда самый большой — обвязка зачастую больше -
Подводные камни AI‑ассистированного программирования
AI отлично пишет сетевой код, который «выглядит правильным»
но в конкурентности, граничных условиях и протокольных state machine он очень легко закладывает мины
может помочь собрать каркас, дописать шаблоны, написать тесты
но не может вместо тебя верифицировать корректность протокола
в итоге часто получается: AI за 5 минут накидал код, а ты 5 часов потом сниффишь пакеты и ищешь виновника
Если делать только простой «core», то самые реалистичные инженерные сложности на практике такие:
сначала чётко определить минимальную цель
не начинать сразу с кроссплатформенности
не начинать сразу с собственного протокола
не начинать сразу с движка правил
не начинать сразу с «универсальной высокопроизводительной архитектуры»
Иначе очень легко получится так:
Первая неделя: я сделаю ядро следующего поколения
Вторая неделя: для начала заставлю TCP-проксирование работать
Третья неделя: почему DNS опять взорвался
Четвёртая неделя: пойду лучше замодю существующий проект
Одной фразой — резкая оценка:
написать с нуля «чтобы бегало» не так уж сложно, сложно написать «долгоживущее, сопровождаемое, кроссплатформенное, стабильное, расширяемое и не тормозное».
Если ты хочешь оценить «сложность MVP с нуля при помощи AI», могу продолжить в этом ключе и разложить так:
прототип на 2 недели
за 1 месяц — чтобы самому пользоваться
за 3 месяца — чтобы сопровождение не стало тюрьмой
вот такие версии.