☰

연결 상태가 좋지 않아 대용량 파일 다운로드

tag-icon • tag-icon curl http download
연결 상태가 좋지 않아 대용량 파일 다운로드

연결 상태가 좋지 않을 때 대용량 파일을 다운로드할 수 있는 기존 도구가 있습니까?

비교적 작은 파일(300MB)을 정기적으로 다운로드해야 하지만 느린(80-120KB/초) 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옵션을 함께 사용할 수는 없을 것 같습니다 .)

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

이 특정 목적을 위해 C#으로 다운로드 도구를 작성할 생각이지만 기존 도구가 있거나 컬 명령이 다른 매개변수와 함께 제대로 작동한다면 시간을 좀 확보할 수 있습니다.

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

답변1

lftp(위키피디아) 이 점이 좋습니다. 여러 프로토콜을 지원하고, 여러 동시 병렬 연결을 사용하여 파일을 다운로드할 수 있으며(비혼잡으로 인해 큰 패킷 손실이 발생하는 상황에서 유용함) 자동으로 다운로드를 재개할 수 있습니다. 또한 스크립트 가능합니다.

여기에는 귀하가 제안한 조정 사항이 포함되어 있습니다(귀하께 감사드립니다):

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"'

답변2

--range귀하의 상황 에서는 이것을 테스트할 수 없지만 -C -. 해당 주제에 대한 매뉴얼 페이지의 내용은 다음과 같습니다.

-C -Tell을 사용 하면 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시간도 채 걸리지 않습니다. 그다지 느리지는 않지만 속도보다 안정성에 더 관심을 가져주셔서 감사합니다.

답변3

어쩌면 당신에게 더 많은 행운이 있을지도 모릅니다 wget --continue.

wget --continue ${URL}

당신은 또한 볼 수 있습니다https://www.cyberciti.biz/tips/wget-resume-broken-download.html

답변4

이전 직장에서도 동일한 문제가 있었습니다(연결이 불안정한 상태에서 300GB 이상의 오프사이트 데이터베이스 백업을 수행하는 경우(사무실) 제외). 약보다 큰 파일을 다운로드하는 동안 사용자는 심각한 문제에 직면하고 있습니다. 연결이 중단되기 전 1GB. RDP 연결을 통해 표준 Windows 파일 복사/붙여넣기를 사용하므로 이는 놀라운 일이 아닙니다.

제가 발견한 한 가지는 VPN 설정이 네트워크 설정(주로 MTU 길이)과 전혀 일치하지 않는다는 것입니다. 두 번째는 Windows의 파일 복사기가 인터넷을 통해 콘텐츠를 복사하는 데 적합하지 않다는 것입니다.

내 첫 번째 솔루션은 간단한 FTP 서버였지만 전송 시간 문제는 해결되지 않았습니다(연결에는 일반적으로 3~4시간이 걸렸습니다).

내 두 번째 해결책은사물을 동기화파일을 내부 NAS로 직접 보냅니다. 백업이 완료된 후 매일 밤 Syncthing은 필요한 모든 것을 사무실 NAS로 다시 보냅니다. 3시간이 넘는 전송 시간 문제를 해결했을 뿐만 아니라, 위기 상황 발생 시 데이터 전송에 소요되는 시간도 1~2시간 절약됐다. 매일 아침 8시에 NAS의 파일이 업데이트되고 백업이 준비됩니다. 대용량 파일(한 시점에서는 700GB 데이터베이스에 접근)에서도 파일 손상이나 기타 문제가 발생하지 않았습니다...

Syncthing은 설정 및 관리가 매우 쉽고 모든 플랫폼(모바일 포함)에서 작동하며 잘못된 연결을 매우 잘 처리합니다. 연결이 실패하면 Syncthing은 몇 분 정도 기다렸다가 다시 시도합니다.

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

동기화의 또 다른 이점은 다음과 같이 설정할 수 있다는 것입니다.변경사항만 동기화파일(예: 차등 백업)에서 대역폭 문제 중 일부를 해결할 수 있습니다.

관련 정보