TeamViewerはどのように高速ですか？

長さについて申し訳ありません、それはちょっと必要です。

前書き

私は、Windows Vista / 7用のC＃4.0でリモートデスクトップソフトウェア（楽しみのために）を開発しています。基本的な障害を乗り越えました：堅牢なUDPメッセージングシステム、比較的クリーンなプログラム設計、ミラードライバー（DemoForgeからの無料のDFMirageミラードライバー）が稼働しており、すべてにNATトラバーサルを実装しています対称NATを除くNATタイプ（企業ファイアウォールの状況に存在）。

画面の転送/共有については、ミラードライバーのおかげで、変更された画面領域が自動的に通知され、ミラードライバーの絶えず変化する画面ビットマップを自分のビットマップにマーシャリングできます。次に、画面領域をPNGとして圧縮し、サーバーからクライアントに送信します。物事はかなり良いように見えますが、十分に速くはありません。VNCと同じくらい遅いです（ところで、私はVNCプロトコルを使用せず、カスタムのアマチュアプロトコルを使用しています）。

最も遅いリモートデスクトップソフトウェアから最も速いリモートデスクトップソフトウェアまで、リストは通常​​、すべてのVNCのような実装で始まり、Microsoft Windowsリモートデスクトップ...、そして... TeamViewerまで続きます。CrossLoop、LogMeInについてはよくわかりません-私はそれらを使用していませんが、TeamViewerは非常に高速です。文字通りライブです。treeコマンドプロンプトでコマンドを実行したところ、20ミリ秒の遅延で更新されました。私のラップトップよりも数ミリ秒遅いWebを閲覧できます。Visual Studioでコードを垂直にスクロールすると、ラグ時間が50ミリ秒になります。これをすべて実現するには、TeamViewerの画面転送ソリューションがどれほど堅牢でなければならないかを考えてください。

VNCは、ポーリングベースのフックを使用して、画面の変化を検出し、ブルートフォース画面のキャプチャ/比較を最悪の場合に行います。最高の状態では、DFMirageのようなミラードライバーを使用します。私はこのレベルです。また、RFBプロトコルと呼ばれるものを使用しています。

Microsoft Windowsリモートデスクトップは、明らかにVNCよりも1段階高くなっています。StackOverflowのどこかから、Windowsリモートデスクトップは画面のビットマップを送信せず、実際の描画コマンドを送信すると聞きました。単純なテキストを送信できるため、これは非常に素晴らしいです（この長方形をこの座標で描画し、このグラデーションで色付けします）。リモートデスクトップは非常に高速で、自宅で作業するための標準的な方法です。また、RDPプロトコルと呼ばれるものを使用します。

今、TeamViewerは私にとって完全な謎です。どうやら、彼らはバージョン2のソースコードをリリースしました（TeamViewerは2012年2月現在のバージョン7）。人々はそれを読んで、バージョン2は役に立たないと言った-それは自動NATトラバーサルによるVNCのほんのいくつかの改善だ。

しかし、バージョン7 ...今は途方もなく高速です。つまり、実際にはWindowsリモートデスクトップよりも高速です。TeamViewerでDirectX 3Dゲームをストリーミングしました（1 fpsですが、WindowsリモートデスクトップではDirectXを実行することもできません）。

ちなみに、TeamViewerはミラードライバーなしでこれらすべてを行います。インストールするオプションがあり、少し速くなります。

質問

私の質問は、TeamViewerはどのくらい高速なのですか？それは不可能であってはなりません。24ビットの深さでも1920 x 1080の解像度がある場合（16ビットの深さはかなり醜いでしょう）、それでも未加工の6,220,800バイトです。libjpeg-turbo（大企業で使用されている最速のJPG圧縮ライブラリの1つ）を使用して30KBに圧縮すると（非常に寛大にしましょう）、TeamViewerのサーバーを介してルーティングするのに時間がかかります（TeamViewerは、トラフィックをプロキシするだけで、企業の対称NATをバイパスします彼らのサーバー）。そして、そのlibjpeg-turbo圧縮は圧縮に時間がかかります。高品質のJPG圧縮は、1920 x 1080のフルスクリーンショットで175ミリ秒かかります。そして、ホストのコンピューターがAtomプロセッサーを実行している場合、その数は増えます。TeamViewerが画面転送をどのように最適化したかがわかりません。繰り返しになりますが、小さなサイズの画像は高度に圧縮されている可能性があります。ただし、圧縮には少なくとも数十ミリ秒かかります。大きなサイズの画像は圧縮に時間がかかりませんが、処理に時間がかかります。どういうわけか、TeamViewerはこのプロセス全体を完了して、毎秒約20〜25フレームを取得します。私はネットワークモニタを使用しましたが、TeamViewerは500 Kbpsと1 Mbpsの速度でも遅延がありません（その転送速度ではVNCソフトウェアは数秒間遅延します）。私の中にtreeコマンドプロンプトテストでは、TeamViewerは1 Mbpsの速度でインバウンドデータを受信し、それでも5〜6 fpsを実行していました。VNCとリモートデスクトップはそれを行いません。では、どうやって？

答えはやや複雑で複雑になるため、TCPの代わりにUDPを使用しているためだと言ってはいけない場合は、$ 0.02を投稿しないでください（実際にTCPを同じように使用していると思いますか）。

StackOverflowのどこかにTeamViewer開発者がいることを願っています。

潜在的な答え

人々が返信したら、これを更新します。

1. 私の考えは、まず第一に、TeamViewerは非常に細かいネットワーク制御を持っているということです。たとえば、大きなパケットをMTUサイズのすぐ下に分割し、トリップを無駄にすることはありません。おそらく、非常に高速なXOR画像比較とともに、画面の変化を検出するためのあらゆる種類のファンシーフックがあります。

ここで最も基本的なことは、静的な画像を送信するのではなく、画像への変更のみを送信することです。これは本質的にビデオストリームに類似しています。

一般的なデスクトップの使用における実際の変更のほとんどは要素の線形移動（要素の変換とは反対に、テキストのスクロール、ウィンドウの移動など）であるため、私の推測では、非常に効率的な（そして非常に特殊化され、最適化された）モーション補正アルゴリズムです。

1 FPSのDirectX 3Dパフォーマンスは、私の推測をある程度確認するようです。

TeamViewerのサーバーを介してルーティングするのに時間がかかります（TeamViewerは、サーバーを介してトラフィックをプロキシするだけで、企業の対称NATをバイパスします）

TeamViewerが独自のサーバーを介してトラフィックを中継する必要がほとんどないことがわかります。TeamViewerは、NATトラバーサルを使用して、NATとNATによって複雑化されたネットワークを貫通します（GoogleのlibjingleのようなUDPホールパンチングだと思います）。

彼らはハンドシェイクと接続のセットアップを行うために、仲介者に対して独自のサーバーを使用しますが、ほとんどの場合、クライアントとサーバー間の関係はP2Pになります（ハンドシェイクが成功した場合に最適です）。NATトラバーサルが失敗した場合、TeamViewerは実際に独自のサーバーを介してトラフィックを中継します。

ただし、クライアントがダブルNATを使用している場合にのみ、これが実行されるのを見たことがあります。

少し遅い答えですが、ConferenceXPと呼ばれるcodeplexに関するよく知られていないプロジェクトをご覧になることをお勧めします

ConferenceXPは、高帯域幅ネットワークとMicrosoft Windowsの高度なマルチメディア機能を使用して、シンプルで柔軟な拡張可能な会議とコラボレーションを提供するオープンソースの研究プラットフォームです。ConferenceXPは、研究者と教育者が、リアルタイムの分散型コラボレーションと遠隔学習環境をサポートする放送品質のオーディオとビデオを特徴とする革新的なアプリケーションとソリューションを開発するのに役立ちます。

完全なソース（巨大です！）が提供されます。RTPプロトコルを実装しています。

誰かが示唆したように、それは確かに画像ストリーミングよりもビデオストリーミングのように聞こえます。JPEG / PNG圧縮はこれらのタイプの速度を対象としていないため、忘れてください。

システムに、着信ビデオストリーム（画面）をリアルタイムで記録できる記録コーデックがあるとします。おそらく、Frapsに少し似ています。次に、反対側（リモートクライアント）のビデオ再生コーデックを想像してください。HDレコーダーはそれを行うことができるので（同じHDからライブで録画し、ライブで再生することもできます）、最終的にはそうする必要があります。HDは、ディスプレイを読み取る速度よりも速く画像を配信できないため、それがボトルネックになることはありません。ボトルネックはビデオコーデックです。すべてのデコーダーはほとんど無料なので、エンコーダーはデコーダーよりもはるかに多くの問題を見つけます。

簡単だと言っているのではありません。私自身、DirectShowを使用してビデオファイルをエンコードしていますが、これははるかにリアルタイムではありません。しかし、適切なコーデックが与えられれば、それが機能することを確信しています。

私のランダムな推測は次のとおりです。テレビは商用ライセンスを持つx264コーデックを使用します（そうでない場合、TeamViewerはソースコードをリリースする必要があります）。ある時点（5年以上前）で、x264の主な開発者が低遅延エンコーディングのために行った改善に関する記事を書いたことを思い出します（数フレーム遅延すると、エンコーダーがよりよく圧縮できます）。 TeamViewerのような使用に関連します。その投稿で彼は、目立った問題なしにビデオストリームで地震を再生することについて言及しました。当時は、TeamViewerがほとんど唯一の選択肢だったので、これらの改善のスポンサーはだれかであると確信していました。x264はH264ビデオコーデックのオープンソース実装です、そしてそれはめちゃくちゃ良い実装であり、最高のものです。同時に、それは非常によく最適化されています。最も可能性が高いのは、x264の実装が非常に優れているため、テレビのCPU負荷が低いと、はるかに良い結果が得られます。AnyDeskとChromeリモートデスクはlibvpxを使用しますが、これはx264（最適化とビデオ品質に関して）ほど良くありません。

ただし、TeamViewがMicrosoftのRDPに勝ることはないと思います。私にとっては最高ですが、Windows PC間またはMacからWindows間でのみ機能します。TVは携帯電話でも機能します。

更新：記事は2010年1月に書かれたため、作業は約10年前に行われました。また、私は誤りを犯しました。彼は地震ではなく、コールオブデューティを果たしました。あなたが質問を投稿したとき、私の推測が正しければ、TeamViewerはその作品を3年間使用していました。そのブログ投稿をWebアーカイブからお読みください：x264：世界で最高の低遅延ビデオストリーミングプラットフォーム。2010年にこの記事を読んだとき、著者が言及している「スタートアップに名前を付けることを要求していない」がTeamViewerであると確信していました。

奇妙なことに。しかし、私の経験では、TeamViewerはVNCよりも高速/応答性が高くなく、セットアップが簡単です。OpenVPNを介してVNCを実行するいくつかのwin-boxenがあり（別のオーバーヘッドレイヤーがあるため）、それは安価なケーブル（512アップ）にあり、TightVNCを適切に設定すると、TeamViewerよりも同じボクセンに応答するようになります。RDPは（当然）さらに多くの場合、ビットマップタイルの代わりにGUI描画コマンドを送信するためです。

これにより、次のことが可能になります。

1. なぜVNCを使用しないのですか？オープンソースのソリューションはたくさんありますが、タイトはおそらく現在ゲームの上にあります。

2. 高度なVNC実装は不可逆圧縮を使用しており、選択したPNGよりも良い結果が得られるようです。また、ペイロードの残りのIIRCもzlibを使用して押しつぶされます。両方のTightとUltraVNCは、特にWindows用に非常に最適化されたアルゴリズムを備えています。その上に、タイトなのはオープンソースです。

3. win boxenが主なターゲットの場合、RDPがより良いオプションであり、オープンソース実装（rdesktop）を持っている場合

4. * nix boxenが主なターゲットである場合、NXの方がより良いオプションであり、オープンソースの実装があります（FreeNX、NoMachine独自の製品ほど最適化されていません）。

JPEGの圧縮がアルゴのパフォーマンスの問題である場合、画像の比較によってパフォーマンスが多少低下することは間違いありません。私はそれらがすべての特定の状況でベストケースの圧縮を使用すると思います。つまり、大きなフレームでは損失があり、小さなフレームではロスレスで高速でダーティ、画像のビットを比較し、ソートの差分と他の最適化トリックの束のみを送信します。

そして、これらのトリックの多くは、タイト> 2.0にも存在している必要があります。私の経験では、TeamViewerのパフォーマンスワイズであるYMMVに勝るものはありません。

また、特にメモリに制約のあるマシンでは、C ++などのJITコンパイルランタイムを選択すると、パフォーマンスエッジから一部が失われる可能性があります（ウィンドウがページファイルを集中的に使用し始めると、多くのパフォーマンスチューニングがトイレに行きます）。そして、DFミラージュが提供するものの上に内部比較のために以前の画像の状態を維持するためのメモリが必要になります。