เร่งความเร็วการอัพโหลด SFTP บนเครือข่ายเวลาแฝงสูง

ฉันกำลังพยายามถ่ายโอนไฟล์ขนาดใหญ่ในระดับสากลโดยใช้ SFTP แต่ฉันพบว่าพันธมิตรต่างประเทศของฉันไม่สามารถรับความเร็วในการอัปโหลดที่สูงกว่า ~ 50k แม้จะมีการเชื่อมต่อที่ดีทั้งสองด้าน เราสามารถอัปโหลดการเชื่อมต่อได้หลายครั้งที่ความเร็วนี้ (ไม่ใช่แบนด์วิธ?) แต่ไม่มีการอัปโหลดครั้งเดียวที่ปรับปรุงด้วยความเร็วซึ่งเป็นปัญหาเนื่องจากไฟล์จำนวนมากมีขนาดหลายกิกะไบต์

SFTP กำลังถูกโฮสต์โดยใช้ระบบ SFTP "การเข้าสู่ระบบระยะไกล" มาตรฐานของ Apple OSX

มีวิธีในการปรับปรุงความเร็วในการอัพโหลดหรือมีโฮสต์ SFTP อื่นที่จะช่วยได้หรือไม่? ยังไม่ชัดเจนสำหรับฉันหากนี่เป็นปัญหาการกำหนดค่าหรือข้อ จำกัด โดยธรรมชาติของโปรโตคอล

(เพื่อเหตุผลด้านความปลอดภัยฉันจำเป็นต้องใช้การเชื่อมต่อแบบ peer-to-peer เข้ารหัสแบบ end-to-end - ไม่มีบริการคลาวด์)

ด้วยไคลเอนต์OpenSSHsftp (ซึ่งคุณดูเหมือนจะใช้) คุณสามารถใช้:

• -Rเปลี่ยนเพื่อเพิ่มความยาวของคิวคำขอ (ค่าเริ่มต้นคือ 64)
• -Bเปลี่ยนเพื่อเพิ่มขนาดคำขออ่าน / เขียน (ค่าเริ่มต้นคือ 32 KB)

สำหรับการเริ่มต้นให้ลองเพิ่มเป็นสองเท่า:

sftp -R 128 -B 65536 user@host

มันอาจจะไม่สำคัญมากซึ่งคุณเพิ่มขึ้น

การเพิ่มทั้งสองจะช่วยทำให้การเชื่อมต่อเวลาแฝงของคุณอิ่มตัว ด้วยการตั้งค่าข้างต้นมันจะเก็บข้อมูล 8 MB มูลค่าการไหลในท่อได้ตลอดเวลา (128 * 64K = 8M)

โปรดทราบว่าสิ่งนี้จะช่วยในการถ่ายโอนไฟล์ขนาดใหญ่เท่านั้น มันจะไม่มีผลกระทบใด ๆ เมื่อถ่ายโอนไฟล์ขนาดเล็กจำนวนมาก

สำหรับพื้นหลังและการสนทนาเกี่ยวกับไคลเอนต์ SFTP (GUI) อื่น ๆ ให้ดูที่ส่วน "ความล่าช้าของเครือข่าย / เวลาแฝง" ของคำตอบของฉันถึงทำไม FileZilla SFTP ถ่ายโอนไฟล์สูงสุดที่สูงสุดที่ 1.3MiB / วินาทีแทนที่จะแบนด์วิดท์ที่อิ่มตัว rsync และ WinSCP จะยิ่งช้าลง

คุณสามารถลองใช้งานการบีบอัดและดูว่ามีประโยชน์หรือไม่

จากman sftp:

-C เปิดใช้การบีบอัด (ผ่านแฟล็ก -sh ของ ssh)

และจากman ssh:

-C ร้องขอการบีบอัดข้อมูลทั้งหมด (รวมถึง stdin, stdout, stderr และข้อมูลสำหรับการเชื่อมต่อ X11, TCP และ UNIX- โดเมนที่ส่งต่อ) อัลกอริทึมการบีบอัดเป็นแบบเดียวกับที่ใช้โดย gzip (1) และ "ระดับ" สามารถควบคุมได้โดยตัวเลือก CompressionLevel สำหรับโปรโตคอลรุ่น 1 การบีบอัดเป็นที่ต้องการในสายโมเด็มและการเชื่อมต่อที่ช้าอื่น ๆ แต่จะช้าลงในเครือข่ายที่รวดเร็ว . ค่าเริ่มต้นสามารถตั้งค่าบนพื้นฐานโฮสต์โดยโฮสต์ในไฟล์การกำหนดค่า; ดูตัวเลือกการบีบอัด

มันฟังดูราวกับว่าการเชื่อมต่ออาจถูก จำกัด ในบางจุดตามเส้นทางของมัน (หรือค่อนข้างว่าสำหรับฉันคำอธิบายที่ง่ายที่สุดสำหรับ 50kB / s ของคุณต่อการเชื่อมต่อ แต่การเชื่อมต่อหลายอย่างเป็นไปได้) แม้ว่ามันอาจจะไม่ใช่ ความคิดที่ไม่ดีเพื่อให้แน่ใจว่าดิสก์ที่อยู่ทั้งสองข้างไม่ใช่ปัจจัย

คุณสามารถเรียกใช้ pcap อย่างรวดเร็วเพื่อดูว่ามีปัญหา 'ชัดเจน' (เช่น retransmits จำนวนมาก) - แต่ถ้าคุณมีความมั่นใจคุณจะสามารถแก้ไขปัญหานี้ได้ ช่วยด้วย.

ฉันพยายามถ่ายโอนไฟล์ขนาดใหญ่ในระดับสากลโดยใช้ SFTP

มันยังไม่ได้รับการกล่าวถึงว่าเป็นคำตอบ แต่เมื่อทำการถ่ายโอนไฟล์หลายไฟล์ผ่านลิงก์เวลาแฝงที่สูงนั้นมีวิธีแก้ไขปัญหาที่ง่ายมากเพื่อให้ได้ประสิทธิภาพที่ดีขึ้น:

ถ่ายโอนหลายไฟล์พร้อมกัน

และมันเป็นทางออกที่คุณพูดถึงในคำถามของคุณ ใช้มัน.

โดยทั่วไปโพรโทคอล TCP ไม่จัดการการเชื่อมต่อกับผลิตภัณฑ์ล่าช้าแบนด์วิดท์ขนาดใหญ่ดีมาก - การเชื่อมต่อเดียวไม่สามารถเก็บข้อมูลเพียงพอที่จะย้ายในเวลาเดียว ดูhttps://en.wikipedia.org/wiki/TCP_tuning

เนื่องจากการเชื่อมต่อแต่ละครั้งจะถูก จำกัด โดยโปรโตคอล TCP เพียงแค่ใช้การเชื่อมต่อมากขึ้น

เร่งความเร็วการถ่ายโอน SFTP

สมมติว่าปัญหาของคุณคือการปรับเครือข่ายและ / หรือการควบคุมปริมาณต่อการเชื่อมต่อ TCP ดูที่sftp โดยใช้ระบบย่อย lftp mirror

การปรับเครือข่ายที่ปลายแต่ละด้านเป็นหัวข้อที่ใหญ่กว่ามากและต้องใช้มากไปข้างหน้าและผลักดันหัวข้อที่อยู่นอกขอบเขตของ ServerFault สำหรับการเชื่อมต่อส่วนบุคคลการบีบอัดที่ระบุโดยiwaseatenbyagrueอาจช่วยได้ทั้งสองทาง นี่ถือว่าสิ้นสุดระยะไกลช่วยให้การบีบอัด

(คุณพูดถึง "latency สูง" ในชื่อคำถาม แต่ไม่ได้อยู่ในเนื้อความคุณเคยวัดเวลาแฝงที่เกิดขึ้นจริงและผลลัพธ์คืออะไร?)

มี patch สำหรับ OpenSSH ที่ปรับปรุง throughput บนลิงค์เครือข่ายที่มีความหน่วงสูงอย่างชัดเจน: HPN-SSH : (ของฉันที่เน้น)

SCP และการใช้โปรโตคอล SSH2 พื้นฐานใน OpenSSH คือประสิทธิภาพของเครือข่ายที่ จำกัด โดยบัฟเฟอร์การควบคุมการไหลภายในที่กำหนดไว้แบบคงที่ บัฟเฟอร์เหล่านี้มักจะทำหน้าที่เป็นคอขวดสำหรับการรับส่งข้อมูลผ่านเครือข่ายของ SCP โดยเฉพาะอย่างยิ่งในการเชื่อมโยงเครือข่ายที่มีแบนด์วิดท์สูงและยาว การแก้ไขโค้ด ssh เพื่อให้สามารถกำหนดบัฟเฟอร์ได้ในขณะใช้งานจะกำจัดปัญหาคอขวดนี้ เราได้สร้างชุดข้อมูลแก้ไขที่จะลบคอขวดใน OpenSSH และสามารถทำงานร่วมกับเซิร์ฟเวอร์และไคลเอนต์อื่น ๆ ได้อย่างสมบูรณ์ นอกจากนี้ลูกค้า HPN จะสามารถดาวน์โหลดได้เร็วขึ้นจากเซิร์ฟเวอร์ที่ไม่ใช่ HPN และเซิร์ฟเวอร์ HPN จะสามารถรับการอัปโหลดได้เร็วขึ้นจากลูกค้าที่ไม่ใช่ HPN

ดังนั้นลองรวบรวมและใช้ HPN-SSH ที่ด้านรับและดูว่าจะปรับปรุงความเร็วในการถ่ายโอนของคุณหรือไม่

ไม่แน่ใจว่านี่เป็นตัวเลือกสำหรับคุณหรือไม่ แต่คุณได้ลองดึงและดันข้อมูลไปยังไซต์ต่างประเทศหรือไม่ รวมทั้งในเวลาที่ต่างกันเพื่อดูว่ามันมีปัญหากับการช่วงชิงทรัพยากรเครือข่ายหรือไม่?

เราสามารถรับการเชื่อมต่อหลาย ๆ อัพโหลดที่ความเร็วนี้ (ดังนั้นไม่แบนด์วิดธ์?)

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

การปรับขนาดคิวและการบีบอัดไม่น่าจะมีผลกระทบอย่างมีนัยสำคัญใด ๆ ยกเว้นสาเหตุที่เป็นซอฟต์แวร์ที่เขียนไม่ดีมาก (และ openSSH ไม่ได้อยู่ในหมวดหมู่นี้ - ไม่มากจุดในการใช้ openssh กับคิวร้องขอยาว / ขนาดบล็อกขนาดใหญ่ มากกว่า 250msec คุณอาจลองกับไคลเอนต์ต่าง ๆ จากตำแหน่งที่ตั้งต่าง ๆ เพื่อแยกแยะปัญหากับเซิร์ฟเวอร์

การโทรครั้งแรกของฉันคือการระบุว่าผู้ให้บริการรายใดที่ตำหนิปัญหาขอให้พวกเขาแก้ไขปัญหาหรือเปลี่ยนไปใช้ผู้ให้บริการรายอื่น