not sure if this question has been asked before, but which one is faster? And why? I've searched Google for a technical explanation, but none of the search results actually clearly revealed an absolute answer. From real world experience, I always see that HTTP downloads are somewhat faster than FTP downloads. I understand that HTTP protocol is stateless while FTP protocol is stateful, so is it because of the overhead involved in maintaining the connection alive that caused the poor performance in FTP transfer? Anyone got links to supporting documents explaining why one is faster than the other?
FTP vs. HTTP transfer performance..
- Thread starter kt
- Start date
FTP is supposedly, theoretically, faster than http, but I don't think you would ever really notice a difference. My bandwidth is capped at a certain point, and with both http and ftp, I get RIGHT up to that number.
Http is basically just a couple lines of headers, and then pure data after that. I can't imagine ftp has much more overhead. In any normal scenario, the difference should be basically nothing. I hear people say "ftp has less overhead," but I don't see how that's possible. If a couple lines of headers is considered noticeable overhead, then that's just nuts.
The only real difference I notice between the two is that grabbing a file via ftp takes a second or two extra at the beginning, because you have to log in.
Http is basically just a couple lines of headers, and then pure data after that. I can't imagine ftp has much more overhead. In any normal scenario, the difference should be basically nothing. I hear people say "ftp has less overhead," but I don't see how that's possible. If a couple lines of headers is considered noticeable overhead, then that's just nuts.
The only real difference I notice between the two is that grabbing a file via ftp takes a second or two extra at the beginning, because you have to log in.
ftp "should" be faster only because it has built in flow control. The control channels and data channels are independant of each other, two seperate TCP connections. FTP "should" be faster.
But in the real world and the real internet it is a toss up. HTTP as a protocol has a lot going against it. Try your own tests with your own servers and see what happens.
-edit- to respond to the above post. When you start adding up that couple of lines of overhead over 1000s of packets it adds up. Hence why the pure data channel of FTP is faster.
But in the real world and the real internet it is a toss up. HTTP as a protocol has a lot going against it. Try your own tests with your own servers and see what happens.
-edit- to respond to the above post. When you start adding up that couple of lines of overhead over 1000s of packets it adds up. Hence why the pure data channel of FTP is faster.
Ok, I probably should come clean. I am taking this class at a local university, the professor asked me the question which protocol is faster for file uploading/downloading. I took the same reasoning that you guys have mentioned and said FTP. I think he was expecting that answer, and said I was wrong. So, at the end of the class when everyone was getting ready to leave he asked us to find out why.
I would like to prove him wrong. But so far everything I've found is at best used as blank ammunition against him. I need something solid that will either prove him wrong or me wrong.
- Oct 25, 1999
- 29,528
- 415
- 126
I think that if you lose the connection HTTP has a better Resume function than FTP.
HTTP vs. FTP
FTP has been the standard mechanism for sending files to a server since the earliest days of TCP/IP. It is reliable, can take into account text vs. binary formats across platforms, and there are ubiquitous clients. However, compared to the flexibility of HTTP, it is deeply lacking. Let's compare:
Authentication: With FTP uploads you must either manage many user accounts or allow anonymous access. With uploads via a web application, the application can determine who is allowed to upload, without a large administrative burden.
Security: Uploads via HTTP can be SSL encoded so that the information is encrypted during transmission. There is no means for doing that using standard FTP.
Ease of configuration: FTP uploads require the administrator to fine tune NTFS permissions. With HTTP-based uploads and your application, this is determined by the application as well as by the adminstrator, if desired.
Flexibility: Want to save DOC files in one location and graphics in another? With FTP, your users have to know that. With a web application, you can enforce these policies in your application and change them without disrupting your users.
Power: With a web application, you can limit the size of the uploaded file dynamically every time it is invoked. You could even change the size depending on information contained in the same form. Additionally, you can flush uploads that do match certain criteria, such as wrong MIME type or file contents.
Simplicity and friendliness: A pleasing web page can offer instructions, advise, on-line help. This is not possible with batch based FTP. More importantly, when errors occur, you can provide immediate feedback to the user and offer corrective action.
Firewall support: Many organizations do not allow out-bound FTP for security and intellectual property reasons. While this is simply a configuration issue, most firewalls do allow HTTP uploads.
Supplemental Information: An HTTP upload (using RFC1867) renders accessible additional information about the upload, such as the user's original filename. This can be very useful in intranet scenarios.
Upload to a database: Server-side components, such SA-FileUp, allows you to upload to an OLE DB database. Try that with FTP!
Performance: both FTP and HTTP ultimately use the TCP protocol, which is the primary determinant of transfer performance.
Reliability and Restart: Both FTP and HTTP 1.1 allow for transfer restart. Unfortunately, many servers including IIS, do not support restart of either protocol at this time. FTP restart is apparently coming in IIS5.
In short, like the web itself, it is programmability of the server that offers vast advantages of HTTP uploads over FTP.
The above is a Quote from: http://www.learnasp.com/aspmagazine/issue8uploads.asp
Here is an additional view on the issue: No More FTP!
HTTP vs. FTP
FTP has been the standard mechanism for sending files to a server since the earliest days of TCP/IP. It is reliable, can take into account text vs. binary formats across platforms, and there are ubiquitous clients. However, compared to the flexibility of HTTP, it is deeply lacking. Let's compare:
Authentication: With FTP uploads you must either manage many user accounts or allow anonymous access. With uploads via a web application, the application can determine who is allowed to upload, without a large administrative burden.
Security: Uploads via HTTP can be SSL encoded so that the information is encrypted during transmission. There is no means for doing that using standard FTP.
Ease of configuration: FTP uploads require the administrator to fine tune NTFS permissions. With HTTP-based uploads and your application, this is determined by the application as well as by the adminstrator, if desired.
Flexibility: Want to save DOC files in one location and graphics in another? With FTP, your users have to know that. With a web application, you can enforce these policies in your application and change them without disrupting your users.
Power: With a web application, you can limit the size of the uploaded file dynamically every time it is invoked. You could even change the size depending on information contained in the same form. Additionally, you can flush uploads that do match certain criteria, such as wrong MIME type or file contents.
Simplicity and friendliness: A pleasing web page can offer instructions, advise, on-line help. This is not possible with batch based FTP. More importantly, when errors occur, you can provide immediate feedback to the user and offer corrective action.
Firewall support: Many organizations do not allow out-bound FTP for security and intellectual property reasons. While this is simply a configuration issue, most firewalls do allow HTTP uploads.
Supplemental Information: An HTTP upload (using RFC1867) renders accessible additional information about the upload, such as the user's original filename. This can be very useful in intranet scenarios.
Upload to a database: Server-side components, such SA-FileUp, allows you to upload to an OLE DB database. Try that with FTP!
Performance: both FTP and HTTP ultimately use the TCP protocol, which is the primary determinant of transfer performance.
Reliability and Restart: Both FTP and HTTP 1.1 allow for transfer restart. Unfortunately, many servers including IIS, do not support restart of either protocol at this time. FTP restart is apparently coming in IIS5.
In short, like the web itself, it is programmability of the server that offers vast advantages of HTTP uploads over FTP.
The above is a Quote from: http://www.learnasp.com/aspmagazine/issue8uploads.asp
Here is an additional view on the issue: No More FTP!
JackMDS, thanks for the info. But that's not exactly what I am looking for. As far as I know HTTP do not have resume function at all. When HTTP initiates a transfer it will close immediately after the last packet is sent becaues of its stateless nature. Or in some instances, you'll get partial incomplete file if an error or time out occurs. HTTP doesn't not check whether the whole file is transferred or not.
But http runs on tcp/ip sockets, how is it in any way involved with individual packets? The http headers are sent once per connection at the beginning, and after that, it is pure data.
You could write your own ftp server with a different way of managing who can upload. That's not unreasonable because you'd have to write the same thing for http uploads.
Wrong, I do SSL transfers all the time. It's built into FlashFXP and other clients as well in some ftpds. You could even do it with winsslwrap
NTFS permissions? Who said this was a discussion about ftpd's on windows?
Once again, you could do this with a custom ftp server. And once again it isn't unreasonable because you'd have to write that web application.
How HTTP goes about Sending a file:
The server sends a GET request to the Web server to retrieve the address it has been given.
For example, when a user types http://www.example.com/1.jpg, the browser sends a GET 1.jpg command to example.com and waits for a response.
The server now responds to the browser's requests. It verifies that the given address exists, finds the necessary files, runs the appropriate scripts, exchanges cookies if necessary, and returns the results back to the browser.
If it cannot locate the file, the server sends an error message to the client.
There is also a web protocol definable feild that is checked to see how many downloads a paticular user can download and if that limit has been reached it queues up any future downloads.
The browser translates the data it has been given in to HTML and MIME encoding and displays the results to the user or in this case asks the user to save the file.
You may want to point out also that HTTP 1.0 is much slower than HTTP 1.1 because of how HTTP 1.0 does not have persistant connections and one file to the next you have to have a new connection established slowing down your overall download time.
As you mention too that HTTP Client/Server is stateless so one file to the next could result in a new connection if the last transfer took a while to complete.
One more thing to note. Currently the way web transfer work is they download them to a cache somewhere (most times your temp directory) then it copies it from there to the final destination.
This is not the case for FTP. FTP will reconstruct the requested file in real time and you can watch the byte value increase.
Resume of download is not automatic in HTTP but can be programmed in whereas most respectable FTP servers have a resume feature already built in.
This web site is an interesting one about how clients and servers negotiate what a file type is before it sends. I don't know how much you want to read into it but there is a delay that is placed on the entire download when negotiating file type. May be insignificant but here it is.
http://www.w3.org/Protocols/HTTP/Negotiation.html
Beyond this it is hard to really nail down which one would be "more efficient" in that they are both protocols that ride on TCP/IP and so they are very similar in nature. Heck they even both call their request for download "GET".
You may want to try to get a hint why the Professor said it wasn't first to see if you can turn the tables on him to give you a good reason why it "IS" better.
Also being a few milliseconds faster doesn't take into account that HTTP Protocol runs on a Web server and web servers are consistantly more exploited than FTP sites so throw the cost vs risk back at him and say how much downtime does a hacked web site cost.
Hope this helps some..
The server sends a GET request to the Web server to retrieve the address it has been given.
For example, when a user types http://www.example.com/1.jpg, the browser sends a GET 1.jpg command to example.com and waits for a response.
The server now responds to the browser's requests. It verifies that the given address exists, finds the necessary files, runs the appropriate scripts, exchanges cookies if necessary, and returns the results back to the browser.
If it cannot locate the file, the server sends an error message to the client.
There is also a web protocol definable feild that is checked to see how many downloads a paticular user can download and if that limit has been reached it queues up any future downloads.
The browser translates the data it has been given in to HTML and MIME encoding and displays the results to the user or in this case asks the user to save the file.
You may want to point out also that HTTP 1.0 is much slower than HTTP 1.1 because of how HTTP 1.0 does not have persistant connections and one file to the next you have to have a new connection established slowing down your overall download time.
As you mention too that HTTP Client/Server is stateless so one file to the next could result in a new connection if the last transfer took a while to complete.
One more thing to note. Currently the way web transfer work is they download them to a cache somewhere (most times your temp directory) then it copies it from there to the final destination.
This is not the case for FTP. FTP will reconstruct the requested file in real time and you can watch the byte value increase.
Resume of download is not automatic in HTTP but can be programmed in whereas most respectable FTP servers have a resume feature already built in.
This web site is an interesting one about how clients and servers negotiate what a file type is before it sends. I don't know how much you want to read into it but there is a delay that is placed on the entire download when negotiating file type. May be insignificant but here it is.
http://www.w3.org/Protocols/HTTP/Negotiation.html
Beyond this it is hard to really nail down which one would be "more efficient" in that they are both protocols that ride on TCP/IP and so they are very similar in nature. Heck they even both call their request for download "GET".
You may want to try to get a hint why the Professor said it wasn't first to see if you can turn the tables on him to give you a good reason why it "IS" better.
Also being a few milliseconds faster doesn't take into account that HTTP Protocol runs on a Web server and web servers are consistantly more exploited than FTP sites so throw the cost vs risk back at him and say how much downtime does a hacked web site cost.
Hope this helps some..
Also piggybacking off of someone elses comment and throw in a mix of my comment and you have a problem when you are downloading your max number of connection and then you go to try and refresh the page or do some sort of control command it will not allow you to do anything until a download is done.
HTTP clients are not currently built with a way to queue up downloads.
While you can program this it is not apart of the normal spec of HTTP
HTTP clients are not currently built with a way to queue up downloads.
While you can program this it is not apart of the normal spec of HTTP
Nothinman
Elite Member
- Sep 14, 2001
- 30,672
- 0
- 0
Even with HTTP you still need some sort of authentication if you want to limit upload capability and IMO FTP would be simpler because you can use file permissions to say who can/can't upload files but with HTTP the httpd is always running as the httpd user no matter who's browsing.
With the use of symlinks you can move things around all you want and not have it change the presentation the FTP client sees. And with the use of symlinks or hardlinks (depending on how the ftpd and OS work) you can chroot the ftpd to a certain directory and link in files outside you want them to be able to access, keeping the layout consistent and helping security.
Most ftpds will allow you to limit uploads based on file extension or size. It's probably not feasible to have it change dynamically (perhaps you could use quotas to enforce that per user/group) but that's an extremely rare requirement. Since clients can lie about MIME types of files they want to upload you can't reliably use that to determine what can and can't be uploaded. Sort of like how IE uses a mixture of MIME and extentions to determine what to do with a file, you send a HTML email to someone with an attached file blah.exe said to be of type audio/wav, IE sees a wav file MIME type and figures it's safe but when it goes to run it, it just uses explorer's open command which runs the file because it's an executable.
Actually that wouldn't be terribly difficult. It would require a very specialized (and yet unwritten) ftpd to do it, but it's possible.
And it's also all those extra features that make HTTP potentially slower than FTP.
It's not part of the FTP spec either.
Basically you need a scenario to really compare the two. In their most basic forms there will probably only be a difference of milliseconds. Depending on how you time it HTTP may be faster because there's no need to login like there is with FTP and many clients will CWD to the parent directory of the file you want to download before starting the download which can add another .5-1s to the FTP transfer even though it's unnecessary.
It's not part of the FTP spec either.
Basically you need a scenario to really compare the two. In their most basic forms there will probably only be a difference of milliseconds. Depending on how you time it HTTP may be faster because there's no need to login like there is with FTP and many clients will CWD to the parent directory of the file you want to download before starting the download which can add another .5-1s to the FTP transfer even though it's unnecessary.
While it isn't part of the actualy FTP RFC there are many many clients that already have a queueing system built in without having to create from scratch some way to queue up documents by the company they can purchase this.
I do agree with you on the actual login delay though but the more we discuss this the more it goes outside the actual transfer speed (login delay, queueing potential .. ect) The poster needs to find out what exactly is being clocked and why HTTP is said to be slower because if you strip off all the authentication and flexibility of programming you are down to the same Layer 3/4.
Basically you need a scenario to really compare the two. In their most basic forms there will probably only be a difference of milliseconds. Depending on how you time it HTTP may be faster because there's no need to login like there is with FTP and many clients will CWD to the parent directory of the file you want to download before starting the download which can add another .5-1s to the FTP transfer even though it's unnecessary.
While it isn't part of the actualy FTP RFC there are many many clients that already have a queueing system built in without having to create from scratch some way to queue up documents by the company they can purchase this.
I do agree with you on the actual login delay though but the more we discuss this the more it goes outside the actual transfer speed (login delay, queueing potential .. ect) The poster needs to find out what exactly is being clocked and why HTTP is said to be slower because if you strip off all the authentication and flexibility of programming you are down to the same Layer 3/4.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 24K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 19K
-
-
-
Facebook
Twitter