Протокол SingLink 2.0

SingLink 2.0 — офіційний мережевий транспортний протокол, розроблений самою SingLinkVPN. «2.0» позначає назву та покоління протоколу; це не версія клієнтського застосунку SingLinkVPN.

Протокол SingLink не лише доставляє трафік до VPN-вузла. Він також охоплює авторизацію акаунта та вузла, обробку DNS, розумну маршрутизацію, шифровані сеанси, інкапсуляцію TCP і UDP, перевірку стану з’єднання, зміни мережі та відновлення після збоїв.

Наразі SingLink має робочий протокол SingLink 2.0 і попередній протокол SingLink Beta, орієнтований насамперед на швидкість. У внутрішніх A/B-тестах SingLink 2.0 досяг стабільності 99.5%, а Beta — приблизно до 97%; за відповідних умов мережі та пристрою пікова швидкість Beta перевищувала 1 Гбіт/с.

Порівняння ключових даних: робочий SingLink 2.0 показав стабільність 99.5% у визначеному тестовому середовищі. Beta досяг приблизно 97%, але за відповідних умов мережі та пристрою перевищив пікову швидкість 1 Гбіт/с. Ці результати відображають різні пріоритети — стабільність і швидкість — і не є гарантією для кожного пристрою чи мережі.

Докази та технічні межі: підтверджене позиціювання продукту, визначення внутрішніх тестів і публічні функції можна цитувати безпосередньо. Конкретні алгоритми шифрування, формат пакетів, узгодження можливостей, Session, Stream, мультиплексування та деталі відновлення сеансу, описані нижче, — це еталонна модель обробки, а не опис специфікації, розгорнутої зараз. Перевагу матимуть майбутні офіційні технічні документи SingLink та опублікований вихідний код.

Повні принципи обробки в протоколі SingLink

Усю систему можна поділити на два шляхи:

Площина керування

Відповідає за:

• вхід в акаунт;
• перевірку членства;
• отримання вузлів;
• визначення прав доступу до вузлів;
• доставлення конфігурації протоколу;
• оновлення правил;
• вибір Beta чи 2.0.

Площина даних

Відповідає за:

• приймання трафіку застосунків;
• розв’язання DNS;
• встановлення захищеного з’єднання;
• інкапсуляцію та передавання TCP і UDP;
• підтримання з’єднання;
• обробку розривів;
• повернення даних застосунку.

Спрощений потік виглядає так:

Користувач входить у SingLinkVPN
        ↓
Отримання дозволених вузлів і конфігурації протоколу
        ↓
Клієнт створює TUN / системний проксі
        ↓
Приймання трафіку застосунків
        ↓
Оцінка правил DNS і маршрутизації
        ↓
Вибір вузла SingLink 2.0 або Beta
        ↓
Узгодження можливостей протоколу
        ↓
Перевірка прав акаунта та пристрою
        ↓
Створення шифрованого сеансу та сеансових ключів
        ↓
Окремий логічний потік для кожного з’єднання застосунку
        ↓
Інкапсуляція даних TCP / UDP
        ↓
Надсилання даних на вузол SingLink
        ↓
Вузол декапсулює дані й звертається до цільового сайту
        ↓
Повернення даних і доставлення застосунку-джерелу
        ↓
Постійне вимірювання затримки, втрат і стану з’єднання
        ↓
Перепідключення, відновлення чи зміна вузла після збою

---

Етап 1: вхід, отримання вузлів і конфігурація протоколу

Коли користувач відкриває SingLinkVPN і входить в акаунт, клієнт не повинен одразу назавжди зберігати на пристрої всі адреси робочих вузлів, облікові дані та параметри протоколу.

Доцільніший порядок такий:

1. Клієнт надсилає облікові дані акаунта.
2. Система акаунтів перевіряє користувача.
3. Система підтверджує тарифний план і права доступу до вузлів.
4. Вона повертає вузли, доступні цьому користувачу.
5. Вона повертає короткочасні облікові дані для підключення.
6. Вона повертає поточну версію протоколу та потрібну конфігурацію.
7. Клієнт перевіряє цілісність конфігурації.
8. Чутлива конфігурація зберігається в захищеному системному сховищі.

Цей рівень передусім визначає:

• чи має користувач чинне членство;
• чи доступні Beta або 2.0;
• чи має акаунт права Pro, Max або Rich;
• які країни та вузли доступні;
• чи не застаріла конфігурація;
• чи потрібно оновити клієнт.

Простими словами

Це схоже на перевірку перед посадкою на швидкісний потяг:

• хто ви;
• квиток якого класу ви купили;
• на який рейс ви можете сісти;
• чи квиток ще дійсний.

Рекомендовані правила безпеки

SingLink не повинен безстроково покладатися на один постійний статичний пароль.

Доцільніший дизайн використовує:

• короткочасний токен підключення;
• одноразовий виклик (challenge);
• nonce пристрою;
• обмеження терміну дії;
• конфігурацію вузлів, підписану сервером;
• механізм відкликання.

Тоді отримання однієї конфігурації підключення не даватиме постійного доступу.

---

Етап 2: створення точки входу в системну мережу

Коли користувач натискає «Підключитися», SingLinkVPN спершу має створити в операційній системі точку входу в мережу.

Спосіб залежить від платформи:

Платформа	Типова точка входу в мережу
iOS / iPadOS	Network Extension / Packet Tunnel
Android	VPN Service
macOS	Network Extension або TUN
Windows	Віртуальний адаптер TUN і системна маршрутизація
Linux	TUN, таблиця маршрутизації та керування DNS

Після її створення дані, які застосунки зазвичай надсилали б напряму в мережу, спершу потрапляють до клієнта SingLinkVPN.

Наприклад:

Застосунок ChatGPT
    ↓
Мережевий стек операційної системи
    ↓
Інтерфейс SingLink TUN
    ↓
Клієнт SingLinkVPN

На цьому етапі клієнт має:

• створити віртуальну IP-адресу;
• налаштувати таблицю маршрутизації;
• налаштувати DNS;
• виключити локальну мережу;
• не допустити, щоб проксі-з’єднання маршрутизувалося назад у TUN;
• створити правила Kill Switch.

Останній пункт важливий.

Без виключення маршруту трафік, яким SingLinkVPN досягає свого вузла, сам міг би знову потрапити у VPN і створити петлю:

Трафік VPN
↓
Знову потрапляє у VPN
↓
Знову інкапсулюється
↓
Нескінченна петля

Тому клієнт має явно виключити:

• IP-адресу самого вузла;
• потрібні інтерфейси керування;
• локальний шлюз;
• сервіси, до яких система має звертатися напряму.

---

Етап 3: розв’язання DNS і оцінка домену

Коли користувач відкриває chatgpt.com, пристрій зазвичай спершу має перетворити домен на IP-адресу.

Неправильна обробка DNS може спричинити:

• DNS-запити, що йдуть напряму через локальну мережу;
• повернення неправильної адреси локальним DNS-резолвером;
• втрату правилами вихідного контексту домену;
• обхід VPN трафіком IPv6;
• витік DNS навіть тоді, коли VPN начебто підключено.

Клієнт SingLink може використовувати такий потік:

Застосунок надсилає DNS-запит
        ↓
Клієнт перехоплює DNS
        ↓
Оцінка правил для домену
        ↓
Вибір локального DNS або захищеного віддаленого DNS
        ↓
Отримання результату IPv4 / IPv6
        ↓
Зв’язування домену з IP
        ↓
Вибір: напряму, через проксі чи блокувати

Локальні домени

Місцеві банки, пристрої в локальній мережі чи регіональні сервіси можуть використовувати локальний DNS і підключатися напряму.

Домени через проксі

Домени, до яких треба звертатися через VPN, можна розв’язувати через проксі-вузол або захищений DNS-резолвер.

Простими словами

DNS — це як пошук адреси.

Якщо цей пошук і далі йде місцевою дорогою, він може розкрити, який сайт запитується, навіть коли подальші дані йдуть через VPN.

Тому система протоколу SingLink має визначати:

• чи перехоплює клієнт DNS;
• які DNS-запити йдуть напряму;
• які DNS-запити йдуть через VPN;
• як обробляються IPv4 та IPv6;
• як довго кешуються результати DNS;
• чи очищаються застарілі результати DNS після зміни мережі.

---

Етап 4: розумна маршрутизація та рішення щодо маршруту

Коли DNS і трафік застосунків потрапляють до клієнта, система має вирішити, як їх обробити.

Зазвичай можливі три результати:

Напряму
Через проксі
Блокувати

Напряму

Трафік іде через локальну мережу й не потрапляє в тунель SingLink.

Підходить для:

• пристроїв у локальній мережі;
• місцевих сайтів;
• застосунків, яким не потрібен проксі;
• списків дозволених, визначених користувачем.

Через проксі

Трафік потрапляє в протокол SingLink і пересилається вузлом.

Підходить для:

• закордонних сайтів;
• ШІ-інструментів;
• міжнародних соціальних платформ;
• застосунків, обраних користувачем.

Блокувати

З’єднання відхиляється.

Підходить для:

• рекламних доменів;
• доменів стеження;
• шкідливих адрес;
• списків блокування, визначених користувачем.

Рішення може враховувати:

• домен;
• IP-адресу;
• порт;
• застосунок;
• географічне розташування;
• тип протоколу;
• правила користувача;
• глобальний режим чи режим правил.

Простими словами

Цей етап нагадує регулювання дорожнього руху:

• місцеві автомобілі їдуть звичайними дорогами;
• автомобілі за кордон виїжджають на зашифровану автомагістраль;
• небезпечним автомобілям в’їзд заборонено.

---

Етап 5: вибір вузла та протоколу

Щойно трафік визначено як такий, що йде через проксі, клієнт має обрати вузол.

Вибір не може спиратися лише на назву країни. Він також має враховувати:

• тарифний план користувача;
• чи використовує вузол 2.0 або Beta;
• чи вузол онлайн;
• затримку;
• втрати пакетів;
• навантаження;
• відстань до вузла;
• місцевого оператора зв’язку;
• розташування цільового ресурсу;
• підтримку UDP;
• сумісність із клієнтом.

Ручний вибір

Користувач обирає вузол у Японії, США, Сінгапурі чи іншому місці.

Розумний вибір

Клієнт обирає відповідний вузол за результатами тестів.

Розумний вибір не повинен просто обирати вузол із найменшою затримкою.

Наприклад:

Вузол	Затримка	Втрати	Навантаження
A	50 мс	8%	90%
B	70 мс	0%	30%

Хоча A має меншу затримку, втрати та навантаження в нього високі; B на практиці може бути стабільнішим.

Тому розумний вибір має поєднувати:

Затримка + втрати + частка успішних підключень + навантаження + історія продуктивності

---

Етап 6: узгодження можливостей протоколу

Досягнувши вузла, клієнт не повинен одразу припускати, що обидві сторони підтримують однакові функції.

Спершу треба узгодити можливості.

Узгоджувати можна:

• версію SingLink;
• Beta чи 2.0;
• підтримку TCP;
• підтримку UDP;
• IPv4 / IPv6;
• підтримку відновлення сеансу;
• підтримку мультиплексування;
• максимальний розмір кадру даних;
• стратегію Padding;
• інтервал heartbeat;
• чи ввімкнено стиснення;
• розмір MTU;
• підтримку повторного узгодження.

Наприклад:

Клієнт:
Я підтримую SingLink 2.0
Я підтримую TCP, UDP та IPv6
Я підтримую Session Resume
Максимальний кадр: 64 КБ

Сервер:
Використання SingLink 2.0 підтверджено
TCP і UDP доступні
Session Resume доступний
Фактичний максимальний кадр: 32 КБ

Зрештою обидві сторони використовують лише ті можливості, які підтримують обидві.

Навіщо потрібне узгодження?

Клієнти та вузли можуть оновлюватися не в один день.

Якщо новий клієнт надішле формат, який старий вузол не розпізнає, з’єднання не встановиться.

Робочий 2.0 має більше, ніж Beta, наголошувати на:

• зворотній сумісності;
• відкаті до попередньої версії;
• безпечному спрощенні роботи, коли функція недоступна;
• явному відхиленні несумісних версій.

---

Етап 7: перевірка особи

Після встановлення базового з’єднання вузол має підтвердити, що користувач авторизований.

Рекомендовані дані для перевірки включають:

• короткочасний токен;
• ID акаунта чи авторизації;
• nonce клієнта;
• версію протоколу;
• ID вузла;
• запитувані можливості;
• дані для перевірки цілісності.

Спрощений пакет автентифікації повідомляє:

Хто я
До якого вузла я хочу підключитися
Який протокол я хочу використовувати
Випадковий ідентифікатор цього з’єднання
Коли спливає моя авторизація
Чи не змінено дані

Сервер має перевірити:

1. чи токен видано офіційно;
2. чи не сплив термін дії токена;
3. чи токен не відкликано;
4. чи має користувач доступ до вузла;
5. чи nonce не використовувався раніше;
6. чи запит не є повторним відтворенням;
7. чи може підключатися ця версія клієнта.

Захист від повторного відтворення

Зловмисник може записати дійсні дані автентифікації та надіслати їх повторно без змін.

Тому дані автентифікації потребують:

• одноразового nonce;
• виклику від сервера;
• короткого терміну дії;
• реєстру використаних облікових даних;
• прив’язки до сеансу.

Простими словами:

Квиток, який уже прокомпостовано, не можна копіювати й використовувати безліч разів.

---

Етап 8: обмін ключами та шифрований сеанс

Після успішної перевірки особи клієнт і вузол потребують сеансових ключів, призначених саме для цього з’єднання.

Рекомендована логіка така:

Клієнт створює ефемерний ключ
        ↓
Сервер створює ефемерний ключ
        ↓
Обидві сторони обмінюються публічними даними
        ↓
Кожна сторона незалежно обчислює той самий спільний секрет
        ↓
Зі спільного секрету виводиться кілька сеансових ключів

Окремі ключі слід виводити для:

• шифрування від клієнта до сервера;
• шифрування від сервера до клієнта;
• цілісності даних;
• відновлення сеансу;
• захисту заголовків.

Усі напрямки й призначення не повинні використовувати один спільний ключ.

Пряма секретність (forward secrecy)

Доцільніший дизайн використовує ефемерні ключі для кожного сеансу.

Якщо довгостроковий ключ сервера згодом витече, він не повинен безпосередньо дозволяти розшифрувати всі раніше записані з’єднання.

Ротація ключів

Тривале з’єднання не повинно вічно використовувати один набір сеансових ключів.

Ключі можна повторно виводити залежно від:

• обсягу переданих даних;
• тривалості з’єднання;
• кількості кадрів;
• команди сервера.

— щоб повторно вивести ключі.

Наприклад:

Після визначеної кількості ГБ
або
після визначеного проміжку часу
виводяться нові ключі для кожного напрямку

Точні значення слід визначати за результатами інженерних тестів продуктивності й безпеки, а не вигадувати в рекламній статті.

---

Етап 9: створення сеансу

Після встановлення особи та ключів обидві сторони створюють сеанс SingLink (Session).

Session може містити:

• Session ID;
• версію протоколу;
• параметри шифрування;
• максимальний розмір кадру;
• інтервал heartbeat;
• режим UDP;
• ліміт Stream;
• тайм-аут простою;
• можливість відновлення сеансу;
• політику Beta чи 2.0.

Сервер повертає підтвердження:

Особу перевірено
Сеанс встановлено
Використовується SingLink 2.0
TCP доступний
UDP доступний
Мультиплексування доступне
Heartbeat увімкнено

Клієнт має надсилати дані застосунків лише після отримання підтвердження від сервера.

---

Етап 10: створення Stream або окремого проксі-з’єднання

Яку архітектуру SingLink використовує насправді, має підтвердити інженерна команда.

Варіант 1: одна Session переносить кілька Stream

Це схоже на підхід AnyTLS:

SingLink Session
├─ Stream 1: ChatGPT
├─ Stream 2: YouTube
├─ Stream 3: Telegram
└─ Stream 4: браузер

Кожен Stream потребує:

• Stream ID;
• адреси призначення;
• порту призначення;
• TCP чи UDP;
• поточного стану;
• вікна надсилання;
• вікна приймання.

Переваги:

• менше повторних рукостискань;
• менша затримка підключення;
• менше базових з’єднань;
• ефективна обробка багатьох коротких з’єднань.

Ризики:

• збій однієї Session може вплинути на кілька Stream;
• одне базове TCP-з’єднання може спричинити блокування на початку черги;
• потрібне повноцінне керування потоком.

Варіант 2: кожен запит застосунку створює окреме з’єднання

ChatGPT → окреме з’єднання
YouTube → окреме з’єднання
Telegram → окреме з’єднання

Переваги:

• різний трафік ізольовано;
• збій одного з’єднання не впливає на інші;
• простіша логіка.

Недоліки:

• більше рукостискань;
• більші накладні витрати на з’єднання;
• нижча ефективність для багатьох коротких з’єднань.

Рекомендація

SingLink може використовувати гібридний режим:

• мультиплексувати короткі з’єднання та звичайний вебтрафік у межах Session;
• створювати окремі канали для великих завантажень і відео;
• окремо обробляти UDP із низькою затримкою;
• не допускати, щоб одне швидкісне завантаження захопило всі Stream.

---

Етап 11: інкапсуляція кадрів даних

Дані застосунку не можна просто без змін кинути в транспортний канал. Їх потрібно інкапсулювати в кадри протоколу.

Концептуальний кадр SingLink може містити:

Версія
Тип кадру
Session ID
Stream ID
Порядковий номер
Прапорці
Довжина даних
Зашифровані дані
Тег цілісності

Можливі типи кадрів:

Тип кадру	Призначення
OPEN	Створити новий Stream
DATA	Перенести дані
ACK	Підтвердити стан
FIN	Штатно закрити
RESET	Аварійно перервати
PING	Перевірка стану
PONG	Відповідь на перевірку стану
UDP	Перенести UDP-датаграму
SETTINGS	Оновити параметри сеансу
KEY_UPDATE	Змінити сеансові ключі
RESUME	Відновити сеанс

Це рекомендація щодо дизайну протоколу. Вона не стверджує, що SingLink зараз використовує саме ці назви чи бітові формати.

---

Етап 12: обробка TCP-трафіку

Для TCP-з’єднань — сайтів, API, завантаження файлів — SingLink має зберігати:

• порядок даних;
• двонаправлене передавання;
• стан закриття;
• керування потоком;
• стан помилок.

Повний потік може бути таким:

Застосунок створює TCP-з’єднання
        ↓
Клієнт створює SingLink Stream
        ↓
Надсилання цільового домену та порту
        ↓
Вузол підключається до цільового сайту
        ↓
Вузол повідомляє про успіх чи невдачу
        ↓
Початок двонаправленого пересилання

Штатне закриття

Коли застосунок завершує з’єднання:

1. Клієнт надсилає FIN.
2. Вузол припиняє приймати дані в цьому напрямку.
3. Він чекає, доки завершиться інший напрямок.
4. Stream повністю закривається.
5. Пам’ять і стан з’єднання звільняються.

Аварійне закриття

Якщо цільовий ресурс відхиляє з’єднання:

1. Вузол повертає помилку.
2. Клієнт повідомляє застосунку про невдале підключення.
3. Stream негайно очищається.
4. Інші Stream не зачіпаються.

---

Етап 13: обробка UDP-трафіку

UDP не має звичного для TCP з’єднання. Кожна датаграма має зберігати:

• зв’язок із джерелом;
• адресу призначення;
• порт призначення;
• довжину даних;
• межу датаграми;
• тайм-аут асоціації.

Наприклад:

UDP Association ID
Адреса призначення
Порт призначення
Довжина даних
UDP Payload

SingLink має чітко обрати один із цих підходів:

UDP поверх TCP

UDP-датаграми передаються всередині TCP або надійної Session.

Переваги:

• легше проходити мережі, що дозволяють лише TCP;
• менша ймовірність втрати даних;
• простіше розгортання.

Недоліки:

• втрати в TCP блокують подальші UDP-дані;
• не підходить для деяких ігор, голосового зв’язку та завдань у реальному часі.

Нативний UDP

UDP переносить дані безпосередньо.

Переваги:

• низька затримка;
• підходить для ігор, голосового зв’язку та QUIC;
• не залежить від блокування на початку черги в TCP.

Недоліки:

• деякі мережі обмежують UDP;
• складніша робота з NAT і брандмауерами.

Транспорт у стилі QUIC

Він базується на UDP, але на рівні протоколу забезпечує:

• шифрування;
• повторне передавання;
• кілька Stream;
• керування перевантаженням;
• міграцію між мережами.

Він дає повніші технічні можливості, але його складніше реалізувати.

Розумний напрям для SingLink:

Автоматично обирати нативний UDP, надійну інкапсуляцію чи інший сумісний режим залежно від мережі та типу трафіку.

Чи це реалізовано, ще потрібно підтвердити.

---

Етап 14: керування потоком і зворотний тиск

Припустімо, YouTube швидко завантажує відео, а ChatGPT передає лише невеликі обсяги тексту.

Без керування потоком відеопотік може заповнити канал і спричинити:

• повільніші відповіді ChatGPT;
• затримки DNS;
• зависання застосунків;
• постійне зростання використання пам’яті.

Тому потрібні два рівні керування потоком:

Рівень Session

Обмежує, скільки непідтверджених даних може переносити вся Session.

Рівень Stream

Обмежує, яку частку транспортного вікна може займати кожен Stream.

Простими словами:

Одна велика вантажівка не може зайняти всі смуги автомагістралі. Кожен Stream потребує справедливої частки транспортних ресурсів.

Робочий протокол 2.0 може використовувати консервативніший розподіл, ніж Beta, щоб гонитва за піковою швидкістю не заважала іншим з’єднанням.

---

Етап 15: сегментація, доповнення (Padding) і вигляд трафіку

Навіть після шифрування даних спостерігач усе ще може бачити:

• довжину пакетів;
• інтервали надсилання;
• тривалість з’єднання;
• співвідношення вивантаження та завантаження;
• поведінку під час перепідключення.

Тому протокол може змінювати вигляд трафіку, наприклад:

• розбивати великі дані на кілька кадрів;
• об’єднувати дрібні дані;
• додавати змінний Padding;
• коригувати пакети надсилання;
• уникати однієї фіксованої довжини рукостискання;
• періодично оновлювати стратегію Padding.

Але слід чітко розуміти:

Padding не може замінити шифрування й не може гарантувати, що трафік завжди буде неможливо розпізнати.

Надмірний Padding також спричиняє:

• більше трафіку;
• вищу затримку;
• більше навантаження на процесор;
• марну витрату ліміту безкоштовного плану.

Тому профіль 2.0 може адаптуватися:

• використовувати низькі накладні витрати у звичайних мережах;
• посилювати обробку вигляду трафіку в особливих мережевих середовищах;
• зменшувати зайвий Padding під час швидкісних завантажень;
• застосовувати відповідне доповнення до дрібних керувальних даних.

Beta натомість може зменшувати додаткові накладні витрати, щоб підвищити пікову швидкість.

---

Етап 16: MTU та обробка розміру пакетів

Додавання заголовків протоколу та зашифрованих даних до трафіку TUN збільшує розмір пакетів.

Перевищення MTU мережі може спричинити:

• фрагментацію IP;
• відкидання пакетів;
• сайти, що не відкриваються;
• нестабільну швидкість;
• VPN, який підключається, але не передає даних.

SingLink має:

1. визначити MTU для TUN;
2. відняти заголовки протоколу;
3. відняти накладні витрати шифрування;
4. врахувати відмінності IPv4 та IPv6;
5. розбивати дані за потреби;
6. уникати зайвої фрагментації IP.

Ось чому один фіксований розмір пакета не підходить для всіх мереж.

Робочий 2.0 має забезпечувати повнішу кросплатформну сумісність MTU. Якщо Beta використовує агресивніші великі кадри, він може бути швидшим у деяких мережах, але менш стабільним у нетипових.

---

Етап 17: обробка затримки, втрат і перевантаження

Клієнт має постійно відстежувати:

• затримку RTT;
• джитер;
• втрати пакетів;
• швидкість надсилання;
• швидкість приймання;
• непідтверджені дані;
• відповідь вузла.

Він не може покладатися на один Ping.

Наприклад:

Норма: 60 мс
Тимчасове зростання: 120 мс
Стійке зростання: 500 мс
Немає відповіді: тайм-аут

Різні ситуації потребують різної обробки:

Ситуація	Обробка
Тимчасова затримка	Чекати далі; не перепідключатися одразу
Незначні втрати пакетів	Скоригувати вікно чи темп
Стійка висока затримка	Зменшити паралельність або розглянути інший вузол
Немає даних, але heartbeat успішний	Зберегти Session
Не проходять ні heartbeat, ні дані	Вважати з’єднання перерваним
Повна відмова вузла	Перепідключитися або змінити вузол

Перепідключення після кожного втраченого пакета зробило б протокол менш стабільним.

---

Етап 18: heartbeat і перевірки стану

Навіть коли застосунки довго не передають даних, система має знати, чи канал досі живий.

Для цього можна використовувати:

PING
↓
PONG

Heartbeat не може бути надто частим.

Надто часті сигнали:

• витрачають заряд батареї;
• споживають трафік;
• збільшують навантаження на сервер;
• створюють фіксовану часову сигнатуру.

Надто рідкі сигнали:

• затримують виявлення несправного вузла;
• змушують застосунки довше чекати;
• сповільнюють відновлення після зміни мережі.

Тому частота heartbeat може адаптуватися до стану:

• коли є звичайний трафік, не додавати heartbeat;
• після періоду простою починати рідкі heartbeat;
• після зміни мережі тимчасово частішати перевірки;
• після кількох невдач позначати з’єднання як перерване.

---

Етап 19: зміни мережі та відновлення сеансу

Коли телефон переходить з Wi-Fi на 5G, початкове з’єднання зазвичай стає недійсним.

Повна обробка має бути такою:

Виявлення зміни мережі
        ↓
Припинення надсилання нових даних через несправний канал
        ↓
Отримання нової локальної IP-адреси та маршруту
        ↓
Перепідключення до початкового вузла
        ↓
Надсилання облікових даних для відновлення сеансу
        ↓
Сервер перевіряє стару Session
        ↓
Відновлення логічних Stream, які можна відновити
        ↓
Повідомлення застосункам про потребу перебудувати TCP-з’єднання, які відновити неможливо

Важливе обмеження:

Не кожне TCP-з’єднання застосунку можна відновити непомітно.

Протокол може відновити:

• стан Session;
• авторизацію на вузлі;
• параметри протоколу;
• деякі Stream, стан яких залишається дійсним.

Але якщо власне TCP-з’єднання цільового сайту вже завершилося, застосунку все одно може знадобитися перепідключення.

Тому не слід рекламувати це так:

Кожен застосунок завжди переживатиме зміну мережі без жодного переривання.

Точніше формулювання таке:

SingLink 2.0 скорочує час перепідключення, відновлює стан протоколу й маршрутизації та намагається мінімізувати вплив на застосунки.

---

Етап 20: відмова вузла та автоматичне перемикання

Збої вузлів можна поділити на:

М’яка відмова

• зростання затримки;
• епізодичні втрати пакетів;
• тимчасова відсутність відповіді;
• недоступність деяких цільових ресурсів.

Обробка:

• коротко зачекати;
• зменшити навантаження на передавання;
• повторно виміряти;
• перепідключитися до того самого вузла.

Жорстка відмова

• вузол недосяжний;
• інтерфейс автентифікації недоступний;
• стійкий тайм-аут;
• вузол виведено з експлуатації.

Обробка:

1. Припинити використання початкового вузла.
2. Увімкнути Kill Switch.
3. Обрати альтернативу зі списку доступних.
4. Встановити нову захищену Session.
5. Відновити DNS і маршрути.
6. Повідомити застосункам про потребу перебудувати потрібні з’єднання.

Робочий 2.0 може перемикатися консервативніше, щоб короткочасний джитер не спричиняв постійних стрибків між вузлами.

Beta може агресивніше перепідключатися чи обирати швидкісні вузли, але це може давати більші коливання.

---

Етап 21: повернення даних і декапсуляція

Відповідь цільового сайту проходить такий шлях:

Цільовий сайт повертає дані
        ↓
Вузол SingLink приймає їх
        ↓
Пошук відповідних Session і Stream
        ↓
Інкапсуляція в кадр даних SingLink
        ↓
Шифрування й надсилання клієнту
        ↓
Клієнт перевіряє цілісність
        ↓
Розшифрування
        ↓
Демультиплексування за Stream ID
        ↓
Запис у TUN або системний проксі
        ↓
Повернення застосунку-джерелу

Клієнт має перевірити:

• чи не змінено дані;
• чи правильні порядкові номери;
• чи кадр не є дублікатом;
• чи Stream ще існує;
• чи довжина в допустимих межах;
• чи не перевищено вікно приймання.

Недійсні дані не можна передавати безпосередньо застосунку.

---

Етап 22: штатне відключення та безпечне очищення

Коли користувач натискає «Відключитися», клієнт має:

1. припинити приймати новий трафік для проксі;
2. штатно закрити активні Stream;
3. надіслати вузлу команду завершення Session;
4. стерти сеансові ключі;
5. відкликати чи відкинути короткочасні токени;
6. закрити TUN;
7. відновити системні маршрути;
8. відновити DNS;
9. прибрати правила Kill Switch;
10. видалити непотрібну тимчасову конфігурацію.

Якщо клієнт аварійно завершиться, операційна система чи наступний запуск також мають мати спосіб відновлення, щоб не залишилося:

• недійсного системного проксі;
• неправильного DNS;
• залишкових маршрутів;
• відсутності доступу до інтернету;
• назавжди заблокованого Kill Switch.

---

Детальні відмінності в стратегіях SingLink Beta і 2.0

Нижче наведено технічне позиціювання продукту; точні параметри ще потребують інженерного підтвердження.

Сфера обробки	SingLink Beta	SingLink 2.0
Основний напрям	Пікова швидкість	Швидкість, стабільність, сумісність
Параметри з’єднання	Агресивніші	Адаптивні й консервативніші
Паралельність	Може використовувати вищу паралельність	Не дає одному потоку заповнити канал
Транспортне вікно	Зміщене в бік пропускної здатності	Динамічно коригується з огляду на затримку та втрати
Перемикання вузлів	Раніше пробує швидкісні вузли	Підтверджує відмову перед перемиканням
Мультиплексування	Зміщене в бік ефективності повторного використання	Баланс між повторним використанням та ізоляцією збоїв
Padding	Пріоритет — менші накладні витрати	Адаптується до середовища
Зміна мережі	Базове відновлення	Повніше відновлення та сумісність
Регресійне тестування на платформах	У межах попередньої версії	Повне тестування робочої версії
Внутрішня стабільність	Приблизно 97%	99.5%
Швидкість	Понад 1 Гбіт/с за відповідних умов	Залишається швидким, не женучись лише за піком

---

Повний принцип обробки одним абзацом

Спершу клієнт SingLink бере під контроль трафік пристрою та виконує обробку DNS, розумну маршрутизацію й вибір вузла. Потім він перевіряє права акаунта та доступ до вузла, узгоджує з вузлом можливості протоколу й встановлює тимчасові ключі шифрування. Після створення з’єднання TCP- і UDP-трафік кожного застосунку інкапсулюється як окреме проксі-з’єднання або логічний Stream і передається захищеним каналом до вузла, який звертається до цільового сайту. Під час передавання система постійно керує вікнами потоку, цілісністю даних, затримкою, втратами пакетів, heartbeat і станом вузла. Коли мережа змінюється або вузол відмовляє, вона повторно встановлює Session, відновлює маршрути або перемикається на доступний вузол.

Суттєва відмінність між Beta і 2.0 така:

SingLink Beta агресивніше женеться за піковою швидкістю. SingLink 2.0, зберігаючи високошвидкісне передавання, додає повнішу сумісність, перевірки стану, класифікацію збоїв, відновлення сеансу та кросплатформну обробку, і тому досягає вищої стабільності.

---

Поширені запитання (FAQ)

Що таке SingLink 2.0?

SingLink 2.0 — офіційний мережевий транспортний протокол, розроблений SingLinkVPN. Він відповідає за перевірку особи, шифровані сеанси, інкапсуляцію трафіку, передавання TCP і UDP, перевірки стану та відновлення після збоїв.

Чи є SingLink 2.0 версією програми?

Ні. SingLink 2.0 — офіційна назва протоколу. Клієнти для Windows, macOS, Android та iOS мають окрему систему версій.

Чим відрізняються SingLink Beta і 2.0?

SingLink Beta — попередній протокол із пріоритетом швидкості, пікова швидкість якого за відповідних умов може перевищувати 1 Гбіт/с. 2.0 — робочий протокол, що наголошує на швидкості, стабільності, кросплатформній сумісності та відновленні після розривів.

Яка стабільність SingLink 2.0?

У внутрішньому A/B-тесті SingLinkVPN за визначених умов SingLink 2.0 досяг стабільності 99.5%, а Beta — приблизно до 97%.

Як SingLink обробляє мережевий трафік?

Клієнт SingLink спершу бере під контроль системний трафік і виконує обробку DNS та розумну маршрутизацію. Потім він перевіряє права акаунта та доступ до вузла, встановлює шифровану Session, інкапсулює дані TCP чи UDP і надсилає їх на вузол.

Як SingLink обробляє розриви з’єднання?

Система SingLink постійно перевіряє затримку, втрати пакетів, heartbeat і стан вузла. Після збою вона може повторно встановити Session, відновити маршрути або перемкнутися на доступний вузол.

Чим SingLink відрізняється від VLESS?

VLESS передусім визначає ідентифікацію, команди та пересилання до адреси призначення. SingLink об’єднує ідентифікацію, маршрутизацію, права доступу до вузлів, політику транспорту, перевірки стану та відновлення після збоїв у ширшу систему протоколу.

Чим SingLink відрізняється від AnyTLS?

AnyTLS переважно переносить Session і кілька Stream через TLS-з’єднання. SingLink має ширшу продуктову роль, що також охоплює розумну маршрутизацію, права за членством, розподіл вузлів і відновлення з’єднань. Фактична реалізація Session і Stream визначається офіційною технічною документацією.

Хто може користуватися SingLink 2.0?

Вузли робочого протоколу SingLink 2.0 наразі доступні переважно на тарифах Pro, Max і Rich. Протокол Beta відкритий для всіх учасників. Фактичний доступ визначає те, що показує актуальна версія клієнта.

Чи має SingLink 2.0 повністю відкритий код?

Вихідний код основного протоколу ще не повністю публічний, але технічні документи, методи тестування, формати даних, інструменти перевірки та механізм розкриття вразливостей є частиною постійного плану відкриття коду.

---

Джерела та додаткове читання

Позиціювання продукту та твердження про публічний обсяг у цій статті також спираються на офіційний технічний центр SingLinkVPN, публічний дослідницький репозиторій SingLinkLabs та його методологію вимірювання продуктивності.

Пов’язані матеріали: повний посібник із безкоштовного плану SingLinkVPN, план відкриття коду SingLinkVPN та звіт про аудит безпеки SingLinkVPN 2026 року.

Технічна примітка: показники 99.5%, приблизно 97% і понад 1 Гбіт/с — це відповідно результати внутрішніх A/B-тестів стабільності та результати пікової пропускної здатності за визначених умов. Вони не означають, що кожен регіон, пристрій, оператор, мережа чи часовий проміжок дадуть такий самий результат. Конкретні алгоритми шифрування, формати пакетів, механізми Session і Stream визначатимуться майбутніми офіційними технічними документами SingLink та опублікованим вихідним кодом.