FolioPierEstudos de TI

WebSocket, SSE e long polling

Nota 26 de 37 · 4 min de leitura
Nesta página
  1. WebSocket
  2. SSE
  3. Long polling
  4. Retomar a conexão e retomar os dados

Para acompanhar pedidos e avisos, um serviço pode manter um canal aberto com o cliente ou fazer a consulta esperar até surgir uma novidade. Essas formas de troca têm tempos e falhas diferentes de uma consulta rápida comum, e uma espera longa pode ser o comportamento normal.

WebSocket

O WebSocket permite mensagens nos dois sentidos durante uma conexão persistente. A conexão começa como uma requisição HTTP que pede a mudança de protocolo, e o servidor aceita com o código 101. Os endereços usam ws:// ou wss://, e o segundo usa o TLS.

Persistente não quer dizer permanente. O cliente, o servidor, a rede ou um intermediário podem encerrar a conexão, e a aplicação define como reconectar e como recuperar as mensagens do intervalo.

Um log de WebSocket pode mostrar a abertura, as mensagens e o fechamento, com um código:

  • 1000: o fechamento normal;
  • 1001: um dos lados está saindo, como um servidor em reinício;
  • 1006: o término anormal, sem o fechamento adequado, indicado localmente pelo programa.

O código 1006 não vem do outro lado, porque o próprio programa registra esse código quando a conexão cai sem a troca de fechamento. Por isso, o 1006 não indica a causa, que pode estar na rede, em um proxy, no servidor, no aplicativo ou em um prazo. A análise também confere se houve reconexão e se os eventos do intervalo foram recuperados.

SSE

O SSE, sigla de Server-Sent Events, usa uma conexão HTTP para o servidor enviar eventos de texto ao cliente. O conteúdo usa o tipo text/event-stream, com linhas como event, data e, quando previsto, id. O fluxo vai só do servidor para o cliente, e as outras requisições do cliente seguem por chamadas separadas.

Ao reconectar, o cliente pode enviar o cabeçalho Last-Event-ID, com o identificador do último evento recebido. Esse cabeçalho comunica a posição conhecida, mas não obriga o servidor a guardar um histórico ilimitado nem a reenviar os eventos perdidos. A retenção e a política de retomada vêm do contrato.

Long polling

No long polling, o cliente faz uma consulta, e o servidor segura a resposta até surgir uma novidade ou até um prazo acabar. Depois de receber o retorno, o cliente inicia outra consulta. Uma requisição demorada é esperada nesse modelo, e a análise separa o prazo normal de espera de uma exceção ou de uma interrupção que a aplicação não tratou.

Retomar a conexão e retomar os dados

O WebSocket fornece o canal, sem definir um histórico de mensagens. A aplicação pode usar uma sequência, um cursor ou uma consulta da situação depois de uma interrupção. Sem um mecanismo de recuperação, reconectar só restabelece o caminho para as mensagens futuras.

A comparação entre o último evento recebido, o último evento aplicado e a primeira posição depois da retomada mostra se houve lacuna. Um evento recebido pode ter falhado no processamento local, e o avanço do cursor sem a aplicação dos dados deixa uma lacuna mesmo com a conexão saudável.

No suporte

Diante de uma falha em um canal contínuo, convém conferir a abertura, o término, a reconexão e a continuidade dos dados. No long polling, a duração da consulta é comparada com o prazo previsto, e, no WebSocket e no SSE, o intervalo sem conexão e o mecanismo de recuperação orientam a análise.

Para guardar

  • O WebSocket troca mensagens nos dois sentidos, e o SSE envia eventos do servidor ao cliente.
  • O long polling espera uma novidade em uma consulta que se repete.
  • O código 1006 indica um término anormal, sem identificar a causa.
  • Reconectar restabelece o canal, e a recuperação dos dados depende do contrato.
O log registra o código 1006 do WebSocket várias vezes. Isso confirma que um firewall está encerrando a conexão?

Não. O programa observou um término sem o fechamento adequado, e a origem ainda precisa ser investigada. Os horários e os logs dos dois lados, junto com a reconexão, orientam a busca da causa.

Uma consulta long polling levou 30 segundos e voltou sem novidade. Isso é uma falha?

Pode ser o comportamento normal, quando o contrato prevê esse prazo e esse retorno. O status, o conteúdo e a continuidade das consultas mostram se a espera foi normal ou se houve erro.

Publicado a partir do Obsidian · FolioPier