Network protocol: detailed explanation of memcached binary protocol

Introduction

The text protocol of memcached was mentioned earlier. Although the text protocol looks very simple, the client usually chooses a more efficient binary protocol.

The essence of the binary protocol is the same as the text protocol, but they are expressed differently. This article will detail the implementation details of the binary protocol in memcached.

Memcached protocol package

For memcached request packets and response packets, except for the difference in the request header, the other formats are the same.

So both requests and responses to memcached can be represented in the same package format:

The first 24 bytes are the header part, and the next is the extra data on the command line, the key and value in memcached.

As mentioned above, the difference between the request packet and the response packet is the header. The following is the definition of the request packet and the response packet:

Request header:

Response header:

The meaning of each field in the packet header is as follows:

• Magic: Magic number, used to distinguish whether the header is a request header or a response header

If it is a request, then the corresponding Magic= 0x80, if it is a response, then the corresponding Magic= 0x81.

In the original design, the Magic should correspond to the version of the protocol. When the version is upgraded, the corresponding Magic should also be adjusted accordingly. But so far, the magic value of the binary protocol has not changed.

• Opcode: operator, that is, the corresponding command

There are the following operators in the memcached protocol:

Those with an asterisk indicate that the order is undecided and may be revised in the future.

A command ending in Q indicates that the command is a quiet version that ignores uninteresting return data.

• Key length: the length of the key
• Status: the status of the request response response

The values of response are as follows:

• Extras length: length of command extras
• Data type: reserved field

data type is a reserved field and currently only has a fixed value: 0x00.

• vbucket id: virtual bucket corresponding to the command
• Total body length: total length of extra + key + value
• Opaque: A data generated by the request will be returned intact in the corresponding response
• CAS: a unique token for data

Example of memcached command

In order to better understand the binary protocol of memcached, let's take a few commonly used commands as examples to see the specific request and response process of memcached.

The most commonly used is the get request, which is used to request the value corresponding to a key to the server.

If the client now wants to get a key=hello data from the server, the requested package is as follows:

Where Magic=0x80, Opcode=0x00,Key length=0x0005,Total body=0x00000005,Key="Hello"

If there is a corresponding key value on the server side, the following data packet will be returned:

We should pay attention to the following fields that are different from the request value:

Among them, Magic=0x81 indicates that this is a response, because this is a response, so the corresponding Key length=0x0000.

In addition, the response contains the Extra length and Extras Flags that do not exist in the get request, where their values are 0x04 and 0xdeadbeef respectively, indicating that the Extra length is 4 bytes, and its value is 0xdeadbeef.

So where does this Extras Flags value come from? If you compare the text protocol mentioned earlier, you can know that the Extras Flags are passed in when the key value is set, and the Flags will be stored on the server side and returned in the get request.

Finally, the response contains the value "World" to be returned.

If the server does not have the value of this key, the corresponding return packet may be as follows:

Among them, Status=0x0001, indicating that it is an abnormal return.

The corresponding value is: "Not found".

I also mentioned a command line version ending with Q, such as getQ. The difference between it and get is that getQ will also put the requested key in the response package and return:

Because the last value contains the key, the Key length here is valuable, and it is the length of the key = 0x0005.

The final return data part contains two parts, namely Key="Hello", value="World".

Summarize

Above, we introduced the basic format of the memcached binary protocol, and illustrated the specific use of the get request and the content of the package. Armed with this knowledge, we can develop a client that supports the memcached two-net protocol.

For more information, please refer to http://www.flydean.com/24-memcached-binary-protocol/

The most popular interpretation, the most profound dry goods, the most concise tutorial, many you do not know

Welcome to pay attention to my official account: "Program those things", understand technology, understand you better!