[gentoo-user] Re: replacement for ftp?

[Kai Krakow]

Am Sat, 29 Apr 2017 20:38:24 +0100
schrieb lee <lee@××××××××.de>:

> Kai Krakow <hurikhan77@×××××.com> writes:
>
> > Am Tue, 25 Apr 2017 15:29:18 +0100
> > schrieb lee <lee@××××××××.de>:
> >
> >> since the usage of FTP seems to be declining, what is a replacement
> >> which is at least as good as FTP?
> >>
> >> I'm aware that there's webdav, but that's very awkward to use and
> >> missing features.
> >
> > If you want to sync files between two sites, try rsync. It is
> > supported through ssh also. Plus, it's very fast also.
>
> Yes, I'm using it mostly for backups/copies.
>
> The problem is that ftp is ideal for the purpose, yet users find it
> too difficult to use, and nobody uses it.  So there must be something
> else as good or better which is easier to use and which ppl do use.

Well, I don't see how FTP is declining, except that it is unencrypted.
You can still use FTP with TLS handshaking, most sites should support
it these days but almost none forces correct certificates because it is
usually implemented wrong on the server side (by giving you
ftp.yourdomain.tld as the hostname instead of ftp.hostingprovider.tld
which the TLS cert has been issued for). That makes it rather pointless
to use. In linux, lftp is one of the few FTP clients supporting TLS
out-of-the-box by default, plus it forces correct certificates.

But I found FTP being extra slow on small files, that's why I suggested
to use rsync instead. That means, where you could use sftp (ssh+ftp),
you can usually also use ssh+rsync which is faster.

There's also the mirror command in lftp, which can be pretty fast, too,
on incremental updates but still much slower than rsync.

> I don't see how they would transfer files without ftp when ftp is the
> ideal solution.

You simply don't. FTP is still there and used. If you see something
like "sftp" (ssh+ftp, not ftp+ssl which I would refer to as ftps), this
is usually only ftp wrapped into ssh for security reasons. It just
using ftp through a tunnel, but to the core it's the ftp protocol. In
the end, it's not much different to scp, as ftp is really just only a
special shell with some special commands to setup a file transfer
channel that's not prone to interact with terminal escape sequences in
whatever way those may be implemented, something that e.g. rzsz needs
to work around.

In the early BBS days, where you couldn't establish a second transfer
channel like FTP does it using TCP, you had to send special escape
sequences to put the terminal into file transfer mode, and then send
the file. By that time, you used rzsz from the remote shell to initiate
a file transfer. This is more the idea of how scp implements a file
transfer behind the scenes.

FTP also added some nice features like site-to-site transfers where the
data endpoints both are on remote sites, and your local site only is
the control channel. This directly transfers data from one remote site
to another without going through your local connection (which may be
slow due to the dial-up nature of most customer internet connections).

Also, FTP is able to stream multiple files in a single connection for
transferring many small files, by using tar as the transport protocol,
thus reducing the overhead of establishing a new connection per file.
Apparently, I know only few clients that support that, and even fewer
servers which that would with.

FTP can be pretty powerful, as you see. It's just victim of its poor
implementation in most FTP clients that makes you feel it's mostly
declined. If wrapped into a more secure tunnel (TLS, ssh), FTP is still
a very good choice for transferring files, tho not the most efficient.
Depending on your use case, you get away much better using more
efficient protocols like rsync.


-- 
Regards,
Kai

Replies to list-only preferred.