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
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
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.
https://openconnect.netflix.com/publications/asiabsd_2015_tl...
edit: check this post first
Only in (very) high-bandwidth cases and (maybe!) for low-power cases. For most things it's just added complexity for no benefit.
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.