Bagaimana cara lebih baik menyalin & menempel file besar melalui RDP?

Baru-baru ini saya membuat beberapa upaya untuk menyalin & menempel file besar (1,2 GB) ke komputer jarak jauh melalui RDP. Komputer jarak jauh adalah mesin pengujian virtual dengan MS Windows Server 2008 Datacenter.

Pertama saya mencoba menyalin & menempel sebelum tengah malam ketika kecepatan transfer dibatasi oleh komputer klien ISP hingga 100 kB / s. Jadi, diperlukan beberapa jam dan saya terpaksa membatalkan transfer karena desktop jarak jauh menjadi terlalu responsif dan lamban (lambat). Jadi, saya memulai kembali pada tengah malam ketika kecepatan transfer lokal saya lebih dari 4MB / s.

Jadi, kesan saya adalah bahwa secara independen pada kecepatan (broadband) transfer copy & paste komputer remote menjadi lamban saat menyalin melalui RDP. Pada saat yang sama mengunduh dari internet tidak membuat host remote menjadi lamban.

AFAIU, itu karena clipboard dari komputer jarak jauh dan karena itu memorinya menjadi kelebihan muatan dengan transfer.
Bagaimana saya bisa mengontrol (membatasi) penggunaan clipboard untuk proses tertentu (menempelkan file)?

Apa cara yang mungkin untuk mengendalikannya?

Pembaruan:
Setelah membaca bahwa kecepatan transfer yang lambat disebabkan oleh enkripsi yang digunakan untuk menyalin & menempel pada RDP dan karena saya percaya saya lebih tertarik pada efisiensi keseluruhan: baik waktu, atau kecepatan, untuk mendapatkan file serta kemungkinan untuk bekerja tanpa menunggu, saya mengubah judul pertanyaan dari:

• Bagaimana cara mengontrol penggunaan penggunaan papan klip desktop jarak jauh untuk menempelkan file besar?

untuk

• Bagaimana cara lebih baik menyalin & menempel file besar melalui RDP?

Misalnya, apakah lebih baik untuk menyalin & menempel satu arsip besar (zip) atau unzip dan menyalin folder dengan file yang tidak di-zip?

Dan lebih tepatnya saya ingin bertanya:

• Apa cara yang mungkin untuk meningkatkan pengalaman secara keseluruhan:

  • kecepatan transfer (yaitu ketersediaan file yang diperlukan)
  • responsif dari host jarak jauh (membuat coputer jarak jauh tersedia untuk bekerja sebelum penyalinan & rekat)?

Ketika Anda mengatakan file Zip, apakah maksud Anda arsip yang tidak terkompresi dengan ukuran yang sama dengan semua file individu? Atau maksud Anda arsip terkompresi? Karena di sana, jika Anda berbicara tentang arsip terkompresi, Anda akan memiliki transfer yang lebih cepat, yang sebenarnya akan lebih baik. Tentu saja, jika Anda memperhitungkan jumlah waktu yang dibutuhkan untuk membuat arsip, dan berapa lama waktu yang diperlukan untuk mengekstrak arsip, maka spesifikasi dari kedua mesin mulai bermain apakah arsip lebih baik daripada file yang longgar.

Sekarang, karena Anda berbicara tentang RDP (berlawanan dengan VNC), penggunaan bandwidth dari koneksi jarak jauh cukup sedikit. RDP lebih responsif daripada VNC, kedalaman warna (secara default) lebih dari 256 warna (32 bit jika Anda tidak mengubahnya), ukuran layar akan menjadi ukuran desktop Anda, dll ... semua faktor ini mempengaruhi berapa banyak bandwidth yang digunakan hanya untuk koneksi jarak jauh. Jika Anda menjatuhkan hal-hal seperti ... ukuran desktop jarak jauh, dan kedalaman warna hingga 16 bit atau kurang, pastikan Anda tidak berbagi suara, dll ... ini akan menggunakan lebih sedikit bandwidth untuk koneksi jarak jauh, sehingga ketika Anda mentransfer file, sesi jarak jauh harus lebih responsif.

Pada akhirnya, kecuali Anda dapat membatasi transfer file, sesi jarak jauh akan menjadi lamban, apa pun yang Anda lakukan saat Anda mentransfer file, karena sebanyak mungkin bandwidth yang tersedia akan digunakan untuk transfer antar mesin jarak jauh dan mesin Anda.

EDIT

Anda berusaha menemukan cara sederhana untuk mentransfer file TANPA mempengaruhi kualitas koneksi jarak jauh. Tidak masalah apakah itu file besar atau file kecil. Di ujung Anda (mesin klien) Anda menyemprotkan sejumlah kecil data hingga mesin jarak jauh (mesin server). Anda tahu ... mengetik, perintah mouse, dll. Server mengirimkan data dalam jumlah besar kepada Anda sepanjang waktu, dalam bentuk gambar yang membentuk apa yang Anda lihat di koneksi jarak jauh. Jadi, sebelum Anda mentransfer file apa pun, Anda SUDAH mentransfer sejumlah besar data dalam satu arah. Itu sebabnya saya mengemukakan hal-hal yang dapat Anda lakukan untuk mengurangi jumlah data yang Anda kirimkan .... yaitu menggunakan resolusi yang lebih kecil untuk mesin jarak jauh di desktop Anda (sebagai lawan dari layar penuh) .... mengurangi jumlah warna dari 32 bit menjadi 16 bit atau bahkan 8 bit. Kedua langkah di sana akan menjatuhkan jumlah data yang Anda kirimkan dari server (jarak jauh) ke klien (Anda). Ini juga berarti bahwa ketika Anda mulai mentransfer file di sepanjang koneksi dan rute yang sama, koneksi jarak jauh Anda akan berkurang.

Seperti yang saya katakan ... tidak ada yang dapat Anda lakukan akan membuat koneksi tetap jernih dan responsif. Mengapa? Karena segera setelah Anda mulai mentransfer file dari server ke klien, ini akan menyedot setiap bit bandwidth yang tersedia di sepanjang pipa itu .... dan Anda sudah menggunakan beberapa bandwidth di sepanjang pipa itu untuk remote koneksi itu sendiri.

Pertama saya mencoba menyalin & menempel sebelum tengah malam ketika kecepatan transfer dibatasi oleh komputer klien ISP hingga 100 kB / s. Jadi, diperlukan beberapa jam dan saya terpaksa membatalkan transfer karena desktop jarak jauh menjadi terlalu responsif dan lamban (lambat). Jadi, saya memulai kembali pada tengah malam ketika kecepatan transfer lokal saya lebih dari 4 GB / s

Jadi ketika Anda pertama kali mencoba transfer, Anda memiliki koneksi unduhan 100kb / s. Anda memindahkan 1.2gb file secepat mungkin, yang akan mendorong untuk memakan sebanyak 100kb / s sebanyak mungkin. Yang akan meninggalkan ruang apa untuk data yang mendukung koneksi desktop jarak jauh? Jadi, tentu saja akan lamban dan tidak responsif. Satu-satunya hal yang tidak Anda perhitungkan, adalah kecepatan server UPLOAD. Jika kecepatan unggah server kurang dari kecepatan unduhan Anda ... dan dalam hipotesis sempurna ini, rute antara server dan Anda mengizinkan kecepatan unggah ini tetap konstan, segera setelah Anda mulai mentransfer file, hampir semua bandwidth yang akan dimakan oleh transfer file, yang akan membuat koneksi remote menderita.

Mengapa?

Karena tidak ada yang memperlambat transfer file ke kecepatan tertentu, atau persentase bandwidth yang tersedia, itu akan berusaha untuk menggunakan setiap kb / s yang dapat dilakukannya. Secara alami, ini akan membuat koneksi jarak jauh menderita.

Bahkan mentransfer file dari server ke pihak ketiga (seperti server FTP di suatu tempat) akan membuat koneksi lambat selama transfer itu, karena sekali lagi, sebanyak mungkin bandwidth yang tersedia akan dialokasikan untuk transfer itu. Namun begitu transfer dilakukan, Anda dapat mengunduhnya dari server FTP tanpa efek pada responsif dari koneksi jarak jauh ... sekali lagi karena pipa masuk Anda setelah tengah malam jauh lebih besar daripada pipa keluar server.

Jadi, saya akan mencoba mengurangi kualitas koneksi jarak jauh.

Ada opsi RDP yang membuat tautan ke drive lokal Anda di komputer jarak jauh. Untuk mengaktifkannya, mulai klien RDP, klik (Tampilkan) Opsi , → buka tab " Sumber Daya Lokal ". → klik " Lainnya " → centang kotak " Drive ".

Setelah Anda terhubung, buka Windows Explorer pada sistem jarak jauh. Drive lokal Anda akan muncul di bagian bawah daftar drive di My Computer. Itu muncul sebagai "C on your_computer_name".

Anda sekarang dapat Seret dan Jatuhkan file dari satu sistem ke sistem lainnya.

Saya menggunakan robocopy di kotak windows 7 saya, menggunakan nama unc \\ tsclient.

Seperti yang disarankan dalam jawabannya oleh @Tom, lebih baik untuk D&D file daripada C & Ping mereka. Ini memiliki manfaat tambahan untuk menghindari bug yang mengganggu transfer file jika Anda gunakan Ctrl+Cpada mesin klien.

Saya pikir tidak satu pun dari jawaban ini yang menjawab pertanyaan dengan sangat baik.

Microsoft RDP adalah protokol yang tidak dioptimalkan dengan sangat baik untuk transfer file. Jika koneksi Anda agak lambat, perpindahan bit file, yang berjalan di atas pipa jaringan yang sama dengan paket-paket UI seperti layar menarik dan gerakan mouse, dapat menyebabkan salah satu dari hal-hal ini habis; dan kemudian, server akan menganggap Anda telah kehilangan koneksi dan akan memutuskan Anda, memutuskan saluran IO Anda. Ini tentu saja membuat masalahnya menjadi lebih buruk.

Terutama, Anda harus mempertimbangkan alur kerja Anda dan melihat apakah Anda memiliki cara yang lebih mudah untuk memindahkan file melalui saluran lain (seperti melalui internet ke server Anda daripada dari workstation Anda) yang tidak melanggar kebijakan keamanan Anda.

Jika Anda memutuskan bahwa Anda harus menggunakan saluran salin file RDP, maka ikuti panduan ini yang bekerja dengan sangat baik untuk saya.

• Jangan mengakses file besar secara langsung melalui jalur UNC ke klien. Misalnya, mengaktifkan folder bersama dan mengakses file dari \ TSCLIENT \ share. Ini mendorong konten file besar di atas pipa multi guna kecil.
• Anda akan mendapatkan sedikit optimisasi dan stabilitas dengan memetakan drive. Misalnya, NET USE X: \ TSCLIENT \ Bagikan akan memetakan drive X: ke lokasi di atas. Namun, kelebihan pipa jaringan akan memutus koneksi Anda dan memutus pemetaan drive Anda juga.
• Yang paling penting, ketika memulai klien RDP, pilih pengaturan bandwidth jaringan "Modem" atau "Lambat". Ini akan jauh lebih baik mengoptimalkan transfer file dan saluran suara, sehingga mereka tidak dapat mengalahkan sisa pipa yang digunakan untuk kontrol UI.
• Pada klien OS X Microsoft Remote Desktop, pengaturan ini anehnya tidak tersedia. Dalam hal ini, instal MacPorts dan jalankan sudo port install rdesktop dan kemudian Anda dapat terhubung dengan rdesktop dan pengaturan -xm (setel level "experience" ke "modem atau 28.8K")
• Jika Anda mengikuti rekomendasi di atas, Anda sekarang akan memiliki koneksi yang dioptimalkan untuk stabilitas dan mendorong file besar tidak akan memutuskan Anda. Sekarang, gunakan cara yang lebih terkontrol untuk menyalin file daripada menyalin / menempel atau drag-and-drop: misalnya, coba ** XCOPY X: *. Msi C: \ Install ** untuk menyalin item yang cocok dengan pola nama file ke dalam yang ditentukan direktori lokal (server).

Saya harap seseorang menemukan saran ini bermanfaat. Mereka pasti bekerja untuk saya.

Melihat http://www.bittorrent.com/sync/download

Tumpukan ini lebih cepat dan tidak memerlukan sesi RDP terbuka saat salinan selesai.

Itu juga tidak mengharuskan Anda untuk memiliki akses ke jalur UNC seperti saran di atas.

Tepuk tangan

Saya sudah mulai menggunakan layanan transfer file berbasis webRTC berbasis web untuk hal semacam ini - Saya saat ini menggunakan http://dragshare.com dengan hasil yang baik (masih dalam versi beta).

Salin dan tempel RDP selalu menyusahkan bagi saya - ini sangat lambat, dan jika Anda memiliki ribuan file, prosesnya menjadi lebih lambat. Ini juga memiliki batas ukuran file maks (yang tidak memperingatkan Anda tentang itu, itu hanya gagal setelah mencoba melampauinya). WebRTC tampaknya jauh lebih cepat daripada yang pernah ditunjukkan RDP kepada saya.