연결이 잘못되어 큰 파일 다운로드

연결이 잘못된 경우 큰 파일을 다운로드하는 데 사용할 수있는 기존 도구가 있습니까?

상대적으로 작은 파일 인 300MB를 정기적으로 다운로드해야하지만 느린 (80-120KBytes / sec) TCP 연결은 10-120 초 후에 임의로 중단됩니다. (이 회사는 대기업 네트워크입니다. 우리는 관리자 (인도에서 근무)에게 여러 번 연락했지만 아무것도 할 수 없거나 원하지 않는 일입니다.) 리버스 프록시 /로드 밸런서에 문제가있을 수 있습니다.

지금까지 pcurl의 수정 된 버전을 사용했습니다 : https://github.com/brunoborges/pcurl

나는이 줄을 바꿨다.

curl -s --range ${START_SEG}-${END_SEG} -o ${FILENAME}.part${i} ${URL} &

이에:

curl -s --retry 9999 --retry-delay 3 --speed-limit 2048 --speed-time 10 \
    --retry-max-time 0 -C - --range ${START_SEG}-${END_SEG} -o ${FILENAME}.part${i} ${URL} &

--speed-limit 2048 --speed-time 10연결이 실패하면 대부분 몇 분 동안 연결이 끊어지기 때문에 추가 해야했습니다.

그러나 최근에는이 스크립트조차 완료 할 수 없습니다.

한 가지 문제는 -C -부품 을 무시하는 것처럼 보이 므로 재시도 후에 세그먼트를 "계속"하지 않는다는 것입니다. 관련 임시 파일을 자르고 각 실패 후 처음부터 시작하는 것 같습니다. ( --range와 -C옵션을 함께 사용할 수 없다고 생각합니다 .)

다른 문제는이 스크립트가 모든 세그먼트를 동시에 다운로드한다는 것입니다. 한 번에 10 개만 다운로드되는 300 개의 세그먼트를 가질 수 없습니다.

이 특정 목적을 위해 C #으로 다운로드 도구를 작성하려고 생각했지만 기존 도구가 있거나 curl 명령이 다른 매개 변수로 제대로 작동하면 시간을 절약 할 수 있습니다.

업데이트 1 : 추가 정보 : 병렬 다운로드 기능은 연결 당 대역폭 제한 (80-120KB / 초, 대부분 80)이 있으므로 제거하면 안됩니다. 따라서 10 개의 연결은 10 배 속도를 높일 수 있습니다. 파일이 매시간 생성되므로 1 시간 안에 파일 다운로드를 완료해야합니다.

lftp( Wikipedia )가 좋습니다. 여러 프로토콜을 지원하고 여러 동시 병렬 연결을 사용하여 파일을 다운로드 할 수 있으며 (정체로 인한 패킷 손실이없는 경우에 유용) 자동으로 다운로드를 다시 시작할 수 있습니다. 스크립트 가능합니다.

여기에 세밀한 조정을 포함하여 (신용)

lftp -c 'set net:idle 10
         set net:max-retries 0
         set net:reconnect-interval-base 3
         set net:reconnect-interval-max 3
         pget -n 10 -c "https://host/file.tar.gz"'

귀하의 상황에서 이것을 테스트 할 수는 없지만와 --range함께 사용해서는 안됩니다 -C -. 맨 페이지에서 주제에 대해 말한 내용은 다음과 같습니다.

전송을 재개 할 위치 / 방법을 자동으로 -C -알려주는 curl데 사용 합니다 . 그런 다음 주어진 출력 / 입력 파일을 사용하여 알아냅니다.

대신 이것을 시도하십시오 :

curl -s --retry 9999 --retry-delay 3 --speed-limit 2048 --speed-time 10 \
    --retry-max-time 0 -C - -o "${FILENAME}.part${i}" "${URL}" &

쉘이 변수를 구문 분석하지 않도록 항상 변수를 큰 따옴표로 묶는 것이 좋습니다. ( https://example.net/param1=one&param2=two쉘이 값을 나누는 URL을 고려하십시오 &.)

또한 120KB / s는 약 1.2Mb / s로 전세계 여러 지역에서 일반적인 xDSL 업로드 속도입니다. MB 당 10 초이므로 전체 파일에 대해 1 시간 미만입니다. 속도보다는 신뢰성에 더 관심을 기울이고 있지만 감사합니다.

어쩌면 당신은 더 운이 좋을 것입니다 wget --continue:

wget --continue ${URL}

참조 https://www.cyberciti.biz/tips/wget-resume-broken-download.html

상자 밖에서 : 안대를 착용하고 비트 토렌트를 사용하십시오. 급류를 만들 때 블록 크기를 작게 만드십시오. 분명히, 파일을 암호화하여 토런트를 찾는 다른 사람은 아무 것도 유용하지 않습니다.

이전 작업에서 동일한 문제가 발생했습니다 (사무실에서 불안정한 연결로 300GB 이상의 오프 사이트 데이터베이스 백업 제외). 사용자가 약보다 큰 파일을 다운로드하는 데 심각한 문제가있었습니다. 연결이 종료되기 전에 1GB RDP 연결을 통해 표준 Windows 복사 / 붙여 넣기 파일을 사용 했으므로 당연합니다.

내가 알게 된 한 가지는 VPN 설정이 네트워크 설정 (주로 MTU 길이)과 완전히 일치하지 않는다는 것입니다. 두 번째는 인터넷을 통해 물건을 복사하기 위해 Windows의 파일 복사기가 만들어지지 않는다는 것입니다.

내 첫 번째 솔루션은 간단한 FTP 서버 였지만 전송 시간 문제를 해결하지 못했습니다 (종종 연결에서 3-4 시간).

두 번째 해결책은 Syncthing 을 사용 하여 파일을 사내 NAS로 직접 보내는 것입니다. 매일 백업이 완료된 후 Syncthing은 필요한 모든 것을 사무실의 NAS로 다시 보냈습니다. 3 시간 이상의 전송 시간 문제가 해결되었을뿐만 아니라, 위기가있는 경우 데이터를 전달하기 위해 1-2 시간을 절약했습니다. 매일 오전 8시에 파일이 NAS에서 업데이트되고 백업이 준비되었습니다. 거대한 파일 (한 시점에 거의 700GB 데이터베이스)이 있어도 파일 손상이나 다른 문제가 발생하지 않았습니다 ...

동기화는 설정 및 관리가 쉬우 며 모든 플랫폼 (휴대 전화 포함)에서 사용할 수 있으며 잘못된 연결을 매우 잘 처리합니다. 연결에 실패하면 동기화는 몇 분 정도 기다렸다가 다시 시도합니다.

동기화 할 로컬 폴더가 필요하지만 파일이 업데이트되는 즉시 파일을 사용할 수 있습니다.

동기화에 대한 또 다른 좋은 점은 파일 의 변경 사항 만 동기화 하도록 설정할 수 있다는 것입니다 (차등 백업과 같이). 아마도 대역폭 문제의 일부를 해결할 수 있습니다.

거친 연결 ( zmodem)을 통해 파일을 이동하는 구식 솔루션을 고려할 수 있습니다 .

사람들이 전화를 들고 연결을 폭파하는 2400 개의 보우 모뎀이 표준이되었을 때 다시 개발되었습니다. 시도해 볼 가치가 있습니다.

Kermit을 사용해 볼 수 있습니다 .

Kermit 프로토콜과 다른 프로토콜을 구별하는 기능은 패킷 길이, 패킷 인코딩, 창 크기, 문자 집합, 오류 감지 방법, 시간 초과 등 두 종류의 컴퓨터 간의 모든 종류 및 연결 품질에 맞게 조정할 수있는 광범위한 설정입니다. , 일시 정지합니다. 대부분의 다른 프로토콜은 특정 종류 또는 품질의 연결 및 / 또는 특정 종류의 컴퓨터 또는 유사한 파일 시스템간에 만 작동하도록 설계되었으므로 다른 곳에서는 제대로 작동하지 않거나 전혀 작동하지 않으며 계획되지 않은 방법으로 적용 할 수있는 방법이 거의 없습니다 -상황에 따라. 반면에 커밋은 어떤 연결에서도 성공적인 파일 전송과 최고의 성능을 달성 할 수있게 해줍니다. "