Mempercepat unggahan SFTP di jaringan latensi tinggi?

27

Saya mencoba untuk mentransfer satu set file besar secara internasional menggunakan SFTP, tetapi saya menemukan mitra internasional saya tidak bisa mendapatkan kecepatan unggah di atas ~ 50k meskipun koneksi yang sangat baik di kedua sisi. Kita bisa mendapatkan banyak koneksi yang mengunggah dengan kecepatan ini (jadi bukan bandwidth?), Tetapi tidak ada satu pun unggahan yang meningkat dalam kecepatan, yang merupakan masalah karena banyak file berukuran beberapa gb.

SFTP dihosting menggunakan sistem SFTP Apple OSX "Remote Login" standar.

Apakah ada cara untuk meningkatkan kecepatan unggah, atau adakah host SFTP berbeda yang akan membantu? Tidak jelas bagi saya apakah ini merupakan masalah konfigurasi atau keterbatasan protokol.

(Untuk alasan keamanan, saya harus menggunakan koneksi peer-to-peer terenkripsi ujung-ke-ujung - tidak ada layanan cloud).

— nick_eu
sumber

Jika Anda memiliki anggaran, ada solusi komersial yang berperforma jauh lebih baik daripada sistem transfer file berbasis TCP seperti SFTP.

— Kenster

4

Jika ini adalah transfer satu kali multi-gb mengapa tidak mencoba alternatif untuk internet .

— vasin1987

1

Skrip shell sederhana untuk memulai N rsynctransfer akan dengan mudah mencapai persyaratan 1. Transfer aman dan 2. Memaksimalkan bandwidth Anda. Lihat di sini untuk contoh bagaimana memulai N rsynctransfer stackoverflow.com/a/38014502/52074

— Trevor Boyd Smith

2

Atau cukup gunakan uftp-multicast.sourceforge.net berharap akan mengenkripsi dan Mac keluar bandwidth Anda.

— Trevor Boyd Smith

4

Berlawanan dengan kalimat terakhir Anda, layanan cloud seharusnya baik-baik saja jika Anda mengenkripsi file secara lokal, mentransfernya melalui cloud, kemudian mendekripsi secara lokal di ujung lainnya), yang masih berarti enkripsi ujung-ke-ujung. (Anda mungkin ingin menambahkan umpan balik singkat tentang penerimaan yang sukses). Anda menggunakan enkripsi sftp untuk mencegah serangan oleh seseorang yang dapat mengendus semua lalu lintas Anda. Oleh karena itu hanya memberi mereka data terenkripsi tidak lebih buruk daripada berasumsi bahwa mereka mungkin mendapatkannya.

— Hagen von Eitzen

29

Dengan klien OpenSSHsftp (yang tampaknya Anda gunakan), Anda dapat menggunakan:

-Rberalih untuk menambah panjang antrian permintaan (standarnya adalah 64)
-Bberalih untuk menambah ukuran permintaan baca / tulis (standarnya adalah 32 KB)

Sebagai permulaan, coba gandakan keduanya:

sftp -R 128 -B 65536 user@host

Mungkin tidak terlalu menjadi masalah, yang mana yang Anda tingkatkan.

Meningkatkan keduanya akan membantu menjenuhkan koneksi latensi tinggi Anda. Dengan pengaturan di atas, itu akan membuat data senilai 8 MB mengalir di pipa kapan saja (128 * 64K = 8M).

Perhatikan bahwa ini hanya membantu transfer file besar. Itu tidak akan berpengaruh apa pun, ketika mentransfer banyak file kecil.

Untuk beberapa latar belakang dan diskusi tentang klien SFTP (GUI) lainnya, lihat bagian "Keterlambatan jaringan / latensi" pada jawaban saya untuk Mengapa file Transfer FileZilla SFTP maksimum dibatasi 1,3MiB / detik alih-alih menjenuhkan bandwidth yang tersedia? rsync dan WinSCP bahkan lebih lambat .

— Martin Prikryl
sumber

4

Anda dapat mencoba dan mengaktifkan kompresi, dan melihat apakah itu membantu.

Dari man sftp:

-C Mengaktifkan kompresi (melalui ssh's -C flag).

Dan dari man ssh:

-C Meminta kompresi semua data (termasuk stdin, stdout, stderr, dan data untuk koneksi domain X11, TCP, dan UNIX yang diteruskan). Algoritma kompresi sama dengan yang digunakan oleh gzip (1), dan "level" dapat dikontrol oleh opsi CompressionLevel untuk versi protokol 1. Kompresi diinginkan pada jalur modem dan koneksi lambat lainnya, tetapi hanya akan memperlambat hal-hal pada jaringan cepat . Nilai default dapat ditetapkan berdasarkan host-demi-host dalam file konfigurasi; lihat opsi Kompresi.

Agak terdengar seolah-olah koneksi mungkin dibatasi pada beberapa titik di sepanjang jalurnya (atau lebih tepatnya, bagi saya penjelasan paling sederhana untuk 50kB / s Anda per koneksi, tetapi beberapa koneksi seperti itu dimungkinkan), meskipun mungkin bukan ide buruk untuk memastikan disk di kedua sisi bukan merupakan faktor.

Anda juga dapat menjalankan pcap cepat untuk melihat apakah ada masalah yang 'jelas' (seperti sejumlah besar transmisi ulang) - tetapi kecuali jika Anda memiliki kepercayaan diri Anda akan dapat mengatasi ini, saya mungkin hanya akan melihat apakah mengaktifkan kompresi akan membantu.

— iwaseatenbyagrue
sumber

Terima kasih! Sayangnya file-file tersebut sudah dikompres sebelumnya, jadi saya ragu itu akan melakukan apa saja ...: /

— nick_eu

Kompresi tidak mempercepat hal-hal di sini bahkan jika data tidak akan dikompres. Itu terlalu besar waktu CPU (dan menunda) sehingga tidak masuk akal hari ini.

— Jakuje

1

Jika bottleneck adalah jaringan maka sedikit lebih banyak CPU di kedua sisi seharusnya tidak memperlambat apa pun @ Jakuje, kecuali kotak tidak dapat dikompresi pada 50kB / s, yang seharusnya tidak menjadi masalah.

— Ben

@ Ben Pertanyaan ini dengan jelas menyatakan bahwa jaringan bukanlah hambatan.

— Jakuje

4

Saya mencoba mentransfer satu set file besar secara internasional menggunakan SFTP

Itu belum disebutkan sebagai jawaban, tetapi ketika mentransfer beberapa file melalui tautan latensi tinggi, ada satu solusi yang sangat sederhana untuk mendapatkan kinerja yang lebih baik:

Transfer beberapa file secara paralel.

Dan itu adalah solusi yang bahkan Anda sebutkan dalam pertanyaan Anda. Gunakan.

Pada dasarnya, protokol TCP tidak menangani koneksi dengan produk penundaan bandwidth besar dengan sangat baik - koneksi tunggal tidak dapat membuat cukup data bergerak pada satu waktu. Lihat https://en.wikipedia.org/wiki/TCP_tuning

Karena setiap koneksi dibatasi oleh protokol TCP, cukup gunakan lebih banyak koneksi.

— Andrew Henle
sumber

1

Berikut adalah cara memparalelkan transfer SFTP: serverfault.com/questions/248105/…

— niutech

3

Mempercepat transfer sftp

Dengan asumsi masalah Anda adalah penyempurnaan jaringan dan / atau pembatasan per koneksi TCP, lihat sftp menggunakan subsistem mirror lftp

Penyetelan jaringan di setiap ujung adalah topik yang jauh lebih besar dan akan membutuhkan banyak bolak-balik, mendorong topik di luar ruang lingkup ServerFault. Untuk koneksi individual, kompresi yang disebutkan oleh iwaseatenbyagrue dapat membantu. Ini mengasumsikan ujung jarak jauh memungkinkan kompresi.

— Harun
sumber

3

(Anda menyebutkan "latensi tinggi" dalam judul pertanyaan, tetapi tidak dalam teks isi. Sudahkah Anda mengukur latensi aktual, dan apa hasilnya?)

Ada patch untuk OpenSSH yang secara eksplisit meningkatkan throughput pada tautan jaringan latensi tinggi: HPN-SSH : (penekanan tambang)

SCP dan implementasi protokol SSH2 yang mendasarinya di OpenSSH adalah kinerja jaringan yang dibatasi oleh buffer kontrol aliran internal yang ditentukan secara statis. Buffer ini sering berakhir sebagai penghambat untuk throughput jaringan SCP, terutama pada link jaringan bandwidth yang panjang dan tinggi. Memodifikasi kode ssh untuk memungkinkan buffer didefinisikan pada saat run time menghilangkan hambatan ini. Kami telah membuat tambalan yang akan menghilangkan hambatan di OpenSSH dan sepenuhnya dapat dioperasikan dengan server dan klien lain. Selain itu, klien HPN akan dapat mengunduh lebih cepat dari server non HPN, dan server HPN akan dapat menerima unggahan lebih cepat dari klien non HPN.

Jadi, coba kompilasi dan gunakan HPN-SSH di sisi penerima, dan lihat apakah ini meningkatkan kecepatan transfer Anda.

— duta besar twisteroid
sumber

Terima kasih! Saya belum benar-benar mengukur, saya sekarang malu untuk mengakuinya, tapi saya akan berkeliling dunia ke negara dengan internet yang sangat-begitu, jadi saya kira saya benar. :) Patch terdengar sangat berguna!

— nick_eu

@nick_eu Saya telah melihat anekdot bahwa para ilmuwan akan menggunakan HPN-SSH untuk mentransfer sejumlah besar data ilmiah di seluruh Atlantik. Kedengarannya seperti itu harus sempurna untuk kasus penggunaan Anda.

— duta besar twisteroid

0

Tidak yakin apakah ini pilihan bagi Anda, tetapi sudahkah Anda mencoba menarik vs mendorong data ke situs internasional? Serta pada waktu yang berbeda untuk melihat apakah ini masalah dengan pertengkaran untuk sumber daya jaringan?

— sleepyweasel
sumber

ide bagus, akan mencoba.

— nick_eu

0

Kita bisa mendapatkan banyak koneksi dengan mengunggah pada kecepatan ini (jadi bukan bandwidth?)

Kedengarannya seperti masalah konfigurasi - baik secara sengaja (sebagai cara meningkatkan layanan tanpa harus membuat ketentuan tambahan) atau secara tidak sengaja (misalnya penskalaan jendela yang rusak atau kontrol lalu lintas yang terlalu bersemangat). Meskipun Anda dapat memparalelkan transfer, Anda tidak memberi tahu kami apa yang ada di ujung koneksi atau jika ada gunanya mengembangkan beberapa skrip sederhana untuk menangani sharding / pemulihan file.

Menyetel ukuran antrian dan kompresi tidak akan berdampak signifikan, kecuali jika penyebabnya adalah perangkat lunak yang ditulis dengan sangat buruk (dan openSSH tidak termasuk dalam kategori ini - tidak banyak gunanya menggunakan openssh dengan antrian permintaan yang lebih panjang / ukuran blok yang lebih besar kecuali latensinya adalah lebih dari 250msec. Anda mungkin mempertimbangkan mencoba dengan klien yang berbeda dari lokasi yang berbeda untuk mengesampingkan masalah dengan server.

Panggilan pertama saya adalah mengidentifikasi penyedia mana yang harus disalahkan atas masalah tersebut, minta mereka untuk memperbaiki masalah atau beralih ke penyedia lain.

— symcbean
sumber

Maaf, seharusnya lebih jelas. Tidak ada "penyedia" - Saya hosting di desktop saya sendiri, dan seorang kolega sedang mencoba untuk terhubung dari komputer mereka. Kolega tersebut baru saja membuka sesi ssh (tidak yakin dengan protokol tetapi dapat memeriksa) dan menggunakanput

— nick_eu

@nick_eu dia berbicara tentang penyedia internet.

— Džuris

Kedengarannya seperti masalah konfigurasi Tidak. Ini bukan masalah konfigurasi. Protokol TCP itu sendiri tidak bekerja dengan baik pada koneksi dengan produk penundaan bandwidth besar. Pada dasarnya, jika koneksi sedemikian rupa sehingga banyak data dapat terbang pada suatu waktu, protokol TCP itu sendiri tidak dapat membuat banyak data bergerak setiap saat. Itulah sebabnya koneksi TCP paralel berfungsi untuk meningkatkan kecepatan transfer data.

— Andrew Henle

"tidak berkinerja baik pada koneksi dengan produk penundaan bandwidth besar" - silakan baca RFC 1323 (dari 1992) dan 7323 (diganti 1323 pada 2014)

— symcbean

@symcbean Kemudian jelaskan OP. Kita bisa mendapatkan banyak koneksi yang mengunggah dengan kecepatan ini (jadi bukan bandwidth?), tetapi tidak ada satu pun unggahan yang meningkat dalam kecepatan. Itu adalah gejala klasik dari TCP melalui koneksi dengan latensi ekstrem - yang dapat dilakukan oleh ekstensi TCP adalah mengurangi masalahnya agak karena mereka tidak dapat mengatasi masalah mendasar dengan protokol itu sendiri. Dan semoga sukses dengan mengidentifikasi penyedia mana yang harus disalahkan atas masalah ini, minta mereka untuk memperbaiki masalah sambil mencoba "mentransfer satu set file besar secara internasional".

— Andrew Henle