mirror of https://github.com/ospab/ostp.git
71 lines
8.0 KiB
Markdown
71 lines
8.0 KiB
Markdown
# Системная архитектура 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-соединения внутри туннеля не прерываются.
|