Débit maximum

Niveau : Star Star Empty Empty Empty
Résumé : TCP + RTT + window size = debit

Si je me connecte au réseau local gigabit, que je fais un transfert de fichier ... je n'arrive pas à dépasser 200Mb/s ! Vous rendez-vous compte que c'est normal ?

Vous allez me dire que je ne suis pas doué, mais ce n'est pas moi, ce sont les lois de la physique.

Bon puisque nous somme dans un cas particulier je m'explique.

Temps de réponse

Le débit a beau toujours augmenter, il y a quelque chose qui s'améliore beaucoup moins vite : le temps de réponse. Pour une bonne raison, l'information a une vitesse limite, celle de la lumière. La limite est un peu inférieure sur une fibre optique et encore inférieure sur un câble cuivre.

De plus il faut une certaine électronique pour traiter tous ces paquets et ce débit. Du coup la traversée de switchs et de firewall en fout un coup à la latence. Et pourtant le débit ne change quasiment pas.

Tout ceci se voit avec la commande ping. Si vous lancez un ping sur la machine d'à coté, vous constatez un temps de réponse de l'ordre de la milliseconde.

Par exemple :

PING mamachine (10.0.0.0.1) 56(84) bytes of data.
64 bytes from mamachine (10.0.0.0.1): icmp_seq=1 ttl=61 time=1.16 ms

C'est le temps qu'il a fallu pour créer le paquet ping, l'envoyer à travers le switch, le réceptionner, répondre, repasser dans le switch, lire la réponse. Donc il faut la diviser par deux pour avoir un ordre de grandeur du temps de transfert du paquet.

Pour une machine sur un autre réseau c'est plus dans les 20ms voire 100ms.

Dans cette histoire les plus gros temps de latence dépendent de votre infrastructure, si vous êtes sur une fibre de 100km c'est elle qui contribuera à la latence, si vous êtes sur un réseau local c'est plus le temps de traitement par la carte réseau et le noyau, et s'il y a plusieurs switchs ou un routeurs c'est l'électronique des ces appareils.

Tout ça pour dire qu'il y a plusieurs limitations qui font que la latence ne s'améliore pas aussi vite que le débit.

TCP

Le TCP a été inventé à une époque où le débit d'une connexion était de l'ordre du Mb/s en local.

Une des limite du TCP est la taille des données pouvant être envoyés sans attendre de réponse (window size). Celle-ci est variable mais est limitée à 65535. Ce qui veut dire qu'une fois qu'on a envoyé 64ko de données il faut attendre une réponse, sinon on est coincé.

On voit donc bien une limite en débit apparaître à cause de la latence.

Cette limite est toute simple à calculer :
débit max = taille fenêtre / latence d'un paquet

Ce qui nous donne pour la connexion précédente :
débit max = 64ko*8 / 0.00116 = 450Mb/s

Dommage, je pensais avoir du gigabit !

Donc pensez-y la prochaine fois que vous faites un test de transfert réseau et que vous constatez que vous n'atteignez pas la limite théorique de votre réseau. Commencez par faire un ping et refaites le calcul ci dessus pour voir quelle était la limite.

PS : ce calcul n'est valable que pour une unique connexion. Si vous en avec 2 vous avez deux fois cette limite.

Erreurs

De plus, une chose qu'on ignore car elles sont devenues rares et corrigées, ce sont les erreurs.

Elles ont beau être rares lorsqu'on envoi des milliards d'octets par seconde il commence à y en avoir pas mal.

Chaque perte de paquet provoque un renvoi de touts les paquets non acquittés depuis, soit dans le pire des cas la taille de la fenêtre. La forte utilisation d'un réseau peut augmenter la perte de paquet et donc avoir un impact visible sur le débit total obtenu.

La formule est cette fois :
débit max = MSS / latence / sqrt(Proba perte de paquet)

Pour un réseau local, en général MSS=1460, prenons une perte de 0.1% on obtient :
débit max = 1460*8 / 0.00116 / sqrt(0.001) = 320Mb/s

Encore pire !

La suite

Mais non, TCP a beau être vieux, il a toujours des réserves. 2 évolutions ont donc été ajoutées à ce protocole il y a déjà un certain temps : window scaling et selective acknowledgement.

Window scaling est une extension TCP permettant d'augmenter la taille de la fenêtre jusqu'à 1Go, ça nous laisse un peu de marge.

Sous linux on vérifie l'utilisation de cette option et la taille de fenêtre associée avec :

$ cat /proc/sys/net/ipv4/tcp_window_scaling
$ cat /proc/sys/net/core/wmem_default
$ cat /proc/sys/net/core/wmem_max

Selective acknowledgement permet de demander la retransmission d'un seul paquet et non pas de toute la fenêtre. Cela permet de limiter l'impact des pertes de paquet sur les réseaux avec une forte latence.

Sous linux on vérifie l'utilisation de cette option avec :