http://mywiki.wooledge.org/FtpMustDie

    Retrieving a single file from an FTP server involves an unbelievable number of back-and-forth handshaking steps.

    1. The client makes a TCP socket connection to the FTP server’s control port and waits for the TCP handshake to be completed.
    2. The client waits for the server to send its “banner”.
    3. The client sends the username to the server and waits for a response.
    4. The client sends the password to the server and waits for a response.
    5. The client sends a SYST command to the server and waits for a response.
    6. The client sends a TYPE I command to the server and waits for a response. (This may happen later, but it must happen at some point.)
    7. If the user needs to change directories on the server, the client sends another command to the server and waits for a response.
    8. (In active mode) the client sends a PORT command to the server and waits for a response. (In passive mode, this would go in the opposite direction, but it’s still another round trip.)
    9. A data connection (an entire new TCP socket connection, with the full three-way handshake) is established.
    10. The bytes of data are sent over the data connection.
    11. The client waits for the server to send a 2xx message on the control connection to indicate successful transfer.
    12. The client sends a QUIT command to the server and waits for the server to say good-bye.

    That’s ten full round trips to get one file, and that’s if you count TCP socket connections as just one round trip! (In reality, they’re more involved than that.)
    Let’s see how many round trips it takes to get a file over HTTP:

    1. The HTTP client makes a TCP socket connection to the HTTP server.
    2. The HTTP client sends a GET command to the HTTP server, including the URL, the HTTP protocol version, the virtual host name, and various optional headers, all at once, and waits for a response.
    3. There is no step three. The response we just got includes the entire data stream. We’re done!

    That’s two round trips (counting the TCP socket as just one). By that admittedly simple metric, HTTP is five times as efficient as FTP for fetching a single file from a server.
    Both FTP and HTTP become more efficient if you transfer more than one file at a time, of course. With FTP, you don’t have to send the username and password again for each new file you transfer within the same session. But HTTP has persistent sockets, so you can ask for another object (file) within the same TCP connection there as well.

    从FTP服务器检索单个文件需要难以置信的来回握手步骤。

    1. 客户端将TCP套接字连接到FTP服务器的控制端口，并等待TCP握手完成。
    2. 客户端等待服务器发送其“横幅”。
    3. 客户端将用户名发送到服务器，并等待响应。
    4. 客户端向服务器发送密码并等待响应。
    5. 客户端发送系统命令发送到服务器并等待响应。
    6. 客户端发送I型命令发送到服务器并等待响应。(这种情况可能会在以后发生，但必须在某一时刻发生。)
    7. 如果用户需要更改服务器上的目录，则客户端将另一个命令发送到服务器并等待响应。
    8. (在活动模式下)客户端发送港命令发送到服务器并等待响应。(在被动模式下，这将向相反的方向发展，但这仍是另一次往返。)
    9. 建立一个数据连接(一个完整的tcp套接字连接，具有完整的三路握手).
    10. 数据的字节通过数据连接发送。
    11. 客户端等待服务器在控制连接上发送一条2xx消息，以指示成功的传输。
    12. 客户端发送退出命令发送到服务器，并等待服务器说再见.

    那是十全程往返一文件，如果您将TCP套接字连接计算为一次往返，那就是！(实际上，他们的参与程度比这还要高。)
    让我们看看在HTTP上获得一个文件需要多少往返：

    1. HTTP客户端与HTTP服务器建立TCP套接字连接。
    2. HTTP客户端发送到达命令发送到HTTP服务器，包括URL、HTTP协议版本、虚拟主机名和各种可选标头，所有这些都是一次性的，并等待响应。
    3. 没有第三步。我们刚刚得到的响应包括整个数据流。我们已完成!

    那是二往返(仅将TCP套接字计算为一个)。通过公认的简单度量，HTTP是五倍的效率作为从服务器获取单个文件的FTP。
    当然，如果一次传输多个文件，FTP和HTTP都会变得更高效。使用FTP，您不必为在同一会话中传输的每个新文件再次发送用户名和密码。但是HTTP有持久的套接字，所以您也可以在同一个TCP连接中请求另一个对象(文件)。
    如果要在检索到的文件(wget-N或curl-R)上设置时间戳，则必须获得完整的目录列表。