HTTP vs. WebSocket
Este artigo compara os protocolos HTTP e WebSocket, explicando as suas principais diferenças, funcionalidades e casos de uso ideais. Fornece aos programadores insights cruciais para escolherem o protocolo certo para as suas aplicações web, contrastando o modelo de requisição-resposta do HTTP com as capacidades de comunicação bidirecional em tempo real do WebSocket.
Developer
A base de todo o mundo digital é a comunicação entre máquinas. Clientes autorizados criam um pedido, que o servidor recebe, interpreta e dá uma resposta adequada. Esta é a compreensão comum da comunicação digital para pessoas comuns. No entanto, o trabalho nos bastidores é complexo e tedioso.
Os programadores de aplicações precisam de fazer muito trabalho para garantir que esta comunicação cliente-servidor funcione corretamente. Escolher o protocolo de comunicação correto é uma dessas tarefas. Quando os programadores tentam selecionar um protocolo de comunicação viável, HTTP e WebSocket são dois conceitos comuns que irão encontrar.
Esclarecer estes dois, as suas semelhanças, funções e outros aspetos é crucial para garantir que a opção correta seja escolhida com base nas necessidades reais.
Introdução ao HTTP
Vamos primeiro entender o HTTP. Provavelmente é o protocolo mais utilizado no campo da comunicação digital. A versão inicial do HTTP foi lançada em 1989, com funcionalidades e alcance de aplicação limitados. Mas rapidamente foi melhorado e atualizado para suportar a comunicação em grande escala entre navegadores e servidores.
O HTTP é um protocolo unidirecional, o que significa que em qualquer momento apenas uma parte na comunicação pode enviar ou receber informações. Quando um cliente envia um pedido a um servidor, este pedido é enviado sob a forma de HTTP ou HTTPS, e o servidor envia uma resposta correspondente e única ao cliente após receber o pedido. Cada pedido HTTP ou HTTPS estabelece uma nova conexão com o servidor e termina automaticamente a conexão após receber a resposta.
Algumas das principais funcionalidades do HTTP incluem:
- Sem estado
- Pode funcionar com base em protocolos orientados à conexão (como SCTP e TCP)
- Informação é codificada em ASCII
- Os principais componentes de um pedido HTTP incluem versão do HTTP (HTTP/1.1, HTTP/2, HTTP/3), método, cabeçalho HTTP, informações do host, e mensagem
O que é WebSocket?
WebSocket é um protocolo de comunicação que pode alcançar comunicação bidirecional em tempo real entre cliente e servidor.
WebSocket é um protocolo para criar canais de comunicação bidirecional em tempo real em aplicações web. Ao contrário dos pedidos HTTP tradicionais (tipicamente um pedido corresponde a uma resposta), o WebSocket pode estabelecer conexões persistentes, permitindo que o servidor empurre dados para o cliente em tempo real enquanto também recebe dados do cliente. Em comparação com a sondagem tradicional, o WebSocket reduz significativamente o tráfego de rede e a latência, melhorando a eficiência e a velocidade da transmissão de dados. É particularmente adequado para desenvolver aplicações web em tempo real e jogos online.
Algumas das principais funcionalidades do WebSocket incluem:
- Baseado em conexões TCP persistentes, que permanecem abertas até que o cliente ou servidor inicie um pedido de termo
- Construído sobre o protocolo HTTP, todos os pedidos WebSocket são enviados através do protocolo HTTP padrão e depois identificados como informação de cabeçalho específica Upgrade no lado do servidor
- O protocolo WebSocket é baseado em quadros (pacotes de dados), um pacote de dados completo pode ser dividido em múltiplos quadros, cada quadro contendo uma parte dos dados e informação de cabeçalho
A relação entre HTTP e WebSocket
A partir da introdução acima, podemos ver que ambos os protocolos HTTP e WebSocket:
- Usam o protocolo TCP para transmissão de dados
- São usados para a comunicação entre cliente e servidor
Podemos mostrar de forma mais intuitiva as diferenças entre HTTP e WebSocket através da tabela seguinte.
| HTTP | WebSocket |
|---|---|
| Estabelece uma nova conexão para cada pedido (a menos que use conexões longas HTTP, como HTTP/1.1 Keep-Alive), e fecha a conexão após o término da comunicação | A conexão permanece aberta após o handshake inicial bem-sucedido, a menos que seja fechada ativamente ou ocorra um erro |
| Modo de comunicação unidirecional, o cliente envia o pedido, o servidor retorna a resposta, cada nova comunicação requer restabelecer a conexão | Modo de comunicação bidirecional, após estabelecer a conexão, cliente e servidor podem enviar dados a qualquer momento sem restabelecer a conexão |
| Cada comunicação requer o envio de cabeçalhos de pedido e resposta completos, portanto, o overhead é grande para comunicações de mensagens curtas frequentes | Uma vez estabelecida a conexão, a transmissão de dados é mais leve, não há necessidade de transmitir informações de cabeçalho cada vez, adequado para necessidades de comunicação de alta frequência e baixa latência |
| Principalmente usado para transmitir dados relativamente estáveis | Principalmente usado para transmitir dados em tempo real |
| Devido à necessidade de restabelecer conexões a cada pedido e transportar informação necessária através de cabeçalhos, etc., a eficiência de uso de largura de banda e a velocidade de resposta são afetadas | A conexão contínua elimina as etapas de estabelecer conexões e a informação necessária para cada pedido, resultando em menor latência e maior eficiência de uso de largura de banda |
| Pedidos frequentes afetam o desempenho | Pedidos frequentes não afetam o desempenho |
Como escolher qual protocolo usar?
Com base na comparação das vantagens e desvantagens do HTTP e WebSocket na seção anterior, podemos avaliar cenários de uso a partir de duas dimensões diferentes:
- Se os dados mudam rapidamente e se o negócio depende de dados em tempo real
- Se está envolvida uma comunicação bidirecional frequente
Por exemplo, se o Jack quer construir uma aplicação de chat por vídeo onde cada utilizador precisa de receber dados de vídeo em tempo real do parceiro de chat e transmitir o seu próprio fluxo de vídeo para a outra parte, então o WebSocket é a melhor escolha.
O Admin Console do Logto não precisa de obter frequentemente o uso de recursos do utilizador logado atual, porque os recursos só mudam de estado quando os utilizadores modificam as configurações. Só é necessário readquirir o estado do recurso em tempo hábil quando os utilizadores operam nos recursos. Sob esta perspetiva, o HTTP é muito adequado para o cenário de uso do Admin Console do Logto. Da mesma forma, para a maioria dos dashboards de serviços em nuvem, o HTTP pode ser escolhido como o protocolo de comunicação entre o dashboard e o servidor.