Làm thế nào là TeamViewer nhanh như vậy?

Xin lỗi về chiều dài, nó hơi cần thiết.

Giới thiệu

Tôi đang phát triển một phần mềm máy tính từ xa (chỉ để giải trí) trong C # 4.0 cho Windows Vista / 7. Tôi đã vượt qua những trở ngại cơ bản: Tôi có một hệ thống nhắn tin UDP mạnh mẽ, thiết kế chương trình tương đối sạch sẽ, tôi đã có một trình điều khiển gương (trình điều khiển gương DFMirage miễn phí từ DemoForge) và tôi đã triển khai NAT traversal cho tất cả Các loại NAT ngoại trừ NAT đối xứng (có mặt trong các tình huống tường lửa của công ty).

Về chuyển / chia sẻ màn hình, nhờ trình điều khiển gương, tôi tự động được thông báo về các vùng màn hình đã thay đổi và tôi có thể chỉ đơn giản là sắp xếp bitmap màn hình luôn thay đổi của trình điều khiển gương thành bitmap của riêng tôi. Sau đó, tôi nén vùng màn hình dưới dạng PNG và gửi nó từ máy chủ đến máy khách của mình. Mọi thứ có vẻ khá tốt, nhưng nó không đủ nhanh. Nó cũng chậm như VNC (btw, tôi không sử dụng giao thức VNC, chỉ là một giao thức nghiệp dư tùy chỉnh).

Từ phần mềm máy tính từ xa chậm nhất đến nhanh nhất, danh sách thường bắt đầu ở tất cả các triển khai giống như VNC, sau đó leo lên Microsoft Windows Remote Desktop ... và sau đó ... TeamViewer. Không hoàn toàn chắc chắn về CrossLoop, LogMeIn - Tôi chưa sử dụng chúng, nhưng TeamViewer cực kỳ nhanh. Nó hoàn toàn sống theo nghĩa đen. Tôi đã chạy một treelệnh trên Command Prompt và nó được cập nhật với độ trễ 20 ms. Tôi có thể duyệt web chậm hơn vài mili giây so với trên máy tính xách tay của mình. Mã cuộn theo chiều dọc trong Visual Studio có thời gian trễ 50 ms. Hãy suy nghĩ về giải pháp chuyển màn hình của TeamViewer mạnh mẽ như thế nào để hoàn thành tất cả điều này.

Các VNC sử dụng các móc dựa trên cuộc thăm dò để phát hiện sự thay đổi màn hình và bắt giữ / so sánh màn hình vũ lực ở mức tồi tệ nhất. Tốt nhất, họ sử dụng trình điều khiển gương như DFMirage. Tôi đang ở cấp độ này. Và họ sử dụng một cái gì đó gọi là giao thức RFB.

Microsoft Windows Remote Desktop rõ ràng cao hơn một bước so với VNC. Tôi nghe nói, từ một nơi nào đó trên StackOverflow, Windows Remote Desktop không gửi bitmap màn hình, mà là các lệnh vẽ thực tế. Điều đó khá tuyệt vời, bởi vì nó chỉ có thể gửi văn bản đơn giản (vẽ hình chữ nhật này tại tọa độ này và tô màu nó bằng gradient này)! Remote Desktop thực sự khá nhanh - và đó là cách làm việc tiêu chuẩn ở nhà. Và nó sử dụng một cái gì đó gọi là giao thức RDP.

Bây giờ TeamViewer là một bí ẩn hoàn toàn đối với tôi. Rõ ràng, họ đã phát hành mã nguồn của họ cho Phiên bản 2 (TeamViewer là Phiên bản 7 kể từ tháng 2 năm 2012). Mọi người đã đọc nó và nói rằng Phiên bản 2 là vô dụng - đó chỉ là một vài cải tiến so với VNC với tính năng NAT tự động.

Nhưng phiên bản 7 ... bây giờ nhanh đến mức nực cười. Ý tôi là, nó thực sự nhanh hơn Windows Remote Desktop. Tôi đã phát trực tuyến các trò chơi DirectX 3D với TeamViewer (ở tốc độ 1 khung hình / giây, nhưng Windows Remote Desktop thậm chí không cho phép DirectX chạy).

Nhân tiện, TeamViewer thực hiện tất cả điều này mà không cần trình điều khiển gương. Có một tùy chọn để cài đặt một, và nó chỉ nhanh hơn một chút.

Câu hỏi

Câu hỏi của tôi là, TeamViewer nhanh như thế nào?Nó không phải là có thể. Nếu bạn có độ phân giải 1920 x 1080 ở độ sâu thậm chí 24 bit (độ sâu 16 bit sẽ rất xấu), đó vẫn là 6.220.800 byte. Ngay cả khi sử dụng libjpeg-turbo (một trong những thư viện nén JPG nhanh nhất được sử dụng bởi các tập đoàn lớn), việc nén nó xuống 30KB (hãy cực kỳ hào phóng), sẽ mất thời gian để định tuyến qua các máy chủ của TeamViewer (TeamViewer bỏ qua NAT đối xứng của công ty bằng cách ủy quyền lưu lượng truy cập thông qua máy chủ của họ). Và nén libjpeg-turbo sẽ mất thời gian để nén. Nén JPG chất lượng cao mất 175 mili giây cho ảnh chụp màn hình 1920 x 1080 đầy đủ cho tôi. Và con số đó tăng lên nếu máy tính của máy chủ chạy bộ xử lý Atom. Tôi chỉ đơn giản là không hiểu làm thế nào TeamViewer đã tối ưu hóa việc chuyển màn hình của họ rất tốt. Một lần nữa, hình ảnh kích thước nhỏ có thể bị nén rất cao, nhưng mất ít nhất hàng chục mili giây để nén. Hình ảnh kích thước lớn không mất thời gian để nén, nhưng mất nhiều thời gian để vượt qua. Bằng cách nào đó, TeamViewer hoàn thành toàn bộ quá trình này để có được khoảng 20-25 khung hình mỗi giây. Tôi đã sử dụng màn hình mạng và TeamViewer vẫn không bị lag ở tốc độ 500 Kb / giây và 1 Mb / giây (độ trễ phần mềm VNC trong vài giây với tốc độ truyền đó). Trong thời gian của tôitreeKiểm tra dấu nhắc lệnh, TeamViewer đã nhận được dữ liệu gửi đến với tốc độ 1 Mb / giây và vẫn chạy 5-6 khung hình / giây. VNC và máy tính để bàn từ xa không làm điều đó. Vậy làm thế nào?

Các câu trả lời sẽ hơi phức tạp và phức tạp, vì vậy vui lòng không đăng 0,02 đô la của bạn nếu bạn chỉ nói rằng vì họ sử dụng UDP thay vì TCP (bạn có tin rằng họ thực sự sử dụng TCP như vậy không).

Tôi hy vọng có một nhà phát triển TeamViewer ở đâu đó trên StackOverflow.

Câu trả lời tiềm năng

Sẽ cập nhật điều này một khi mọi người trả lời.

1. Suy nghĩ của tôi, trước hết, rằng TeamViewer có khả năng kiểm soát mạng rất tốt. Ví dụ, họ chia các gói lớn thành dưới kích thước MTU và không bao giờ lãng phí một chuyến đi. Họ có thể có tất cả các loại móc lạ mắt để phát hiện thay đổi màn hình cùng với việc so sánh hình ảnh XOR cực nhanh.

Điều cơ bản nhất ở đây có lẽ là bạn không muốn truyền hình ảnh tĩnh mà chỉ thay đổi hình ảnh, về cơ bản là tương tự với luồng video .

Dự đoán tốt nhất của tôi là một số thuật toán bù chuyển động rất hiệu quả (và rất chuyên biệt và được tối ưu hóa), bởi vì hầu hết sự thay đổi thực tế trong sử dụng máy tính để bàn chung là chuyển động tuyến tính của các yếu tố (cuộn văn bản, di chuyển cửa sổ, v.v. trái ngược với chuyển đổi các yếu tố).

Hiệu suất DirectX 3D của 1 FPS dường như xác nhận dự đoán của tôi ở một mức độ nào đó.

sẽ mất thời gian để định tuyến qua các máy chủ của TeamViewer (TeamViewer bỏ qua các NAT đối xứng của công ty bằng cách chỉ cần ủy quyền lưu lượng truy cập thông qua các máy chủ của họ)

Bạn sẽ thấy rằng TeamViewer hiếm khi cần chuyển tiếp lưu lượng qua máy chủ của riêng họ. TeamViewer thâm nhập vào NAT và các mạng phức tạp bởi NAT bằng cách sử dụng NAT traversal (Tôi nghĩ rằng đó là lỗ hổng UDP , giống như lib lible của Google ).

Họ sử dụng máy chủ của riêng mình cho người trung gian để thực hiện bắt tay và thiết lập kết nối, nhưng hầu hết thời gian mối quan hệ giữa máy khách và máy chủ sẽ là P2P (trường hợp tốt nhất, khi bắt tay thành công). Nếu NAT traversal thất bại, thì TeamViewer thực sự sẽ chuyển tiếp lưu lượng qua các máy chủ của chính nó.

Tôi chỉ từng thấy nó làm điều này khi một khách hàng đứng sau hai lần NAT.

Một câu trả lời hơi muộn, nhưng tôi khuyên bạn nên xem một dự án không nổi tiếng về codeplex có tên là ConferenceXP

ConferenceXP là một nền tảng nghiên cứu mã nguồn mở cung cấp sự hợp tác và hội thảo đơn giản, linh hoạt và có thể mở rộng bằng cách sử dụng các mạng băng thông cao và các khả năng đa phương tiện tiên tiến của Microsoft Windows. ConferenceXP giúp các nhà nghiên cứu và nhà giáo dục phát triển các ứng dụng và giải pháp sáng tạo có tính năng âm thanh và video chất lượng phát sóng để hỗ trợ cộng tác phân tán thời gian thực và môi trường học từ xa.

Nguồn đầy đủ (nó rất lớn!) Được cung cấp. Nó thực hiện giao thức RTP .

Nghe có vẻ như video phát trực tiếp nhiều hơn truyền phát hình ảnh, như ai đó đề xuất. Nén JPEG / PNG không được nhắm mục tiêu cho các loại tốc độ này, vì vậy hãy quên chúng đi.

Hãy tưởng tượng có một codec ghi âm trên hệ thống của bạn có thể ghi lại luồng video đến (màn hình của bạn) theo thời gian thực. Một chút giống như Fraps có lẽ. Sau đó tưởng tượng một codec phát lại video ở phía bên kia (máy khách từ xa). Vì các đầu ghi HD có thể làm điều đó (ghi trực tiếp và thậm chí phát lại trực tiếp từ cùng một HD), cuối cùng bạn cũng nên như vậy. HD chắc chắn không thể cung cấp hình ảnh nhanh hơn bạn có thể đọc màn hình của mình, vì vậy đó không phải là nút cổ chai. Nút thắt là các codec video. Bạn sẽ thấy bộ mã hóa gặp nhiều vấn đề hơn bộ giải mã, vì tất cả các bộ giải mã hầu hết đều miễn phí.

Tôi không nói nó đơn giản; Bản thân tôi đã sử dụng DirectShow để mã hóa một tệp video và cho đến nay nó không phải là thời gian thực. Nhưng với codec đúng, tôi tin rằng nó có thể hoạt động.

Dự đoán ngẫu nhiên của tôi là: TV sử dụng codec x264 có giấy phép thương mại (nếu không TeamViewer sẽ phải phát hành mã nguồn của họ). Tại một số thời điểm (hơn 5 năm trước), tôi nhớ lại nhà phát triển chính của x264 đã viết một bài viết về các cải tiến mà anh ấy đã thực hiện để mã hóa độ trễ thấp (nếu bạn trì hoãn một vài bộ mã hóa khung hình có thể nén tốt hơn), ngoài ra anh ấy đã đề cập đến một số cải tiến khác có liên quan để sử dụng giống như TeamViewer. Trong bài đăng đó, ông đã đề cập đến việc chơi trận động đất qua luồng video mà không có vấn đề gì đáng chú ý. Trước đó tôi đã chắc chắn ai là nhà tài trợ cho những cải tiến này, vì TeamViewer là lựa chọn duy nhất vào thời điểm đó. x264 là một triển khai mã nguồn mở của video H264và nó thực hiện rất tốt, đó là cách tốt nhất. Đồng thời nó được tối ưu hóa cực kỳ tốt. Rất có thể do triển khai x264 cực kỳ tốt, bạn sẽ nhận được kết quả tốt hơn nhiều với TV ở mức tải CPU thấp hơn. AnyDesk và Chrome Remote Desk sử dụng libvpx, không tốt bằng x264 (tối ưu hóa và chất lượng video một cách khôn ngoan).

Tuy nhiên, tôi không nghĩ TeamView có thể đánh bại RDP của microsoft. Đối với tôi nó là tốt nhất, tuy nhiên nó chỉ hoạt động giữa các PC Windows hoặc từ Mac sang Windows. TV hoạt động ngay cả từ điện thoại di động.

Cập nhật: bài viết đã được viết vào tháng 1 năm 2010, vì vậy công việc đó đã được thực hiện khoảng 10 năm trước. Ngoài ra, tôi đã phạm một sai lầm: anh ấy chơi gọi nghĩa vụ, không phải trận động đất. Khi bạn đăng câu hỏi của mình, nếu suy đoán của tôi là chính xác, TeamViewer đã sử dụng công việc đó trong 3 năm. Đọc bài đăng trên blog từ kho lưu trữ web: x264: nền tảng phát video trực tuyến có độ trễ thấp tốt nhất trên thế giới . Khi tôi đọc bài báo trở lại vào năm 2010, tôi đã chắc chắn rằng "startup đã yêu cầu không được đặt tên" mà tác giả đề cập đến là TeamViewer.

Kì lạ nhưng theo kinh nghiệm của tôi, TeamViewer không nhanh hơn / phản ứng nhanh hơn VNC, chỉ dễ cài đặt hơn. Tôi có một vài win-box mà tôi VNC qua OpenVPN (vì vậy có một lớp trên cao khác) và đó là trên Cáp giá rẻ (512 trở lên) và tôi thấy cài đặt chặt chẽ củaVNVN sẽ phản ứng nhanh hơn nhiều so với TeamViewer cho cùng một boxen. RDP (tự nhiên) thậm chí còn nhiều hơn vì phần lớn nó gửi các lệnh vẽ GUI thay vì các lát bitmap.

Điều này đưa chúng ta đến:

1. Tại sao bạn không sử dụng VNC? Có rất nhiều giải pháp nguồn mở và chặt chẽ có lẽ là trên đầu trò chơi của nó ngay bây giờ.

2. Việc triển khai VNC nâng cao sử dụng nén mất dữ liệu và điều đó dường như đạt được kết quả tốt hơn so với lựa chọn PNG của bạn. Ngoài ra, IIRC phần còn lại của tải trọng cũng bị đè bẹp bằng zlib. Cả haijj chặt chẽ và UltraVNC có thuật toán rất tối ưu, đặc biệt là cho các cửa sổ. Trên hết, đó là nguồn mở.

3. Nếu win boxen là RDP mục tiêu chính của bạn có thể là một lựa chọn tốt hơn và có triển khai mã nguồn mở (rdesktop)

4. Nếu * nix boxen là mục tiêu chính NX của bạn có thể là một lựa chọn tốt hơn và có triển khai nguồn mở (FreeNX, mặc dù không được tối ưu hóa như sản phẩm độc quyền của NoMachine).

Nếu nén JPEG là một vấn đề về hiệu suất đối với thuật toán của bạn, tôi khá chắc chắn rằng so sánh hình ảnh vẫn sẽ lấy đi một số hiệu suất. Tôi cá là họ sử dụng nén trường hợp tốt nhất cho mọi tình huống cụ thể, ví dụ như mất cho các khung lớn, một số nội bộ nhanh và bẩn không thua đối với các ảnh nhỏ hơn, so sánh các bit của hình ảnh và chỉ gửi các loại khác nhau của các thủ thuật tối ưu hóa khác.

Và rất nhiều trong số những mánh khóe đó phải xuất hiện trong Chế độ chặt chẽ> 2.0 một lần nữa, theo kinh nghiệm của tôi, nó đánh bại được hiệu suất của TeamViewer, YMMV.

Ngoài ra, việc lựa chọn thời gian chạy được biên dịch JIT so với C ++ có thể mất một phần từ cạnh hiệu suất của bạn, đặc biệt là trong các máy bị hạn chế bộ nhớ (rất nhiều điều chỉnh hiệu năng đi vào nhà vệ sinh khi các cửa sổ bắt đầu sử dụng trang web đầy đủ). Và bạn sẽ cần bộ nhớ để giữ các trạng thái hình ảnh trước đó để so sánh bên trong trên đỉnh của những gì ảo ảnh DF mang lại cho bạn.