Les
timestamp (horodatage TCP) sont activés avec tous les systèmes d'exploitation. La MSS n'est donc plus de 1460 octets.
Les
timestamp permettent, entre autres, d'obtenir avec précision le RTT d'un paquet
● en cas de paquets reçus en désordre
● lors de retransmis° (à quel paq se réfère un ack ?)
● sur plusieurs paquets, permet de savoir si la congestion est sur le chemin ascendant ou descend
C'est nécessaire pour les Rwin importantes, elles mêmes nécessaire pour les très haut débit.
Chaque paquet est numéroté et si il est perdu, il demande le renvoi de tous les paquets à partir du n° x (ou ne demande de renvoyer que le n° x si l'option SACK est activé). Le N° est codé sur 16bits donc 65535 possibilités. Le N° reviens donc a 0 tous les 65535. Avec des grandes Rwin, il y a risque d'avoir le même N° de paquet 2 fois. En cas d'erreur, il ne sauras donc pas quel paquet renvoyer. Les timestamps sont la pour résoudre ce problème. Ils sont donc indispensable pour les grandes Rwin, donc pour les connexions FTTH et satellites.
Le pb c'est que les clients Windows font une demande de timestamp tellement a coté des RFC que si on interprète strictement les RFC qui disent "When TSecr is not valid, its value must be zero.", on désactive le timestamp. C'est donc le ca d'un client Windows avec un serveur Linux (cas très fréquent, Windows étant majoritaire sur les clients et Linux majoritaire sur les serveurs)
Dans les paquets initiants une connexion (flag SYN seul monté), on ne se préoccupe pas de la valeur de TSecr, mais uniquement de la valeur de TSval), Ensuite, la valeur de TSval est recopiée dans TSecr, lors de la réponse (flag ACK seul monté), or il est dit que Tsecr n'est pas valide si sa valeur est de zéro. Windows XP mettant 0 TSval, on se retrouve avec 0 dans TSrec, du coup, la gestion des timestamps n'est pas activée avec les systèmes qui respectent la RFC (linux).
Un exemple avec un client linux : Tsval = 458372 et non 0
On voit que dans les paquets derrière les timestamps sont activés (les valeurs Tsval et Tsecr s'incrèmentent)
On voit que la Rwin du client est de 5792 au démarrage et qu'il va l'augmenter au fur et a mesure a chaque acquittement. (rwin adaptative)
Voici un exemple avec Windows : TSV = 0
RFC1323 page 12 :
+-------+-------+---------------------+---------------------+
|Kind=8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)|
+-------+-------+---------------------+---------------------+
The Timestamps option carries two four-byte timestamp fields.
The Timestamp Value field (TSval) contains the current value of
the timestamp clock of the TCP sending the option.
The Timestamp Echo Reply field (TSecr) is only valid if the ACK
bit is set in the TCP header; if it is valid, it echos a times-
tamp value that was sent by the remote TCP in the TSval field
of a Timestamps option. When TSecr is not valid, its value
must be zero. The TSecr value will generally be from the most
recent Timestamp option that was received; however, there are
exceptions that are explained below.Il est dit que Tsecr n'est pas valide si sa valeur est de zéro. (et Linux désactive les timestamps quand Tsecr n'est pas valide)
Microsoft Windows ne respecte pas la norme en envoyant TSval 0, TSecr 0 lors du SYN alors que ce n'est pas le cas d'un client linux qui envoi TSval 16111025, TSerc 0 lors d'un SYN. (16111025 est un exemple)
Microsoft Windows est en tord sur ce point là : il n'est pas logique de mettre un zéro dans TSval puisque de cette façon, toutes les requêtes de demande de connexion ont un timestamp équivalent de zéro et que Linux désactive les timestamps (les timestamps sont activé si le serveur est un FreeBSD ou un Winodws)
Comment tester son débit ?