Как лучше копировать и вставлять большие файлы через RDP?

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

Сначала я пытался копировать и вставлять до полуночи, когда скорость передачи данных была ограничена ISP клиентского компьютера до 100 кБ / с. Итак, это заняло несколько часов, и я был вынужден отменить передачу, так как удаленный рабочий стол стал слишком не отвечающим и вялым (медленным). Итак, я перезапустил его в полночь, когда скорость локальной передачи превысила 4 МБ / с.

Итак, у меня сложилось впечатление, что независимо от скорости (широкополосного) копирования и вставки удаленный компьютер становится медленным при копировании через RDP. В то же время загрузка из Интернета не делает вялым удаленный хост.

AFAIU, это потому, что буфер обмена удаленного компьютера и, следовательно, его память перегружаются при передаче.
Как я могу контролировать (ограничивать) использование буфера обмена для конкретного процесса (вставка файла)?

Каковы возможные способы контроля?

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

• Как контролировать использование буфера обмена удаленного рабочего стола для вставки большого файла?

в

• Как лучше копировать и вставлять большие файлы через RDP?

Например, лучше ли скопировать и вставить один огромный (zip) архив или разархивировать его и скопировать и вставить папку с разархивированными файлами?

А точнее я хотел спросить:

• Каковы возможные способы улучшения общего опыта:

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

Когда вы говорите Zip-файл, вы имеете в виду несжатый архив, размер которого будет одинаковым со всеми отдельными файлами? Или ты имеешь ввиду сжатый архив? Потому что прямо здесь, если вы говорите о сжатом архиве, у вас будет более быстрая передача, что, строго говоря, будет лучше. Конечно, если вы принимаете во внимание время, необходимое для создания архива, и время, необходимое для извлечения архива, то в игру вступают спецификации обеих машин, чтобы определить, является ли архив лучше, чем потерянные файлы.

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

Однако, в конце концов, если вы не сможете ограничить передачу файлов, удаленный сеанс будет замедляться независимо от того, что вы делаете во время передачи файлов, поскольку максимально возможная пропускная способность будет использоваться для передачи между удаленная машина и ваша машина.

РЕДАКТИРОВАТЬ

Вы пытаетесь найти простой способ передачи файлов без влияния на качество удаленного соединения. Не имеет значения, являются ли они большими файлами или маленькими файлами. На вашем конце (клиентский компьютер) вы распределяете небольшие объемы данных на удаленный компьютер (серверный компьютер). Вы знаете ... набор текста, команды мыши и т. Д. Сервер постоянно отправляет вам большие объемы данных в виде изображений, составляющих то, что вы видите через удаленное соединение. Поэтому, прежде чем передавать какие-либо файлы, вы УЖЕ переносите большой объем данных в одном направлении. Вот почему я рассказал о том, что вы можете сделать, чтобы уменьшить объем передаваемых данных .... а именно использовать меньшее разрешение для удаленного компьютера на вашем рабочем столе (в отличие от полноэкранного режима) .... уменьшение количества цветов с 32 бит до 16 бит или даже 8 бит. Эти два шага уменьшат объем данных, которые вы передаете с сервера (удаленного) клиенту (вам). Это также означает, что когда вы начинаете передавать файлы по тому же соединению и маршруту, ваше удаленное соединение будет страдать меньше.

Как я уже сказал ... ничего, что вы можете сделать, не сделает соединение четким и отзывчивым. Зачем? Потому что, как только вы начнете передавать файлы с сервера на клиент, это будет поглощать каждый бит пропускной способности, доступный по этому каналу .... и вы уже используете часть пропускной способности по этому каналу для удаленного Само соединение.

Сначала я пытался копировать и вставлять до полуночи, когда скорость передачи данных была ограничена ISP клиентского компьютера до 100 кБ / с. Итак, это заняло несколько часов, и я был вынужден отменить передачу, так как удаленный рабочий стол стал слишком не отвечающим и вялым (медленным). Итак, я перезапустил его в полночь, когда моя локальная скорость передачи превышает 4 ГБ / с.

Поэтому, когда вы впервые попробовали пересылку, у вас было загрузочное соединение со скоростью 100 кбит / с. Вы перемещали 1,2 ГБ файлов настолько быстро, насколько это возможно, что потребовало бы, чтобы съесть как можно больше этих 100 Кбит / с. Что бы оставить то , что места для данных , поддерживающих подключение к удаленному рабочему столу? Так что, конечно, это будет вялым и безразличным. Единственное, что вы также не принимаете во внимание, это скорость загрузки сервера. Если скорость загрузки сервера меньше вашей скорости загрузки ... и в этом идеальном предположении маршрут между сервером и вами позволил этой скорости загрузки оставаться постоянной, как только вы начнете передавать файлы, почти все из этой пропускной способности будет съедена передачей файла, которая пострадает от удаленного соединения.

Зачем?

Поскольку ничто не ограничивает передачу файлов с определенной скоростью или процентом доступной пропускной способности, он будет пытаться использовать все возможные кбит / с. По природе вещей, это заставит страдать удаленное соединение.

Даже передача файлов с сервера третьему лицу (например, где-то на FTP-сервере) может привести к замедлению соединения во время этой передачи, поскольку, опять же, для этой передачи будет выделена максимально возможная пропускная способность. Однако, как только эта передача будет выполнена, вы сможете загрузить ее с FTP-сервера, не влияя на скорость отклика удаленного соединения ... опять же, поскольку ваш входящий канал после полуночи намного больше, чем исходящий канал сервера.

Итак, я бы попытался снизить качество удаленного подключения.

Существует опция RDP, которая создает ссылку на локальный диск на удаленном компьютере. Чтобы включить его, запустите клиент RDP, нажмите (Показать) параметры , → откройте вкладку « Локальные ресурсы ». → нажмите « Дополнительно » → установите флажок « Диски ».

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

Теперь вы можете перетаскивать файлы из одной системы в другую.

Я использую robocopy на моем компьютере с Windows 7, используя unc name \\ tsclient.

Как предложено в его ответе @Tom, предпочтительнее D & D файлы, а не C & Ping их. Это дает дополнительное преимущество в обход ошибки, которая прерывает передачу файла, если вы используете Ctrl+Cна клиентском компьютере.

Я думаю, что ни один из этих ответов действительно не решает вопрос очень хорошо.

Microsoft RDP - это протокол, который не очень хорошо оптимизирован для передачи файлов. Если ваше соединение немного медленное, перемещение битов файла, которые проходят по тому же сетевому каналу, что и пакеты пользовательского интерфейса, такие как рисование экрана и движение мыши, может привести к истечению времени ожидания одной из этих вещей; и затем сервер предположит, что вы потеряли соединение, и отключит вас, нарушив ваши каналы ввода-вывода. Это, конечно, усугубляет проблему.

Прежде всего, вы должны рассмотреть свой рабочий процесс и посмотреть, есть ли у вас более простой способ переместить файлы по другому каналу (например, через Интернет на сервер, а не с рабочей станции), который не нарушает вашу политику безопасности.

Если вы решите, что должны использовать канал копирования файлов RDP, тогда следуйте этим рекомендациям, которые мне подходят.

• Не обращайтесь к большим файлам напрямую через UNC-путь к клиенту. Например, включение общих папок и доступ к файлу из \ TSCLIENT \ share. Это проталкивает содержимое большого файла через небольшой многоцелевой канал.
• Вы получите небольшую оптимизацию и стабильность при сопоставлении диска. Например, NET USE X: \ TSCLIENT \ Share диск X: к указанному выше местоположению. Тем не менее, перегрузка сетевых каналов будет разъединять вас и отключать сопоставление дисков.
• Что наиболее важно, при запуске клиента RDP выберите настройку пропускной способности сети «Модем» или «Медленный». Это намного лучше оптимизирует передачу файлов и звуковые каналы, так что они не могут заглушить остальную часть канала, используемого для управления пользовательским интерфейсом.
• В клиенте Microsoft Remote Desktop для OS X этот параметр странным образом недоступен. В этом случае установите MacPorts и запустите sudo port install 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.