SingLinkLabs · Protocol Paper 01
Технический документ протокола SingLink
Архитектура SingLink 2.0, полный жизненный цикл соединения и границы протокола
SingLink 2.0 — это формальный протокол сетевой передачи, независимо разработанный SingLinkVPN, а не версия клиентского программного обеспечения. В этой статье плоскость управления, плоскость данных и полный жизненный цикл соединения рассматриваются в качестве основных направлений для объяснения общедоступных возможностей протокола, эталонной модели реализации, границ тестовых данных и различий между внешними протоколами.
- Document
- SLP-WP-01
- Revision
- 1.0
- Published
- 2026-07-29
- Language
- Русский
Поколения протоколов и версии клиентов управляются независимо. Доступность узла зависит от статуса клиента в реальном времени.
Подписаться на обновления документаScope and evidence
Область применения, выводы и границы доказательности
Это не маркетинговая страница, а описание системы от получения конфигурации до очистки соединения. В каждом пункте различаются подтвержденные возможности, общедоступные описания проектов и эталонные модели реализации.
SingLink 2.0 — это официальное поколение сетевых протоколов передачи данных, независимо разработанное SingLinkVPN. «2.0» представляет собой имя протокола и поколение протокола, а не номер версии программного обеспечения Windows, macOS, Android, iOS или других клиентов.
Граница продукта протокола — это не просто байтовый формат от клиента к серверу, но также включает разрешения учетной записи и узла, обработку DNS, интеллектуальную разгрузку, выбор узла, определение работоспособности сеанса, переключение сети и восстановление после сбоя.
Со страницы продукта возможности клиента и официальный паблик калибр.
Опишите проблему, которую должен решить протокол, и текущие границы системы.
Используется для объяснения возможных реализаций, не эквивалентен опубликованной двоичной спецификации.
Versioning
Поколения протоколов не являются версиями программного обеспечения.
Protocol
SingLink 2.0
Представляет общую эволюцию поколений транспортных протоколов, согласование возможностей, модели сеансов и политики совместимости.
Client software
Каждая платформа имеет свой номер
Клиенты Windows, macOS, Android, iOS, Linux и TV управляются в соответствии с ритмами их выпусков и не будут смешиваться с протоколом 2.0.
System architecture
Разделение плоскости управления и плоскости данных
Плоскость управления отвечает за разрешения, конфигурацию и планирование узлов; плоскость данных отвечает за каналы, по которым фактически передается пользовательский трафик. Их разделение помогает ограничить объем конфиденциальных данных и изолировать сбои.
Control plane
поверхность управления
- 01 Разрешения учетной записи и пакета
- 02 Список возможностей узлов и протоколов
- 03 Краткосрочная конфигурация, стратегия и отзыв
- 04 Информация о состоянии узла и расписании
Data plane
Плоскость данных
- 01 Прием и переадресация трафика
- 02 TCP, UDP и логический носитель потока
- 03 Статус сеанса и обнаружение работоспособности
- 04 Декапсуляция возвращаемых данных
Connection lifecycle
22 этапа обработки
От разрешений учетной записи, входа в системную сеть до обратной декапсуляции данных и очистки безопасности — следующий процесс сохраняет полные технические ссылки и отмечает статус доказательства для каждого шага.
- 01
Вход в аккаунт и подтверждение разрешения
Подтвержденные возможностиКлиент получает доступные пакеты, узлы и разрешения протокола текущей учетной записи. Учетные данные аутентификации должны быть кратковременными, отзывными и не связанными с последующим статусом пересылки данных.
- 02
Доставка конфигурации узла и протокола
Описание публичного дизайнаПлоскость управления возвращает адрес узла, порт, доступные протоколы и необходимые политики и не должна напрямую доставлять клиенту долгосрочные главные ключи или ненужные конфиденциальные поля.
- 03
Установить вход в сеть системы
Подтвержденные возможностиКлиент получает трафик, который необходимо обработать через режим TUN, системный прокси или расширение сети платформы. Конкретный вход зависит от возможностей операционной системы.
- 04
Разрешение DNS и определение доменного имени
Подтвержденные возможностиДля DNS-запросов и последующих подключений необходимо использовать согласованные политики, чтобы доменные имена не проходили через прокси-серверы, пока DNS все еще просачивается из локальной сети или вызывает ошибочное перенаправление.
- 05
Интеллектуальное распределение трафика и оценка маршрутизации
Подтвержденные возможностиОпределяет соединения как прямые, прокси-серверы или заблокированные на основе правил, приложения, имени целевого домена, IP-адреса и состояния сети.
- 06
Выбор узла
Подтвержденные возможностиВ ручном режиме используются узлы, указанные пользователем; интеллектуальный режим может выбирать узлы-кандидаты на основе задержки, доступности, нагрузки, региона и разрешений пакета.
- 07
Согласование возможностей протокола
Описание публичного дизайнаКлиент и сервер подтверждают поколения протоколов и возможности, поддерживаемые обеими сторонами. Старый клиент не должен молча включать несовместимое поведение, если он не может распознать новые возможности.
- 08
Аутентификация и защита от повтора
Эталонная модель реализацииУзлы проверяют, что учетная запись или сеанс действительны, и должны предотвращать повторное использование старых данных аутентификации посредством устаревания, рандомизации или аналогичных механизмов.
- 09
Обмен ключами и сеансовые ключи
Эталонная модель реализацииПротокол требует создания отдельного контекста шифрования для текущего соединения. Конкретные наборы шифров, поля подтверждения и периоды ротации должны быть предметом будущих общедоступных спецификаций.
- 10
Создать сеанс
Эталонная модель реализацииСеанс представляет собой сеанс передачи между клиентом и узлом, который может передавать состояние соединения, информацию о возможностях, контрольные сигналы и один или несколько логических потоков.
- 11
Установите Stream или независимое прокси-соединение.
Эталонная модель реализацииКаждый запрос приложения может быть сопоставлен с логическим потоком внутри сеанса или может быть установлено независимое соединение; окончательный метод зависит от публичной реализации.
- 12
Инкапсуляция кадров данных
Эталонная модель реализацииИнформация о пункте назначения, идентификация потока, длина полезной нагрузки, команды управления и данные необходимы для формирования анализируемого кадра; эта страница не изобретает недокументированные двоичные поля.
- 13
обработка TCP-трафика
Описание публичного дизайнаПотоки байтов TCP должны поддерживать порядок, обрабатывать полузакрытия и ненормальные закрытия, а также передавать противодавление со стороны приложения на транспортную сторону.
- 14
Обработка UDP и QUIC-трафика
Описание публичного дизайнаДатаграммы UDP должны сохранять границы сообщений и управлять таймаутами сеансов; Службам типа UDP, таким как QUIC, также необходимо избегать ненужной блокировки начала строки.
- 15
Контроль потока и противодавление
Эталонная модель реализацииКогда скорость потребления клиента, узла или целевой службы замедляется, рост буфера должен быть ограничен, чтобы один поток не мог привести к сбою всего сеанса.
- 16
Подупаковка, отступы и внешний вид трафика
Эталонная модель реализацииПакетизация и заполнение могут использоваться только как часть стратегии передачи и не могут быть описаны как абсолютная скрытность; его условия и накладные расходы требуют тестирования и проверки.
- 17
Обработка MTU и размера пакета
Описание публичного дизайнаНакладные расходы туннеля уменьшат доступный MTU, а количество сбоев крупных пакетов необходимо уменьшить за счет предотвращения фрагментации, настройки MSS или эквивалентных механизмов.
- 18
Задержка, потеря пакетов и обработка перегрузок
Эталонная модель реализацииПротокол должен управлять ритмом отправки и повторной передачей на основе обратной связи сети и различать реальную потерю пакетов, задержку в очереди и кратковременный дрожание сети.
- 19
Обнаружение сердцебиения и состояния здоровья
Подтвержденные возможностиПостоянно отслеживайте состояние сеанса и узла, чтобы не полагаться исключительно на длительные тайм-ауты операционной системы при обнаружении неработающих соединений.
- 20
Переключение сети и восстановление сеанса
Подтвержденные возможностиПосле переключения между Wi-Fi и мобильными сетями клиент повторно подтверждает вход в сеть, сеансы DNS, маршрутизации и передачи и возобновляет соединение в соответствии со своими возможностями.
- 21
Отказ узла и автоматическое переключение
Подтвержденные возможностиВ случае мягкого сбоя сессию можно сначала перестроить, а в случае жесткого сбоя можно переключить доступные узлы. В процессе переключения необходимо восстановить системную маршрутизацию и избегать трафика от неожиданных прямых соединений.
- 22
Возврат данных, декапсуляция и очистка безопасности
Описание публичного дизайнаКлиент проверяет и декапсулирует возвращаемые данные, а также очищает статус временного сеанса, ключи кэша, изменения маршрутизации и DNS после завершения соединения.
Traffic entry and routing
Перехват трафика, DNS и интеллектуальная разгрузка
Вход в системную сеть, разрешение доменных имен и определение маршрутизации должны использовать один и тот же контекст, чтобы избежать утечек DNS, ошибочных выходов и неожиданных прямых подключений.
Настольные системы могут использовать режим TUN или системный прокси; мобильные и телевизионные платформы используют соответствующие возможности расширения сети. Разные платформы имеют разные API, но цели политики одни и те же: трафик, которому требуется прокси, поступает в туннель, а трафик, не требующий прокси, подключается напрямую по правилам.
Проксирование только трафика приложений и разрешение DNS продолжать проходить через локальную сеть может привести к раскрытию имени домена или получению результатов разрешения, которые не подходят для текущего выхода. Таким образом, сопоставление доменных имен, DNS-запросы, кэширование IP-адресов и установление соединения должны использовать один и тот же контекст маршрутизации.
прямое соединение
Локальные службы или цели, которым явно не требуется прокси-сервер, используют локальную сеть.
агент
После проверки разрешения соединение устанавливается через выбранный узел SingLink.
блокировать
Соединение запрещено при срабатывании правила безопасности или при попадании в цель без разрешения.
Authentication
Аутентификация и зашифрованные сеансы
Подтверждение разрешения отвечает «Может ли эта учетная запись использовать этот узел и протокол»; Аутентификация передачи отвечает: «Является ли текущее соединение от действительного клиента». Оба должны использовать кратковременное, отзывное состояние сеанса и предотвращать повторное воспроизведение старой аутентификационной информации.
Клиенту и узлу также необходимо подтвердить поколения протоколов и возможности, поддерживаемые обеими сторонами. Сторона, которая не распознает новые возможности, должна безопасно понизить версию или отказаться от соединения и не может включить несовместимое поведение без подтверждения.
Disclosure boundary
Неопубликованные криптографические данные
Существующей информации недостаточно для идентификации конкретных полей подтверждения, наборов шифров, функций получения ключей, периодов ротации и форматов двоичных пакетов. В этой статье описываются только цели безопасности и не указываются версии AES, TLS, определенные кривые или фиксированная длина полей как свершившийся факт.
Session model
Сеанс, поток и кадр данных
Используйте иерархическую модель сеанса, чтобы объяснить взаимосвязь между подключениями приложений, логическими потоками и транспортными контекстами узлов, одновременно проясняя нераскрытые границы формата.
Session
Транспортный контекст между клиентом и узлом может переносить результаты аутентификации, возможности, контрольные сигналы и управление потоком на уровне соединения.
Stream
Соединение с приложением логики. Совместное использование сеансов несколькими потоками зависит от окончательной публичной реализации и политики платформы.
Кадр данных должен выражать как минимум команды управления, логический поток, границы нагрузки и статус ошибки; до того, как официальный формат будет опубликован, на этой странице не будет непроверенной таблицы полей.
Transport
TCP, UDP и QUIC
TCP
упорядоченный поток байтов
Поддерживайте порядок байтов, обрабатывайте полузакрытие, ненормальное закрытие, противодавление и ошибки целевого соединения, а также предотвращайте заполнение буфера сеанса медленными соединениями.
UDP
границы дейтаграмм
Сохранять границы дейтаграмм и поддерживать статус цели и тайм-аута; если используется UDP-over-TCP, необходимо оценить блокировку начала линии и усиление потери пакетов.
QUIC
Надежный транспорт через UDP
Постарайтесь сохранить собственные преимущества QUIC в отношении перегрузки и повторной передачи, чтобы избежать повторного восстановления, вызванного дополнительными уровнями надежности.
Reliability
Управление потоком, MTU, пульс и восстановление
Стабильное соединение — это не кнопка автоматического переподключения, а конечный автомат, состоящий из буферизации, упаковки пакетов, определения работоспособности, восстановления маршрута и переключения узлов.
контроль потока
Настройте окно отправки в соответствии со скоростью потребления, чтобы не блокировать всю сессию одним потоком.
Обработка MTU
Учитывайте дополнительные затраты на туннели, чтобы снизить риск фрагментации и черных дыр.
проверка здоровья
Определите соединение на основе пульса, задержки, потери пакетов и реального статуса пересылки.
восстановление сети
После отключения сети портал, DNS, маршрутизация и сеансы перестраиваются, чтобы предотвратить случайное прямое подключение трафика.
Product comparison
SingLink 2.0 и бета-версия
| индикатор | SingLink 2.0 | SingLink Beta |
|---|---|---|
| Позиционирование | официальное соглашение между поколениями | Протокол предварительного просмотра, ориентированный на скорость |
| Уровень стабильности внутреннего A/B-тестирования | 99.5％ | Примерно до 97% |
| Скорость фокусировки | Баланс скорости, стабильности и совместимости | Пиковое значение превышает 1 Гбит/с при подходящих условиях. |
| Разрешения узла протокола | Про, Макс и Рич | Все пакеты |
| изменить стратегию | Сосредоточьтесь на долгосрочной совместимости и восстановлении. | Используется для проверки новых возможностей и производительности. |
External protocols
Граничное сравнение с VLESS и AnyTLS
Основой для сравнения являются официальные публичные документы каждого проекта. Здесь мы сравниваем позиционирование, границы системы и возможности раскрытия информации и не смешиваем маркетинговые цифры с основными выводами протокола.
| Размеры | Объем технической документации SingLink | Общественная сфера VLESS | Общедоступная область AnyTLS |
|---|---|---|---|
| публичное позиционирование | Общая система плоскости управления продуктом и плоскости передачи данных | Легкий транспортный протокол клиента и сервера без сохранения состояния | Прокси-протокол на основе TLS и эталонная реализация |
| Личность и цель | Учетная запись, разрешения узла, совместная работа по сеансам и маршрутизации | UUID, команда, порт и целевой адрес | Пост-аутентификация TLS, затем установка сеанса |
| Session／Stream | Объяснение эталонной модели, точный формат еще не раскрыт. | Поддержка мультиплексирования, детали определяются реализацией и конфигурацией. | Раскрытие кадров сеанса, мультиплексирование потоков и команды |
| внешний вид трафика | Стратегия передачи, требующая проверки, не претендует на абсолютную невидимость | Официальные документы описывают дополнительный Flow и другие механизмы. | Раскрытие информации о субподрядах, дополнительных планах и механизмах обновления |
| Устойчивость | Обнаружение работоспособности, отключение сети, восстановление сеанса и переключение узлов | Отвечает за экологию рентгеновского излучения и конкретную комбинацию передачи. | Протокол v2 предоставляет доступ к SYNACK, тактовому сигналу и согласованию сервера. |
| система продуктов | DNS, интеллектуальная разгрузка, разрешения пакетов и планирование узлов | Не эквивалентно полной поверхности управления продуктом VPN. | Не эквивалентно полной поверхности управления продуктом VPN. |
В этой таблице не представлены совместимость кода, рейтинги производительности или выводы аудита безопасности.
Platforms and openness
Кроссплатформенная совместимость и границы открытого исходного кода
Согласованность платформы
SingLinkVPN распространяется на устройства iOS, Android, Windows, macOS, Linux и телевизоры. Межплатформенная согласованность не означает, что каждая платформа использует один и тот же системный API, но поддерживает один и тот же набор разрешений, маршрутизацию, логику выбора узлов и протоколов и придерживается ограничений расширения сети каждой операционной системы.
Публичная сфера
Исходный код основного протокола SingLink 2.0 еще полностью не раскрыт. Опубликованные инструкции включают техническую документацию, описания архитектуры, данные исследований, воспроизводимые методы тестирования, форматы данных, инструменты проверки и инфраструктуру ответственного раскрытия уязвимостей.
Frequently asked questions
Часто задаваемые вопросы
Q01Что такое СингЛинк 2.0?
SingLink 2.0 — это формальный протокол сетевой передачи, независимо разработанный SingLinkVPN. Он используется для организации проверки личности и полномочий, маршрутизации трафика, сеансов передачи, обработки TCP и UDP, обнаружения работоспособности и восстановления исключений.
Q02Является ли SingLink 2.0 версией клиентского программного обеспечения?
Нет. SingLink 2.0 — это имя протокола и его генерация. Windows, macOS, Android, iOS и другие клиенты используют независимые системы версий программного обеспечения.
Q03В чем разница между SingLink Beta и SingLink 2.0?
Бета-версия — это предварительный протокол для проверки скорости и новых возможностей; SingLink 2.0 — это официальное поколение протоколов, в котором больше внимания уделяется стабильности, межплатформенной согласованности, восстановлению соединения и долгосрочной совместимости.
Q04Каков уровень стабильности SingLink 2.0?
Показатель внутреннего A/B-тестирования SingLinkVPN в специально отведенных средах тестирования составляет 99,5 %, при этом пик бета-тестирования составляет примерно 97 %. Это не гарантии для всех регионов и периодов времени, а фактические результаты будут зависеть от сетевых операторов, нагрузки на узлы, оборудования и методов тестирования.
Q05Как SingLink обрабатывает сетевой трафик?
Клиент сначала устанавливает вход в сеть системы, выполняет DNS и интеллектуальное распределение, затем выбирает узлы, проверяет разрешения, устанавливает сеанс передачи и инкапсулирует данные TCP или UDP перед отправкой их на узел.
Q06Как SingLink обрабатывает отключения и сетевые переключения?
Клиент постоянно отслеживает состояние сеанса и узла. При возникновении исключения сеанс будет перестроен, DNS и маршрутизация восстановлены или переключены на другие доступные узлы в зависимости от возможностей.
Q07В чем разница между SingLink и VLESS?
VLESS официально позиционируется как облегченный протокол передачи данных между клиентом и сервером без сохранения состояния. Объем, описанный в официальном документе SingLink, шире и также охватывает плоскость управления продуктом, разрешения узлов, интеллектуальную маршрутизацию, процессы обнаружения работоспособности и восстановления; их не следует сравнивать на основе одного формата кадра.
Q08В чем разница между SingLink и AnyTLS?
Публичная спецификация AnyTLS фокусируется на описании аутентификации, сеанса, повторного использования потока, заполнения и контрольного сигнала через TLS. В официальном документе SingLink также описывается ввод клиентского трафика, DNS, маршрутизация, разрешения пакетов и планирование узлов, поэтому сравнение основано на границах системы, а не на утверждении, что базовая реализация одинакова.
Q09Кто может использовать SingLink 2.0?
В настоящее время узлы протокола SingLink 2.0 в основном открыты для пакетов Pro, Max и Rich; Узлы протокола SingLink Beta открыты для всех пакетов. Фактически доступные узлы отображаются на клиенте в режиме реального времени.
Q10Является ли SingLink 2.0 полностью открытым исходным кодом?
В настоящее время исходный код основного протокола полностью не раскрыт. Технические документы, данные исследований, методы тестирования, форматы данных, инструменты проверки и механизмы раскрытия уязвимостей были включены в план непрерывного открытого исходного кода. Объем раскрытия информации зависит от склада SingLinkLabs и официальных объявлений.
References and revision
Данные, внутренние ссылки и записи изменений
Информация о внешнем протоколе
Next step
Испытайте протокол SingLink 2.0
Узлы SingLink 2.0 в основном открыты для пакетов Pro, Max и Rich. Количество узлов и доступность протокола отображаются на клиенте в режиме реального времени.