Làm cách nào để sao chép và dán các tệp lớn hơn RDP?

Gần đây tôi đã thực hiện một vài nỗ lực để sao chép và dán một tệp lớn (1,2 GB) vào máy tính từ xa qua RDP. Máy tính từ xa là máy kiểm tra ảo với MS Windows Server 2008 Datacenter.

Đầu tiên tôi cố gắng sao chép và dán trước nửa đêm khi tốc độ truyền bị giới hạn bởi ISP máy tính khách đến 100 kB / s. Vì vậy, nó cần một vài giờ và tôi buộc phải hủy chuyển vì máy tính để bàn từ xa trở nên quá không phản hồi và chậm chạp (chậm). Vì vậy, tôi đã khởi động lại nó hơn nửa đêm khi tốc độ chuyển cục bộ của tôi là hơn 4MB / s.

Vì vậy, ấn tượng của tôi là độc lập về tốc độ (băng thông rộng) của sao chép và dán chuyển máy tính từ xa trở nên chậm chạp trong khi sao chép qua RDP. Đồng thời tải xuống từ internet không làm cho máy chủ từ xa chậm chạp.

AFAIU, đó là do clipboard của máy tính từ xa và do đó bộ nhớ của nó bị quá tải khi truyền.
Làm cách nào tôi có thể kiểm soát (hạn chế) việc sử dụng clipboard cho quy trình cụ thể (dán tệp)?

Cách có thể để kiểm soát nó là gì?

Cập nhật:
Sau khi đọc rằng tốc độ truyền chậm là do mã hóa được sử dụng để sao chép và dán qua RDP và vì tôi tin rằng tôi quan tâm nhiều hơn đến hiệu quả tổng thể: cả thời gian, hoặc sự nhanh chóng, về việc nhận tệp cũng như khả năng hoạt động mà không phải chờ đợi, tôi đã thay đổi tiêu đề câu hỏi từ:

• Làm cách nào để kiểm soát việc sử dụng clipboard của máy tính để bàn từ xa để dán một tệp lớn?

đến

• Làm cách nào để sao chép và dán các tệp lớn hơn RDP?

Ví dụ, tốt hơn là sao chép và dán một kho lưu trữ (zip) khổng lồ hoặc giải nén nó và sao chép dán một thư mục với các tệp được giải nén?

Và chính xác hơn tôi muốn hỏi:

• Những cách có thể để cải thiện trải nghiệm tổng thể là gì:

  • tốc độ chuyển (tức là có sẵn tệp cần thiết)
  • khả năng đáp ứng của máy chủ từ xa (làm cho máy photocopy từ xa có sẵn cho công việc trước khi hoàn thành sao chép và dán)?

Khi bạn nói một tệp Zip, bạn có nghĩa là một kho lưu trữ không nén có cùng kích thước với tất cả các tệp riêng lẻ? Hay bạn có nghĩa là một kho lưu trữ nén? Bởi vì ngay tại đó, nếu bạn đang nói về một kho lưu trữ nén, bạn sẽ chuyển khoản nhanh hơn, nói đúng ra sẽ tốt hơn. Tất nhiên, nếu bạn tính đến lượng thời gian cần thiết để lưu trữ và mất bao lâu để trích xuất kho lưu trữ, thì thông số kỹ thuật của cả hai máy sẽ phát huy xem liệu kho lưu trữ có tốt hơn các tệp lỏng lẻo hay không.

Bây giờ, vì bạn đang nói về RDP (trái ngược với VNC), việc sử dụng băng thông của kết nối từ xa là khá ít. RDP phản ứng nhanh hơn VNC, độ sâu màu (theo mặc định) hơn 256 màu (32 bit nếu bạn không thay đổi), kích thước màn hình sẽ là kích thước của máy tính để bàn của bạn, v.v ... tất cả các yếu tố này ảnh hưởng đến bao nhiêu băng thông đang được sử dụng chỉ cho kết nối từ xa. Nếu bạn bỏ những thứ như ... kích thước của máy tính để bàn từ xa và độ sâu màu xuống 16 bit trở xuống, hãy đảm bảo bạn không chia sẻ âm thanh, v.v ... điều này sẽ sử dụng ít băng thông hơn cho kết nối từ xa, để khi bạn đang chuyển tập tin, phiên từ xa sẽ phản ứng nhanh hơn.

Tuy nhiên, cuối cùng, trừ khi bạn có thể điều tiết việc truyền tệp, phiên từ xa sẽ chậm chạp bất kể bạn làm gì trong khi bạn đang truyền tệp, vì càng nhiều băng thông có sẵn sẽ được sử dụng để chuyển giữa máy từ xa và máy của bạn.

CHỈNH SỬA

Bạn đang cố gắng tìm một cách đơn giản để truyền tệp mà KHÔNG ảnh hưởng đến chất lượng của kết nối từ xa. Không thành vấn đề nếu chúng là tệp lớn hoặc tệp nhỏ. Cuối cùng (máy khách), bạn sẽ tiết ra một lượng nhỏ dữ liệu cho máy từ xa (máy chủ). Bạn biết ... gõ, lệnh chuột, v.v. Máy chủ đang gửi một lượng lớn dữ liệu cho bạn mọi lúc, dưới dạng hình ảnh tạo nên những gì bạn nhìn thấy qua kết nối từ xa. Vì vậy, trước khi bạn chuyển bất kỳ tệp nào, bạn C ALNG chuyển một lượng lớn dữ liệu theo một hướng. Đó là lý do tại sao tôi đưa ra những điều bạn có thể làm để giảm lượng dữ liệu bạn đang truyền .... cụ thể là sử dụng độ phân giải nhỏ hơn cho máy từ xa trên máy tính để bàn của bạn (trái ngược với toàn màn hình) .... giảm số lượng màu từ 32 bit xuống 16 bit hoặc thậm chí 8 bit. Hai bước ngay tại đó sẽ giảm lượng dữ liệu bạn đang truyền từ máy chủ (từ xa) đến máy khách (bạn). Điều đó cũng có nghĩa là khi bạn bắt đầu chuyển các tệp cùng một kết nối và tuyến đường, kết nối từ xa của bạn sẽ bị ảnh hưởng ít hơn.

Như tôi đã nói ... không có gì bạn có thể làm sẽ khiến kết nối trở nên rõ ràng và phản hồi nhanh. Tại sao? Bởi vì ngay khi bạn bắt đầu chuyển các tập tin từ máy chủ sang máy khách, điều này sẽ hút mọi bit băng thông có sẵn dọc theo đường ống đó .... và bạn đã sử dụng một số băng thông dọc theo đường ống đó cho điều khiển từ xa kết nối chính nó.

Đầu tiên tôi cố gắng sao chép và dán trước nửa đêm khi tốc độ truyền bị giới hạn bởi ISP máy tính khách đến 100 kB / s. Vì vậy, nó cần một vài giờ và tôi buộc phải hủy chuyển vì máy tính để bàn từ xa trở nên quá không phản hồi và chậm chạp (chậm). Vì vậy, tôi đã khởi động lại nó hơn nửa đêm khi tốc độ chuyển cục bộ của tôi là hơn 4 GB / s

Vì vậy, khi bạn lần đầu thử chuyển khoản, bạn đã có kết nối tải xuống 100kb / s. Bạn đã di chuyển 1,2gb tệp càng nhanh càng tốt, điều này sẽ thúc đẩy ăn hết 100kb / giây đó. Điều gì sẽ để lại chỗ cho dữ liệu hỗ trợ kết nối máy tính từ xa? Vì vậy, tất nhiên nó sẽ chậm chạp và không phản hồi. Điều duy nhất bạn không tính đến, đó là tốc độ UPLOAD của máy chủ. Nếu tốc độ tải lên của máy chủ thấp hơn tốc độ tải xuống của bạn ... và trong giả thuyết hoàn hảo này, tuyến đường giữa máy chủ và bạn cho phép tốc độ tải lên này không đổi, ngay khi bạn bắt đầu chuyển các tệp, chỉ là về tất cả băng thông đó sẽ bị ăn mòn bởi việc truyền tệp, điều này sẽ khiến kết nối từ xa bị ảnh hưởng.

Tại sao?

Bởi vì không có gì điều chỉnh việc truyền tệp đến một tốc độ cụ thể, hoặc một tỷ lệ phần trăm của băng thông có sẵn, nên nó sẽ cố gắng sử dụng mọi kb / s có thể. Theo bản chất của sự vật, điều này sẽ làm cho kết nối từ xa bị ảnh hưởng.

Ngay cả việc chuyển các tệp từ máy chủ sang bên thứ ba (như máy chủ FTP ở đâu đó) sẽ khiến kết nối chậm chạp trong quá trình chuyển đó, bởi vì một lần nữa, càng nhiều băng thông khả dụng càng tốt sẽ được phân bổ cho chuyển đó. Tuy nhiên, khi quá trình chuyển đó được thực hiện, bạn sẽ có thể tải xuống từ máy chủ FTP mà không ảnh hưởng đến khả năng phản hồi của kết nối từ xa ... bởi vì đường ống đến sau nửa đêm của bạn lớn hơn nhiều so với đường ống đi của máy chủ.

Vì vậy, tôi sẽ thử giảm chất lượng của kết nối từ xa.

Có một tùy chọn RDP tạo liên kết đến ổ đĩa cục bộ của bạn trên máy tính từ xa. Để bật nó, hãy khởi động ứng dụng khách RDP, nhấp vào (Hiển thị) Tùy chọn , → mở tab " Tài nguyên cục bộ ". → nhấp vào " Khác " → đánh dấu vào hộp kiểm " Ổ đĩa ".

Sau khi bạn kết nối, hãy mở Windows Explorer trên hệ thống từ xa. Ổ đĩa cục bộ của bạn sẽ xuất hiện ở cuối danh sách ổ đĩa trong Máy tính của tôi. Nó hiển thị là "C trên your_computer_name".

Bây giờ bạn có thể Kéo và thả tệp từ hệ thống này sang hệ thống khác.

Tôi sử dụng robocopy trên hộp windows 7 của mình, sử dụng tên không tên \ tsclient.

Như được đề xuất trong câu trả lời của anh ấy bởi @Tom, tốt hơn là D & D các tệp thay vì C & Ping chúng. Điều này có thêm lợi ích là tránh một lỗi làm gián đoạn quá trình truyền tệp nếu bạn sử dụng Ctrl+Ctrên máy khách.

Tôi nghĩ rằng không có câu trả lời nào thực sự giải quyết câu hỏi rất tốt.

Microsoft RDP là một giao thức không thực sự được tối ưu hóa tốt cho việc truyền tệp. Nếu kết nối của bạn chậm một chút, việc di chuyển các bit tệp, di chuyển trên cùng một đường ống mạng như các gói UI như màn hình vẽ và di chuyển chuột, có thể khiến một trong những điều này bị hết thời gian; và sau đó, máy chủ sẽ cho rằng bạn đã mất kết nối và sẽ ngắt kết nối với bạn, phá vỡ các kênh IO của bạn. Điều này tất nhiên làm cho vấn đề tồi tệ hơn.

Về cơ bản, bạn nên xem xét quy trình làm việc của mình và xem liệu bạn có cách nào dễ dàng hơn để di chuyển các tệp qua kênh khác (như qua internet đến máy chủ của bạn thay vì từ máy trạm của bạn) không vi phạm chính sách bảo mật của bạn.

Nếu bạn quyết định rằng bạn phải sử dụng kênh sao chép tệp RDP, thì hãy làm theo các hướng dẫn này phù hợp với tôi.

• Không truy cập các tệp lớn trực tiếp qua đường dẫn UNC đến máy khách. Ví dụ: kích hoạt các thư mục được chia sẻ và truy cập tệp từ \ TSCLIENT \ share. Điều này đẩy nội dung tệp lớn qua ống đa dụng nhỏ.
• Bạn sẽ đạt được một chút tối ưu và ổn định bằng cách ánh xạ một ổ đĩa. Chẳng hạn, NET USE X: \ TSCLIENT \ Share sẽ ánh xạ ổ X: đến vị trí trên. Tuy nhiên, quá tải các đường ống mạng sẽ ngắt kết nối bạn và ngắt kết nối ánh xạ ổ đĩa của bạn.
• Quan trọng nhất, khi khởi động máy khách RDP, chọn cài đặt băng thông mạng "Modem" hoặc "Chậm". Điều này sẽ tối ưu hóa tốt hơn nhiều cho việc truyền tệp và các kênh âm thanh, do đó chúng không thể chặn phần còn lại của đường ống được sử dụng cho điều khiển UI.
• Trên máy khách OS X Microsoft Remote Desktop, cài đặt này không có sẵn. Trong trường hợp này, cài đặt MacPorts và chạy sudo port cài đặt rdesktop và sau đó bạn có thể kết nối với rdesktop và cài đặt -xm (đặt mức "kinh nghiệm" thành "modem hoặc 28.8K")
• Nếu bạn làm theo các khuyến nghị ở trên, giờ đây bạn sẽ có một kết nối được tối ưu hóa cho sự ổn định và việc đẩy các tệp lớn sẽ không ngắt kết nối với bạn. Bây giờ, sử dụng một cách được kiểm soát nhiều hơn để sao chép các tệp hơn là sao chép / dán hoặc kéo và thả: ví dụ: thử ** XCOPY X: *. Msi C: \ Install ** để sao chép các mục khớp với mẫu tên tệp vào mẫu đã chỉ định thư mục cục bộ (máy chủ).

Tôi hy vọng ai đó tìm thấy những gợi ý này hữu ích. Họ chắc chắn làm việc cho tôi.

Hãy xem http://www.bittorrent.com/sync/doad

Đây là đống nhanh hơn và không yêu cầu phiên RDP mở trong khi bản sao đang hoàn tất.

Nó cũng không yêu cầu bạn có quyền truy cập vào đường dẫn UNC như các đề xuất ở trên.

Chúc mừng

Tôi đã bắt đầu sử dụng các dịch vụ chuyển tệp dựa trên WebRTC dựa trên trình duyệt cho loại điều này - Tôi hiện đang sử dụng http://dragshare.com với kết quả tốt (vẫn đang trong giai đoạn thử nghiệm).

Sao chép và dán RDP luôn là một nỗi đau đối với tôi - nó rất chậm và nếu bạn có hàng ngàn tệp, nó thậm chí còn chậm hơn. Nó cũng có giới hạn kích thước tệp tối đa (điều này không cảnh báo bạn, nó chỉ thất bại sau khi cố gắng vượt quá nó). WebRTC dường như nhanh hơn bất cứ thứ gì RDP từng cho tôi thấy.