# Системная архитектура 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-соединения внутри туннеля не прерываются.