Exame do protocolo de sincronização do Couchbase Lite via Wireshark

Durante o curso do desenvolvimento, muitas vezes é útil examinar o que exatamente é enviado pela rede entre as máquinas. Isso ajuda a realizar tarefas como encontrar a origem de um problema ou simplesmente entender a conversa. Muitas vezes, a conversa usa um protocolo bem conhecido, como HTTP. Entretanto, no Couchbase Mobile 2.0 e superior, a conversa ocorre usando um protocolo de sincronização chamado BLIPtransportado via soquete da Web. Você pode pensar que isso torna a conversa totalmente opaca, mas na verdade wireshark é capaz de analisar mensagens BLIP. Vamos dar uma olhada rápida em como fazer isso.

Antes de entrarmos nesse assunto, no entanto, preciso me isentar de algo. As informações aqui são apresentadas apenas para fins educacionais. Você não deve confiar que esse formato será sempre o mesmo. Nós, da Couchbase, não temos nenhum contrato com os consumidores sobre isso, e ele está sujeito a alterações. No entanto, às vezes ainda é bom poder ver o que está acontecendo.

Filtragem no BLIP

Esta publicação pressupõe que você saiba o básico sobre como usar o wireshark. Qualquer versão 3.0.0 ou superior pode ser usada, mas as versões anteriores têm um bug que pode causar uma falha em mensagens compactadas grandes, portanto, recomenda-se a versão 3.2.7+ / 3.0.14+. Você deve estar familiarizado com a forma de iniciar uma captura de rede. Esta postagem começa supondo que você já tenha feito uma. Quando abrirmos sua captura para examinar, você verá algo parecido com a imagem a seguir.

Esta é a visualização que você provavelmente verá quando abrir um novo rastreamento

Isso ocorre porque ainda não definimos nenhum filtro. Todos os pacotes de todos os tipos estão visíveis no momento. Se você observar, perto da parte superior há uma caixa de texto com o texto de dica "Apply a display filter" (Aplicar um filtro de exibição). O BLIP é um formato de pacote compatível, e você pode definir um filtro para mostrar somente mensagens BLIP.

Agora as coisas parecem mais gerenciáveis, mostrando apenas a conversa BLIP.

Uma ressalva a isso é que, como o BLIP usa soquetes da Web, ele não pode ser decodificado se a conversa inteira não estiver presente. Em outras palavras, a solicitação HTTP inicial para o soquete da Web deve estar presente. Por exemplo, se você alterar o filtro para blip || http então você poderá ver a primeira mensagem HTTP nessa conversa.

Observe as duas entradas verdes na parte superior, que mostram uma mensagem HTTP de solicitação/resposta para um soquete da Web.

Detalhes da mensagem

Então, agora que uma conversa BLIP está aqui, o que há em uma mensagem BLIP? Para responder a essa pergunta, vamos examinar o conteúdo de uma mensagem BLIP típica:

O conteúdo de uma mensagem BLIP típica.

De cima para baixo, temos os seguintes itens:

• Número da mensagem - Basicamente, a ID da mensagem que está sendo mencionada. Isso é importante para a próxima seção.
• Sinalizadores de quadro - Algumas informações de metadados sobre a mensagem (Neste exemplo, o corpo está compactado e é urgente. Isso significa que ela será tratada fora de ordem).
• Properties Length (Comprimento das propriedades) - O comprimento das propriedades da mensagem (as propriedades são codificadas como uma entrada de comprimento, seguida pelos dados do comprimento fornecido)
• Propriedades - As propriedades da mensagem (uma coleção de pares de valores-chave)
• Corpo da mensagem - O conteúdo real da mensagem. Ocupa todo o restante da mensagem, exceto os últimos 4 bytes.
• Checksum - Um valor de checksum é gravado para garantir que a mensagem seja recebida na ordem em que foi enviada e que o conteúdo do pacote não tenha sido malformado

Há 6 tipos de mensagens que podem ser enviadas, indicadas pela forma como são marcadas na lista de pacotes:

• MSG - Uma nova mensagem
• RPY - Uma resposta [normal] a uma mensagem recebida
• ERR - Uma resposta de erro a uma mensagem recebida
• ACKMSG - Confirmação de progresso para o recebimento de uma mensagem longa de vários pacotes
• ACKRPY - Confirmação de progresso para receber uma resposta longa de vários pacotes

Seguindo uma conversa

Para fins de acompanhamento de uma determinada conversa, um aspecto importante a ser levado em conta é que ambos os lados podem iniciar uma mensagem. Isso aparecerá na lista de mensagens do wireshark como MSG#{NUM}. A maneira de saber qual lado enviou a mensagem é observar os endereços IP de origem e destino. Por exemplo, em dois diagramas acima, você pode ver MSG#2 como a terceira mensagem da lista. Você também pode ver MSG#2 como a penúltima mensagem da lista. A diferença é que a primeira entrada tem o IP de origem como 192.168.33.1 e o IP de destino como 192.168.33.11, e o último está invertido. Isso indica que a primeira mensagem é uma mensagem que o Couchbase Lite enviou ao Sync Gateway porque, na minha configuração, a instância do Sync Gateway está sendo executada em 192.168.33.11. A segunda é o oposto, uma mensagem que o Sync Gateway enviou ao Couchbase Lite.

Depois de receber uma mensagem, uma das três coisas ocorrerá:

1. A mensagem é recebida, executada e finalizada normalmente. Nesse caso, uma mensagem de resposta será enviada com o mesmo número de mensagem que a mensagem recebida. Por exemplo, MSG#2 receberá um RPY#2 (com os IPs de origem e destino invertidos).
2. A mensagem é recebida, mas não pode ser concluída normalmente. Nesse caso, uma mensagem de erro será enviada com as mesmas condições de #1.
3. A mensagem tem um NãoRepresentação em seus sinalizadores. Nesse caso, nenhuma resposta é enviada.

Usando o exemplo acima, podemos ver que, na lista de mensagens, a mensagem imediatamente após a primeira MSG#2 é RPY#2 e, portanto, é a resposta à mensagem. Da mesma forma, o primeiro MSG#1 tem um ERR#1 resposta, indicando que terminou com um erro. Esse método é aplicável a ambos os lados da conversa, portanto, deve ser fácil rastrear as mensagens de ida e volta em uma determinada conversa BLIP.