Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jacques Caron
Salut,
On Thu, 17 Mar 2005 23:28:20 +0100, zebulon wrote:
je sais pas si je suis dans le bon forum, mais sinon tout est dans le titre.. qu'est ce qu'est le plus verbeux : http ou ftp ?
Ca dépend du contexte. Une fois qu'on est en mode transfert proprement dit, les deux sont sensiblement pareils, puisqu'on envoie bêtement le fichier directement dans la connexion TCP. HTTP a cependant quelques options qui peuvent ajouter un peu d'overhead (mode "chuncked") et d'autres qui permettent de réduire (compression).
Par contre pour le reste de la transaction (établissement de la connexion, demande du fichier, etc.) j'aurais tendance à dire que HTTP est moins gourmand, mais c'est limite, ça dépend beaucoup de la configuration du client et du serveur et du nombre de headers qu'ils se balancent. Mais HTTP a au moins l'avantage de pouvoir tout transférer en une seule connexion TCP alors que FTP réclame une connexion de contrôle + une connexion TCP par transfert.
Bref, YMMV.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On Thu, 17 Mar 2005 23:28:20 +0100, zebulon <o@rfer.fref> wrote:
je sais pas si je suis dans le bon forum, mais sinon tout est dans le
titre..
qu'est ce qu'est le plus verbeux : http ou ftp ?
Ca dépend du contexte. Une fois qu'on est en mode transfert proprement
dit, les deux sont sensiblement pareils, puisqu'on envoie bêtement le
fichier directement dans la connexion TCP. HTTP a cependant quelques
options qui peuvent ajouter un peu d'overhead (mode "chuncked") et
d'autres qui permettent de réduire (compression).
Par contre pour le reste de la transaction (établissement de la connexion,
demande du fichier, etc.) j'aurais tendance à dire que HTTP est moins
gourmand, mais c'est limite, ça dépend beaucoup de la configuration du
client et du serveur et du nombre de headers qu'ils se balancent. Mais
HTTP a au moins l'avantage de pouvoir tout transférer en une seule
connexion TCP alors que FTP réclame une connexion de contrôle + une
connexion TCP par transfert.
Bref, YMMV.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Thu, 17 Mar 2005 23:28:20 +0100, zebulon wrote:
je sais pas si je suis dans le bon forum, mais sinon tout est dans le titre.. qu'est ce qu'est le plus verbeux : http ou ftp ?
Ca dépend du contexte. Une fois qu'on est en mode transfert proprement dit, les deux sont sensiblement pareils, puisqu'on envoie bêtement le fichier directement dans la connexion TCP. HTTP a cependant quelques options qui peuvent ajouter un peu d'overhead (mode "chuncked") et d'autres qui permettent de réduire (compression).
Par contre pour le reste de la transaction (établissement de la connexion, demande du fichier, etc.) j'aurais tendance à dire que HTTP est moins gourmand, mais c'est limite, ça dépend beaucoup de la configuration du client et du serveur et du nombre de headers qu'ils se balancent. Mais HTTP a au moins l'avantage de pouvoir tout transférer en une seule connexion TCP alors que FTP réclame une connexion de contrôle + une connexion TCP par transfert.
Bref, YMMV.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Xavier Roche
Jacques Caron wrote:
Ca dépend du contexte. Une fois qu'on est en mode transfert proprement dit, les deux sont sensiblement pareils, puisqu'on envoie bêtement le fichier directement dans la connexion TCP.
Assez équivalent (au minimum: "GET /foo/bar HTTP/1.0rnHost: foobarrnrn" contre "CWD foornRETR barrn". Mais bon, l'overhead est totalement ridicule pour des fichiers un peu importants. Et puis on compare deux univers totalement différents, l'un pour accéder à des fichers, l'autre pour accéder à des ressources plus abstraites.
HTTP a cependant quelques options qui peuvent ajouter un peu d'overhead (mode "chuncked") et d'autres qui permettent de réduire (compression).
Plus un équivalent du "seek" du FTP en mode 'avancé', qui permet de reprendre le téléchargement en gérant en plus la mise à jour éventuelle (on peut faire un équivalent du ftp, mais en mieux géré, avec des vrais dates et/ou la gestion des versions, et pas des trucs immondes parsés à la main comme sur ftp, où de mémoire on est obligé de repérer la taille d'un fichier dans la réponse si le SIZE est pas implémenté)
Mais HTTP a au moins l'avantage de pouvoir tout transférer en une seule connexion TCP alors que FTP réclame une connexion de contrôle + une connexion TCP par transfert.
Sans parler du fait que FTP est un protocole baisé par construction et prévu pour UN protocole de transport (ipv4), avec des morceaux de couche ipv4 dans la couche applicative, ce qui fait qu'on a du tout péter pour ipv6, et qu'on devra tout péter à chaque fois qu'il faudra adapter une autre couche. Je n'ai d'ailleurs jamais compris le pourquoi de la connexion "data": on peut même pas initier plusieurs "downloads" (ou uploads) simultanés sur une connexion de contrôle, si je ne m'abuse, ce qui aurait été la seule et unique justification pour tout ce bordel. Encore un protocole écrit lors d'une beuverie :p
Jacques Caron wrote:
Ca dépend du contexte. Une fois qu'on est en mode transfert proprement
dit, les deux sont sensiblement pareils, puisqu'on envoie bêtement le
fichier directement dans la connexion TCP.
Assez équivalent (au minimum: "GET /foo/bar HTTP/1.0rnHost:
foobarrnrn" contre "CWD foornRETR barrn". Mais bon, l'overhead
est totalement ridicule pour des fichiers un peu importants. Et puis on
compare deux univers totalement différents, l'un pour accéder à des
fichers, l'autre pour accéder à des ressources plus abstraites.
HTTP a cependant quelques
options qui peuvent ajouter un peu d'overhead (mode "chuncked") et
d'autres qui permettent de réduire (compression).
Plus un équivalent du "seek" du FTP en mode 'avancé', qui permet de
reprendre le téléchargement en gérant en plus la mise à jour éventuelle
(on peut faire un équivalent du ftp, mais en mieux géré, avec des vrais
dates et/ou la gestion des versions, et pas des trucs immondes parsés à
la main comme sur ftp, où de mémoire on est obligé de repérer la taille
d'un fichier dans la réponse si le SIZE est pas implémenté)
Mais HTTP a au moins l'avantage de pouvoir tout transférer
en une seule connexion TCP alors que FTP réclame une connexion de
contrôle + une connexion TCP par transfert.
Sans parler du fait que FTP est un protocole baisé par construction et
prévu pour UN protocole de transport (ipv4), avec des morceaux de couche
ipv4 dans la couche applicative, ce qui fait qu'on a du tout péter pour
ipv6, et qu'on devra tout péter à chaque fois qu'il faudra adapter une
autre couche. Je n'ai d'ailleurs jamais compris le pourquoi de la
connexion "data": on peut même pas initier plusieurs "downloads" (ou
uploads) simultanés sur une connexion de contrôle, si je ne m'abuse, ce
qui aurait été la seule et unique justification pour tout ce bordel.
Encore un protocole écrit lors d'une beuverie :p
Ca dépend du contexte. Une fois qu'on est en mode transfert proprement dit, les deux sont sensiblement pareils, puisqu'on envoie bêtement le fichier directement dans la connexion TCP.
Assez équivalent (au minimum: "GET /foo/bar HTTP/1.0rnHost: foobarrnrn" contre "CWD foornRETR barrn". Mais bon, l'overhead est totalement ridicule pour des fichiers un peu importants. Et puis on compare deux univers totalement différents, l'un pour accéder à des fichers, l'autre pour accéder à des ressources plus abstraites.
HTTP a cependant quelques options qui peuvent ajouter un peu d'overhead (mode "chuncked") et d'autres qui permettent de réduire (compression).
Plus un équivalent du "seek" du FTP en mode 'avancé', qui permet de reprendre le téléchargement en gérant en plus la mise à jour éventuelle (on peut faire un équivalent du ftp, mais en mieux géré, avec des vrais dates et/ou la gestion des versions, et pas des trucs immondes parsés à la main comme sur ftp, où de mémoire on est obligé de repérer la taille d'un fichier dans la réponse si le SIZE est pas implémenté)
Mais HTTP a au moins l'avantage de pouvoir tout transférer en une seule connexion TCP alors que FTP réclame une connexion de contrôle + une connexion TCP par transfert.
Sans parler du fait que FTP est un protocole baisé par construction et prévu pour UN protocole de transport (ipv4), avec des morceaux de couche ipv4 dans la couche applicative, ce qui fait qu'on a du tout péter pour ipv6, et qu'on devra tout péter à chaque fois qu'il faudra adapter une autre couche. Je n'ai d'ailleurs jamais compris le pourquoi de la connexion "data": on peut même pas initier plusieurs "downloads" (ou uploads) simultanés sur une connexion de contrôle, si je ne m'abuse, ce qui aurait été la seule et unique justification pour tout ce bordel. Encore un protocole écrit lors d'une beuverie :p
"Sebastien Vincent" wrote in message news:423a9af8$0$3121$
Encore un protocole écrit lors d'une beuverie :p Moi aussi le protocole ftp me laisse perplexe :/
La plus grosse aberration à mon avis est surtout que les gens continuent de l'utiliser malgré tous ces problèmes :-) Rsync ou sftp sont de bien meilleurs candidats au transfert de fichiers à mon avis.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Sebastien Vincent" <svincent@idems.fr> wrote in message
news:423a9af8$0$3121$8fcfb975@news.wanadoo.fr
Encore un protocole écrit lors d'une beuverie :p
Moi aussi le protocole ftp me laisse perplexe :/
La plus grosse aberration à mon avis est surtout que les gens
continuent de l'utiliser malgré tous ces problèmes :-)
Rsync ou sftp sont de bien meilleurs candidats au transfert de fichiers
à mon avis.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Sebastien Vincent" wrote in message news:423a9af8$0$3121$
Encore un protocole écrit lors d'une beuverie :p Moi aussi le protocole ftp me laisse perplexe :/
La plus grosse aberration à mon avis est surtout que les gens continuent de l'utiliser malgré tous ces problèmes :-) Rsync ou sftp sont de bien meilleurs candidats au transfert de fichiers à mon avis.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Raphael Bouaziz
Le Fri, 18 Mar 2005 13:01:10 +0000 (UTC), Eric Lalitte a écrit dans le message :
Encore un protocole écrit lors d'une beuverie :p Moi aussi le protocole ftp me laisse perplexe :/
La plus grosse aberration à mon avis est surtout que les gens continuent de l'utiliser malgré tous ces problèmes :-) Rsync ou sftp sont de bien meilleurs candidats au transfert de fichiers à mon avis.
On l'utilise parce que ... C'est un bon protocole.
En HTTP je dois lancer trois ou quatre téléchargements simultanés pour remplir une ligne IP/ADSL Max.
En FTP, un seul téléchargement suffit à obtenir le débit maximal.
Je passe sur l'aspect serveur : en HTTP je peine péniblement pour dépasser les 40-50 Mbit/s sur un serveur, en FTP je monte à 135 Mbit/s sans trop de soucis.
-- Raphael Bouaziz.
Le Fri, 18 Mar 2005 13:01:10 +0000 (UTC), Eric Lalitte a écrit
dans le message <ff3c18773a27e29a099d8f1de93236d5.28089@mygate.mailgate.org> :
Encore un protocole écrit lors d'une beuverie :p
Moi aussi le protocole ftp me laisse perplexe :/
La plus grosse aberration à mon avis est surtout que les gens
continuent de l'utiliser malgré tous ces problèmes :-)
Rsync ou sftp sont de bien meilleurs candidats au transfert de fichiers
à mon avis.
On l'utilise parce que ... C'est un bon protocole.
En HTTP je dois lancer trois ou quatre téléchargements simultanés
pour remplir une ligne IP/ADSL Max.
En FTP, un seul téléchargement suffit à obtenir le débit maximal.
Je passe sur l'aspect serveur : en HTTP je peine péniblement pour
dépasser les 40-50 Mbit/s sur un serveur, en FTP je monte à 135 Mbit/s
sans trop de soucis.
Le Fri, 18 Mar 2005 13:01:10 +0000 (UTC), Eric Lalitte a écrit dans le message :
Encore un protocole écrit lors d'une beuverie :p Moi aussi le protocole ftp me laisse perplexe :/
La plus grosse aberration à mon avis est surtout que les gens continuent de l'utiliser malgré tous ces problèmes :-) Rsync ou sftp sont de bien meilleurs candidats au transfert de fichiers à mon avis.
On l'utilise parce que ... C'est un bon protocole.
En HTTP je dois lancer trois ou quatre téléchargements simultanés pour remplir une ligne IP/ADSL Max.
En FTP, un seul téléchargement suffit à obtenir le débit maximal.
Je passe sur l'aspect serveur : en HTTP je peine péniblement pour dépasser les 40-50 Mbit/s sur un serveur, en FTP je monte à 135 Mbit/s sans trop de soucis.
-- Raphael Bouaziz.
Jacques Caron
Salut,
On Fri, 18 Mar 2005 14:58:51 +0000 (UTC), Raphael Bouaziz wrote:
On l'utilise parce que ... C'est un bon protocole.
On l'utilise parce qu'on est bien obligé dans certains cas :-(
En HTTP je dois lancer trois ou quatre téléchargements simultanés pour remplir une ligne IP/ADSL Max.
En FTP, un seul téléchargement suffit à obtenir le débit maximal.
Ce n'est certainement pas lié au protocole lui-même. Comme je le disais, dans un cas comme dans l'autre, une fois qu'on est en mode transfert, donc l'immense majorité du temps sur un gros fichier, l'un comme l'autre jettent assez bêtement le fichier directement sur la connexion TCP, et la connexion TCP n'a pas de raison particulière de se comporter différemment dans les deux cas.
Il faudrait faire la comparaison entre des situations exactement analogues (même fichier, même machine pour le serveur HTTP et le serveur FTP, même client, même heure), je pense qu'on verrait assez clairement qu'il y a très peu d'écart dans ce cas de figure, à moins d'un problème d'implémentation dans le client ou le serveur de l'un ou l'autre protocoles.
Je viens d'ailleurs de faire le test, et j'obtiens le même débit dans les deux cas de figure (en fait un petit peu moins en FTP), aussi bien sur un WAN (avec un fichier de 10 Mo) que sur un LAN (avec un fichier de 1 Go), sur lequel j'atteinds sans problème plus de 10 Mo/s en HTTP, de quoi remplir une ligne IP/ADSL Max à fond les ballons.
Dans des circonstances différentes, toutes sortes de facteurs peuvent limiter le débit max de la connexion TCP (et donc du transfert FTP ou HTTP), en particulier la latence, la taille des fenêtres, la MTU utilisée et celle effectivement diposnible. Si tu compares un FTP sur un serveur très disponible juste de l'autre côté de l'IX le plus proche avec un HTTP sur un serveur un peu chargé en Californie, c'est clair que tu observeras ce phénomène.
Je passe sur l'aspect serveur : en HTTP je peine péniblement pour dépasser les 40-50 Mbit/s sur un serveur, en FTP je monte à 135 Mbit/s sans trop de soucis.
Pour la même chose? 40-50 Mbit/s pour un serveur qui sert des tonnes de fichiers de quelques Ko, donc certains sont éventuellement générés dynamiquement, c'est quand même pas la même chose que servir quelques gros fichiers statiques...
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On Fri, 18 Mar 2005 14:58:51 +0000 (UTC), Raphael Bouaziz
<bouaziz@nerim.net> wrote:
On l'utilise parce que ... C'est un bon protocole.
On l'utilise parce qu'on est bien obligé dans certains cas :-(
En HTTP je dois lancer trois ou quatre téléchargements simultanés
pour remplir une ligne IP/ADSL Max.
En FTP, un seul téléchargement suffit à obtenir le débit maximal.
Ce n'est certainement pas lié au protocole lui-même. Comme je le disais,
dans un cas comme dans l'autre, une fois qu'on est en mode transfert, donc
l'immense majorité du temps sur un gros fichier, l'un comme l'autre
jettent assez bêtement le fichier directement sur la connexion TCP, et la
connexion TCP n'a pas de raison particulière de se comporter différemment
dans les deux cas.
Il faudrait faire la comparaison entre des situations exactement analogues
(même fichier, même machine pour le serveur HTTP et le serveur FTP, même
client, même heure), je pense qu'on verrait assez clairement qu'il y a
très peu d'écart dans ce cas de figure, à moins d'un problème
d'implémentation dans le client ou le serveur de l'un ou l'autre
protocoles.
Je viens d'ailleurs de faire le test, et j'obtiens le même débit dans les
deux cas de figure (en fait un petit peu moins en FTP), aussi bien sur un
WAN (avec un fichier de 10 Mo) que sur un LAN (avec un fichier de 1 Go),
sur lequel j'atteinds sans problème plus de 10 Mo/s en HTTP, de quoi
remplir une ligne IP/ADSL Max à fond les ballons.
Dans des circonstances différentes, toutes sortes de facteurs peuvent
limiter le débit max de la connexion TCP (et donc du transfert FTP ou
HTTP), en particulier la latence, la taille des fenêtres, la MTU utilisée
et celle effectivement diposnible. Si tu compares un FTP sur un serveur
très disponible juste de l'autre côté de l'IX le plus proche avec un HTTP
sur un serveur un peu chargé en Californie, c'est clair que tu observeras
ce phénomène.
Je passe sur l'aspect serveur : en HTTP je peine péniblement pour
dépasser les 40-50 Mbit/s sur un serveur, en FTP je monte à 135 Mbit/s
sans trop de soucis.
Pour la même chose? 40-50 Mbit/s pour un serveur qui sert des tonnes de
fichiers de quelques Ko, donc certains sont éventuellement générés
dynamiquement, c'est quand même pas la même chose que servir quelques gros
fichiers statiques...
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Fri, 18 Mar 2005 14:58:51 +0000 (UTC), Raphael Bouaziz wrote:
On l'utilise parce que ... C'est un bon protocole.
On l'utilise parce qu'on est bien obligé dans certains cas :-(
En HTTP je dois lancer trois ou quatre téléchargements simultanés pour remplir une ligne IP/ADSL Max.
En FTP, un seul téléchargement suffit à obtenir le débit maximal.
Ce n'est certainement pas lié au protocole lui-même. Comme je le disais, dans un cas comme dans l'autre, une fois qu'on est en mode transfert, donc l'immense majorité du temps sur un gros fichier, l'un comme l'autre jettent assez bêtement le fichier directement sur la connexion TCP, et la connexion TCP n'a pas de raison particulière de se comporter différemment dans les deux cas.
Il faudrait faire la comparaison entre des situations exactement analogues (même fichier, même machine pour le serveur HTTP et le serveur FTP, même client, même heure), je pense qu'on verrait assez clairement qu'il y a très peu d'écart dans ce cas de figure, à moins d'un problème d'implémentation dans le client ou le serveur de l'un ou l'autre protocoles.
Je viens d'ailleurs de faire le test, et j'obtiens le même débit dans les deux cas de figure (en fait un petit peu moins en FTP), aussi bien sur un WAN (avec un fichier de 10 Mo) que sur un LAN (avec un fichier de 1 Go), sur lequel j'atteinds sans problème plus de 10 Mo/s en HTTP, de quoi remplir une ligne IP/ADSL Max à fond les ballons.
Dans des circonstances différentes, toutes sortes de facteurs peuvent limiter le débit max de la connexion TCP (et donc du transfert FTP ou HTTP), en particulier la latence, la taille des fenêtres, la MTU utilisée et celle effectivement diposnible. Si tu compares un FTP sur un serveur très disponible juste de l'autre côté de l'IX le plus proche avec un HTTP sur un serveur un peu chargé en Californie, c'est clair que tu observeras ce phénomène.
Je passe sur l'aspect serveur : en HTTP je peine péniblement pour dépasser les 40-50 Mbit/s sur un serveur, en FTP je monte à 135 Mbit/s sans trop de soucis.
Pour la même chose? 40-50 Mbit/s pour un serveur qui sert des tonnes de fichiers de quelques Ko, donc certains sont éventuellement générés dynamiquement, c'est quand même pas la même chose que servir quelques gros fichiers statiques...
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
