Як краще скопіювати та вставити великі файли через RDP?

Нещодавно я робив кілька спроб скопіювати та вставити великий файл (1,2 ГБ) на віддалений комп'ютер через RDP. Віддалений комп'ютер - це віртуальна тестова машина з MS Windows Server 2008 Datacenter.

Спочатку я спробував скопіювати та вставити до півночі, коли швидкість передачі була обмежена провайдером клієнтського комп'ютера до 100 кБ / с. Отже, на це знадобилося кілька годин, і я був змушений скасувати передачу, оскільки віддалений робочий стіл став занадто невідповідним і млявим (повільним). Отже, я знову запустив її опівночі, коли моя локальна швидкість передачі перевищує 4 Мб / с.

Отже, моє враження таке, що незалежно від швидкості (широкосмугового) передачі копій та вставки віддалений комп'ютер стає млявим під час копіювання через RDP. У той же час завантаження з Інтернету не робить віддаленого хоста млявим.

AFAIU, це тому, що буфер обміну віддаленого комп'ютера і тому його пам'ять перевантажується передачею.
Як я можу контролювати (обмежувати) використання буфера обміну для певного процесу (вставлення файлу)?

Який можливий спосіб контролювати це?

Оновлення:
Прочитавши, що повільна швидкість передачі викликається шифруванням, яке використовується для копіювання та вставки через RDP, і оскільки я вважаю, що мене більше цікавить загальна ефективність: як час, так і швидкість отримання файлу, а також можливість працювати без очікування, я змінив назву питання з:

• Як контролювати використання віддаленого буфера обміну для робочого столу для вставки великого файлу?

до

• Як краще скопіювати та вставити великі файли через RDP?

Наприклад, чи краще скопіювати та вставити один величезний (zip) архів або розпакувати його та скопіювати вставити папку з розпакованими файлами?

І точніше я хотів запитати:

• Які можливі способи покращити загальний досвід:

  • швидкість передачі (тобто наявність необхідного файлу)
  • чуйність віддаленого хоста (надання віддаленого комп'ютера доступним для роботи до завершення копіювання та вставки)?

Коли ви говорите Zip-файл, ви маєте на увазі нестиснений архів, який би був такого ж розміру, як і всі окремі файли? Або ви маєте на увазі стислий архів? Тому що саме там, якщо ви говорите про стиснутий архів, ви мали би швидший переказ, який строго кажучи було б краще. Звичайно, якщо ви враховуєте кількість часу, необхідного для створення архіву, і скільки часу потрібно для його вилучення, то специфікації обох машин вступають у гру щодо того, чи краще архів, ніж вільні файли.

Тепер, оскільки ви говорите про RDP (на відміну від VNC), використання пропускної здатності віддаленого з'єднання зовсім небагато. RDP чутливіший ніж VNC, глибина кольору (за замовчуванням) перевищує 256 кольорів (32 біт, якщо ви не змінюєте), розмір екрана буде розміром вашого робочого столу тощо ... всі ці фактори впливають на величину пропускної здатності, яка використовується лише для віддаленого з'єднання. Якщо ви кинете такі речі, як ... розмір віддаленого робочого столу та глибина кольору до 16 біт або менше, переконайтеся, що ви не ділите звук тощо ... це дозволить використовувати меншу пропускну здатність для віддаленого з'єднання, так що коли ви передаєте файли, віддалений сеанс повинен бути більш чуйним.

Зрештою, якщо ви не зможете перешкодити передачі файлів, віддалений сеанс стане млявим, незалежно від того, що ви робите під час передачі файлів, оскільки для передачі між ними буде використовуватися якомога більша кількість доступної пропускної здатності. віддалену машину та вашу машину.

EDIT

Ви намагаєтеся знайти простий спосіб передачі файлів БЕЗ, що впливає на якість віддаленого з'єднання. Не має значення, великі вони чи невеликі файли. В кінці (клієнтська машина) ви збираєте невеликі обсяги даних до віддаленої машини (серверної машини). Ви знаєте ... введення тексту, команди миші тощо. Сервер постійно надсилає вам велику кількість даних у вигляді зображень, що створюють те, що ви бачите через віддалене з'єднання. Отже, перед тим, як передати будь-які файли, ВЖЕ МАЄТЕ передати велику кількість даних в одному напрямку. Ось чому я підказав те, що ви могли зробити, щоб зменшити кількість даних, які ви передаєте .... а саме використовувати меншу роздільну здатність для віддаленої машини на робочому столі (на відміну від повноекранного) .... зменшення кількості кольорів з 32 біт до 16 біт або навіть 8 біт. Ці два кроки прямо там зменшать кількість даних, які ви передаєте з сервера (віддаленого) клієнту (вам). Це також означає, що коли ви почнете передавати файли по одному і тому ж з'єднанню і маршруту, ваше віддалене з'єднання постраждає менше.

Як я вже сказав, ніщо, що ви можете зробити, зробить зв’язок чітким та чутливим. Чому? Тому що, як тільки ви починаєте передавати файли з сервера на клієнта, це буде висмоктувати кожен шматочок пропускної здатності, який є доступним уздовж цієї труби .... і ви вже використовуєте частину пропускної здатності вздовж цієї труби для віддаленого сам зв’язок.

Спочатку я спробував скопіювати та вставити до півночі, коли швидкість передачі була обмежена провайдером клієнтського комп'ютера до 100 кБ / с. Отже, на це знадобилося кілька годин, і я був змушений скасувати передачу, оскільки віддалений робочий стіл став занадто невідповідним і млявим (повільним). Отже, я знову запустив її опівночі, коли моя локальна швидкість передачі перевищує 4 Гб / с

Отже, коли ви вперше спробували передачу, у вас було з'єднання для завантаження 100 кбіт / с. Ви переміщували 1,2 Гб файлів якомога швидше, що підштовхнуло б з'їсти стільки 100 кбіт / с, наскільки це можливо. Що б залишити то , що місця для даних , що підтримують підключення до віддаленого робочого стола? Тож, звичайно, це було б мляво і безвідповідально. Єдине, що ви також не враховуєте, це швидкість завантаження сервера. Якщо швидкість завантаження сервера менша за швидкість завантаження ... і в цій ідеальній гіпотетиці маршрут між сервером і вами дозволив, щоб ця швидкість завантаження залишалася постійною, як тільки ви почнете передавати файли, майже про всі цієї пропускної здатності буде з'їдено передачею файлів, через що віддалене з'єднання постраждає.

Чому?

Оскільки немає нічого, що перешкоджає передачі файлів із певною швидкістю або відсотком доступної пропускної здатності, він намагатиметься використовувати кожен кбіт / с, який може. За характером речей це спричинить страждання віддаленого зв'язку.

Навіть передача файлів із сервера третій стороні (як-от FTP-сервер десь) зробить з'єднання млявим під час цієї передачі, оскільки знову ж таки максимальна кількість доступної пропускної здатності буде виділена на цю передачу. Після того як ця передача була здійснена, ви зможете завантажити її з FTP-сервера, не впливаючи на чутливість віддаленого з'єднання ... знову ж таки тому, що ваша вхідна труба після півночі набагато більша, ніж вихідна труба сервера.

Отже, я б спробував знизити якість віддаленого з'єднання.

Існує параметр RDP, який створює посилання на ваш локальний диск на віддаленому комп'ютері. Щоб увімкнути це, запустіть клієнт RDP, натисніть (Показати) Параметри , → відкрийте вкладку « Локальні ресурси ». → натисніть " Детальніше " → поставте галочку " Диски ".

Після підключення відкрийте Провідник Windows у віддаленій системі. Ваш локальний диск повинен з’являтися внизу списку дисків у розділі Мій комп'ютер. Він відображається як "C на вашому імені_комп'ютера".

Тепер ви можете перетягувати файли з однієї системи в іншу.

Я використовую робокопію на своєму вікні Windows 7, використовуючи unc ім'я \\ tsclient.

Як запропоновано у своїй відповіді від @Tom, файли бажано розробити, а не C & Ping. Це має додаткову перевагу в обході помилки, яка перериває передачу файлів, якщо ви використовуєте Ctrl+Cна клієнтській машині.

Я думаю, що жодна з цих відповідей насправді не дуже добре вирішує це питання.

Microsoft RDP - це протокол, який не дуже добре оптимізований для передачі файлів. Якщо ваш зв’язок відбувається трохи повільно, переміщення бітів файлів, які пересуваються через ту саму мережеву трубу, що і пакети інтерфейсу користувача, як малювання екрана та рух миші, може спричинити затримку однієї з цих речей; і тоді сервер припустить, що ви втратили зв’язок, і відключить вас, порушивши ваші канали вводу-виводу. Це, звичайно, погіршує проблему.

Перш за все, слід розглянути свій робочий процес і побачити, чи є у вас більш простий спосіб переміщення файлів через інший канал (наприклад, через Інтернет на ваш сервер замість робочої станції), який не порушує вашу політику безпеки.

Якщо ви вирішили скористатися каналом копіювання файлів RDP, то дотримуйтесь цих вказівок, які для мене працюють добре.

• Не отримуйте доступу до великих файлів безпосередньо через UNC шлях до клієнта. Наприклад, ввімкнення спільних папок та доступ до файлу з \ TSCLIENT \ share. Це натискає великий вміст файлу на малій багатокористувацькій трубці.
• Ви отримаєте невелику оптимізацію та стабільність, зіставивши привід. Наприклад, NET USE X: \ TSCLIENT \ Share відобразить диск X: у вказане вище місце. Тим не менш, перевантаження мережевих труб відключить вас і відключить відображення вашого приводу.
• Найголовніше, що при запуску клієнта RDP вибирайте мережеву пропускну здатність «Модем» або «Повільний». Це значно покращить оптимізацію передачі файлів та звукових каналів, так що вони не зможуть заграти решту труби, що використовується для управління користувальницьким інтерфейсом.
• Для клієнта віддаленого робочого столу Microsoft X X цей параметр дивно недоступний. У цьому випадку встановіть MacPorts і запустіть порт sudo, встановіть rdesktop, і тоді ви зможете підключитися за допомогою rdesktop та налаштування -xm (встановіть рівень "досвід" на "модем або 28,8 К ")
• Якщо ви будете дотримуватися вищезазначених рекомендацій, тепер у вас буде з'єднання, оптимізоване для стабільності, і натискання великих файлів не відключить вас. Тепер скористайтеся більш контрольованим способом копіювання файлів, ніж копіювання / вставка або перетягування: наприклад, спробуйте ** XCOPY X: *. Msi C: \ Install **, щоб скопіювати елементи, що відповідають шаблону імені файлу, у вказаний локальний (серверний) каталог.

Сподіваюся, хтось вважає ці пропозиції корисними. Вони, безумовно, працюють на мене.

Погляньте на http://www.bittorrent.com/sync/download

Це накопичується швидше і не вимагає відкриття сеансу RDP, коли копія завершується.

Він також не вимагає від вас доступу до шляху UNC, як описано вище.

Ура

Я почав користуватися послугами передачі файлів на базі браузера WebRTC для подібних речей - наразі використовую http://dragshare.com з хорошими результатами (все ще в бета-версії).

Копіювання та вставлення RDP завжди було болем для мене - це дуже повільно, і якщо у вас є тисячі файлів, це стає ще повільніше. У нього також є максимальний розмір файлу (про який він не попереджає, він просто не працює після спроби перевищити його). Здається, WebRTC є набагато швидшим, ніж все, що мені показав RDP.