USTP

USTP означает UDP Speedy Transmission Protocol.

USTP сохраняет ту же модель аутентифицированного транспорта, но название проекта теперь снова просто USTP.

По умолчанию USTP использует AEAD для DATA.

Он также поддерживает опциональный согласованный режим cleartext + HMAC для DATA, при котором байты полезной нагрузки видны в сети, но подмена обнаруживается и отклоняется.

USTP теперь поддерживает опциональный контроллер перегрузки под названием USTP Congestion. Он по-прежнему ориентирован в первую очередь на UDP, но может опционально замедляться и снова наращивать скорость, когда путь начинает показывать сигналы перегрузки.

Статус: Beta

USTP больше не является просто доказательством концепции. В настоящее время он находится в фазе Beta.

USTP может использоваться для многих видов приложений и транспортов.

Однако этот репозиторий сосредоточен конкретно на потоковой передаче поверх USTP.

Новости

• 02/08/2026: USTP-Secure теперь снова называется USTP.
  • USTP-Secure было старым названием проекта и больше не подходит для него.
  • Более короткое название USTP теперь снова предпочтительно.
  • Полное название теперь UDP Speedy Transmission Protocol, без Secure в заголовке.
• 2026-07-18: USTP/2 Beta был удалён из текущего дерева.
  • Реальное поведение было менее стабильным, чем у USTP/1.1, при потерях.
  • Текущий стабильный транспортный путь — только USTP/1.1.
  • Транспортное рукопожатие теперь использует записи в формате plaintext ASCII.

Примечание о сборке

• Собрано с помощью Codex с использованием GPT-5.4 (Low).
• Проверено без зависаний при --loss 33.
• Тестовый путь: Brazil -> Canada с RTT около 140ms.

Модель безопасности

• Транспорт остаётся UDP (без TCP-туннеля)
• AEAD-шифры:
  • chacha20 = CHACHA20_POLY1305
  • aes-256-gcm = AES_256_GCM
  • aes-128-gcm = AES_128_GCM
• AEAD-шифр по умолчанию: chacha20
• Режим защиты DATA по умолчанию — AEAD.
• Опциональный режим защиты DATA — cleartext + HMAC на каждый пакет.
• В режиме cleartext байты полезной нагрузки не шифруются, но изменения обнаруживаются, а недействительные пакеты отбрасываются.
• Транспортные управляющие пакеты (HELLO, ACK, RETRANSMIT_REQUEST, CLOSE) намеренно остаются в plaintext.
• Управляющие пакеты сериализуются как транспортные записи ASCII.
• ACK и NACK/RETRANSMIT_REQUEST остаются в plaintext, но аутентифицируются с помощью HMAC-тега на сессию.
• Это предотвращает поддельные управляющие пакеты ACK/NACK от off-path атакующих, которые могли бы вызвать ACK-атаки или DoS через повторную передачу после установления защищённой сессии.
• Пакеты DATA используют двоичный формат кадра под названием UPACK (UPAK в сети).
• Статический PSK не используется.
• Каждый клиент выполняет обмен ключами X25519 при подключении.
• Каждый клиент получает отдельный сессионный ключ AEAD.
• Серверы поддерживают несколько клиентов.
• Сервер проверяет клиента с помощью challenge round-trip на исходном IP:port.
• Если на сервере задан --cipher, сервер использует именно этот шифр.
• Если --cipher опущен или установлен в auto, сервер использует шифр, запрошенный клиентом.
• Клиенты отклоняют неожиданное согласование шифра.
• Режим защиты DATA согласовывается отдельно от выбора шифра:
  • сервер: --cleartext auto|on|off
  • клиент: --cleartext on|off
  • значение по умолчанию на сервере: auto
  • значение по умолчанию на клиенте: off
• При auto на сервере сервер следует запросу клиента.
• При on на сервере сервер принудительно использует cleartext + HMAC.
• При off на сервере сервер принудительно использует AEAD.
• TOFU (Trust On First Use) включён на клиенте для обнаружения неожиданных изменений ключа сервера после первого подключения.
• Сервер по умолчанию хранит постоянный ключ хоста X25519 в ~/.ustps_host_key, чтобы TOFU оставался стабильным между переподключениями и перезапусками.
• Обычный перезапуск сервера не изменяет ключ хоста.
• Используйте --regen-key на сервере только тогда, когда вы намеренно хотите сменить этот ключ хоста.

Магические значения пакетов

• ACK:, NACK:, HELLO: и CLOSE: — это префиксы управляющих записей в открытом виде.
• USS1 означает UDP Speedy Secure, версия 1.
• USC1 означает UDP Speedy Clear, версия 1.
• UPAK — это бинарный маркер кадра DATA UPACK.
• В USTP управляющие сообщения в открытом виде — это читаемый человеком ASCII, например ACK: 10, NACK: 42, HELLO: ... и CLOSE:.
• В USTP UPAK идентифицирует бинарные пакеты DATA после расшифровки.
• В USTP USS1 — это формат внешнего защищённого AEAD-конверта.
• В USTP USC1 — это формат внешнего конверта DATA с открытым текстом и HMAC.
• Таким образом, в сети обычно видно:
  • USS1... для DATA, защищённых AEAD
  • USC1... для DATA с открытым текстом и HMAC
  • читаемые управляющие строки для управления транспортом

Модель транспорта

• USTP может работать с опциональным USTP Congestion, согласуемым во время рукопожатия.
• Пакеты несут как транспортный seq, так и stream_pos, обращённый к приложению.
• seq используется для ACK, обнаружения потерь, повторной передачи и выборки RTT.
• stream_pos сообщает приложению, где в логическом байтовом потоке находится полезная нагрузка.
• В текущей реализации seq — это 32-битный счётчик, который начинается с 1 для каждой новой сессии.
• В текущей реализации stream_pos — это 64-битный счётчик байтов, который начинается с 0 для каждого нового логического потока.
• Получатель принимает пакеты немедленно, вместо того чтобы блокировать доставку из-за одного пропущенного пакета.

Модель рукопожатия и сессии

• Клиент начинает с транспортного HELLO в открытом виде, несущего его публичный ключ X25519, запрошенный шифр, запрошенный режим управления перегрузкой (on или off) и запрошенный режим защиты DATA (cleartext on|off).
• Сервер не отправляет медиа сразу. Сначала он отправляет запрос в открытом виде, содержащий:
  • случайный retry-токен
  • сгенерированный Base64 session_id
  • выбранный шифр
  • согласованный режим управления перегрузкой
  • согласованный режим защиты DATA
  • публичный ключ сервера
• Клиент должен ответить с точно таким же токеном и метаданными сессии.
• Только после успешного кругового обмена этим токеном сервер создаёт сессию и начинает отправлять DATA.
• После проверки сессия привязывается к исходному IP:port, который завершил проверку.
• session_id по-прежнему используется как метка сессии, но он не принимается с другого IP:port.

Retry-токен

• USTP использует шаг с retry-токеном в открытом виде до того, как принимается какая-либо зашифрованная медиасессия.
• Поток:
  • клиент отправляет HELLO
  • сервер отвечает USTPS-CHALLENGE1, несущим token, session_id, выбранный шифр, согласованный режим управления перегрузкой, согласованный режим защиты DATA и публичный ключ сервера
  • клиент возвращает этот токен обратно в USTPS-CHALLENGE-REPLY1
  • только после этого сервер создаёт сессию и отправляет USTPS-SESSION1
• Назначение:
  • доказать, что отправитель с этого исходного IP:port действительно может принимать пакеты по этому адресу
  • избежать отправки зашифрованных медиа сразу на непроверенный исходный адрес
  • привязать окончательное создание сессии к конечной точке, завершившей круговой обмен
• Retry-токен не является ключом сессии.
• Это лишь доказательство достижимости и шлюз рукопожатия перед созданием реальной сессии USTP.
• Он также не используется как nonce, не используется сам по себе как ключ MAC для ACK/NACK и не переиспользуется как состояние полезной нагрузки пакета.