WebSocket
Monitorização de WebSocket
O handshake de upgrade, o socket ainda aberto um momento depois, e a primeira mensagem.
Experimenta agora
Uma verificação, de um lugar, agora mesmo, e nada é guardado. Um monitor verifica de todas as localizações onde operamos e confirma uma falha a partir de dois outros continentes antes de alguém ser acordado, algo que uma única verificação não pode mostrar.
Para que serve
O teu chat, o teu dashboard ao vivo, o teu feed de preços, o teu editor colaborativo, o teu lobby de jogo: tudo isso é um WebSocket, e é a parte de um produto que falha enquanto todas as camadas por baixo continuam verdes. A página carrega, a API responde, o certificado está bom, a porta está aberta, e o socket nunca abre.
Ou abre e fecha novamente duzentos milissegundos depois, que do lado do utilizador é um ecrã que para de atualizar silenciosamente e que ninguém reporta como uma falha. Eles fazem refresh, funciona por um minuto, desistem. Por isso isto não para no handshake: observa o socket por um momento depois, da mesma forma que a verificação TCP pode insistir num cumprimento em vez de se satisfazer com uma porta aberta.
E aquele em que as pessoas realmente perdem dinheiro: o feed que está conectado e parou de publicar. Dá-nos uma mensagem para enviar e um padrão que a resposta tem de corresponder, ou apenas um padrão, e um feed silencioso é uma falha em vez de uma linha verde com bom aspeto.
Como cada verificação aqui, corre a partir de Amsterdam, New York, Sydney and Singapore, e uma falha é confirmada a partir de dois outros continentes antes de alguém ser acordado. Como funciona isso.
O que podes configurar
Tudo abaixo está no formulário quando adicionas um, em todos os planos.
- Endereço
- Um endereço ws:// ou wss://, com o caminho. Um host e porta é a verificação TCP, que é uma questão diferente.
- Enviar isto primeiro
- Um frame de texto, enviado assim que o socket abre, para um endpoint que responde em vez de publicar.
- Mensagem esperada
- Uma expressão regular que um frame tem de corresponder. Preenchê-la é o que torna um frame necessário.
- Quanto tempo esperar por ele
- Segundos. Separado do timeout de conexão, porque um feed que publica a cada trinta segundos está saudável e falharia um limite de tempo em forma de handshake.
- Timeout
- Quanto tempo o próprio handshake pode demorar.
- Confirmações
- Quantos outros continentes têm de concordar antes de alguém ser acordado.
Perguntas
Porque não posso simplesmente apontar o monitor HTTPS para isto?
Porque a resposta saudável seria registada como uma falha. Um WebSocket começa como um HTTP GET com Upgrade: websocket e um Sec-WebSocket-Key, e um servidor que responde a um GET simples com 400 ou 426 está a comportar-se exatamente como deve. Um monitor HTTPS vê esse código de estado e reporta-te como offline enquanto tudo funciona perfeitamente.
O que é que a verificação realmente faz?
Completa o handshake de upgrade, o que significa um 101 com o Sec-WebSocket-Accept derivado da chave enviada, e depois mantém o socket por um momento para ver se permanece aberto. Depois desliga. Não mantém uma conexão entre verificações, por isso nada disto parece um cliente para o teu servidor.
O meu feed está silencioso na maior parte do tempo. Isso vai falhar?
Não. Um socket que abre e não diz nada está saudável, a menos que preenchas uma mensagem esperada, porque um feed sem nada para publicar não é um feed quebrado. Preenche isso e as regras mudam de propósito: um frame passa a ser necessário dentro do tempo de espera que definires, que é como apanhas o feed que está conectado e parou.
Qual é a diferença entre 1000 e 1011 num close?
1000 é um encerramento normal e 1011 é o servidor a dizer que encontrou uma condição da qual não conseguiu recuperar, e ambos chegam como um socket que desapareceu. O código de encerramento e a razão estão na falha, em vez de serem simplificados para desconectado, porque enviam quem está a resolver o problema para dois lugares diferentes.
Suportas Socket.IO, SignalR, STOMP ou MQTT?
Não, e dizemos isso em vez de sugerir o contrário. Esses são enquadramentos sobrepostos ao WebSocket, cada um com o seu próprio handshake e a sua própria ideia de namespace, e uma verificação que os falasse pela metade seria pior do que uma que não fala. A verificação bruta ainda te diz que o transporte por baixo deles está ativo.
Verifica o certificado num endereço wss://?
Sim. Uma conexão wss:// é verificada contra o repositório de confiança pública como qualquer outra, por isso um certificado expirado, um autoassinado ou um hostname incompatível falha na verificação. Os dias restantes são uma questão para um monitor de certificado, e vale a pena correr ao lado deste.
Posso verificar um socket na minha própria rede?
Não, e esta é a recusa pela qual menos lamentamos. Um WebSocket para um endereço interno é um túnel bidirecional de longa duração aberto pela nossa infraestrutura num horário, que é uma versão pior de uma falsificação de pedido do lado do servidor do que uma fetch única. O endereço é resolvido imediatamente antes de conectar e um privado é recusado.
O meu cliente reconecta sozinho. Porquê monitorizar o socket também?
Deve, e um cliente sem lógica de retry é o maior problema dos dois, por isso esse trabalho não é desperdiçado. Significa que o teu cliente esconde exatamente o que vale a pena saber. Um socket que aceita uma conexão, mantém-na por trinta segundos e depois a encerra fará com que um cliente que reconecta pareça quase conectado durante horas, enquanto todas as mensagens enviadas nos intervalos desaparecem. Isto conecta, completa o handshake e mantém o socket, por isso um servidor que falha desta forma falha na verificação em vez de ser mascarado pela lógica de retry do outro lado.