On a besoin d'argumenter un vendredi ? C'est nouveau ?
Le problème avec FTP, c'est qu'il y a 2 connexions ouvertes, une pour les commandes et une pour les données. La connexion de données pose problème au niveau des firewalls et des systèmes de translation d'adresse. Rien d'insurmontable, mais c'est du boulot en plus par rapport à HTTP qui nécessite juste de pouvoir ouvrir une connexion TCP entre le client et le serveur. Ça a aussi un cout niveau trafic réseau et ça ajoute une latence supplémentaire.
Ça suffit ou il faut que je continue en parlant de sécurité ?
Non, plus il y a de fichier, plus l’overhead de HTTP est grand.
On parle de quelques dizaines d'octets par fichier, c'est pas une grosse affaire. Et au passage, l'overhead du FTP est bien plus grand, parce que la connexion de données doit être réouverte pour chaque fichier (un handshake TCP par fichier, c'est considérable si on a beaucoup de petits fichiers)
[^] # Re: Question de troll :]
Posté par Buf (Mastodon) . En réponse au journal Révolution dans la gestion des modules Weboob. Évalué à 2. Dernière modification le 20 janvier 2012 à 17:49.
On a besoin d'argumenter un vendredi ? C'est nouveau ?
Le problème avec FTP, c'est qu'il y a 2 connexions ouvertes, une pour les commandes et une pour les données. La connexion de données pose problème au niveau des firewalls et des systèmes de translation d'adresse. Rien d'insurmontable, mais c'est du boulot en plus par rapport à HTTP qui nécessite juste de pouvoir ouvrir une connexion TCP entre le client et le serveur. Ça a aussi un cout niveau trafic réseau et ça ajoute une latence supplémentaire.
Ça suffit ou il faut que je continue en parlant de sécurité ?
On parle de quelques dizaines d'octets par fichier, c'est pas une grosse affaire. Et au passage, l'overhead du FTP est bien plus grand, parce que la connexion de données doit être réouverte pour chaque fichier (un handshake TCP par fichier, c'est considérable si on a beaucoup de petits fichiers)