Копирование больших файлов через rdp
Обновлено: 04.07.2024
Недавно я сделал несколько попыток скопировать и вставить большой (1,2 ГБ) файл на удаленный компьютер через RDP. Удаленный компьютер - виртуальный тестовый компьютер с центром обработки данных MS Windows Server 2008.
Сначала я попытался скопировать и вставить до полуночи, когда скорость передачи была ограничена клиентским компьютером ISP до 100 кБ /с. Таким образом, это потребовало нескольких часов, и я был вынужден отменить передачу, поскольку удаленный рабочий стол стал слишком нерешенным и вялым (медленным). Итак, я перезапустил его за полночь, когда моя скорость передачи данных превышает 4 МБ /с.
Итак, у меня сложилось впечатление, что независимо от скорости (широкополосного) копирования и переноса пасты удаленный компьютер становится вялым при копировании через RDP. В то же время загрузка из Интернета не делает удаленный хост вялым.
AFAIU, это потому, что буфер обмена удаленного компьютера и поэтому его память становится перегруженной передачей.
Как я могу контролировать (ограничивать) использование буфера обмена для конкретного процесса (вставка файла)?
Каков возможный способ его контролировать?
Update:
После прочтения, что медленная скорость передачи вызвана шифрованием, используемым для копирования и вставки поверх RDP, и поскольку я считаю, что меня больше интересует общая эффективность: как время, так и скорость получения файла, а также возможность работать без ожидания, Я сменил название вопроса на:
- Как управлять использованием использования буфера обмена удаленных рабочих столов для вставки большого файла?
- Как лучше скопировать и вставить большие файлы через RDP?
Например, лучше ли скопировать и вставить один огромный архив (zip) или распаковать его и скопировать в папку с распакованными файлами?
И точнее я хотел спросить:
Каковы возможные способы улучшения общего опыта:
- скорость передачи (т. е. доступность необходимого файла)
- отзывчивость удаленного хоста (что делает удаленный кофейтер доступным для работы до завершения копирования и вставки)?
Когда вы говорите файл Zip, вы имеете в виду несжатый архив, который будет такого же размера, как и все отдельные файлы? Или вы имеете в виду сжатый архив? Потому что прямо здесь, если вы говорите о сжатом архиве, у вас будет более быстрая передача, которая, строго говоря, будет лучше. Разумеется, если учесть количество времени, которое требуется на создание архива, и сколько времени требуется на извлечение архива, тогда характеристики обеих машин вступают в игру относительно того, лучше ли архив лучше, чем свободные файлы.
Теперь, поскольку вы говорите о RDP (в отличие от VNC), использование пропускной способности удаленного соединения довольно немного. RDP более отзывчив, чем VNC, глубина цвета (по умолчанию) более 256 цветов (32 бит, если вы его не изменяете), размер экрана будет размером вашего рабочего стола и т. Д. . все эти факторы влияют на использование полосы пропускания только для удаленного соединения. Если вы потеряете такие вещи, как . размер удаленного рабочего стола и глубина цвета до 16 бит или меньше, убедитесь, что вы не используете звук, и т. Д., Это будет использовать меньшую пропускную способность для удаленного подключения, так что когда вы передаете файлы, удаленный сеанс должен быть более отзывчивым.
В конце концов, если только вы не сможете дросселировать передачу файлов, удаленный сеанс будет вялым, независимо от того, что вы делаете во время передачи файлов, так как большая часть доступной полосы пропускания как возможно, будет использоваться для передачи между удаленным компьютером и вашей машиной.
ИЗМЕНИТЬ
Вы пытаетесь найти простой способ передачи файлов БЕЗ влияния на качество удаленного подключения. Неважно, являются ли они большими файлами или небольшими файлами. В конце (клиентской машине) вы производите небольшие объемы данных до удаленной машины (серверной машины). Вы знаете . ввод, команды мыши и т. Д. Сервер отправляет вам большое количество данных в виде изображений, которые составляют то, что вы видите по удаленному соединению. Итак, прежде чем передавать какие-либо файлы, вы УЖЕ передаете большой объем данных в одном направлении. Вот почему я рассказал о том, что вы могли бы сделать, чтобы уменьшить объем передаваемых данных . а именно использовать меньшее разрешение для удаленной машины на вашем рабочем столе (в отличие от полного экрана) . уменьшая количество цвета от 32 до 16 бит или даже 8 бит. Эти два шага направят туда данные, которые вы передаете с сервера (удаленно) клиенту (вы). Это также означает, что при запуске передачи файлов по одному и тому же соединению и маршруту ваше удаленное соединение будет меньше.
Как я уже сказал, вы ничего не сможете сделать, чтобы соединение оставалось четким и отзывчивым. Зачем? Поскольку, как только вы начнете передавать файлы с сервера на клиент, это будет всасывать каждый бит полосы пропускания, который доступен по этому каналу . и вы уже используете некоторую полосу пропускания вдоль этого канала для удаленного само соединение.
Сначала я попытался скопировать и вставить до полуночи, когда скорость передачи была ограничена клиентским компьютером ISP до 100 кБ /с. Таким образом, это потребовало нескольких часов, и я был вынужден отменить передачу, поскольку удаленный рабочий стол стал слишком нерешенным и вялым (медленным). Итак, я перезапустил его за полночь, когда моя скорость передачи данных превышает 4 ГБ /с
Итак, когда вы впервые попробовали передачу, у вас было подключение для загрузки 100 кбит /с. Вы как можно быстрее перемещали файлы объемом 1,2 Гбайт, что давало бы возможность съедать столько же 100 кбит /с, сколько возможно. Что бы оставить , что для данных, поддерживающих подключение к удаленному рабочему столу? Так что, конечно, это было бы вяло и невосприимчиво. Единственное, что вы не учитываете, - это скорость UPLOAD сервера. Если скорость загрузки сервера меньше скорости загрузки . и в этой идеальной гипотезе маршрут между сервером и вамипозволил этой скорости загрузки оставаться постоянным, как только вы начнете передавать файлы, почти вся эта пропускная способность будет съедена путем передачи файлов, что приведет к их удалению.
Поскольку нет ничего дросселирования передачи файла на определенную скорость или процент от доступной полосы пропускания, он попытается использовать каждый kb /s, который он может использовать. По характеру вещей это заставит удаленное соединение пострадать.
Даже передача файлов с сервера третьим лицам (например, FTP-серверу) приведет к тому, что соединение будет вялым во время этой передачи, потому что опять же, как можно больше доступной полосы пропускания будет выделено для этой передачи. Однако после того, как эта передача была выполнена, вы сможете загрузить ее с FTP-сервера, не влияя на отзывчивость удаленного соединения . снова, потому что ваш входящий канал после полуночи намного больше, чем исходящий канал сервера.
Итак, я попытался бы уменьшить качество удаленного подключения.
Существует опция RDP, которая создает ссылку на ваш локальный диск на удаленном компьютере. Чтобы включить его, запустите клиент RDP, нажмите (Показать) Параметры , → откройте вкладку Локальные ресурсы . → нажмите « Дополнительно » → отметьте флажок « Диски ».
После подключения откройте проводник Windows в удаленной системе. Ваш локальный диск должен появиться в нижней части списка дисков в «Мой компьютер». Он отображается как «C на вашем_компьютере».
Недавно я делал несколько попыток скопировать и вставить большой (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-сервера, не влияя на скорость отклика удаленного соединения . опять же, поскольку ваш входящий канал после полуночи намного больше, чем исходящий канал сервера.
При работе на серверах в режиме подключения Remote Desktop Connection (RDP) постоянно возникает необходимость копирования/перемещения файлов между локальной и удаленной машиной. Для этого в подключении настраивается "проброс" дисков и буфера обмена локальной машины. Файлы копируются обычным способом в проводнике удаленной машины или просто через буфер обмена.
Такой "обычный" метод прекрасно работает до тех пор, пока файлы не оказываются сравнительно большими или соединение недостаточно стабильным. А большинство файлов, которые необходимо скопировать, как раз и являются большими: дистрибутивы, конфигурации, выгрузки баз, архивы логов, бэкапы и т.д. Загрузка / выгрузка таких файлов не всегда проходит успешно. Малейшая нестабильность канала приводит к обрыву передачи с ошибкой. Иногда приходится возобновлять передачу вновь и вновь и вновь, что может длиться часами. Особенно, если размер файла составляет несколько Гигабайт.
И если на серверах, которыми владеете Вы или Ваша Компания, возможны другие варианты организации файлообмена, кроме как по RDP-соединению, то к серверам, находящихся в инфраструктуре Заказчика, чаще всего есть только RDP доступ (к тому же, в большинстве случаев, через VPN) и организация альтернативных способов требует согласования со службой информационной безопасности Заказчика.
Однажды, после того как выгрузка нескольких гигабайт архивированных логов ТехЖурнала с продуктивной системы в контуре Заказчика для отправки на контроль в
Целью заметки не является подробное описание данного протокола. В Сети достаточно материала, в том числе и на русском языке. Сосредоточимся лишь на практическом применении в отношении RDP-сессий.
Реализация
При решении задачи я воспользовался реализацией скрипта на PowerShell
Для примера будем загружать с локальной машины на удаленную дистрибутив сервера 1С, т.к. доступа к Интернет с самого сервера нет.
Ниже привожу основную, рабочую часть скрипта. Достаточно указать в параметрах -Source и -Destination свои пути к файлам. Оба пути - с удаленной машины. Один указывает на локальный диск, второй - на "проброшенный" (\\tsclient)
Служба может работать в обе стороны, т.е. как скачивать на удаленную машину с локальной, так и закачивать с удаленной на локальную. Достаточно поменять местами значения параметров -Source и -Destination.
Запускать скрипт нужно на удаленной машине, т.е. в RDP-сессии.
Совет: самый простой способ добавить путь к файлу - найти его в проводнике, выделить, нажать Shift+ПКМ и выбрать "Копировать как путь". Что сделать дальше со строкой в буфере, полагаю и так все знают.
После запуска скрипт демонстрирует прогресс операции в процентах.
Можно в любой момент прервать его выполнение по Ctrl-C или закрыв окно. При следующем запуске через несколько минут можно заметить что процент выполнения будет больше того, на котором был произведен обрыв. Таким же образом будет возобновлена передача файлов после повторного соединения при обрыве связи или отключении сессии. При настройках по умолчанию, следующая попытка после неудачной предпринимается через 10 минут. Чтобы не ожидать автоматического возобновления, можно запустить скрипт повторно.
Если оставить задачу "без присмотра", т.е. без работающего скрипта, то загрузка выполнится, но загружаемые файлы не появятся в целевом каталоге. Вернее, в нём будут временные файлы вида "BIT5F71.tmp". Для того, чтобы в каталоге назначения объявились "правильные" файлы, необходимо выполнить "финализацию", при которой созданные временные файлы будут переименованы и задание службы будет удалено.
Сделать это можно, просто повторно запустив скрипт. Либо выполнить в консоли:
В случае, если на протяжении загрузки скрипт выполнялся, то финализация будет выполнена автоматически, без дополнительных действий.
Как уже было показано, при завершении скрипта по Ctrl-C или закрытием окна и даже выходом из сессии, задача BITS-transfer не удаляется.
При необходимости отменить задачу, сделать это можно следующим образом:
Возможные ошибки
При первом запуске скрипта может возникнуть ошибка вида:
Для устранения ошибки необходимо разрешить выполнение сценариев, сменив политику выполнения:
Файл для загрузки
В загружаемом файле приложена чуть более доработанная версия скрипта, с интерактивными диалоговыми окнами выбора файла-источника и каталога-назначения, а также возможностью выбора нескольких файлов.
Если вы активно используете удаленные подключения к рабочим станциям, Windows серверам, RDS фермерам через протокол RDP, скорее всего вы не раз сталкивались, что в некоторых случаях не работает буфер обмена в терминальной сессии. В результате вы не можете передать (скопировать/вставить) текст или файлы между вашим компьютером и удаленным рабочим столом. Проблема встречается как в Windows Server, так и в десктопных версиях Windows.
Возможны два сценария – на удаленном сервере запрещено копировать файлы/данные через RDP, или в текущей сессии пользователя произошел сбой процесса rdpclip.exe.
Не работают функции копировать/вставить в буфере обмена RDP сессии (rdpclip.exe)
Если буфер обмена в конкретной RDP сессии перестал работать неожиданно, а пункт Paste в контекстном меню удаленного компьютера стал неактивным, проще всего корректно завершить текущую RDP сессию (logoff) и подключиться заново. Это наверняка исправит проблему с буфером обмена. Однако это не всегда удобно, потому что приходится заново запускать все приложения в RDP сессии. К счастью, есть способ восстановить работу буфера обмена в RDP сессии без выполнения logoff.
За работу буфера обмена между вашим компьютером и удаленной RDP отвечает приложение rdpclip.exe. Для каждого удаленного пользователя при подключении к Remote Desktop для стартует собственный процесс rdpclip.exe . С помощью Task Manager вы можете завершить процесс rdpclip.exe (RDP Clipboard Monitor/ Монитор буфера обмена RDP) и запустить его вручную (Task Manager -> File -> Start new task -> rdpclip -> Enter).
Это обычно помогает быстро восстановить работу удаленного буфера обмена. Проверьте, работает ли теперь copy/paste (Ctrl+C / Ctrl+V) в RDP окне.
(Get-WmiObject -Query "select * from Win32_Process where name='RDPClip.exe'"|?).Terminate()
rdpclip.exe
Также не забывайте, что успешного копирования данных через RDP буфер обмена должны быть выполнены следующие условия:
Если вы используете другой RDP клиент, например Remote Desktop Connection Manager или mRemoteNG, имейте в виду что опция удаленного буфера обмена может называться по-другому.Как запретить/разрешить копирование через буфер обмена RDP в Windows?
С помощью параметров групповых политик или реестра вы можете разрешить или запретить использование RDP буфера обмена на хосте Windows для операций копировать/вставить.
- Запустите локальный редактор групповых политик – gpedit.msc ;
- Перейдите в секцию GPO Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Device and Resource Redirection;
- Чтобы запретить копировать данные с/на удаленный сервер через буфер обмена RDP сессии установите Enabled для следующих политик:
- DisableClipboardRedirection = 1
- DisableDriveRedirection = 1
Можно запретить копирование данных между компьютером и удаленным RDP хостом так:
reg add “HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server” / v “DisableClipboardRedirection” / t REG_DWORD / d 1 / f
reg add “HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server” / v “DisableDriveRedirection” / t REG_DWORD / d 1 / f
Если у вас используются RDS сервера, можно отключить буфер обмена и локальные диски в настройках коллекции: Remote Desktop Services -> Collections -> Tasks -> Edit Properties -> Client Settings. Снимите галки у опций “Clipboard” и “Drive” в секции Enable redirecting for the following.
Читайте также: