Accelerare i caricamenti SFTP su una rete ad alta latenza?

Sto cercando di trasferire un set di file di grandi dimensioni a livello internazionale utilizzando SFTP, ma sto trovando che il mio partner internazionale non può ottenere velocità di upload superiori a ~ 50k nonostante le connessioni molto buone su entrambi i lati. Siamo in grado di ottenere più connessioni caricando a questa velocità (quindi non larghezza di banda?), Ma nessun singolo upload migliora in velocità, il che è un problema in quanto molti file hanno dimensioni di diversi GB.

L'SFTP è ospitato utilizzando il sistema SFTP "Accesso remoto" di Apple OSX standard.

C'è un modo per migliorare la velocità di upload o c'è un host SFTP diverso che potrebbe aiutare? Non mi è chiaro se si tratta di un problema di configurazione o di una limitazione intrinseca del protocollo.

(Per motivi di sicurezza, devo utilizzare una connessione peer-to-peer crittografata end-to-end - nessun servizio cloud).

Con il client OpenSSHsftp (che sembri usare), puoi usare:

• -Rpassare per aumentare la lunghezza della coda richieste (il valore predefinito è 64)
• -Bpassare per aumentare la dimensione della richiesta di lettura / scrittura (il valore predefinito è 32 KB)

Per cominciare, prova a raddoppiare entrambi:

sftp -R 128 -B 65536 user@host

Probabilmente non importa molto, quale di essi aumenti.

L'aumento di entrambi dovrebbe aiutare a saturare la tua connessione ad alta latenza. Con le impostazioni di cui sopra, manterrà 8 MB di flusso di dati nel tubo in qualsiasi momento (128 * 64 K = 8 M).

Nota che questo aiuta solo con trasferimenti di file di grandi dimensioni. Non avrà alcun effetto quando si trasferiscono molti file di piccole dimensioni.

Per alcuni retroscena e una discussione su altri client SFTP (GUI), vedere la sezione "Ritardo / latenza di rete" della mia risposta a Perché il trasferimento di file SFTP FileZilla ha un limite massimo di 1,3 MiB / sec invece di saturare la larghezza di banda disponibile? rsync e WinSCP sono ancora più lenti .

Potresti provare ad abilitare la compressione e vedere se questo aiuta.

Da man sftp:

-C Abilita la compressione (tramite flag -C di ssh).

E da man ssh:

-C Richiede la compressione di tutti i dati (inclusi stdin, stdout, stderr e dati per le connessioni X11, TCP e UNIX inoltrate). L'algoritmo di compressione è lo stesso utilizzato da gzip (1) e il "livello" può essere controllato dall'opzione CompressionLevel per la versione del protocollo 1. La compressione è desiderabile su linee modem e altre connessioni lente, ma rallenterà le cose solo su reti veloci . Il valore predefinito può essere impostato su base host per host nei file di configurazione; vedere l'opzione di compressione.

Sembra piuttosto che la connessione potrebbe essere limitata in qualche punto lungo il suo percorso (o piuttosto, questa mi sembra la spiegazione più semplice per i tuoi 50kB / s per connessione, ma più connessioni possibili sono possibili), anche se potrebbe non essere un pessima idea di assicurarsi che i dischi su entrambi i lati non siano un fattore.

Potresti anche eseguire un rapido pcap per vedere se ci sono problemi 'ovvi' (come un gran numero di ritrasmissioni) - ma se non avessi una certa sicurezza saresti in grado di affrontare questo, probabilmente vedrei solo se abilitare la compressione Aiuto.

Sto cercando di trasferire un set di file di grandi dimensioni a livello internazionale utilizzando SFTP

Non è ancora stata menzionata come risposta, ma quando si trasferiscono più file su un collegamento ad alta latenza, esiste una soluzione davvero semplice per ottenere prestazioni migliori:

Trasferisci più file in parallelo.

Ed è una soluzione che hai persino menzionato nella tua domanda. Usalo

Fondamentalmente, il protocollo TCP non gestisce molto bene le connessioni con un grande prodotto che ritarda la larghezza di banda - una singola connessione non può far muovere abbastanza dati contemporaneamente. Vedi https://en.wikipedia.org/wiki/TCP_tuning

Poiché ogni connessione è limitata dal protocollo TCP, basta usare più connessioni.

Accelerare i trasferimenti sftp

Supponendo che i tuoi problemi siano l'ottimizzazione della rete e / o la limitazione per connessione TCP, dai un'occhiata a sftp usando il sottosistema mirror lftp

L'ottimizzazione della rete su ciascuna estremità è un argomento molto più ampio e richiederebbe molto avanti e indietro, spingendo l'argomento al di fuori dell'ambito di ServerFault. Per le connessioni individuali, la compressione menzionata da iwaseatenbyagrue può aiutare in entrambi i modi. Ciò presuppone che l'estremità remota consenta la compressione.

(Indichi "alta latenza" nel titolo della domanda, ma non nel testo del corpo. Hai misurato la latenza effettiva e quali sono i risultati?)

C'è una patch per OpenSSH che migliora esplicitamente il throughput su un collegamento di rete ad alta latenza: HPN-SSH : (enfatizzazione mia)

SCP e l'implementazione del protocollo SSH2 sottostante in OpenSSH sono le prestazioni di rete limitate da buffer di controllo del flusso interno definiti staticamente. Questi buffer finiscono spesso per fungere da strozzature per il throughput di rete di SCP, in particolare sui collegamenti di rete a banda lunga e alta. La modifica del codice ssh per consentire la definizione dei buffer in fase di esecuzione elimina questo collo di bottiglia. Abbiamo creato una patch che rimuoverà i colli di bottiglia in OpenSSH ed è completamente interoperabile con altri server e client. Inoltre, i client HPN saranno in grado di scaricare più velocemente da server non HPN e i server HPN saranno in grado di ricevere upload più velocemente da client non HPN.

Quindi, prova a compilare e utilizzare HPN-SSH sul lato ricevente e vedere se migliora la velocità di trasferimento.

Non sei sicuro che questa sia un'opzione per te, ma hai provato a tirare contro il push dei dati sul sito internazionale? Così come in momenti diversi per vedere se si tratta di un problema con la contesa per le risorse di rete?

Siamo in grado di ottenere più connessioni caricando a questa velocità (quindi non larghezza di banda?)

Sembra un problema di configurazione - o deliberatamente (come un modo di upselling dei servizi senza dover effettuare alcuna fornitura aggiuntiva) o per caso (ad esempio ridimensionamento delle finestre rotto o controllo del traffico troppo zelante). Mentre potresti parallelizzare i trasferimenti, non ci hai detto nulla di ciò che si trova all'altra estremità della connessione o se vale la pena sviluppare alcuni semplici script per gestire la condivisione / ricostituzione dei file.

È improbabile che l'ottimizzazione della dimensione e della compressione della coda abbia un impatto significativo, a meno che la causa sia un software scritto molto male (e openSSH non rientra in questa categoria - non ha molto senso utilizzare openssh con una coda di richiesta più lunga / dimensioni del blocco maggiori a meno che la latenza non sia oltre 250msec. È possibile provare a provare con client diversi da posizioni diverse per escludere un problema con il server.

La mia prima chiamata sarebbe quella di identificare quale fornitore è responsabile del problema, chiedere loro di risolvere il problema o passare a un altro fornitore.