Examen del protocolo de sincronización de Couchbase Lite mediante Wireshark

Durante el desarrollo, a menudo resulta útil examinar qué se envía exactamente por la red entre las máquinas. Esto ayuda a realizar tareas como encontrar el origen de un problema o simplemente entender la conversación. A menudo la conversación usa un protocolo bien conocido como HTTP. Sin embargo, para Couchbase Mobile 2.0 y superior, la conversación tiene lugar usando un protocolo de sincronización llamado BLIPtransportado a través de un socket web. Se podría pensar que esto hace que la conversación sea totalmente opaca, pero en realidad wireshark es capaz de analizar los mensajes BLIP. Veamos rápidamente cómo hacerlo.

Sin embargo, antes de entrar en materia, debo advertirle de algo. Esta información se presenta con fines puramente educativos. No debes confiar en que este formato sea siempre el mismo. En Couchbase no tenemos ningún contrato con los consumidores al respecto, y está sujeto a cambios. Sin embargo, a veces es bueno ser capaz de ver lo que está pasando.

Filtrado en BLIP

Este post asumirá que usted sabe lo básico de cómo utilizar wireshark. Se puede utilizar cualquier versión 3.0.0 o superior, pero las versiones anteriores tienen un error que puede causar un fallo en los mensajes comprimidos de gran tamaño por lo que se recomienda 3.2.7+ / 3.0.14+. Usted debe estar familiarizado con la forma de iniciar una captura de red. Este post comienza asumiendo que ya has hecho una. Cuando abrimos tu captura para examinarla, puedes ver algo como la siguiente imagen.

Esta es la vista que probablemente verá cuando abra una nueva traza

Esto se debe a que aún no hemos establecido ningún filtro. Todos los paquetes de todos los tipos están visibles. Si te fijas, cerca de la parte superior hay un cuadro de texto con la sugerencia "Aplicar un filtro de visualización". BLIP es un formato de paquete soportado, y puedes establecer un filtro para mostrar sólo mensajes BLIP.

Ahora las cosas parecen más manejables, mostrando sólo la conversación BLIP.

Una advertencia a esto es que como BLIP usa web sockets, no puede ser decodificado si la conversación completa no está presente. En otras palabras, la petición HTTP inicial para el socket web debe estar presente. Por ejemplo, si cambias el filtro a blip || http entonces podrás ver el primer mensaje HTTP de esta conversación.

Fíjate en las dos entradas verdes de la parte superior, que muestran un mensaje HTTP de solicitud/respuesta para un socket web.

Detalles del mensaje

Ahora que ya existe una conversación BLIP, ¿qué contiene un mensaje BLIP? Para responder a esta pregunta, examinemos el contenido de un mensaje BLIP típico:

Contenido de un mensaje BLIP típico.

De arriba a abajo tenemos los siguientes artículos:

• Número de mensaje - Básicamente el ID del mensaje al que se hace referencia. Esto es importante para la siguiente sección.
• Frame Flags - Alguna información de metadatos sobre el mensaje (En este ejemplo, el cuerpo está comprimido y es urgente. Esto significa que se tratará fuera de orden).
• Longitud de las propiedades - Longitud de las propiedades del mensaje (Las propiedades se codifican como una entrada de longitud, seguida de los datos de la longitud dada)
• Propiedades - Las propiedades del mensaje (Una colección de pares clave-valor)
• Cuerpo del mensaje - Es el contenido real del mensaje. Ocupa todo el resto del mensaje, excepto los 4 últimos bytes.
• Suma de comprobación: se escribe un valor de suma de comprobación para garantizar que el mensaje se recibe en el orden en que se envió y que el contenido del paquete no ha sido malformado.

Hay 6 tipos de mensajes que se pueden enviar, indicados por la forma en que están marcados en la lista de paquetes:

• MSG - Un nuevo mensaje
• RPY - Respuesta [normal] a un mensaje recibido
• ERR - Respuesta de error a un mensaje recibido
• ACKMSG - Acuse de recibo de un mensaje multipaquete largo
• ACKRPY - Acuse de recibo de progreso para recibir una respuesta multipaquete larga

Tras una conversación

A efectos de seguir una conversación determinada, algo importante a tener en cuenta es que ambas partes pueden iniciar un mensaje. Esto aparecerá en la lista de mensajes en wireshark como MSG#{NUM}. La forma de saber qué lado envió el mensaje es mirar las direcciones IP de origen y destino. Por ejemplo, dos diagramas más arriba se puede ver MSG#2 como tercer mensaje de la lista. También puede ver MSG#2 como el penúltimo mensaje de la lista. La diferencia es que la primera entrada tiene la IP de origen como 192.168.33.1 y la IP de destino como 192.168.33.11, y esta última está invertida. Esto indica que el primer mensaje es un mensaje que Couchbase Lite envió a Sync Gateway porque en mi configuración la instancia de Sync Gateway está corriendo en 192.168.33.11. El segundo es lo contrario, un mensaje que Sync Gateway envió a Couchbase Lite.

Tras recibir un mensaje ocurrirá una de estas tres cosas:

1. El mensaje se recibe, se ejecuta y finaliza normalmente. En este caso, se enviará un mensaje de respuesta con el mismo número de mensaje que el recibido. Así, por ejemplo MSG#2 obtendrá un RPY#2 (con las IP de origen y destino invertidas).
2. El mensaje se recibe, pero no puede completarse normalmente. En este caso, se enviará un mensaje de error con las mismas condiciones que #1.
3. El mensaje tiene un NoReply en sus banderas. En este caso, no se envía ninguna respuesta.

Utilizando lo anterior, podemos ver que en la lista de mensajes, el mensaje que sigue inmediatamente al primero MSG#2 es RPY#2 y, por tanto, es la respuesta al mensaje. Del mismo modo, el primer MSG#1 tiene un ERR#1 respuesta, indicando que finalizó con un error. Este método es aplicable a ambos lados de la conversación, por lo que debería ser fácil rastrear los mensajes de ida y vuelta en una determinada conversación BLIP.