Tout d'abord un peu de contexte, le TCP a un concept appelé taille maximale des segments (MSS). Il s'agit du plus grand segment (de données) que la pile TCP accepte. Elle est annoncée au pair distant dans le segment SYN lorsque la connexion est établie. Le décodage de paquet suivant montre le segment SYN avec l'option TCP MSS en surbrillance. Toutes les options TCP ont le même format, 1 octet pour le numéro d'option, 2 dans ce cas, 1 octet pour la longueur totale de l'option (4) et la valeur de l'option, dans ce cas 5b4 hex ou 1460 décimal.
packet_monitor -interface #sdlmux.m16.11-3 -hex_dump -numeric -time_stamp -verbo +se -pkt_hdr -filter -host 10.64.77.50 dir icmp type + tcp hh:mm:ss.ttt dir len proto source destination src port ds +t port type 10:11:56.751 Xmit Ether Dst 00:23:54:52:18:6e Src 00:00:a8:43:52:22 Type 0800 +(IP) IP Ver/HL 45, ToS 0, Len 2c, ID be0b, Flg/Frg 0, TTL 3c, Prtl 6 Cksum dcdd, Src a404d80, Dst a404d32 TCP from 10.64.77.128.55911 to 10.64.77.50.telnet seq 1305537174, ack n.a., window 8192, 4 data bytes, flags Syn. X/Off 06, Flags 02, Cksum 815d, Urg-> 0000 offset 0 . . . 4 . . . 8 . . . C . . . 0...4...8...C... 0 2 4 5 b4 <<<4
Pour une connexion établie avec un hôte sur un réseau local, le STCP utilise une valeur de 1460. Une fois que vous ajoutez tout le protocole, vous obtenez une trame Ethernet de 1518 octets, soit la taille maximale d'une trame Ethernet. Pour les connexions établies avec des hôtes sur des segments non locaux, le STCP utilise une valeur dérivée du paramètre min_mss. L'utilisation de la valeur min_mss par défaut donne une valeur MSS de 536. Cette valeur est la taille minimale que tous les équipements de réseau basés sur IP, c'est-à-dire les routeurs, doivent être prêts à transmettre sans fragmentation IP. La spécification qui a établi 536 comme minimum a été écrite en 1983 dans la RFC 879 - "The TCP Maximum Segment Size and related Topics".
Aujourd'hui, il est probable que tous vos routeurs peuvent gérer une taille plus importante. Vous pouvez donc faire passer le minimum du STCP de 536 à une taille supérieure. La question clé est de savoir de combien est plus grande la taille. Le danger de le rendre trop grand est la fragmentation. Le pire scénario, mais le plus facile à diagnostiquer, est que le routeur choisira de se débarrasser du segment TCP au lieu de le fragmenter. Dans ce cas, vous pourrez établir une connexion, mais lors du transfert de données, la connexion échouera. Une trace sur l'hôte d'envoi montrera de multiples retransmissions de grands segments TCP jusqu'à ce que la connexion soit terminée. La trace peut également montrer des messages ICMP de destination inaccessibles provenant du routeur qui rejette le segment. Si le routeur choisit de fragmenter le segment, il donnera probablement au processus de fragmentation une faible priorité, ce qui peut en fait entraîner une réduction du débit. La probabilité de perdre le segment pour cause de corruption ou d'encombrement augmente également avec le nombre de fragments. Le moyen le plus simple de savoir si c'est le cas est d'exécuter une trace packet_monitor sur le module. Si les segments TCP arrivent sous forme de fragments, vous savez qu'il y a eu fragmentation.
Les trois trames Ethernet suivantes représentent un segment TCP fragmenté en trois parties. Vous pouvez dire que la première trame est un fragment car la valeur Flg/Frg est de 2000. Le 2 indique que le bit More Fragments est activé et le 000 est le décalage du fragment, dans ce cas 0 indique qu'il s'agit du premier fragment. Le moniteur de paquets signale en fait que les 2 images suivantes sont des fragments. La valeur Flg/Frg de la trame 2 est 2048, le 2 indique à nouveau que le bit More Fragments est activé et le 48 est le décalage (en multiples de 8 octets) des données du datagramme IP original. La troisième trame a un Flg/Frag de seulement 90, ou plus précisément 0090. Comme le bit More Fragments est à 0, nous savons qu'il s'agit du dernier fragment. Nous savons que toutes ces trames appartiennent au même ensemble car elles ont toutes la même valeur d'identification IP, 2e87. La longueur des données dans la première trame est une indication de la valeur MSS qui doit être définie, dans ce cas 556.
15:52:27.081 Rcvd Ether Dst 00:00:a8:43:52:22 Src 00:12:3f:82:57:10 Type 0800 +(IP) IP Ver/HL 45, ToS 8, Len 254, ID 2e87, Flg/Frg 2000, TTL 3f, Prtl 6 Cksum 1422, Src c0a86432, Dst a404d80 TCP from 192.168.100.50.32781 to 10.64.77.128.ftp-data seq 568258166, ack 840605671, window 5440, 556 data bytes, flags Ack. X/Off 05, Flags 10, Cksum d149, Urg-> 0000 offset 0 . . . 4 . . . 8 . . . C . . . 0…4… 8…C… 0 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 * 5678901234567890 10 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 * 1234567890123456 20 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 * 7890123456789012 30 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 * 3456789012345678 40 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 * 9012345678901234 50 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 * 5678901234567890 60 d a 31 32 33 34 35 36 37 38 39 30 31 32 33 34 * <<12345678901234 70 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 * 5678901234567890
15:52:33.793 Rcvd Ether Dst 00:00:a8:43:52:22 Src 00:12:3f:82:57:10 Type 0800 +(IP) IP Ver/HL 45, ToS 8, Len 254, ID 2e87, Flg/Frg 2048, TTL 3f, Prtl 6 Cksum 13da, Src c0a86432, Dst a404d80 TCP from 192.168.100.50. to 10.64.77.128. *fragments*, 576 bytes data offset 0 . . . 4 . . . 8 . . . C . . . 0…4… 8…C… 0 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 * 1234567890123456 10 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 * 7890123456789012 20 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 * 3456789012345678 30 39 30 d a 31 32 33 34 35 36 37 38 39 30 31 32 * 90<<123456789012 40 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 * 3456789012345678 50 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 * 9012345678901234 60 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 * 5678901234567890 70 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 * 1234567890123456
15:52:33.793 Rcvd Ether Dst 00:00:a8:43:52:22 Src 00:12:3f:82:57:10 Type 0800 +(IP) IP Ver/HL 45, ToS 8, Len f8, ID 2e87, Flg/Frg 90, TTL 3f, Prtl 6 Cksum 34ee, Src c0a86432, Dst a404d80 TCP from 192.168.100.50. to 10.64.77.128. *fragments., 228 bytes data offset 0 . . . 4 . . . 8 . . . C . . . 0…4… 8…C… 0 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 * 5678901234567890 10 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 * 1234567890123456 20 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 * 7890123456789012 30 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 * 3456789012345678 40 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 * 9012345678901234 50 35 36 37 38 39 30 d a 31 32 33 34 35 36 37 38 * 567890<<12345678 60 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 * 9012345678901234 70 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 * 5678901234567890
Le problème de l'augmentation de la valeur du MSS est qu'elle l'augmente pour toutes les connexions TCP. Vous ne pouvez pas l'augmenter pour une seule ou quelques destinations. Vous devez donc tester soigneusement cette modification pour évaluer son effet sur toutes vos connexions.
Vous pouvez voir la valeur MSS actuelle et la modifier à l'aide des deux commandes suivantes :
analyze_system -request_line 'list_stcp_params min_mss' -quitOpenVOS Release 17.0.1as, analyze_system Release 17.0.1asCurrent process is 357, ptep 8FA86000, Noah_Davids.SysAdmin
maximum tcp segment size [500-1480] (min_mss) 556
ready 10:52:07analyze_system -request_line 'set_stcp_param min_mss 1480' -quit OpenVOS Release 17.0.1as, analyze_system Release 17.0.1asCurrent process is 357, ptep 8FA86000, Noah_Davids.SysAdmin
Changing maximum tcp segment size (min_mss)from 556 to 1480ready 10:52:24
Le nom du paramètre, min_mss, implique qu'il s'agit de la valeur MSS mais il s'agit en réalité de la valeur MSS plus la longueur de l'en-tête TCP de 20 octets. Dans l'exemple ci-dessus, la valeur de min_mss serait 556+20 ou 576.
Alors, quelle est l'impulsion que vous pouvez donner en augmentant la valeur du MSS ? En raison de la prévalence des connexions VPN qui ajoutent des octets supplémentaires, je ne recommande pas de fixer la valeur maximale à 1480 (MSS TCP réel de 1460). Je suggère quelque chose d'un peu plus petit, disons 1220 (MSS réel de 1200) octets. En supposant que vous envoyez 10 mégaoctets de données en utilisant des segments de 536 octets, il faudra 18657 trames, le nombre total d'octets - y compris l'overhead (8 octets de préambule Ethernet + 14 octets d'en-tête Ethernet + 20 octets d'en-tête IP + 20 octets d'en-tête TCP + 4 octets de fin Ethernet + 12 octets effectifs pour l'espace inter-trames Ethernet) sera de 11 455 246 octets. Si vous utilisez des segments de 1200 octets, il vous faudra 8334 trames avec un nombre total d'octets de 10 650 052, soit un peu plus de 9 % de moins. Cependant, gardez à l'esprit que la valeur MSS est une annonce du plus grand segment qui sera accepté, il n'est pas nécessaire que l'hôte d'envoi envoie réellement des segments aussi grands. Cependant, en supposant que c'est le cas et qu'il n'y a pas d'autres goulots d'étranglement, vous obtenez un débit de 9%.
Pouvons-nous faire quelque chose du côté de l'UDP ?
L'UDP n'a pas le concept de taille maximale de segment, il n'y a donc pas de paramètre pour l'ajuster.