Protocolos de comunicação WebSocket vs. HTTP
Resumo de WebSocket vs. HTTP
Muitas de suas atividades diárias na Internet, desde pedir comida, pesquisar um fato ou falar com um médico on-line, são habilitadas por protocolos de comunicação WebSocket ou HTTP. Como desenvolvedor, ao criar um aplicativo, qual destes protocolos de comunicação você deve usar? Quais são as diferenças quando comparamos WebSocket vs. HTTP? Resumindo, o WebSocket, um protocolo de comunicação full-duplex, é relativamente mais novo e adequado para aplicações em tempo real, como < um i=3>bate-papo no aplicativo, notificações e voz ou videochamadas. Por outro lado, o HTTP, um protocolo de comunicação half-duplex, já existe há algum tempo e tem sido a base dos websites desde a sua estreia.
Neste comparativo, você conhecerá mais sobre esses dois protocolos de comunicação, suas semelhanças e diferenças, além de entender quando escolher um em vez do outro. Vamos mergulhar!
Sobre a conexão WebSocket
O protocolo WebSocket descreve como um cliente e um servidor se comunicam em canais full-duplex. Em outras palavras, tanto o cliente quanto o servidor podem enviar e receber dados simultaneamente através de uma conexão de longa duração. Esse tipo de comunicação tem menos sobrecarga do que a pesquisa HTTP, proporcionando ao aplicativo diversas vantagens em termos de funcionalidade em tempo real.
Vantagens de uma conexão WebSocket
Comunicação bidirecional
Como ambos os lados da conexão podem enviar mensagens sempre que desejarem, uma conexão WebSocket é uma excelente opção quando você precisa mover muitos dados rapidamente.
Imagine uma simples sala de chat conectando vários clientes. Se um servidor WebSocket moderar sua conversa, um cliente envia uma mensagem ao servidor, que a retransmite imediatamente para todos os outros clientes conectados. No que diz respeito aos usuários, eles podem enviar mensagens entre si em tempo real.
Esta é uma versão simples de como é:
Menor latência
Um padrão comum em uma conexão HTTP para busca de dados de frequência relativamente alta é a polling, em que o cliente solicita periodicamente novos dados do servidor. Talvez a maior desvantagem desse método de comunicação seja a latência: você precisa se comprometer entre solicitações frequentes ou de longa duração e a alta latência.
Com uma conexão WebSocket, os dados são enviados assim que estiverem disponíveis. O cliente não precisa ficar solicitando. O resultado é uma latência muito menor com uma fração da sobrecarga e do tráfego de rede.
Diagrama de comunicação WebSocket vs. HTTP
Conexões persistentes
Com a conexão HTTP tradicional, o cliente faz uma solicitação e, após o servidor enviar sua resposta, a conexão é encerrada. Se o cliente precisar de mais dados, ele deverá abrir uma nova conexão.
Observe que embora o HTTP/1.1 tenha introduzido conexões persistentes que permitem a reutilização da conexão TCP/IP, esse modelo mental ainda é útil e, em sua maioria, preciso.
Com uma conexão WebSocket, o cliente pode abrir e usar uma única conexão para todas as suas comunicações WebSocket com o servidor. Essa conexão persistente permite mensagens bidirecionais de baixa latência.
Essa conexão WebSocket também pode ser com estado. Uma conexão HTTP não tem estado – isso significa que cada solicitação é tratada isoladamente, sem retenção de informações sobre as solicitações anteriores. O WebSocket, por outro lado, tem estado graças à sua conexão persistente.
Se um aplicativo aproveita ou não a capacidade com estado depende inteiramente do desenvolvedor e de como ele usa sua conexão WebSocket.
Sobre a conexão HTTP
O protocolo HTTP foi projetado como um protocolo de solicitação-resposta. Um cliente, como um navegador, enviaria uma solicitação a um servidor web, e o servidor web responderia com um resposta contendo os recursos correspondentes à solicitação, como arquivos HTML e CSS. Embora as conexões HTTP sejam abertas, elas são apenas half-duplex, o que significa que a comunicação ocorre apenas em uma direção. Depois que uma resposta é recebida, a conexão geralmente é encerrada.
HTTP/1.1 introduziu conexões persistentes que reutilizam a conexão TCP/IP, o que permite algumas melhorias de desempenho. No entanto, as especificidades dessas conexões persistentes variam de servidor para servidor e, na maioria dos casos, elas são fechadas eventualmente com base em um tempo limite de inatividade. Portanto, embora seja uma adição bem-vinda à funcionalidade da conexão HTTP, ainda não é uma comparação direta com uma conexão WebSocket.
O protocolo HTTP tem sido muito bom naquilo para o qual foi construído: responder a solicitações. No entanto, ele não foi desenvolvido para lidar com casos de uso de comunicação em tempo real, como bate-papo ou evento ao vivo streaming, que as pessoas esperam hoje.
Mesmo assim, o HTTP ainda apresenta diversas vantagens sobre o protocolo WebSocket.
Vantagens de uma conexão HTTP
Simplicidade e onipresença
O poder de permanência das conexões HTTP vem de sua ampla adoção e de sua acessibilidade direta. Entre as três versões principais do HTTP, praticamente todos os servidores e navegadores da Web podem aproveitar o protocolo de alguma forma:
HTTP/1.1. Cerca de 35% dos sites ainda usam HTTP/1.1 ou inferior.
HTTP/2. Usado por 39,3% de todos os sites.
HTTP/3. Usado por 25,7% de todos os sites.
Natureza sem estado e suporte de cache
Como as solicitações HTTP são independentes e sem estado, o desempenho de um site pode se beneficiar do armazenamento em cache de respostas, especialmente ao lidar com conteúdo e ativos estáticos. O cache pode ocorrer em vários níveis:
No navegador: Isso elimina a necessidade de entrar em contato com o servidor.
Na borda: isso usa um servidor mais próximo da localização geográfica do usuário, como acontece com CDNs .
No servidor: Isso permite que o servidor evite recálculos caros se o resultado for sempre o mesmo.
As mensagens WebSocket não podem ser armazenadas em cache tão facilmente quanto as respostas HTTP, visto que elas têm estado e geralmente são sensíveis ao contexto. Essas mensagens mudariam com muita frequência para que o cache fosse útil na maioria dos casos.
Mecanismos de segurança robustos
A onipresença do protocolo HTTP significa que ele tem sido objeto de diversas iniciativas para melhorar sua postura de segurança.
HTTPS
O protocolo HTTP original carece de um aspecto importante: as mensagens de solicitação e resposta não são criptografadas e são relativamente fáceis de serem interceptadas e lidas por agentes mal-intencionados.
Esse problema é atenuado pelo HTTPS, uma variante do HTTP que usa Transport Layer Security (TLS) ou Secure Sockets Layer (SSL) para criptografar solicitações e respostas. Um ator malicioso pode interceptar seus pacotes, mas não conseguirá ler seu conteúdo, graças a essa criptografia.
Segurança de transporte estrita HTTP
Outro mecanismo de segurança relacionado ao HTTP é o HTTP Strict Transport Security (HSTS). O HSTS permite que os servidores especifiquem políticas para ajudar a prevenir problemas comuns de segurança, como ataques MITM, ataques de downgrade de protocolo.sequestro de cookies e
Um site pode aproveitar o HSTS retornando o cabeçalho apropriado por meio de uma conexão HTTPS, da seguinte forma:
Quando configurado corretamente, o HSTS garante que o navegador sempre solicitará a variante HTTPS do site, mesmo que o usuário tenha clicado em um link HTTP padrão. Como resultado, o usuário conta com uma camada de segurança que o protege de muitos ataques fáceis de mitigar.
WebSocket vs. HTTP: Escolhendo o protocolo adequado
Antes de começar a usar os protocolos WebSocket ou HTTP, considere o que você está construindo e por quê. Observe que cada protocolo de comunicação se destaca em diversas áreas onde o outro normalmente fica aquém.
Compensações técnicas entre uma conexão WebSocket vs. HTTP
Compreender as compensações técnicas entre esses dois protocolos de comunicação pode lhe dar uma ideia de qual é o mais adequado para o seu projeto.
Configuração e gerenciamento de conexão
Considere como você precisa que as conexões sejam estabelecidas e gerenciadas ao longo do tempo.
No caso do WebSocket, a conexão persistente é estabelecida por um handshake entre o cliente e o servidor. Ele permanece aberto durante a sessão, mesmo que haja um atraso significativo entre as mensagens.
Com o HTTP, as conexões são estabelecidas com um handshake e depois usadas para o ciclo de solicitação-resposta. O HTTP/1.1 permite que a mesma conexão TCP/IP seja reutilizada para vários pares de solicitação-resposta, o que reduz a sobrecarga e melhora a latência, mas não na mesma extensão que o WebSocket. A conexão ainda será encerrada em um período relativamente curto, variando de alguns segundos a vários minutos.
Transmissão e codificação de dados
Considere como você deseja que os dados sejam transmitidos.
Uma conexão WebSocket usa comunicação bidirecional full-duplex – qualquer lado da conexão pode enviar mensagens sempre que desejar. Uma conexão HTTP utiliza comunicação half-duplex; apenas uma parte pode se comunicar por vez, e a mensagem do servidor é sempre uma resposta a uma solicitação de um cliente.
Tanto o WebSocket quanto o HTTP podem enviar dados codificados em formatos baseados em texto, como JSON, XML e texto simples, bem como dados codificados em binário.
Tratamento e recuperação de erros
Considere quais métodos de tratamento de erros teriam menos impacto para os usuários.
Uma conexão WebSocket pode falhar por vários motivos, incluindo erros no código do seu aplicativo. Os clientes recebem um evento de erro que eles podem escutar, e você pode tratar o erro nesse ouvinte da maneira que achar melhor. No entanto, se o seu servidor WebSocket estiver sendo executado dentro do código do seu aplicativo, erros fatais no nível do aplicativo poderão afetar drasticamente a capacidade do seu aplicativo de implementar o tratamento de erros elegante.
É claro que uma conexão HTTP pode passar por circunstâncias semelhantes, mas certas arquiteturas comuns podem oferecer benefícios quando se trata de tratamento de erros. HTTP especifica um intervalo de códigos de status com os quais os servidores podem responder para indicar amplamente se a solicitação foi bem-sucedida ou não. Os intervalos 4xx e 5xx são reservados para erros de cliente e servidor, respectivamente.
Considere um aplicativo da Web em que as solicitações são tratadas por meio do NGINX como servidor da Web e do PHP.HTTP 503 - Serviço indisponível como linguagem de back-end dinâmica. Digamos que algo na lógica do aplicativo resulte em um erro fatal ou no encerramento do processo. Isso não afeta a capacidade do NGINX de fornecer uma resposta ao cliente, que provavelmente seria uma mensagem
É claro que essa separação depende da arquitetura da sua aplicação. Considere uma situação semelhante em que seu aplicativo e servidor web são implementados juntos no mesmo processo, como um aplicativo Node.js Express. Um erro fatal aqui também encerrará o servidor web, limitando a utilidade do erro que o cliente receberá.
Escalabilidade
Considere as necessidades de consumo de recursos do seu aplicativo.
As conexões WebSocket são projetadas para serem altamente eficientes no que fazem. Eles são orientados por eventos – as mensagens só são enviadas quando há algo sobre o qual enviar uma mensagem.
Uma conexão HTTP pode alcançar algo semelhante à funcionalidade em tempo real por meio de sondagens longas, em que as solicitações são enviadas e mantidas abertas até que haja algo para responder. Esta aproximação aproximada da comunicação em tempo real tem algumas limitações, especialmente em escala. As solicitações HTTP não podem ser mantidas abertas indefinidamente, o que significa que o cliente precisará abrir periodicamente uma nova solicitação de pesquisa longa. Com o tempo, a sobrecarga de processamento de todas essas solicitações HTTP de longa duração aumenta.
Com streaming HTTP, uma conexão é mantida aberta indefinidamente para facilitar um fluxo contínuo de dados. Isso é conceitualmente semelhante ao WebSocket, mas ainda é executado por HTTP e ainda é unidirecional – o cliente não pode enviar mensagens ao servidor por meio de streaming HTTP.
Considerações de desempenho de uma conexão WebSocket vs. HTTP
Considere as expectativas de desempenho do seu aplicativo.
Graças às conexões persistentes, o WebSocket se beneficia da redução da sobrecarga e da latência. Isso leva a um melhor desempenho, atualizações mais rápidas em tempo real e menos poder de processamento gasto em coisas como o aperto de mão de três vias HTTP e aplicações específicas de HTTP. código para gerenciar solicitações recebidas e autenticação/autorização.
Como o HTTP normalmente precisa lidar com diversas conexões durante a vida útil de uma sessão, ele naturalmente gastará mais tempo e recursos em comparação com o WebSocket.
Segurança de uma conexão WebSocket vs. HTTP
Considere o que é mais fácil para você proteger.
As conexões WebSocket e HTTP são semelhantes em relação às considerações de segurança. Ambos têm variantes inseguras e seguras e podem ser vítimas de vários ataques comuns se não forem protegidos adequadamente. Há também ataques específicos para cada protocolo que você precisa conhecer, como ataques de script entre sites para HTTP e sequestro de WebSocket entre sites para WebSocket.
No entanto, se você configurá-los adequadamente e usar a criptografia TLS, poderá mitigar a maioria das ameaças, tornando ambos os protocolos suficientemente seguros.
Abordagens híbridas para protocolos de comunicação
Normalmente, a abordagem recomendada é usar ambos os protocolos para o que eles fazem de melhor em seu sistema. Isso significa usar uma conexão HTTP para a maior parte do tráfego padrão da Web e uma conexão WebSocket para qualquer coisa que exija comunicação em tempo real, como notificações, .chamadas de vídeo ou mensagens/bate-papo
Você também pode considerar avaliar tecnologias complementares ou alternativas; Afinal, WebSocket e HTTP não são as únicas opções quando se trata de comunicação em tempo real. WebRTC é semelhante ao WebSocket, com a principal diferença de que ele é usado para implementar conexões ponto a ponto< /span> sem depender de um servidor. Isso pode ser especialmente útil para videochamadas, permitindo que os participantes se comuniquem diretamente sem sobrecarregar o servidor.
Protocolos de comunicação para comunicações seguras, escaláveis e confiáveis em aplicativos
Agora você deve ter uma ideia sólida de como os protocolos de comunicação WebSocket e HTTP devem ser usados. Você viu seus pontos fortes e fracos e pode apreciar suas vantagens e desvantagens.
Felizmente, você não precisa escolher um em vez de outro. Os dois protocolos de comunicação podem, e muitas vezes devem, ser usados em conjunto, permitindo que cada um faça o que faz melhor. Se você precisar implementar comunicação em tempo real e funcionalidade de streaming em seus aplicativos, confira Sendbird. As APIs e SDKs de cliente do Sendbird cuidam do trabalho técnico pesado para bate-papo, chamadastransmissão ao vivo. O serviço de chat do Sendbird abstrai os problemas (como funcionar de forma confiável e segura em tempo real em grande escala) associados ao crescimento e manutenção de um sistema de chat por um longo período de tempo. Isso significa que você pode se concentrar nos aspectos principais do seu aplicativo.
Quer experimentar? Inscreva-se gratuitamente, sem necessidade de compromisso ou cartão de crédito.
Feliz construção de comunicações no aplicativo! 📱