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
コントロールプレーンとデータプレーンの分離
コントロール プレーンは、権限、構成、ノードのスケジューリングを担当します。データ プレーンは、実際にユーザー トラフィックを伝送するチャネルを担当します。この 2 つを分離すると、機密データの範囲を制限し、障害を切り分けることができます。
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
セッションの作成
参照実装モデルセッションは、クライアントとノード間の送信セッションを表し、接続ステータス、機能情報、ハートビート、および 1 つ以上の論理フローを伝送できます。
- 11
ストリームまたは独立したプロキシ接続を確立する
参照実装モデル各アプリケーション要求はセッション内の論理ストリームにマッピングすることも、独立した接続を確立することもできます。最後のメソッドはパブリック実装に依存します。
- 12
データフレームのカプセル化
参照実装モデル解析可能なフレームを形成するには、宛先情報、ストリーム識別、ペイロード長、制御コマンド、およびデータが必要です。このページは文書化されていないバイナリ フィールドを作成するものではありません。
- 13
TCPトラフィック処理
パブリックデザインの説明TCP バイト ストリームは、順序を維持し、ハーフ クローズと異常クローズを処理し、アプリケーション側のバックプレッシャーをトランスポート側に渡す必要があります。
- 14
UDPおよびQUICトラフィック処理
パブリックデザインの説明UDP データグラムはメッセージ境界を保持し、セッション タイムアウトを管理する必要があります。 QUIC などの UDP タイプのサービスも、不要な行頭ブロックを回避する必要があります。
- 15
フロー制御とバックプレッシャー
参照実装モデルクライアント、ノード、またはターゲット サービスの消費速度が遅くなった場合、単一のストリームによってセッション全体がダウンするのを防ぐために、バッファの増加を制限する必要があります。
- 16
サブパッケージ化、パディングおよびトラフィックの外観
参照実装モデルパケット化とパディングは送信戦略の一部としてのみ使用でき、絶対的なステルスとは言えません。その有効条件とオーバーヘッドにはテストと検証が必要です。
- 17
MTU とパケット サイズの処理
パブリックデザインの説明トンネルのオーバーヘッドにより利用可能な MTU が減少するため、断片化の回避、MSS 調整、または同等のメカニズムを通じて大規模なパケット障害を軽減する必要があります。
- 18
遅延、パケット損失、輻輳の処理
参照実装モデルプロトコルは、ネットワーク フィードバックに基づいて送信リズムと再送信を制御し、実際のパケット損失、キュー遅延、および短期的なネットワーク ジッターを区別する必要があります。
- 19
心拍と健康状態の検出
確認済みの機能セッションとノードのステータスを継続的に監視して、オペレーティング システムの長いタイムアウトのみに依存して切断された接続を検出することを回避します。
- 20
ネットワークの切り替えとセッションの回復
確認済みの機能Wi-Fi ネットワークとモバイル ネットワークを切り替えた後、クライアントはネットワーク エントランス、DNS、ルーティング、および送信セッションを再確認し、その機能に従って接続を再開します。
- 21
ノード障害と自動切り替え
確認済みの機能ソフト障害の場合は、最初にセッションを再構築でき、ハード障害の場合は、使用可能なノードを切り替えることができます。切り替えプロセス中は、システム ルーティングを復元し、予期しない直接接続によるトラフィックを回避する必要があります。
- 22
データの返却、カプセル化解除、セキュリティのクリーンアップ
パブリックデザインの説明クライアントは返されたデータを検証してカプセル化を解除し、接続の完了後に一時的なセッション ステータス、キャッシュ キー、ルーティング、および DNS の変更をクリアします。
Traffic entry and routing
トラフィック テイクオーバー、DNS、インテリジェント オフロード
DNS リーク、エラー終了、予期しない直接接続を避けるために、システム ネットワーク エントリ、ドメイン名解決、およびルーティング判断は同じコンテキストを共有する必要があります。
デスクトップ システムは TUN モードまたはシステム プロキシを使用できます。モバイル プラットフォームと TV プラットフォームは、それぞれのネットワーク拡張機能を使用します。プラットフォームが異なれば 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% |
| スピード重視 | 速度、安定性、互換性のバランス | 適切な条件下ではピーク値が1Gbpsを超える |
| プロトコルノードの権限 | プロ、マックス、リッチ | すべてのパッケージ |
| 戦略を変える | 長期的な互換性と回復に重点を置く | 新しい機能とパフォーマンスの検証に使用されます |
External protocols
VLESSおよびAnyTLSとの境界比較
比較の基準となるのは、各プロジェクトの公式公開文書です。ここでは、ポジショニング、システム境界、開示能力を比較し、基礎となるプロトコルの結論にマーケティング数値を混入しません。
| 寸法 | SingLink ホワイトペーパーの範囲 | VLESSパブリックスコープ | AnyTLS パブリック スコープ |
|---|---|---|---|
| パブリックポジショニング | 製品コントロールプレーンと伝送データプレーンのシステム全体 | ステートレスで軽量なクライアントおよびサーバーのトランスポート プロトコル | TLS ベースのプロキシ プロトコルとリファレンス実装 |
| アイデンティティと目的 | アカウント、ノード権限、セッションおよびルーティングのコラボレーション | UUID、コマンド、ポート、ターゲットアドレス | TLS 事後認証、その後セッションを確立 |
| Session/Stream | 参考モデルの説明、正確なフォーマットは未公開 | Mux をサポートします。詳細は実装と構成によって決まります | セッションフレーム、ストリーム多重化、およびコマンドを公開する |
| 交通の様子 | 送信戦略は検証されるべきですが、絶対的な不可視性を主張するものではありません | 公式文書にはオプションのフローやその他のメカニズムが記載されています | 下請け、水増し計画、更新メカニズムの開示 |
| 回復力 | 健全性の検出、ネットワークの切断、セッションの再構築、ノードの切り替え | X線の生態と特定の透過の組み合わせを担当 | プロトコル v2 は SYNACK、ハートビート、サーバー ネゴシエーションを公開します |
| 製品システム | DNS、インテリジェントオフロード、パッケージ権限、ノードスケジューリング | 完全な VPN 製品のコントロール サーフェスと同等ではありません | 完全な VPN 製品のコントロール サーフェスと同等ではありません |
この表は、コードの互換性、パフォーマンスのランキング、またはセキュリティ監査の結論を表すものではありません。
Platforms and openness
クロスプラットフォームの互換性とオープンソースの境界
プラットフォームの一貫性
SingLinkVPN は、iOS、Android、Windows、macOS、Linux、および TV デバイスをカバーします。クロスプラットフォームの一貫性とは、各プラットフォームがまったく同じシステム API を使用することを意味するのではなく、同じ権限セット、ルーティング、ノードおよびプロトコル選択ロジックを維持し、各オペレーティング システムのネットワーク拡張制限に従うことを意味します。
公開範囲
SingLink 2.0 コア プロトコルのソース コードはまだ完全には公開されていません。公開された指示には、技術文書、アーキテクチャの説明、研究データ、再現可能なテスト方法、データ形式、検証ツール、責任ある脆弱性開示インフラストラクチャが含まれます。
Frequently asked questions
よくある質問
Q01SingLink 2.0 とは何ですか?
SingLink 2.0 は、SingLinkVPN が独自に開発した正式なネットワーク伝送プロトコル世代です。これは、ID と権限の検証、トラフィック ルーティング、送信セッション、TCP と UDP の処理、正常性の検出、および例外の回復を整理するために使用されます。
Q02クライアント ソフトウェアのバージョンは SingLink 2.0 ですか?
いいえ。SingLink 2.0 はプロトコル名とプロトコル生成です。 Windows、macOS、Android、iOS、およびその他のクライアントは、独立したソフトウェア バージョン システムを使用します。
Q03SingLink Beta と SingLink 2.0 の違いは何ですか?
ベータ版は、速度と新機能を検証するためのプレビュー プロトコルです。 SingLink 2.0 は、安定性、クロスプラットフォームの一貫性、接続の回復、長期的な互換性を重視した公式プロトコル世代です。
Q04SingLink 2.0の安定率はどれくらいですか?
指定されたテスト環境における SingLinkVPN の内部 A/B テスト記録は 99.5% で、ベータ ピークは約 97% です。これらはすべての地域および期間を保証するものではなく、実際の結果はネットワーク オペレーター、ノードの負荷、機器およびテスト方法の影響を受けます。
Q05SingLink はネットワーク トラフィックをどのように処理しますか?
クライアントは最初にシステム ネットワークの入り口を確立し、DNS とインテリジェントな分散を完了してから、ノードを選択し、権限を確認し、送信セッションを確立し、TCP または UDP データをノードに送信する前にカプセル化します。
Q06SingLink は切断やネットワークの切り替えをどのように処理しますか?
クライアントはセッションとノードのステータスを継続的に監視します。例外が発生すると、セッションが再構築され、DNS とルーティングが復元されるか、機能に基づいて他の利用可能なノードに切り替えられます。
Q07SingLink と VLESS の違いは何ですか?
VLESS は、ステートレスで軽量なクライアントおよびサーバーの送信プロトコルとして公式に位置づけられています。 SingLink ホワイトペーパーで説明されている範囲はさらに広く、製品のコントロール プレーン、ノードのアクセス許可、インテリジェント ルーティング、正常性の検出および回復プロセスもカバーされています。この 2 つは、単一のフレーム形式に基づいて比較すべきではありません。
Q08SingLink と AnyTLS の違いは何ですか?
AnyTLS 公開仕様は、TLS 上の認証、セッション、ストリームの再利用、パディング、ハートビートの記述に重点を置いています。 SingLink のホワイト ペーパーでは、クライアント トラフィック エントリ、DNS、ルーティング、パッケージのアクセス許可、ノードのスケジューリングについても説明しているため、比較は基礎となる実装が同じであると主張するのではなく、システムの境界に基づいています。
Q09SingLink 2.0 を使用できるのは誰ですか?
現在、SingLink 2.0 プロトコル ノードは主に Pro、Max、および Rich パッケージに対応しています。 SingLink Beta プロトコル ノードはすべてのパッケージに対してオープンです。実際に利用可能なノードは、クライアント上でリアルタイムに表示されます。
Q10SingLink 2.0 は完全にオープンソースですか?
現時点では、コアプロトコルのソースコードは完全には公開されていません。技術文書、研究データ、テスト方法、データ形式、検証ツール、脆弱性開示メカニズムが継続的なオープンソース計画に含まれています。開示範囲は、SingLinkLabs のウェアハウスおよび公式発表の対象となります。
References and revision
データ、内部リンク、変更記録
Next step
SingLink 2.0 プロトコルを体験する
SingLink 2.0 ノードは主に Pro、Max、および Rich パッケージに対応しています。ノードの数とプロトコルの可用性は、クライアント上でリアルタイムに表示されます。