Hacker News Reader

Comment by phil21 | Hacker News Reader

The control/data connections are actually pretty neat, and for the era (actual working Internet) it was a good idea that worked quite well. I understand it looks "hacky" today - but that's largely due to far worse hacks lower down the stack.

NAT came along, and everyone broke everything. Now you can't make up neat protocols like this any more - everything must be user-initiated TCP or server based. I do wonder how much development and innovation this has held back. Even games back in the day had far more interesting network models - that were more sustainable long-term.

NAT was likely the first major crack in the wall of the open Internet, making it much weaker and the users more compliant than it previously was. I strongly believe that's one of the major reasons why we have what we're left with today.

View on HN

Don't forget that FTP also lets you connect two servers together with the data connection going between them, so can transfer a file from one server to another without downloading it. (http://www.proftpd.org/docs/howto/FXP.html)

Of course this awesome ability was exploited by hackers (the FTP Bounce Attack: https://www.cert.org/historical/advisories/CA-1997-27.cfm - and they say that inventing fancy names for attacks is a new thing). This is why we can't have nice things :-)

Yea I used to use FXP it was handy to be a client actor in that role but... exploited and abandoned mostly.

Thank you, guys. You prompted me to learn a bit about the protocol. I want to share what I learned after skimming over the RFC.

A typical session looks like:

    $ telnet ftp.kernel.org 21
    Trying 149.20.4.69...
    Connected to ftp.all.kernel.org.
    Escape character is '^]'.
    220 Welcome to kernel.org
    USER anonymous
    331 Please specify the password.
    PASS
    230 Login successful.
    PASV
    227 Entering Passive Mode (149,20,4,69,119,142).

Then I was baffled. What does 149,20,4,69,119,142 mean? Okay, 149,20,4,69 looks like an IP address for ftp.kernel.org. But what do they want me to do with 119,142? Turns out it's a port number divided into two octets. Basically they are asking me to connect to port 119 * 256 + 142 = 30606.

So, on the second terminal I run:

    $ telnet 149.20.4.69 30606
    Trying 149.20.4.69...
    Connected to 149.20.4.69.
    Escape character is '^]'.

Back to the first one:

    LIST
    150 Here comes the directory listing.
    226 Directory send OK.

And I get the listing I requested, on the second terminal:

    drwxr-xr-x    9 ftp      ftp          4096 Dec 01  2011 pub
    Connection closed by foreign host.
    $

Instead of using PASV, you can request the FTP server to connect back to you, with PORT. First, you need to start listening on your WAN interface (if you have one; if you don't, you are out of luck) with `nc -l your.ip.goes.here 2560`. Then, request the server to connect by typing `PORT your,ip,goes,here,10,0` (NB: use commas, not dots). Of course, don't forget to replace your.ip.goes.here with your real WAN IP address.

Cheers.

This was cool! Thank you for sharing!

Why is this design better than the HTTPS design, where you make an (integrity-protected) request for a file and you get a (framed, integrity-protected) response for that file over the same TCP connection?

I understand the argument for peer-to-peer gaming, but I don't see why for file transfer, FTP's design is better.

The big difference I see is that a separate TCP connection has separate flow control and avoids head-of-line blocking for multiple simultaneous transfers, but for static file transfers, the only cause of head-of-line blocking should be actual congestion, which would impact every connection simultaneously, right? (That is, it's better for the Internet to route all traffic between two hosts, where neither side is CPU-bound, over a single TCP connection so that TCP can do its thing.)

And certainly active mode (server connects back to client) doesn't seem like it has any benefits to congestion or anything else: once a connection is established, it doesn't matter who established it.

Imagine you're not bandwidth-limited and you want to transfer multiple files. One is on Disk A, one is on Disk B, one is on NFS, etc. Sending them all at once exploits parallelism, and the transfer on the faster disk doesn't get stuck behind the transfer on the slower disk.

One file per connection also makes the implementation simpler. If you want to use one TCP connection for multiple transfers then you need some kind of a header and logic to determine start and end of file, and new control messages get delayed in queue behind already-buffered data. If you have a data connection for exactly one file then you just call sendfile() and then close().

And transferring a file with active mode FTP looks like this:

  Client -> Server: I want to transfer a file, connect to 1.2.3.4:12345.
  Server -> Client: TCP SYN to 1.2.3.4:12345

Passive mode requires another half trip latency:

  Client -> Server: I want to transfer a file, passive mode.
  Server -> Client: OK, connect to 4.3.2.1:54321.
  Client -> Server: TCP SYN to 4.3.2.1:54321

A different protocol could avoid the extra latency by having the server always use the same port, but that makes the implementation more complicated again. The server could get a data connection from the client before it gets the associated control message. Now it has to deal with matching them up, another timeout in case the control message never arrives, etc.

It's possible to run FTP over TLS. Hardly anybody does that because it makes the NAT problem worse, because then the NAT device can't even snoop the control connection and map the port. FTP programs could fix this by mapping the data port using something like NAT-PMP or PCP, but I'm not aware of any that currently do.

Unfortunately, these days crypto really is a mandatory feature, and sendfile doesn't work with TLS anyway. (IMO it should - secure communication should be an OS-level service rather than requiring each application to figure it out, just like the OS provides TCP rather than requiring each application to implement reliable connections - but that's another story.)

Hmmm. sendfile is great because it lets the kernel arrange for DMA straight from disk to the network card, in addition to bypassing context switches and copies to and from userspace buffers. If the kernel gains an SSL stack (the encrypted version of the file is going to be different for each connection), you can't DMA and you'll need to make copies into kernelspace buffers to do the encryption on. Is skipping the context switch enough to make a meaningful performance different?

Yes. And I believe Solaris was the first to discover this. Here's a paper Netflix put out covering their first attempt. Measurable gains, hopefully more coming in the future.

https://openconnect.netflix.com/publications/asiabsd_2015_tl...

edit: check this post first

https://news.ycombinator.com/item?id=12037748

If you do it that way you could add hardware encryption support to the network card and be back to using DMA.

Oh, that's fascinating and awesome! Thanks for the links.

> Is skipping the context switch enough to make a meaningful performance different?

Only in (very) high-bandwidth cases and (maybe!) for low-power cases. For most things it's just added complexity for no benefit.

FTP is broken regardless of NAT. It flat out does not work with a default deny firewall policy.

FTP invented in either 1971 or 1985 depending on whether you think RFC 114 or RFC 959 best describes the basic protocol.

Simple packet-filtering firewalls invented in 1988.

In addition you can force passive mode and confine FTP to a range of ports on just about every server and client out there. So your statement that FTP "flat out does not work" is untrue, unless you mean that your firewall is so much default-deny that you cannot even open incoming ports.

However, while it makes me a bit sad, I have to agree that there are better, simpler and more secure protocols now for downloading files. HTTP/2 in particular.

How well do HTTP/2 handle the transfer of whole directory trees?

It's still a little kludgy, but it got a lot better in November when Firefox joined Chrome and Edge in implementing "folder upload". https://developer.mozilla.org/en-US/Firefox/Releases/50#File...

In the use case of kernel.org a folder download feature would be needed, maybe even recursive.

We offer rsync for that purpose.

Good point, I didn't really think of that. I have used wget -r but that's not very HTML 5 lol

There's webdav, but it seems to me it never caught on for some reason, and it's mostly dead these days.

I tried implementing WebDAV servers some 10+ years ago. Back then this was a major pain with different clients expecting and sending different properties etc. No idea how this looks these days.

I think I last tried it four years ago or so. Not much had changed. I briefly used Apache as a server; I think the server was fine, but the open source clients were flaky at best. I also used to have a hosting account that included WebDAV support, among others, but I never got any client to work with it except for the web interface bolted on top of that thing.

I'm surprised to see WebDAV mentioned here, to be honest, I thought it was a dead horse everywhere except in enterprise.

How about WebDAV? Is that minimally relevant these days? If not, what has superseded it?

The modern web is much more about routes, resources, and URLs than directories and files.

...and can you transfer data from one server to another without downloading it locally?

rsync will do it nicely.

By sequentially transmitting whole directory trees? FTP-the-protocol never had anything useful to say here. It's always been about FTP-the-client and these didn't need things like "control channels" and "active mode" to do what they're doing.

FTP is a pretty conceited protocol, and one that deserves to go away. People say it made more sense in the 80's, but I was there and even then *NIX/Solaris admins found FTP to be about as much fun as that IRC pingback identd service; which is to say not very fun.

Sorry, but HTTP/2 is not a panacea for everything, especially for transferring large files. FTP would actually transfers files faster than HTTP/2.

Agreed. HTTP2 is garbage.

Reply on news.ycombinator.com