FTP vs HTTP
-
I have often seen/heard people say that FTP is faster than HTTP, but I wonder if this is a fallacious argument for the client. The only difference I can tell is that FTP maintains a extra control connection port open whilst HTTP does it all via the data port. However using an extra port with TCP is gonna cause a conflict of whether the data or control packet gets priority. At the end of the day a chain is only as strong as the weakest link, which is similar to data transference IMHO. So having a great server and fibreoptics etc has no real benefit when you have a mm or rusted Cu connecting you at some location. Any opinions, to blast my thoughts outta the water ? Regardz Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining. Said by Roger Wright about me.
-
I have often seen/heard people say that FTP is faster than HTTP, but I wonder if this is a fallacious argument for the client. The only difference I can tell is that FTP maintains a extra control connection port open whilst HTTP does it all via the data port. However using an extra port with TCP is gonna cause a conflict of whether the data or control packet gets priority. At the end of the day a chain is only as strong as the weakest link, which is similar to data transference IMHO. So having a great server and fibreoptics etc has no real benefit when you have a mm or rusted Cu connecting you at some location. Any opinions, to blast my thoughts outta the water ? Regardz Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining. Said by Roger Wright about me.
Id think fiber and a great server would be better than rusted Cu and a mediocre server. Just my opionion Cheers;P
-
I have often seen/heard people say that FTP is faster than HTTP, but I wonder if this is a fallacious argument for the client. The only difference I can tell is that FTP maintains a extra control connection port open whilst HTTP does it all via the data port. However using an extra port with TCP is gonna cause a conflict of whether the data or control packet gets priority. At the end of the day a chain is only as strong as the weakest link, which is similar to data transference IMHO. So having a great server and fibreoptics etc has no real benefit when you have a mm or rusted Cu connecting you at some location. Any opinions, to blast my thoughts outta the water ? Regardz Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining. Said by Roger Wright about me.
There are a pile of factors involved in optimizing performance over TCP/IP networks, so sometimes the obvious explainations can get trumped by implementation details. However, FTP will be faster than HTTP in most cases because a) there's less overhead in the FTP protocol, and b) files are usually transferred in binary format under FTP and in Base64 Encoded format in HTTP (which expands binary data by 33%) David http://www.dundas.com
-
Id think fiber and a great server would be better than rusted Cu and a mediocre server. Just my opionion Cheers;P
I was making the observation of where exists a bottleneck it doesn't make that much difference what's happening on either side of it. Regardz Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining. Said by Roger Wright about me.
-
There are a pile of factors involved in optimizing performance over TCP/IP networks, so sometimes the obvious explainations can get trumped by implementation details. However, FTP will be faster than HTTP in most cases because a) there's less overhead in the FTP protocol, and b) files are usually transferred in binary format under FTP and in Base64 Encoded format in HTTP (which expands binary data by 33%) David http://www.dundas.com
Hmmm !! Learn somethimg new every day. For a) I didn't think the difference existed because they are both app layer protocols. and for b) I had no idea base64 caused that much bloat. :-( ( Now I'm busy trying to figure out where the 33% is caused by as I thought this was counted into the transmission units ) Regardz Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining. Said by Roger Wright about me.
-
Hmmm !! Learn somethimg new every day. For a) I didn't think the difference existed because they are both app layer protocols. and for b) I had no idea base64 caused that much bloat. :-( ( Now I'm busy trying to figure out where the 33% is caused by as I thought this was counted into the transmission units ) Regardz Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining. Said by Roger Wright about me.
Colin Davies wrote: Now I'm busy trying to figure out where the 33% is caused by as I thought this was counted into the transmission units As far as I understand, you use base64 to create a textonly (printable ASCII consisting of A-Z, a-z, 0-9 and two other characters) representation of binary data. You divide the binary data in chunks of 6 bits (64 different values) and depending on the value, output one of the characters (8 bits). So, for every three binary bytes, you have four in the output, hence the 33% increase. -- LuisR ────────────── Luis Alonso Ramos Chihuahua, Mexico www.luisalonsoramos.com "Do not worry about your difficulties in mathematics, I assure you that mine are greater." -- Albert Einstein
-
Colin Davies wrote: Now I'm busy trying to figure out where the 33% is caused by as I thought this was counted into the transmission units As far as I understand, you use base64 to create a textonly (printable ASCII consisting of A-Z, a-z, 0-9 and two other characters) representation of binary data. You divide the binary data in chunks of 6 bits (64 different values) and depending on the value, output one of the characters (8 bits). So, for every three binary bytes, you have four in the output, hence the 33% increase. -- LuisR ────────────── Luis Alonso Ramos Chihuahua, Mexico www.luisalonsoramos.com "Do not worry about your difficulties in mathematics, I assure you that mine are greater." -- Albert Einstein
What an incredible waste. :-( Regardz Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining. Said by Roger Wright about me.
-
There are a pile of factors involved in optimizing performance over TCP/IP networks, so sometimes the obvious explainations can get trumped by implementation details. However, FTP will be faster than HTTP in most cases because a) there's less overhead in the FTP protocol, and b) files are usually transferred in binary format under FTP and in Base64 Encoded format in HTTP (which expands binary data by 33%) David http://www.dundas.com
Don't forget HTTP can compress on the fly, and reduce file sizes.
-
There are a pile of factors involved in optimizing performance over TCP/IP networks, so sometimes the obvious explainations can get trumped by implementation details. However, FTP will be faster than HTTP in most cases because a) there's less overhead in the FTP protocol, and b) files are usually transferred in binary format under FTP and in Base64 Encoded format in HTTP (which expands binary data by 33%) David http://www.dundas.com
David Cunningham wrote: Base64 Encoded format in HTTP (which expands binary data by 33%) Woah, I had no idea of this overhead. I knew it was true for encoding binary files into ASCII e-mails, but I had previously thought HTTP had some mechanism for transferring pure binary. I have been here a year and this is probably the best signature I've ever had.
-
David Cunningham wrote: Base64 Encoded format in HTTP (which expands binary data by 33%) Woah, I had no idea of this overhead. I knew it was true for encoding binary files into ASCII e-mails, but I had previously thought HTTP had some mechanism for transferring pure binary. I have been here a year and this is probably the best signature I've ever had.
Simon Walton wrote: David Cunningham wrote: Base64 Encoded format in HTTP (which expands binary data by 33%) Woah, I had no idea of this overhead. I knew it was true for encoding binary files into ASCII e-mails, but I had previously thought HTTP had some mechanism for transferring pure binary. You can send binary over HTTP with no problem... no need for base64.
Andy Hassall (andy@andyh.org) Space - disk usage analysis tool
-
Simon Walton wrote: David Cunningham wrote: Base64 Encoded format in HTTP (which expands binary data by 33%) Woah, I had no idea of this overhead. I knew it was true for encoding binary files into ASCII e-mails, but I had previously thought HTTP had some mechanism for transferring pure binary. You can send binary over HTTP with no problem... no need for base64.
Andy Hassall (andy@andyh.org) Space - disk usage analysis tool
Andy, you are correct, my bad. I spend so much time combing through MIME as it pertains to SMTP that the Base64 thing is stuck in my brain. HTTP (and other reliable 8-bit communication systems) can make use of the binary encoding scheme. David
-
Andy, you are correct, my bad. I spend so much time combing through MIME as it pertains to SMTP that the Base64 thing is stuck in my brain. HTTP (and other reliable 8-bit communication systems) can make use of the binary encoding scheme. David
David Cunningham wrote: MIME as it pertains to SMTP that the Base64 AH OK !!! That clears that up. I was beginning to wonder !!! Regardz Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining. Said by Roger Wright about me.
-
What an incredible waste. :-( Regardz Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining. Said by Roger Wright about me.
No embedded NULLs or other characters that could really hose things. Bse 64 is also a standard for NNTP and email attachments. Besides, HTTP was not designed for transmitting large files.