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 Gbpsを超えるピーク速度を記録しています。

主要データの比較： 正式版SingLink 2.0は指定されたテスト環境で99.5%の安定率を記録しました。Betaは最高約97%ですが、適切なネットワークと端末条件ではピーク速度が1 Gbps超に達します。これらはそれぞれ安定性重視と速度重視の傾向を示す結果であり、すべての端末やネットワークに対する保証値ではありません。

根拠と技術上の境界： 確認済みの製品位置付け、内部テストの測定基準、公開機能は直接引用できます。一方、本稿で扱う具体的な暗号アルゴリズム、パケット形式、能力ネゴシエーション、Session、Stream、多重化、セッション復旧は参考処理モデルであり、現在配備済みの仕様とはみなせません。今後SingLinkが公開する正式な技術文書とソースコードを基準にしてください。

SingLinkプロトコルの完全な処理原理

システム全体は次の2系統に分けられます。

コントロールプレーン

担当する処理：

  • アカウントへのログイン

  • 会員資格の検証

  • ノードの取得

  • ノード権限の判定

  • プロトコル設定の配布

  • ルールの更新

  • 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. 機密設定をOSの安全な保存領域へ格納する。

この層では主に次の項目を判定します。

  • ユーザーが有効な会員か

  • Betaと2.0のどちらを利用できるか

  • Pro、Max、Richの権限を持つか

  • 利用可能な国とノード

  • 設定が期限切れか

  • クライアントの更新が必要か

わかりやすい例

高速鉄道へ乗る前にシステムが次の項目を確認するのと同じです。

  • 利用者が誰か

  • どの等級の切符を購入したか

  • どの列車に乗れるか

  • 切符がまだ有効か

推奨されるセキュリティルール

SingLinkは、永久に変わらない単一の静的パスワードへ長期間依存すべきではありません。

より適切なのは次の仕組みです。

  • 短期接続Token

  • ワンタイムChallenge

  • 端末が生成するNonce

  • 有効期限

  • サーバー署名付きノード設定

  • 失効機構

これにより、一度の接続設定が取得されたとしても、恒久的に使用できることにはなりません。

第2段階：システムネットワーク入口の作成

ユーザーが接続をクリックすると、SingLinkVPNはまずOS上にネットワーク入口を作成します。

処理方法はプラットフォームによって異なります。

プラットフォーム

一般的なネットワーク入口

iOS／iPadOS

Network Extension／Packet Tunnel

Android

VPN Service

macOS

Network ExtensionまたはTUN

Windows

TUN仮想NICとシステムルーティング

Linux

TUN、ルーティングテーブル、DNS管理

作成後、アプリケーションからネットワークへ直接送られていたデータは、先にSingLinkVPNクライアントへ入ります。

例：

ChatGPT App
    ↓
OSネットワークスタック
    ↓
SingLink TUNインターフェース
    ↓
SingLinkVPNクライアント

この段階でクライアントが行う処理：

  • 仮想IPの作成

  • ルーティングテーブルの設定

  • DNSの設定

  • ローカルLANの除外

  • プロキシ接続が再びTUNへ戻されることの防止

最後の項目は特に重要です。

「ルート除外」がなければ、SingLinkVPNがノードへ接続するためのトラフィックまで再びVPNへ入り、ループする可能性があります。

VPNトラフィック
↓
再びVPNへ入る
↓
再びカプセル化
↓
無限ループ

したがって、クライアントは次を明示的に除外する必要があります。

  • ノード自体のIP

  • 必要な制御インターフェース

  • ローカルゲートウェイ

  • OSが直接アクセスする必要のあるサービス

第3段階：DNS名前解決とドメイン判定

ユーザーが chatgpt.com を開くとき、端末は通常、先にドメイン名をIPアドレスへ解決します。

DNS処理が適切でない場合、次の問題が起こり得ます。

  • DNS要求がローカルネットワークへ直接流れる

  • ローカルDNSが誤ったアドレスを返す

  • ルールがドメインを判定できない

  • IPv6がVPNを迂回する

  • VPN接続後もDNSが漏えいする

SingLinkクライアントは次のフローで処理できます。

アプリがDNS要求を送信
        ↓
クライアントがDNSをインターセプト
        ↓
ドメインルールを判定
        ↓
ローカルDNSまたはリモートの安全なDNSを選択
        ↓
IPv4／IPv6の結果を取得
        ↓
ドメインとIPを関連付け
        ↓
直接接続、プロキシ、ブロックを決定

ローカルドメイン

現地の銀行、LAN内機器、地域限定サービスなどは、ローカルDNSを使用して直接接続できます。

プロキシ対象ドメイン

VPN経由でアクセスするドメインは、プロキシノードまたは保護されたDNSで名前解決できます。

わかりやすい例

DNSは住所録を調べる仕組みに似ています。

住所録を調べる過程がローカル回線を通るままだと、その後のデータがVPNを通っても「どのサイトを調べているか」が露出する可能性があります。

そのため、SingLinkプロトコル体系では次を明確に定義する必要があります。

  • クライアントがDNSをインターセプトするか

  • 直接接続するDNS要求

  • VPN経由にするDNS要求

  • IPv4とIPv6の処理方法

  • DNSキャッシュの保持期間

  • ネットワーク切り替え後に古いDNS結果を削除するか

第4段階：スマートルーティングと経路判定

DNSとアプリケーショントラフィックがクライアントへ入ると、システムはその処理方法を決定します。

通常、結果は次の3種類です。

直接接続
プロキシ
ブロック

直接接続

トラフィックはローカルネットワークを直接使用し、SingLinkトンネルへ入りません。

対象：

  • LAN内機器

  • ローカルサイト

  • プロキシを必要としないアプリ

  • ユーザー定義の許可リスト

プロキシ

トラフィックはSingLinkプロトコルへ入り、ノードによって転送されます。

対象：

  • 海外サイト

  • AIツール

  • 国際的なソーシャルプラットフォーム

  • ユーザー指定のアプリ

ブロック

接続を拒否します。

対象：

  • 広告ドメイン

  • トラッキングドメイン

  • 悪意のあるアドレス

  • ユーザー設定のブロックリスト

判定基準には次が含まれます。

  • ドメイン名

  • IPアドレス

  • ポート

  • アプリケーション

  • 地理的位置

  • プロトコルの種類

  • ユーザールール

  • グローバルモードまたはルールモード

わかりやすい例

この段階は交通の振り分けに相当します。

  • 地元の車両は一般道を通る

  • 海外へ向かう車両は暗号化された高速道路へ入る

  • 危険な車両は通行を禁止する

第5段階：ノードとプロトコルの選択

トラフィックをプロキシ経由にすると決まった後、クライアントは接続先ノードを選択します。

ノード選択では国名だけでなく、次の要素も考慮する必要があります。

  • ユーザーのプラン

  • ノードが2.0かBetaか

  • ノードがオンラインか

  • 遅延

  • パケット損失

  • 負荷

  • ノードまでの距離

  • 現地の通信事業者

  • 対象サイトの場所

  • ノードがUDPに対応するか

  • クライアントとの互換性

手動選択

ユーザーが日本、米国、シンガポールなどのノードを自分で選択します。

スマート選択

クライアントが測定結果に基づいて適切なノードを選択します。

スマート選択では、遅延が最小という理由だけでノードを決めるべきではありません。

例：

ノード

遅延

パケット損失

負荷

A

50ms

8%

90%

B

70ms

0%

30%

Aは遅延が小さい一方、パケット損失と負荷が高いため、実際の利用ではBのほうが安定する可能性があります。

したがってスマート選択では、次を総合的に評価します。

遅延＋パケット損失＋接続成功率＋負荷＋過去の実績

第6段階：プロトコル機能のネゴシエーション

クライアントがノードに接続しても、双方がまったく同じ機能に対応していると直ちに仮定してはいけません。

まず機能ネゴシエーションを行う必要があります。

交渉項目には次が含まれます。

  • SingLinkのバージョン

  • Betaまたは2.0

  • TCP対応

  • UDP対応

  • IPv4／IPv6

  • セッション再開への対応

  • 多重化への対応

  • 最大データフレーム

  • Padding方針

  • ハートビート間隔

  • 圧縮を有効にするか

  • MTUサイズ

  • 再ネゴシエーション能力

例：

クライアント：
SingLink 2.0に対応
TCP、UDP、IPv6に対応
Session Resumeに対応
最大フレーム64KB

サーバー：
SingLink 2.0の使用を確認
TCP、UDPを利用可能
Session Resumeを利用可能
実際の最大フレーム32KB

最終的に、双方が共通して対応する機能を使用します。

なぜネゴシエーションが必要なのか

クライアントとノードが同じ日に更新されるとは限らないためです。

新しいクライアントが古いノードの理解できない形式を直接送信すると、接続は失敗します。

正式版2.0ではBeta以上に次を重視すべきです。

  • 後方互換性

  • バージョンフォールバック

  • 未対応機能に対する安全な機能縮退

  • 非互換バージョンの明確な拒否

第7段階：本人確認

基本接続の完了後、ノードはユーザーに利用権限があるかを確認します。

推奨される検証データは次のとおりです。

  • 短期Token

  • アカウントまたは認可ID

  • クライアントの乱数

  • プロトコルバージョン

  • ノードID

  • 要求する機能

  • 完全性検証データ

検証パケットを平易に表すと、次の情報です。

私は誰か
どのノードを使うか
どのプロトコルを使うか
今回の接続に割り当てた乱数
認可の有効期限
データが改変されていないか

サーバー側は次を確認します。

  1. Tokenが公式に発行されたものか

  2. Tokenが期限切れではないか

  3. Tokenが失効していないか

  4. ユーザーがノードの利用権限を持つか

  5. 乱数が以前に使用されていないか

  6. リクエストがリプレイされていないか

  7. クライアントのバージョンに接続が許可されているか

リプレイ攻撃対策

攻撃者は正当な検証データを一度記録し、そのまま再送する可能性があります。

そのため検証データには次を含める必要があります。

  • 使い捨てNonce

  • サーバーChallenge

  • 短い有効期間

  • 使用済み資格情報の記録

  • セッションへの紐付け

平易に言えば、次のとおりです。

一度検札された同じ乗車券を複製し、無制限に使うことはできません。

第8段階：鍵交換と暗号化セッション

本人確認に成功した後、クライアントとノードは今回の接続専用のセッション鍵を確立します。

推奨される流れは次のとおりです。

クライアントが一時鍵を生成
        ↓
サーバーが一時鍵を生成
        ↓
双方が公開情報を交換
        ↓
それぞれがローカルで同じ共有鍵を計算
        ↓
共有鍵から複数のセッション鍵を導出

次の鍵は用途別に導出する必要があります。

  • クライアントからサーバーへの暗号鍵

  • サーバーからクライアントへの暗号鍵

  • データ完全性鍵

  • セッション再開鍵

  • Header保護鍵

すべての方向と用途で同じ鍵を共有すべきではありません。

前方秘匿性

各セッションで一時鍵を使うほうが合理的です。

これにより、将来サーバーの長期鍵が漏えいしても、過去に記録されたすべてのトラフィックが直ちに復号されることを防げます。

鍵のローテーション

長時間の接続で、同じセッション鍵を恒久的に使用すべきではありません。

次の条件に応じて、

  • 転送したデータ量

  • 接続時間

  • フレーム数

  • サーバーからの要求

鍵を再導出できます。

例：

一定のGBを転送するごと
または
一定時間ごとに
方向別の鍵を再生成

具体的なしきい値は、性能試験とセキュリティ試験を通じて決定されます。

第9段階：Sessionの確立

本人確認と鍵の確立後、双方はSingLink Sessionを確立します。

Sessionには次が含まれます。

  • Session ID

  • プロトコルバージョン

  • 暗号化パラメーター

  • 最大フレームサイズ

  • ハートビート間隔

  • UDPモード

  • Stream上限

  • アイドルタイムアウト

  • セッション再開能力

  • Betaまたは2.0の方針

サーバーは確認結果を返します。

本人確認に成功
セッション確立に成功
SingLink 2.0を使用
TCPを利用可能
UDPを利用可能
多重化を利用可能
ハートビートを有効化

クライアントはサーバーの確認を受信してから、アプリケーションデータの正式な送信を開始します。

第10段階：Streamまたは独立プロキシ接続の確立

この段階でよく使われるアーキテクチャは2種類あります。

方式1：1つのSessionで複数のStreamを伝送

AnyTLSに似た考え方です。

SingLink Session
├─ Stream 1：ChatGPT
├─ Stream 2：YouTube
├─ Stream 3：Telegram
└─ Stream 4：ブラウザー

各Streamには次が必要です。

  • Stream ID

  • 宛先アドレス

  • 宛先ポート

  • TCPまたはUDP

  • 現在の状態

  • 送信ウィンドウ

  • 受信ウィンドウ

利点：

  • 重複するハンドシェイクを削減できる

  • 接続遅延を抑えられる

  • 下位レイヤーの接続数を減らせる

  • 多数の短時間接続に適する

リスク：

  • 1つのSessionの問題が複数のStreamに影響する可能性がある

  • 単一のTCP下位レイヤーでヘッドオブラインブロッキングが発生する可能性がある

  • 十分なフロー制御が必要になる

方式2：アプリケーション要求ごとに独立接続を確立

ChatGPT → 独立接続
YouTube → 独立接続
Telegram → 独立接続

利点：

  • 異なるトラフィックを相互に分離できる

  • 1つの接続の失敗がほかの接続に影響しない

  • ロジックが比較的単純になる

欠点：

  • ハンドシェイクが増える

  • 接続オーバーヘッドが大きくなる

  • 多数の短時間接続では効率が下がる

推奨

SingLinkはハイブリッド方式を採用できます。

  • 短時間接続と一般的なWeb閲覧にはSession多重化を使用する

  • 大容量ダウンロードと動画には独立したチャネルを確立する

  • 低遅延UDPは独立して処理する

  • 1つの高速ダウンロードがすべてのStreamを占有しないようにする

第11段階：データフレームへのカプセル化

アプリケーションデータをそのまま伝送チャネルへ投入することはできず、プロトコルフレームにカプセル化する必要があります。

概念上のSingLinkフレームには次を含められます。

バージョン
フレーム種別
Session ID
Stream ID
シーケンス番号
Flags
データ長
暗号化データ
完全性タグ

フレーム種別には次が考えられます。

フレーム種別

役割

OPEN

新しいStreamを確立

DATA

データを転送

ACK

状態を確認

FIN

正常に終了

RESET

異常終了

PING

ヘルスチェック

PONG

ヘルスチェックへ応答

UDP

UDPパケットを転送

SETTINGS

セッション設定を更新

KEY_UPDATE

セッション鍵を更新

RESUME

セッションを再開

これはプロトコル設計上の提案であり、現在のSingLinkがこれらの名称やビット形式を使用していることを示すものではありません。

第12段階：TCPトラフィックの処理

Webページ、API、ファイルダウンロードなどのTCP接続では、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-over-TCP

UDPパケットをTCPまたは信頼性のあるSessionに格納して転送します。

利点：

  • TCPしか許可しないネットワークを通過しやすい

  • データが失われにくい

  • 導入が容易

欠点：

  • TCPで損失が起きると後続のUDPデータがブロックされる

  • 一部のゲーム、音声、リアルタイム用途には適さない

原生UDP

UDPで直接伝送します。

利点：

  • 遅延が小さい

  • ゲーム、音声、QUICに適する

  • TCPのヘッドオブラインブロッキングの影響を受けない

欠点：

  • UDPを制限するネットワークがある

  • NATとファイアウォールの処理がより複雑になる

QUIC方式の伝送

UDPを基盤に、プロトコル層で次を提供します。

  • 暗号化

  • 再送

  • 複数Stream

  • 輻輳制御

  • ネットワーク移行

機能はより充実しますが、実装の複雑さも高まります。

SingLinkの合理的な方向性は次のとおりです。

ネットワークとトラフィック種別に応じて、UDPのネイティブ伝送、信頼性のあるカプセル化、または別の互換モードを自動選択する。

第14段階：フロー制御とバックプレッシャー

YouTubeのダウンロードが非常に速く、ChatGPTは少量のテキストしか送らない状況を想定します。

フロー制御がなければ、動画のStreamがチャネル全体を占有し、次の問題が起こり得ます。

  • ChatGPTの応答が遅くなる

  • DNSの遅延が増える

  • ほかのアプリケーションが停止する

  • メモリ使用量が増え続ける

したがって2段階のフロー制御が必要です。

Session単位

Session全体で同時に送信できる未確認データ量を制限します。

Stream単位

各Streamが使用できる伝送ウィンドウを制限します。

平易に言えば、次のとおりです。

1台の大型トラックに高速道路の全車線を占有させてはいけません。各Streamへ道路資源を適切に配分する必要があります。

2.0正式版プロトコルではBetaより慎重なトラフィックスケジューリングを採用し、ピーク速度の追求がほかの接続に影響しないようにできます。

第15段階：分割、Padding、トラフィック外観

データを暗号化した後でも、外部から次の特徴が見える可能性があります。

  • パケット長

  • 送信間隔

  • 接続の継続時間

  • 上りと下りの比率

  • 再接続の挙動

そのため、プロトコルは次のようなトラフィック外観の処理を行えます。

  • 大きなデータを複数フレームに分割する

  • 小さなデータを結合する

  • 可変Paddingを追加する

  • 送信バッチを調整する

  • すべてのハンドシェイク長が固定されることを避ける

  • Padding方針を定期的に更新する

ただし、次を明確にする必要があります。

Paddingは暗号化の代わりにはならず、トラフィックが永久に識別不能になることも保証しません。

過剰なPaddingは次の負担も生みます。

  • トラフィック量の増加

  • 遅延の増加

  • CPU消費の増加

  • 無料通信量の浪費

したがって2.0では適応型の方針を使用できます。

  • 通常のネットワークでは低オーバーヘッドにする

  • 特殊なネットワーク環境では外観処理を増やす

  • 高速ダウンロード時には不要なPaddingを減らす

  • 小さな制御データには適切なPaddingを加える

Betaはピーク速度を高めるため、追加オーバーヘッドの削減をより優先する可能性があります。

第16段階：MTUとパケットサイズの処理

TUNトラフィックにプロトコルヘッダーと暗号化データを追加すると、パケットは大きくなります。

ネットワークMTUを超えると、次が発生する可能性があります。

  • IPフラグメンテーション

  • パケットの破棄

  • 一部サイトを開けない

  • 速度が不安定になる

  • VPNには接続できても通信できない

SingLinkには次の処理が必要です。

  1. TUN MTUを決定する

  2. プロトコルヘッダー分を差し引く

  3. 暗号化オーバーヘッド分を差し引く

  4. IPv4、IPv6に応じて調整する

  5. 必要に応じてデータを分割する

  6. 不要なIPフラグメンテーションを避ける

同じ固定パケットサイズがすべてのネットワークに適するとは限らないのは、このためです。

正式版2.0では、より包括的なクロスプラットフォームMTU互換処理を備えるべきです。Betaがより積極的な大容量フレーム方針を使う場合、一部ネットワークでは高速になる一方、特殊なネットワークでは安定性が低くなる可能性があります。

第17段階：遅延、パケット損失、輻輳の処理

クライアントは次を継続的に監視する必要があります。

  • RTT遅延

  • 遅延の変動

  • パケット損失

  • 送信速度

  • 受信速度

  • 未確認データ

  • ノードの応答

1回のPingだけに依存してはいけません。

例：

正常：60ms
一時的な上昇：120ms
継続的な上昇：500ms
まったく応答なし：タイムアウト

状況に応じて異なる処理が必要です。

状況

処理方法

一時的な遅延

待機を続け、直ちに再接続しない

軽微なパケット損失

ウィンドウまたは送信ペースを調整

継続的な高遅延

同時実行数を減らすかノード切替を検討

データはないがハートビートあり

セッションを維持

ハートビートとデータがともに失敗

接続切断と判定

ノードが完全に停止

再接続またはノード切替

1回のパケット損失だけで再接続すると、かえってプロトコルが不安定になります。

第18段階：ハートビートとヘルスチェック

アプリケーションデータが長時間流れない場合でも、システムはチャネルが存続しているかを把握する必要があります。

次を使用できます。

PING
↓
PONG

ただし、ハートビートを頻繁に送信しすぎてはいけません。

頻度が高すぎると次の問題が起こります。

  • バッテリーを浪費する

  • 通信量を消費する

  • サーバー負荷が増える

  • 固定間隔の特徴が形成される

一方、頻度が低すぎると次の問題が起こります。

  • ノード停止の検出が遅れる

  • アプリケーションの待機時間が長くなる

  • ネットワーク切替後の復旧が遅くなる

そのため、状態に応じてハートビートを調整できます。

  • 通常のトラフィックがある間は追加のハートビートを送らない

  • 一定時間アイドル状態になったら低頻度のハートビートを開始する

  • ネットワーク切替直後は一時的に検査頻度を上げる

  • 複数回失敗した後に接続切断と判定する

第19段階：ネットワーク切替とセッション再開

スマートフォンがWi-Fiから5Gへ切り替わると、従来の接続は通常失効します。

完全な処理は次のようになります。

ネットワーク変更を検出
        ↓
無効なチャネルへの新規データ送信を一時停止
        ↓
新しいローカルIPとルートを取得
        ↓
元のノードへ再接続
        ↓
セッション再開資格情報を提出
        ↓
サーバーが以前のSessionを検証
        ↓
再開可能な論理フローを復元
        ↓
再開できないTCP接続はアプリケーションへ再確立を通知

注意が必要です。

すべてのアプリケーションのTCP接続をシームレスに再開できるわけではありません。

プロトコルが再開できるもの：

  • セッション

  • ノード認可

  • プロトコルパラメーター

  • 状態が残っている一部のStream

ただし対象サイト自体のTCP接続が切れていれば、アプリケーションによる再接続が必要になる場合があります。

そのため、私たちは次のようにはうたいません。

ネットワーク切替時も、すべてのアプリケーションが常に完全に無影響である。

より正確な説明は次のとおりです。

SingLink 2.0は再接続時間を短縮し、プロトコルとルーティング状態を復元して、アプリケーションへの影響を可能な限り抑えます。

第20段階：ノード障害と自動切替

ノードの異常は次の2種類に分けられます。

ソフト障害

  • 遅延の増加

  • ときどき発生するパケット損失

  • 一時的な無応答

  • 一部の宛先が利用不能

処理方法：

  • 一時的に待機する

  • 伝送負荷を下げる

  • 再測定する

  • 同じノードへの再接続を試す

ハード障害

  • ノードへまったく接続できない

  • 認証インターフェースが利用できない

  • タイムアウトが継続する

  • ノードが停止されている

処理方法：

  1. 元のノードの使用を停止する

  2. 利用可能リストから代替ノードを選ぶ

  3. 新しい安全なセッションを確立する

  4. DNSとルートを復元する

  5. 必要な接続を再確立するようアプリケーションへ通知する

正式版2.0ではより慎重な切替方針を採用し、一時的な揺らぎで頻繁にノードを移動することを避けられます。

Betaではより積極的な再接続や高速ノード選択を行えますが、その結果として変動が大きくなる可能性があります。

第21段階：返却データとデカプセル化

対象サイトからの返却フローは次のとおりです。

対象サイトがデータを返却
        ↓
SingLinkノードが受信
        ↓
対応するSessionとStreamを特定
        ↓
SingLinkデータフレームへカプセル化
        ↓
暗号化してクライアントへ送信
        ↓
クライアントが完全性を検証
        ↓
復号
        ↓
Stream IDに従って振り分け
        ↓
TUNまたはシステムプロキシへ書き込み
        ↓
元のアプリケーションへ返却

クライアントは次を確認する必要があります。

  • データが改変されていないか

  • シーケンス番号が正しいか

  • 重複フレームではないか

  • Streamがまだ存在するか

  • 長さが制限内か

  • 受信ウィンドウを超えていないか

不正なデータをそのままアプリケーションへ渡してはいけません。

第22段階：正常切断と安全なクリーンアップ

ユーザーが切断を押した後、クライアントは次を行います。

  1. 新しいプロキシトラフィックの受信を停止する

  2. アクティブなStreamを正常に閉じる

  3. ノードへセッション終了を送信する

  4. セッション鍵を消去する

  5. 短期Tokenを失効または破棄する

  6. TUNを閉じる

  7. システムルートを復元する

  8. DNSを復元する

  9. 不要な一時設定を消去する

クライアントが突然クラッシュした場合も、OSまたは次回起動時に修復を行い、次が残らないようにする必要があります。

  • 無効なシステムプロキシ

  • 誤ったDNS

  • 残存ルート

  • インターネットへ接続できない状態

次の表は、SingLink BetaとSingLink 2.0の技術的な位置付けをまとめたものです。

処理項目

SingLink Beta

SingLink 2.0

中心的な方向性

ピーク速度

速度、安定性、互換性

接続パラメーター

より積極的

適応型かつ比較的慎重

同時実行方針

高い同時実行数を使用可能

単一トラフィックによるチャネル占有を回避

伝送ウィンドウ

高速スループットを重視

遅延と損失に応じて動的調整

ノード切替

高速ノードをより早く試行

障害を確認してから切替

多重化

再利用効率の向上を重視

再利用と障害分離の均衡

Padding

オーバーヘッド削減を優先

環境に応じて適応

ネットワーク切替

基本的な復旧

より完全な復旧と互換性

プラットフォーム回帰試験

プレビュー範囲

正式な包括試験

内部安定率

約97%

99.5%

速度

適切な環境では1 Gbps超に到達可能

高速を維持しつつピークだけを追求しない

処理原理を一文で説明

SingLinkでは、まずクライアントが端末のトラフィックを引き受け、DNS、スマートルーティング、ノード選択を完了します。続いてアカウントとノードの権限を検証し、ノードとの間でプロトコル機能を交渉して一時暗号鍵を確立します。接続確立後、各アプリケーションのTCPおよびUDPトラフィックは独立したプロキシ接続または論理Streamへカプセル化され、保護されたチャネルを通じてノードへ送られ、ノードが対象サイトへアクセスします。伝送中は、システムがフローウィンドウ、データ完全性、遅延、パケット損失、ハートビート、ノード状態を継続的に管理します。ネットワーク切替やノード障害時には、セッションを再確立し、ルートを復元するか、利用可能なノードへ切り替えます。

Betaと2.0の本質的な違いは次のとおりです。

SingLink Betaはピーク速度をより積極的に追求します。SingLink 2.0は高速伝送に加え、より包括的な互換性、ヘルスチェック、異常判定、セッション再開、クロスプラットフォーム処理を備えるため、安定率が高くなります。

よくある質問

SingLink 2.0はSingLinkVPNが独自開発した正式なネットワーク伝送プロトコルで、本人確認、暗号化セッション、トラフィックのカプセル化、TCPおよびUDP伝送、ヘルスチェック、異常からの復旧を担います。

いいえ。SingLink 2.0はプロトコルの正式名称です。Windows、macOS、Android、iOSクライアントのバージョンとは別のバージョン体系です。

Betaは速度優先のプレビュープロトコルであり、適切な条件ではピーク速度が1 Gbpsを超える場合があります。2.0は速度、安定性、クロスプラットフォーム互換性、切断からの復旧を重視する正式プロトコルです。

SingLinkVPNが指定する試験環境での内部A/Bテストでは、SingLink 2.0の安定率は99.5%、Betaの最高値は約97%でした。

SingLinkはネットワークトラフィックをどのように処理しますか

クライアントが最初にシステムトラフィックを引き受け、DNSとスマートルーティングを完了します。その後、アカウントとノードの権限を検証し、暗号化セッションを確立して、TCPまたはUDPデータをカプセル化しノードへ送ります。

SingLinkは切断をどのように処理しますか

システムは遅延、パケット損失、ハートビート、ノード状態を継続的に検査します。異常時にはセッションを再確立し、ルートを復元するか、利用可能なノードへ切り替えます。

SingLinkとVLESSの違いは何ですか

VLESSの中心は主にID、命令、宛先への転送です。SingLinkはID、ルーティング、ノード権限、伝送方針、ヘルスチェック、異常からの復旧をプロトコル体系として統合します。

SingLinkとAnyTLSの違いは何ですか

AnyTLSは主にTLS接続でSessionと複数のStreamを伝送します。SingLinkはさらにスマートルーティング、会員権限、ノードスケジューリング、接続再開まで含む、より広い位置付けです。SessionとStreamの具体的な実装は正式な技術文書に従います。

SingLink 2.0正式プロトコルのノードは、Pro、Max、Richの会員が利用できます。Betaプロトコルは無料プランを含むすべてのプランで利用できます。実際の権限は最新クライアントの表示に従います。

現在、コアプロトコルのソースコードはまだ全面公開されていません。一方、技術文書、試験方法、データ形式、検証ツール、脆弱性開示の仕組みは継続的なオープンソース計画に含まれています。

関連資料と参考記事

本記事の製品上の位置付けと公開範囲は、SingLinkVPN公式技術センター、SingLinkLabs公開研究リポジトリ、および同リポジトリの性能試験方法も参照しています。

関連コンテンツとして、SingLinkVPN無料プラン完全ガイド、SingLinkVPNオープンソース計画、2026年SingLinkVPNセキュリティ監査報告書もご覧ください。

技術上の注意：本記事の99.5%、97%、1 Gbps超という数値は、それぞれ指定環境での内部A/Bテストとピーク試験の結果です。すべての地域、端末、通信事業者、時間帯で同じ結果が得られることを保証するものではありません。具体的な暗号アルゴリズム、パケット形式、SessionおよびStreamの仕組みについては、SingLinkが今後公開する正式な技術文書とソースコードを基準とします。