Teste de carga do WebSocket

Configurando uma solicitação WebSocket

URL

Para abrir uma conexão WebSocket, você é obrigado a inserir a URL do WebSocket do endpoint ou endereço IP da URL do WebSocket que você deseja verificar (os protocolos de wss:// ws:// e criptografados são suportados). Por exemplo, wss://echo.websocket.org/

Para ativar um modo de entrada mais visualmente amigável, clique no interruptor Detalhado na parte superior da seção.

Você pode converter a URL em um valor dinâmico ou parâmetro de contexto aqui. Por exemplo, para alterar dinamicamente a URL de destino.

Enviar dados

Se você precisar transferir dados para o ponto final de destino, no campo Enviar dados, especifique uma mensagem em um formato de sequência ou binário. O Dotcom-Monitor enviará a mensagem para o ponto final do destino usando o protocolo WebSocket e aguardará a resposta.

O Dotcom-Monitor suporta expressões de Razor nas mensagens WebSocket. Para enviar uma sequência que contenha uma expressão razor, insira-a no campo Enviar dados e use o Script prepare para definir o tipo de mensagem para a expressão Razor. Caso contrário, a mensagem será analisada e enviada como texto. Use o seguinte trecho no campo Preparar script para notificar o sistema de que a mensagem deve ser analisada com o mecanismo Razor:

ProcessPostDataByRazor(currentTask);

Além do mecanismo Razor, o Dotcom-Monitor permite alterar dinamicamente os dados do corpo de solicitação usando máscaras de dados. Para saber como usar a sintaxe e máscaras de dados razor em dados enviados e configurar a carga útil de mudança dinâmica, consulte Como alterar dinamicamente a carga útil na solicitação HTTP.

Validação de resposta (validação de conteúdo)

Para validar uma sequência de mensagens recebida do WebSocket, você pode afirmar palavras-chave no cenário de execução de chamadas. O sistema aguardará a resposta do ponto de extremidade de destino e verificará a mensagem recebida para a presença da palavra-chave especificada na cadeia de caracteres. Se a palavra-chave não for detectada nas respostas do soquete, um erro será gerado.

Nos campos Palavra-chave , você pode especificar uma palavra ou frase que deseja pesquisar na mensagem de resposta. Use o texto sem formatação para especificar uma palavra-chave:

Prepare script e poste script

Os campos podem conter código C#, que pode ser usado para solicitações específicas e dados de URL ou para validar ou publicar cabeçalhos personalizados. Consulte o artigo “Use Prepare Script and Post Script” ou entre em contato com suporte técnico para obter mais detalhes sobre o uso.

O cenário dinâmico da execução da chamada WebSocket pode ser especificado no campo Preparar script. O cenário dinâmico pode incluir uma série de operações com dados binários ou de string.

Operações binárias formatadas (msg como Base64 codificada):

• ValidateBinary(string msg) – verifica se uma resposta WebSocket é igual aos dados binários especificados.
• ValidebinaryContains(string msg) – verifica se uma resposta do WebSocket contém dados binários especificados.
• SendBinary (string msg) – envia uma mensagem binária para um WebSocket.

Operações formatadas por texto:

• SendText(string msg) – envia uma sequência de texto para um WebSocket.
• ValidateText(string msg) – verifica se uma resposta de um WebSocket é igual a uma cadeia de caracteres especificada.
• ValidateTextContains(string msg) – verifica se uma resposta WebSocket contém uma cadeia de caracteres especificada.

Nos casos em que qualquer afirmação foi especificada no campo Preparar script, o sistema aguardará a afirmação especificada na resposta e prosseguirá com a execução do script assim que a validação for bem sucedida. Se uma mensagem com a declaração especificada não for recebida e o tempo limite de conclusão da tarefa for atingido, geraremos o erro de validação.

O Dotcom-Monitor permite que você inclua quantas operações forem necessárias no script Preparar. No entanto, se o tempo limite de conclusão da tarefa for atingido, a execução do script será encerrada. O tempo de conclusão da tarefa é contado a partir do início da execução do script.

currentTask.SendText("This is a test");
currentTask.ValidateText("This is a test");

Verificação de SSL/Certificado

A Verificação de Certificado SSL do Secure Socket Layer inclui as seguintes opções de validação:

• Autoridade: verifica se uma cadeia de certificados contém um certificado raiz confiável ou não confiável.
• Nome Comum (CN): valida que um endereço que você navega corresponde ao certificado de endereço ao qual o endereço foi assinado.
• Data: verifica a data de validade do certificado.
• Revogação: valida que a cadeia de confiança do certificado não contém um certificado revogado.
• Uso: verifica uma cadeia de certificados para o uso inadequado de um certificado intermediário.
• Lembrete de expiração em dias: um lembrete que notifica (como um erro) sobre a expiração do certificado.
• Certificado do Cliente: nome do certificado do cliente.

Limite de validação de tempo (em segundos)

Insira o número de segundos que o serviço deve aguardar uma resposta da página da Web antes de encerrar a execução da solicitação e retornar um erro. Se isso for deixado em branco, o tempo limite padrão para uma solicitação será de 60 segundos.

Autenticação Básica

The HTTP authentication protocol is used to allow users to access content on some websites.

The following authentication schemes are available:

• Basic Authentication: This method encodes the username and password in base64 and sends them in the request header. It’s simple but not secure unless used with HTTPS.
• Digest Authentication: This scheme hashes credentials using a nonce (a random value) before sending them over the network, providing better security than Basic Authentication by preventing replay attacks.
• NTLM Authentication: A challenge-response mechanism developed by Microsoft, NTLM is used for securing credentials in Windows environments. It provides strong security by using multiple hashing and challenge-response protocols.

Once provided, login credentials will be passed along with the request header to the web server.

• Username: contains a username for HTTP/S  authentication.
• User Password: contains a password for HTTP/S authentication.

Do not confuse HTTP authentication with other authentication schemes such as Bearer Authentication that involves bearer tokens and OAuth 2.0 that uses access tokens.

Read the articles on Basic Authentication Username and Password and Monitoring OAuth 2.0-based APIs for more information.

Cabeçalhos

A opção permite adicionar quaisquer cabeçalhos personalizados adicionais, se necessário.

• Nome do cabeçalho: especifique o nome do parâmetro, pois ele aparecerá na solicitação.
• Valor: digite o valor associado ao nome do parâmetro.

Opções de DNS

O recurso Opções de DNS permite que os usuários escolham como as solicitações de servidor de nomes de domínio (DNS) são conduzidas durante uma tarefa de monitoramento.

Para especificar o modo de resolução de nomes de host, na seção Modo de Resolução DNS , selecione um dos modos disponíveis. Para obter mais detalhes sobre a configuração do recurso, consulte Opções do modo DNS.

A seção Hosts DNS personalizados permite configurar o mapeamento de endereços IP para nomes de host. A resolução DNS IPv6 e IPv4 é suportada.

Para especificar o mapeamento, insira o endereço IP e o nome do host nos campos correspondentes.

Consulte também: Opções do modo DNS.

Filtro de erros

You can create filters to ignore specific errors that may occur but are not relevant to the purpose of a particular device. When an error matches a configured filter, the system will not generate alerts for that response. For example, DNS-related errors can be ignored if DNS server availability is managed by a third party.

Tips

• To ignore a range of error codes, use a dash (for example, 500–504).
• To ignore several error codes in a specific category, list the codes separated by commas or semicolons (for example, 404;504).

You can find a comprehensive list of supported error codes in the HTTP Status Codes List | HTTP Error Codes Explained article of this wiki.

For example, if 404 errors are expected or not relevant for a specific device, you can filter them out to avoid receiving alerts when those errors occur. The error details will still be available for review in the device reports.