SingLinkLabs · Protocol Paper 01

SingLinkプロトコル技術ホワイトペーパー

SingLink 2.0 アーキテクチャ、完全な接続ライフサイクルとプロトコル境界

SingLink 2.0 は、SingLinkVPN が独自に開発した正式なネットワーク伝送プロトコルであり、クライアント ソフトウェアのバージョンではありません。この記事では、コントロール プレーン、データ プレーン、および完全な接続ライフ サイクルを主軸として、プロトコルのパブリック機能、リファレンス実装モデル、テスト データの境界、および外部プロトコルの違いを説明します。

Document
SLP-WP-01
Revision
1.0
Published
2026-07-29
Language
日本語

プロトコルの世代とクライアントのバージョンは独立して管理されます。ノードの可用性は、クライアントのリアルタイムのステータスに依存します。

ホワイトペーパー更新フィードを購読
Chapter 01

Scope and evidence

範囲、結論、証拠の境界

これはマーケティング ページではなく、構成の取得から接続のクリーンアップまでのシステムの説明です。各項目は、確認済みの機能、公開設計の説明、および参照実装モデルを区別します。

SingLink 2.0 は、SingLinkVPN が独自に開発した公式ネットワーク伝送プロトコル世代です。 「2.0」は、Windows、macOS、Android、iOS、またはその他のクライアントのソフトウェアのバージョン番号ではなく、プロトコル名とプロトコルの世代を表します。

プロトコルの製品境界は、クライアントからサーバーへのバイト形式だけではなく、アカウントとノードの権限、DNS 処理、インテリジェントなオフロード、ノードの選択、セッションの健全性検出、ネットワークの切り替え、障害回復も含まれます。

確認済みの機能

製品ページから、クライアントの機能と公式の公開能力について説明します。

パブリックデザインの説明

プロトコルが解決する必要がある問題と、現在公開されているシステム境界について説明します。

参照実装モデル

可能な実装を説明するために使用され、公開されたバイナリ仕様と同等ではありません。

Chapter 02

Versioning

プロトコルの世代はソフトウェアのバージョンではありません

Protocol

SingLink 2.0

トランスポート プロトコルの世代、機能ネゴシエーション、セッション モデル、および互換性ポリシーの全体的な進化を表します。

Client software

各プラットフォームには独自の番号があります

Windows、macOS、Android、iOS、Linux、および TV クライアントは、それぞれのリリース リズムに従って管理され、プロトコル 2.0 と混在することはありません。

Chapter 03

System architecture

コントロールプレーンとデータプレーンの分離

コントロール プレーンは、権限、構成、ノードのスケジューリングを担当します。データ プレーンは、実際にユーザー トラフィックを伝送するチャネルを担当します。この 2 つを分離すると、機密データの範囲を制限し、障害を切り分けることができます。

Control plane

コントロールサーフェス

  • 01 アカウントとパッケージの権限
  • 02 ノードとプロトコルの機能リスト
  • 03 短期的な構成、戦略、および取り消し
  • 04 ノードの健全性とスケジュール情報

Data plane

データプレーン

  • 01 トラフィックの引き継ぎと転送
  • 02 TCP、UDP、および論理フローベアラー
  • 03 セッションステータスとヘルス検出
  • 04 リターンデータのカプセル化解除
アカウントと設定
システムネットワーク入口
DNSとオフロード
ノードとセッション
TCP/UDP送信
返却と片付け
Chapter 04

Connection lifecycle

22 の処理ステージ

アカウントのアクセス許可、システム ネットワークの入り口からリターン データのカプセル化解除、セキュリティ クリーンアップに至るまで、次のプロセスでは完全な技術的リンクが保持され、各ステップの証拠ステータスがマークされます。

  1. 01

    アカウントのログインと権限の確認

    確認済みの機能

    クライアントは、現在のアカウントの使用可能なパッケージ、ノード、およびプロトコル権限を取得します。認証資格情報は有効期間が短く、取り消し可能であり、その後のデータ転送ステータスから切り離されている必要があります。

  2. 02

    ノードおよびプロトコル構成の配信

    パブリックデザインの説明

    コントロール プレーンは、ノード アドレス、ポート、利用可能なプロトコル、および必要なポリシーを返します。長期マスター キーや不要な機密フィールドをクライアントに直接配信すべきではありません。

  3. 03

    システムネットワーク入口の確立

    確認済みの機能

    クライアントは、TUN モード、システム プロキシ、またはプラットフォーム ネットワーク拡張を通じて処理する必要があるトラフィックを受信します。具体的な入り口はオペレーティング システムの機能によって異なります。

  4. 04

    DNS解決とドメイン名の決定

    確認済みの機能

    DNS が依然としてローカル ネットワークから漏洩したり、誤った転送を引き起こしたりしている間にドメイン名がプロキシを経由するのを避けるために、DNS 要求とその後の接続には一貫したポリシーを使用する必要があります。

  5. 05

    インテリジェントなトラフィック分散とルーティング判断

    確認済みの機能

    ルール、アプリケーション、ターゲット ドメイン名、IP、およびネットワーク ステータスに基づいて、接続を直接、プロキシ、またはブロックとして決定します。

  6. 06

    ノードの選択

    確認済みの機能

    手動モードでは、ユーザー指定のノードが使用されます。インテリジェント モードでは、遅延、可用性、負荷、リージョン、およびパッケージの権限に基づいて候補ノードを選択できます。

  7. 07

    プロトコル機能のネゴシエーション

    パブリックデザインの説明

    クライアントとサーバーは、双方がサポートするプロトコルの世代と機能を確認します。古いクライアントは、新しい機能を認識できない場合に、互換性のない動作を黙って有効にしてはいけません。

  8. 08

    認証とリプレイ防止

    参照実装モデル

    ノードはアカウントまたはセッションが有効であることを検証し、エージング、ランダム化、または同等のメカニズムによって古い認証データが再利用されるのを防ぐ必要があります。

  9. 09

    鍵交換鍵とセッション鍵

    参照実装モデル

    このプロトコルでは、現在の接続に対して別の暗号化コンテキストを確立する必要があります。特定の暗号スイート、ハンドシェイク フィールド、およびローテーション期間は、将来の公開仕様に従う必要があります。

  10. 10

    セッションの作成

    参照実装モデル

    セッションは、クライアントとノード間の送信セッションを表し、接続ステータス、機能情報、ハートビート、および 1 つ以上の論理フローを伝送できます。

  11. 11

    ストリームまたは独立したプロキシ接続を確立する

    参照実装モデル

    各アプリケーション要求はセッション内の論理ストリームにマッピングすることも、独立した接続を確立することもできます。最後のメソッドはパブリック実装に依存します。

  12. 12

    データフレームのカプセル化

    参照実装モデル

    解析可能なフレームを形成するには、宛先情報、ストリーム識別、ペイロード長、制御コマンド、およびデータが必要です。このページは文書化されていないバイナリ フィールドを作成するものではありません。

  13. 13

    TCPトラフィック処理

    パブリックデザインの説明

    TCP バイト ストリームは、順序を維持し、ハーフ クローズと異常クローズを処理し、アプリケーション側のバックプレッシャーをトランスポート側に渡す必要があります。

  14. 14

    UDPおよびQUICトラフィック処理

    パブリックデザインの説明

    UDP データグラムはメッセージ境界を保持し、セッション タイムアウトを管理する必要があります。 QUIC などの UDP タイプのサービスも、不要な行頭ブロックを回避する必要があります。

  15. 15

    フロー制御とバックプレッシャー

    参照実装モデル

    クライアント、ノード、またはターゲット サービスの消費速度が遅くなった場合、単一のストリームによってセッション全体がダウンするのを防ぐために、バッファの増加を制限する必要があります。

  16. 16

    サブパッケージ化、パディングおよびトラフィックの外観

    参照実装モデル

    パケット化とパディングは送信戦略の一部としてのみ使用でき、絶対的なステルスとは言えません。その有効条件とオーバーヘッドにはテストと検証が必要です。

  17. 17

    MTU とパケット サイズの処理

    パブリックデザインの説明

    トンネルのオーバーヘッドにより利用可能な MTU が減少するため、断片化の回避、MSS 調整、または同等のメカニズムを通じて大規模なパケット障害を軽減する必要があります。

  18. 18

    遅延、パケット損失、輻輳の処理

    参照実装モデル

    プロトコルは、ネットワーク フィードバックに基づいて送信リズムと再送信を制御し、実際のパケット損失、キュー遅延、および短期的なネットワーク ジッターを区別する必要があります。

  19. 19

    心拍と健康状態の検出

    確認済みの機能

    セッションとノードのステータスを継続的に監視して、オペレーティング システムの長いタイムアウトのみに依存して切断された接続を検出することを回避します。

  20. 20

    ネットワークの切り替えとセッションの回復

    確認済みの機能

    Wi-Fi ネットワークとモバイル ネットワークを切り替えた後、クライアントはネットワーク エントランス、DNS、ルーティング、および送信セッションを再確認し、その機能に従って接続を再開します。

  21. 21

    ノード障害と自動切り替え

    確認済みの機能

    ソフト障害の場合は、最初にセッションを再構築でき、ハード障害の場合は、使用可能なノードを切り替えることができます。切り替えプロセス中は、システム ルーティングを復元し、予期しない直接接続によるトラフィックを回避する必要があります。

  22. 22

    データの返却、カプセル化解除、セキュリティのクリーンアップ

    パブリックデザインの説明

    クライアントは返されたデータを検証してカプセル化を解除し、接続の完了後に一時的なセッション ステータス、キャッシュ キー、ルーティング、および DNS の変更をクリアします。

Chapter 05

Traffic entry and routing

トラフィック テイクオーバー、DNS、インテリジェント オフロード

DNS リーク、エラー終了、予期しない直接接続を避けるために、システム ネットワーク エントリ、ドメイン名解決、およびルーティング判断は同じコンテキストを共有する必要があります。

デスクトップ システムは TUN モードまたはシステム プロキシを使用できます。モバイル プラットフォームと TV プラットフォームは、それぞれのネットワーク拡張機能を使用します。プラットフォームが異なれば API も異なりますが、ポリシーの目標は同じです。プロキシを必要とするトラフィックはトンネルに入り、プロキシを必要としないトラフィックはルールに従って直接接続されます。

アプリケーション トラフィックのみをプロキシし、DNS がローカル ネットワークを通過し続けることを許可すると、ドメイン名が公開されたり、現在の出口に適さない解決結果が得られたりする可能性があります。したがって、ドメイン名の照合、DNS クエリ、IP キャッシュ、および接続の確立では、同じルーティング コンテキストを使用する必要があります。

DIRECT

直結

プロキシを明示的に必要としないローカル サービスまたはターゲットは、ローカル ネットワークを使用します。

TUNNEL

エージェント

権限の検証後、選択した SingLink ノードを介して接続が確立されます。

BLOCK

ブロック

セキュリティルールにヒットした場合、または許可のないターゲットにヒットした場合に接続を拒否します。

Chapter 06

Authentication

認証と暗号化されたセッション

許可の確認の応答は「このアカウントはこのノードとプロトコルを使用できますか?」送信認証は、「現在の接続が有効なクライアントからのものであるかどうか」に答えます。どちらも、有効期間が短く、取り消し可能なセッション状態を使用し、古い認証情報が再生されないようにする必要があります。

クライアントとノードは、双方がサポートするプロトコルの世代と機能を確認する必要もあります。新しい機能を認識しない側は、安全にダウングレードするか接続を拒否する必要があり、確認なしに互換性のない動作を有効にすることはできません。

Disclosure boundary

未公開の暗号の詳細

既存の情報では、特定のハンドシェイク フィールド、暗号スイート、キー導出関数、ローテーション期間、バイナリ パケット フォーマットを特定するには不十分です。この記事ではセキュリティ目標についてのみ説明しており、AES、TLS バージョン、特定の曲線、または固定フィールド長などを既成事実として記述することはありません。

Chapter 07

Session model

セッション、ストリーム、データフレーム

階層型セッション モデルを使用して、アプリケーション接続、論理フロー、およびノード トランスポート コンテキストの間の関係を説明しながら、非公開の形式の境界を明確にします。

Session

クライアントとノード間のトランスポート コンテキストは、認証結果、機能、ハートビート、および接続レベルのフロー制御を伝送できます。

Stream

ロジック アプリ接続。複数のストリームがセッションを共有するかどうかは、最終的なパブリック実装とプラットフォーム ポリシーによって異なります。

アプリケーション接続
論理ストリーム
転送セッション
SingLink ノード

データ フレームは、少なくとも制御コマンド、ロジック フロー、負荷境界、エラー ステータスを表現する必要があります。正式な形式が公開されるまで、このページでは未検証のフィールド テーブルを提供しません。

Chapter 08

Transport

TCP、UDP、QUIC

TCP

順序付けられたバイトストリーム

バイト順序を維持し、ハーフクローズ、異常クローズ、バックプレッシャーおよびターゲット接続エラーを処理し、低速接続によってセッションバッファがいっぱいになるのを防ぎます。

UDP

データグラム境界

データグラム境界を保持し、ターゲットとタイムアウトのステータスを維持します。 UDP-over-TCP を使用する場合は、行頭ブロッキングとパケット損失の増幅を評価する必要があります。

QUIC

UDP 経由の信頼性の高いトランスポート

追加の信頼性レイヤーによって引き起こされる繰り返しの回復を避けるために、QUIC 自体の輻輳と再送信の利点を維持するようにしてください。

Chapter 09

Reliability

フロー制御、MTU、ハートビート、リカバリ

安定した接続は、自動再接続ボタンではなく、バッファリング、パケット パッケージング、健全性検出、ルート回復、ノード切り替えで構成されるステート マシンです。

01

フロー制御

単一ストリームでセッション全体がブロックされないように、消費速度に応じて送信ウィンドウを調整します。

02

MTUの処理

断片化やブラック ホールのリスクを軽減するために、トンネルの追加オーバーヘッドを考慮してください。

03

健康診断

ハートビート、遅延、パケット損失、実際の転送ステータスに基づいて接続を決定します。

04

ネットワークの回復

ネットワークが切断された後、トラフィックが誤って直接接続されるのを防ぐために、ポータル、DNS、ルーティング、およびセッションが再構築されます。

Chapter 10

Product comparison

SingLink 2.0 とベータ版

インジケーターSingLink 2.0SingLink Beta
位置決め世代間の正式な合意速度優先のプレビュー プロトコル
内部 A/B テスト安定率99.5%最大約97%
スピード重視速度、安定性、互換性のバランス適切な条件下ではピーク値が1Gbpsを超える
プロトコルノードの権限プロ、マックス、リッチすべてのパッケージ
戦略を変える長期的な互換性と回復に重点を置く新しい機能とパフォーマンスの検証に使用されます
Chapter 11

External protocols

VLESSおよびAnyTLSとの境界比較

比較の基準となるのは、各プロジェクトの公式公開文書です。ここでは、ポジショニング、システム境界、開示能力を比較し、基礎となるプロトコルの結論にマーケティング数値を混入しません。

寸法SingLink ホワイトペーパーの範囲VLESSパブリックスコープAnyTLS パブリック スコープ
パブリックポジショニング製品コントロールプレーンと伝送データプレーンのシステム全体ステートレスで軽量なクライアントおよびサーバーのトランスポート プロトコルTLS ベースのプロキシ プロトコルとリファレンス実装
アイデンティティと目的アカウント、ノード権限、セッションおよびルーティングのコラボレーションUUID、コマンド、ポート、ターゲットアドレスTLS 事後認証、その後セッションを確立
Session/Stream参考モデルの説明、正確なフォーマットは未公開Mux をサポートします。詳細は実装と構成によって決まりますセッションフレーム、ストリーム多重化、およびコマンドを公開する
交通の様子送信戦略は検証されるべきですが、絶対的な不可視性を主張するものではありません公式文書にはオプションのフローやその他のメカニズムが記載されています下請け、水増し計画、更新メカニズムの開示
回復力健全性の検出、ネットワークの切断、セッションの再構築、ノードの切り替えX線の生態と特定の透過の組み合わせを担当プロトコル v2 は SYNACK、ハートビート、サーバー ネゴシエーションを公開します
製品システムDNS、インテリジェントオフロード、パッケージ権限、ノードスケジューリング完全な VPN 製品のコントロール サーフェスと同等ではありません完全な VPN 製品のコントロール サーフェスと同等ではありません

この表は、コードの互換性、パフォーマンスのランキング、またはセキュリティ監査の結論を表すものではありません。

Chapter 12

Platforms and openness

クロスプラットフォームの互換性とオープンソースの境界

プラットフォームの一貫性

SingLinkVPN は、iOS、Android、Windows、macOS、Linux、および TV デバイスをカバーします。クロスプラットフォームの一貫性とは、各プラットフォームがまったく同じシステム API を使用することを意味するのではなく、同じ権限セット、ルーティング、ノードおよびプロトコル選択ロジックを維持し、各オペレーティング システムのネットワーク拡張制限に従うことを意味します。

公開範囲

SingLink 2.0 コア プロトコルのソース コードはまだ完全には公開されていません。公開された指示には、技術文書、アーキテクチャの説明、研究データ、再現可能なテスト方法、データ形式、検証ツール、責任ある脆弱性開示インフラストラクチャが含まれます。

Chapter 13

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 のウェアハウスおよび公式発表の対象となります。

Chapter 14

References and revision

データ、内部リンク、変更記録

バージョン 1.0 · 2026 年 7 月 29 日:簡体字中国語の最初のバージョンがリリースされました。このバージョンでは、完全な接続ライフ サイクル、証拠ステータス、ベータ データ境界、VLESS と AnyTLS パブリック データの比較が整理され、TechArticle、FAQ、Canonical、Feed、およびサイト マップ検出メカニズムが追加されました。

Next step

SingLink 2.0 プロトコルを体験する

SingLink 2.0 ノードは主に Pro、Max、および Rich パッケージに対応しています。ノードの数とプロトコルの可用性は、クライアント上でリアルタイムに表示されます。