ostp/docs/ru/architecture.md

8.0 KiB
Raw Permalink Blame History

Системная архитектура OSTP

Обзор

Obfuscated Secure Transport Protocol (OSTP) — это высокопроизводительный асинхронный фреймворк сетевого туннелирования, разработанный для обеспечения безопасной, устойчивой и нераспознаваемой передачи данных в недоверенных сетях. Проект написан на Rust, гарантируя безопасность памяти, высокую конкурентность и минимальные накладные расходы.


Структура проекта

Проект состоит из следующих специализированных модулей (crates):

  1. ostp-core: Основа протокола. Содержит конечные автоматы состояний, реализацию рукопожатия (Noise Protocol Framework), механизмы сериализации кадров (framing), алгоритмы обфускации и логику надежной доставки пакетов (ARQ).
  2. ostp-client: Клиентский демон, управляющий перехватом трафика хоста через двухрежимный SOCKS5/HTTP-прокси или виртуальные адаптеры (TUN/Wintun), мультиплексированием потоков в единый UDP-туннель и взаимодействием с TURN для обхода NAT.
  3. ostp-server: Высоконагруженный диспетчер соединений, отвечающий за демультиплексирование данных от множества сессий, прозрачный роуминг адресов и проксирование трафика в интернет.
  4. ostp-obfuscator: Утилиты для статического шейпинга трафика и генерации динамических ключей маскировки.
  5. ostp-jni: Нативный SDK для интеграции в мобильные платформы Android.
  6. ostp: Единый исполняемый файл командной строки (CLI), который запускает систему в режиме сервера или клиента.

Формат кадра и структура данных (Framing)

Весь трафик OSTP разбивается на логические кадры перед отправкой в зашифрованном виде. Спецификация заголовка кадра (FrameHeader) имеет фиксированный размер 12 байт:

Смещение (байт) Тип данных Имя поля Описание
0 u8 version Версия протокола (текущая: 1)
1 u8 kind Тип кадра (см. таблицу ниже)
2 u8 flags Служебные флаги управления потоком
3 u8 резерв Зарезервировано для будущего использования (0)
4-5 u16 BE stream_id Логический идентификатор мультиплексированного потока
6-9 u32 BE payload_len Длина полезной нагрузки в байтах
10-11 u16 BE pad_len Длина адаптивного паддинга в байтах

Типы кадров (FrameKind):

  • 1 - Handshake: Обмен ключевой информацией (Noise Handshake Payload).
  • 2 - Data: Передача зашифрованных прикладных данных.
  • 3 - Close: Сигнализация закрытия сессии или конкретного потока.
  • 4 - KeepAlive: Пакет поддержания активности соединения.
  • 5 - Nack: Запрос на немедленную повторную передачу потерянного кадра.
  • 6 - Ack: Подтверждение успешного получения диапазонов кадров.

Полный пакет (FramedPacket) кодируется по схеме: [12 байт FrameHeader] + [N байт Payload] + [M байт Padding]


Механизм надежной доставки (Reliable ARQ System)

Для обеспечения гарантированной доставки данных поверх ненадежного UDP-туннеля в ostp-core реализована селективная система автоматического запроса повторной передачи (Selective Repeat ARQ):

  1. Нумерация кадров: Каждому отправляемому кадру данных присваивается строго возрастающий 64-битный счетчик (nonce), используемый также в качестве вектора инициализации для AEAD-шифра.
  2. Буферизация отправки (sent_history): Отправленные датаграммы кэшируются до тех пор, пока от удаленной стороны не придет подтверждение (Ack). При превышении порога max_sent_history старые кадры вытесняются.
  3. Быстрый путь повторной отправки (Fast-Path Nack):
    • При обнаружении "пробела" в номерах входящих пакетов, принимающая сторона немедленно генерирует и отправляет кадр Nack, содержащий номер пропущенного пакета (expected_recv_nonce).
    • Отправитель, получив Nack, немедленно извлекает кадр из истории и выполняет повторную передачу, минуя стандартный цикл тайм-аутов.
  4. Тайм-аут повторной передачи (RTO / Tick):
    • Каждые несколько миллисекунд запускается событие OstpEvent::Tick.
    • Любой неподтвержденный пакет, время нахождения в пути которого превышает rto_ms, отправляется повторно, увеличивая счетчик retries.
  5. Сборка out-of-order пакетов (reorder_buffer):
    • Пакеты, пришедшие не по порядку, помещаются в упорядоченное B-дерево.
    • Как только пропущенные пакеты получены, буфер «проливается», передавая непрерывную последовательность данных вышестоящему приложению.

Бесшовный роуминг (Dynamic Roaming)

OSTP спроектирован для мобильных сценариев. Соединение привязано не к паре IP:Порт, а к уникальному криптографическому идентификатору сессии (session_id), согласованному во время рукопожатия. Когда клиент переключается с мобильного интернета на Wi-Fi:

  1. Новые пакеты отправляются с нового IP/порта, сохраняя текущий session_id и криптографический контекст.
  2. Сервер успешно дешифрует пакет, сопоставляет его с сессией в O(1)-O(N) таблице и моментально перенаправляет обратный трафик на новый адрес источника.
  3. Пользовательские TCP-соединения внутри туннеля не прерываются.