File Transfer Speed – Copying Everything at Once vs One Thing at a Time

When you say a Zip file, do you mean an uncompressed archive that would be the same size as all the individual files? Or do you mean a compressed archive? Because right there, if you are talking about a compressed archive, you'd have a faster transfer, which strictly speaking would be better. Of course, if you take into account the amount of time it takes to make the archive, and how long it takes to extract the archive, then the specs of both machines come into play as to whether the archive is better than loose files.

Now, since you are talking about RDP (as opposed to VNC), the bandwidth usage of the remote connection is quite a bit. RDP is more responsive than VNC, the color depth is (by default) more than 256 colors (32 bit if you don't change it), the screen size will be the size of your desktop, etc... all of these factors affect how much bandwidth is being used just for the remote connection. If you drop things like... the size of the remote desktop, and color depth to 16 bit or less, make sure you aren't sharing sound, etc... this will use less bandwidth for the remote connection, so that when you are transferring files, the remote session should be more responsive.

In the end though, unless you can throttle the file transfer, the remote session is going to get sluggish no matter what you do while you are transferring files, since as much of the available bandwidth as possible is going to be used for the transfer between the remote machine and your machine.

EDIT

You are attempting to find a simple way to transfer files WITHOUT affecting the quality of the remote connection. It doesn't matter if they are large files or small files. At your end (the client machine) you are squirting small amounts of data up to the remote machine (server machine). You know... typing, mouse commands, etc. The server is sending large amounts of data to you all the time, in the form of the images that are making up what you see across the remote connection. So, before you transfer any files, you are ALREADY transferring a large amount of data in one direction. That's why I brought up the things you could do to reduce the amount of data you are transmitting.... namely use a smaller resolution for the remote machine on your desktop (as opposed to full screen).... reducing the number of colors from 32 bit to 16 bit or even 8 bit. Those two steps right there will drop the amount of data you are transmitting from the server (remote) to the client (you). It also means that when you start transferring files along the same connection and route, your remote connection will suffer less.

As I said... nothing you can do will make the connection stay crisp and responsive. Why? Because as soon as you start transferring files from the server to the client, this is going to suck up every bit of bandwidth that is available along that pipe.... and you are already using some of the bandwidth along that pipe for the remote connection itself.

First I tried to copy&paste before midnight when the transfer speed was limited by client computer ISP to 100 kB/s. So, it required a few hours and I was forced to cancel transfer since remote desktop became too unresponsive and sluggish (slow). So, I re-started it over midnight when my local transfer speed is over 4 GB/s

So when you first tried the transfer, you had a download connection of 100kb/s. You were moving 1.2gb of files as fast as possible, which would push to eat up as much of that 100kb/s as it could. Which would leave what room for the data supporting the remote desktop connection? So, of course it would be sluggish and unresponsive. The only thing you are not also taking into account, is the UPLOAD speed of the server. If the upload speed of the server is less than your download speed... and in this perfect hypothetical the route between the server and you allowed for this upload speed to remain constant, as soon as you start to transfer the files, just about all of that bandwidth is going to be eaten up by the file transfer, which will make the remote connection suffer.

Why?

Because there is nothing throttling the file transfer to a specific speed, or a percentage of available bandwidth, it is going to attempt to use every kb/s it can. By the nature of things, this will make the remote connection suffer.

Even transferring the files from the server to a third party (like an FTP server somewhere) would make the connection sluggish during that transfer, because again, as much of the available bandwidth as possible would be allocated to that transfer. Once that transfer was done however, you would be able to download it from the FTP server with no effect on the responsiveness of the remote connection... again because your incoming pipe after midnight is much larger than the server's outgoing pipe.

So, I would try reducing the quality of the remote connection.

What about using something like 7zip or winrar to create split archives of, say 50MB each. That way you can transfer files until connection drops but you don't need to start from scratch each time.

# -mx0 indicates no compression to be used (quickest method)
7z a -mx0 -v50m video.7z myVideo.mp4

Once all files transferred (using scp or equivalent) just recombine and extract? You'll probably also get better speeds from transferring multiple files at once.

--

EDIT: I know you said removable media was out of the question, but could you remove the hard disk from computer 1 and just plug into computer 2 at all to perform the transfer?