대륙간에 많은 양의 데이터 전송 [중복]


12

가능한 중복 :
인터넷을 통해 큰 파일을 공유하는 무료 방법?
인터넷을 사용하지 않고 대용량 파일을 전송하는 옵션은 무엇입니까?

제 아내의 실험실은 싱가포르에서 공동 작업자와 함께 미국에서 프로젝트를하고 있습니다. 때때로 대륙 전체에 대량의 고차원 이미지 데이터 (~ 10GB 압축)를 전송해야합니다. 현재 기술로이 사용 시나리오에 적합한 솔루션은 무엇입니까?

나는 몇 가지를 생각할 수 있지만 그중 어느 것도 이상적인 것으로 보이지 않습니다.

  • 인터넷을 통한 직접 연결 : 전송 속도는 약 500KB / s이며 오류 / 재전송을 처리 할 도구가 없습니다.
  • Dropbox와 같은 공통 서버 또는 서비스에 업로드 : 미국 이외의 공동 작업자에게는 업로드가 어려움
  • Courier를 통한 디스크 굽기 또는 HD로 복사 및 배송 : 대기 시간이 중요하며 로컬 복사를위한 추가 작업이 필요합니다.

어떤 제안?

업데이트 : 협업 당사자는 기술에 정통한 사용자가 아닙니다.


그림과 같은 이미지 또는 DVD를 나타내는 파일과 같은 이미지?
Daniel Beck

현미경으로 생성 된 고차원 이미지.
Frank

1
그래서 그것은 매우 큰 파일입니까? 파일 수, 개별 파일 크기 및 전송 간 변경 횟수에 대한 자세한 정보를 제공해 주시겠습니까? 그들 모두, 일부 등입니까?
Daniel Beck


Sneakernet 또는 IPoAC 작업처럼 들립니다 .
Naftuli Kay

답변:


20

rsync 사용하는 것이 좋습니다 . Rsync는 델타 전송 알고리즘을 지원하므로 파일이 부분적으로 만 변경되거나 이전 전송이 비정상적으로 종료 된 경우 Rsync는 새로운 / 변경된 내용 만 동기화 할 수있을 정도로 똑똑합니다.

원래 Rsync의 Windows 및 기타 비 유닉스 호환 시스템 (여유 및 비 무료)에 대한 여러 포트가 있습니다. 자세한 내용은 Rsync Wikipedia 기사 를 참조하십시오.

SSH를 통한 Rsync는 매우 널리 사용되며 잘 작동합니다. 10GB는 현재 비교적 적은 양의 데이터이므로 "가끔"의미하는 것을 지정하지 않았습니다. 주간? 매일? 매시간? 전송 속도가 500KB / 초이면 실제로는 오래 걸리지 않고 약 6 시간이 걸립니다. 데이터를 자주 전송해야하는 경우 csync 작업을 만들어 rsync를 자동으로 시작하는 것이 좋습니다.


rsync델타에 대한 자체 프로토콜이 필요 하지 않고 반대쪽에 유능한 대응 시스템이 필요합니까?
Daniel Beck

@DanielBeck : SSH를 통한 rsync가 델타 카피를 사용할 수 없다는 문서에는 아무것도 없습니다 ... 기본적으로 rsync 클라이언트는 ssh를 통해 서버에서 다른 rsync 사본을 실행하므로 왜 작동하지 않는지 알 수 없습니다.
haimg

+1 거기에 포인트가 있습니다. 그래도 서버에 Linux 요구 사항이 남아 있습니까?
Daniel Beck

합니까 rsync의 델타 알고리즘 일 진 압축 된 데이터를 전송 ( .zip또는 .jpg)?
Aditya

@DanielBeck : 여러 Windows rsync 포트가있는 Wikipedia 기사에 대한 링크를 추가했습니다. 분명히 그들 중 일부는 ssh를 포함하여 서버로 작동합니다. 나는 그들 중 어느 것도 사용하지 않았다.
haimg

12

인터넷을 통한 연결은 실행 가능한 옵션이 될 수 있으며 bittorrent와 같은 프로그램은 파일을 논리적 조각으로 분할하여 다른 쪽 끝에서 재구성하기 위해 인터넷을 통해 전송되므로이 목적에 정확히 적합합니다.

Bittorrent는 또한 자동 오류 수정, 손상된 부분 복구 및 더 많은 사람들이 파일을 필요로하는 경우 이미 다운로드 한 파일의 일부 (일부)에서 파일을 제공받을 수 있다는 이점을 얻습니다.

허가받은 사람들은 영화 등을 다운로드하는 좋은 방법으로 생각하지만 더 많은 법적 용도를 가지고 있습니다.

많은 비트 토 런트 클라이언트에는 추적기가 내장되어 있으므로 파일을 호스팅하기 위해 전용 서버가 필요하지 않습니다.


2
입력 주셔서 감사합니다. 아카데믹 네트워크에서 BitTorrent를 사용하면 관리자가 불안해 할 수 있습니다. 또한 트래커 서버의 설정 및 유지 관리는 일반 컴퓨터 사용자에게는 쉽지 않을 수 있습니다.
Frank

2
많은 기업 및 학술 네트워크에서 비트 토렌트를 적극적으로 금지하고 있습니다. 적절한 관리를 통해 비트 토렌트를 사용할 수있는 사용자 또는 컴퓨터의 네트워크 내에 화이트리스트를 설정할 수 있지만, 이는 각 IT 부서와의 긴밀한 연계를 의미합니다. 앞에서 언급했듯이 많은 클라이언트 프로그램에 내장 될 수 있으므로 반드시 전용 서버가 필요하지 않습니다. 그래도 귀하의 상황에 적합하지 않으면 걱정하지 않아도됩니다. 귀하의 요구 사항을 고려할 때 합리적인 것처럼 보였습니다.
Mokubai

당신이 bitorrent를 사용하는 경우, 또한 webseed 소리를 사용하는 영리한 아이디어
Journeyman Geek

(답변에 언급 된 '보다 합법적 인 사용'중 하나의 예로 Facebook 비트 토렌트를 사용하여 1GB 바이너리를 수천 대의 프로덕션 서버에 배포합니다. 기술이 그 용도 중 하나 때문에 폐기되는 것이 유감입니다.)
Anton Strogonoff

6

파일을 50MB 단위로 분할하십시오 (예 :) split. 모든 체크섬을 계산합니다 (예 :) md5sum. FTP 및 lftpLinux 와 같은 오류 허용 FTP 클라이언트를 사용하여 직접 업로드하십시오 . 모든 청크와 모든 체크섬을 포함하는 파일을 전송하십시오.

원격 사이트에서 모든 청크에 원하는 체크섬이 있는지 확인하고 실패한 체크섬을 다시 업로드 한 다음 원래 파일로 다시 어셈블하십시오 (예 :) cat.

필요에 따라 서버의 위치를 ​​되돌립니다 (대상 사이트가 서버를 제공하고 파일이 준비되면 로컬로 전송을 시작한다는 가정하에 게시했습니다). FTP 클라이언트는 신경 쓰지 않아야합니다.


과거에 비슷한 문제가 있었고 오류 허용 FTP 클라이언트를 사용했습니다. 비트가 뒤집 히지 않고 정기적 인 연결이 중단되므로 청크 생성을 건너 뛰고 파일을 업로드 할 수 있습니다. 만일을 대비하여 우리는 여전히 완전한 파일에 대한 체크섬을 제공했습니다.


3
어떤 이유로 든 lftp진행중인 전송을 중단하지는 않지만주의해야합니다 . 대상 사이트에 항상 충분한 디스크 여유 공간이 있는지 확인하십시오.
Daniel Beck

3

Daniel Beck의 대답의 변형은 파일을 50MB에서 200MB의 순서로 분할 하여 전체 세트에 대한 패리티 파일 을 작성 하는 것입니다.

이제 FTP, SCP 등을 사용하여 파일 (패리티 파일 포함)을 원격 사이트로 전송하고 전체 세트가 도착한 후 확인을 수행 할 수 있습니다. 이제 손상된 부품이있는 경우 블록이 충분한 경우 패리티 파일로 수정할 수 있습니다. 손상되는 파일 수와 생성 한 패리티 파일 수에 따라 달라집니다.

패리티 파일은 유즈넷에서 큰 파일을 보내기 위해 많이 사용됩니다. 대부분의 경우 그들은 RAR 아카이브로 분할됩니다. 이런 식으로 최대 50GB에서 60GB까지 데이터를 보내는 것은 드문 일이 아닙니다.

첫 번째 링크를 반드시 확인해야하며 패리티 파일을 작성하고 다운로드 한 파일을 검증하며 제공된 패리티 파일로 손상된 파일을 복원 할 수있는 도구 인 QuickPar 도 살펴볼 수 있습니다.


+1-이 접근 방식은 유즈넷에서 잘 작동하며 패리티 파일은 엄청난 양의 누락 된 데이터를 복구 할 수 있습니다. 단점은 패리티 파일을 분할 및 생성하고 수신 후 파일을 검사하고 추출하는 데 필요한 처리 시간입니다.
deizel

1

하나의 큰 10GB 파일입니까? 쉽게 나눌 수 있습니까?

나는 이것을 많이 사용하지는 않았지만이 상황에서 효과가있을 수있는 흥미롭고 상대적으로 간단한 개념으로 나를 놀라게했다.

http://sendoid.com/


Sendoid는 꽤 멋지지만 불행히도 업로드는 여전히 고통 스럽습니다. 그런 다음 HDD를 우편으로 보내지 않는 한 모든 유형의 문제가 다시 발생합니다. 사용하기 편한 +1
DMan

0

ftp / http / https / sftp / ftps (로그온 자격 증명 필요)를 통해 데이터를 사용 가능하게 하고 클라이언트 측의 모든 다운로드 관리자 를 사용하십시오 .

다운로드 관리자는 발생할 수있는 오류에 관계없이 데이터를 검색하여 작업에 이상적으로 적합하도록 특별히 설계되었습니다.

서버의 경우 FTP 서버가 일반적으로 설정하기가 가장 쉽습니다. Wikipedia에서 목록 을 참조하십시오 . HTTPS, SFTP 및 FTPS는 암호화를 허용하지만 (순수한 FTP / HTTP에서는 비밀번호가 일반 텍스트로 전송 됨) SFTP / FTPS는 클라이언트 소프트웨어에서 덜 일반적으로 지원되며 HTTP / HTTPS 서버 설정은 까다 롭습니다.


1
http 또는 ftp를 사용할 때의 문제점은 전송 오류가 있다는 것입니다. 모든 것을 다시 보내야합니다. rsync, bittorrent 및 기타 프로토콜은 파일이 일치하는지 확인하고 손상된 부분 만 다시 전송합니다. QuickPar가 생성하는 것과 같은 패리티 데이터도 도움이 될 수 있습니다.
afrazier

FTP와 HTTP 모두 전송 재개 기능을 옵션 확장으로 포함하며 대부분의 서버와 거의 모든 다운로드 관리자가 지원합니다.
ivan_pozdeev

그들은 재개, 이론적으로 TCP는 반드시 데이터를 위해 유효한 검사로 도착하는 것이 있습니다. 그러나 큰 HTTP 또는 FTP 전송이 손상된 사용자는보다 강력한 프로토콜이나 ECC의 가치를 알게되었습니다.
afrazier
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.