si un paquet TCP a reçu un accusé de réception partiel, comment le mécanisme de retransmission réagit-il ?

C'est ce qu'on appelle reconnaissance sélective et est déjà incluse dans la spécification TCP définie dans RFC 2018 . Cela permettrait au client de renvoyer uniquement les octets 15001 à 20000 (puisqu'ils se trouvent dans des paquets/segments différents). si vous les aviez divisés comme vous le dites), mais, plus intéressant encore, il permet même des accusés de réception dans le désordre.

De RFC 2018 :

Lorsqu'il reçoit un ACK contenant une option SACK, l'expéditeur des données DOIT enregistrer l'accusé de réception sélectif pour référence ultérieure. L'expéditeur de données est supposé avoir une file d'attente de retransmission qui contient les segments qui ont été transmis mais pas encore acquittés, dans l'ordre des numéros de séquence.

Soutien à SACK es no requis par la spécification TCP. Si le client o le serveur ne prenait pas en charge l'accusé de réception sélectif, en effet tous les octets 10000 à 20000 devaient être retransmis.

Dans la mise en œuvre de la pile TCP, est-ce la même chose que dans la théorie ?

Habituellement SACK est soutenu, car les gains en termes de performances, d'efficacité et de latence sont importants, surtout dans un réseau comme l'internet.

En effet, ces hypothèses devraient rester vraies même si vous manipulez manuellement les paquets comme vous l'avez indiqué. D'après RFC 793 au minimum, toute la fenêtre de données devra être retransmise, mais le récepteur fait savoir que les données reçues sont au moins valide . Pour les détails de mise en œuvre, Section 3.3 - Numéros d'ordre de la RFC 793.

Pour un aperçu de l'ensemble du processus, avec et sans soutien sélectif de reconnaissance, voir cet article (qui comprend des diagrammes très utiles).

La taille des segments peut changer (et change effectivement) au cours de la durée de vie d'une connexion. Heureusement, TCP n'a pas besoin d'enregistrer la taille du segment avec lequel les paquets individuels ont été envoyés précédemment. Par conséquent, il procède comme suit :

1. Chaque fois qu'un ACK arrive, avancez le pointeur vers le premier octet non acquitté en conséquence et éliminez tout tampon désormais inutile.
2. Lorsque le besoin de retransmission (Retransmission rapide ou Timeout) se fait sentir ; PAS immédiatement après la réception du premier ACK !), il enverra à nouveau dans le mode taille du segment actuellement valide en commençant par le pointeur du premier octet non acquitté.

Les deux opérations sont effectuées indépendamment de la taille du segment dans lequel ces octets ont été envoyés à l'origine. La théorie devrait donc correspondre à la plupart des implémentations.

Permettez-moi de vous donner quelques explications :

Le protocole TCP utilise-t-il des octets ou des segments ? Pour l'application, TCP expose une interface de flux d'octets. De même, tous les champs d'en-tête et les variables internes sont en octets. Cependant, pour transmettre des informations, TCP les découpe en segments, car l'envoi d'octets un par un serait un gaspillage :-). L'utilisation de compteurs d'octets partout présente l'avantage que la taille du segment ne doit pas nécessairement rester constante pendant toute la durée de la connexion :

• Des options sont introduites, par exemple l'ajout d'un SACK à une retransmission (les implémentations réelles ne rencontrent ce problème que rarement, voire jamais).
• Le MTU du chemin change, c'est-à-dire qu'un lien le long du chemin passe à un MTU inférieur ou que le lien MTU du goulot d'étranglement est augmenté. Cela se produit lorsque des tunnels sont établis (VPN, PPPoE) ou que le protocole de routage sélectionne un lien MTU différent. Cela se produit dans IPv4 avec Don't Fragment set (vrai pour la plupart des TCP modernes) ; toujours dans TCPv6).

BTW : SACK n'est pas la solution ici, car le récepteur n'utilisera (typiquement) SACK que s'il reconnaît une trou dans le flux d'octets (c'est-à-dire si un paquet a été perdu mais qu'un paquet suivant est arrivé).