リモートデスクトップソフトウェア：Teamviewerがオープンソースの競合他社よりもはるかに高速なのはなぜですか？
TeamViewerは、次の2つの側面に関してFLOSSの代替手段と比較して高速です。
- 実際のセッションの前の構成プロセス全体：IPを決定し、NAT＆ファイアウォールなどを通過しますが、TeamViewerではID/PWを入力するだけで、TeamViewerの集中システムを通過します（もちろんです）信頼の問題！）。
- リモート表示/制御セッション自体：VNCソリューションは、流暢で応答性がはるかに低く、数十秒遅れることがよくありますが、Teamviewerでは、画面のコンテンツが高頻度で変化する場合（アニメーションコンテンツなど）を除いて、ほぼ「ライブ」に感じられます。
＃2に関する技術的な説明をいただければ幸いです。 TeamViewerを非常に高速にする最適化の可能性がどこにあるのかを理解することはできません。
VNCは非効率的です-それは [〜＃〜] rfb [〜＃〜] を使用します。これは事実上、システムのスナップショットを頻繁に取得し、クライアントシステムにXサイズのボックスを頻繁に描画するように指示します（ RFBプロトコル の完全な説明はここにあります。より効率的なプロトコルはありませんフレームバッファレベルで動作します [〜＃〜] rdp [〜＃〜] たとえば、Windowsでカーネルレベルのドライバを使用し、 nx データをキャッシュおよび圧縮します。
より効率的なプロトコルはそのようになりそうです
- データをキャッシュし、違いのみを送信します
- ホストOSのネイティブサブシステムにフックします
- キャッシュと圧縮を使用してデータ転送を高速化します。
Teamviewerの場合、1番目と3番目の賢い使用の可能性があります- 同じクライアントを使用しているように見えるため WindowsとLinuxの場合、サーバーを使用してトラフィックの接続とルーティングを処理します
VNCは単に恐ろしい比較ポイントであるという事実を強調したいと思います。
Linuxシステム間で、適切に構成されたxpraは、はるかに優れたパフォーマンスを提供します。これは主に、H.264ベースの不可逆圧縮をサポートしているためです。
TeamViewerでサポートされている唯一の不可逆圧縮は、色深度を減らし、アニメーションコンテンツにはほとんど役立たない、ある種のインターレースアップデートであるようです。優れたシステムは、品質をスムーズに犠牲にして、妥当な更新率を維持することができます。言及されたxpraはそれにいくらか近づいていますが、正直なところ、それはまだくだらない仕事をします。
もう1つの問題は、TCP vs.UDPベースです。TCPベースのプロトコルは、たとえば、高いパケット損失や、データを送信すると、送信する必要があります-したがって、1回の大きな更新は、画面が到着するまでハングすることを意味します。特に、画面に大きな変更があると数分後まで変更が表示されないため、VNCが使用できなくなる低速接続の場合は、sshも比較してください。純粋なテキストの場合はモッシュ。
高度なビデオコーデックの高い圧縮率、失われたパケットを処理するための優れた方法を備えたUDPの使用、「役に立たない」よりもテキストの読みやすさを検出して優先する知覚コーディングを組み合わせたプロトコルは、まだ誰も本当に優れたプロトコルを発明できていないようです。 「詳細、更新/送信速度と品質およびエンコード速度の適切な自動バランス調整、更新されていない領域の時間の経過に伴う段階的かつスムーズな品質の改善、クライアント側のキャッシングと差分（ビデオコーディングは過去のフレームを参照できますが、実際にはあまり良くありません）通常のデスクトップコンテンツと一致し、数百MBの参照データクライアント側を簡単に保存できるという事実）。言い換えれば、TeamViewerがしているように見えるのは、完全に愚かなことをしないことだけです（VNCにはほとんどその年齢を示す言い訳がありますが）、言うまでもなく、今日でも可能な巧妙なトリックのほんの一部でも実装するソリューションはありません想像できるすべてのもの。