24

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

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

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

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

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

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

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

в

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

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

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

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

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

7 ответов7

22

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

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

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

7

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

5

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

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

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

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

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

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

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

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

Зачем?

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

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

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

4

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

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 **, чтобы скопировать элементы, соответствующие шаблону имени файла, в указанный локальный (серверный) каталог.

Я надеюсь, что кто-то найдет эти предложения полезными. Они, безусловно, работают на меня.

4

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

2

Взгляните на http://www.bittorrent.com/sync/download

Это намного быстрее и не требует открытия сеанса RDP во время завершения копирования.

Это также не требует, чтобы у вас был доступ к пути UNC, как указано выше.

ура

0

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

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .