¿Por qué Yahoo usa un MSS de 1440 bytes?

Puede ser un truco permitir que los sitios que están ennegrecidos con MTU (es decir, detrás de un enlace MTU sub-1500, * y * un enrutador / cortafuegos estúpido que deja caer ICMP frag-need) todavía se conecten a Yahoo. Las MTU Sub-1500 no son infrecuentes, debido a las VPN y PPPoE. Los cortafuegos tontos son lamentablemente demasiado comunes, debido a vendedores y / o administradores idiotas.

Actualización: He aquí por qué …

El tamaño mínimo de un encabezado IP es de 20 bytes, y lo mismo nuevamente para el encabezado TCP. Por lo tanto, un 1460 MSS permite fácilmente que el otro lado transmita paquetes de 1500 bytes. Además, muchos, si no todos, los paquetes TCP / IP tendrán al menos algunas opciones de TCP. La opción Timestamp particularmente, que tiende a ocupar 12 bytes. PPPoE “roba” 8 bytes de la MTU 1500 PPP. Ahora tenga en cuenta que:

1440 + 12 + 8 + 20 * 2 = 1500

Es decir, un MSS 1440 es exactamente consistente con tratar de evitar el agujero negro de PPPoE MTU.

Eso no es para reclamar este * must * la razón, solo que es plausible y consistente.

FWIW, tengo un enlace PPPoE DSL, y he tenido problemas regulares con sitios remotos bloqueados debido a la estupidez de firewall a su lado. Los enrutadores DSL ahora se han enviado con hacks para destrozar el MSS en segmentos salientes y reescribirlos a valores más bajos para evitar el problema, llamado “sujeción del MSS”. Además, creo que las implementaciones más recientes de PPP / PPPoE ahora pueden permitir el 1500 MTU completo.

Ver RFC879 para una discusión sobre MSS. Tenga en cuenta que aunque es anterior a la opción de marca de tiempo.

Odio tener que decírtelo, pero eso es algo que sucede a tu lado, no en el lado de Yahoo; Yahoo no establece explícitamente su MSS cuando se comunica con los sistemas finales.

Otra razón puede ser porque hay / hubo un conflicto entre los RFC relacionados con TCP y diffserv. No he revisado recientemente. Estos pueden haber sido actualizados recientemente.

De acuerdo con los TCP RFC, si el MSS es reducido por un dispositivo de red intermedio, se envía un mensaje ICMP al host transmisor para reducir la MTU. Sin embargo, si algún dispositivo intermedio también modifica el campo TOS (que es donde se establece el punto de código diffserve), el host transmisor ignorará la trama ICMP. Esto significa que el host de transmisión continuará intentando transmitir tramas de tamaño completo y eventualmente fallará con un tiempo de espera.

La razón más común para esta condición es como resultado de una vpn donde el encabezado de cifrado reduce el MSS por (estoy trabajando en la parte superior de mi cabeza aquí) unos 40 bytes más o menos. Una transferencia de datos TCP fallará en estas condiciones si se cumplen estrictamente los RFC, suponiendo que no se hayan actualizado.

Yahoo parece estar intentando que funcione para la audiencia más amplia posible.