0Аннотация
Adaptive Connect 2.0 научил приложения замечать путь, который ломается при подключении, и переводить трафик на резервный канал. Полевые данные показали три слабых места: диагностика обрыва занимала десятки секунд, в незнакомой сети приложение действовало вслепую, а из-за того, что одна и та же логика была написана отдельно на четырёх платформах, решения расходились. Adaptive Connect 3.0 направлен на эти три места: подсказки сети, выводимые из анонимных агрегированных данных, чтобы с первой попытки начинать с верного режима подключения; набор восстановления, который находит рабочий сервер, даже когда API недоступен; наблюдатель, диагностирующий обрыв примерно за 11 секунд; и общий набор правил из 46 векторов, которому подчиняются все четыре приложения. В отчёте описаны архитектура 3.0, поэтапное включение и измерения, а части, которые пока в альфе или только запланированы, выделены отдельно.
1Зачем нужна версия 3.0?
В первую неделю после выхода 2.0 мы собирали данные из двух источников: лабораторные прогоны с внесением сбоев и анонимная телеметрия подключений, которую отправляют приложения (её устройство описано в разделе о приватности). В базовом лабораторном измерении версии 2.0 против 29 серверов 85,2 % проверок были успешными; проблемы концентрировались в определённых типах сбоев (лабораторный отчёт).
| Находка | Источник | Результат |
|---|---|---|
| Медленная диагностика обрыва | Полевая телеметрия | Среднее время между обнаружением и восстановлением: Android 54 с, Windows 34 с |
| Длинный «хвост» подключения в Windows | Полевая телеметрия + тестовый компьютер | Удачные подключения с первой попытки в среднем занимали 14,9 с; первопричина: пока удерживается kill switch, адреса API хранились только в памяти |
| Резервный канал иногда так и не подхватывал | Лаборатория | Из-за того что фоновый трафик превышал порог, переключение на резервный канал откладывалось бессрочно |
| Слепой старт в новой сети | Полевая телеметрия | В сети без памяти приложение перебирало режимы в фиксированном порядке |
| Платформы разошлись | Анализ кода | Одно и то же правило было написано отдельно на четырёх языках; в Windows и Linux различались ранжирование и разбор подсказок |
Поэтому цель 3.0 — не новый протокол, а качество решений: меньше попыток, короче слепой период, одинаковое решение на каждой платформе. У пользователя не собирается никаких дополнительных данных, а выбранная вручную локация никогда не меняется.
2Архитектура: семь компонентов
3.0 с самого начала проектировался как каркас из семи компонентов. Не все они одинаково зрелы; таблица ниже прямо показывает текущее состояние каждого.
| Компонент | Что делает | Состояние |
|---|---|---|
| Коллективные подсказки сети | По анонимным агрегированным данным определяет, какой режим подключения работает в сети | Работает |
| Упреждающий старт | В незнакомой сети приложение начинает с режима, указанного в подсказке; опирается на правила, машинного обучения нет | Работает |
| Автономное восстановление | Подключается с помощью набора восстановления, хранящегося на устройстве, и сохранённых адресов, даже когда API недоступен | Работает |
| Быстрое обнаружение обрыва | Диагностирует обрыв при подключении за ~11 с и решает, когда покинуть сервер | Работает |
| Сетевая лаборатория | Пакеты внесения сбоев и общие для платформ тестовые векторы | Работает (внутренний инструмент) |
| Движок непрерывности (CSL) | Сессионный уровень, сохраняющий сессию, даже когда туннель меняется; несколько несущих линий | Альфа (Windows, тестовые аккаунты) |
| Адаптивная маскировка | Выбор формы трафика и параметров транспорта в зависимости от сети | Запланировано |
Подсказки сети v2
Приложения анонимно сообщают исход каждой попытки подключения (режим, успех или неудача, длительность). Панель превращает их в суточные итоги по сетям, то есть на уровне страна + автономная система (ASN). Если по сети достаточно данных, вместе со списком серверов возвращается порядок `preferred`: режимы, работавшие в этой сети за последние 24 часа, сначала с лучшей долей успехов. При смене сети приложение заново получает список и использует подсказку новой сети.
В измерении 16 октября за последние семь дней было замечено 89 разных сетей; по 44 из них данных хватало для решения, а для 40 был построен порядок предпочтений. В некоторых сетях доля успехов у Hysteria2 на основе UDP составляла 92 %, тогда как у TCP-режимов — 44–54 %; фиксированный порядок заставлял терять время при каждом подключении в этих сетях.
Набор восстановления
В 2.0, если список серверов не удавалось получить от API, приложению было некуда подключаться. В 3.0, пока API отвечает, приложение примерно раз в сутки скачивает небольшой набор восстановления и хранит его на устройстве: полные профили для нескольких серверов в разных странах, действующие намного дольше обычной конфигурации. Сначала выбираются серверы, до которых это устройство дотягивалось в последние дни, затем по одному серверу из каждой страны; так что, даже если доступ к серверам одной страны перекрыт, остальные остаются. Набор используется только тогда, когда ни один адрес API не отвечает и обычный кэш тоже не смог подключиться; после установления соединения приложение обращается к API изнутри туннеля и обновляет всё.
Кроме того, приложения для Windows и Linux теперь хранят адреса API на диске и обновляют их параллельно. Когда kill switch сохранялся с предыдущего запуска (автоматическое подключение после сбоя или перезагрузки), системный DNS был закрыт, поэтому 2.0 пытался разрешать адреса по очереди, и от запуска до подключения проходило 21–25 секунд.
Быстрое обнаружение обрыва
Наблюдатель проверяет основной путь раз в секунду с тайм-аутом в три секунды. Одна потеря ещё не решение; когда последовательные потери подтверждаются, решение об обрыве принимается примерно за 11 секунд. Что делать после решения, зависит от масштаба обрыва:
| Ситуация | Решение |
|---|---|
| Упал только основной путь, резервный канал работает | Трафик остаётся на резервном канале; сначала пробуются другие режимы того же сервера |
| Основной путь и резервный канал упали вместе, устройство в сети | В автоматическом режиме сервер на 30 минут отодвигается на задний план для этой сети, пробуется следующий сервер |
| Пропал собственный интернет устройства | Ни режим, ни сервер не винят; когда сеть возвращается, подключение возобновляется |
| Локация выбрана вручную | Сервер не меняется; переключение происходит только между режимами в той же локации |
Исправлена и ошибка 2.0: при постоянном небольшом фоновом трафике переключение на резервный канал откладывалось бессрочно под предлогом «занято». В 3.0 отсрочка ограничена максимум двумя минутами или 32 KB.
Мгновенный идентификатор устройства
У каждого устройства на каждом сервере свой идентификатор. В 2.0 новый идентификатор доходил до сервера только при регулярной 15-секундной синхронизации, поэтому первое подключение нового пользователя могло не удаваться 15–30 секунд. Теперь изменение идентификатора передаётся серверам сразу; запрос конфигурации немного ждёт, а если идентификатор всё ещё не готов, приложение знает об этом и повторяет попытку с интервалом в две секунды.
3Общие правила решений и движок на Go
Правила Adaptive Connect живут в четырёх приложениях на четырёх разных языках: Kotlin (Android), C# (Windows и Linux), Dart и Swift (iOS). С 3.0 эти правила привязаны к единому источнику: общим тестовым векторам. Каждый вектор содержит входные данные (серверы, измерения, память, подсказки) и ожидаемое решение; наборы тестов четырёх приложений прогоняют одни и те же файлы.
| Файл векторов | Охват |
|---|---|
| ranking | Ранжирование серверов в автоматическом режиме: последний рабочий, пинг, штрафы, правило своей страны (19 случаев) |
| transport | Базовый порядок режимов подключения, старт по подсказке, игнорируемые отметки |
| hints | Разбор ответа с подсказками |
| recovery | Решение о восстановлении, время обновления, чтение набора, следующий сервер |
Всего в четырёх файлах 46 случаев. Если правило меняется в одном приложении и один из векторов даёт другой результат, набор тестов этого приложения не проходит.
Первый же прогон векторов нашёл реальные расхождения: Windows и Linux применяли правило отодвигания собственной страны к каждой стране; в этих двух приложениях значение подсказки, не являющееся числом, могло нарушить чтение всего списка серверов; Linux упорядочивал TCP-режимы только по задержке. Всё это сведено в единый набор правил.
Те же правила реализованы и в пакете на Go с открытым исходным кодом, и он проходит те же 46 векторов. Движок встроен в приложения для Android, Windows и Linux в теневом режиме: при подключении решение самого приложения сравнивается с решением движка, расхождения записываются, но решает приложение. Если движок возвращает ошибку, он отключается на десять минут. Когда расхождения в теневом режиме сойдут к нулю, решения будут переданы движку; в iOS движок пока не встроен.
4Поэтапное включение
Клиентская часть 3.0 добавлена в релизы так, чтобы решение о включении можно было принимать удалённо: Android 2.9.2, Windows 2.9.7, Linux 1.5.3 и серия iOS 5.9. Панель возвращает флаг `features.adaptive_connect_3` в ответе со списком серверов. Какое устройство попадает в группу включения, определяется стабильной корзиной, вычисляемой из SHA-256-хеша идентификатора устройства; одно и то же устройство остаётся в той же группе, пока процент не меняется. Приложение сохраняет последний флаг и пользуется им, пока не может связаться с API.
| Дата | Доля | Платформы |
|---|---|---|
| 16 октября 2026 г. | 10 % | Android, Windows, iOS |
| 17 октября 2026 г. | 15 % | Android, Windows, iOS |
| 20 октября 2026 г. | 100 % | Android, Windows, iOS |
Удалённо включаются старт по подсказке сети и набор восстановления. Быстрое обнаружение обрыва, правило ухода с сервера, сохранённые адреса API и общие правила пришли ко всем пользователям вместе с релизом. Linux сознательно оставлен за пределами удалённого включения: пользователей слишком мало для сравнения, а в версии 1.5.3 был рост ошибок подключения, не связанный с 3.0. Откат выполняется одной настройкой и не требует обновления приложения.
5Измерения
| Измерение | 2.0 | 3.0 | Как измерялось |
|---|---|---|---|
| Диагностика обрыва | 54 с (Android), 34 с (Windows), среднее по полевым данным | ~11 с | Темп наблюдателя; модульные тесты и тестовый компьютер |
| Общий перерыв, когда трафик к серверу отрезан на 45 с | 50 с | 22,4 с | Тестовый компьютер на Windows, правило брандмауэра на устройстве |
| От запуска до подключения, пока удерживается kill switch | 21–25 с | 5,1–5,2 с | Тестовый компьютер на Windows, повторные перезапуски |
| Первое подключение в сети без памяти | Фиксированный порядок режимов | 1,6 с (с режимом из подсказки) | Тестовое устройство на Android |
| Подключение, когда API недоступен | Некуда подключаться | Подключено через 12 с после нажатия | Тестовое устройство на Android, API заблокирован, кэш не учитывался |
В поле в дни после 16 октября успешность подключения на Android измерялась в диапазоне 98,3–98,6 % (в предыдущие недели она колебалась от дня ко дню между 80 % и 98 %); в Windows 2.9.8 — 97,4 %. Мы не относим эту разницу только на счёт 3.0: так как телеметрия по конструкции анонимна, устройства группы 3.0 нельзя отделить от остальных, а в тех же версиях выходили и другие исправления. За время включения не замечено ни одной жалобы или падения успешности, связанных с 3.0; решения о включении опирались на этот критерий.
6Приватность
Обучающимся частям 3.0 не нужны новые данные о пользователях. Телеметрия подключений анонимна по конструкции: события записываются только как суточные итоги в две отдельные таблицы, не имеющие общей строки.
- Сетевая таблица: страна + ASN (из подписанного сетевого токена), режим, количество результатов. Сервера нет.
- Серверная таблица: сервер × страна клиента, количество результатов. ASN нет.
- Ни в одной таблице нет аккаунта, идентификатора устройства или IP-адреса; соединив две таблицы, нельзя выйти на одного пользователя.
- Память о последнем рабочем сервере, отметках зависания и штрафах хранится на устройстве и не передаётся панели.
- Корзина включения вычисляется из одностороннего хеша идентификатора устройства; какое устройство в какой группе, не сохраняется.
Подробности — в отчёте о безопасности и политике конфиденциальности.
7Движок непрерывности: CSL в альфе
Colitu Session Layer (CSL) — сессионный уровень, упомянутый в отчёте о 2.0 как будущая работа. Его цель — чтобы открытые соединения не обрывались, даже когда меняется лежащий под ними туннель: сессия идёт по нескольким несущим линиям (lane), и если одна линия гибнет, сессия продолжается по другой. Исходный код открыт под лицензией Apache-2.0: github.com/colitu/csl.
Сегодня CSL находится на стадии альфа: он доступен только тестовым аккаунтам и отдельному тестовому серверу, через пункт «Непрерывная сессия (alpha)» в Расширенном режиме приложения для Windows. Для каждого устройства создаётся отдельный идентификатор сессии; серверная часть слушает только локально. Когда CSL выключен или не срабатывает, приложение возвращается к обычному подключению. Дату общего доступа мы не называем.
8Ограничения
- Правила, а не модель. «Упреждающий» старт — это правила, выведенные из анонимных агрегатов, а не статистическая модель. В сетях с малым количеством данных подсказки нет, и действует поведение 2.0.
- Охват измерений. Лабораторные результаты получены на одном тестовом компьютере и одном тестовом телефоне, со сбоями, создаваемыми на устройстве; сбои на серверах, где есть реальные пользователи, не тестировались. Их нельзя обобщать на любую сеть.
- Движок на Go в теневом режиме. Решение по-прежнему принимается в собственном коде каждого приложения; в iOS движка нет.
- В Linux подсказки сети и набор восстановления пока отключены.
- Открытые TCP-потоки могут оборваться при смене пути, пока CSL не станет общедоступным; браузеры и приложения обычно переподключаются сами.
9Дальнейшие шаги
- Передать решения движку на Go после устранения расхождений в теневом режиме; добавить движок в iOS.
- Перевести CSL в бету: Android, поддержка UDP-датаграмм и «режим звонка», отправляющий критический трафик голосовых и видеозвонков сразу по двум линиям.
- Адаптивная маскировка: выбор из существующих параметров транспорта для каждой сети.
- Включить Linux после дополнительной проверки.
Эти пункты — дорожная карта, а не обещание сроков или результатов. По мере выхода каждого из них отчёт будет обновляться.
10Заключение
2.0 заложил принцип «заметить ломающийся путь и восстановить». 3.0 развивает его в трёх направлениях: меньше слепых попыток благодаря анонимным подсказкам сети, подключение независимо от API с помощью набора восстановления и сохранённых адресов, обрывы, диагностируемые примерно за 11 секунд. Общие тестовые векторы гарантируют, что четыре приложения принимают одинаковое решение в одинаковой ситуации. Непрерывность и маскировка пока в самом начале пути; о них мы будем сообщать с измеренными результатами. Устройство предыдущей версии и часовой тест сбоев — в отчёте об Adaptive Connect 2.0.
·Источники
- RFC 8305, Happy Eyeballs Version 2: Better Connectivity Using Concurrency.
- RFC 9000, QUIC: A UDP-Based Multiplexed and Secure Transport.
- RFC 5482, TCP User Timeout Option.
- Технический отчёт Colitu Adaptive Connect 2.0, 10 октября 2026 г.
- Colitu Lab, регрессионный тест сбоев Adaptive Connect (faultlab).
- Исходный код Colitu Session Layer (CSL), github.com/colitu/csl.