HTTPS en quente fronte a unha VPN en quente: compare a mesma ruta de solicitude

Probablemente leu que HTTPS abre unha conexión TCP nova e un handshake TLS novo para cada solicitude de API, de xeito que un túnel que permanece aberto unha hora parece máis barato. A primeira metade diso adoita ser falsa. Un cliente compatible reutiliza unha conexión xa establecida para moitos intercambios, e unha proba que crea un cliente novo por chamada mide o ciclo de vida e non a protección. O resto desta páxina trata de que medir no seu lugar.

Que esixe realmente a reutilización

A persistencia forma parte do modelo HTTP, non é un truco: unha conexión transporta varios intercambios de solicitude e resposta. A conexión remata cando calquera das dúas partes a pecha, cando o servidor retira unha conexión inactiva ou sobrecargada, ou cando unha cabeceira ou unha regra do protocolo indica que a conexión non se pode reutilizar. HTTPS coloca esa conversa dentro de TLS sen esixir un novo handshake para cada intercambio. Así, unha segunda solicitude non repite o handshake da primeira salvo que algo rematase a conexión entretanto.

A reutilización ten ademais unha condición que as aplicacións rompen con facilidade. Un cliente que pensa reutilizar unha conexión debe ler o corpo completo da resposta, e unha resposta abandonada a medias é o xeito habitual de que un grupo de conexións desapareza sen que ninguén o note.

Comprobe o cliente compatible e o ciclo de vida do grupo de conexións da biblioteca en lugar de supoñer que a agrupación está activada ou desactivada. Anote tamén a versión HTTP negociada, porque HTTP/2 e HTTP/3 xestionan a reutilización de conexións de forma distinta a HTTP/1.1. Trate a versión negociada como parte da medición, non como unha nota ao pé.

Por que a comparación mide o ciclo de vida

Crear un cliente novo para cada operación e comparalo cun túnel conectado desde hai unha hora compara a configuración da conexión cun estado estacionario. Iso é unha proba lexítima, e non é HTTPS fronte a VPN. Dúas execucións coa mesma configuración de cliente describen mellor o comportamento que unha, sobre todo cando a primeira execución quenta un resolutor ou unha caché de conexións.

Manteña constantes a operación de API, o servidor, a conta e os datos, ou a comparación leva máis dunha variable. Decida de antemán onde coloca o cronómetro, porque a configuración, a negociación TLS, a execución da aplicación e a entrega da resposta contribúen de forma distinta ao total. Un só cronómetro da primeira solicitude caracteriza a configuración e non di nada sobre o tráfico estable que realmente executa. Anote os límites do cronómetro xunto ás cifras.

Separe a configuración en frío das solicitudes en quente

Mida a primeira solicitude por separado das que a seguen. Despois engada o que o servizo ve de verdade: períodos de inactividade, ráfagas, concorrencia, tamaño da resposta e reconexións.

Manteña a validación de certificados e HTTPS activadas nas dúas rutas, porque quitalas mide un deseño de seguridade distinto e non un máis rápido. Se o túnel cambia a ruta ou a localización da pasarela, informe desa diferenza por separado en lugar de atribuír cada cambio de tempo á cifraxe, xa que a ruta, a perda e a cola poden dominar unha solicitude pequena. Execute cada ruta dúas veces polo mesmo camiño antes de sacar unha conclusión. Anote o protocolo negociado e os límites do cronómetro con ambas as execucións.

Planifique a conexión que se pecha

Persistente non significa permanente. Un servidor, un proxy ou un cambio de rede poden pechar unha conexión durante un período de inactividade, e o cliente ten que recuperarse co comportamento que admite a súa biblioteca. Esa recuperación ten unha máquina de estados: a solicitude pode terse completado no servidor ou pode ter fallado antes de que o servidor a lese, e un socket pechado non lle di a quen chama que ocorreu. Unha operación non idempotente nesa posición non se pode simplemente repetir, porque unha repetición converte un resultado descoñecido nunha escritura duplicada. Aquí é onde un túnel quente e unha conexión quente se comportan igual, xa que ambos poden fallar no momento en que hai traballo en curso.

Use o mecanismo documentado de reintento ou idempotencia do servizo en lugar dun bucle que reabre o socket. Probe a recuperación de forma explícita: peche unha conexión inactiva e observe que fai o cliente despois. Reabrir un socket non fai seguro repetir unha chamada que cambia o estado.

Escolla primeiro a fronteira e logo axuste

Escolla a fronteira de rede a partir dos requisitos de acceso e confianza antes de optimizar nada. Unha VPN protexe o segmento entre os seus pares, mentres que os extremos da aplicación e calquera segmento en texto claro fóra do túnel seguen a importar. Despois axuste o ciclo de vida da conexión dentro desa fronteira. A conclusión do túnel máis barato só se segue da crenza de que cada solicitude repite o handshake, e esa crenza é o que se pon a proba aquí.

A sección de persistencia de RFC 9112 é a referencia do que a reutilización promete en realidade, incluídas as condicións que rematan unha conexión. Léaa unha vez antes de confiar nunha proba que as ignora.