답변:
다음 은이 둘 의 성능 비교 입니다. 작은 파일의 요청-응답에 HTTP가 더 반응이 좋지만, 제대로 조정되면 큰 파일의 경우 FTP가 더 나을 수 있습니다. FTP는 일반적으로 더 빠른 것으로 간주되었습니다. FTP는 TCP 상태 외에 제어 채널과 상태를 유지해야하지만 HTTP는 그렇지 않습니다. FTP에서 데이터 전송을 시작하기 전에 6 개의 패킷 전송이 있지만 HTTP에서는 4 만 전송됩니다.
적절하게 조정 된 TCP 계층은 응용 프로그램 계층 프로토콜의 차이보다 속도에 더 큰 영향을 줄 것이라고 생각합니다. Sun Blueprint 이해 튜닝 TCP 에 자세한 내용이 있습니다.
각 프로토콜의 개별 특성에 대한 또 다른 좋은 비교 입니다.
FTP와 HTTP를 통한 파일 전송을 벤치마킹했습니다.
결과:
fdm) : 1 분따라서 기본적으로 "실제"상황에서 :
1) 하나의 큰 파일을 다운로드 할 때 HTTP가 FTP보다 빠릅니다.
2) HTTP는 병렬 청크 다운로드를 사용하여 네트워크 조건에 따라 FTP보다 6 배 더 빠릅니다.
많은 방화벽이 포트 80 또는 443 (http & https)이 아닌 아웃 바운드 연결을 끊습니다. 일부는 HTTP (S)가 아닌 포트에 대한 연결을 끊기도합니다. FTP는 활성 / PASV 모드를 말하지 않고 허용되거나 허용되지 않을 수 있습니다.
또한 HTTP / 1.1은 훨씬 더 나은 부분 요청 ( "바이트 123456에서 파일의 끝으로 전송"), 조건부 요청 및 캐싱 ( "콘텐츠가 변경된 경우 / 마지막으로 수정 한 날짜가 변경된 경우에만 보내기") 및 콘텐츠 압축을 허용합니다. (gzip).
프록시를 통해 HTTP를 사용하는 것이 훨씬 쉽습니다.
필자의 일화 적 증거에서 HTTP는 연결 끊기 / 느린 연결 / 틀린 연결로 작업하기가 더 쉽습니다. 예를 들어, 전송을 다시 시작하기 전에 로그인 세션을 다시 설정할 필요가 없습니다.
OTOH, HTTP는 상태 비 저장이므로 인증을 수행하고 "누가 언제 무엇을했는지"추적을 작성해야합니다.
내가 알아 낸 속도의 유일한 차이점은 많은 작은 파일을 전송하는 것입니다. 파이프 라이닝을 사용하는 HTTP가 더 빠릅니다 (대기 시간이 길어짐, 특히 지연 시간이 긴 네트워크에서 눈에 띄게 나타남).
참고 HTTP / 2 FTP 프로토콜은 수십 년 동안 업데이트를 보지 않은 반면 이벤트 더욱 최적화 (FTP 및도 확장 사용자가 미미 흡수가). 따라서 타임 머신을 통해 파일을 전송하지 않으면 HTTP가 승리 한 것 같습니다.
(Tantentially : rsync또는 BitTorrent 와 같은 파일 전송에 더 적합한 프로토콜이 있지만 그 정도는 많지 않지만 HTTP는 Everywhere ™입니다.)
FTP에서 비표준 포트를 사용할 수 있으므로 방화벽을 통과하기가 어렵습니다 (특히 SSL을 사용하는 경우). HTTP는 일반적으로 알려진 포트에 있으므로 거의 문제가되지 않습니다.
FTP를 사용하기로 결정한 경우 활성 및 수동 FTP 에 대해 읽으십시오 .
성능면에서 하루가 끝나면 TCP 연결을 통해 파일을 직접 분출하므로 거의 동일해야합니다.