Ir al contenido principal
Primero un poco de fondo, el TCP tiene un concepto llamado tamaño máximo de segmento (MSS). Este es el mayor segmento (de datos) que la pila del TCP aceptará. Se anuncia al par remoto en el segmento SYN cuando se establece la conexión. La siguiente decodificación de paquetes muestra el segmento SYN con la opción TCP MSS resaltada. Todas las opciones TCP tienen el mismo formato, 1 byte para el número de opción, 2 en este caso, 1 byte para la longitud total de la opción (4) y el valor de la opción, en este caso 5b4 hex o 1460 decimal.

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
Para una conexión hecha a un host en una red local, STCP utiliza un valor de 1460. Una vez que añades toda la sobrecarga del protocolo, terminas con una trama Ethernet de 1518 bytes - el tamaño máximo de trama Ethernet. Para conexiones hechas a hosts en segmentos no locales, STCP usa un valor derivado del parámetro min_mss. Usando el valor por defecto min_mss resultará en un valor MSS de 536. Este valor es el tamaño mínimo que todo el equipo de red basado en IP, es decir, los routers deben estar dispuestos a reenviar sin fragmentación de IP, la especificación que establece 536 como mínimo fue escrita en 1983 en el RFC 879 - "The TCP Maximum Segment Size and related Topics".

 

Hoy en día es probable que todos sus routers puedan manejar un tamaño mayor. Por lo tanto, puedes aumentar el mínimo de STCP de 536 a algo más grande. Cuánto más grande es la pregunta clave. El peligro de hacerlo demasiado grande es la fragmentación. El peor escenario, pero el más fácil de diagnosticar, es que el enrutador elija descartar el segmento TCP en lugar de fragmentarlo. En este caso podrá establecer una conexión, pero al transferir los datos la conexión fallará. Un rastro en el host de envío mostrará múltiples retransmisiones de grandes segmentos TCP hasta que la conexión se agote. El rastreo también puede mostrar mensajes de destino ICMP inalcanzables desde el enrutador que está descartando el segmento. Si el enrutador elige fragmentar el segmento, probablemente le dará al proceso de fragmentación una prioridad baja, lo que en realidad puede resultar en una reducción del rendimiento. También la probabilidad de perder el segmento debido a la corrupción o a la congestión aumenta con el número de fragmentos. La forma más fácil de saber si esto es así es ejecutando un trazado packet_monitor en el módulo. Si los segmentos de TCP llegan como fragmentos, se sabe que se ha producido una fragmentación.

 

Las siguientes tres tramas de Ethernet representan un segmento TCP fragmentado en tres partes. Se puede decir que la primera trama es un fragmento porque el valor de Flg/Frg es 2000. El 2 indica que el bit Más fragmentos está establecido y el 000 es el desplazamiento del fragmento, en este caso el 0 indica que es el primer fragmento. El monitor de paquetes en realidad marca los siguientes 2 cuadros como fragmentos. El valor de Flg/Frg en el cuadro 2 es 2048, de nuevo el 2 indica que el bit More Fragments está activado y el 48 es el desplazamiento (en múltiplos de 8 bytes) de los datos en el datagrama IP original. El tercer cuadro tiene un valor de Flg/Frag de sólo 90, o más exactamente 0090. Como el bit de Más fragmentos es 0 sabemos que este es el último fragmento. Sabemos que todos estos cuadros pertenecen juntos porque todos tienen el mismo valor de identificación IP, 2e87. La longitud de los datos en el primer cuadro es una indicación del valor MSS que debe ser fijado, en este caso 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

 

El problema de aumentar el valor del MSS es que lo aumenta para todas las conexiones TCP. No se puede aumentarlo para uno o unos pocos destinos. Por lo tanto, necesitas probar cuidadosamente este cambio para medir su efecto en todas tus conexiones.
Puedes ver el valor actual de MSS y cambiarlo con los siguientes dos comandos:
analyze_system -request_line 'list_stcp_params min_mss' -quit
OpenVOS Release 17.0.1as, analyze_system Release 17.0.1as
Current process is 357, ptep 8FA86000, Noah_Davids.SysAdmin

maximum tcp segment size [500-1480] (min_mss) 556

ready 10:52:07
analyze_system -request_line 'set_stcp_param min_mss 1480' -quit 
OpenVOS Release 17.0.1as, analyze_system Release 17.0.1as
Current process is 357, ptep 8FA86000, Noah_Davids.SysAdmin

Changing maximum tcp segment size (min_mss)
from 556 to 1480
ready 10:52:24
El nombre del parámetro, min_mss, implica que es el valor MSS pero en realidad es el valor MSS más la longitud del encabezado del TCP de 20 bytes. Para el ejemplo anterior, se establecería el valor min_mss a 556+20 o 576.

 

Entonces, ¿cuánto puedes conseguir aumentando el valor del MSS? Debido a la prevalencia de las conexiones VPN que añaden bytes de carga, no recomiendo establecer el valor máximo de 1480 (TCP MSS real de 1460). Sugiero algo un poco más pequeño, digamos 1220 (MSS real de 1200) bytes. Asumiendo que está enviando 10 megabytes de datos usando 536 segmentos de bytes requerirá 18657 tramas, el número total de bytes - incluyendo la sobrecarga (8 bytes de preámbulo Ethernet + 14 bytes de encabezamiento Ethernet + 20 bytes de encabezamiento IP + 20 bytes de encabezamiento TCP + 4 bytes de remolque Ethernet + 12 bytes efectivos para la brecha entre tramas Ethernet) será de 11.455.246 bytes. Si se utilizan segmentos de 1200 bytes, se necesitarán 8334 tramas con un número total de bytes de 10.650.052 o un poco más del 9% más pequeño. Sin embargo, tenga en cuenta que el valor de MSS es un anuncio del segmento más grande que será aceptado, no hay ningún requisito de que el host de envío envíe realmente segmentos tan grandes. Sin embargo, asumiendo que lo hace y que no hay otros cuellos de botella, sólo tienes un 9% de arranque en el rendimiento.

2 Comentarios