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' -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
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.
¿Podemos hacer algo en el lado de la UDP?
El UDP no tiene el concepto de tamaño máximo del segmento, por lo que no hay ningún parámetro para ajustarlo.