TeamViewer는 얼마나 빠릅니까?

길이가 미안해, 좀 필요해

소개

Windows Vista / 7 용 C # 4.0에서 원격 데스크톱 소프트웨어 (재미있게)를 개발 중입니다. 나는 기본적인 장애물을 겪었습니다 : 강력한 UDP 메시징 시스템, 비교적 깨끗한 프로그램 디자인, 미러 드라이버 (DemoForge의 무료 DFMirage 미러 드라이버)가 설치되어 있으며 모두를 위해 NAT 통과를 구현했습니다. 대칭 NAT를 제외한 NAT 유형 (회사 방화벽 상황에 있음).

화면 전송 / 공유와 관련하여 미러 드라이버 덕분에 변경된 화면 영역에 대해 자동으로 알림을 받고 미러 드라이버의 계속 변경되는 화면 비트 맵을 내 비트 맵에 마샬링 할 수 있습니다. 그런 다음 화면 영역을 PNG로 압축하여 서버에서 클라이언트로 보냅니다. 상황이 꽤 좋아 보이지만 충분히 빠르지는 않습니다. VNC만큼 느립니다 (btw, VNC 프로토콜을 사용하지 않고 맞춤형 아마추어 프로토콜을 사용합니다).

가장 느린 원격 데스크톱 소프트웨어에서 가장 빠른 원격 데스크톱까지이 목록은 일반적으로 모든 VNC와 같은 구현에서 시작하여 Microsoft Windows 원격 데스크톱으로 올라간 다음 TeamViewer로 올라갑니다. CrossLoop, LogMeIn에 대해 잘 모르겠습니다. 사용하지는 않았지만 TeamViewer는 엄청나게 빠릅니다. 말 그대로 살아요. tree명령 프롬프트 에서 명령을 실행하고 20ms 지연으로 업데이트되었습니다. 랩톱보다 몇 밀리 초 느리게 웹을 탐색 할 수 있습니다. Visual Studio에서 세로로 스크롤하는 코드의 지연 시간은 50ms입니다. 이 모든 것을 달성하기 위해 TeamViewer의 화면 전송 솔루션이 얼마나 강력해야하는지 생각해보십시오.

VNC는 폴 기반 후크를 사용하여 최악의 화면 변경 및 무차별 화면 캡처 / 비교를 감지합니다. 기껏해야 DFMirage와 같은 미러 드라이버를 사용합니다. 나는이 수준에있다. 그리고 그들은 RFB 프로토콜이라는 것을 사용합니다.

Microsoft Windows Remote Desktop은 VNC보다 한 단계 높았습니다. StackOverflow 어딘가에서 Windows Remote Desktop이 화면 비트 맵을 보내지 않고 실제 드로잉 명령을 전송한다고 들었습니다. 그것은 간단한 텍스트를 보낼 수 있기 때문에 매우 훌륭합니다 (이 좌표 에서이 사각형을 그리고이 그라디언트로 채색하십시오)! 원격 데스크톱은 실제로 매우 빠르며 집에서 일하는 표준 방법입니다. 그리고 RDP 프로토콜이라는 것을 사용합니다.

이제 TeamViewer는 나에게 완전한 미스터리입니다. 분명히, 그들은 버전 2에 대한 소스 코드를 공개했습니다 (TeamViewer는 2012 년 2 월 현재 버전 7입니다). 사람들은 그것을 읽었으며 버전 2는 쓸모가 없다고 말했습니다. 자동 NAT 통과 기능을 통해 VNC보다 약간 개선 된 것입니다.

그러나 버전 7 ... 지금 엄청나게 빠릅니다. 실제로 Windows Remote Desktop보다 빠릅니다. TeamViewer를 사용하여 DirectX 3D 게임을 스트리밍했습니다 (1fps이지만 Windows Remote Desktop에서는 DirectX를 실행할 수 없음).

그건 그렇고, TeamViewer는 미러 드라이버 없이이 모든 것을 수행합니다 . 하나를 설치하는 옵션이 있으며 조금 더 빠릅니다.

질문

제 질문은 TeamViewer가 얼마나 빠릅니까?가능하지 않아야합니다. 24 비트 깊이 (16 비트 깊이는 눈에 띄게 좋지 않음)에서 1920 x 1080 해상도를 유지하더라도 여전히 6,220,800 바이트입니다. libjpeg-turbo (대기업이 사용하는 가장 빠른 JPG 압축 라이브러리 중 하나)를 사용하여 30KB (압축률이 높음)로 압축하더라도 TeamViewer 서버를 통해 라우팅하는 데 시간이 걸립니다 (TeamViewer는 단순히 트래픽을 프록시하여 기업 대칭 NAT를 우회 함) 그들의 서버). 그리고 libjpeg-turbo 압축은 압축하는 데 시간이 걸립니다. 고품질 JPG 압축은 1920 x 1080 스크린 샷의 경우 175 밀리 초가 걸립니다. 호스트 컴퓨터에서 Atom 프로세서를 실행하면이 숫자가 올라갑니다. TeamViewer가 화면 전송을 어떻게 최적화했는지 이해하지 못합니다. 다시 말하지만 작은 이미지는 압축률이 높을 수 있습니다. 압축하는 데 수십 밀리 초가 걸립니다. 큰 이미지는 압축하는 데 시간이 걸리지 않지만 시간이 오래 걸립니다. 어떻게 든 TeamViewer는이 프로세스 전체를 완료하여 초당 약 20-25 프레임을 얻습니다. 네트워크 모니터를 사용했는데 TeamViewer는 여전히 500Kbps 및 1Mbps 속도에서 지연이 없습니다 (VNC 소프트웨어는 해당 전송 속도에서 몇 초 동안 지연됩니다). 나의 동안tree명령 프롬프트 테스트, TeamViewer는 1Mbps의 속도로 인바운드 데이터를 수신하고 5-6fps를 계속 실행했습니다. 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 라는 코드 플렉스에서 잘 알려지지 않은 프로젝트를 살펴 보는 것이 좋습니다.

ConferenceXP는 고 대역폭 네트워크와 Microsoft Windows의 고급 멀티미디어 기능을 사용하여 간단하고 유연하며 확장 가능한 회의 및 공동 작업을 제공하는 오픈 소스 리서치 플랫폼입니다. ConferenceXP는 연구원과 교사가 실시간 분산 협업 및 원격 학습 환경을 지원하는 방송 품질의 오디오 및 비디오를 특징으로하는 혁신적인 응용 프로그램 및 솔루션을 개발할 수 있도록 도와줍니다.

전체 소스 (거대합니다!)가 제공됩니다. RTP 프로토콜을 구현합니다 .

누군가가 제안한 것처럼 실제로 이미지 스트리밍보다 비디오 스트리밍처럼 들립니다. JPEG / PNG 압축은 이러한 유형의 속도를 대상으로하지 않으므로 잊지 마십시오.

들어오는 비디오 스트림 (화면)을 실시간으로 녹화 할 수있는 녹화 코덱이 시스템에 있다고 상상해보십시오. 아마도 Fraps와 비슷합니다. 그런 다음 다른 쪽 (원격 클라이언트)의 비디오 재생 코덱을 상상해보십시오. HD 레코더가 할 수있는 것처럼 (실시간 녹화, 심지어 같은 HD에서 라이브 재생), 결국에는해야합니다. HD는 디스플레이를 읽을 수있는 것보다 이미지를 더 빨리 전달할 수 없으므로 병목 현상이 발생하지 않습니다. 병목 현상은 비디오 코덱입니다. 모든 디코더는 대부분 무료이기 때문에 인코더보다 인코더가 더 많은 문제를 발견 할 수 있습니다.

나는 그것이 간단하지 않다고 말하는 것이 아니다. 나 자신은 비디오 파일을 인코딩하기 위해 DirectShow를 사용했으며 지금까지는 실시간이 아닙니다. 그러나 올바른 코덱이 주어지면 작동 할 수 있다고 확신합니다.

내 무작위 추측은 : TV는 상용 라이센스가있는 x264 코덱을 사용합니다 (그렇지 않으면 TeamViewer가 소스 코드를 공개해야 함). 어느 시점에서 (5 년 이상 전) x264의 주요 개발자는 저 지연 인코딩에 대한 개선 사항에 대해 기사를 썼습니다 (인코더가 압축 할 수있는 몇 프레임으로 지연되는 경우). TeamViewer와 같은 용도에 적합합니다. 그 게시물에서 그는 눈에 띄는 문제없이 비디오 스트림을 통한 진동 재생을 언급했습니다. 당시에는 TeamViewer가 그 당시 유일한 옵션 이었기 때문에 누가 이러한 개선을 후원했는지 확신했습니다. x264는 H264 비디오 코덱 의 오픈 소스 구현입니다구현이 굉장히 훌륭하고 최고입니다. 동시에 매우 최적화되어 있습니다. 아마도 x264를 매우 잘 구현했기 때문에 CPU 부하가 적을 때 TV로 훨씬 더 나은 결과를 얻을 수 있습니다. AnyDesk와 Chrome 원격 데스크는 x264 (최적화 및 비디오 품질 수준)만큼 좋지 않은 libvpx를 사용합니다.

그러나 TeamView가 Microsoft의 RDP를 이길 수는 없다고 생각합니다. 나에게 가장 좋지만 Windows PC 또는 Mac에서 Windows로만 작동합니다. TV는 휴대 전화에서도 작동합니다.

업데이트 : 기사는 2010 년 1 월에 작성되었으므로 약 10 년 전에 작업이 완료되었습니다. 또한, 나는 실수를했다 : 그는 지진이 아니라 외침을했다. 질문을 올렸을 때 내 추측이 맞다면 TeamViewer는 3 년 동안 그 작업을 사용해 왔습니다. 웹 아카이브에서 해당 블로그 게시물을 읽으십시오. x264 : 세계 최고의 지연 시간이 짧은 비디오 스트리밍 플랫폼 . 2010 년 기사를 다시 읽었을 때 필자가 언급 한 "스타트 업 – 이름을 지정하지 말 것"은 TeamViewer라고 확신했습니다.

이상하게 그러나 내 경험에 따르면 TeamViewer는 VNC보다 빠르거나 반응이 빠르지 만 설정하기 쉽습니다. OpenVPN을 통한 VNC (또 다른 오버 헤드 레이어가 있음)에 몇 가지 win-boxen이 있으며 저렴한 케이블 (512 up)에 있으며 TightVNC가 TeamViewer보다 동일한 boxen에 훨씬 더 반응 적으로 올바르게 설정되어 있습니다. RDP는 자연스럽게 비트 맵 타일 대신 GUI 그리기 명령을 전송하기 때문에 훨씬 더 자연 스럽습니다.

이것은 우리에게 다음을 가져옵니다.

1. 왜 VNC를 사용하지 않습니까? 수많은 오픈 소스 솔루션이 있으며 Tight는 아마도 현재 게임의 맨 위에있을 것입니다.

2. 고급 VNC 구현에서는 손실 압축을 사용하므로 선택한 PNG보다 더 나은 결과를 얻을 수 있습니다. 또한 IIRC는 나머지 페이로드도 zlib를 사용하여 스쿼시됩니다. j Tight와 UltraVNC는 특히 창문에 최적화 된 알고리즘을 가지고 있습니다. Tight는 오픈 소스입니다.

3. win boxen이 기본 대상인 경우 RDP가 더 나은 옵션 일 수 있으며 공개 소스 구현 (rdesktop)이 있습니다.

4. * nix boxen이 주요 대상인 경우 NX가 더 나은 옵션 일 수 있으며 오픈 소스 구현 (NoMachine의 독점 제품만큼 최적화되지는 않았지만 FreeNX)이있을 수 있습니다.

JPEG 압축이 algo의 성능 문제인 경우 이미지 비교로 인해 여전히 일부 성능이 저하 될 것입니다. 나는 모든 특정 상황에 대해 최상의 압축을 사용합니다. 즉, 큰 프레임의 경우 손실이 있고 작은 프레임의 경우 빠르고 내부가 빠르며 이미지의 비트를 비교하고 다른 종류의 최적화 트릭 만 보냅니다.

그리고 Tight> 2.0에는 많은 트릭이 다시 나타나야합니다. 제 경험상 TeamViewer 성능 인 YMMV를 능가합니다.

또한 C ++과 같은 것보다 JIT 컴파일 된 런타임을 선택하면 특히 메모리 제한 시스템 (성능이 많은 경우 Windows가 페이지 파일을 집중적으로 사용하기 시작하면 변질됩니다)에서 성능 측면에서 약간의 시간이 걸릴 수 있습니다. 그리고 DF mirage가 제공하는 것의 내부 비교를 위해 이전 이미지 상태를 유지하려면 메모리가 필요합니다.