Resumen
- La opción MSS pertenece al receptor que la anuncia en un segmento con SYN y limita los datos que recibirá desde el otro extremo; los dos sentidos son independientes.
- El emisor calcula después una MSS efectiva con el menor límite entre la capacidad remota y lo que IP permite, y reduce los datos por las opciones presentes en cada paquete concreto.
- MSS no es MTU de ruta, ventana de recepción, tamaño de mensaje ni promesa de que los segmentos posteriores tendrán esa longitud.
La cifra del cliente gobernaba al servidor
En RFC 793, Maximum Segment Size era la opción de tipo 2 y longitud 4. Sus 16 bits comunicaban el máximo segmento de recepción del TCP que enviaba el SYN. La ubicación en el inicio de la conexión hizo que muchos operadores la leyeran como una negociación.
RFC 879 advirtió en 1983 que se trataba de un anuncio, “a menudo llamado erróneamente negociación”. El cliente no propone 1460 para que el servidor lo acepte como valor global. Declara que puede recibir hasta 1460 octetos de datos TCP. El servidor puede declarar 1200 sobre su propia recepción. Ambos valores son ciertos porque contestan preguntas opuestas.
La asimetría no es una excepción. Dos extremos pueden tener interfaces, buffers, políticas y caminos distintos. Una herramienta que guarda solo “MSS negociada” pierde quién habló y qué flujo quedó limitado. Esa pérdida de procedencia puede convertir una observación correcta en una regla aplicada al revés.
El origen del 536
El punto de partida de IPv4 era un datagrama de 576 octetos que los hosts debían poder recibir y reensamblar. Al restar 20 octetos del encabezado IPv4 fijo y 20 del encabezado TCP fijo quedaban 536 para datos TCP. RFC 879 aclaró que MSS cuenta datos, no encabezados.
SYN y FIN consumen cada uno una posición de secuencia, pero no se cuentan como datos MSS. El espacio de secuencia y el tamaño de carga no son la misma contabilidad.
RFC 1122 exigió implementar el envío y la recepción de MSS. Si no llegaba la opción durante el establecimiento, el emisor debía suponer 536. RFC 9293, la especificación TCP vigente, conserva 536 para IPv4 y añade 1220 para IPv6: 1280 menos 40 de IPv6 y 20 de TCP.
La ausencia de opción no autoriza tamaños ilimitados. Activa un valor conservador. Tampoco demuestra que 536 o 1220 sean óptimos para la ruta moderna: son reglas para suplir una declaración ausente, no mediciones.
El anuncio remoto era solo una de las restricciones
RFC 1122 introdujo la distinción entre SendMSS, recibida del otro extremo, y la MSS efectiva de envío. El segmento que realmente puede producir TCP queda limitado por la menor de dos superficies: la capacidad de recepción remota y el máximo que permite IP en el contexto de salida. Después cuentan los encabezados del paquete presente.
Un receptor puede aceptar una carga grande y, sin embargo, el camino no transportarla entera. Un camino ancho tampoco permite superar el límite del receptor. Confundir ambos números entrega a un extremo conocimiento que no posee sobre redes intermedias.
La historia de Path MTU Discovery ya publicada estudia cómo errores ICMP y pruebas de entrega ayudan al emisor a revisar una estimación del camino. Esta historia estudia la entrada distinta que viene del receptor. Se combinan en el cálculo, pero una no certifica a la otra.
El emisor puede usar menos que el máximo por falta de datos, ventanas, congestión, opciones, retransmisión o planificación. Por ello, observar cargas pequeñas no prueba por sí solo una reescritura MSS ni fija la capacidad de la ruta.
Una cifra fija no podía predecir encabezados variables
La longitud de IP y TCP puede variar. Durante años persistió la duda de si el receptor debía descontar en el SYN todas las opciones que tal vez aparecieran después. RFC 6691 asignó la cuenta al actor que conocía el paquete.
El MSS anunciado se calcula restando solo los encabezados fijos de IP y TCP al MTU efectivo. No se descuentan opciones hipotéticas. Cuando el emisor construye un paquete con opciones reales, reduce sus datos exactamente por esa sobrecarga.
El receptor no conoce en el apretón qué combinación futura usará el emisor. Un MSS fijo tampoco puede representar todas las combinaciones variables. Si el receptor reserva espacio y el emisor vuelve a descontarlo, los segmentos quedan demasiado cortos. Si nadie lo hace, quedan demasiado largos y pueden fragmentarse o descartarse.
RFC 6691 también corrigió la premisa de un ejemplo antiguo de RFC 879 que restaba una opción IP Security del MSS ofrecido. Una errata verificada ajustó el relleno aritmético de aquel ejemplo, pero la regla posterior mostró que la resta pertenecía al envío del paquete, no al anuncio. RFC 9293 consolida esa solución.
La errata 6381 de RFC 1122 propuso eliminar una aparente doble resta de opciones IP. Fue rechazada: las notas del verificador separan el espacio reservado por IP de las opciones entregadas por TCP. Un registro de investigación debe conservar el estado de la errata, no citar toda propuesta como corrección aceptada.
Un valor demasiado pequeño también decide
RFC 6691 advirtió que anunciar una MSS pequeña puede impedir que PMTUD aproveche una ruta mayor. El servicio quizá siga funcionando, pero con más paquetes, más encabezados y una pérdida de capacidad difícil de distinguir de una limitación real.
En interfaces cuyo MTU efectivo cambia, el extremo tampoco debe anunciar solo el mejor caso. Una compresión puede necesitar encabezados completos para resincronizarse, y una retransmisión podría superar entonces el sobre disponible. La recomendación es basar el anuncio en el menor MTU efectivo.
Para jumbogramas IPv6, 65535 se interpreta como infinito y PMTUD determina el máximo real. Es un escape para el límite de 16 bits, no una afirmación de capacidad infinita.
IANA conserva el nombre, no la ruta
El registro de parámetros TCP de IANA mantiene el tipo 2, longitud 4, como Maximum Segment Size y remite a RFC 9293. Eso prueba continuidad de la gramática común. No prueba uso, cumplimiento, valores actuales ni paso efectivo por una ruta.
RFC 9293 sustituyó RFC 793, RFC 879 y RFC 6691 y reemplazó los requisitos TCP de RFC 1122. La consolidación mantuvo la división esencial: el receptor anuncia una capacidad propia; el emisor la combina con IP; el emisor descuenta la sobrecarga variable que solo él conoce.
MSS es una cota con dirección y autor. Dos valores, dos cálculos efectivos y los paquetes observados forman la evidencia. Una sola casilla llamada “negociado” no.
Fuentes y límites
- RFC 793 — Transmission Control Protocol
- RFC 879 — The TCP Maximum Segment Size and Related Topics
- RFC 1122 — Requirements for Internet Hosts — Communication Layers
- RFC 6691 — TCP Options and Maximum Segment Size
- RFC 9293 — Transmission Control Protocol (TCP)
- IANA — Transmission Control Protocol (TCP) Parameters
Estas fuentes establecen especificación, correcciones y registro. No miden despliegue actual, valores por sistema, frecuencia de reescritura, MTU de una ruta ni causa de un incidente.
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
