기술적으로 Dropbox 가 FTP보다 훨씬 빠른 이유를 알고 싶습니다 . 어떤 종류의 기술을 사용합니까?
나는 diff 파일에 대해 이야기하지 않고 두 경우 모두 새 파일을 전송하는 것에 대해 이야기하고 있으며 Dropbox가 훨씬 빠릅니다.
업로드 한 파일의 FTP보다 10 배나 빠릅니다. 나중에 더 큰 파일을 다시 실험 해 보겠습니다.
기술적으로 Dropbox 가 FTP보다 훨씬 빠른 이유를 알고 싶습니다 . 어떤 종류의 기술을 사용합니까?
나는 diff 파일에 대해 이야기하지 않고 두 경우 모두 새 파일을 전송하는 것에 대해 이야기하고 있으며 Dropbox가 훨씬 빠릅니다.
업로드 한 파일의 FTP보다 10 배나 빠릅니다. 나중에 더 큰 파일을 다시 실험 해 보겠습니다.
답변:
여기에는 여러 가지 이유가있을 수 있습니다.
FTP 프로토콜은 효율적 이 아닙니다 .
FTP 전송에는 DropBox가 단일 HTTP 연결 만 사용할 수있는 두 개 이상의 연결 (제어용과 데이터 용)이 필요합니다. 또한 FTP 세션에 대한 데이터 연결이 서버에서 클라이언트로 열릴 수 있으며 NAT를 사용하는 경우 FTP 클라이언트가 연결을 시도하지 못하고 다른 방법으로 연결을 시도하지 못할 수 있습니다.
FTP 연결에는 많은 것들이 있습니다. 파일을 보내려면 클라이언트가 최소 두 개의 명령 (하나는 데이터 연결을 열고 다른 하나는 보내기 시작)을 보내야하며 서버가 응답 할 때까지 대기해야 할 때마다 대기 시간이 추가됩니다. 파일 당이 두 왕복뿐만 아니라 초기 연결을위한 여러 명령-응답 왕복이 있습니다. 하나는 사용자 이름을 보내고, 하나는 암호를, 하나는 전송 매개 변수를 설정하여 (서버가 ASCII가 아닌 이진 데이터를 기대). 클라이언트는 서버에 대한 정보를 얻기 위해 몇 가지 추가 명령을 실행할 수도 있습니다. Dropbox는 하나의 HTTP 요청 또는 최대 두 개 (인증 및 데이터 전송 중 하나)를 사용하고있을 것입니다.
또한 FTP 전송에 사용중인 클라이언트에 따라 (이를 지정하지 않은 경우 해당 정보를 포함하도록 질문을 편집하는 것이 좋습니다) 각 전송 작업 후 연결이 끊어지고 다음에 다시 연결될 수 있습니다. 시각. DropBox가 장기간 폴링을 위해 잠시 동안 연결을 유지하지 않고이 클라이언트가 다운로드해야하는 새로운 데이터에 대해 가능한 빨리 반응하므로 새로운 데이터를 가져와야합니다. 파일을 보내기위한 HTTP 연결은 다시 인증 할 필요가 없습니다.
FTP 클라이언트가없는 곳에서 DropBox 클라이언트가 데이터를 전송하기 전에 (속도를 높이고 대역폭을 절약하기 위해) 압축하지는 않을 것입니다. 따라서 큰 파일의 경우 (사전 압축 또는 암호화되지 않은 경우) DropBox 및 이와 같은 유틸리티는 기본 FTP 전송보다 약간 더 빠를 수 있습니다.
큰 파일의 경우 위의 처음 세 지점은 실제로 데이터를 전송하는 데 걸리는 시간과 비교할 때 미미한 수준이지만 4 지점은 여전히 중요합니다. 작은 파일의 경우 FTP 프로토콜에 의해 추가 된 모든 추가 설정 시간이 실제로 데이터를 보내는 데 걸리는 시간보다 몇 배 더 길 수 있습니다.
다른 사람들이 언급했듯이 Dropbox는 변경되지 않은 파일의 일부를 건너 뛸 수 있습니다 . 또한 서버 측에 이미 사본이있는 Dropbox는 파일을 업로드하지 않습니다 (사용자 또는 다른 사람이 이미 업로드 한 파일).
따라서 Dropbox에 이미있는 파일과 동일한 파일을 업로드하려고하면 업로드를 건너 뜁니다 (그리고 연결된 다른 시스템이 Dropbox 서버에서 다운로드를 시작할 수 있습니다). 이미 업로드 된 다른 파일과 거의 동일한 파일을 업로드하는 경우 (이미 업로드 된 파일이 '내 파일'이어야하는지 또는 다른 사용자가 올 수 있는지 확실하지 않은 경우) 파일의 일부만 전송합니다. 파일을 이미 업로드 한 파일과 결합 할 때 서버에서 다시 작성하십시오.
FTP는 이러한 작업을 수행 할 수 없습니다 (원격 엔드에서 사용 가능한 다른 데이터를 참조하지 않고 데이터 스트림을 송수신하는 간단한 프로토콜입니다). rsync 및 Unison 과 같은 도구 는 '다른쪽에 이미있는 청크를 건너 뛸'수 있지만 일반적으로 동기화 된 계층 구조의 동일한 경로에서 파일 내의 청크를 비교하는 것으로 제한됩니다. Dropbox는이 아이디어를 파일 모음으로 확장하는 것으로 보입니다 (따라서 거의 동일한 두 파일을 '업로드'하면 다른 하나를 다시 만들기 위해 하나의 'diff'만 보내도록 정렬 할 수 있습니다).
파일 전송 측면에서 더 빨리 의미한다고 가정합니다. Dropbox 폴더에 파일을 저장하면 Dropbox 는 데이터 의 델타 (또는 diff) 만 원격 스토리지 서버로 보냅니다. FTP (대부분의 경우)는 변경 사항을 전송하는 대신 파일을 바이트 단위로 전송하므로 네트워크를 통해 전송하는 데 훨씬 오래 걸릴 수 있습니다. 마찬가지로 원격 서버 에서 동기화 할 때 로컬 클라이언트는 변경 사항 만 다운로드합니다.
LAN 동기화 기능은 잠재적으로 동기화 속도를 높이고 필요한 네트워크 트래픽을 줄일 수 있습니다.
md5 / sha와 비슷한 간단한 해싱 기술을 사용한다고 생각합니다.
로컬 "dropbox"에 파일을 놓을 때마다 dropbox-client는 해당 파일의 해시를 계산하고 파일 크기, 파일 이름과 같은 추가 데이터를 dropbox-server로 전송해야합니다.
dropbox-server가 유사한 파일을 찾으면 (해시 색인과 서버에서 파일 데이터를 유지 관리해야 함) 단순히 파일이 성공적으로 "업로드"되었음을 클라이언트에 알립니다. ;-)
이렇게하면 파일을 논리적으로 만 "업로드"할 수 있습니다. 실제 파일 내용 전송이 없으므로 다른 것보다 빠릅니다.
Dropbox가 어떤 해싱 알고리즘을 사용하는지 잘 모르겠지만 작동 원리가 위에서 설명한 것과 비슷하다는 것을 100 % 확신합니다.
Dropbox는 다른 서비스를 사용하고 있지만 역사적으로 Amazon AWS (Amazon Web Services)를 사용해 왔습니다. 소스에서 대상으로 전송하는 데 전송 파이프가 매우 큰 것처럼 들립니다. 필자의 경험에 따르면 Dropbox는 한 번에 많은 양의 데이터를 수신 할 수있는 대상을 사용하고 있습니다. Dropbox는 또한 업로드를 다른 IP 주소로 배포합니다. FTP를 사용하는 사이트에는 전송 파이프가 훨씬 작으며 업로드를 효율적으로 배포 할 수 없습니다.
Resource Monitor (resmon) 을 실행 하고 Network 탭으로 이동하면 네트워크 대역폭을 사용하는 다른 프로세스를 알 수 있습니다.
Total (B/sec)
Total (B/sec)
나를 위해 Dropbox에 파일을 업로드 할 때 4 개의 연결을 사용하여 4 개의 다른 IP 주소를 보냅니다.