%20FreeBSD%20'net.inet.tcp.always_keepalive'%20viola%20RFC1122%3F.png)
Mientras trabajaba en una aplicación de servidor que se ejecuta en FreeBSD y usa TCP, noté que se envían sondas de mantenimiento de conexión de TCP a pesar de que mi aplicación deshabilita explícitamente SO_KEEPALIVE en los sockets TCP.
De acuerdo aRFC1122 Sección 4.2.3.6(TCP mantiene vivo):
"Si se incluyen keep-alive, la aplicación DEBE poder activarlos o desactivarlos para cada conexión TCP, y DEBEN estar desactivados de forma predeterminada".
Descubrí que el parámetro sintonizablenet.inet.tcp.always_keepalivese había habilitado (establecido en 1), y que deshabilitarlo detendría el envío de sondas keepalive.
¿Cuál es el razonamiento detrás de la inclusión de este comportamiento en FreeBSD? Por lo que puedo decir, Linux y Windows no tienen esa opción, pero FreeBSD y Mac OS X sí, por lo que violan el RFC.
Para ser más específicos, ¿bajo qué circunstancias tendría sentido ignorar los deseos de la solicitud?
En mi caso, esta es una solución sencilla, ya que puedo desactivar la opción, pero me gustaría entender por qué está ahí.
Esta preguntamuestra que Linux se comporta según el RFC.
Respuesta1
Aquí se proporciona la justificación para activar keep-alive de forma predeterminada:https://svnweb.freebsd.org/base?view=revision&revision=47752
Agregue un identificador para controlar los keepalives de TCP globales y actívelos de forma predeterminada.
A pesar de su nombre, no mantiene vivas las sesiones TCP, las mata si el otro extremo se ha ido sin permiso. Esto sucede mucho con clientes que usan NAT, asignación dinámica de IP o que tienen un límite superior de tiempo de actividad de 2^32 * 10^-3 segundos.
No hay un aumento detectable en el tráfico de la red debido a esto: dos paquetes TCP mínimos cada dos horas para una conexión TCP activa.
Muchos servidores ya habilitan keepalives.
El RFC sobre requisitos de host tiene 10 años y no sabe nada de la pérdida de clientes de Internet actual.
De todos modos, es mejor desactivar Keep-Alive si lo solicita la aplicación, por ejemplo (en C):
int val = 0;
setsockopt(s, SOL_SOCKET, SO_KEEPALIVE, &val, sizeof(val));
pero no es fácil arreglar esto.
Respuesta2
Creo que la perilla sintonizable debería existir, pero quizás sea mejor mantenerla apagada de forma predeterminada.
Mi razonamiento es el siguiente: un desarrollador de aplicaciones puede tomar este tipo de decisiones equivocadas y, en última instancia, un administrador de sistemas debería tener control sobre este tipo de política de red, no el desarrollador de aplicaciones.