P2P開発のすべての痛み

こんにちは、habrasociety！ 今日は、リモートアシスタントであるTensorの魔法のような素晴らしいプロジェクトについてお話ししたいと思います。 これは、一般的なVLSIクライアントベースのフレームワーク内で数百万の顧客とオペレーターを接続するリモートアクセスシステムです。 リモートアシスタンスは、現在online.sbis.ruと密接に統合されています。 毎日1万件以上の接続と1日あたり数十時間のセッションを登録していますこの記事では、p2p接続を確立する方法と、これが失敗した場合の対処方法について説明します。

経験は難しい間違いの息子です

多くのリモートアクセスシステムがあります。 これらは、無料のVNCのあらゆる種類のバリエーションであり、非常に強力であり、幅広い機能を備えたソリューションを提供します。最初は、このようなソリューションの1つであるUltraVNCを採用しました。 これは、IPを知っている別のPCに接続できる優れた無料システムです。 PCがインターネットネットワークに間接的にアクセスしている場合の対処方法のオプションは、Habrのオープンスペースで既にちらついています。このトピックについては触れません。 このソリューションは、比較的少数の同時接続が達成されるまで十分です。 左へのステップ、右へのステップ、およびスマットは、スケーリング、ユーザビリティ、システムへの統合、および改善の複雑さから始まります。もちろん、これらはソフトウェアライフサイクル中に発生します。



そのため、自転車を発明して独自のリモートデスクトップ管理システムを作成し、VLSIエコシステム全体に統合することができました。 もちろん、怠zyなPCだけを使用しない2台のPCを接続する最も簡単な方法は、数値識別子を使用することです。 実装では、特定のクライアントを参照せずに6桁のランダムな数字を使用します。



ある有名な人はかつて言った：

理論は、すべてが知られているが、何も機能しないときです。

練習はすべてがうまくいくときですが、その理由は誰にもわかりません。

理論と実践を組み合わせます：何も機能しません...

誰もその理由を知りません！

私たちの旅の最初に、この引用は真実に非常に似ていました。クライアントとオペレーターをお互いに「紹介」する方法についての理解がありました。 しかし実際には、すべてが完全に些細なものではないことが判明しました。

P2Pの概要

2つのデバイスを接続するために、シグナルサーバーを使用します。これは、両方の当事者が利用できる仲介サーバーです。 その役割は、参加者間でリアルタイムに情報を登録および交換することです。 それを介して、面倒なことなく、接続を確立するためにエンドポイント（IPアドレスとポートの束、アクセスポイント）を交換します。







リモートヘルパーマネージャー（RHM）と呼ばれるこのシグナルサーバーは、nodejsで記述されたシステムのプールであり、サービス全体のフォールトトレラントな操作を提供します。 Nuuu、より正確には、「フォールトトレラント」として...私たちはそう願っています:)。 いずれかのサーバーへの接続は、ラウンドロビン方式に基づいています。 したがって、クライアントとオペレーターは異なるサーバーに接続でき、同期と調整のためのすべてのメカニズムはデスクトップアプリケーションから完全に削除されます。



すべての作業はサービスパッケージの交換に削減されます。これにより、たとえば、接続の候補を収集するプロセスを開始したり、接続試行自体を開始したりするために、当事者が互いに一意に識別し、アクションを比較的同期的に実行できます。



ところで、私たちのように振る舞わないでください-足元で自分を撃たないでください：443 TCPポートを使用する場合-純粋なトラフィックではなくTLSを使用してください。 さらに多くのファイアウォールがそれをブロックし、さらに多くの場合プロバイダー側​​で切断します。




インターネットで最も一般的な通信プロトコルはUDPとTCPです。 UDPは迅速かつ簡単ですが、パケットの配信と順序を保証するネイティブ機能がありません。 TCPにはこれらの欠点はありませんが、p2p接続のセットアップ中は少し複雑です。 そして、最新のトレンドでは、直接のTCP接続は完全に忘却に沈むことができるように思えます。



p2p接続のセットアップは、常にネットワークプロトコルを操作する能力に大きく依存しているわけではありません。 ほとんどの場合、この機能は特定のネットワーク設定、より多くの場合、NAT（ネットワークアドレス変換）やファイアウォール設定などに依存します。



NATを4つのタイプに分割するのが通例です。それぞれのタイプは、外部ネットワークからエンドユーザーにパケットを送信するためのルールが異なります。

• 対称NAT
• コーン/フルコーンNAT
• アドレス制限付きコーンNAT
• ポート制限コーンNAT

ちなみに、一部の高度なデバイスでは、構成パネルから直接モードを選択できますが、現在ではそうではありません。



ほとんどの場合、NATを突破して、ホストへのデータ転送を開始し、そこから応答を受信することができます。 これを行うには、リモート側がその外部エンドポイントを認識し、それを当社に通知する必要があります。 次に、同じことを行う必要があります。



外部デバイスのIPアドレスとポートを調べるには（簡単にするためにルーターと呼びましょう）、STUN（NATのセッショントラバーサルユーティリティ）およびTURN（リレーNATを使用したトラバーサル）サーバーを使用します。 STUN-外部IPを決定するため：UDPプロトコルのポート（エンドポイント）、TURN-TCPの場合。



なぜ、私たち自身のシグナルサーバーから外部IPを取得する方がはるかに簡単だろうか？



これには少なくとも4つの引数があります。

1. エンドポイントを収集するためにサーバーのリスト（独自のサーバーと公開されているサーバーの両方）を透過的に拡張する機能により、システムの復元力が向上します。
2. STUNおよびTURNプロトコルの相補性と広範な使用により、エンドポイントの収集とトラフィックの中継に最小限の注意を払うことができます。
3. STUNおよびTURNプロトコルは非常に似ています。 STUNパッケージのアーキテクチャを扱った後、TURNはすでに経験しています。 また、TURNを使用すると、直接接続の確立に失敗したときにトラフィックを中継する機会が得られます。
4. 私たちはすでにビデオコールのプロジェクトでSTUN / TURNサーバー「コターン」を使用しました。つまり、「鉄」への最小限の注入でその能力を「プラグイン」することが可能でした。

Coturnは、TURNおよびSTUNサーバーのオープンソース実装です。 実践が示しているように、その使用はWebRTCにまったく限定されません。 私の意見では、これはかなり柔軟なツールであり、それほど要求はありません。 はい、水平方向に拡張する組み込み機能はありませんが、たとえば信号サーバーを使用してすべてが解決されます。

STUN / TURNプロトコルを使用して構築されたサーバーとの通信はどのように行われますか？

エンドポイントを取得する手順は、RFC＃3489、＃5389、＃5766、および＃6062に記載されています。

STUNまたはTURNプロトコルへのすべてのメッセージは次のとおりです。







したがって：

1. メッセージタイプごとに12バイト
2. その長さ（後続のすべての属性のサイズ）が22バイト
3. TURNのランダム識別子には12バイト、STUNパケットには16バイト。 サイズは4バイト異なります-このデータは、一定のMagicCookieの下でTURNパケット用に予約されています。

一般に、オーバーヘッド情報はパケットの最初の20バイトに含まれています。

属性も次のもので構成されます。

1. 属性タイプごとに2バイト
2. 長さ2バイト
3. 属性値自体

属性の全長が4バイトの倍数であることが重要です。 たとえば、属性の長さの値が7である場合、最後にスタッフ不足が必要です：（2 + 2 + 7）％4バイトの空のデータ。



UDPプロトコルのエンドポイントコレクションは次のようになります。

1. サーバーに接続する
2. バインディングリクエストを含むパッケージを送信する：
   
   
3. バインディングレスポンスを含むパッケージの取得：
   
   
4. パケットの解析とマッピングアドレスの抽出：
   
   0x00 0x01-MAPPED-ADDRESSに対応する属性タイプ
   
   0x00 0x08-属性の全長
   
   0x00 0x01-IPv4に対応するプロトコルバージョン
   
   0x30 0x39-ポート、値12345

さらに、各バイトはipv4アドレスのオクテットに対応します：123.123.123.123



TCPのエンドポイントのコレクションは多少異なります。 TURNプロトコルに従って取得します。 なぜそうですか？ すべては、TURNサーバーに接続されるソケットの数を最小化することで説明されます。つまり、潜在的に多くの人が同じトラフィックリレーサーバーで「ハング」することができます。



TURNプロトコルで候補者を収集するには、以下を行う必要があります。

1. サーバーに接続します。
2. 割り当て要求を含むパッケージを送信します。
3. TURNサーバーでの認証が必要な場合、応答で401エラーを伴う割り当てエラーを受け取ります。 この場合、サーバーから受信した応答から取得したメッセージ自体、ユーザー名、パスワード、およびレルム属性に基づいて生成されたユーザー名とメッセージ整合性属性で割り当て要求を繰り返す必要があります。
4. 次に、登録が成功した場合、サーバーは、XOR-MAPPED-ADDRESSと同様に、TURNサーバーの専用ポートの属性とともに割り当て成功応答を送信します。これにより、TCPプロトコルのパブリックエンドポイントが送信されます。 IPをさらに使用するには、MagicCookie定数属性0x21 0x12 0xA4 0x42の同じバイトを使用して、各オクテットを「詰まらせる」必要があります（XOR-論理例外操作OR）。
5. このTURN接続でさらに作業する場合は、毎回更新要求を送信して登録を更新する必要があります。 これは、「デッド」接続を破棄するために行われます。

そのため、収集したエンドポイントをリモート側と交換するサーバーがあります。



もちろん、これは単純で理解しやすいように見えますが、RFCを見て振り返ると、wiresharkのヒントがなければ、物事が地面から落ちないことを理解できます-飛び込む準備ができています...

子供を学ぶ、そうでなければあなたは鍵を与えるでしょう...

接続を確立する方法は？

最も簡単なのは、UDPホールパンチを整理することです。

これを行うには、NATでルーティングルールを人為的に作成する必要があります。







リモートエンドポイントへの一連のパケット転送を整理し、そこからの応答を待つだけです。 NATで対応するルールを作成し、「レース」を取り除くには、いくつかのパッケージが必要です。「レース」は、誰が対応するパッケージを最初に配信するのでしょうか。 さて、誰もUDPの損失をキャンセルしませんでした。



その後、制御フレーズを交換し、接続が確立されたと想定できます。



TCPホールパンチの構成はもう少し複雑ですが、一般的なイデオロギーはまったく同じです。



難点は、デフォルトでローカルエンドポイントを占有できるソケットは1つだけであり、別のアドレスに接続しようとすると、最初のアドレスから自動的に切断されることです。 ただし、この制限を削除するソケットオプションがあります：REUSE_ADDRESSおよびEXCLUSIVEADDRUSE。 ソケットの最初のオプションを設定し、2番目のオプションをリセットすると、他のソケットが同じローカルエンドポイントを占有できるようになります。



TURNに接続するときにソケットによって開かれたローカルエンドポイントにバインドし、リモート側のエンドポイントに接続しようとするだけです。



まあ、もう少し複雑ですが、安定した接続設定にはトラフィックリレーも重要です。

1. なぜなら すでにTURNの登録があります。必要なのは、TURN権限にリモート側の登録を追加することだけです。 これを行うには、リモート登録を示すCreatePermissionパッケージを送信します。
2. 接続の開始側は、リモート登録の「詰まった」エンドポイントを示すConnectRequestパケットを送信し、MessageIntegrityパケットに署名します。
3. すべてが正常で、リモート側が登録とともにCreatePermissionを送信した場合、接続成功応答がイニシエーターに送られ、接続がクライアントに試みられます。 どちらの場合も、connection-id属性は着信パケットに存在します。
4. さらに、短時間、元のソケットと同じIPおよびTURNサーバーポートに新しいソケットを接続し（従来のTURNバージョンでは、3478および443 TCPポートの両方がサーバーをリッスンできます）、接続を使用して新しいソケットからConnectionBindパケットを送信する必要があります。以前に受信したID。
5. 接続バインド成功応答を含むパケットを待ち、出来上がり-接続が確立されます。 この場合、はい、2つのソケットが使用されます-接続の維持を担当するコントロールソケットと、直接接続と同様に操作できるトランスポートソケット-送受信されるすべてのものをそのまま処理する必要があります。

使用の優先順位に従って、このような階層を並べました：direct tcp> direct udp> relay（relay）

なぜ私たちは直接UDPを2位にしたのですか？

さて、UDPは、その使いやすさと速度の点で、重大な欠点があります。配信の保証と優先度がありません。 そして、どういうわけかビデオストリーム（グラフィックアーティファクトの存在）に何らかの形で対応できる場合、ここでのファイル転送はやや深刻です。



保証と優先度を確保するために、信頼できるUDPに似たメカニズムが実装されました。これは、はい、わずかに多くのリソースを消費しますが、望ましい結果ももたらします。

どのようにして状況から抜け出しましたか？ まず、MTU（最大伝送単位）-つまり、通過ノードでフラグメンテーションなしで送信できるパケットの可能な最大udpサイズを見つける必要があります。



これを行うには、最大パケットサイズに512バイトを使用し、IP_DONTFRAGMENTオプションをソケットに設定します。 パッケージを送信し、確認を待ちます。 一定時間内に回答が得られた場合は、最大サイズを増やして反復を繰り返します。 最終的に確認を待たなかった場合、MTUサイズを明確にする手順を開始します。最大ブロックサイズを大幅に下げず、10回以内に安定した確認を期待します。 彼らは確認を受けませんでした-彼らはMTUを減らし、新たにサイクルを始めました。

最適なMTUサイズが見つかりました。



次に、分割します。大きなブロック全体を多くの小さなブロックに分割し、パッケージを特徴付ける開始セグメント番号と終了セグメント番号を示します。 分割後、セグメントを送信キューに追加します。 セグメントは、リモートパーティが受信したことを通知するまで送信されます。 再試行間隔は、1.2 * MTUの検索時に受信した最大pingサイズとして使用されます。

受信側では、受信したセグメントを見て、それを着信キューに追加し、最も近いパケットを収集しようとします。 うまくいった場合、ラインをきれいにして、次のラインを集めようとします。



ここで、もちろん、この段落に「生きた」あなたの最も注意深い人は、安全に気付くことができます：x264またはx265コーデックを使用しませんか？ -そして、部分的に正しいでしょう。 正直なところ、私たちはそれをzayuzatする傾向があるので、udpでこの自転車を放棄することができます。 しかし、たとえば、バイナリファイルの転送はどうでしょうか。 この場合、配達の保証と荷物の優先度の必要性に再び戻ります。



結論として、このような接続の組織では、1日に2〜3％の失敗した接続しかありません。そのほとんどは、問題なく接続をセットアップする不正なプロキシまたはファイアウォールの設定です。



このトピックがあなたにとって興味深いものであることが判明した場合（そして、そのように思われます）、以下の記事で、システムで最高の権限を持つアプリケーションの起動、これにより生じる問題、およびそれらへの対処方法について説明します。 圧縮アルゴリズム、仮想デスクトップなどについて。



作成者：Vladislav Yakovlev asmsa