Pour commencer, un peu de contexte : le protocole TCP utilise un concept appelé « taille maximale de segment » (MSS). Il s'agit du plus gros segment (de données) que la pile TCP est susceptible d'accepter. Cette valeur est communiquée au pair distant dans le segment SYN lors de l'établissement de la connexion. Le décodage de paquet ci-dessous montre le segment SYN avec l'option TCP MSS mise en évidence. 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 en hexadécimal ou 1460 en 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 protocole STCP utilise une valeur de 1 460. Une fois pris en compte l'ensemble de la surcharge liée au protocole, on obtient une trame Ethernet de 1 518 octets, soit la taille maximale d'une trame Ethernet. Pour les connexions établies avec des hôtes situés sur des segments non locaux, le protocole STCP utilise une valeur dérivée du paramètre min_mss. L'utilisation de la valeur par défaut de min_mss donne une valeur MSS de 536. Cette valeur correspond à la taille minimale que tous les équipements réseau IP, c'est-à-dire les routeurs, doivent être capables de transférer sans fragmentation IP. La spécification qui a établi 536 comme valeur minimale a été rédigée en 1983 dans la RFC 879 – « The TCP Maximum Segment Size and related Topics ».
Aujourd'hui, il est probable que tous vos routeurs puissent gérer des segments de plus grande taille. Vous pouvez donc augmenter la valeur minimale STCP de 536 à une valeur supérieure. La question clé est de savoir de combien l'augmenter. Le risque lié à une valeur trop élevée est la fragmentation. Le pire scénario, mais aussi le plus facile à diagnostiquer, est que le routeur choisisse de rejeter le segment TCP plutôt que de le fragmenter. Dans ce cas, vous pourrez établir une connexion, mais celle-ci échouera lors du transfert de données. Une trace sur l'hôte émetteur montrera de multiples retransmissions de segments TCP volumineux jusqu'à ce que la connexion expire. La trace peut également afficher des messages ICMP « destination inaccessible » provenant du routeur qui rejette le segment. Si le routeur choisit de fragmenter le segment, il attribuera probablement une faible priorité au processus de fragmentation, ce qui peut en réalité entraîner une réduction du débit. De plus, la probabilité de perdre le segment en raison d'une corruption ou d'une congestion augmente avec le nombre de fragments. Le moyen le plus simple de déterminer si c'est le cas consiste à exécuter une trace packet_monitor sur le module. Si les segments TCP arrivent sous forme de fragments, vous savez qu'une fragmentation s'est produite.
Les trois trames Ethernet suivantes représentent un segment TCP fragmenté en trois parties. On peut voir que la première trame est un fragment car la valeur Flg/Frg est 2000. Le 2 indique que le bit « More Fragments » est activé et le 000 correspond au décalage du fragment ; dans ce cas, le 0 indique qu’il s’agit du premier fragment. Le moniteur de paquets signale effectivement les deux trames suivantes comme étant des fragments. La valeur Flg/Frg de la trame 2 est 2048 ; là encore, le 2 indique que le bit « More Fragments » est activé et le 48 correspond au décalage (en multiples de 8 octets) des données dans le datagramme IP d'origine. La troisième trame a une valeur Flg/Frg 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 vont ensemble car elles ont toutes la même valeur d'ID IP, 2e87. La longueur des données dans la première trame indique 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 lié à l'augmentation de la valeur MSS est qu'elle s'applique à toutes les connexions TCP. Il n'est pas possible de l'augmenter pour une seule destination ou pour quelques-unes seulement. Vous devez donc tester cette modification avec soin afin d'évaluer son impact sur l'ensemble de vos connexions.
Vous pouvez consulter la valeur actuelle de MSS 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, laisse entendre qu'il s'agit de la valeur MSS, mais il s'agit en réalité de la valeur MSS augmentée de la longueur de l'en-tête TCP, soit 20 octets. Dans l'exemple ci-dessus, vous devriez donc définir la valeur de min_mss sur 556 + 20, soit 576.
Quel gain de débit peut-on obtenir en augmentant la valeur MSS ? En raison de la prévalence des connexions VPN, qui ajoutent des octets de surcharge, je ne recommande pas de régler la valeur maximale à 1480 (MSS TCP réel de 1460). Je suggère une valeur légèrement inférieure, par exemple 1220 octets (MSS réel de 1200). En supposant que vous envoyiez 10 mégaoctets de données en utilisant des segments de 536 octets, cela nécessitera 18 657 trames, soit un nombre total d'octets – surcoût compris (préambule Ethernet de 8 octets + en-tête Ethernet de 14 octets + en-tête IP de 20 octets + en-tête TCP de 20 octets + trailer Ethernet de 4 octets + 12 octets effectifs pour l'intervalle entre trames Ethernet) sera de 11 455 246 octets. Si vous utilisez des segments de 1 200 octets, cela nécessitera 8 334 trames, pour 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 correspond à la taille maximale du segment qui sera acceptée ; il n’est pas obligatoire que l’hôte émetteur envoie effectivement des segments de cette taille. Toutefois, en supposant qu'il le fasse et qu'il n'y ait pas d'autres goulots d'étranglement, vous venez de gagner 9 % de débit.
Peut-on faire quelque chose du côté UDP ?
Le protocole UDP ne prévoit pas de taille maximale de segment ; il n'existe donc aucun paramètre permettant de la régler.