Ir al contenido principal

He notado cierta confusión entre la Unidad de Transmisión Máxima de Ethernet (MTU) y el Tamaño de Segmento Máximo de TCP (MSS), espero que lo explique lo siguiente. Si todavía (o ahora) está confundido, no dude en añadir un comentario o enviarme un e-mail pidiendo una aclaración.

En primer lugar, el STCP diferencia entre los segmentos TCP que se envían a un host en una subred local y los segmentos que se envían a un host en una subred remota, es decir, a través de un router. Los segmentos enviados a un host en una subred local tienen un MSS que está relacionado con el MTU de Ethernet; específicamente el MSS es MTU - tamaño de cabecera IP - tamaño de cabecera TCP. En las versiones anteriores a la 17.1 (más cerca de la 17.1 en un minuto) esto hace que el MSS sea igual a 1500 - 20 - 20 o 1460. Los segmentos enviados a un host en una subred remota utilizan un MSS de 536. STCP utiliza el MSS más pequeño en los segmentos remotos debido a los requisitos de la RFC 791 y la RFC 879. Analicé cómo sintonizar (aumentar) el SMS y los posibles problemas en un artículo publicado en el boletín electrónico para clientes de junio de 2004 Stratus . Puede encontrar una copia del artículo aquí. Aunque el artículo fue escrito usando ejemplos de la versión 14.7 de VOS, el contenido sigue siendo válido (a partir de la versión 17.1 de OpenVOS).

La versión 17.1 de OpenVOS ha añadido soporte para marcos Ethernet jumbo. Las tramas jumbo permiten más de 1500 bytes en la trama Ethernet, es decir, un aumento de la MTU Ethernet. El MTU por defecto sigue siendo 1500, pero se puede aumentar cuando la interfaz está configurada utilizando el argumento "-mtu" (ejemplo 1). El valor máximo del argumento MTU es 16110 dependiendo del hardware (ver tabla 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
Ejemplo 1 - configuración de MTU cuando se configura una interfaz

 

Tipo de adaptador MTU
Adaptadores integrados en V100, V200, V400 1500
Adaptadores incorporados en V150, V250, V300, V500
Adaptadores incorporados en V2302, V2404, V4304, V4408, V6308, V6408
9200
Adaptador de cobre de un solo puerto U571V 10/100/1000 mbps 1500
U574V-LC Adaptador de fibra de 1000 mbps de doble puerto
Adaptador de cobre U575V de doble puerto 10/100/1000 mbps
U578V Adaptador de cobre de cuatro puertos 10/100/1000 mbps
U582V Adaptador de cobre de cuatro puertos 10/100/1000 mbps
U583V Adaptador de fibra de cuatro puertos de 1000 mbps
9200
Adaptador de fibra de 10.000 mbps de doble puerto U584V 16110
U776V Adaptador de fibra de 1000 mbps de cuatro puertos 9200
Tabla 1 - Valores de MTU por tipo de hardware

 

Después de configurar una MTU más grande se puede ver que STCP anunciará una MSS más grande para las conexiones locales, 0x23c8 es 9160 decimal.


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

 

Pero las conexiones remotas siguen teniendo el MSS más pequeño, 0x218 es 536 decimal.


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

 

No se puede aumentar el mínimo MSS para conexiones remotas más allá de 1460 (1480 con el encabezado TCP)

as: set_stcp_param min_mss 9160
set_stcp_param: El argumento no está dentro del rango permitido. El error en
     'param_valor'. [500-1480] permitido
como:

 

A menos que ambos lados de una conexión anuncien un MSS más grande, no hay un efecto real. Por ejemplo, aunque el servidor FTP esté configurado con un MTU de 9200 y esté anunciando un MSS de 9160, ya que el cliente está anunciando un MSS de 1460 (0x5b4), que es el número máximo de bytes que el servidor enviará en un segmento.


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...
. . . .

 

Incluso cuando ambas partes anuncian el MSS más grande no hay garantía de que cada cuadro contenga la máxima cantidad de datos. Por ejemplo, tanto el cliente como el servidor están anunciando un MSS de 9160 pero los segmentos son sólo de 8204 bytes porque es el máximo que la aplicación está diseñada para enviar.


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.