Hello,

Je me suis récemment monté un nas sous Linux.
En LAN je l'utilise via NFS, aucun problème à ce niveau-là.

En revanche pour y accéder depuis mon téléphone j'ai essayé de le faire via SFTP, cela fonctionne mais c'est extrêmement lent.

Dernier exemple en date, je tente d'accéder à des fichiers depuis une connexion 5G à un débit de plus de 40 Mbps, le téléchargement de fichier se fait à a peine 500 kB/s... Donc plus de 10x moins rapide que le réseau disponible.

La machine du nas n'a aucune charge cpu (à peine 2%...) et est raccordée à internet en nat directement derrière mon routeur fibre qui dispose d'un accès à internet à 600Mbps montant et 1Gbps descendant.

Dans ces conditions, je ne comprend vraiment pas pourquoi les transferts sont à ce point plus lents que le réseau ? Est-ce intrinsèque au protocole SFTP ?

Merci

non ce n'est pas lié au protocole SFTP. Tu peux facilement vérifier en refaisant le test en SFTP depuis ton LAN.
Un autre test que tu peux faire est de télécharger en 5G mais via HTTP pour voir si le problème est spécifique à SFTP+5G ou pas.

Ouais,
 
SFTP en LAN = j'ai déjà essayé, ressenti plus rapide qu'en 5G mais quand même beaucoup plus lent qu'en NFS. Faudrait que je fasse des mesures pour avoir des infos plus objectives.
 
HTTP en 5G = à peu près 10x plus rapide, comme le débit du réseau le laisse supposer.

Quelques autres tests depuis chez moi, téléchargement d'un fichier unique de 15MB:
 
Téléphone en wifi + SFTP: téléchargement rapide <1s, peu importe que j'utilise l'adresse LAN du nas ou l'adresse WAN de ma box (+nat vers le serveur).
 
Téléphone en 5G : connexion testée à 150mbps par speed test, mais le SFTP plafonne a 800kBps et le téléchargement prend environ 15s.
En 5G + http (même serveur, même fichier) ça reste beaucoup plus lent qu'en wifi, mais environ 2 ou 3x plus rapide qu'en SFTP.

SFTP ça aime pas trop la latence et vu que c'est de l'UDP ça aime pas trop si je dis pas de conneries le désordre des paquets etc.

SFTP c'est du SSH, donc TCP.
 
Moi je parie sur un throttle côté opérateur mais je dis ça un peut au pif, pour aller plus loin faudrait faire une capture de paquets de part et d'autre.

Un throttle opérateur qui se déclencherait en SFTP uniquement et que je n'aurai pas par exemple lorsque j'upload des fichiers en http depuis chez moi ni en speedtest ?
 
Ça serait étrange non ?

Ce que je remarque au fil de mes tests, c'est que la vitesse semble scaler assez linéairement avec la vitesse de la connexion distante, que ce soit une connexion 4/5G ou une ligne fixe chez ma famille.
 
En revanche ça reste toujours ~10x plus lent que le réseau disponible.

 
oui c'est pour ça que je suis vraiment pas sûr. Faudrait essayer un transfert avec un autre protocole bien identifié "transferts de fichiers" pour voir si on a le même comportement, genre FTP.
 
tu peux peut-être aussi demander sur lafibre.info, il y aura peut-être des gens mieux renseignés qu'ici sur ce genre de limitation.

My bad j'ai pensé TFTP   je sais pas pk. J'ai bien déconnecté ce WE Pascal  

J'ai refait plein de tests, sans succès :
 
Depuis mon vps chez ovh, transfert capé à 1MBps. J'ai utilisé cette machine pour comparer SFTP et scp, exactement le même résultat.
 
Changer le port externe du NAT pour 2222 au lieu de 22 => aucune différence.
 
Mettre le serveur dans la dmz de la box plutôt que passer en NAT => aucune différence.
 
Désactiver le chroot de mon user SFTP => aucune différence.
 
Utiliser une Auth par mdp plutôt que clé privée => aucune différence.

Si j’en crois ce billet tout juste publié hier et annonçant la sortie d’OpenVMS 9.2 (oui, ça existe encore), il semblerait que ces lenteurs soient inhérentes au protocole SFTP…
 
OpenVMS 9.2 for x86 is finally available for hobbyists!
 
Perso, quand je veux transférer rapidement des fichiers entre les deux PC que j’ai chez moi, je passe en effet par SFTP. Mais là où c’est bizarre, c’est que si je transfère dans le sens fixe (en Ethernet et CPL) vers portable (en Wi-Fi), je peux atteindre du 7 Mio/s (le plafond du CPL) ; tandis que dans l’autre sens, ça plafonne à 2,5 Mio/s (alors que là où il est placé, le portable peut télécharger à 13 ou 14 Mio/s). Je mettais cette asymétrie sur le compte de la différence de modes de transmission (filaire contre sans fil), mais ça pourrait ne pas venir de là…

J'en viens à penser ça aussi, que la vitesse de téléchargement scale non seulement avec le débit mais également avec la latence...

Oui c'est un fait établi d'un point de vue théorique: https://en.wikipedia.org/wiki/Bandwidth-delay_product
 
Maintenant ça reste difficile d'affirmer que c'est le problème que tu rencontres.

Bon, quelques nouveaux tests viennent totalement invalider l'idée selon laquelle cela serait inhérent au protocole.
 
Par exemple, depuis mon VPS hébergé chez ovh, je me connecte à mon NAS.
Si je transfère un fichier du NAS vers OVH : 1MBps.  
 
Mais si je fais l'inverse, j'ai la même connexion donc, même latence, simplement le NAS passe en sens descendant à 1000 Mbps théorique au lieu de montant (600 Mbps théorique).  
Donc logiquement je m'attends à ce que cela soit ~2x plus rapide puisque la SEULE différence c'est la bande passante disponible au niveau du NAS qui est 2x plus grande.
Sauf que non, là dans ce sens on sature la bande passante et on monte à 50 MBps.

faudrait faire une capture pour voir si la MTU est la même dans chaque sens.

Mouais, j'ai du mal à imaginer qu'une simple différence de MTU puisse causer une telle différence, on est sur un factur 50 quand même pas 3 ou 4.
 
En tous cas ma box me rapporte un seul MTU, y'a pas de distinction de sens.

Encore un test entre mon NAS et mon VPS, cette fois j'ai copié le même fichier dans le même sens (upload), mais :  
 

• Si je fais un PUT depuis le NAS, pas de problème, copie instantanée.
• Si je fais un GET sur le même fichier mais depuis le VPS, je suis limité à 1 MBps.

Vraiment chelou cette histoire.

J'ai fait un peu de packet capture avec tcpdump sur le nas, mais je ne maîtrise pas trop le réseau à un si bas niveau je ne sais pas trop quoi chercher.
 
Au niveau de la longueur de trame je constate une légère différence, 1388 dans le "mauvais" sens et 1428 dans le "bon".
Au niveau de ma box et de l'interface ethernet je voyais un MTU de 1500 donc ça paraît cohérent.
À vue de nez, pas de quoi justifier une telle différence de débit ?

fais la même capture côté VPS pour voir si les valeurs correspondent.

je sais pas si tu as vu mais avec tcpdump -w toto.pcap tu peux générer un fichier que tu peux ensuite ouvrir dans wireshark pour analyse, et ça permet de faire des choses assez poussées, tu peux par exemple grapher à peu près n'importe quoi (le delta de temps entre les paquets, le taux de retransmissions, etc)

Je vais essayer de regarder ça

Voilà le résultat côté NAS en capturant dans les deux sens :  
https://owncloud.jbellion.fr/index. [...] 0Cuv8gdmsx
 
Dans un sens on constate un packet rate élevé (25/ms en moyenne) et quasiment aucune erreur TCP sur le graphique.
Dans l'autre sens, un packet rate significativement plus faible (0.5/ms) et un taux d'erreurs bien plus élevé.

OMG je crois que j'ai trouvé, il suffisait d'ajouter :  
 
IPQoS lowdelay throughput
 
dans /etc/ssh/sshd_config.
 
Pas sûr d'avoir tout compris mais apparemment le fait que la connexion vienne d'internet ajoute un flag à la trame IP, et les serveurs SSH interprètent cela comme un signal qu'il faut limiter le packet rate ?

non le tag dscp il est présent dans tout paquet IP, et il est positionné par la machine qui envoie le paquet (il peut être modifié par les équipements sur le chemin mais normalement ça ne devrait pas être le cas). C'est un truc que tu peux vérifier facilement dans ta capture, tu peux regarder s'il a des valeurs différentes dans les différents cas ou pas. Et avec la capture de chaque côté tu peux vérifier s'il est modifié en chemin.