ดาวน์โหลดไฟล์ขนาดใหญ่ผ่านการเชื่อมต่อที่ไม่ดี

มีเครื่องมือที่มีอยู่ซึ่งสามารถใช้ดาวน์โหลดไฟล์ขนาดใหญ่ผ่านการเชื่อมต่อที่ไม่ดีได้หรือไม่?

ฉันต้องดาวน์โหลดไฟล์ที่ค่อนข้างเล็กเป็นประจำ: 300 MB แต่การเชื่อมต่อ TCP ที่ช้า (80-120 KBytes / วินาที) จะหยุดพักแบบสุ่มหลังจาก 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 -ส่วนดังนั้นจึงไม่ "ดำเนินการต่อ" ส่วนหลังจากลองอีกครั้ง ดูเหมือนว่าจะตัดทอนไฟล์ temp ที่เกี่ยวข้องและเริ่มจากจุดเริ่มต้นหลังจากแต่ละไฟล์ล้มเหลว (ฉันคิดว่า--rangeและ-Cตัวเลือกไม่สามารถใช้ร่วมกันได้)

ปัญหาอื่นคือสคริปต์นี้ดาวน์โหลดทุกส่วนในเวลาเดียวกัน ไม่สามารถมีกลุ่มได้ 300 กลุ่มโดยมีการดาวน์โหลดเพียง 10 ครั้งเท่านั้น

ฉันกำลังคิดที่จะเขียนเครื่องมือดาวน์โหลดใน C # สำหรับจุดประสงค์เฉพาะนี้ แต่ถ้ามีเครื่องมือที่มีอยู่หรือถ้าคำสั่ง curl สามารถทำงานได้อย่างถูกต้องกับพารามิเตอร์ที่แตกต่างกันฉันก็จะเสียเวลา

อัปเดต 1: ข้อมูลเพิ่มเติม: ไม่ควรลบฟังก์ชันการดาวน์โหลดแบบขนานเนื่องจากมีขีด จำกัด แบนด์วิดท์ (80-120 Kbytes / วินาทีโดยส่วนใหญ่ 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}" &

ฉันขอแนะนำอย่างยิ่งว่าคุณควรอ้างอิงตัวแปรของคุณเป็นสองเท่าเสมอเพื่อให้เชลล์ไม่พยายามแยกวิเคราะห์ (พิจารณา URL https://example.net/param1=one&param2=twoที่เชลล์จะแบ่งค่าเป็น&.)

บังเอิญ 120 KB / s อยู่ที่ประมาณ 1.2 Mb / s ซึ่งเป็นความเร็วในการอัพโหลด xDSL ทั่วไปในหลายส่วนของโลก 10 วินาทีต่อ MB ดังนั้นน้อยกว่าหนึ่งชั่วโมงสำหรับไฟล์ทั้งหมด ไม่ช้าเลยแม้ว่าฉันจะขอบคุณที่คุณให้ความสำคัญกับความน่าเชื่อถือมากกว่าความเร็ว

บางทีคุณอาจมีโชคด้วยwget --continue:

wget --continue ${URL}

ดูเพิ่มเติมที่https://www.cyberciti.biz/tips/wget-resume-broken-download.html

นอกกรอบ: ใส่ที่คาดตาและใช้ bittorrent ทำให้ขนาดบล็อกเล็กเมื่อคุณสร้างฝนตกหนัก เห็นได้ชัดว่าเข้ารหัสไฟล์เพื่อให้คนอื่นที่พบว่าฝนตกหนักไม่มีประโยชน์อะไรเลย

ฉันมีปัญหาเดียวกันในงานก่อนหน้าของฉัน (ยกเว้นการสำรองฐานข้อมูลภายนอก 300GB บนการเชื่อมต่อที่ไม่เสถียร (จากสำนักงาน) ผู้ใช้มีปัญหาร้ายแรงในการดาวน์โหลดไฟล์ที่ใหญ่กว่าประมาณ 1 GB ก่อนการเชื่อมต่อจะหมด เนื่องจากพวกเขาใช้ไฟล์คัดลอก / วาง Windows มาตรฐานผ่านการเชื่อมต่อ RDP จึงไม่น่าแปลกใจ

สิ่งหนึ่งที่ฉันพบคือการตั้งค่า VPN ของเรานั้นไม่ตรงกับการตั้งค่าเครือข่าย (ส่วนใหญ่เป็นความยาว MTU) สิ่งที่สองคือเครื่องถ่ายเอกสารไฟล์ของ Windows ไม่ได้ทำขึ้นเพื่อคัดลอกข้อมูลทางอินเทอร์เน็ต

ทางออกแรกของฉันคือ FTP เซิร์ฟเวอร์ที่เรียบง่าย แต่มันไม่ได้แก้ปัญหาเวลาส่ง (มักจะ 3-4 ชั่วโมงในการเชื่อมต่อของเรา)

ทางออกที่สองของฉันคือการใช้Syncthingเพื่อส่งไฟล์โดยตรงไปยัง NAS ภายในองค์กร ทุกคืนหลังจากการสำรองข้อมูลเสร็จสมบูรณ์ Syncthing ส่งทุกสิ่งที่เราต้องการกลับไปที่ NAS ในสำนักงาน ไม่เพียงแก้ไขปัญหาเวลาในการส่งข้อมูล 3+ ชั่วโมงเท่านั้น แต่ฉันใช้เวลา 1-2 ชั่วโมงในการจัดส่งข้อมูลหากมีวิกฤต เวลา 8.00 น. ทุกเช้าไฟล์จะถูกอัปเดตใน NAS และเรามีการสำรองข้อมูลของเราพร้อม แม้จะมีไฟล์ขนาดใหญ่ (ณ จุดหนึ่งฐานข้อมูลเกือบ 700GB) ฉันยังไม่ได้พบความเสียหายของไฟล์หรือปัญหาอื่น ๆ ...

Syncthing นั้นง่ายต่อการติดตั้งและจัดการและสามารถใช้งานได้กับทุกแพลตฟอร์ม (แม้กระทั่งโทรศัพท์) และมีการจัดการการเชื่อมต่อที่ไม่ดีมาก .. หากการเชื่อมต่อล้มเหลว Syncthing ก็รอเพียงไม่กี่นาทีและลองอีกครั้ง

คุณต้องการโฟลเดอร์ในเครื่องเพื่อซิงค์สิ่งต่าง ๆ แต่ไฟล์ของคุณจะสามารถใช้งานได้เกือบจะทันทีที่มีการอัปเดต

อีกสิ่งที่ดีเกี่ยวกับ syncthing คือมันสามารถตั้งค่าให้ซิงค์การเปลี่ยนแปลงในไฟล์ (เช่นในการสำรองข้อมูลที่แตกต่างกัน) ... อาจแก้ปัญหาแบนด์วิดท์ของคุณได้

คุณอาจพิจารณาการแก้ปัญหาเก่าโรงเรียนสำหรับการย้ายไฟล์ผ่านการเชื่อมต่อหมัด - Zmodem

สิ่งนี้ได้รับการพัฒนาย้อนกลับไปเมื่อมีโมเด็ม 2400 baud กับผู้คนที่ยกหูโทรศัพท์ขึ้นมา อาจจะคุ้มค่ากับการลอง

คุณสามารถลองใช้Kermit :

คุณลักษณะที่แยกความแตกต่างของโปรโตคอล Kermit จากตัวอื่น ๆ ส่วนใหญ่คือการตั้งค่าที่หลากหลายเพื่อให้สามารถปรับให้เข้ากับชนิดและคุณภาพของการเชื่อมต่อระหว่างคอมพิวเตอร์สองประเภท - ความยาวของแพ็คเก็ต, การเข้ารหัสแพ็คเก็ต, ขนาดหน้าต่าง หยุดชั่วคราว โปรโตคอลอื่น ๆ ส่วนใหญ่ได้รับการออกแบบมาเพื่อทำงานเฉพาะกับการเชื่อมต่อบางประเภทและ / หรือระหว่างคอมพิวเตอร์บางประเภทหรือเช่นระบบไฟล์ดังนั้นจึงทำงานได้ไม่ดี (หรือไม่เลย) และที่อื่น ๆ และเสนอวิธีการปรับให้เข้ากับแผนทันที - สำหรับสถานการณ์ ในทางกลับกัน Kermit จะช่วยให้คุณถ่ายโอนไฟล์ได้สำเร็จและมีประสิทธิภาพสูงสุดในทุกการเชื่อมต่อที่กำหนด "