A sua aplicação autoalojada precisa de ligações persistentes? Uma checklist de WebSockets, SSE e long polling

Porque as ligações persistentes são uma questão de seleção da aplicação, e não apenas uma definição do proxy

Um requisito de ligação persistente altera mais do que a configuração de um proxy reverso. Afeta o percurso de rede entre um utilizador e a aplicação, a forma como as implementações são drenadas, o que acontece após alterações de autenticação, a forma como várias instâncias da aplicação se coordenam e os sinais de que os operadores precisam durante um incidente.

Comece pela experiência do utilizador, em vez de uma preferência por protocolo. Uma aplicação pode funcionar perfeitamente com HTTP normal de pedido-resposta para trabalho administrativo, relatórios periódicos e atualizações não urgentes. Outras experiências podem parecer incompletas quando as atualizações sofrem atrasos ou quando uma sessão interativa se volta a ligar repetidamente. A pergunta certa não é “O proxy suporta WebSockets?”, mas sim “Que fluxo de trabalho do utilizador depende de uma ligação aberta ou mantida repetidamente, e qual é o comportamento aceitável quando ela não está disponível?”

Numa implementação gerida, confirme os requisitos na documentação atual do fornecedor da aplicação e teste o fluxo de trabalho real após a implementação. A Airbip executa instâncias de aplicações como workloads Docker em servidores cloud e automatiza o encaminhamento e os certificados TLS através do Traefik e do Let’s Encrypt. Isto pode simplificar a infraestrutura em torno de uma aplicação suportada, mas não substitui a necessidade de validar o comportamento em tempo real específico da aplicação, o desenho da identidade, o tratamento de dados e a responsabilidade operacional.

• Identifique o ecrã, o fluxo de trabalho ou a integração exata que precisa de entrega atempada.
• Defina se a aplicação precisa apenas de atualizações do servidor para o browser ou de mensagens interativas bidirecionais.
• Registe o mecanismo de contingência esperado: atualização da página, polling periódico, notificação atrasada, fila de repetição ou um estado offline claro.
• Trate os requisitos de transporte em tempo real como um critério de aceitação antes da migração, e não como uma tarefa de ajuste posterior ao lançamento.

WebSockets, Server-Sent Events e long polling: o que difere operacionalmente

Os WebSockets começam com um handshake de abertura HTTP e, em seguida, trocam mensagens enquadradas através da ligação estabelecida. São adequados quando uma aplicação precisa de um canal bidirecional contínuo. A RFC 6455 também define frames de controlo Ping e Pong, que os pontos finais podem utilizar para verificações de atividade ou capacidade de resposta.

Os Server-Sent Events, habitualmente denominados SSE, utilizam a interface EventSource do browser e o tipo de conteúdo text/event-stream. Os SSE foram concebidos para a entrega de eventos do servidor para a página. São frequentemente uma boa opção quando o browser recebe sobretudo atualizações e envia comandos através de pedidos HTTP normais. O EventSource volta a ligar-se depois de uma ligação ser fechada, exceto se o servidor enviar HTTP 204 No Content; também pode fornecer um cabeçalho Last-Event-ID ao voltar a ligar-se, permitindo ao servidor determinar o último identificador de evento recebido.

O long polling mantém um pedido HTTP em espera até ocorrer uma atualização, alteração de estado ou timeout, após o que o cliente normalmente abre outro pedido. Pode funcionar através de infraestrutura HTTP familiar, mas cada entrega continua a ser uma troca completa de pedido-resposta HTTP. Os pedidos pendentes consomem recursos em clientes, servidores, gateways e proxies, pelo que as suas características operacionais merecem testes deliberados à concorrência esperada.

• Escolha WebSockets quando o produto exige um canal bidirecional contínuo e o fornecedor documenta esse transporte.
• Considere SSE para fluxos unidirecionais do servidor para o browser, com pedidos HTTP usados para ações do cliente.
• Considere long polling quando a aplicação o suporta e as atualizações quase em tempo real são úteis, mas uma ligação continuamente atualizada não é necessária.
• Não presuma que um padrão é inerentemente mais simples: a complexidade operacional depende da aplicação, do comportamento do cliente e de cada intermediário no percurso.

Que experiências de utilizador podem depender de ligações persistentes

As ligações persistentes justificam-se normalmente por padrões de interação, e não por uma etiqueta de categoria como CRM, análises ou colaboração. Um indicador de presença em tempo real, uma superfície de edição partilhada, uma consola operacional em atualização contínua, uma resposta de IA transmitida em fluxo ou um feed de notificações dentro do produto podem depender de entrega atempada pelo servidor. Ainda assim, a mesma aplicação pode frequentemente conter muitas páginas que não precisam disso.

Classifique cada fluxo de trabalho pela consequência. Um atraso na atualização de um dashboard pode ser tolerável. Uma interface de controlo que deixa um operador sem saber se uma ação foi recebida pode não o ser. Da mesma forma, uma funcionalidade de colaboração pode ter de indicar que o seu canal em tempo real está a voltar a ligar-se, em vez de mostrar silenciosamente um estado desatualizado.

Pergunte ao fornecedor se o comportamento é necessário para a correção, preferível para a capacidade de resposta ou apenas uma melhoria opcional. Pergunte também se a aplicação tem um modo degradado suportado. Não deduza requisitos de transporte a partir do marketing do produto ou da presença de uma interface de browser.

• Colaboração: estado partilhado, presença, comentários ou alertas podem precisar de propagação rápida.
• Interfaces operacionais: alterações de estado, progresso de tarefas e alertas podem precisar de um indicador explícito de atualidade.
• Notificações: determine se e-mail atrasado ou consulta na aplicação é um mecanismo de contingência aceitável.
• Interfaces de IA: distinga uma resposta transmitida em fluxo de um pedido que pode simplesmente terminar antes de apresentar o resultado.
• Integrações: estabeleça se os eventos recebidos, as confirmações de entrega enviadas ou ambos dependem de um canal de longa duração.

Uma checklist antes da adoção: documentação do fornecedor, percurso de rede, autenticação, escalabilidade e comportamento em caso de falha

Antes de adotar ou migrar uma aplicação, crie um perfil de ligação curto e baseado em evidências. A documentação do fornecedor da aplicação deve ser a fonte principal para transportes suportados, caminhos de endpoint, cabeçalhos obrigatórios, comportamento de autenticação, orientação para proxies, desenho multi-instância e comportamento de contingência esperado. Se a documentação não for clara, teste o fluxo de trabalho específico num ambiente representativo em vez de fazer suposições.

Mapeie todo o percurso: browser ou cliente, DNS, terminação TLS, camada de entrega de conteúdo ou segurança, se existir, proxy reverso, balanceador de carga, workload da aplicação e qualquer componente de partilha de mensagens exigido pela aplicação. Uma definição que parece correta na extremidade da aplicação pode ser anulada por um intermediário anterior com um timeout de inatividade mais curto ou uma política de ligação que não permite o tráfego pretendido.

A autenticação exige atenção especial porque uma ligação pode sobreviver a um pedido de página. Estabeleça como a aplicação autentica a ligação inicial, como trata credenciais expiradas e o que acontece quando o acesso é revogado enquanto um canal está aberto. Trate estes pontos como questões de desenho específicas da aplicação a verificar, e não como propriedades universais do transporte.

• Obtenha a documentação do fornecedor sobre proxy e escalabilidade para o modo de implementação pretendido.
• Liste todos os intermediários de rede e as respetivas políticas de ligações, cabeçalhos e timeouts.
• Verifique os requisitos de TLS e de domínio personalizado; a Airbip suporta um subdomínio Airbip ou um domínio personalizado compatível.
• Documente a autenticação no estabelecimento da ligação, a expiração de token ou sessão, o encerramento de sessão e a revogação de acesso.
• Teste as reconexões esperadas, atualizações do browser, reinícios da aplicação e indisponibilidade temporária do proxy.
• Confirme o modelo suportado pela aplicação para várias instâncias antes de projetar a escalabilidade horizontal.

Perguntas a fazer a um fornecedor de alojamento gerido ou à equipa interna de plataforma

As perguntas úteis são concretas e estão ligadas ao comportamento documentado da aplicação. Uma equipa de plataforma pode explicar a camada de encaminhamento, o processo de domínios e certificados, os controlos de ciclo de vida, a abordagem de backups e os limites do seu serviço. Não pode prometer de forma responsável que um transporte de aplicação não documentado, uma biblioteca de cliente ou uma integração de terceiros se comportará corretamente sem validação.

Para implementações na Airbip, os pontos de partida relevantes incluem o modelo de workloads Docker da aplicação, a automatização de encaminhamento e TLS através do Traefik e do Let’s Encrypt, as verificações de DNS, a gestão do ciclo de vida do serviço e backups diários, semanais e mensais configuráveis. Os backups são importantes para a recuperabilidade, mas não substituem a drenagem de ligações, a lógica de repetição do cliente ou um modo de falha em tempo real testado.

• A versão planeada da aplicação documenta endpoints de WebSocket, SSE ou long polling e requisitos de proxy?
• Onde termina o TLS e as ligações WebSocket seguras são suportadas em todo o percurso pretendido?
• Que definições de timeout se aplicam na camada de encaminhamento e que camadas a montante impõem os seus próprios limites?
• A aplicação pode ser reiniciada ou atualizada com uma experiência de reconexão definida para o utilizador?
• Se for utilizada mais do que uma instância da aplicação, que componente partilha eventos, presença ou estado relacionado com ligações?
• Que registos e métricas estão disponíveis durante um incidente de ligação?
• Que responsabilidades permanecem com o cliente relativamente ao acesso de utilizadores, à configuração da aplicação, à retenção de dados e à governação?

Proxies reversos e balanceadores de carga: atualizações, timeouts, cabeçalhos encaminhados e limites de ligações

Para WebSockets, valide o handshake de abertura HTTP ao longo de todo o percurso. O Traefik documenta suporte para WS e WSS sem um middleware WebSocket separado e afirma que preserva cabeçalhos relevantes do handshake, como Origin e Sec-WebSocket-Key. Este é um comportamento de infraestrutura útil, mas a aplicação implementada continua a ter de aceitar a origem pública, construir URLs externas corretas e aplicar as suas próprias regras de segurança.

Os cabeçalhos encaminhados são importantes quando uma aplicação precisa de conhecer o host, o esquema ou o endereço do cliente original. O Traefik adiciona automaticamente X-Forwarded-For, X-Real-Ip, X-Forwarded-Host, X-Forwarded-Port, X-Forwarded-Proto e X-Forwarded-Server durante o proxy. Verifique como a aplicação confia e interpreta os cabeçalhos encaminhados, especialmente quando existe outro proxy antes da camada de encaminhamento.

Os timeouts devem ser avaliados como uma cadeia. Os entry points do Traefik expõem definições de timeout de leitura, escrita e inatividade. Para long polling, a RFC 6202 observa que um servidor ou intermediário pode terminar um pedido pendente com HTTP 408 ou HTTP 504, e o timeout limitativo pode estar na infraestrutura, e não no browser. O SSE pode necessitar de saída keepalive periódica porque alguns proxies antigos podem fechar uma ligação HTTP que, de outro modo, está inativa. Os limites de ligações, a capacidade de descritores de ficheiro e a utilização de recursos a montante também precisam de ser revistos para o número esperado de clientes simultâneos.

• Confirme o comportamento de handshake e atualização de WebSocket de ponta a ponta, e não apenas no proxy final.
• Alinhe os heartbeats ou keepalives da aplicação com a política de inatividade relevante mais curta, quando a aplicação os suportar.
• Defina e teste as durações dos pedidos de long polling face aos timeouts do servidor e dos intermediários.
• Impeça o armazenamento em cache inadequado de rotas de long polling através de controlos de cache HTTP padrão.
• Verifique o tratamento de origem e a configuração de confiança no proxy da aplicação.
• Teste a capacidade de ligações abertas concorrentes e observe a pressão sobre recursos do proxy, do host e da aplicação.

Como as ligações persistentes afetam implementações multi-instância e o desenho de sessões

Uma única instância de aplicação pode evitar muitas questões de sistemas distribuídos, mas não elimina a necessidade de lidar com reconexões e reinícios. Quando o tráfego é servido por várias instâncias, um cliente ligado pode estar associado a uma instância enquanto um evento é criado noutra. Se a aplicação exigir difusões, presença partilhada ou entrega a utilizadores ligados noutros locais, precisa do mecanismo documentado para partilhar mensagens ou eventos relacionados com ligações entre instâncias.

A orientação do HAProxy para WebSockets ilustra a questão subjacente: cada servidor WebSocket tem a sua própria lista de clientes ligados, pelo que a entrega ou difusão entre servidores exige que as mensagens sejam partilhadas entre servidores. A afinidade do balanceador de carga pode ser relevante para alguns modelos de sessão de aplicação, mas não substitui, de forma geral, o estado partilhado. Não pode tornar um evento conhecido de uma instância que não o recebeu.

Analise o estado separadamente: sessões de utilizador, estado de autorização, propriedade da ligação, estado de subscrição, histórico de eventos e tarefas em segundo plano podem ter, cada um, requisitos diferentes de armazenamento ou coordenação. Escalone apenas com uma arquitetura suportada pelo fornecedor e teste um cliente a voltar a ligar-se a uma instância diferente.

• Determine se a aplicação suporta oficialmente mais de uma instância ativa.
• Identifique onde são armazenados as sessões, as subscrições e o histórico de eventos.
• Confirme como são propagadas as difusões entre instâncias e a entrega direcionada.
• Teste a perda de uma instância enquanto os clientes permanecem ligados às outras.
• Não dependa da afinidade do balanceador de carga como único desenho para eventos partilhados ou estado durável.
• Garanta que os clientes que se voltam a ligar conseguem restaurar o estado ou pedir com segurança uma vista atual.

Sinais de monitorização: clientes ligados, desconexões, taxas de reconexão, padrões de erro e pressão sobre recursos

Os canais persistentes precisam de observabilidade que distinga uma ligação silenciosa saudável de uma ligação interrompida. Recolha contagens de ligações onde o proxy ou a aplicação as disponibilizar, mas interprete-as juntamente com a idade da ligação, motivos de desconexão, tentativas de reconexão, falhas de handshake, erros de resposta e atualidade visível para o utilizador. Não existe um limiar saudável universal: os níveis normais dependem da população de clientes da aplicação, da duração esperada das sessões, da atividade de lançamento e do perfil de tráfego.

Acompanhe tanto o comportamento do serviço como o do cliente. Uma taxa crescente de desconexões pode indicar uma incompatibilidade de timeout, interrupção de rede, evento de implementação ou problema na aplicação. Um aumento de reconexões após a recuperação de um serviço pode criar o seu próprio pico de carga. A RFC 6455 recomenda reconexões atrasadas com períodos cada vez maiores após um encerramento anormal, ajudando os clientes a evitar sobrecarregar um serviço em recuperação.

A monitorização de recursos continua essencial. O long polling pode acumular pedidos HTTP pendentes. As ligações de longa duração podem manter sockets e consumir recursos do proxy, do sistema operativo e da aplicação. Monitorize a capacidade de ligação relevante, CPU, memória, atividade de rede e registos de erros em todo o percurso, investigando alterações em relação a uma linha de base em vez de depender de metas numéricas emprestadas.

• Clientes ligados atuais e de pico, segmentados por endpoint quando disponível.
• Falhas de handshake, falhas de autorização e códigos de resposta inesperados.
• Motivos de desconexão e distribuição da duração das ligações.
• Taxa de reconexão, comportamento de atraso de repetição e eventos correlacionados de implementação ou rede.
• Pedidos de long polling pendentes e respostas de timeout, como 408 ou 504.
• Pressão sobre CPU, memória, sockets e recursos de rede no proxy, host e aplicação.
• Um indicador de atualidade ou desconexão visível para o utilizador, quando a aplicação o disponibilizar.