A gRPC traffic analysis method, device, equipment and medium

Abstract

The application relates to the computer technical field, and in particular to a gRPC traffic analysis method and device, equipment and medium. In the method, a service message from a client is received, and the service message is intercepted based on the byte code of the service message in the case that the service message exists gRPC traffic, wherein the byte code is obtained by performing byte code encoding on the service message according to a preset encoding rule, and the intercepted service message is analyzed layer by layer based on a pre-configured rule set, wherein the rule set contains multiple rules, and each rule has a corresponding relationship with the header field of each layer in the service message. Compared with the prior art, the above scheme can improve the efficiency of identifying and analyzing gRPC traffic by determining whether the service message exists gRPC traffic through the byte code obtained by the preset encoding rule.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a gRPC traffic parsing method, apparatus, device and medium. Background Technology

[0002] gRPC is a high-performance, general-purpose, open-source RPC framework developed by Google. Primarily designed for mobile application development and based on the HTTP / 2 protocol standard, it also supports most popular programming languages. However, because gRPC is a binary protocol, and binary protocols are often difficult to read, achieving readability in some technical scenarios is complex. It cannot be directly parsed using existing UNIX tools. Therefore, improving the efficiency of identifying and parsing gRPC traffic is a problem that needs to be solved. Summary of the Invention

[0003] This application provides a gRPC traffic parsing method, apparatus, device, and medium to improve the parsing efficiency of identifying and parsing the gRPC protocol.

[0004] In a first aspect, embodiments of this application provide a gRPC traffic parsing method, including:

[0005] Receive business messages from the client;

[0006] If gRPC traffic is detected in a business message based on its bytecode, the business message is intercepted. The bytecode is obtained by the client encoding the business message according to a preset encoding rule.

[0007] The intercepted business messages are parsed layer by layer based on a pre-configured set of rules. The set of rules contains multiple rules, and each rule corresponds to a header field of each layer in the business message.

[0008] Compared to the problem of low parsing efficiency caused by the inability to directly parse business messages using existing UNIX tools in the prior art, the method of determining whether there is gRPC traffic in the business message by obtaining bytecode through preset encoding rules in this application can improve the efficiency of identifying and parsing gRPC traffic.

[0009] Optionally, business messages are parsed layer by layer based on a pre-configured set of rules, specifically including:

[0010] The system performs packet parsing, service parsing, interface parsing, and data content parsing on business messages based on a pre-configured set of rules.

[0011] The above method describes the various levels of the business message when parsing the business message layer by layer based on a pre-configured set of rules in the embodiments of this application.

[0012] Optionally, the intercepted business messages are parsed layer by layer based on a pre-configured set of rules, specifically including:

[0013] Based on the correspondence between the header fields of each layer in the business message and the rules, the rules for parsing the business message are determined from the rule set;

[0014] The business messages are parsed layer by layer according to the rules for parsing business messages.

[0015] The above method provides a more detailed description of the method in this application for parsing intercepted business messages layer by layer based on a pre-configured set of rules.

[0016] Optionally, based on the correspondence between the header fields of each layer in the business message and the rules, the rules for parsing the business message are determined from the rule set, specifically including:

[0017] The rules for package parsing are determined from the rule set based on the package field;

[0018] The rules for service parsing are determined from the rule set based on the service field;

[0019] The rules for interface parsing are determined from the rule set based on the RPC field;

[0020] The rules for parsing data content are determined from the set of rules based on object fields.

[0021] The above method describes in more detail the method of determining the rules for parsing business messages from the rule set based on the correspondence between the header fields of each layer in the business message and the rules in the embodiments of this application.

[0022] Optionally, if the bytecode of the business message indicates the presence of gRPC traffic, the business message can be intercepted, specifically including:

[0023] Pass business messages to the kernel-mode eBPF module;

[0024] If the eBPF module determines that the business message contains gRPC traffic based on the bytecode of the business message, it will intercept the business message.

[0025] The above method utilizes the efficient Extended Packet Filter (eBPF) technology to identify and parse the gRPC protocol at the Linux kernel level, eliminating the need for reassembling protocol packets at the user level. This significantly improves the efficiency of identifying and parsing gRPC traffic. Furthermore, eBPF, based on the Linux kernel, is a kernel-level operating system technology. Because eBPF supports direct data processing in kernel mode, it reduces data copying between user and kernel modes, thus lowering application overhead.

[0026] Secondly, an embodiment of this application provides a gRPC traffic parsing apparatus, comprising:

[0027] The send / receive module is used to receive business messages from the client.

[0028] The processing module is used to intercept business messages when it is determined that there is gRPC traffic in the business message based on the bytecode of the business message. The bytecode is obtained by the client encoding the business message according to the preset encoding rules.

[0029] The parsing module is used to parse the intercepted business messages layer by layer based on a pre-configured set of rules. The set of rules contains multiple rules, and each rule corresponds to a header field of each layer in the business message.

[0030] Optionally, business messages are parsed layer by layer based on a pre-configured set of rules. The parsing module is specifically used for:

[0031] The system performs packet parsing, service parsing, interface parsing, and data content parsing on business messages based on a pre-configured set of rules.

[0032] Optionally, the intercepted business messages are parsed layer by layer based on a pre-configured set of rules. The parsing module is specifically used for:

[0033] Based on the correspondence between the header fields of each layer in the business message and the rules, the rules for parsing the business message are determined from the rule set;

[0034] The business messages are parsed layer by layer according to the rules for parsing business messages.

[0035] Optionally, based on the correspondence between the header fields of each layer in the business message and the rules, the rules for parsing the business message are determined from the rule set. The parsing module is specifically used for:

[0036] The rules for package parsing are determined from the rule set based on the package field;

[0037] The rules for service parsing are determined from the rule set based on the service field;

[0038] The rules for interface parsing are determined from the rule set based on the RPC field;

[0039] The rules for parsing data content are determined from the set of rules based on object fields.

[0040] Optionally, if the bytecode of the business message indicates the presence of gRPC traffic, the business message is intercepted. The processing module is specifically used for:

[0041] Pass business messages to the kernel-mode eBPF module;

[0042] If the eBPF module determines that the business message contains gRPC traffic based on the bytecode of the business message, it will intercept the business message.

[0043] Thirdly, embodiments of this application provide an electronic device, including:

[0044] processor;

[0045] Memory used to store processor-executable instructions;

[0046] The processor is configured to execute instructions to implement the gRPC traffic parsing method as described in any of the first aspects above.

[0047] Fourthly, embodiments of this application provide a computer-readable storage medium that, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform the gRPC traffic parsing method as described in any of the first aspects above.

[0048] Fifthly, embodiments of this application provide a computer program product, including a computer program that is executed by a processor to implement the gRPC traffic parsing method as described in any of the first aspects above.

[0049] The technical effects of any of the implementation methods in aspects two through five can be found in the technical effects of the corresponding implementation method in aspect one, and will not be repeated here. Attached Figure Description

[0050] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0051] Figure 1 A schematic diagram illustrating an application scenario of an optional gRPC traffic parsing method provided in this application embodiment;

[0052] Figure 2 A flowchart of a gRPC traffic parsing method provided in this application embodiment;

[0053] Figure 3 A schematic diagram of a business message provided in an embodiment of this application;

[0054] Figure 4 A flowchart of a gRPC traffic parsing method provided in this application embodiment;

[0055] Figure 5A schematic diagram of a gRPC traffic parsing device provided for an embodiment of this application;

[0056] Figure 6 A schematic diagram of another gRPC traffic parsing device provided for an embodiment of this application;

[0057] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0058] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0059] The application scenarios described in this application are for the purpose of more clearly illustrating the technical solutions of this application, and do not constitute a limitation on the technical solutions provided in this application. Those skilled in the art will understand that with the emergence of new application scenarios, the technical solutions provided in this application are also applicable to similar technical problems. In the description of this application, unless otherwise stated, "multiple" means two or more.

[0060] Extended Berkeley Packet Filter (eBPF) has been regarded as a revolutionary technology in the Linux operating system kernel in recent years. It allows developers to dynamically load their own sandboxed programs into the Linux kernel in real time without modifying the kernel source code. Furthermore, user-space programs can exchange data with eBPF programs in the kernel in real time through system calls and data structures (bpf map) in the kernel.

[0061] gRPC is a high-performance, general-purpose, open-source Remote Procedure Call (RPC) framework developed by Google. It is primarily designed for mobile application development and is based on the Hypertext Transfer Protocol version 2 (HTTP / 2) standard. It also supports most popular programming languages, such as JavaScript Object Notation (JSON) and Extensible Markup Language (XML), but with higher performance for data exchange.

[0062] gRPC enables streaming. Different messages within the same gRPC request can share HTTP headers. However, for different messages sharing HTTP headers, each message needs a separate five-byte prefix to indicate compression and length information. Because of these five bytes, regardless of whether the data storage format is Protobuf or JSON, gRPC traffic is a binary protocol. Therefore, commonly used text tools under UNIX cannot handle gRPC communication content well.

[0063] Because there are no readily available parsing tools for binary protocols, and binary protocol parsing is complex—binary protocols have poor readability, and existing technologies for parsing binary protocols are complex—it is necessary to first acquire the binary stream, which may require packet decomposition and reassembly to obtain the binary data. Then, according to the protocol, command words and data fields are parsed one by one. Furthermore, traditional traffic acquisition methods that store data in buffers and then transmit it to user space for parsing are relatively slow. Therefore, improving the efficiency of parsing the gRPC protocol is essential.

[0064] To address the aforementioned issues, this application provides a gRPC traffic parsing method that receives business messages from a client. If the presence of gRPC traffic in the business message is determined based on its bytecode, the business message is intercepted. The bytecode is obtained by the client encoding the business message according to preset encoding rules. The intercepted business message is parsed layer by layer based on a pre-configured set of rules. The rule set contains multiple rules, each corresponding to a header field at each level of the business message.

[0065] This application embodiment allows the client to send business messages to the server, and the server to perform gRPC traffic parsing.

[0066] like Figure 1 As shown in the figure, an application scenario diagram of an optional gRPC traffic parsing method according to an embodiment of this application is illustrated, including a server 100 and a terminal 101. The server 100 and the terminal 101 can be connected through a network to realize the gRPC traffic parsing method of this application.

[0067] Users can interact with terminal 101 via a network using server 100, such as receiving or sending messages. Various client applications can be installed on terminal 101, such as programming applications, web browser applications, and search applications. Terminal 101 can be various electronic devices with a display screen that support web browsing, including but not limited to smartphones, tablets, desktop computers, etc.

[0068] Server 100 receives business messages from clients. If the presence of gRPC traffic in the business message is determined based on its bytecode, the server intercepts the message. The bytecode is obtained by the client encoding the business message according to preset encoding rules. The intercepted business message is then parsed layer by layer based on a pre-configured set of rules. Each rule set contains multiple rules, and each rule corresponds to a header field in each layer of the business message. Server 100 can be implemented as a standalone server or a server cluster consisting of multiple servers.

[0069] like Figure 2 As shown in the flowchart of a gRPC traffic parsing method provided in this application embodiment, it may specifically include the following steps:

[0070] Step S201: Receive a business message from the client;

[0071] Optionally, when a user submits a business request, the client converts at least one business request into binary data to obtain a business message. The client then encodes the resulting business message into bytecode according to a preset encoding rule, producing a business message containing bytecode. This bytecode-containing business message is then sent to the server, where gRPC traffic parsing is performed.

[0072] For any given business request, this application embodiment generates the corresponding business message according to the following method:

[0073] For example, a business client can receive submitted business requests. Serializing business requests facilitates the transmission of business messages between the client and server. The message loader can store the business fields from the request in a business object database and serialize them. The message encoder selects the message corresponding to the business request and performs message serialization. If the business message contains gRPC traffic, the message encoder compiles the business message using the gRPC compiler. The code generator encodes the business message into bytecode according to preset encoding rules, obtaining the bytecode of the business message. In other words, the code generator can compile the binary data of the business message into system-supported bytecode using the compiler. The business client calls the gRPC client program file (stub) to send gRPC messages, transmitting the aforementioned business message, including the bytecode, to the server through a long-lived connection.

[0074] Optionally, to facilitate subsequent data analysis, the message loader can also deserialize the business fields and store them in the business object database.

[0075] It is understood that the preset encoding rules in the embodiments of this application may be pre-set by those skilled in the art. Those skilled in the art may also modify the above-mentioned preset encoding rules according to specific application scenarios. For example, the client can obtain socket code by bytecode encoding the business message according to the preset encoding rules. As another example, the client can obtain BPF code by bytecode encoding the business message according to the preset encoding rules. The serialization processing operation specifically uses a serialization platform to serialize the business request; no specific limitation is made to the serialization platform.

[0076] After the client sends at least one business message to the server, the server receives the business message.

[0077] In one possible scenario, the server can also receive business messages from the client through an external system. The external system then forwards the business messages to the protocol parser on the server.

[0078] Step S202: If the business message contains gRPC traffic based on the bytecode of the business message, intercept the business message.

[0079] Among them, bytecode is obtained by the client encoding the business message into bytecode according to preset encoding rules.

[0080] Compared to the problem of low parsing efficiency caused by the inability to directly parse business messages using existing UNIX tools in the prior art, the method of determining whether there is gRPC traffic in the business message by obtaining bytecode through preset encoding rules in this application can improve the efficiency of identifying and parsing gRPC traffic.

[0081] In one alternative embodiment, the server can load the generated BPF code into an eBPF module located in the Linux kernel space via a bytecode loader. The eBPF module, based on the bytecode of the business message, intercepts the message if it determines that gRPC traffic exists.

[0082] In the above methods, eBPF supports direct data processing in kernel mode, such as decoding and generating visualization charts. This embodiment employs extended packet filtering technology to intercept and collect gRPC protocol data. By using the eBPF module to determine whether gRPC traffic exists in the service message and thus whether to intercept the message, data copying between user mode and kernel mode can be reduced, which helps to reduce application overhead and save computing resources.

[0083] Step S203: Parse the intercepted business messages layer by layer based on the pre-configured rule set.

[0084] The rule set contains multiple rules, and each rule corresponds to a header field at each level in the business message.

[0085] In one optional embodiment, the server can determine the rules for parsing the business message from a rule set based on the correspondence between the header fields of each layer in the business message and the rules. The business message is then parsed layer by layer according to the rules for parsing the business message. Specifically, the business message is parsed based on a pre-configured rule set, including packet parsing, service parsing, interface parsing, and data content parsing.

[0086] For example, packet parsing determines the rules from the rule set based on the package field in the header of the proto (service design message file). Service parsing determines the rules from the rule set based on the service field in the proto file. Interface parsing determines the rules from the rule set based on the Remote Procedure Call (RPC) field in the proto file. Data content parsing determines the rules from the rule set based on the object fields of the business layer.

[0087] For example, based on their own business needs, users may determine the execution command for parsing business messages as follows:

[0088]

[0089]

[0090] like Figure 3 As shown in the figure, this application embodiment provides a schematic diagram of a business message. Figure 3 Business messages are transmitted via HTTP / 2. These messages include gRPC traffic. Because the data description language (ProtoBuf) predefines the names and order of transmitted fields, the transmission structure only needs to sequentially record the type label and binary value of each field. The gRPC traffic includes header, service, message, and data fields. Packet parsing determines the parsing rules from the rule set based on the package field in the proto (service design message file) header. Service parsing determines the parsing rules from the rule set based on the service field in the proto file. Interface parsing determines the parsing rules from the rule set based on the Remote Procedure Call (RPC) field in the proto file. Data content parsing determines the parsing rules from the rule set based on the object fields of the business layer.

[0091] In one optional embodiment, the server can determine the rules for parsing the business message from the rule set based on the correspondence between the header fields of each layer in the business message and the rules, according to the outermost layers in the Proto file. The server then parses the business message layer by layer according to these rules.

[0092] For example, the server can parse business messages layer by layer in the order of packet parsing, service parsing, interface parsing, and data content parsing.

[0093] Optionally, the embodiments of this application can be applied to various application scenarios. For example, in the Kubernetes platform, RPC can be used in the container runtime interface to manage resource objects such as processes (Pods), containers, and images running in the cluster. Management commands issued to the application software (Kubernetes) platform can be monitored, audited, or visualized.

[0094] The following is about Figure 2 The following examples illustrate the implementation:

[0095] Business clients can submit business requests. The message loader stores the business fields from the request in the business object database and serializes these fields. The message encoding processor selects the corresponding message and performs message serialization. The client encodes the business message into bytecode according to preset encoding rules, obtaining the bytecode, i.e., BPF code. The client calls the gRPC client program file (stub) to send gRPC messages through a long connection established with the server, sending the aforementioned business message, including the bytecode, to the server. The external system connected to the server receives the business message from the client and submits the gRPC protocol parsing request to the protocol parser. The bytecode loader loads the generated BPF code into the eBPF attachment module located in the Linux kernel. When the eBPF module detects the corresponding gRPC traffic, it triggers message interception and stores the intercepted message in the decoder. Rules for packet parsing are determined from the rule set based on the package field. Rules for service parsing are determined from the rule set based on the service field. Rules for interface parsing are determined from the rule set based on the rpc field. Rules for data content parsing are determined from the rule set based on the object field. According to the rules for parsing business messages, the business messages are parsed layer by layer in the order of packet parsing, service parsing, interface parsing, and data content parsing.

[0096] like Figure 4 As shown in the figure, this application provides an overall flowchart of a gRPC traffic parsing method.

[0097] Step S401: Receive a business message from the client;

[0098] Step S402: If gRPC traffic is found in the business message based on the bytecode of the business message, the business message is intercepted. The bytecode is obtained by the client encoding the business message according to the preset encoding rules.

[0099] Step S403: Determine the rules for package parsing from the rule set based on the package field;

[0100] Step S404: Determine the rules for service parsing from the rule set based on the service field;

[0101] Step S405: Determine the rules for interface parsing from the rule set based on the RPC field;

[0102] Step S406: Determine the rules for parsing data content from the rule set based on the object field;

[0103] Step S407: According to the rules for parsing business messages, parse the business messages layer by layer in the order of packet parsing, service parsing, interface parsing, and data content parsing.

[0104] This application provides an apparatus for gRPC traffic parsing, such as... Figure 5 As shown, the device includes: a transceiver module 501, a processing module 502, and a parsing module 503, wherein... ：

[0105] The transceiver module 501 is used to receive business messages from the client;

[0106] The processing module 502 is used to intercept the business message when it is determined that the business message contains gRPC traffic based on the bytecode of the business message. The bytecode is obtained by the client encoding the business message according to the preset encoding rules.

[0107] The parsing module 503 is used to parse the intercepted business messages layer by layer based on a pre-configured set of rules. The set of rules contains multiple rules, and each rule corresponds to a header field of each layer in the business message.

[0108] The parsing module 503 parses business messages layer by layer based on a pre-configured set of rules. Specifically, it is used for:

[0109] The system performs packet parsing, service parsing, interface parsing, and data content parsing on business messages based on a pre-configured set of rules.

[0110] Optionally, the intercepted business messages are parsed layer by layer based on a pre-configured set of rules. The parsing module 503 is specifically used for:

[0111] Based on the correspondence between the header fields of each layer in the business message and the rules, the rules for parsing the business message are determined from the rule set;

[0112] The business messages are parsed layer by layer according to the rules for parsing business messages.

[0113] Optionally, based on the correspondence between the header fields of each layer in the business message and the rules, the rules for parsing the business message are determined from the rule set. The parsing module 503 is specifically used for:

[0114] The rules for package parsing are determined from the rule set based on the package field;

[0115] The rules for service parsing are determined from the rule set based on the service field;

[0116] The rules for interface parsing are determined from the rule set based on the RPC field;

[0117] The rules for parsing data content are determined from the set of rules based on object fields.

[0118] Optional, such as Figure 6 As shown, the gRPC traffic parsing device may further include an eBPF module 504, which, if it is determined that gRPC traffic exists in the service message based on the bytecode of the service message, intercepts the service message. The processing module 502 is specifically used for:

[0119] Pass business messages to the kernel-mode eBPF module;

[0120] eBPF module 504 is used to intercept business messages when gRPC traffic is detected in the business message based on the bytecode of the business message.

[0121] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0122] At least one processor 701 and a memory 702 connected to at least one processor 701. In this embodiment, the specific connection medium between the processor 701 and the memory 702 is not limited. Figure 7 The example shown is the connection between processor 701 and memory 702 via bus 700. Bus 700 is... Figure 7 The connections between other components are indicated by thick lines and are for illustrative purposes only, not as limiting information. The 700 bus can be divided into address bus, data bus, control bus, etc., for ease of representation. Figure 7 The term is represented by a single thick line, but this does not imply that there is only one bus or one type of bus. Alternatively, the processor 701 can also be called a controller; there is no restriction on the name.

[0123] In this embodiment, the memory 702 stores instructions executable by at least one processor 701. By executing the instructions stored in the memory 702, the at least one processor 701 can execute the aforementioned method for determining indicators based on IoT data. The processor 701 can implement... Figure 4 The functions of each module in the device shown.

[0124] The processor 701 is the control center of the device. It can connect to various parts of the control device through various interfaces and lines. By running or executing instructions stored in memory 702 and calling data stored in memory 702, the processor can perform various functions and process data, thereby monitoring the device as a whole.

[0125] In one possible design, processor 701 may include one or more processing units. Processor 701 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, driver interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may also not be integrated into processor 701. In some embodiments, processor 701 and memory 702 may be implemented on the same chip; in some embodiments, they may also be implemented on separate chips.

[0126] The processor 701 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor, application-specific integrated circuit, field-programmable gate array or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the gRPC traffic parsing method disclosed in the embodiments of this application can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules within the processor.

[0127] Memory 702, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 702 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic storage, magnetic disk, optical disk, etc. Memory 702 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. In the embodiments of this application, memory 702 can also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0128] By designing and programming the processor 701, the code corresponding to the IoT data-based index determination method described in the aforementioned embodiments can be embedded into the chip, enabling the chip to execute it during operation. Figure 2 The illustrated embodiment presents a gRPC traffic parsing method. How to design and program the processor 701 is a technique well-known to those skilled in the art and will not be described further here.

[0129] It should be noted that the electronic device provided in this application embodiment can implement all the method steps implemented in the above method embodiment and can achieve the same technical effect. Here, the parts that are the same as those in the method embodiment and the beneficial effects will not be described in detail.

[0130] This application also provides a computer-readable storage medium storing computer-executable instructions for causing a computer to execute a method for determining indicators based on Internet of Things data as described above. Optionally, the storage medium may be a non-transitory computer-readable storage medium, such as a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0131] In an exemplary embodiment, a computer program product is also provided, including a computer program that, when executed by a processor 701, implements any of the gRPC traffic parsing methods provided in this application.

[0132] In an exemplary embodiment, various aspects of the gRPC traffic parsing method provided in this application can also be implemented as a program product, which includes program code. When the program product is run on a computer device, the program code is used to cause the computer device to perform the steps in the gRPC traffic parsing method according to the various exemplary embodiments of this application described above.

[0133] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may include, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0134] The program product for the gRPC traffic parsing method according to the embodiments of this application can be a portable compact disc read-only memory (CD-ROM) and include program code, and can run on an electronic device. However, the program product of this application is not limited thereto. In this document, the readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0135] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying readable program code. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0136] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0137] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's electronic device, partially on the user's device, as a standalone software package, partially on the user's electronic device and partially on a remote electronic device, or entirely on a remote electronic device or server. In cases involving remote electronic devices, the remote electronic device can be connected to the user's electronic device via any type of network, such as a local area network (LAN) or a wide area network (WAN), or it can be connected to an external electronic device, for example, via the Internet using an Internet service provider.

[0138] It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

[0139] Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0140] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0141] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable image scaling device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable image scaling device, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0142] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable image scaling device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0143] These computer program instructions can also be loaded onto a computer or other programmable image scaling device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0144] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0145] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A gRPC traffic parsing method, characterized in that, The method includes: Receive business messages from the client; If gRPC traffic is determined to be present in the business message based on its bytecode, the business message is intercepted. The bytecode is obtained by the client encoding the business message according to a preset encoding rule. The intercepted business messages are parsed layer by layer based on a pre-configured set of rules. The set of rules contains multiple rules, and each rule corresponds to a header field of each layer in the business message. The process of parsing the intercepted business messages layer by layer based on a pre-configured set of rules specifically includes: Based on the correspondence between the header fields of each layer in the business message and the rules, the rules for parsing the business message are determined from the rule set; According to the rules for parsing business messages, the business messages are parsed layer by layer; The step of determining the rules for parsing the business message from the rule set based on the correspondence between the header fields of each layer in the business message and the rules specifically includes: The rules for package parsing are determined from the set of rules based on the package field; The rules for service parsing are determined from the set of rules based on the service field; The rules for interface parsing are determined from the rule set based on the RPC field; The rules for parsing data content are determined from the set of rules based on the object field.

2. The method according to claim 1, characterized in that, The process of parsing the business message layer by layer based on a pre-configured set of rules specifically includes: The business messages are parsed based on a pre-configured set of rules, including packet parsing, service parsing, interface parsing, and data content parsing.

3. The method according to claim 1, characterized in that, If the bytecode of the service message indicates the presence of gRPC traffic, the interception of the service message specifically includes: The service message is then passed to the eBPF module in kernel mode; If the eBPF module determines that the service message contains gRPC traffic based on the bytecode of the service message, it will intercept the service message.

4. A device for gRPC traffic parsing, characterized in that, include: The send / receive module is used to receive business messages from the client. The processing module is used to intercept the business message when it is determined that the business message contains gRPC traffic based on the bytecode of the business message, wherein the bytecode is obtained by the client encoding the business message according to a preset encoding rule; The parsing module is used to parse the intercepted business messages layer by layer based on a pre-configured set of rules. The set of rules contains multiple rules, and each rule corresponds to a header field of each layer in the business message. The intercepted business messages are parsed layer by layer based on a pre-configured set of rules. Specifically, the parsing module is used for: Based on the correspondence between the header fields of each layer in the business message and the rules, the rules for parsing the business message are determined from the rule set; According to the rules for parsing business messages, the business messages are parsed layer by layer; The step involves determining the rules for parsing the business message from the rule set based on the correspondence between the header fields of each layer in the business message and the rules. Specifically, the parsing module is used for: The rules for package parsing are determined from the set of rules based on the package field; The rules for service parsing are determined from the set of rules based on the service field; The rules for interface parsing are determined from the rule set based on the RPC field; The rules for parsing data content are determined from the set of rules based on the object field.

5. The apparatus according to claim 4, characterized in that, The business message is parsed layer by layer based on a pre-configured set of rules. Specifically, the parsing module is used for: The business messages are parsed based on a pre-configured set of rules, including packet parsing, service parsing, interface parsing, and data content parsing.

6. The apparatus according to claim 4, characterized in that, If the bytecode of the service message indicates the presence of gRPC traffic, the processing module intercepts the service message. Specifically, the processing module is used to: The service message is then passed to the eBPF module in kernel mode; If the eBPF module determines that the service message contains gRPC traffic based on the bytecode of the service message, it will intercept the service message.

7. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the gRPC traffic parsing method as described in any one of claims 1-3.

8. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is able to perform the gRPC traffic parsing method as described in any one of claims 1-3.

Images