Je dois développer une application Java) qui doit lire certains fichiers sur le réseau, les éditer et les remettre en place.
Le problème est que je faisais toujours (sur le réseau) des opérations de fichiers via le protocole FTP. Mais, j'ai récemment entendu parler de Webdav, basé sur HTTP.
Quelqu'un a-t-il remarqué une différence (en termes de vitesse) entre eux? Lequel est le meilleur ? Pourquoi ont-ils "inventé" Webdav si le FTP est bon pour cela?
WebDAV présente les avantages suivants par rapport au FTP:
En travaillant via une connexion TCP, il est plus facile de le configurer pour contourner les pare-feu, les NAT et les mandataires. Dans FTP, le canal de données peut causer des problèmes avec la bonne configuration NAT.
Encore une fois, à cause d'une connexion TCP, qui peut être persistante, WebDAV serait un peu plus rapide que FTP lors du transfert de nombreux petits fichiers - il n'est pas nécessaire d'établir une connexion de données pour chaque fichier.
La compression GZIP est une norme pour HTTP mais pas pour FTP (oui, MODE Z est offert en FTP, mais il n’est défini dans aucune norme).
HTTP a un large choix de méthodes d'authentification qui ne sont pas définies dans FTP. Par exemple. Les authentifications NTLM et Kerberos étant courantes dans HTTP et FTP, il est difficile d’obtenir une prise en charge appropriée à moins d’écrire les côtés client et serveur de FTP.
WebDAV prend en charge les transferts partiels et les envois partiels FTP ne sont pas possibles (vous ne pouvez pas écraser un bloc au milieu du fichier).
Il y a encore une chose à considérer (selon que vous contrôliez le serveur ou non) - SFTP (protocole de transfert de fichier SSH, sans aucun lien avec FTP). SFTP est plus riche en fonctionnalités que WebDAV et SFTP est un protocole permettant d’accéder aux systèmes de fichiers distants, tandis que WebDAV a été conçu avec l’abstraction (WebDAV était destiné aux "documents", tandis que SFTP était destiné aux fichiers et aux répertoires). SFTP présente tous les avantages mentionnés ci-dessus pour WebDAV et est plus populaire parmi les administrateurs et les développeurs.
Réponse pour question - Why did they "invent" Webdav
WebDAV signifie Web Distributed Authoring and Versioning
.
Internet n'était tout simplement pas destiné à la consommation de ressources via des URL ( niform Resource Locator )
Mais c'est ce que c'est devenu.
Parce que HTTP avait une forte sémantique pour extraire des ressources (GET) et (HEAD). (POST) a couvert le nombre d'opérations sémantiques alors que (DELETE) était enveloppé de méfiance. HTTP manquait d'autres qualités telles que les opérations multi-ressources.
En résumé, il s'agissait d'un protocole lu et non d'un protocole d'écriture.
Vous voudriez rendre vos ressources (URL) disponibles pour la récupération en les téléchargeant via FTP et de nombreux mécanismes.
WebDAV était censé fournir l'histoire manquante d'Internet: Prise en charge de la création de ressources via le même mécanisme HTTP. Il a étendu sa sémantique, introduit le nouveau HTTP VERBS.
Il a également introduit le mécanisme permettant non seulement de lire, écrire, modifier et supprimer une ressource (uris), mais également de demander des informations sur les propriétés méta de la ressource et de la modifier. Ce n'est pas que vous ne pouviez pas le faire avant, mais cela a été fait par un mécanisme de porte arrière.
Vous voyez donc que certains des mêmes mécanismes que ceux que vous attendez des opérations de fichiers sur des ressources de bureau à Internet sont prévus.
Voici certaines des analogies:
MKCOL ----- make collection ----- similar to make folder
PROPGET ---- get properties (meta?) --- same as get info or extended attributes on mac
PROPPATCH --- modify properties
COPY ---- cp
MOVE ---- mv
J'espère que j'ai défini certains des nobles objectifs de WebDAV en tant qu'extension de HTTP pour prendre en charge la création sur Internet. Je ne sais pas si nous y sommes parvenus.
Pour votre question
Votre application est un client et devra faire avec quel mécanisme est disponible - FTP ou WebDAV de l'autre côté. Si WebDAV est disponible, vous pouvez l'utiliser. Mais il faudra un certain temps pour s’habituer à la sémantique. FTP a une sémantique limitée et excelle en simplicité. Si vous l'utilisez déjà, ne le changez pas.
Ce qui est plus rapide
Cela s'apparente à répondre, ce qui est plus rapide HTTP ou FTP?
Sur une note sournoise, si c'était un tel problème, nous n'aurions pas téléchargé/téléchargé des fichiers via HTTP;)
Depuis [~ # ~] dav [~ # ~] fonctionne [~ # ~] http [~ # ~] , vous bénéficiez de tous les avantages de HTTP que FTP ne peut pas fournir.
Par exemple:
authentification forte, chiffrement, prise en charge du proxy et mise en cache.
Il est vrai que vous pouvez en obtenir une partie grâce à SSH , mais la infrastructure HTTP est beaucoup plus largement déployée que SSH. De plus, SSH ne dispose pas du vaste éventail d'outils, de bibliothèques de développement et d'applications que HTTP.
Les transferts DAV (ainsi, les transferts HTTP) sont également plus efficaces que FTP. Vous pouvez utiliser plusieurs transferts via une seule et même connexion TCP, alors que FTP nécessite une nouvelle connexion pour chaque fichier transféré (plus la connexion de contrôle).
Cela dépend de ce que vous voulez faire. Par exemple, le temps système nécessaire pour récupérer une liste de fichiers sur FTP est de 7 octets (LIST -a), contre 370 octets avec Webdav (PROPFIND + 207 Multi Status).
Pour l'envoi de certains fichiers, la surcharge est moins importante sur FTP que sur Webdav, etc.
Si vous devez envoyer/récupérer beaucoup de petits fichiers, FTP s’avérera plus rapide (utiliser plusieurs connexions pour un traitement en pipeline correct et par fichier TCP). Si vous envoyez/recevez de grandes fichiers, c’est la même chose pour les deux technologies, les frais généraux seront négligeables.
Veuillez consulter: http://www.philippheckel.com/files/syncany-heckel-thesis.pdf
date de modification du fichier:
il semble y avoir une différence de traitement entre ftp et webdav avec le temps de modification des fichiers.
Il semble qu'il existe une 'commande' dans ftp pour conserver ce temps (plusieurs clients et serveurs ftp prétendent le faire), alors que webdav, si mes souvenirs sont exacts, peut obtenir la date de modification du fichier mais ne peut pas le définir lors du téléchargement.
le client owncloud et certains clients Webdav propriétaires semblent avoir une solution de contournement, mais cela ne fonctionne que dans leur logiciel
selon l'usage, c'est un argument de poids en faveur de ftp. Je ne veux pas que la date de modification de mes fichiers soit == la date de téléchargement. Après un téléchargement ultérieur, je ne serais pas en mesure de dire par date quelle version du fichier que j'ai.
Webdav présente des avantages par rapport à FTP en ce qui concerne le passage facile de pare-feu (pas de sockets de contrôle/données séparés). La vitesse devrait être à peu près la même que les deux protocoles transfèrent le fichier sur un socket TCP brut.