Recientemente estuve haciendo algunos intentos de copiar y pegar un archivo grande (1,2 GB) en una computadora remota a través de RDP. La computadora remota es una máquina de prueba virtual con MS Windows Server 2008 Datacenter.
Primero intenté copiar y pegar antes de la medianoche cuando el ISP de la computadora cliente limitaba la velocidad de transferencia a 100 kB/s. Entonces, tomó algunas horas y me vi obligado a cancelar la transferencia ya que el escritorio remoto dejó de responder y se volvió lento (lento). Entonces, lo reinicié alrededor de la medianoche cuando mi velocidad de transferencia local supera los 4 MB/s.
Entonces, mi impresión es que, independientemente de la velocidad (banda ancha) de la transferencia de copiar y pegar, la computadora remota se vuelve lenta al copiar a través de RDP. Al mismo tiempo, la descarga desde Internet no ralentiza el host remoto.
AFAIU, se debe al portapapeles de la computadora remota y, por lo tanto, su memoria se sobrecarga con la transferencia.
¿Cómo puedo controlar (restringir) el uso del portapapeles para un proceso específico (pegar un archivo)?
¿Cuáles son las posibles formas de controlarlo?
Actualizar:
Después de leer que la baja velocidad de transferencia se debe al cifrado utilizado para copiar y pegar a través de RDP y dado que creo que estoy más interesado en la eficiencia general: tanto el tiempo o la rapidez de obtener el archivo como la posibilidad de trabajar sin esperar,Cambié el título de la pregunta.de:
- ¿Cómo controlar el uso del portapapeles del escritorio remoto para pegar un archivo grande?
a
- ¿Cómo copiar y pegar mejor archivos grandes a través de RDP?
Por ejemplo, ¿es mejor copiar y pegar un archivo enorme (zip) o descomprimirlo y copiar y pegar una carpeta con archivos descomprimidos?
Y más exactamente quería preguntar:
¿Cuáles son las posibles formas de mejorar la experiencia general?
- la velocidad de transferencia (es decir, la disponibilidad del archivo necesario)
- ¿Capacidad de respuesta del host remoto (hacer que la computadora remota esté disponible para trabajar antes de completar el proceso de copiar y pegar)?
Respuesta1
Cuando dices un archivo Zip, ¿te refieres a un archivo sin comprimir que tendría el mismo tamaño que todos los archivos individuales? ¿O te refieres a un archivo comprimido? Porque ahí mismo, si estás hablando de un archivo comprimido, tendrías una transferencia más rápida, lo que estrictamente hablando sería mejor. Por supuesto, si se tiene en cuenta la cantidad de tiempo que lleva crear el archivo y el tiempo que lleva extraerlo, entonces las especificaciones de ambas máquinas entran en juego para determinar si el archivo es mejor que los archivos sueltos.
Ahora, dado que estás hablando de RDP (a diferencia de VNC), el uso de ancho de banda de la conexión remota es bastante. RDP responde mejor que VNC, la profundidad de color es (por defecto) de más de 256 colores (32 bits si no lo cambia), el tamaño de la pantalla será el tamaño de su escritorio, etc... todos estos factores afecta la cantidad de ancho de banda que se utiliza solo para la conexión remota. Si reduce cosas como... el tamaño del escritorio remoto y la profundidad de color a 16 bits o menos, asegúrese de no compartir sonido, etc... esto utilizará menos ancho de banda para la conexión remota, de modo que cuando está transfiriendo archivos, la sesión remota debería responder mejor.
Pero al final, a menos quetúpuede acelerar la transferencia de archivos, la sesión remota se volverá lenta sin importar lo que haga mientras transfiere archivos, ya que la mayor parte posible del ancho de banda disponible se utilizará para la transferencia entre la máquina remota y su máquina.
EDITAR
Está intentando encontrar una forma sencilla de transferir archivos SIN afectar la calidad de la conexión remota. No importa si son archivos grandes o pequeños. Por su parte (la máquina cliente), está enviando pequeñas cantidades de datos a la máquina remota (máquina servidora). Ya sabes... escritura, comandos del mouse, etc. El servidor te envía grandes cantidades de datos todo el tiempo, en forma de imágenes que componen lo que ves a través de la conexión remota. Entonces, antes de transferir cualquier archivo, YA estás transfiriendo una gran cantidad de datos en una dirección. Es por eso que mencioné las cosas que podría hacer para reducir la cantidad de datos que está transmitiendo... es decir, usar una resolución más pequeña para la máquina remota en su escritorio (en lugar de pantalla completa)... reducir la cantidad de colores de 32 bits a 16 bits o incluso 8 bits. Esos dos pasos reducirán la cantidad de datos que está transmitiendo desde el servidor (remoto) al cliente (usted). También significa que cuando comiences a transferir archivos a través de la misma conexión y ruta, tu conexión remota sufrirá menos.
Como dije... nada de lo que puedas hacer hará que la conexión se mantenga nítida y receptiva. ¿Por qué? Porque tan pronto como comiences a transferir archivos desde el servidor al cliente, esto consumirá todo el ancho de banda disponible a lo largo de esa tubería... y ya estás usando parte del ancho de banda a lo largo de esa tubería para el control remoto. conexión misma.
Primero intenté copiar y pegar antes de la medianoche cuando el ISP de la computadora cliente limitaba la velocidad de transferencia a 100 kB/s. Entonces, tomó algunas horas y me vi obligado a cancelar la transferencia ya que el escritorio remoto dejó de responder y se volvió lento (lento). Entonces, lo reinicié sobre la medianoche cuando mi velocidad de transferencia local supera los 4 GB/s.
Entonces, cuando intentaste la transferencia por primera vez, tenías una conexión de descarga de 100 kb/s. Estabas moviendo 1,2 GB de archivos lo más rápido posible, lo que obligaría a consumir la mayor cantidad posible de esos 100 kb/s. cual dejariaqué¿Espacio para los datos que respaldan la conexión al escritorio remoto? Entonces, por supuesto, sería lento y no respondería. Lo único que no estás teniendo en cuenta es la velocidad de CARGA del servidor. Si la velocidad de carga del servidor es menor que su velocidad de descarga... y en este hipotético perfecto la ruta entre el servidor y usted permitió que esta velocidad de carga permaneciera constante, tan pronto como comience a transferir los archivos, casi todos Gran parte de ese ancho de banda será consumido por la transferencia de archivos, lo que afectará la conexión remota.
¿Por qué?
Debido a que no hay nada que limite la transferencia de archivos a una velocidad específica o un porcentaje del ancho de banda disponible, intentará utilizar cada kb/s que pueda. Por la naturaleza de las cosas, esto hará que la conexión remota se vea afectada.
Incluso transferir los archivos del servidor a un tercero (como un servidor FTP en algún lugar) haría que la conexión fuera lenta durante esa transferencia, porque nuevamente, la mayor parte posible del ancho de banda disponible se asignaría a esa transferencia. Sin embargo, una vez realizada la transferencia, podrá descargarla desde el servidor FTP sin ningún efecto en la capacidad de respuesta de la conexión remota... nuevamente porque su canal entrante después de medianoche es mucho más grande que el canal saliente del servidor.
Entonces, intentaría reducir la calidad de la conexión remota.
Respuesta2
Existe una opción RDP que crea un enlace a su unidad local en la computadora remota. Para habilitarlo, inicie el cliente RDP, haga clic en (Mostrar)Opciones, → abre el "Recursos locales" pestaña. → haga clic en "Más" → marca la casilla "Unidades"casilla de verificación.
Después de conectarse, abra el Explorador de Windows en el sistema remoto. Su unidad local debería aparecer al final de la lista de unidades en Mi PC. Aparece como "C en su_nombre_de_computadora".
Ahora puedes arrastrar y soltar archivos de un sistema a otro.
Respuesta3
Utilizo robocopy en mi caja de Windows 7, usando el nombre unc \\tsclient.
Respuesta4
Como lo sugiere @Tom en su respuesta, es preferible D&D los archivos en lugar de C&Ping. Esto tiene el beneficio adicional de evitar un error que interrumpe la transferencia de archivos si lo usa Ctrl+Cen la máquina cliente.