Недавно я делал несколько попыток скопировать и вставить большой (1,2 ГБ) файл на удаленный компьютер через RDP. Удаленный компьютер — это виртуальная тестовая машина с MS Windows Server 2008 Datacenter.
Сначала я попытался скопировать и вставить до полуночи, когда скорость передачи была ограничена клиентским провайдером до 100 кБ/с. Поэтому это заняло несколько часов, и мне пришлось отменить передачу, так как удаленный рабочий стол стал слишком неотзывчивым и вялым (медленным). Поэтому я перезапустил его после полуночи, когда моя локальная скорость передачи превысила 4 МБ/с.
Итак, мое впечатление таково, что независимо от скорости (широкополосной) передачи копировать-вставить удаленный компьютер становится медленным при копировании через RDP. В то же время загрузка из интернета не делает удаленный хост медленным.
AFAIU, это потому, что буфер обмена удаленного компьютера и его память перегружаются при передаче.
Как я могу контролировать (ограничивать) использование буфера обмена для определенного процесса (вставка файла)?
Каковы возможные способы контроля?
Обновлять:
Прочитав, что низкая скорость передачи данных вызвана шифрованием, используемым для копирования и вставки по RDP, и поскольку я считаю, что меня больше интересует общая эффективность: как время или скорость получения файла, так и возможность работать без ожидания,Я изменил название вопроса.от:
- Как контролировать использование буфера обмена удаленного рабочего стола для вставки большого файла?
к
- Как лучше копировать и вставлять большие файлы через RDP?
Например, что лучше: скопировать и вставить один огромный (zip) архив или распаковать его и скопировать и вставить папку с распакованными файлами?
А точнее я хотел спросить:
Каковы возможные способы улучшения общего опыта:
- скорость передачи (т.е. наличие нужного файла)
- отзывчивость удаленного хоста (предоставление удаленному компьютеру доступа к работе до завершения копирования и вставки)?
решение1
Когда вы говорите Zip-файл, вы имеете в виду несжатый архив, который будет того же размера, что и все отдельные файлы? Или вы имеете в виду сжатый архив? Потому что прямо здесь, если вы говорите о сжатом архиве, у вас будет более быстрая передача, что, строго говоря, было бы лучше. Конечно, если вы примете во внимание количество времени, необходимое для создания архива, и сколько времени требуется для извлечения архива, то характеристики обеих машин вступают в игру относительно того, лучше ли архив, чем свободные файлы.
Теперь, поскольку вы говорите о RDP (в отличие от VNC), использование полосы пропускания удаленного соединения довольно много. RDP более отзывчив, чем VNC, глубина цвета (по умолчанию) больше 256 цветов (32 бита, если вы ее не меняете), размер экрана будет размером вашего рабочего стола и т. д. все эти факторы влияют на то, сколько полосы пропускания используется только для удаленного соединения. Если вы уменьшите такие вещи, как... размер удаленного рабочего стола и глубину цвета до 16 бит или меньше, убедитесь, что вы не делитесь звуком и т. д. это будет использовать меньшую полосу пропускания для удаленного соединения, поэтому при передаче файлов удаленный сеанс должен быть более отзывчивым.
В конце концов, если толькотыможет ограничить передачу файлов, удаленный сеанс станет медленным, независимо от того, что вы делаете во время передачи файлов, поскольку для передачи между удаленной машиной и вашей машиной будет использоваться максимально возможная часть доступной пропускной способности.
РЕДАКТИРОВАТЬ
Вы пытаетесь найти простой способ передачи файлов БЕЗ влияния на качество удаленного соединения. Неважно, большие это файлы или маленькие. На своем конце (клиентская машина) вы отправляете небольшие объемы данных на удаленную машину (серверную машину). Вы знаете... печатаете, команды мыши и т. д. Сервер все время отправляет вам большие объемы данных в виде изображений, которые составляют то, что вы видите через удаленное соединение. Поэтому, прежде чем вы передадите какие-либо файлы, вы УЖЕ передаете большой объем данных в одном направлении. Вот почему я поднял вопрос о том, что вы можете сделать, чтобы уменьшить объем передаваемых вами данных... а именно использовать меньшее разрешение для удаленной машины на вашем рабочем столе (в отличие от полноэкранного режима)... уменьшая количество цветов с 32 бит до 16 бит или даже 8 бит. Эти два шага прямо здесь уменьшат объем данных, которые вы передаете с сервера (удаленного) клиенту (вам). Это также означает, что когда вы начнете передавать файлы по тому же соединению и маршруту, ваше удаленное соединение будет страдать меньше.
Как я уже сказал... ничего, что вы можете сделать, не заставит соединение оставаться четким и отзывчивым. Почему? Потому что как только вы начнете передавать файлы с сервера на клиент, это поглотит всю доступную полосу пропускания на этом канале... и вы уже используете часть полосы пропускания на этом канале для самого удаленного соединения.
Сначала я попытался скопировать и вставить до полуночи, когда скорость передачи была ограничена клиентским провайдером до 100 кБ/с. Поэтому это заняло несколько часов, и мне пришлось отменить передачу, так как удаленный рабочий стол стал слишком неотзывчивым и вялым (медленным). Поэтому я перезапустил его после полуночи, когда моя локальная скорость передачи превысила 4 ГБ/с.
Итак, когда вы впервые попробовали передачу, у вас было соединение для загрузки 100 кбит/с. Вы перемещали 1,2 ГБ файлов с максимально возможной скоростью, что подтолкнуло бы вас съесть как можно больше из этих 100 кбит/с. Что оставило бычтоместо для данных, поддерживающих подключение к удаленному рабочему столу? Конечно, это будет вялым и неотзывчивым. Единственное, что вы не учитываете, это скорость ЗАГРУЗКИ сервера. Если скорость загрузки сервера меньше вашей скорости загрузки... и в этой идеальной гипотетической ситуации маршрут между сервером и вами позволяет этой скорости загрузки оставаться постоянной, как только вы начнете передавать файлы, почти вся эта полоса пропускания будет съедена передачей файлов, что заставит страдать удаленное соединение.
Почему?
Поскольку нет ничего, что ограничивало бы передачу файлов определенной скоростью или процентом доступной пропускной способности, он будет пытаться использовать каждый кб/с, который может. По сути, это заставит страдать удаленное соединение.
Даже передача файлов с сервера на третью сторону (например, на FTP-сервер где-нибудь) сделает соединение вялым во время этой передачи, потому что, опять же, максимально возможная часть доступной полосы пропускания будет выделена для этой передачи. Однако, как только эта передача будет завершена, вы сможете загрузить ее с FTP-сервера без какого-либо влияния на скорость отклика удаленного соединения... опять же, потому что ваш входящий канал после полуночи намного больше, чем исходящий канал сервера.
Поэтому я бы попробовал снизить качество удаленного соединения.
решение2
Есть опция RDP, которая создает ссылку на ваш локальный диск на удаленном компьютере. Чтобы включить ее, запустите клиент RDP, нажмите (Показать)Параметры, → открыть "Местные ресурсы" таб. → щелчок "Более" → отметьте галочкой "Диски"флажок.
После подключения откройте проводник Windows на удаленной системе. Ваш локальный диск должен появиться в нижней части списка дисков в Моем компьютере. Он отображается как "C на your_computer_name".
Теперь вы можете перетаскивать файлы из одной системы в другую.
решение3
Я использую robocopy на своем компьютере с Windows 7, используя unc-имя \\tsclient.
решение4
Как предположил в своем ответе @Tom, предпочтительнее использовать D&D для файлов вместо C&Ping. Это дает дополнительное преимущество в виде обхода ошибки, которая прерывает передачу файлов, если вы используете ее Ctrl+Cна клиентской машине.