Quels sont les avantages (ou limites) de l'un par rapport à l'autre pour le transfert de fichiers sur Internet?
(Je connais les 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 fichier, etc.)
Réponses:
Voici une comparaison des performances des deux. HTTP est plus réactif pour les demandes-réponses des petits fichiers, mais FTP peut être meilleur pour les gros fichiers s'il est correctement réglé. FTP était généralement considéré comme plus rapide. FTP nécessite qu'un canal de contrôle et un état soient maintenus en plus de l'état TCP, mais pas HTTP. Il y a 6 transferts de paquets avant que les données ne commencent à être transférées en FTP mais seulement 4 en HTTP.
Je pense qu'une couche TCP correctement réglée aurait plus d'effet sur la vitesse que la différence entre les protocoles de la couche application. Le Sun Blueprint Understanding Tuning TCP contient des détails.
Voici une autre bonne comparaison des caractéristiques individuelles de chaque protocole.
Je viens de comparer un transfert de fichiers via FTP et HTTP:
Le résultat:
fdm): 1 minuteDonc, fondamentalement dans une situation «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 de blocs parallèles, ce qui le rend 6 fois plus rapide que FTP en fonction des conditions du réseau.
De nombreux pare-feu abandonnent les connexions sortantes qui ne sont pas vers les ports 80 ou 443 (http & https); certains abandonnent même les connexions à ces ports qui ne sont pas HTTP (S). FTP peut être autorisé ou non, sans parler des modes actifs / PASV.
En outre, HTTP / 1.1 permet de bien meilleures requêtes partielles ("envoyer uniquement de l'octet 123456 à la fin du fichier"), des requêtes conditionnelles et de la mise en cache ("envoyer uniquement si le contenu a changé / si la date de la 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 à faire fonctionner avec des connexions abandonnées / lentes / irrégulières; par exemple, il n'est pas nécessaire de (ré) établir une session de connexion avant de (ré) lancer le transfert.
OTOH, HTTP est sans état, vous devrez donc vous authentifier et créer vous-même une trace de "qui a fait quoi et quand".
La seule différence de vitesse que j'ai remarquée est le transfert de nombreux petits fichiers: HTTP avec pipelining est plus rapide (réduit les allers-retours, surtout perceptible sur les réseaux à forte latence).
Notez que HTTP / 2 offre encore plus d'optimisations, alors que le protocole FTP n'a pas vu de mises à jour depuis des décennies (et même les extensions de FTP ont une adoption insignifiante par les utilisateurs). Donc, à moins que vous ne transfériez des fichiers via une machine à remonter le temps, HTTP semble avoir gagné.
(Tangentiellement: il existe des protocoles mieux adaptés pour le transfert de fichiers, comme rsyncou BitTorrent, mais ceux-ci n'ont pas autant de partage d'esprit, alors que HTTP est Everywhere ™)
Une considération est que FTP peut utiliser des ports non standard, ce qui peut rendre difficile l'accès aux pare-feu (surtout si vous utilisez SSL). HTTP est généralement sur un port connu, c'est donc rarement un problème.
Si vous décidez d'utiliser FTP, assurez-vous de lire sur FTP actif et passif .
En termes de performances, à la fin de la journée, ils crachent tous les deux des fichiers directement via des connexions TCP, ce qui devrait donc être à peu près le même.