Slashdot Mirror
FTP Is 40 Years Old
An anonymous reader writes "FTP celebrates its 40th birthday tomorrow. Originally launched as the RFC 114 specification, which was published on 16 April 1971, FTP is arguably even more important today than when it was born. Frank Kenney, vice president of global strategy for US managed file transfer company Ipswitch, said that the protocol we know as FTP today is 'a far cry from when Abhay Bushan, a student at MIT, wrote the original specifications for FTP.' According to Kenney, the standard has grown from 'a simple protocol to copy files over a TCP-based network [to] a sophisticated, integrated model that provides control, visibility, compliance and security in a variety of environments, including the cloud.'"
FTP is a hideous protocol. The client connects to the server with one TCP connection, and then when a file (or directory listing) is requested, the server opens up another TCP connection back to the client. This is a nightmare for firewalls. There is also passive mode where the client initiates the second connection to the server, but it is only slightly less hideous.
As awful as HTTP is, it is infinitely better than FTP. Sadly HTTP is mostly one way, but these days for anything that isn't being broadcast to the public (the web), you are betterm off using ssh/scp.
Let FTP die already.
Do we really need to bring buzzwords like the cloud into this? It's a file transfer protocol, aptly named, for transferring data to another system. It could be in a cloud or in a cave for all I care, as long as it has port 21 open.
Now die!
When software gets to be around 40 years of age, wrinkles that were once minor are more and more apparent, what was once new and exciting isn't so much anymore, and it gets rather set in its ways and resistant to change. Decisions made in its youth often become a cause of later regret, and there's a certain amount of jealously of those who are now doing the same job it once did but in a snazzier way.
But at the same time, it's likely to be far more established and dependable than its younger counterparts. You can count on it getting the job done, one way or another. It won't be flashy, but it will work.
I am officially gone from
Asking the vice president of global strategy of a company built around its FTP client to comment on the relevance of FTP is a bit like asking an Adobe marketing executive about the importance of Flash, no?
Quote FTFA "Join us in a toast to FTP - at 40 years of age, it’s lasted well and looks like it will remain a relevant technology for years to come."
That is like saying we should still be driving the Model T and expect it to still be around.
EA David Gardner -"... but the consumers have proven that actually what they want is fun."
According to Kenney, the standard has grown from 'a simple protocol to copy files over a TCP-based network [to] a sophisticated, integrated model that provides control, visibility, compliance and security in a variety of environments, including the cloud.
Actually, FTP predates TCP by 10 years and 679 RFCs. Hint: TCP is defined in RFC 793.
Ask Slashdot: Where bad ideas meet poor googling skills.
Kermit is the way to go.
that the grand FTP sites like Walnut Creek didn't last this long. RIP cdrom.com, RIP gamehead, RIP happypuppy, RIP filefactory, RIP gamesdomain, and RIP sunet.se
n00b.
RIP wsmr-simtel20.army.mil
FTP died in 1993, murdered by httpd and the Mosaic browser. I watched it die. I shed no tears.
I agree (though if you are going to consider sftp, please also consider ftps), but it has been surprisingly durable. Rivals, historically, have included fsp, scp, rsync, uucp, WAIS, gopher and ftpmail. Some, like WAIS and gopher, also provided a far superior interface to the traditional FTP client.
Of these, scp and rsync are the only ones still in use today and I don't know of any anonymous FTP sites that provides scp, though I think kernel.org provides rsync.
About the only significant change to FTP since it began was that people used to use archie to find programs. (Archie, for those too young to remember, was a search engine specifically for anonymous FTP sites. You gave it a regexp, it gave you every site that had files that matched and the full directory path of those files. Because it was specialized, there was no risk of clutter. Equally, there was no chance it would survive into the era of web crawlers and generalized search engines.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
but I need to say SFTP is the only option in today's world of HIPAA and net neutrality. FTP-SSL, still, is just another layer over the already ubiquitous FTP.
Yes, SFTP is yet another wrapper against FTP, but it is much more secure compared to FTP over SSL. SSL only offers limited encryption options. SFTP, on the other hand, can encrypt data flowing over public keys with encryption streams 1024-bit or higher.
The FTP we know today originated in RFC 765, published June 1980, and was designed to work over TCP. RFC 114 defines a completely different protocol for file transfer that has nothing to do with FTP.
The only nonsucky thing about FTP is that you can use FXP to transfer files between two remote servers without piping it through your client. For example, suppose you have FTP logins on two servers and each has a nice, fast Internet connection. You are on dialup and need to copy database backups from one server to the other. You can use FTP to tell the first to upload to the second's IP address, and tell the second to recv a file from the first's IP address. Nothing but the status messages go through your poor local modem.
You can do the same with by ssh'ing to the first server and scp'ing a file from it to the second, but that requires generating keypairs and copying the public keys around. If you're nitpicky about having separate keypairs on each SSH client machines (and you really should be!), and you have 20 hosts, then you'd have to copy 19 public keys to each machine. With FTP+FXP, you need an FTP login on each of the hosts. That's especially nice if the sending server is a public repository where you don't have anything but anonymous FTP access.
This isn't exactly a killer feature for most people, but it's kind of slick if you ever actually need it.
Dewey, what part of this looks like authorities should be involved?
As recently as 5 years ago, I set up an FTP server for use by a number of financial firms to send orders into a specialized stock trading system
$100M worth of orders were FTPed into that system using PGP encrypted text files (with public key fingerprints verified via telephone to make sure that all of the keys were valid). IP filtering was used to give a small additional layer of security.
This system was set up in a short period of time (3 weeks from inception including writing the file spec and setting up the servers) and FTP was the one thing that all parties could count on having (client operating systems included Windows, various flavors of Unix, IBM VM, and I think one customer had Tandem Nonstop). Pushing files via HTTP PUT is possible, but it's a lot easier to script an FTP file transfer.
With ftp I can download whole folders with boatloads of files and more folders, and the rest my network stay up just fine. Transfer speeds are top notch. It lets other traffic through.. Bittorrent? I might put it on when I crash for the night.
ftp through a nice private tunnel.. hasn't failed me yet..
For justice, we must go to Don Corleone
I agree (though if you are going to consider sftp, please also consider ftps), but it has been surprisingly durable. Rivals, historically, have included fsp, scp, rsync, uucp, WAIS, gopher and ftpmail. Some, like WAIS and gopher, also provided a far superior interface to the traditional FTP client.
Of these, scp and rsync are the only ones still in use today and I don't know of any anonymous FTP sites that provides scp, though I think kernel.org provides rsync.
About the only significant change to FTP since it began was that people used to use archie to find programs. (Archie, for those too young to remember, was a search engine specifically for anonymous FTP sites. You gave it a regexp, it gave you every site that had files that matched and the full directory path of those files. Because it was specialized, there was no risk of clutter. Equally, there was no chance it would survive into the era of web crawlers and generalized search engines.
) . . . . . . whew!
Here's a little more background on the various generations of the FTP protocol.
First Generation (1971-1980)
The original specification for FTP (RFC 114) was published in 1971 by Abhay Bhushan of MIT. This standard introduced down many concepts and conventions that survive to this day including: ASCII vs. "binary" transfers, Username authentication (passwords were "elaborate" and "not suggested" at this stage) , "Retrieve", "Store", "Append", "Delete" and "Rename" commands, Partial and resumable file transfer , A protocol "designed to be extendable", Two separate channels: one for "control information", the other for "data", and Unresolved character translation and blocking factor issues
Second Generation (1980-1997)
The second generation of FTP (RFC 765) was rolled out in 1980 by Jon Postel of ITI. This standard retired RFC 114 and introduced more concepts and conventions that survive to this day, including: A formal architecture for separate client/server functions and two separate channels, Site-to-site transfers, Passive (a.k.a. "firewall friendly") transfer mode and The 3-digits-followed-by-text command response convention. ...and RFC 765 was replaced by RFC 959 (which formalized directory navigation) in 1985.
Third Generation (1997-current)
The third and current generation of FTP was a reaction to two technologies that RFC 959 did not address: SSL/TLS and IPv6.
Most FTP software now conforms to RFC 2228 for FTPS. Oddly enough, there are still a LOT of file transfer packages that still don't have IPv6 or EPSV support. The RFCs beyond IPv6 and EPSV support are pretty well baked, so if you're still dealing with a vendor without those attributes, consider that a big red flag.
Also keep an eye on draft-ietf-ftpext2-hash and draft-peterson-streamlined-ftp-command-extensions - that's where the action is in FTP today.
You expect me to hire a portrait-man? I adjust my monocle and twirl my mustache in indignation, you son of a loose woman!
How can I believe you when you tell me what I don't want to hear?
scp doesn't distract people with popups, doesn't eat resources, tends to be more stable, doesn't require a GUI interface, won't allow people to get distracted with porn and/or Cowboy Neil (or, indeed, porn of Cowboy Neil), is far friendlier to network resources than HTTP (HTTP is =HORRIBLE= for file transfers), and prevents people listening in to what you download.
From a security standpoint, very few FTP sites provide signatures, FTP and HTTP can suffer mitm attacks (all it takes is a trojaned machine anywhere in the chain between you and the site), FTP is Bad News because firewalls tend not to like it, and HTTP is Bad News because web clients have this obnoxious habit of trying to process anything they receive - which tends to be where most of the security holes come from.
From a server standpoint, HTTP connections keep connection state information for several minutes. This is a heavy resource drain. Web servers are also fairly heavy beasts - they've got to maintain a lot of internal state, the protocol is heavy, etc. It doesn't take much to exhaust a machine running, say, Apache 2.x of resources. On the other hand, any simple copy-a-file mechanism can afford to preserve almost no state at all, the processing of the requests is usually trivial and doesn't need hundreds of support libraries, and you don't need keepalives.
Which brings us back to security. Simple Is Good. Complex Is Bad. Every possible arc through the code is a potential haven for bugs. I dare anyone on Slashdot to even imagine how many arcs there are on a Cold Fusion site (you've the app, Cold Fusion itself, JRun4, Java and the web server, and any bug in any of that could potentially result in a security hole or a server crash). Now consider how many arcs there are in what is essentially a linear network copy process.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
That just made me rofl
ftps wraps up all the issues with firewalling FTP, and makes them 1000 times worse, by adding encryption. You still have two connections, you still have pseudo-random ports that are such a joy to firewall & load balancer admin's every where, and you pile the joy of encrypting the port number so that you have to terminate the SSL session at each intervening firewall. Pure, unadulterated joy if you sell cpus for routers. Take a 10 foot pole, and gingerly push FTPS away... It is a really bad idea. secsh ftp (what is more often called SFTP, but confusingly was the original name used for ftps) is the way to go. I don't get why they don't adopt the RFC already, it's been an expired draft for nearly five years!
ASCII was the correct decision at the time, and it is still occasionally useful today. For example, At work, we send and or post a lot of data, to a lot of different clients. The following has happenned twice now:
so yeah, it was corrupt.
Note that this would also corrupt text being sent to windows boxes, who would expect a <CR> before the <LF> on text files. It's happenned twice, because five years later when we went from Redhat 7 fo Debian Etch, the tweak got lost, had to figure it out again.
I find your assertation that HTTP servers have to maintain more state and are heavier than scp servers insane.
Do you actually know how either of those protocols work? HTTP servers don't maintain ANY state, at all. The protocol is literally: Open a TCP connection, send a single line with a file path, send a newline, get some headers, a newline, and the file. That's it. A full featured HTTP server can be implemented with a 15 line shell script run from inetd.
It is much lighter weight than scp could ever dream of, mainly because it doesn't have to negotiate an encrypted connection. Of course, you can negoiate an encrypted connection...and HTTP is still more lightweight because scp keeps track of directories as it copies, so, strictly speaking, it is 'heavier' and keeps more 'state'. (Although supporting recursive copy from the server, instead of requiring the clients to request, is obviously a useful feature. But if we get into 'useful features' HTTP comes out ahead, so you argued exactly the opposite.)
You think all HTTP servers are like apache, but perhaps you should learn that that the most common implimentation of a protocol is not always the most lightweight. In fact, it's almost never the most lightweight.
If corporations are people, aren't stockholders guilty of slavery?