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ミリ秒の遅延で更新しました。私のラップトップよりも数ミリ秒遅いだけでウェブを閲覧できます。 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つ）を使用して30 KBに圧縮しても（非常に寛大になりましょう）、TeamViewerのサーバーを経由するのに時間がかかります（TeamViewerは単にトラフィックをプロキシすることで企業Symmetric NATをバイパスします彼らのサーバー）。そして、そのlibjpeg-turbo圧縮は圧縮に時間がかかります。高品質のJPG圧縮には、1920 x 1080のスクリーンショット全体で175ミリ秒かかります。そして、ホストのコンピューターがAtomプロセッサーを実行している場合、その数値は上がります。 TeamViewerがどのように画面転送を最適化しているかがわかりません。繰り返しますが、小さなサイズの画像は高度に圧縮されている場合がありますが、圧縮には少なくとも数十ミリ秒かかります。大きいサイズの画像は圧縮するのに時間がかかりませんが、処理に時間がかかります。どういうわけか、TeamViewerはこのプロセス全体を完了して、1秒あたり約20〜25フレームを取得します。ネットワークモニターを使用しましたが、TeamViewerは500 Kbpsおよび1 Mbpsの速度でまだラグレスです（その転送速度でVNCソフトウェアは数秒間遅れます）。 treeコマンドプロンプトテスト中、TeamViewerは1 Mbpsの速度でインバウンドデータを受信し、5〜6 fpsを実行していました。 VNCとリモートデスクトップはそれを行いません。それで、どうやって？
答えはやや複雑で複雑になるため、TCPの代わりにUDPを使用しているためだと言う場合は、$ 0.02を投稿しないでください（実際にTCPを実際に使用していると思いますか？）.
StackOverflowのどこかにTeamViewer開発者がいることを期待しています。
潜在的な回答
人々が返信したらこれを更新します。
- 私の考えは、まず第一に、TeamViewerには非常にきめ細かなネットワーク制御があるということです。たとえば、大きなパケットをMTUサイズのすぐ下に分割し、旅行を無駄にすることはありません。おそらく、非常に高速なXOR画像比較とともに、画面の変化を検出するためのあらゆる種類の派手なフックがあります。
ここで最も基本的なことは、おそらく、静的な画像を送信するのではなく、画像にchangesのみを送信することです。これは、本質的にvideo stream 。
一般的なデスクトップの使用法の実際の変更のほとんどはlinear要素の移動（スクロールテキスト、ウィンドウの移動など）要素の変換）。
1 FPSのDirectX 3Dパフォーマンスは、ある程度私の推測を裏付けているようです。
teamViewerのサーバーを介してルーティングするのに時間がかかります（TeamViewerは、単にサーバーを介してトラフィックをプロキシすることにより、企業の対称NATをバイパスします）
TeamViewerが独自のサーバーを介してトラフィックを中継する必要はほとんどありません。 TeamViewerはNATおよびNATによる複雑なネットワークに侵入しますNATトラバーサルを使用して（それは DPホールパンチング のように、 Googleのlibjingle ）。
彼らは、ハンドシェイクと接続のセットアップを行うために、仲介者に対して独自のサーバーを使用しますが、ほとんどの場合、クライアントとサーバー間の関係はP2Pになります（ハンドシェイクが成功した場合が最適です）。 NATトラバーサルが失敗した場合、TeamViewerは実際に独自のサーバーを介してトラフィックを中継します。
ただし、クライアントがダブルNATの背後にいる場合にのみ、これを行うのを見たことはあります。
少し遅れた答えですが、コードプレックスでよく知られていない ConferenceXP というプロジェクトをご覧になることをお勧めします
ConferenceXPは、高帯域幅ネットワークとMicrosoft Windowsの高度なマルチメディア機能を使用して、シンプルで柔軟かつ拡張可能な会議とコラボレーションを提供するオープンソースの研究プラットフォームです。 ConferenceXPは、研究者と教育者がリアルタイムの分散コラボレーションと遠隔学習環境をサポートする放送品質のオーディオとビデオを特徴とする革新的なアプリケーションとソリューションを開発するのを支援します。
完全なソース（巨大です！）が提供されています。 RTPプロトコル を実装します。
誰かが提案したように、それは確かに画像ストリーミングよりもビデオストリーミングのように聞こえます。 JPEG/PNG圧縮は、これらのタイプの速度を対象としていないため、忘れてください。
システム上に着信ビデオストリーム（画面）をリアルタイムで記録できるレコーディングコーデックがあることを想像してください。おそらくフラップに少し似ています。次に、反対側（リモートクライアント）のビデオ再生コーデックを想像してください。 HDレコーダーでできるので（同じHDからライブで録画し、ライブで再生することもできます）、最終的にはあなたもそうするべきです。 HDは、ディスプレイを読むよりも速く画像を配信できないので、ボトルネックではありません。ボトルネックはビデオコーデックです。すべてのデコーダーはほとんど無料であるため、エンコーダーはデコーダーよりもはるかに問題が多いことがわかります。
簡単だと言っているわけではありません。私自身、DirectShowを使用してビデオファイルをエンコードしましたが、これは決してリアルタイムではありません。しかし、適切なコーデックがあれば、それが機能すると確信しています。
奇妙な。しかし、私の経験では、TeamViewerはVNCよりも高速/応答性が高くなく、セットアップが簡単です。私はOpenVPN経由でVNCを行ういくつかのwin-boxenを持っているため（別のオーバーヘッドレイヤーがあります）、それは安価なケーブル（512以上）にあり、TightVNCを適切にセットアップすると、同じboxenに対してTeamViewerよりもはるかに応答しやすくなります。大部分はビットマップタイルの代わりにGUI描画コマンドを送信するため、RDPは（当然）さらにそれ以上です。
これにより、次のことが可能になります。
なぜVNCを使用していないのですか？たくさんのオープンソースソリューションがありますが、今はおそらくタイトがゲームのトップにいます。
高度なVNC実装では非可逆圧縮を使用しているため、PNGを選択するよりも優れた結果が得られるようです。また、IIRCはペイロードの残りもzlibを使用して押しつぶされます。 TightとUltraVNCの両方は、特にウィンドウ向けに非常に最適化されたアルゴリズムを備えています。その上にTightはオープンソースです。
Win boxenが主なターゲットである場合、RDPがより良いオプションであり、オープンソース実装（rdesktop）があります。
* nix boxenが主なターゲットである場合、NXがより良いオプションであり、オープンソース実装を備えている可能性があります（NoMachine独自の製品ほど最適化されていませんが、FreeNX）。
JPEGの圧縮がアルゴリズムのパフォーマンスの問題である場合、画像の比較によってパフォーマンスが多少低下することは間違いありません。特定の状況ごとにベストケース圧縮を使用していることを確認します。つまり、大きなフレームの場合は不可逆、小さなフレームの場合は内部のロスレスな高速、ダーティな画像のみを比較し、その他の最適化トリックを送信します。
そして、これらのトリックの多くは、Tight> 2.0に存在する必要があります。私の経験では、TeamViewerのパフォーマンスwyse、YMMVに勝っています。
また、C++のようなものよりもJITコンパイル済みランタイムを選択すると、特にメモリに制約のあるマシンでパフォーマンスエッジの一部を使用する場合があります（Windowsがページファイルを集中的に使用し始めると、多くのパフォーマンスチューニングがトイレに行きます）。また、DF mirageが提供する内容の内部比較のために、以前のイメージ状態を保持するためのメモリが必要になります。