Primero, un poco de contexto: TCP tiene un concepto llamado tamaño máximo de segmento (MSS). Este es el segmento más grande (de datos) que la pila 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 hexadecimal 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 realizada a un host en una red local, STCP utiliza un valor de 1460. Una vez añadida toda la sobrecarga del protocolo, se obtiene una trama Ethernet de 1518 bytes, el tamaño máximo de trama Ethernet. Para las conexiones realizadas a hosts en segmentos no locales, STCP utiliza un valor derivado del parámetro min_mss. El uso del valor predeterminado de min_mss dará como resultado un valor MSS de 536. Este valor es el tamaño mínimo que todos los equipos de red basados en IP, es decir, los enrutadores, deben estar dispuestos a reenviar sin fragmentación de IP. La especificación que estableció 536 como mínimo se redactó en 1983 en RFC 879: «El tamaño máximo de segmento TCP y temas relacionados».
Hoy en día es probable que todos sus routers puedan manejar un tamaño mayor. Por lo tanto, puede aumentar el mínimo de STCP de 536 a un valor mayor. La pregunta clave es cuánto mayor. El peligro de hacerlo demasiado grande es la fragmentación. El peor escenario, pero el más fácil de diagnosticar, es que el router opte por descartar el segmento TCP en lugar de fragmentarlo. En este caso, podrá establecer una conexión, pero al transferir datos, la conexión fallará. Un rastreo en el host de envío mostrará múltiples retransmisiones de segmentos TCP grandes hasta que se agote el tiempo de espera de la conexión. El rastreo también puede mostrar mensajes ICMP de destino inalcanzable del router que está descartando el segmento. Si el router decide fragmentar el segmento, probablemente le dará al proceso de fragmentación una prioridad baja, lo que en realidad puede provocar una reducción del rendimiento. Además, la probabilidad de perder el segmento debido a daños o congestión aumenta con el número de fragmentos. La forma más fácil de saber si este es el caso es ejecutando un rastreo packet_monitor en el módulo. Si los segmentos TCP llegan como fragmentos, sabrá que se ha producido una fragmentación.
Las tres tramas Ethernet siguientes representan un segmento TCP fragmentado en tres partes. Se puede saber que la primera trama es un fragmento porque el valor Flg/Frg es 2000. El 2 indica que el bit Más fragmentos está activado y el 000 es el desplazamiento del fragmento; en este caso, el 0 indica que es el primer fragmento. El monitor de paquetes marca las dos tramas siguientes como fragmentos. El valor Flg/Frg en la trama 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. La tercera trama tiene un Flg/Frag de solo 90, o más exactamente 0090. Dado que el bit More Fragments es 0, sabemos que este es el último fragmento. Sabemos que todas estas tramas pertenecen al mismo conjunto porque todas tienen el mismo valor de ID de IP, 2e87. La longitud de los datos en la primera trama es una indicación del valor MSS que debe establecerse, 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 MSS es que lo aumenta para todas las conexiones TCP. No se puede aumentar solo para uno o varios destinos. Por lo tanto, es necesario probar cuidadosamente este cambio para evaluar su efecto en todas las conexiones.
Puede ver el valor actual de MSS y cambiarlo con los dos comandos siguientes:
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 TCP de 20 bytes. Para el ejemplo anterior, se establecería el valor min_mss en 556+20 o 576.
Entonces, ¿qué aumento se puede obtener al incrementar el valor MSS? Debido a la prevalencia de las conexiones VPN, que añaden bytes adicionales, no recomiendo establecer el valor máximo de 1480 (MSS TCP real de 1460). Sugiero un valor ligeramente inferior, por ejemplo, 1220 (MSS real 1200) bytes. Suponiendo que envía 10 megabytes de datos utilizando segmentos de 536 bytes, se necesitarán 18657 tramas, con un número total de bytes, incluida la sobrecarga (preámbulo Ethernet de 8 bytes + encabezado Ethernet de 14 bytes + encabezado IP de 20 bytes + encabezado TCP de 20 bytes + tráiler Ethernet de 4 bytes + 12 bytes efectivos para el intervalo entre tramas Ethernet) será de 11 455 246 bytes. Si utiliza segmentos de 1200 bytes, necesitará 8334 tramas con un número total de bytes de 10 650 052, es decir, un poco más del 9 % menos. Sin embargo, tenga en cuenta que el valor MSS es un anuncio del segmento más grande que se aceptará, no hay ningún requisito de que el host emisor envíe realmente segmentos tan grandes. No obstante, suponiendo que lo haga y que no haya otros cuellos de botella, acaba de obtener un aumento del 9 % en el rendimiento.
¿Podemos hacer algo por el lado del UDP?
UDP no tiene el concepto de tamaño máximo de segmento, por lo que no hay ningún parámetro para ajustarlo.