Supposons qu'un fragment TCP donné soit fragmenté en deux datagrammes IP et que le premier datagramme arrive au serveur TCP, mais le deuxième datagramme n'arrive jamais.
Après un certain laps de temps, le serveur TCP envoie un keepalive et détermine que le client est vivant. Que fait alors le serveur TCP avec ce premier datagramme? Attend-il que le deuxième datagramme arrive ou rejette-t-il le premier datagramme?
Réponses:
Une fois le délai d'expiration du réassemblage du fragment expiré, le fragment est supprimé; l'autre extrémité devrait être retransmise.
Ce délai est généralement configurable. Sous Linux, c'est 30 secondes par défaut et contrôlé via /proc/sys/net/ipv4/ipfrag_time.
Il n'y a pas de réponse définitive à cette question;
Si vous voyez cet article sur la retransmission adaptative, vous verrez que TCP utilise RTT comme facteur dans le calcul des retards appropriés.
Ceci est un article plus détaillé. Essentiellement, il n'y a pas de valeur de délai d'attente spéciale uniquement pour la fragmentation.
Cet article de Cisco indique cependant qu'un pare-feu virtuel IOS XR a un délai par défaut de 10 secondes pour les fragments, avec son propre temporisateur configurable. Je relie ceci pour dire que les systèmes d'exploitation et les appareils vont se comporter différemment et si vous passez une connexion via un appareil comme celui-ci par exemple, cela pourrait interférer négativement avec votre connexion.
Il serait préférable de connecter deux machines de la même configuration avec un croisement et de commencer les tests à partir de là si vous souhaitez tester les effets du retard de fragmentation.