Comparer HTTP et FTP pour transférer des fichiers
Quels sont les avantages (ou les limitations) de l’un sur l’autre pour le transfert de fichiers sur Internet?
(Je connais des formes sécurisées des deux protocoles. J'aimerais entendre des comparaisons à travers des expériences personnelles en termes de performances, de fiabilité, de limitations de taille de fichiers, etc.)
Voici un comparaison de performance des deux. HTTP est plus réactif pour la demande-réponse de petits fichiers, mais FTP peut être meilleur pour les gros fichiers s'il est réglé correctement. FTP était généralement considéré comme plus rapide. FTP nécessite un canal de contrôle et l'état doit être maintenu en plus de l'état TCP mais pas HTTP. Il y a 6 transferts de paquets avant le début du transfert de données en FTP, mais seulement 4 en HTTP.
Je pense qu'une couche correctement optimisée TCP aurait plus d’effet sur la vitesse que la différence entre les protocoles de couche d’application. Le Plan directeur Sun Comprendre le réglage de TCP contient des détails.
Voici un autre bonne comparaison des caractéristiques individuelles de chaque protocole.
Je viens de comparer un transfert de fichier via FTP et HTTP:
- sur deux très bonnes connexions au serveur
- en utilisant le même fichier .Zip de 1 Go
- dans les mêmes conditions de réseau (testées les unes après les autres)
Le résultat:
- via FTP: 6 minutes
- en utilisant HTTP: 4 minutes
- en utilisant un logiciel de téléchargement http simultané (
fdm): 1 minute
Donc, fondamentalement, dans une situation de "vie réelle":
1) HTTP est plus rapide que FTP lors du téléchargement d’un gros fichier.
2) HTTP peut utiliser le téléchargement en bloc parallèle, ce qui le rend six fois plus rapide que FTP, en fonction des conditions du réseau.
De nombreux pare-feu abandonnent les connexions sortantes qui ne sont pas sur les ports 80 ou 443 (http & https); certains abandonnent même les connexions à ces ports qui ne sont pas HTTP (S). FTP peut ou peut ne pas être autorisé, sans parler des modes actif/PASV.
De plus, HTTP/1.1 permet de bien meilleures requêtes partielles ("envoi uniquement de l'octet 123456 à la fin du fichier"), requêtes conditionnelles et mise en cache ("envoi uniquement si le contenu a été modifié/si la date de dernière modification a été modifiée") et la compression du contenu. (gzip).
HTTP est beaucoup plus facile à utiliser via un proxy.
D'après mes preuves anecdotiques, HTTP est plus facile à utiliser avec des connexions abandonnées/lentes/irrégulières; par exemple. il n'est pas nécessaire d'établir (ré) établir une session de connexion avant de (ré) initier le transfert.
OTOH, HTTP est sans état, il vous faudrait donc vous authentifier et créer une piste de "qui a fait quoi quand".
La seule différence de vitesse que j'ai remarquée est le transfert de nombreux petits fichiers: HTTP avec le traitement en pipeline est plus rapide (réduit les allers-retours, notamment sur les réseaux à latence élevée).
Notez que HTTP/2 offre encore plus d’optimisations, alors que le protocole FTP n’a pas connu de mises à jour depuis des décennies (et même les extensions de FTP ont peu d’absorption par les utilisateurs). Donc, à moins que vous ne transfériez des fichiers sur une machine à remonter le temps, HTTP semble avoir gagné.
(Tangentiellement: il existe des protocoles mieux adaptés au transfert de fichiers, tels que rsync ou BitTorrent, mais ils n’ont pas autant d’esprit partagé, alors que HTTP est Everywhere ™)
Une considération est que FTP peut utiliser des ports non standard, ce qui peut rendre difficile l’obtention de pare-feu (surtout si vous utilisez SSL). HTTP est généralement sur un port connu, ce qui pose rarement problème.
Si vous décidez d'utiliser FTP, assurez-vous de lire à propos de FTP actif et passif .
En termes de performances, à la fin de la journée, ils crachent tous les deux directement des fichiers TCP connexions devraient donc être à peu près les mêmes.