Resumen

  • RFC 3511 medía por separado conexiones TCP concurrentes, tasa máxima de establecimiento y tasa máxima de cierre; convertir una de ellas en “capacidad” borra el ciclo de vida y sus fallos.
  • RFC 9411 sustituyó esa metodología para equipos de seguridad modernos y añadió configuración de efectividad, tráfico de aplicaciones, TLS y QUIC, fases sostenidas y criterios de validación. El resultado sigue siendo un recibo de laboratorio, no una promesa de producción.

La prueba llenó una tabla de estado. Las conexiones permanecieron casi inmóviles durante el intervalo y el contador alcanzó el objetivo. En el despliegue, las sesiones llegaban y salían con rapidez, exigían inspección y transferían objetos completos. El mismo número de “conexiones” describía cargas distintas.

RFC 3511 apareció en abril de 2003 como RFC Informational del grupo BMWG. Su estructura ya advertía la diferencia: capacidad concurrente, establecimiento y cierre eran pruebas independientes. RFC 9411 lo hizo obsoleto en marzo de 2023 porque un dispositivo moderno ejecuta más funciones y ve protocolos que aquel contrato no representaba.

La lección no es escoger la cifra menor. Es conservar qué transición contó cada cifra.

Una conexión es una secuencia, no una celda

Una sesión TCP nace con un handshake, ocupa memoria y temporizadores, transporta datos, puede retransmitir, expirar, recibir un reset y cerrarse en tres o cuatro pasos. Un firewall añade política, traducción, inspección, registro y a veces proxy.

Contar estados simultáneos responde cuántos registros coexistieron bajo una configuración. No responde cuántos podían crearse por segundo, cuánto trabajo contenían, cuántos terminaron correctamente ni cuánto tardó el dispositivo en liberar recursos.

Por eso RFC 3511 no permitió que el nombre de un KPI sustituyera a los demás. La tabla de capacidad no era el establecimiento; el establecimiento no era el teardown; ninguno era una transacción HTTP completa.

La validación conserva los fracasos

Un informe útil registra no solo las conexiones aceptadas. Conserva fallos de establecimiento, timeouts, resets, cierres incompletos y errores de validación. También identifica método de cierre y dirección.

Si el numerador contiene éxitos y el denominador desaparece, un sistema puede parecer más rápido precisamente porque abandona trabajo. Si una prueba termina antes de que los temporizadores venzan, la deuda de estado queda fuera de la ventana.

La capacidad sostenible exige observar el sistema hasta que el flujo de altas y bajas se equilibre. Un pico con la tabla aún vacía no demuestra ese equilibrio.

Reglas, NAT y autenticación cambian la sesión

RFC 3511 pedía declarar el estado de NAT y recomendaba medirlo activado y desactivado. Las reglas configuradas debían acompañar el resultado. Caché y autenticación también podían mover el trabajo hacia memoria local o un servicio externo.

Cada opción modifica el ciclo de la conexión. NAT crea asociaciones. La autenticación añade una dependencia. Una regla puede rechazar antes de inspeccionar. El caché puede evitar el servidor. El mismo handshake visible no implica el mismo camino interno.

El recibo debe contener política, distribución de matches, traducción, dependencias, estado inicial y tiempo de espera. Sin ello, “conexión” nombra solo la envoltura de transporte.

Throughput y transacciones no heredan el conteo

El throughput IP de RFC 3511 distinguía carga prevista, carga ofrecida, tasa de reenvío y tamaños de paquete. Las pruebas HTTP añadían tamaños de objeto, solicitudes por conexión, respuestas completas, retransmisiones y goodput.

Un gran número de sesiones ociosas no prueba throughput. Muchos bytes reenviados no prueban transacciones. Una respuesta parcial no prueba éxito de aplicación.

La latencia también tenía un límite semántico: debía medirse al nivel máximo sin pérdida. Fuera de ese punto, llamar latencia al valor mezclaba cola, pérdida y carga sin preservar el criterio.

El permiso rápido no es seguridad

RFC 3511 incluyó pruebas de tráfico ilegal y de efecto ante una carga de denegación de servicio, pero dejó la evaluación de seguridad fuera de alcance.

El informe de tráfico ilegal debía contar conexiones prohibidas que el dispositivo permitió. Esta variable impide premiar el camino más rápido si omite la política. La prueba DoS observaba cómo una carga definida afectaba tasas definidas; no certificaba resistencia universal.

Conexiones sostenidas, bloqueo correcto y cobertura de amenazas son recibos separados. Una sola luz verde los confunde y elimina a sus propietarios.

RFC 9411 exige primero un objeto de seguridad

La metodología moderna describe NGFW y NGIPS inline. Fija funciones recomendadas como inspección TLS, IDS/IPS, anti-malware, identificación de aplicaciones, logging e inspección profunda según el tipo de equipo.

La configuración de efectividad se valida antes del rendimiento y debe mantenerse entre pruebas. Omitir una función puede ser legítimo para un caso concreto, pero debe explicarse junto con su efecto probable.

RFC 9411 exige además un entorno aislado y una prueba de referencia sin DUT/SUT. Así se descubre si un switch, una función virtual, el hardware de tráfico o una reducción térmica limita el resultado.

TLS y QUIC introducen nuevos ciclos

Una conexión HTTPS puede incluir TCP, handshake TLS, certificado, SNI, ALPN, descifrado, inspección, cifrado y aplicación. HTTP/3 usa QUIC y combina seguridad y transporte de otro modo.

La base de RFC 9411 desactiva reanudación TLS y exige handshakes completos; su perfil QUIC desactiva 0-RTT y early data. Estas elecciones crean un caso reproducible, no una descripción de cada navegador real.

Versiones, ciphers, claves, tamaño de records, resumption, 0-RTT, objeto y mezcla de tráfico deben acompañar la tasa. Sin ellos, comparar conexiones por segundo compara nombres y no trabajo.

La fase sostenida descubre la deuda

RFC 9411 separa inicio, rampa, sostenimiento y descenso. Mide los KPI en la fase sostenida y exige que la rampa no ahogue al dispositivo antes del punto de observación.

En tráfico de aplicaciones, las transacciones fallidas y los resets TCP inesperados deben quedar bajo criterios concretos; HTTP/3 añade errores QUIC. La transacción solo cuenta como exitosa cuando transfiere todos los datos y obtiene un estado válido.

Una curva temporal revela si la tasa cae a medida que crece el estado. El promedio sin curva puede esconder justo el agotamiento que una capacidad de conexiones debía anticipar.

El cambio de RFC rompe la serie

Un resultado de RFC 3511 puede conservar valor histórico si también conserva su configuración. No se vuelve un resultado RFC 9411 por cambiar la etiqueta.

El método moderno añade efectividad, aplicaciones, cifrado, QUIC, validación y reporting distintos. Una serie que atraviesa 2023 necesita marcar la ruptura. De lo contrario atribuye al producto una diferencia creada por el contrato de medida.

La obsolescencia no borra el pasado. Impide usarlo sin procedencia.

Frontera de evidencia

Este artículo no nombra fabricante, producto, versión, laboratorio, cliente ni incidente. No ofrece cifras de rendimiento, exploits, cuota de mercado, ranking o comportamiento actual de una implementación.

RFC 3511 se trata como metodología Informational de abril de 2003, obsoleta por RFC 9411. RFC 9411 es Informational de marzo de 2023 y no es una certificación. Sus límites de validación no son una tolerancia general a fallos de seguridad.

Los principios de especificación mínima y primacía del código de Heng Lu son lentes editoriales declaradas: el estándar comparte un recibo mínimo y el operador conserva la responsabilidad de extrapolar. No son resultados de firewall.

La conclusión es limitada: una tabla de conexiones puede estar llena y, aun así, el ciclo que importa seguir sin medirse.

Sources