En fait la stratégie d'ouvrir plusieurs connexions TCP en parallèle pour remplir le réseau n'est qu'un contournement. Le vrai problème est souvent lié à un problème de taille de fenêtre TCP qui ne monte pas assez haut.
C'est assez trivial à comprendre. TCP est un protocole qui nécessite l’acquittement des données transmises régulièrement. La quantité de donnée qu'une extrémité peut envoyer avant d'attendre un acquittement de l'autre extrémité s'appelle la fenêtre de réception. Dés que la latence ou la bande passante augmente dans certaine proportions, il faut que la taille de cette fenêtre suive, sinon, l’émetteur passe son temps a attendre l'acquittement des données qu'il vient de transmettre.
La formule c'est RWIN = BP * RTT.
Imagine une liaison satellite à 10Gb/s ayant un RTT de 0.5s, il faut que cette fenêtre atteigne 5Gb soit une fenêtre de 625Mo pour que la connexion TCP remplisse le tuyau.
C'est un exemple extrême, mais même avec des latence type WAN "contintental", disons 10 ms, il faut déjà une fenêtre de 12,5 Mo pour monter à 10Gb/s (1,25 pour 1 Gb/s, etc ...)
Il y a plein de chose qui peuvent "brider" cette fenêtre de transmission, par exemple, un certain nombre de paramètres sur les systèmes hôtes (par exemple sous linux : net.ipv4.tcp_rmem ou tcp_window_scaling). Mais pas seulement, quelque fois le problème est carrément coté applicatif qui n'alloue pas assez de mémoire dans ses buffers interne. Par exemple, il y a un patch bien connu qui existe pour openssh : https://www.psc.edu/hpn-ssh
L'accélération matérielle TCP de certaines cartes réseau peut aussi interférer.
A l'origine, le protocole TCP lui-même ne prévoyait qu'une fenêtre maximum de 64ko. Étendue à 1Go en utilisant le mécanisme d'extension de la fenêtre de transmission TCP (TCP window scaling, RFC 1323). Pour approfondir, on peut lire l'excellent billet de Stéphane Bortzmeyer sur la question.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: copie efficace vers/de une machine distante
Posté par Big Pete . En réponse à la dépêche Sortie de gfast-copy et de fast-copy sur www.open-source-projects.net. Évalué à 10.
En fait la stratégie d'ouvrir plusieurs connexions TCP en parallèle pour remplir le réseau n'est qu'un contournement. Le vrai problème est souvent lié à un problème de taille de fenêtre TCP qui ne monte pas assez haut.
C'est assez trivial à comprendre. TCP est un protocole qui nécessite l’acquittement des données transmises régulièrement. La quantité de donnée qu'une extrémité peut envoyer avant d'attendre un acquittement de l'autre extrémité s'appelle la fenêtre de réception. Dés que la latence ou la bande passante augmente dans certaine proportions, il faut que la taille de cette fenêtre suive, sinon, l’émetteur passe son temps a attendre l'acquittement des données qu'il vient de transmettre.
La formule c'est RWIN = BP * RTT.
Imagine une liaison satellite à 10Gb/s ayant un RTT de 0.5s, il faut que cette fenêtre atteigne 5Gb soit une fenêtre de 625Mo pour que la connexion TCP remplisse le tuyau.
C'est un exemple extrême, mais même avec des latence type WAN "contintental", disons 10 ms, il faut déjà une fenêtre de 12,5 Mo pour monter à 10Gb/s (1,25 pour 1 Gb/s, etc ...)
Il y a plein de chose qui peuvent "brider" cette fenêtre de transmission, par exemple, un certain nombre de paramètres sur les systèmes hôtes (par exemple sous linux : net.ipv4.tcp_rmem ou tcp_window_scaling). Mais pas seulement, quelque fois le problème est carrément coté applicatif qui n'alloue pas assez de mémoire dans ses buffers interne. Par exemple, il y a un patch bien connu qui existe pour openssh : https://www.psc.edu/hpn-ssh
L'accélération matérielle TCP de certaines cartes réseau peut aussi interférer.
A l'origine, le protocole TCP lui-même ne prévoyait qu'une fenêtre maximum de 64ko. Étendue à 1Go en utilisant le mécanisme d'extension de la fenêtre de transmission TCP (TCP window scaling, RFC 1323). Pour approfondir, on peut lire l'excellent billet de Stéphane Bortzmeyer sur la question.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.