Webdav 또는 FTP 중 어떤 파일 액세스가 가장 좋습니까?
네트워크에서 일부 파일을 읽고 편집 한 다음 다시 넣어야하는 Java 애플리케이션을 개발해야합니다.
문제는 내가 항상 FTP 프로토콜을 통해 (네트워크를 통해) 파일 작업을 수행했다는 것입니다. 하지만 최근에 HTTP 기반 인 Webdav에 대해 들었습니다.
누구든지 그들 사이의 차이 (속도 측면에서)를 알아 차렸습니까? 어느 것이 최고입니까? FTP가 좋은 경우 Webdav를 "발명"한 이유는 무엇입니까?
WebDAV는 FTP에 비해 다음과 같은 장점이 있습니다.
하나의 TCP 연결을 통해 작업하면 방화벽, NAT 및 프록시를 우회하도록 구성하는 것이 더 쉽습니다. FTP에서 데이터 채널은 적절한 NAT 설정에 문제를 일으킬 수 있습니다.
하나의 TCP 연결 (영구적 일 수 있음)로 인해 WebDAV는 많은 작은 파일을 전송할 때 FTP보다 약간 빠릅니다. 각 파일에 대해 데이터 연결을 만들 필요가 없습니다.
GZIP 압축은 HTTP의 표준이지만 FTP에는 적용되지 않습니다 (예, MODE Z는 FTP에서 제공되지만 어떤 표준에도 정의되어 있지 않습니다).
HTTP에는 FTP에 정의되지 않은 다양한 인증 방법이 있습니다. 예 : NTLM 및 Kerberos 인증은 HTTP에서 일반적이며 FTP에서는 FTP의 클라이언트 측과 서버 측을 모두 작성하지 않는 한 적절한 지원을 받기가 어렵습니다.
WebDAV는 부분 전송을 지원하며 FTP에서는 부분 업로드가 불가능합니다 (즉, 파일 중간에있는 블록을 덮어 쓸 수 없음).
고려해야 할 사항이 한 가지 더 있습니다 (서버 제어 여부에 따라 다름)-SFTP (SSH 파일 전송 프로토콜, 어떤 방식 으로든 FTP와 관련이 없음). SFTP는 WebDAV보다 기능이 더 풍부하고 SFTP는 원격 파일 시스템에 액세스하기위한 프로토콜 인 반면 WebDAV는 추상화를 염두에두고 설계되었습니다 (WebDAV는 "문서"용이고 SFTP는 파일 및 디렉토리 용입니다). SFTP는 WebDAV에 대해 위에서 언급 한 모든 이점을 가지고 있으며 관리자와 개발자 모두에게 더 인기가 있습니다.
질문에 대한 답변- Why did they "invent" Webdav
WebDAV는 Web Distributed Authoring and Versioning
.
인터넷은 URL ( Uniform Resource Locator )을 통한 리소스 소비를 의미하지 않았습니다.
그러나 그것이 된 것입니다.
HTTP에는 리소스 (GET) 및 (HEAD) 가져 오기에 대한 강력한 의미가 있기 때문입니다. (POST)는 (DELETE)가 불신에 가려진 동안 의미 론적 연산의 수에 대한 커버리지를 제공했습니다. HTTP에는 다중 리소스 작업과 같은 다른 특성이 없었습니다.
간단히 말해서, 프로토콜 쓰기가 아니라 읽기 프로토콜이었습니다.
FTP 및 여러 메커니즘을 통해 리소스 (URL)를 업로드하여 가져올 수 있도록 할 수 있습니다.
WebDAV는 인터넷의 누락 된 이야기를 제공하기로되어있었습니다. 동일한 메커니즘 HTTP를 통한 저작 리소스 지원. 의미를 확장하고 새로운 HTTP VERBS를 도입했습니다.
또한 리소스 (uris)를 읽고, 쓰고, 수정하고, 삭제할뿐만 아니라 리소스의 메타 속성을 조회하고 수정하는 메커니즘도 도입했습니다. 전에는 할 수 없었던 것이 아니라 백도어 메커니즘을 통해 이루어졌습니다.
보시다시피, 데스크탑의 파일 작업에서 기대하는 것과 동일한 메커니즘을 인터넷 리소스로 가져 왔습니다.
다음은 몇 가지 비유입니다.
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
나는 인터넷 저작을 지원하기 위해 HTTP에 대한 확장으로서 WebDAV의 고상한 목표 중 일부를 설정하기를 바랍니다. 우리가 그것을 달성했는지 확실하지 않습니다.
귀하의 질문에
응용 프로그램은 클라이언트이므로 사용 가능한 메커니즘 (다른 쪽의 FTP 또는 WebDAV)을 사용해야합니다. WebDAV를 사용할 수 있으면 사용할 수 있습니다. 그러나 의미론에 익숙해지는 데는 시간이 걸립니다. FTP는 의미가 제한되어 있으며 단순성이 뛰어납니다. 이미 사용 중이라면 변경하지 마십시오.
더 빠릅니다
그것은 응답과 비슷합니다. 어떤 것이 더 빠른 HTTP 또는 FTP입니까?
교활한 메모에서 그러한 문제라면 HTTP를 통해 파일을 다운로드 / 업로드하지 않았을 것입니다.)
DAV 는 HTTP를 통해 작동 하므로 FTP가 제공 할 수없는 HTTP의 모든 이점을 얻을 수 있습니다.
예를 들면 :
강력한 인증 , 암호화 , 프록시 지원 및 캐싱 .
SSH 를 통해이 중 일부를 얻을 수 있다는 것은 사실 이지만 HTTP 인프라 는 SSH보다 훨씬 광범위하게 배포됩니다. 또한 SSH에는 HTTP가 수행하는 도구, 개발 라이브러리 및 애플리케이션의 광범위한 보완 기능이 없습니다.
DAV 전송 (예, HTTP 전송)도 FTP보다 효율적입니다. 단일 TCP 연결을 통해 여러 전송을 파이프 라인 할 수 있지만 FTP에는 전송 된 각 파일 (및 제어 연결 포함)에 대해 새 연결이 필요합니다.
무엇을하고 싶은지에 따라 다릅니다. 예를 들어 파일 목록을 가져 오기위한 FTP의 오버 헤드는 7 바이트 (LIST -a)이고 Webdav (PROPFIND + 207 Multi Status)에서는 370 바이트입니다.
일부 파일을 보내는 경우 Webdav보다 FTP에서 오버 헤드가 적습니다.
많은 작은 파일을 보내거나 가져와야하는 경우 FTP가 더 빠릅니다 (올바른 파이프 라이닝 및 파일 당 TCP 연결을 위해 다중 연결 사용). 대용량 파일을주고받는 경우 두 기술 모두 동일하므로 오버 헤드는 무시할 수 있습니다.
참조 : http://www.philippheckel.com/files/syncany-heckel-thesis.pdf
파일 수정 시간 :
ftp와 webdav가 파일 수정 시간을 처리하는 방법에 차이가있는 것 같습니다.
그 시간을 보존하기 위해 ftp에 '명령'이있는 것 같습니다 (여러 ftp 클라이언트와 서버가이를 수행한다고 주장함). 반면 webdav는 올바르게 기억하면 파일 수정 날짜를 가져올 수 있지만 업로드시 설정할 수는 없습니다.
owncloud 클라이언트 및 일부 고유 webdav 클라이언트에는 해결 방법이있는 것 같지만 해당 소프트웨어에서만 작동합니다.
depending on usage, that is a stong argument in favour of ftp. I don't want my files to have their modification date == upload date. After a later download, I would not be able to tell by date which version of the file I have.
Webdav has advantages over FTP regarding easy passing of firewalls (no separate control/data sockets). Speed should be roughly the same as both protocols transfer the file over a raw tcp socket.
참고URL : https://stackoverflow.com/questions/11216884/which-file-access-is-the-best-webdav-or-ftp
'Programing' 카테고리의 다른 글
Python의 전용 변수 및 메서드 (0) | 2020.11.18 |
---|---|
javascript int를 float로 변환 (0) | 2020.11.18 |
이 'for'루프가 유효하지 않은 이유는 무엇입니까? (0) | 2020.11.18 |
Ruby on Rails 내에서 안전한 REST API를 구축하기위한 제안을 찾고 있습니다. (0) | 2020.11.18 |
VB.NET에서 문자열을 결합하기위한 +와 &의 차이점 (0) | 2020.11.18 |