O WebSocket é um protocolo de rede que fornece um canal de comunicação full-duplex sobre uma única conexão TCP. Ele permite uma conexão persistente entre cliente e servidor, possibilitando que ambos enviem e recebam dados proativamente. Esse design reduz a sobrecarga e a latência associadas ao estabelecimento frequente de novas conexões, tornando-o mais eficiente que o modelo tradicional de requisição-resposta HTTP. O WebSocket é usado principalmente em aplicações que exigem comunicação em tempo real. O Classic Load Balancer (CLB) suporta o protocolo WebSocket por padrão.
Introdução ao WebSocket
Por que usar o WebSocket
Com a evolução das tecnologias web, as aplicações exigem cada vez mais que os servidores enviem dados em tempo real para funcionalidades como salas de bate-papo ao vivo e comentários instantâneos. O método tradicional de polling, no qual o navegador do cliente envia repetidamente requisições HTTP ao servidor para buscar os dados mais recentes, apresenta desvantagens significativas. Requisições frequentes com cabeçalhos HTTP grandes e cargas úteis de dados pequenas aumentam a carga do servidor e desperdiçam largura de banda.
Para resolver esses problemas, o HTML5 introduziu o protocolo WebSocket, que oferece uma solução mais eficiente para a comunicação entre cliente e servidor. O WebSocket suporta comunicação full-duplex, o que significa que servidor e cliente podem enviar e receber dados simultaneamente. Isso permite que o servidor envie novos dados proativamente ao cliente sem esperar por uma requisição de polling. Esse mecanismo de comunicação bidirecional e em tempo real melhora a eficiência da transferência de dados, reduz requisições de rede desnecessárias e economiza recursos do servidor e largura de banda, proporcionando uma experiência de usuário mais fluida e responsiva.
Principais recursos do WebSocket
A comunicação começa com um handshake TCP padrão de três vias. Em seguida, o cliente envia uma requisição HTTP especial, conhecida como handshake de upgrade de protocolo. Após a conclusão bem-sucedida desse handshake, a conexão muda de HTTP para WebSocket. Toda a comunicação subsequente entre cliente e servidor utiliza o protocolo WebSocket, permitindo a troca bidirecional de dados pela mesma conexão.
Uma vez estabelecida, a conexão WebSocket permanece ativa. Essa conexão persistente e de baixa latência permite a transferência contínua e bidirecional de dados, o que aumenta a eficiência da troca de informações.
O WebSocket comunica-se usando frames de dados, que possuem seu próprio formato de protocolo de frame com cabeçalhos concisos. Os dados podem ser transmitidos como texto ou binário. Esse método reduz a sobrecarga do protocolo em conexões persistentes, tornando a interação de rede mais eficiente. Ele economiza recursos do servidor e largura de banda, ao mesmo tempo que proporciona uma experiência interativa em tempo real mais fluida.
Para obter mais informações sobre o protocolo WebSocket, consulte a documentação oficial The WebSocket Protocol.
Casos de uso do WebSocket
O WebSocket é ideal para aplicações que exigem comunicação bidirecional rápida e em tempo real, como aplicações de IA, salas de bate-papo online, sistemas de notificação em tempo real, jogos online multiplayer e feeds de dados de mercado em tempo real.
Cenário de exemplo
Uma empresa deseja implantar uma aplicação web de bate-papo online na Alibaba Cloud. Os usuários acessam o service de backend por meio de um nome de domínio para comunicação em tempo real. Por ser uma aplicação de mensagens instantâneas, ela requer baixa latência e comunicação bidirecional eficiente e em tempo real.
O service de site da empresa enfrenta desafios relacionados a alta concorrência e gerenciamento de conexões persistentes. À medida que o número de usuários cresce, o modelo HTTP tradicional não consegue suportar muitos usuários simultâneos na comunicação em tempo real, pois cada interação exige uma nova conexão. Isso leva a um aumento abrupto na carga do servidor e a um desempenho insatisfatório.
Nesse cenário, o uso do CLB com o protocolo WebSocket gerencia eficazmente as conexões persistentes sob alta concorrência. Ao implantar a aplicação WebSocket em vários servidores de backend em um grupo vServer e usar o Redis para sincronização de mensagens, o service alcança alta disponibilidade. Isso fornece uma solução de mensagens em tempo real confiável e eficiente para a aplicação de bate-papo online.
Observações de uso
Os listeners HTTP no CLB suportam o protocolo WebSocket por padrão. O CLB suporta atualizações a quente, o que significa que alterações de configuração não afetam as conexões persistentes existentes.
Observe os seguintes pontos:
Se a conexão entre o CLB e os servidores de backend usar uma versão específica do HTTP, como HTTP/1.1, utilize um servidor web que suporte a mesma versão HTTP nos servidores de backend.
-
O tempo limite padrão para requisição de conexão de um listener HTTP é de 60 segundos. Caso nenhuma mensagem seja trocada entre o CLB e um servidor de backend por mais de 60 segundos, o CLB encerra a conexão proativamente.
Se o tempo limite padrão de 60 segundos for insuficiente para suas necessidades, modifique o Connection Request Timeout do listener.
Para manter a conexão aberta, implemente um mecanismo de keepalive para trocar pacotes pelo menos uma vez a cada 60 segundos.
Os listeners HTTP no CLB suportam o protocolo WebSocket por padrão, e os listeners HTTPS suportam o protocolo WebSocket Secure (WSS) por padrão. Nenhuma configuração adicional é necessária.
Ao usar listeners TCP, o CLB não fornece suporte integrado ao WebSocket. Configure o WebSocket nos servidores de backend. Os itens de configuração para listeners TCP (algoritmo de agendamento, persistência de sessão, limitação de largura de banda e tempo limite de conexão) não incluem opções relacionadas ao WebSocket.
Ao configurar uma porta de escuta, evite portas vulneráveis, como as portas 25, 135, 139, 444, 445, 5800 e 5900. Essa restrição é imposta pelas redes dos provedores de internet (ISP), não pelo CLB. O console do CLB não bloqueia a configuração dessas portas, mas algumas redes de ISP bloqueiam o tráfego nelas.
Pré-requisitos
-
São necessárias três instâncias ECS: ECS01, ECS02 e ECS03.
As instâncias ECS01 e ECS02 são usadas para implantar a aplicação WebSocket, e a ECS03 é usada para implantar o Redis.
Neste tutorial, todos os servidores executam o CentOS 7.9.
Recomendamos colocar as instâncias ECS01, ECS02 e ECS03 no mesmo grupo de segurança. Se elas estiverem em grupos de segurança diferentes, configure regras que permitam o tráfego nas portas de comunicação necessárias entre os servidores.
É necessário um nome de domínio registrado com registro ICP concluído. Para obter mais informações, consulte Registrar um nome de domínio na Alibaba Cloud e Registro ICP.
Procedimento
Etapa 1: Implantar services
Implante o Redis na instância ECS03 e a aplicação WebSocket nas instâncias ECS01 e ECS02.
Este tópico usa uma sala de bate-papo online simples baseada em Python no CentOS 7.9 para fins de demonstração. Este exemplo serve apenas como referência. Em um ambiente de produção, use sua própria aplicação.
Implantar o Redis na ECS03
Faça logon na instância ECS03.
-
Copie e execute os comandos a seguir para instalar e configurar o Redis.
# Install EPEL (Extra Packages for Enterprise Linux) sudo yum install epel-release -y # Install Redis sudo yum install redis -y # Start and enable the Redis service sudo systemctl start redis sudo systemctl enable redis # Edit the Redis configuration file to allow remote connections sudo sed -i 's/^bind 127.0.0.1$/bind 0.0.0.0/' /etc/redis.conf sudo sed -i 's/^protected-mode yes/protected-mode no/' /etc/redis.conf # Restart the Redis service for the changes to take effect sudo systemctl restart redis # Check the Redis status sudo systemctl status redis -
Se os comandos forem executados sem erros e a saída mostrar que o service do Redis está no estado active (running), a implantação e a configuração foram bem-sucedidas.
● redis.service - Redis persistent key-value database Loaded: loaded (/usr/lib/systemd/system/redis.service; enabled; vendor preset: disabled) Active: active (running) since ... Main PID: 12345 (redis-server) CGroup: /system.slice/redis.service └─12345 /usr/bin/redis-server 0.0.0.0:6379
Implantar o WebSocket na ECS01
Faça logon na instância ECS01.
Execute
sudo pip3 install flask flask-socketio flask-cors redispara instalar as dependências.Execute
vi ECS01_ws.pye pressione a teclaipara entrar no modo de edição.-
Copie e cole o código a seguir:
Pressione a tecla
Esce insira:wqpara salvar as alterações.Execute o comando
sudo python3 ECS01_ws.pypara iniciar o script.-
Quando a seguinte saída for exibida, a aplicação WebSocket terá iniciado na porta 5000.
Server initialized for threading. * Serving Flask app 'ECS01_ws' (lazy loading) * Environment: production WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead. * Debug mode: off * Running on all addresses. WARNING: This is a development server. Do not use it in a production deployment. * Running on http://192.168.*.*:5000/ (Press CTRL+C to quit)Se a aplicação falhar ao iniciar, verifique se a porta já está em uso ou se você copiou os comandos ou o código incorretamente.
● redis.service – Redis persistent key-value database
Loaded: loaded (/usr/lib/systemd/system/redis.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/redis.service.d
└─limit.conf
Active: active (running) since Thu 2xxx xxx xxx xxx CST; 6s ago
Process: 14715 ExecStop=/usr/libexec/redis-shutdown (code=exited, status=0/SUCCESS)
Main PID: 14730 (redis-server)
CGroup: /system.slice/redis.service
└─14730 /usr/bin/redis-server 0.0.0.0:6379
Implantar o WebSocket na ECS02
Faça logon na instância ECS02.
Execute
sudo pip3 install flask flask-socketio flask-cors redispara instalar as dependências.Execute
vi ECS02_ws.pye pressione a teclaipara entrar no modo de edição.-
Copie e cole o código a seguir:
Pressione a tecla
Esce insira:wqpara salvar as alterações.Execute o comando
sudo python3 ECS02_ws.pypara iniciar o script.-
Quando a seguinte saída for exibida, a aplicação WebSocket terá iniciado na porta 5000.
Server initialized for threading. * Serving Flask app 'ECS02_ws' (lazy loading) * Environment: production WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead. * Debug mode: off * Running on all addresses. WARNING: This is a development server. Do not use it in a production deployment. * Running on http://192.168.*.*:5000/ (Press CTRL+C to quit)Se a aplicação falhar ao iniciar, verifique se a porta já está em uso ou se você copiou os comandos ou o código incorretamente.
Etapa 2: Configurar um grupo vServer
Faça logon no console do Classic Load Balancer (CLB).
Na barra de navegação superior, selecione a região onde a instância CLB está implantada.
No painel de navegação à esquerda, escolha Instances. Na página Instances, localize a instância de destino e clique em seu ID.
-
Na aba vServer groups, clique em Create vServer Group. Na página Create vServer Group, configure o parâmetro a seguir. Utilize os valores padrão para os outros parâmetros ou modifique-os conforme necessário. Após concluir a configuração, clique em Create e siga as instruções na tela.
Parâmetro
Descrição
vServer Group Name
Insira RS1 como o nome do grupo vServer.
Na aba vServer groups, localize o grupo vServer criado e clique em Modify na coluna Actions.
Na página Modify vServer Group, clique em Add. Na página Servers, adicione os servidores de backend ECS01 e ECS02. Defina a porta de ambos os servidores como 5000, que é a porta utilizada pela aplicação WebSocket.
Na página Modify vServer Group, selecione os servidores adicionados e clique em Save.
Etapa 3: Configurar um listener HTTP
Faça logon no console do Classic Load Balancer (CLB).
Na barra de navegação superior, selecione a região onde a instância CLB está implantada.
No painel de navegação à esquerda, escolha Instances.
Na página Instances, localize a instância de destino e clique em Configure Listener na coluna Actions.
-
Na página Protocol & Listener, configure os parâmetros a seguir. Utilize os valores padrão para os outros parâmetros ou modifique-os conforme necessário. Após concluir a configuração, clique em Next.
Parâmetro
Descrição
Select Listener Protocol
Selecione HTTP.
Listener Port
Neste exemplo, a porta está definida como 5000.
-
Na página Backend Servers, configure o parâmetro a seguir. Utilize os valores padrão para os outros parâmetros ou modifique-os conforme necessário. Após concluir a configuração, clique em Next.
Parâmetro
Descrição
Server Group
Selecione o grupo vServer que você criou.
Na página Health Check, utilize os valores padrão para os parâmetros ou modifique-os conforme necessário. Em seguida, clique em Next.
Na página Confirm, revise a configuração e clique em Submit para criar o listener.
Etapa 4: Configurar a resolução DNS
Para domínios não registrados na Alibaba Cloud, é necessário primeiro adicionar o domínio ao console do Alibaba Cloud DNS antes de configurar os registros DNS.
Se sua instância CLB for voltada para a rede interna, associe primeiro um endereço Elastic IP (EIP) a ela e crie um registro A que mapeie o nome de domínio para o EIP para habilitar o acesso público.
No painel de navegação à esquerda, escolha .
Na página Instances, selecione a instância de destino e copie seu IP Address.
-
Siga as etapas abaixo para adicionar um registro A:
Faça logon no console do Alibaba Cloud DNS.
Na página Public Zone, localize o nome de domínio de destino e clique em Settings na coluna Actions.
Na página Settings, clique em Add Record.
-
No painel Add Record, configure os parâmetros a seguir. Mantenha os valores padrão para os outros parâmetros ou modifique-os conforme necessário. Em seguida, clique em OK.
Parâmetro
Descrição
Record Type
Selecione A na lista suspensa.
Hostname
O prefixo do seu nome de domínio.
NotaPara um domínio raiz, defina o hostname como @.
Record Value
Insira o endereço IP copiado da instância CLB.
Etapa 5: Verificar o resultado
Prepare dois computadores com endereços IP públicos diferentes. Em cada computador, use um navegador para enviar e visualizar mensagens de bate-papo, a fim de verificar se o CLB entrega mensagens em tempo real via WebSocket.
-
Em um navegador, acesse
http://<your-domain-name>:5000para abrir a aplicação de sala de bate-papo online.A interface Online Chat Room é carregada. A mensagem "You have entered the chat room!" aparece na área de mensagens, indicando que a conexão WebSocket foi estabelecida. A página contém uma área de definição de nome de usuário com um botão Set Username e uma área de envio de mensagens com um botão Send.
Se você abrir as ferramentas de desenvolvedor do navegador, a aba Network mostrará que o navegador está se comunicando usando o protocolo WebSocket.
No painel Network, defina o filtro como
websocket. Uma requisição WebSocket com código de status 101 indica que o upgrade de protocolo foi bem-sucedido. O status da conexão será Pending, o que significa que a conexão persistente WebSocket está estabelecida e ativa. Insira um nome de usuário para o bate-papo e clique em Set Username.
-
Em cada computador, insira várias mensagens de bate-papo e clique em Send para testar a aplicação.
Ambos os navegadores recebem as mensagens em tempo real.
A aplicação Online Chat Room foi implantada com sucesso. A página contém uma caixa de entrada Username e um botão Set Username, uma área de exibição de mensagens e uma caixa de entrada de mensagens com um botão Send na parte inferior. Vários usuários, como User1 e User2, podem conversar em tempo real na sala de bate-papo.
Isso confirma que o uso do CLB com WebSocket possibilita mensagens em tempo real e com alta disponibilidade.
Configuração de WebSocket para listeners TCP
Os listeners TCP realizam apenas encaminhamento de Camada 4 (camada de transporte). O CLB encaminha conexões TCP diretamente para os servidores de backend sem participar do processamento de protocolo da Camada 7 (camada de aplicação). O CLB não fornece upgrade de protocolo WebSocket integrado para listeners TCP. Os services de backend devem implementar o handshake HTTP Upgrade para concluir o upgrade do protocolo WebSocket.
Isso difere dos listeners HTTP e HTTPS. Os listeners HTTP suportam o protocolo WebSocket (WS) por padrão, e os listeners HTTPS suportam o protocolo WebSocket Secure (WSS) por padrão. Nenhuma configuração adicional é necessária para esses tipos de listener.
Etapas de configuração
Para usar um service WebSocket com um listener TCP:
Faça logon no console do Classic Load Balancer (CLB). Localize a instância CLB de destino e clique em Configure Listener na coluna Actions. Defina o protocolo de frontend como TCP e especifique a porta de escuta.
Nos servidores de backend, implante o service WebSocket. O service de backend deve implementar o handshake HTTP Upgrade para concluir o upgrade do protocolo WebSocket. O CLB encaminha fluxos TCP tal como estão e não processa protocolos da Camada 7.
O CLB encaminha todas as conexões TCP recebidas diretamente para os servidores de backend. O servidor de backend lida com o handshake WebSocket e mantém a conexão WebSocket persistente.
Comparação: listeners TCP vs. listeners HTTP e HTTPS
|
Tipo de listener |
Suporte a WebSocket |
Configuração necessária |
|
Listener HTTP |
Suporta WebSocket (WS) por padrão |
Nenhuma configuração adicional necessária |
|
Listener HTTPS |
Suporta WebSocket Secure (WSS) por padrão |
Nenhuma configuração adicional necessária |
|
Listener TCP |
Sem suporte integrado a WebSocket |
O backend deve implementar o handshake HTTP Upgrade |
Casos de uso
Listener HTTP ou HTTPS — Recomendado para aplicações web padrão que usam o protocolo WebSocket. O CLB lida com o upgrade de protocolo automaticamente, o que simplifica a configuração.
Listener TCP — Adequado para cenários que exigem tratamento personalizado de protocolo na camada de aplicação ou quando um único listener precisa suportar múltiplos protocolos da camada de aplicação simultaneamente.
Perguntas frequentes
Como usar o protocolo WebSocket Secure?
O WebSocket Secure é a versão criptografada do protocolo WebSocket.
Os listeners HTTPS suportam o protocolo WebSocket Secure por padrão. Para usar o protocolo WebSocket Secure, selecione HTTPS ao configurar o listener.
Há cobrança pelo uso do WebSocket?
Não há taxas extras pelo uso dos protocolos WebSocket e WebSocket Secure.
Quais regiões suportam o WebSocket?
Todas as regiões que suportam o CLB também suportam WebSocket e WebSocket Secure.
Referências
Este tutorial demonstra a implantação do Redis em uma instância ECS para testes. No entanto, um único servidor Redis representa um potencial ponto único de falha. Para ambientes de produção, recomendamos o uso de Tair para garantir alta disponibilidade. Para obter mais informações, consulte Início rápido do Tair.