Dropbox is likely to be using just that one HTTP request, or at most two (one to authenticate, one to send the data). The client may also issue a couple of extra commands to get information back from the server about itself. As well as these two round-trips per file there are several command-response round-trips for the initial connection - one to send the username, one for the password, and at least one to set transfer parameters (to make sure the server is expecting binary, not ASCII, data). To send a file the client needs to send a minimum of two commands (one to open the data connection and one to start the send) and each time it needs to wait for the server to respond, adding extra latency. There is a lot of to-ing and fro-ing on an FTP connection. Also the data connection for an FTP session may be opened from the server to your client and if you are NATed this may fail so your FTP client may be trying to connect that way around, failing then trying the other way around. There could be a number of reasons for this.Īn FTP transfer needs at least two connections (one for control and one for data) where DropBox may be using just a single HTTP connection.
0 kommentar(er)
