HTTPS en caliente frente a una VPN en caliente: compare la misma ruta de solicitud

Probablemente haya leído que HTTPS abre una conexión TCP nueva y un handshake TLS nuevo para cada solicitud de API, de modo que un túnel que permanece abierto una hora parece más barato. La primera mitad de eso suele ser falsa. Un cliente compatible reutiliza una conexión ya establecida para muchos intercambios, y una prueba que crea un cliente nuevo por llamada mide el ciclo de vida y no la protección. El resto de esta página trata de qué medir en su lugar.

Qué exige realmente la reutilización

La persistencia es parte del modelo HTTP, no un truco: una conexión transporta varios intercambios de solicitud y respuesta. La conexión termina cuando cualquiera de las dos partes la cierra, cuando el servidor retira una conexión inactiva o sobrecargada, o cuando una cabecera o una regla del protocolo indica que la conexión no puede reutilizarse. HTTPS coloca esa conversación dentro de TLS sin exigir un handshake nuevo para cada intercambio. Así, una segunda solicitud no repite el handshake de la primera salvo que algo haya terminado la conexión entretanto.

La reutilización tiene además una condición que las aplicaciones rompen con facilidad. Un cliente que piensa reutilizar una conexión debe leer el cuerpo completo de la respuesta, y una respuesta abandonada a medias es la forma habitual de que un grupo de conexiones desaparezca sin que nadie lo note.

Compruebe el cliente compatible de la biblioteca y el ciclo de vida del grupo de conexiones en lugar de suponer que la agrupación está activada o desactivada. Anote también la versión HTTP negociada, porque HTTP/2 y HTTP/3 gestionan la reutilización de conexiones de forma distinta a HTTP/1.1. Trate la versión negociada como parte de la medición, no como una nota al pie.

Por qué la comparación mide el ciclo de vida

Crear un cliente nuevo para cada operación y compararlo con un túnel conectado desde hace una hora compara la configuración de la conexión con el estado estacionario. Es una prueba legítima, y no es HTTPS frente a VPN. Dos ejecuciones con la misma configuración de cliente describen mejor el comportamiento que una, sobre todo cuando la primera ejecución calienta un resolutor o una caché de conexiones.

Mantenga constantes la operación de API, el servidor, la cuenta y los datos, o la comparación arrastrará más de una variable. Decida de antemano dónde coloca el cronómetro, porque la configuración, la negociación TLS, la ejecución de la aplicación y la entrega de la respuesta contribuyen de forma distinta al total. Un solo cronómetro de la primera solicitud caracteriza la configuración y no dice nada del tráfico estable que realmente ejecuta. Anote los límites del cronómetro junto a las cifras.

Separe la configuración en frío de las solicitudes en caliente

Mida la primera solicitud por separado de las que la siguen. Después añada lo que el servicio ve de verdad: periodos de inactividad, ráfagas, concurrencia, tamaño de la respuesta y reconexiones.

Mantenga la validación de certificados y HTTPS activadas en ambas rutas, porque quitarlas mide un diseño de seguridad distinto y no uno más rápido. Si el túnel cambia la ruta o la ubicación de la pasarela, informe de esa diferencia por separado en lugar de atribuir cada cambio de tiempo al cifrado, ya que la ruta, la pérdida y la cola pueden dominar una solicitud pequeña. Ejecute cada ruta dos veces por el mismo camino antes de sacar una conclusión. Anote el protocolo negociado y los límites del cronómetro con ambas ejecuciones.

Planifique la conexión que se cierra

Persistente no significa permanente. Un servidor, un proxy o un cambio de red pueden cerrar una conexión durante un periodo de inactividad, y el cliente tiene que recuperarse con el comportamiento que admite su biblioteca. Esa recuperación tiene una máquina de estados: la solicitud puede haberse completado en el servidor o puede haber fallado antes de que el servidor la leyera, y un socket cerrado no dice a quien llama qué ocurrió. Una operación no idempotente en esa posición no puede simplemente repetirse, porque una repetición convierte un resultado desconocido en una escritura duplicada. Aquí es donde un túnel caliente y una conexión caliente se comportan igual, ya que ambos pueden fallar en el momento en que hay trabajo en curso.

Use el mecanismo documentado de reintento o idempotencia del servicio en lugar de un bucle que reabre el socket. Pruebe la recuperación de forma explícita: cierre una conexión inactiva y observe qué hace el cliente después. Reabrir un socket no hace seguro repetir una llamada que cambia el estado.

Elija primero la frontera y luego ajuste

Elija la frontera de red a partir de los requisitos de acceso y confianza antes de optimizar nada. Una VPN protege el segmento entre sus pares, mientras que los extremos de la aplicación y cualquier segmento en texto claro fuera del túnel siguen importando. Después ajuste el ciclo de vida de la conexión dentro de esa frontera. La conclusión del túnel más barato solo se sigue de la creencia de que cada solicitud repite el handshake, y esa creencia es lo que se pone a prueba aquí.

La sección de persistencia de RFC 9112 es la referencia de lo que la reutilización promete en realidad, incluidas las condiciones que terminan una conexión. Léala una vez antes de fiarse de una prueba que las ignora.