FTP is traditionally used for transferring files. Recently, HTTP(S) has become a more popular way of transferring files. This article talks about the pros and cons of using FTP(S) verses HTTP(S) for transferring files. Before we get into this, let's discuss what HTTP and FTP are.
FTP (File Transfer Protocol) is a network protocol used to transfer data files over a network. FTP, file transferring requires a client and a server. Users will need an FTP client in order to communicating with the FTP server. The client initiates sending or requesting data from the server. The server handles all the stored data that the client has sent.
HTTP (Hyper Text Transfer Protocol) is an application-level protocol used by the World Wide Web. This protocol defines how messages are formatted and delivered. The data communication beings with a request sent from a client and ends with the response received from a web server. HTTP and FTP both are protocols which allow data communication between client and server. These protocols have been around for a long time now and are still being used by many businesses. Many businesses and users use FTP and HTTP as file transferring solutions.
One important feature in HTTP is the human element, meaning a human being is usually on the client's end. This feature enables the HTTP protocol with endless possibilities when it comes to features. FTP however, does not have this feature. FTP protocol was designed to communicate directly with machines so, there are no additional features that can be implemented, or very difficult to implement to benefit clients. With that note, let's take a look at some of the systemic qualities for FTP and HTTP as a file transfer server:
|-Has the ability to transfer multiple files, even multiple directories at the same time. This makes file transferring very quick and reliable.|| -HTTP without any additional logic is typically slower than FTP. That is because HTTP POST requests cannot be very large. Therefore, large files must be chopped into multiple request.
-On the other hand, smart algorithms can be used in HTTP to compensate for this speed lag, which allow HTTP to be actually faster.
Two such examples are:
1 - Compression
2 - RSYNC
|-Simultaneously upload files while other files are being downloaded.||-Unlike FTP, HTTP supports pipe-lining. This means that a client can immediately request for the next transfer even before the previous one has ended. This allows multiple files to get sent without any delay between each files.|
|-Allows the continuity of transferring files if a connection is lost. In case your machine suddenly reboots or connection is suddenly lost, you can resume the file transfer right where it was instead of starting all over again.||-The logic of resuming files must be implemented by the application. Many applications have implemented proprietary methods allowing them to resume incomplete transfers.|
|-FTP must create a new connection to the server for each new data transfer. Constantly doing new connections can hinder performance due to having to frequently do new handshakes/connections all the time.||-HTTP has persistent connections (Also known as keep-alive or connection reuse). A client can use only a single connection to a server and continuously use the same connection for any amount of data transfers. Persistent connections make a much better TCP performance.|
|-Secure Channel - FTP by itself is not secure. Therefore, you can either use FTPS or SFTP to secure the communication. SFTP requires SSH, which does not work on Windows without a third-party application.||-HTTP is made secure by using HTTPS, preventing a middleman from peeking in between.|
|-A pair of user ID/passwords are typically used to authenticate users.||-Although Basic Access Authentication (https://en.wikipedia.org/wiki/Basic_access_authentication) is provided in HTTP, which is similar to the authentication mechanism provided by FTP, a better approach is to handle authentication at the application level.
-Application level authentication provides additional benefits such as:
1. 2 Factor authentication
2. IP blocking if too many invalid login attempts are detected
3. Alerts can be generated
4. Audit logs
|-Anonymous access can be granted by creating an "anonymous" user. Most servers allow anonymous access for downloads. Although it can be created for uploads as well, most administrators do not do that to prevent misuse.||-Anonymous uploads/downloads are typically possible by crafting a specific URL that is only sent to specific recipients. In addition to a custom URL, applications can also put an expiration date as well as optionally protect it with a password.|
|-Although transport layer encryption can be added by using FTPS, there is no way to provide application layer encryption.||-Application layer encryption can be added. Consider an example where a lawyer has to share a file with their clients. An HTTP based file sharing server can encrypt the confidential files with the last 4 digits of the clients social security number before serving the files.|
|-FTP does not have a set of headers that send metadata. Meta data can be fetched by explicitly running the DIR command.||-Unlike FTP, HTTP have headers that send meta data. This allows information such as date created, date modified, and file size to be transferred and viewed, allowing the HTTP client to abort transfers if nothing has changed.|
|-FTP protocol lacks the ability of reporting. However, many FTP servers provide custom logging and reporting facilities.||
-Similarly, every HTTP servers provide custom logging mechanism. User applications running on the server can provide additional features such as:
1. Upload/download notifications
2. Policy enforcement
3. Triggering custom logic after transfer completion
|-FTP protocol does not have any provision for connection client's information. For example, it cannot determine the operating system of the connecting client.||
-HTTP headers provide very useful information of the connecting client. As a result, an application can intelligently steer a connecting client to appropriate content.
-For example, if the server can determine the operating system of the connecting client, it can send appropriate file for that OS.
|-By default FTP requires two ports: TCP/20 and TCP/21. Although by using FTP in passive mode, this port requirement is reduced to just TCP/21, many firewalls typically block these ports.||-HTTP requires only one port TCP/80 or TCP/443 if SSL is used. Most companies do not block these ports and therefore, HTTP based applications typically work without any changes in the firewall.|
|-FTP clients are script friendly. Most operating systems have built-in client allowing you to write scripts that can upload/download files.||-HTTP on the other hand requires custom application if scripting is required. For example, SynaMan comes with a CLI (command line interface) allowing users to use scripting.|
|-Content expiration is typically not handled by the protocol. If a publisher wants to deny downloads, they must manually delete the necessary files||
-Logic for content expiration can be built by custom applications, allowing users to put expiration dates on downloadable files.
-Additionally, applications can also be configured to allow certain number of downloads. For example, further downloading fails once a pre-defined number of downloads are over.
|No further business logic can be added when using FTP other than what is provided by the protocol or the FTP server.||
Applications running inside a web server can provide endless features that are otherwise not available. Here are a few examples:
1. Dynamic Content - change the contents based on the time of the day, operating system used by the client, or perhaps a question this the user must answer before getting access to the file.
2. Business Logic - when a file containing information such as an invoice is transferred, a notification will automatically get sent to the accountant's email.
|Created on:||Jan 31, 2019|
|Last updated on:||Jan 28, 2023|
Would it be possible to compare the data total required for each. Example I am using a Cellular Modem, each byte is counted against my data plan. What is the difference in bytes through sending a 1k file with FTP vs. HTTP? Will the added header info of HTTP etc. add a fairly sizable overhead to the transfer?
This is an answer to Paul's question. Both FTP and HTTP will have some overhead. It is difficult to say what will be the exact size but I'd say a 1K overhead is a good assumption.
A 1K overhead looks big when you're trying to transfer 1K file. However, it is negligible when your file size is 100MB.
You should be able to get the exact size difference by using a sniffing tool or a proxy server in between to see the difference.