J'ai remarqué une certaine confusion entre l'unité de transmission maximale Ethernet (MTU) et la taille maximale de segment TCP (MSS). J'espère que les explications suivantes permettront d'y voir plus clair. Si vous avez encore (ou maintenant) des doutes, n'hésitez pas à ajouter un commentaire ou à m'envoyer un e-mail pour demander des précisions.
Tout d'abord, le STCP fait la distinction entre les segments TCP envoyés à un hôte sur un sous-réseau local et les segments envoyés à un hôte sur un sous-réseau distant, c'est-à-dire via un routeur. Les segments envoyés à un hôte sur un sous-réseau local ont un MSS lié au MTU Ethernet ; plus précisément, le MSS est égal au MTU moins la taille de l'en-tête IP et la taille de l'en-tête TCP. Dans les versions antérieures à la version 17.1 (plus d'informations sur la version 17.1 dans un instant), cela rend le MSS égal à 1500 – 20 – 20, soit 1460. Les segments envoyés à un hôte sur un sous-réseau distant utilisent un MSS de 536. STCP utilise le MSS le plus petit sur les segments distants en raison des exigences des RFC 791 et RFC 879. J'ai abordé la manière d'ajuster (augmenter) le MSS et les problèmes potentiels dans un article publié dans la newsletter électronique Stratus eNewsletter de juin 2004. Vous pouvez trouver une copie de cet article ici. Bien que l'article ait été rédigé à partir d'exemples tirés de la version 14.7 de VOS, son contenu reste valable (à la date de la version 17.1 d'OpenVOS).
La version 17.1 d'OpenVOS prend désormais en charge les trames Ethernet jumbo. Les trames jumbo permettent d'avoir plus de 1 500 octets dans la trame Ethernet, c'est-à-dire une augmentation de la MTU Ethernet. La MTU par défaut reste 1 500, mais vous pouvez l'augmenter lors de la configuration de l'interface à l'aide de l'argument « –mtu » (exemple 1). La valeur maximale de l'argument MTU est 16 110, en fonction de votre matériel (voir tableau 1).
ifconfig #sdlmux.m16.11-2 172.16.1.116 -netmask 255.255.255.0 -mtu 9200 -add
Adding interface %phx_vos#sdlmux.m16.11-2 with IP address 172.16.1.116
%phx_vos#sdlmux.m16.11-2: <UP, BROADCAST, RUNNING, NOFORWARDBROADCAST, KEEPALIVE
+, MTU:9200>
172.16.1.116 netmask 0xffffff00 broadcast 172.16.1.255
|
| Exemple 1 – Définition du MTU lors de la configuration d'une interface |
| Type d'adaptateur | MTU |
| Adaptateurs intégrés dans les modèles V100, V200, V400 | 1500 |
| Adaptateurs intégrés dans les modèles V150, V250, V300, V500 Adaptateurs intégrés dans les modèles V2302, V2404, V4304, V4408, V6308, V6408 |
9200 |
| Adaptateur cuivre U571V à port unique 10/100/1000 Mbps | 1500 |
| Adaptateur fibre optique double port 1000 Mbps U574V-LC Adaptateur cuivre double port 10/100/1000 Mbps U575V Adaptateur cuivre quadri-port 10/100/1000 Mbps U578V Adaptateur cuivre quadri-port 10/100/1000 Mbps U582V Adaptateur fibre quadri-port 1000 Mbps U583V |
9200 |
| Adaptateur fibre optique double port 10 000 Mbps U584V | 16110 |
| Adaptateur fibre optique quadri-port 1000 Mbps U776V | 9200 |
| Tableau 1 – Valeurs MTU par type de matériel |
Après avoir défini une MTU plus grande, vous pouvez voir que STCP annonce une MSS plus grande pour les connexions locales, 0x23c8 correspond à 9160 en décimal.
9:04:55.912 Xmit Ether Dst 00:16:97:c4:01:aa Src 00:00:a8:41:52:22 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 3c, ID 0, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 23fc, Src ac100174, Dst ac10012c
TCP from 172.16.1.116.59410 to 172.16.1.44.9182
seq 3764213089, ack n.a., window 8192, 20 data bytes, flags Syn.
X/Off 0a, Flags 02, Cksum d329, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 23 c8 3 3 6 4 2 8 a 18 bf 3f d6 0 <<#H<<<< <<<<??V
10 0 0 0 0
|
Mais les connexions à distance obtiennent toujours le MSS le plus petit, 0x218 correspond à 536 en décimal.
9:20:34.051 Xmit Ether Dst 00:16:97:c4:01:aa Src 00:00:a8:41:52:22 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 3c, ID 0, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 1086, Src ac100174, Dst c0a8000a
TCP from 172.16.1.116.49186 to 192.168.0.10.9182
seq 1916893234, ack n.a., window 8192, 20 data bytes, flags Syn.
X/Off 0a, Flags 02, Cksum de8e, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 2 18 3 3 6 4 2 8 a 0 1 69 a 0 <<<<<<<< <<< <i<
10 0 0 0 0
|
Vous ne pouvez pas augmenter le MSS minimum pour les connexions à distance au-delà de 1460 (1480 avec l'en-tête TCP).
comme : set_stcp_param min_mss 9160
set_stcp_param : l'argument n'est pas compris dans la plage autorisée. Erreur dans
« param_value ». [500-1480] autorisé
comme :
|
À moins que les deux côtés d'une connexion n'annoncent un MSS plus important, il n'y a pas d'effet réel. Par exemple, même si le serveur FTP est configuré avec un MTU de 9200 et annonce un MSS de 9160, comme le client annonce un MSS de 1460 (0x5b4), c'est le nombre maximal d'octets que le serveur enverra dans un segment.
11:02:49.758 Xmit Ether Dst 00:00:a8:42:3b:6e Src 00:00:a8:41:52:22 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 3c, ID 5, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 2401, Src ac100174, Dst ac100122
TCP from 172.16.1.116.ftp-data to 172.16.1.34.49343
seq 2092638702, ack n.a., window 8192, 20 data bytes, flags Syn.
X/Off 0a, Flags 02, Cksum 7c62, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 23 c8 3 3 6 4 2 8 a 0 19 5c b5 0 <<#H<<<< <<< <5
10 0 0 0 0
11:02:49.758 Rcvd Ether Dst 00:00:a8:41:52:22 Src 00:00:a8:42:3b:6e Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 3c, ID 1bcb, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 083b, Src ac100122, Dst ac100174
TCP from 172.16.1.34.49343 to 172.16.1.116.ftp-data
seq 3565222463, ack 2092638703, window 8192, 20 data bytes, flags Syn Ack.
X/Off 0a, Flags 12, Cksum fef7, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 5 b4 3 3 6 4 2 8 a 13 cc 99 0 0 <<<4<<<< <<<<L>
10 19 5c b5 0 <5
. . . .
11:02:50.620 Xmit Ether Dst 00:00:a8:42:3b:6e Src 00:00:a8:41:52:22 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 5dc, ID 8, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 1e5e, Src ac100174, Dst ac100122
TCP from 172.16.1.116.ftp-data to 172.16.1.34.49343
seq 2092638703, ack 3565222464, window 128, 1460 data bytes, flags Push A
+ck.
X/Off 08, Flags 18, Cksum 7467, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
. . . .
|
Même lorsque les deux parties annoncent un MSS plus important, rien ne garantit que chaque trame contiendra la quantité maximale de données. Par exemple, le client et le serveur annoncent tous deux un MSS de 9160, mais les segments ne font que 8204 octets, car c'est la quantité maximale que l'application est conçue pour envoyer.
11:33:40.492 Xmit Ether Dst 00:00:a8:43:ba:64 Src 00:00:a8:41:52:22 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 3c, ID 34, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 231b, Src ac100174, Dst ac1001d9
TCP from 172.16.1.116.ftp-data to 172.16.1.217.49430
seq 851197707, ack n.a., window 8192, 20 data bytes, flags Syn.
X/Off 0a, Flags 02, Cksum d8f7, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 23 c8 3 3 6 4 2 8 a 0 20 9b 7d 0 <<#H<<<< <<< >}
10 0 0 0 0
11:33:40.493 Rcvd Ether Dst 00:00:a8:41:52:22 Src 00:00:a8:43:ba:64 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 3c, ID 33, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 231c, Src ac1001d9, Dst ac100174
TCP from 172.16.1.217.49430 to 172.16.1.116.ftp-data
seq 3989207776, ack 851197708, window 8192, 20 data bytes, flags Syn Ack.
X/Off 0a, Flags 12, Cksum d75d, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 23 c8 3 3 6 4 2 8 a 0 e e1 8a 0 <<#H<<<< <<< <a>
10 20 9b 7d 0 >}
. . . .
11:33:40.504 Xmit Ether Dst 00:00:a8:43:ba:64 Src 00:00:a8:41:52:22 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 2034, ID 37, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 0320, Src ac100174, Dst ac1001d9
TCP from 172.16.1.116.ftp-data to 172.16.1.217.49430
seq 851197708, ack 3989207777, window 128, 8204 data bytes, flags Ack.
X/Off 08, Flags 10, Cksum ee81, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
. . . .
|
Finally just setting a large MTU on your hosts is not enough; you also have to make sure that all network devices between the two hosts are configured to allow the larger frame size. If not then what you will find is that everything will work correctly when the host uses small (<= 1460) segments, but if it transmits a larger segment, that segment will be dropped by the network device and the connection will eventually fail with a timeout condition of some kind. Larger segments may be sent because the application sends it or because STCP combines smaller segments. This can make for random and very frustrating failures.