Considere um aplicativo que acessa um servidor HTTPS remoto, enviando POST de solicitações formatadas em JSON em uma URL no servidor e recebendo respostas em formato JSON. O servidor não suporta a multiplexação HTTP / 2 .
Existem muitos pedidos, com uma carga de trabalho muito variável (do inactivo para centenas de TPS). As mensagens JSON são da ordem de 1 kbyte. Cliente e servidor são autenticados por certificados + chaves privadas. As solicitações podem ser consideradas independentes (em particular, o servidor trata solicitações semelhantes para todos os canais HTTPS abertos com o mesmo certificado de cliente).
O HTTP / 1.1 não permite vários * solicitações POST simultâneas na mesma conexão. Portanto, a taxa de transferência não pode exceder N / (Tr + Ts) TPS, onde N é o número de canais HTTPS / TLS abertos em uso, Tr é o atraso de ida e volta da rede, e Ts está processando o tempo o lado do servidor (na ordem de 30 ms sob carga baixa, devido ao acesso ao banco de dados e outros fatores). Abrir uma conexão HTTPS custa pelo menos 4 Tr e um tempo considerável de CPU em ambos os lados. Parece que algo é necessário para gerenciar um conjunto de conexões HTTPS no lado do cliente.
Como esse problema costuma ser tratado?
O que são bibliotecas comuns ou daemon / serviços de segundo plano, abrindo automaticamente novas conexões HTTPS, conforme necessário, reutilizando-as sempre que possível?
Seria bom se isso fosse detectado quando o servidor parasse de responder, e resolvesse o fallback para um servidor de backup em uma URL diferente, com o retorno ao servidor principal quando ele estivesse ativo novamente.
Nota: O próximo passo seria o balanceamento de carga, mas minha camada de balanceamento de carga deve manipular uma afinidade entre as solicitações, pois elas não são totalmente independentes (o envio de uma solicitação dependente para o servidor errado é detectado com segurança pelo servidor, embora).
Tags networking https concurrency