Protocolo de conexión de MongoDB

Nota

Esta especificación del protocolo MongoDB Wire está licenciada bajo una Licencia Creative Commons Atribución-NoComercial-CompartirIgual 3.0 de Estados UnidosNo puede utilizar ni adaptar este material para ningún propósito comercial, como crear una base de datos comercial o una oferta de base de datos como servicio.

Introducción

El protocolo de conexión de MongoDB es un protocolo sencillo de tipo solicitud-respuesta basado en sockets. Los clientes se comunican con el servidor de bases de datos a través de un socket TCP/IP normal.

Socket TCP/IP

Los clientes deben conectarse a la base de datos con un socket TCP/IP normal.

Puerto

El número de puerto predeterminado para mongodLas mongos instancias y 27017 son. El número de puerto para mongod y es configurable y puede mongos variar.

Orden de bytes

Todos los números enteros en el protocolo de conexión de MongoDB utilizan el orden de bytes little-endian, es decir, el byte menos significativo primero.

Tipos y formatos de mensajes

MongoDB utiliza el código de operación OP_MSG tanto para las solicitudes del cliente como para las respuestas de la base de datos. Hay varios formatos de mensaje utilizados en versiones anteriores de MongoDB que han quedado obsoletos en favor de OP_MSG.

Nota

Esta página utiliza un struct tipo C para describir la estructura del mensaje.

Los tipos utilizados en este documento, como int32 y cstring, son los mismos que los definidos en la especificación BSON.

Encabezado de mensaje estándar

En general, cada mensaje consta de un encabezado de mensaje estándar seguido de datos específicos de la solicitud. El encabezado del mensaje estándar está estructurado de la siguiente manera:

struct MsgHeader {
    int32   messageLength; // total message size, including this
    int32   requestID;     // identifier for this message
    int32   responseTo;    // requestID from the original request
                           //   (used in responses from the database)
    int32   opCode;        // message type
}

Campo	Descripción
`messageLength`	El tamaño total del mensaje en bytes. Este total incluye los 4 bytes que contienen la longitud del mensaje.
`requestID`	Identificador generado por el cliente o por la base de datos que identifica de forma exclusiva el mensaje.
`responseTo`	El `requestID` tomado de los mensajes del cliente.
`opCode`	Tipo de mensaje. Consulta Códigos de operación para obtener detalles.

Códigos de operación

MongoDB utiliza estos valores opCode:

Nombre del opcode	Valor	Comment
`OP_COMPRESSED`	2012	Abarca otros códigos de operación mediante compresión
`OP_MSG`	2013	Envía un mensaje con el formato estándar. Se usa tanto para solicitudes de clientes como para respuestas de base de datos.
`OP_REPLY` Deprecated in MongoDB 5.0. Removed in MongoDB 5.1.	1	Responder a una solicitud de un cliente. `responseTo` está configurado.
`OP_UPDATE` Deprecated in MongoDB 5.0. Removed in MongoDB 5.1.	2001	Update document.
`OP_INSERT` Deprecated in MongoDB 5.0. Removed in MongoDB 5.1.	2002	Inserta un nuevo documento.
`RESERVED`	2003	Anteriormente utilizado para OP_GET_BY_OID.
`OP_QUERY` Deprecated in MongoDB 5.0. Removed in MongoDB 5.1.	2004	Realiza un query a una colección.
`OP_GET_MORE` Deprecated in MongoDB 5.0. Removed in MongoDB 5.1.	2005	Obtén más datos de un query. Consulta Cursores.
`OP_DELETE` Deprecated in MongoDB 5.0. Removed in MongoDB 5.1.	2006	Borra documentos.
`OP_KILL_CURSORS` Deprecated in MongoDB 5.0. Removed in MongoDB 5.1.	2007	Notifica a la base de datos que el cliente ha terminado con el cursor.

`OP_COMPRESSED`

Cualquier código de operación puede comprimirse e incluirse en un encabezado OP_COMPRESSED. El mensaje OP_COMPRESSED contiene el mensaje original comprimido del código de operación junto con los metadatos necesarios para procesarlo y descomprimirlo.

El formato del mensaje OP_COMPRESSED es:

struct {
    MsgHeader header;            // standard message header
    int32  originalOpcode;       // value of wrapped opcode
    int32  uncompressedSize;     // size of deflated compressedMessage, excluding MsgHeader
    uint8  compressorId;         // ID of compressor that compressed message
    char    *compressedMessage;  // opcode itself, excluding MsgHeader
}

Campo	Descripción
`MsgHeader`	Encabezado del mensaje, como se describe en Encabezado del mensaje estándar.
`originalOpcode`	Contiene el valor del código de operación incluido.
`uncompressedSize`	El tamaño del `compressedMessage` desinflado, que excluye el `MsgHeader`.
`compressorId`	El ID del compresor que comprimió el mensaje. A continuación, se proporciona una lista de valores de `compressorId`.
`compressedMessage`	El propio código de operación, excluido el `MsgHeader`.

A cada compresor se le asigna un ID de compresor predefinido de la siguiente manera:

compressorId	Valor de protocolo de enlace	Descripción
`0`	noop	El contenido del mensaje no está comprimido. Esto se utiliza para pruebas.
`1`	rápido	El contenido del mensaje se comprime mediante snappy.
`2`	zlib	El contenido del mensaje se comprime mediante zlib.
`3`	zstd	El contenido del mensaje se comprime mediante zstd.
`4-255`	reservado	Reservado para uso futuro.

`OP_MSG`

OP_MSG es un formato de mensaje extensible que se utiliza para codificar tanto las solicitudes del cliente como las respuestas del servidor en la conexión.

OP_MSG tiene el siguiente formato:

OP_MSG {
    MsgHeader header;           // standard message header
    uint32 flagBits;            // message flags
    Sections[] sections;        // data sections
    optional<uint32> checksum;  // optional CRC-32C checksum
}

Campo	Descripción
`header`	Encabezado de mensaje estándar, como se describe en Encabezado de mensaje estándar.
`flagBits`	Una máscara de bits enteros que contiene marcas de mensajes, como se describe en Bits de marca.
`sections`	Secciones del cuerpo del mensaje, como se describen en Secciones.
`checksum`	Una suma de verificación CRC-32C opcional, como se describe en Suma de verificación.

Bits de marca

El número entero flagBits es una máscara de bits que codifica marcas para modificar el formato y el comportamiento de OP_MSG.

Los primeros 16 bits (0-15) son obligatorios y los analizadores DEBEN mostrar un error si se establece un bit desconocido.

Los últimos 16 bits (16 a 31) son opcionales y los analizadores DEBEN ignorar cualquier bit de conjunto desconocido. Los proxies y otros reenviadores de mensajes DEBEN borrar cualquier bit opcional desconocido antes de reenviar los mensajes.

Bit	Nombre	Solicitud	Respuesta	Descripción
0	`checksumPresent`	✓	✓	El mensaje termina con 4 bytes que contienen una suma de verificación CRC-32C [2]. Consulta Suma de verificación para obtener detalles.
1	`moreToCome`	✓	✓	Se enviará otro mensaje después de este sin que el receptor realice otra acción. El receptor NO DEBE enviar otro mensaje hasta recibir uno con `moreToCome` establecido en 0, ya que los envíos pueden bloquearse y generar un bloqueo. Las solicitudes con el bit de `moreToCome` activado no recibirán respuesta. Las respuestas solo tendrán esta configuración ante las solicitudes con el conjunto de bits `exhaustAllowed`.
16	`exhaustAllowed`	✓		El cliente está preparado para varias respuestas a esta solicitud con el bit `moreToCome`. El servidor nunca producirá respuestas con el bit de `moreToCome` activado a menos que la solicitud tenga ese bit activado. Esto garantiza que se envíen varias respuestas solo cuando la capa de red del solicitante esté preparada para recibirlas.

Secciones

Un mensaje OP_MSG contiene una o varias secciones. Cada sección comienza con un byte kind que indica su tipo. Todo lo que viene después del byte kind constituye la carga útil de la sección.

Los tipos de secciones disponibles son los siguientes.

Tipo 0: Cuerpo

Una sección del cuerpo se codifica como un único objeto BSON. El tamaño en el objeto BSON también sirve como tamaño de la sección. Este tipo de sección es el cuerpo estándar de solicitud y respuesta de comandos.

Todos los campos de nivel superior DEBEN tener un nombre único.

Tipo 1: Secuencia de documentos

Tipo	Descripción
int32	Tamaño de la sección en bytes.
String C	Identificador de secuencia de documento. En todos los comandos actuales, este campo es el campo (posiblemente anidado) que está reemplazando de la sección del cuerpo. Este campo NO DEBE existir también en la sección del cuerpo.
Cero o más objetos BSON	Los objetos se secuencian de forma consecutiva sin separadores. Cada objeto está limitado a los `maxBSONObjectSize` del servidor. La combinación de todos los objetos no se limita a `maxBSONObjSize`. La secuencia del documento finaliza una vez que se consumen `size` bytes. Los analizadores PUEDEN optar por fusionar estos objetos en el cuerpo como un arreglo en la ruta especificada por el identificador de secuencia al convertirlos en objetos de nivel de lenguaje.

Kind 2

Esta sección se utiliza para fines internos.

suma de verificación

Cada mensaje PUEDE terminar con una suma de verificación CRC-32C [2] que cubra todos los bytes del mensaje excepto la propia suma de verificación.

Si no usas conexiones TLS/SSL, las instancias de mongod y las instancias de mongos intercambian mensajes con sumas de verificación.

Si usas conexiones TLS/SSL, las instancias de mongod y las instancias de mongos omiten la suma de verificación.

Los drivers y los binarios más antiguos ignorarán la suma de verificación si se presentan con mensajes que contengan dicha suma.

La presencia de una suma de verificación se indica con el bit de marca checksumPresent.

Códigos de operación heredados

A partir de MongoDB 5.1, estos códigos de operación se eliminan en favor de OP_MSG:

OP_DELETE
OP_GET_MORE
OP_INSERT
OP_KILL_CURSORS
OP_QUERY [1]
OP_REPLY
OP_UPDATE

Si estás ejecutando una versión anterior de MongoDB y necesitas información detallada sobre los códigos de operación anteriores, consulta Códigos de operación heredados.

Notas al pie

[1]	MongoDB 5.1 remueve el soporte para ambas operaciones de búsqueda `OP_QUERY` y comandos `OP_QUERY`. Como excepción, `OP_QUERY` sigue siendo compatible para ejecutar los comandos `hello` y `isMaster` como parte del protocolo de enlace de conexión.

[2]	(,1 2) 32bits CRC calculado con el polinomio de Castagnoli como se describe en https://tools.ietf.org/html/rfc4960#page-.140

Volver

MongoDB Database Tools

Códigos de operación heredados