Cache de Conexões HTTP Pix

As requisições HTTP Pix usam um cache de conexões próprio, separado do cache de sessões do HSM. Abrir uma conexão nova significa refazer o handshake TLS, e todo handshake completo usa a chave privada dentro do HSM; reaproveitar a conexão evita os dois custos.

O cache guarda conexões HTTP já estabelecidas com o peer. Cada requisição de um handle no modo padrão pega uma conexão emprestada e a devolve ao terminar, de forma que a quantidade de conexões acompanha a concorrência real da aplicação, e não a quantidade de handles abertos. Handles criados com DN_PIX_NO_CACHE não participam do cache.

Características do cache de conexões HTTP:

1. Intra-processo: assim como o cache de sessões, o cache é feito por processo. Duas aplicações na mesma máquina não compartilham conexões;
2. Uma conexão por entrada: cada entrada do cache mantém exatamente uma conexão, então o número de entradas é o próprio número de conexões abertas com o peer;
3. Seleção MRU: entre as conexões livres equivalentes é escolhida a usada mais recentemente. Isso mantém quente um conjunto pequeno de conexões e deixa as demais expirarem por ociosidade, em vez de espalhar o tráfego por todas.

Reaproveitamento

Uma conexão só é reaproveitada por uma requisição equivalente. São considerados:

• a identidade autenticada no HSM;
• os identificadores da chave privada, do certificado e da cadeia do peer;
• o destino (host:porta).

Como o destino faz parte do critério, um mesmo handle usado contra dois endpoints diferentes mantém uma conexão para cada um, em vez de reconectar a cada alternância.

Retomada de sessão TLS (session resumption)

Ao abrir uma conexão nova, o cliente tenta retomar a sessão TLS de outra conexão equivalente, o que evita um handshake completo. A retomada (session resumption) é feita por identificador de sessão (session ID): os tickets de sessão (RFC 5077) ficam desabilitados no cliente HTTP, portanto a retomada só acontece quando o peer mantém cache de session ID do lado servidor.

Um handshake retomado não envia CertificateVerify e, com isso, não usa a chave privada do HSM. É o que torna a reconexão barata, e é a diferença observável entre os contadores de handshakes e de assinaturas no HSM.

Ociosidade e limites

Uma conexão parada por mais tempo que o TTL de ociosidade é fechada na próxima varredura. O tempo é configurado pela variável de ambiente HSM_PIX_POOL_IDLE_TTL.

O número máximo de conexões é configurado por HSM_PIX_POOL_MAX_HANDLES. Por ser uma conexão por entrada, este é o próprio teto de conexões simultâneas apresentado ao peer. O padrão é sem limite, o que faz o cache crescer conforme a concorrência da aplicação; ao atingir um limite configurado, a requisição falha em vez de abrir uma conexão além do teto.

Ambas as variáveis também podem ser ajustadas em tempo de execução por DPIXSetCacheParam().

Troca de certificados

Os objetos do HSM (chave privada, certificado e cadeia) são lidos durante o handshake. Uma conexão já aberta não os relê, portanto uma troca programada só passa a valer quando a conexão é refeita.

Para não esperar, limpe o cache com DPIXSetCacheParam() usando PIXCP_CLEAR: as conexões ociosas são fechadas imediatamente e as em uso ao final da requisição em andamento. A próxima requisição abre uma conexão nova e relê os objetos.

Contadores

DPIXGetCacheParam() com PIXCP_STATS devolve os contadores do cache, úteis para dimensionar o limite e acompanhar o custo das conexões: conexões vivas, em uso, máximo já atingido, conexões fechadas por ociosidade, handshakes TLS e assinaturas feitas no HSM.

Para detalhes sobre configuração consulte o tópico Sessões - Pix.