Les paquets IP disposent d'un champ dans leur en-tête permettant de spécifier la classe de trafic auquel ils appartiennent (valeur DSCP). Ces classes de trafic peuvent être utilisées par le réseau pour prioriser certains flux par rapport aux autres.
Par exemple, la voix sur IP, la visio conférence, les jeux vidéos temps réel ou les sessions SSH sont très interactifs et réagissent mal à la perte de paquets ou à la jigue (variation de la latence). Au contraire, les transferts de données volumineux ont besoin d'une bande passante élevée mais peuvent passer après les autres, car très peu sensibles à la jigue.
L'OS ne sait pas ce qu'une application pousse dans une socket (en gros, un flux de données), mais l'application possédant cette socket peut lui demander de marquer tous les paquets appartenant à ce flux avec une classe de trafic donnée.
Si aucune demande n'est faite par l'application, l'OS utilise une classe de service par défaut "best effort", normalement.
Dans le cas qui t'intéresse, scp marque par défaut son trafic en CS1, c'est à dire moins prioritaire que le trafic best effort, qui représente l'écrasante majorité du trafic Web.
Comme le réseau d'Orange honore les marquages DSCP, il dé-priorise donc ton trafic scp au profit des autres flux empruntant le même chemin réseau: le débit utile de ce flux souffre donc.
Debian s'est rendu compte de la supercherie et a changé la classe de trafic par défaut utilisée par scp dans leur OS, ce qui explique qu'il ne souffre pas du souci. Mais sur un autre OS sans cette modification, scp marquera son trafic en CS1 par défaut (cas de macOS).
Je suppose que, chez Free, soit le réseau ne discrimine pas sur le champ DSCP, soit la box ou l'OLT ré-écrit le champ lors de la réception d'un paquet depuis le LAN, et donc là aussi, tu n'observais pas le problème.
Avec la ligne de configuration que je t'ai donné, on indique à ssh et à scp de marquer le trafic avec la classe par défaut, comme la grande majorité du trafic web, donc. Et cela résout le problème.
Débit fibre