Yüksek gecikmeli ağda SFTP yüklemelerini hızlandırmak mı?

27

SFTP kullanarak uluslararası bir dizi büyük dosyayı aktarmaya çalışıyorum, ancak uluslararası ortağımın her iki tarafta çok iyi bağlantılara rağmen ~ 50k üzerinde yükleme hızları alamadığını tespit ediyorum. Bu hızda birden fazla bağlantı yükleyebiliyoruz (bu yüzden bant genişliği değil mi?), Ancak tek bir yüklemenin hızı artmıyor, bu da çoğu dosyanın boyutu birkaç gb olduğundan bir sorun.

SFTP standart Apple OSX "Uzaktan Giriş" SFTP sistemi kullanılarak barındırılmaktadır.

Yükleme hızını arttırmanın bir yolu var mı, yoksa yardımcı olabilecek farklı bir SFTP sunucusu var mı? Bu bir yapılandırma sorunu mu yoksa protokolün içsel bir kısıtlaması mı?

(Güvenlik nedeniyle uçtan uca şifreli eşler arası bağlantı kullanmam gerekiyor - bulut hizmetleri yok).

— nick_eu
kaynak

Bütçeniz varsa, SFTP gibi TCP tabanlı dosya aktarma sistemlerinden daha iyi performans gösteren ticari çözümler vardır.

— Kenster

4

Bir zaman multi-gb transferi ise, neden internete alternatif denemiyorsunuz .

— vasin1987

1

N rsyncaktarımlarını başlatan basit bir kabuk betiği , 1. Güvenli aktarım ve 2. Bant genişliğinizi en üst düzeye çıkarma gereksinimlerinizi kolayca karşılar. N rsynctransferlerin nasıl başlatılacağına dair bir örnek için buraya bakın stackoverflow.com/a/38014502/52074

— Trevor Boyd Smith

2

Ya da sadece uftp-multicast.sourceforge.net dileklerini şifreleyip Mac'inizin bant genişliğini belirlemesini isteyin .

— Trevor Boyd Smith

4

Son cümlenizin aksine, dosyayı yerel olarak şifrelemeniz, bulut yoluyla aktarmanız ve ardından diğer ucunda yerel olarak şifresini çözmeniz durumunda (bu, yine de uçtan uca şifreleme anlamına gelir), bulut hizmeti tamam olmalıdır. (Başarılı alım hakkında kısa bir geri bildirim eklemek isteyebilirsiniz). Tüm trafiğinizi koklayabilecek birisinin saldırılarını önlemek için sftp şifrelemesini kullanırsınız. Dolayısıyla onlara şifrelenmiş verileri vermek, yine de alabileceklerini varsaymaktan daha kötü değildir.

— Hagen von Eitzen

29

İle OpenSSH sftpistemcisi (eğer kullanım görünüyor), kullanabilirsiniz:

-Ristek kuyruğu uzunluğunu artırmak için geçiş yap (varsayılan 64)
-Bgeçiş okuma / yazma isteği boyutunu artırmak için (varsayılan 32 KB)

Bir başlangıç için ikisini de ikiye katlamayı deneyin:

sftp -R 128 -B 65536 user@host

Muhtemelen önemli değil, hangisini arttırdığınız.

Her ikisinin de artırılması, yüksek gecikmeli bağlantınızı doyurmaya yardımcı olmalıdır. Yukarıdaki ayarlarla, istediğiniz zaman boruda 8 MB değerinde veri akışı sağlar (128 * 64K = 8M).

Bunun yalnızca büyük dosya aktarımlarında yardımcı olacağını unutmayın. Çok sayıda küçük dosyayı aktarırken herhangi bir etkisi olmaz.

Bazı arka plan ve diğer (GUI) SFTP istemcileri hakkında bir tartışma için , FileZilla SFTP dosya aktarımı maks. rsync ve WinSCP daha yavaş .

— Martin Prikryl
kaynak

4

Sıkıştırmayı deneyip etkinleştirebilir ve bunun yardımcı olup olmadığını görebilirsiniz.

Kimden man sftp:

-C Sıkıştırmayı etkinleştirir (ssh'in -C bayrağı aracılığıyla).

Ve kimden man ssh:

-C Tüm verilerin sıkıştırılmasını ister (stdin, stdout, stderr ve iletilen X11, TCP ve UNIX alan adı bağlantıları için veriler dahil). Sıkıştırma algoritması gzip (1) tarafından kullanılanlarla aynıdır ve “seviye” protokol sürüm 1 için CompressionLevel seçeneğiyle kontrol edilebilir. Sıkıştırma, modem hatlarında ve diğer yavaş bağlantılarda istenir ancak yalnızca hızlı ağlarda işleri yavaşlatır. . Varsayılan değer, yapılandırma dosyalarında ana bilgisayar bazında ayarlanabilir; Sıkıştırma seçeneğine bakın.

Bağlantının yolu boyunca bir noktada bağlantı hızı sınırlanmış gibi görünüyor (ya da daha doğrusu, bu bağlantı başına 50kB / sn için en basit açıklama gibi görünüyor, ancak bu tür bir çok bağlantı mümkün olabilir). Her iki taraftaki disklerin bir etken olmadığından emin olmak kötü bir fikir.

Ayrıca, herhangi bir 'bariz' sorun olup olmadığını (çok sayıda yeniden gönderim gibi) olup olmadığını görmek için hızlı bir pcap da çalıştırabilirsiniz - ancak, bu sorunu çözebileceğinizden emin olamadığınız sürece, muhtemelen sıkıştırmayı etkinleştirip etkinleştirmeyeceğinizi göreceksiniz. yardım et.

— iwaseatenbyagrue
kaynak

Teşekkürler! Ne yazık ki dosyalar önceden sıkıştırılmıştır, bu yüzden herhangi bir şey yapacağından şüpheliyim ...: /

— nick_eu

Sıkıştırma, veriler sıkıştırılmasa bile burada işleri hızlandırmaz. CPU zamanının çok büyük olması (ve gecikmesi) bu günlerde bir anlam ifade etmiyor.

— Jakuje

1

Eğer tıkanıklık ağ ise, her iki tarafta da biraz daha fazla CPU, kutu 50kB / s'de sıkıştıramadığı sürece herhangi bir sorunu yavaşlatmamalı.

— Ben

@Ben Soru açıkça ağın bir darboğaz olmadığını belirtir.

— Jakuje

4

SFTP kullanarak uluslararası bir dizi büyük dosyayı aktarmaya çalışıyorum

Henüz bir cevap olarak bahsedilmedi, ancak yüksek gecikmeli bir bağlantı üzerinden birden fazla dosyayı aktarırken daha iyi performans elde etmek için gerçekten basit bir çözüm var:

Paralel olarak birden fazla dosya aktarın.

Ve bu olduğunu hatta sorudaki bir çözüm. Kullanın.

Temel olarak, TCP protokolü geniş bant genişliği gecikmeli bir ürünle olan bağlantıları çok iyi bir şekilde işlemez - tek bir bağlantı, herhangi bir zamanda yeterli veriyi taşıyamaz. Bkz. Https://en.wikipedia.org/wiki/TCP_tuning

Yana her bağlantı TCP protokolü tarafından sınırlandırılır, sadece daha fazla bağlantıları kullanın.

— Andrew Henle
kaynak

1

SFTP transferlerini nasıl paralel hale getireceğinizi burada bulabilirsiniz: serverfault.com/questions/248105/…

— niutech

3

Sftp transferlerini hızlandırın

Sorunlarınızın ağ bağlantısı ve / veya TCP bağlantısı başına kısma olduğunu varsayarsak , lftp mirror alt sistemini kullanarak sftp'ye bir göz atın.

Her iki uçta yapılan ağ ayarlama işlemi çok daha büyük bir konudur ve konuyu ServerFault kapsamı dışına iten çok ileri ve geri gerektirir. Bireysel bağlantılar için, iwaseatenbyagrue tarafından belirtilen sıkıştırma her iki şekilde de yardımcı olabilir. Bu, uzak ucun sıkıştırmaya izin verdiğini varsayar.

— Aaron
kaynak

3

(Soru başlığında "yüksek gecikme" den bahsediyorsunuz, ancak metin metninde değil. Gerçek gecikmeyi ölçtünüz mü ve sonuçlar nelerdir?)

Yüksek gecikmeli bir ağ bağlantısındaki verimi açıkça artıran OpenSSH için bir düzeltme eki var: HPN-SSH : (vurgu benimki)

SCSS ve OpenSSH'daki altta yatan SSH2 protokolü uygulaması, statik olarak tanımlanmış dahili akış kontrol tamponları ile sınırlı ağ performansıdır. Bu tamponlar genellikle, özellikle uzun ve yüksek bant genişliği olan ağ bağlantılarında SCP'nin ağ çıkışı için bir tıkanıklık işlevi görür. Tamponların çalışma zamanında tanımlanabilmesi için ssh kodunun değiştirilmesi bu tıkanıklığı ortadan kaldırır. OpenSSH'deki tıkanıklıkları giderecek ve diğer sunucular ve istemcilerle tam olarak birlikte çalışabilecek bir yama oluşturduk. Ek olarak, HPN istemcileri, HPN olmayan sunuculardan daha hızlı indirebilecek ve HPN sunucuları da HPN olmayan istemcilerden daha hızlı yükleme alabilecek.

Bu nedenle, alıcı tarafta HPN-SSH'yi derlemeye ve kullanmaya çalışın ve aktarım hızınızı artırıp artırmadığını görün.

— twisteroid elçisi
kaynak

Teşekkürler! Ben aslında ölçmedim, şimdi itiraf etmekten utanıyorum, ama dünyanın öbür ucuna so-so internet olan bir ülkeye gidiyorum, bu yüzden haklı olduğumu tahmin ediyorum. :) Yama çok kullanışlı geliyor!

— nick_eu

@ nick_eu Bilim insanlarının Atlantik'teki büyük miktarlardaki bilimsel verileri aktarmak için HPN-SSH'yi kullanacakları fıkraları gördüm. Kullanım durumunuz için mükemmel olmalı gibi geliyor.

— twisteroid elçisi,

0

Bunun sizin için bir seçenek olup olmadığından emin değilsiniz, ancak verileri uluslararası siteye itmek yerine çekmeyi denediniz mi? Hem de farklı zamanlarda ağ kaynaklarına ilişkin bir sorun olup olmadığını görmek için?

— sleepyweasel
kaynak

harika bir fikir, deneyecek.

— nick_eu

0

Bu hızda birden fazla bağlantı yükleyebiliriz (bu yüzden bant genişliği değil?)

Bir yapılandırma sorunu gibi gözüküyor - kasten (fazladan bir önlem almak zorunda kalmadan satış hizmetlerinin bir yolu olarak) veya kazayla (örn. Kırık cam ölçeklendirme veya aşırı trafik kontrolü). Aktarımları paralelleştirirken, bağlantının diğer ucunda ne olduğu hakkında bir şey anlatmadınız ya da dosyaların paylaşılması / yeniden yapılandırılması için basit komut dosyaları geliştirmeye değerse.

Sıra çok kötü yazılmış bir yazılım olmadıkça, sıra boyutu ve sıkıştırmanın ayarlanması önemli bir etkiye sahip değildir (ve openSSH bu kategoriye girmez - gecikme süresi daha uzun bir istek kuyruğu / daha büyük blok boyutu ile openssh kullanmanın pek bir anlamı yoktur) Sunucu ile ilgili bir sorunu ortadan kaldırmak için farklı konumlardan farklı istemcilerle denemeyi düşünebilirsiniz.

İlk çağrım, sorunun hangi sağlayıcıyı suçlayacağını belirlemek, sorunu düzeltmelerini veya farklı bir sağlayıcıya geçmelerini istemek olacaktır.

— symcbean
kaynak

Üzgünüm, daha açık olmalıydı. "Sağlayıcı" yok - Kendi masaüstümde barındırıyorum ve bir meslektaşım bilgisayarlarından bağlanmaya çalışıyor. Meslektaşım sadece bir ssh oturumu açıyor (protokolden emin değil, kontrol edebiliyor) ve kullanıyorput

— nick_eu

@ nick_eu internet sağlayıcıları hakkında konuşuyor.

— Džuris

Bir yapılandırma sorunu gibi geliyor. Hayır. Bir yapılandırma sorunu değil. TCP protokolünün kendisi, geniş bant genişliği gecikmeli bir ürünle olan bağlantılarda iyi performans göstermez. Temel olarak, bağlantı bir seferde çok fazla veri uçuş halinde olacaksa, TCP protokolünün kendisi herhangi bir zamanda bu kadar veriyi hareket ettiremez. Paralel TCP bağlantılarının veri aktarım hızlarını artırmak için çalışmasının nedeni budur.

— Andrew Henle

"Geniş bant genişliği gecikmeli bir ürünle olan bağlantılarda iyi performans göstermiyor" - lütfen RFC 1323 (1992'den itibaren) ve 7323 (2014'te

— 1323'ün

OP var açıklamak Sonra @symcbean (? öyle değil bant genişliği) Bu hızda çoklu bağlantı yükleme alabilirsiniz, ama hiçbir Tek yükleme hızında geliştirir aşırı gecikme içeren bir bağlantı üzerinden TCP klasik semptom - yapabileceğiniz tüm TCP uzantıları Azaltmak olduğunu Sorun biraz da protokolün temel problemlerini çözemedikleri için. Ve hangi sağlayıcının problemi suçlayacağını belirlemede iyi şanslar , onlardan "uluslararası bir dizi büyük dosyayı transfer etmeye" çalışırken sorunu çözmelerini isteyin .

— Andrew Henle,