Um chat, um painel que se actualiza sozinho, notificações em directo: tudo isso pede uma ligação que fica aberta entre o navegador e o servidor, em vez do pedido e resposta de sempre. Essa ligação chama-se WebSocket. A resposta curta: numa hospedagem partilhada, não conte com ela. As ligações abertas ocupam recursos da conta durante todo o tempo em que alguém está no site, e a conta tem limites de processos. Num VPS funciona bem, com o proxy bem configurado.
O que muda de uma ligação normal
Um pedido HTTP normal dura milissegundos e liberta o servidor. Um WebSocket dura minutos ou horas: cada visitante ligado é uma ligação a ocupar memória e um «lugar» no processo. Dez visitantes são dez ligações abertas ao mesmo tempo, mesmo que ninguém escreva nada. Daí a diferença entre onde cabe e onde não cabe.
|
No cPanel (partilhada) |
Num VPS |
| Ligações abertas |
Ocupam recursos limitados da conta; um servidor de websockets residente choca com o limite de processos. |
Só as limita a memória e o processador do VPS. |
| Quem garante o proxy |
O Passenger. Não temos como prometer que as ligações longas passem de forma estável. |
Você, com o nginx: tem de passar os cabeçalhos de upgrade. |
| Socket.IO |
Pode arrancar por polling (pedidos repetidos) quando o WebSocket não passa. Funciona, mas é um pedido atrás do outro. |
Usa o WebSocket a sério. |
| Recomendação |
Teste com poucos utilizadores; para tempo real a sério, mude. |
O sítio certo. |
Num VPS com nginx, passo a passo
| 2 |
No bloco do nginx, acrescente as linhas que deixam passar a mudança de HTTP para WebSocket:location / {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_read_timeout 3600s;
}O proxy_read_timeout importa: por omissão o nginx fecha uma ligação que fique 60 segundos sem dados, e os websockets inactivos caem. O valor acima é um exemplo.
|
|
| 3 |
No navegador, use wss:// (e não ws://) quando o site é HTTPS, no mesmo domínio. Um site em HTTPS que abra ws:// é bloqueado pelo navegador.
|
|
| 4 |
Recarregue o nginx depois de validar a configuração: sudo nginx -t e sudo systemctl reload nginx.
|
|
| 5 |
Confirme no navegador: nas ferramentas de programador, separador «Rede», filtre por «WS». Uma ligação com o estado «101» é um WebSocket a funcionar.
|
|
Se o Socket.IO «funciona» mas é lento, pode estar a cair para polling sem que ninguém repare: o separador «Rede» mostra pedidos repetidos em vez de uma ligação 101. É sinal de que o WebSocket não está a passar, quase sempre por falta das linhas de upgrade no proxy.
|
|
Várias instâncias da aplicação? Com mais de um processo atrás do proxy, os clientes do Socket.IO precisam de ficar sempre no mesmo processo ou de um adaptador partilhado: a documentação do projecto explica. Comece com um processo. Num VPS não gerido, a manutenção é sua: até onde vai o nosso suporte.
|
|
Precisa de ligações em tempo real? Um VPS dá-lhe o controlo do proxy e dos processos.
Ver os servidores VPS
|
PRODUTO RECOMENDADO Servidor VPS com acesso root Recursos só seus, o sistema que escolher, reinstalação quando quiser. desde 7.560,00 Kz/mês (plano de 3 anos, com cupão) Ver planos |
Português
English
