WO2013079003A1 - 网络消息解析方法及通信设备 - Google Patents

网络消息解析方法及通信设备 Download PDF

Info

Publication number
WO2013079003A1
WO2013079003A1 PCT/CN2012/085494 CN2012085494W WO2013079003A1 WO 2013079003 A1 WO2013079003 A1 WO 2013079003A1 CN 2012085494 W CN2012085494 W CN 2012085494W WO 2013079003 A1 WO2013079003 A1 WO 2013079003A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
information
segment
decision
section
Prior art date
Application number
PCT/CN2012/085494
Other languages
English (en)
French (fr)
Inventor
哈桑·尤里
克里斯托·爱米特
莫默
黄毽
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP12853692.7A priority Critical patent/EP2770687B1/en
Publication of WO2013079003A1 publication Critical patent/WO2013079003A1/zh
Priority to US14/292,086 priority patent/US9819719B2/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/07User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
    • H04L51/18Commands or executable codes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18Multiprotocol handlers, e.g. single devices capable of handling multiple protocols

Definitions

  • the embodiments of the present invention relate to the field of communications technologies, and in particular, to a network message parsing method and a communication device. Background technique
  • DPI Deep Packet Inspection
  • HTTP Hypertext Transfer Protocol
  • existing The technology provides a method for parsing a network message of an HTTP protocol.
  • the network server receives a network message of an HTTP protocol transmitted between a server and a client, and the data parsing module in the network server is pre-configured according to a format of the HTTP protocol.
  • Logic after receiving the network message of the HTTP protocol, processing according to the preset logic, and describing the analysis method of the prior art by taking the following network message as an example:
  • the pre-set logic uses the character-by-character scanning method to match the request method type and the host header field value in the network message, as in the above example, matching
  • the request method type is "GET"
  • the information URL requested by the request method specifically “/root.html”
  • the Host header field value "d.wikimedia.org” are output to the policy matching module in the web server.
  • the policy matching module matches the established policy used by the data stream, and outputs the policy to the network server. Executing a module, so that the policy execution module in the network server executes the predetermined policy, such as a charging policy, for the data flow.
  • the HTTP protocol is used as a tunnel of the Real Time Streaming Protocol (RTSP), and after a period of time, the network message of the RTSP protocol is switched to the Real-time Transport Protocol (RTP).
  • RTSP Real Time Streaming Protocol
  • RTP Real-time Transport Protocol
  • the network message of the protocol the prior art needs to reset the implementation logic for the above situation, and the software and hardware need to be modified to support the above protocol switching, and the non-destructive upgrade cannot be performed, that is, the upgrade can be implemented without interrupting the service, and the reliable operation of the network server is affected.
  • the embodiment of the present invention provides a network message parsing method and a communication device. Because the configuration file is used, when the processing manner of the next message is changed, only the section description information corresponding to the application protocol needs to be modified. Reset the implemented logic to achieve a lossless upgrade.
  • a network message parsing method includes:
  • Network message including one or more segments
  • the network described by a section description information in a configuration file corresponding to the first application protocol Obtaining, in the current segment of the network message, the data of interest indicated by the data of interest indication information in the segment description information;
  • the decision result includes a processing manner of a next message of the network message, where the network message belongs to the same application as the next message, when the current segment is the last segment of the network message.
  • Floor a processing manner of a next message of the network message, where the network message belongs to the same application as the next message, when the current segment is the last segment of the network message.
  • a communication device comprising:
  • a communication module configured to receive a network message, where the network message includes one or more segments; an identification module, configured to identify an application protocol type of the network message as a first application protocol; and a parsing module, configured to Obtaining the data of interest indicated by the data of interest indication information in the section description information in the current section of the network message described by a section description information in the configuration file corresponding to the application protocol; Or partially concerned with the data as a decision condition, executing a decision method in the section description information, and obtaining a corresponding decision result;
  • the decision result includes a processing manner of a next message of the network message, where the network message belongs to the same application as the next message, when the current segment is the last segment of the network message.
  • Floor a processing manner of a next message of the network message, where the network message belongs to the same application as the next message, when the current segment is the last segment of the network message.
  • a parsing system comprising: a compilation engine and a processing engine
  • the compiling engine is configured to compile the configuration file into protocol parsing auxiliary data that can be recognized by the processing engine; wherein different application protocol types correspond to different configuration files;
  • the processing engine is configured to receive a network message, where the network message includes one or more segments; the application protocol type that identifies the network message is a first application protocol; and the protocol corresponding to the first application protocol is parsed Obtaining the data of interest indicated by the data of interest indication information in the section description information in the current section of the network message described by a section description information in the auxiliary data; using all or part of the data of interest as the acquired data a decision condition, performing a decision method in the section description information, to obtain a corresponding decision result; wherein, when the current segment is the last segment of the network message, the decision result includes the network message The processing of the next message, the network message and the next message belong to the same application layer.
  • the embodiment of the present invention uses the segment description information to obtain the current region described by the segment description information.
  • the data in the segment is concerned with the data, and the decision method in the segment description information is executed according to the data of interest, and the processing method of the next message is decided, so that if the processing manner of the next message is changed, the segment description may be modified.
  • the decision-making methods described in the information are implemented without the need to reset the logic of the implementation, so that non-destructive upgrades can be achieved and the flexibility is improved.
  • Figure la is a schematic diagram of protocol bearer provided by an embodiment of the present invention.
  • Figure lb is a schematic diagram of protocol switching provided by an embodiment of the present invention.
  • Figure lc is a schematic diagram of an application layer protocol provided by an embodiment of the present invention.
  • FIG. 1 is a schematic structural diagram of a configuration file provided by an embodiment of the present invention
  • FIG. 2 is a schematic diagram of segment division according to an embodiment of the present invention.
  • FIG. 3 is a schematic diagram of a section distribution of a network message according to an embodiment of the present invention
  • FIG. 4 is a flowchart of a method for parsing a network message according to an embodiment of the present invention
  • FIG. 5 is a flowchart of a method for parsing a network message according to another embodiment of the present invention.
  • FIG. 6 is a structural diagram of a network message according to an embodiment of the present invention.
  • FIG. 7 is a schematic diagram of a fast scan in a segment according to an embodiment of the present invention.
  • FIG. 8 is a flowchart of a fast scanning method according to an embodiment of the present invention.
  • FIG. 9 is a flowchart of processing a network message according to an embodiment of the present invention.
  • Figure 10a is a structural diagram of a communication device according to an embodiment of the present invention.
  • FIG. 10b is a structural diagram of another communication device according to an embodiment of the present invention.
  • FIG. 11 is a structural diagram of a scanning submodule in a communication device according to an embodiment of the present invention.
  • FIG. 12 is a structural diagram of an analysis system according to an embodiment of the present invention.
  • FIG. 13 is a structural diagram of a compiling engine and a processing engine in an analysis system according to an embodiment of the present invention
  • FIG. 14 is a structural diagram of a computer system according to an embodiment of the present invention. detailed description
  • the protocol bearer refers to a message carrying a second application layer in a message of the first application layer, where the second application layer
  • the message is a message body of the first application layer message
  • the first application layer is a previous application layer of the second application layer.
  • the protocol stack of the network data is a hierarchical relationship, and the next application layer message is encapsulated and carried by the last application layer message. For example, the network data first appears in the header of the protocol A message, and then is the message of the protocol A message.
  • the message body is a protocol B message, and the protocol B message is also internally divided into a header and a message body, and the message body of the protocol B is a protocol C message.
  • protocol switching is a protocol switching between network messages in different data flows in different application protocols in the same application layer.
  • messages involved in protocol switching are messages of the same application layer; for example, in the same data stream.
  • the protocol A message plays a role, for example, as a tunnel, negotiation capability, and the like.
  • the protocol B message After the protocol A message is completely processed, it is switched to the protocol B message, and then switched to the protocol ⁇ message, and then switched to the protocol D message, where the protocol A and the protocol B and the protocol C and the protocol D are different application protocols in the same application layer.
  • the HTTP protocol is switched to the RTSP protocol, and then switched to the RTP protocol.
  • the application layer protocol in the embodiment of the present invention refers to an application layer protocol in the TCP/IP layer
  • the application layer protocol in the TCP/IP layer includes three levels, which are respectively equivalent to an open system interconnection ( Open System Interconnect, OSI)
  • OSI Open System Interconnect
  • the configuration file corresponding to each application protocol is pre-configured, and the configuration file structure corresponding to different application protocols is basically the same.
  • the designer needs a certain protocol format according to the protocol structure and the resolution detail requirement.
  • the network message is described or divided into one or more sections, and the characteristics and processing methods of each section are described. It should be understood that some protocols of network messages cannot be divided, such as binary protocols, such as the domain name system ( Domain Name System (DNS), without obvious delimiters, can only be represented by a single section. However, most of the protocols used by most network traffic on the current network can be divided.
  • DNS Domain Name System
  • the configuration file corresponding to each application protocol includes: one or more section description information, where the area The segment description information is used to describe the characteristics and processing method of the segment.
  • the minimum information set of the segment description information is the segment name and the segment type. If the configuration file includes multiple segment description information, it should be understood that some The section description information may include a section name, a section type, a concern data indication information, and a decision method, and some section description information may include only a section name, a section type, and some section description information may include a section name.
  • segment type next segment information; some segment description information may include one of a segment name, a segment type, a care data indication information, a decision method, and a separator (data separator, segment separator) Or multiple);
  • the embodiment of the present invention focuses on introducing at least one or more section description information in a configuration file corresponding to an application protocol, and at least one section description information includes a section name, a section type, and a concern.
  • data indicates information and decision methods, how to resolve the data of interest in the network message.
  • FIG. 1d is a schematic structural diagram of a configuration file according to an embodiment of the present invention.
  • a configuration file corresponding to an application protocol includes:
  • Global configuration information of the protocol corresponding to the protocol such as the protocol name, case sensitivity, etc. In actual applications, whether the case is sensitive or not is optional.
  • the segment contains the segment name, the segment type, the data indication information and the decision method.
  • the segment type indicates the scanning mode of the segment, such as the fast scanning mode and the regular rule. Expression matching method, direct jump mode by a certain length, and so on.
  • Each section needs to describe the care data indication information of the section, so that the data of interest is used to obtain the corresponding data of interest when parsing, and the data of interest is output to the policy matching module to perform matching of the established strategy, or Use this data of interest as a basis for decision making.
  • the decision condition includes one or more care data; if not provided, it means that no decision is required to jump directly to the next session. If the current segment is already in the last segment, or if the decision result does not require further processing, the entire protocol data is processed after the scanning of the segment ends.
  • configuration files corresponding to different application protocols may be stored in a computer medium, and the contents may be reloaded at the time of system startup or normal operation, and compiled into a protocol that the computer can directly read. Parse auxiliary data (such as structures, linked lists, arrays, etc.) and save them to the computer's memory for reading during protocol parsing.
  • the format of the configuration file can be used Any format that can describe the above information, such as XML and so on.
  • FIG. 2 is a schematic diagram showing the segmentation of a network message of an application protocol, where several rectangular boxes represent segments, and rectangular representations with various shadings are shown. Different care data.
  • the data of interest of the segment 1 is more detailed, and each character may be required.
  • the segment 1 is usually the first line of an application protocol, such as the first line of the HTTP protocol.
  • the data of interest includes: The requested method “GET”, the URL “www.abc.com”, and the version number "1.1”. Therefore, the regular expression scan method can be used for this first line.
  • FIG. 2 is a schematic diagram showing the segmentation of a network message of an application protocol, where several rectangular boxes represent segments, and rectangular representations with various shadings are shown. Different care data.
  • the data of interest of the segment 1 is more detailed, and each character may be required.
  • the segment 1 is usually the first line of an application protocol, such as the first line of the HTTP protocol.
  • the data of interest includes: The requested method “GET”, the URL “www.abc.com”,
  • the data of interest in the segment 2 is relatively small, wherein the segment 2 is usually the header field portion (also referred to as the header field segment) of the message of a certain application protocol, which is shown in the figure. It only contains two data of interest, and the rest of the data can be ignored.
  • This section can use the fast scan mode. The following examples will introduce the fast scan mode. As can be seen from Figure 2, section 3 has no concern. Data, where segment 3 is usually the message body of the network message, does not include any data of interest, does not need to be parsed, and can be skipped as a whole.
  • the segment description information in the configuration file corresponding to the application protocol is determined according to the segmentation manner of the network message of the foregoing application protocol, and includes: segment description information 1, segment description information 2, and segment description information.
  • the section description information described in the section is the first line of the network message
  • the section described in the section description information 2 is the header field part of the network message
  • the section description section 3 describes the section as the network.
  • the message body of the message among them:
  • the section description information 1 includes: a section name, a section type, and a concern data indication information, where the section type indicates that the section uses a regular expression scanning manner, and the section description information may further include: The separator, the section separator is used by the network server to segment the first line from the network message.
  • the section separator may be " ⁇ r ⁇ n";
  • the section description information 2 includes: a section name, a section type, a concern data indication information, and a decision method, where the section type indicates that the section uses a fast scanning manner, and the section description information 2 may further include: Splitter and section separator.
  • the data separator is used to split the data in the header field
  • the segment separator is used by the network server to segment the header field from the network message, where the segment separator may be " ⁇ r ⁇ n ⁇ r ⁇ n".
  • the section description information 3 includes: a section name and a section type, where the section type indicates that the scanning mode of the section is skipping a character of a predetermined length, and the predetermined length is a message of a network message.
  • the length of the body may be the same as the segment separator in the segment description information 2, or may be different, and does not affect the implementation of the present invention.
  • the network message described by the segment description information 1 and the segment description information 3 and the segment description information 3 is a network message sent by the first device to the second device.
  • the application protocol corresponds to the configuration file.
  • the section description information may further include section description information 4, section description information 5, and section description information 6, etc., at this time, the section description information 4, section description information 5, and section description information are described.
  • the network message is a network message sent by the second device to the first device, where the definition of the segment description information 4 is similar to the segment description information 1.
  • the definition of the segment description information 5 is similar to the segment description information 2.
  • the definition of the section description information 6 is similar to that of the section description information 3, and details are not described herein again.
  • the interest data indication information in the section description information 1 may include: a Uniform / Universal Resource Locator (URL), a version number indication information, and the like;
  • the interest data indication information in the section description information 2 may include: first indication information used to indicate protocol type information of the next section, second indication information used to indicate length information of the next section, and At least one of third indication information for indicating codec information of the next section.
  • section description information may also have a decision method, or may have no decision method, and does not affect the implementation of the present invention.
  • the decision method in the section description information 2 indicates that different atomic methods are executed according to different decision conditions, and the atomic method includes: one or more of the following:
  • SIP Session Initiation Protocol
  • SIP request header field segment If it is a SIP request segment, the segment is processed according to the request segment, if it is a SIP response region. Segment, then the segment is processed in response to the segment.
  • next segment is a type that skips a specific length directly
  • the next segment is set to directly skip the segment of a specific length, where the specific length is a parameter required by the atomic method, such as a real-time streaming protocol ( Real Time Streaming Protocol (RTSP)
  • RTSP Real Time Streaming Protocol
  • the Content-Length header field of a message indicates the length of its message body part.
  • Determining the end of a complete message Equivalent to completing a complete protocol processing loop, The essential action is to set the next section to be the first section of the current protocol type, re-circulating. For example: After an HTTP message is processed, another HTTP message is sent in the same stream.
  • the segment and the segment have a certain order relationship, but the segment is not necessarily a fixed segment, and is not necessarily the data of the current protocol format, and can be switched to another protocol. Even after several messages are processed, the protocol switching is performed, and the before and after protocols are not bearer relationships.
  • the order of the network messages appears from top to bottom.
  • the network messages transmitted between the server and the client received by the network server are the network messages of the application protocol A, and the network of the application protocol A.
  • the message includes multiple segments; in another case, the network message transmitted between the server and the client received by the network server has multiple protocols for switching, such as switching from protocol A to protocol B; processing in the current segment
  • a decision needs to be made to determine what the next segment is. For example, as shown in Figure 3, where segment 1 and segment 2 respectively use the segment description of protocol A. Information 1 and section description information 2, the network server makes a decision according to the decision method in the section description information 2.
  • the network message exists in the next section, and the decision result indicates that the next section is protocol A.
  • the next segment of the network message for example, the header field segment of the SIP message is followed by the message body segment
  • the segment 3 of the network message can continue to use the segment description of protocol A
  • the next message is not present in the network message, and the result of the decision indicates that the next network message is the network message of protocol B, and correspondingly, it is also divided into multiple segments, such as the area of protocol B.
  • Segment 1 and section 2 of protocol B, etc. in this case, the relationship between protocol B and protocol A is protocol switching, that is, protocol A is switched to protocol B, and correspondingly, sector 1 and sector 2 of protocol B respectively use protocol B.
  • Section description information one and section description information two. Referring to FIG. 4, an embodiment of the present invention provides a network message parsing method, where the method includes:
  • Al receiving a network message, where the network message includes one or more segments.
  • the segments can be segmented by a separator or a given offset length.
  • the execution body of each step of the embodiment of the present invention may be a network server.
  • the network server is located in communication with the first device and the second device, and the received network message is an uplink network message sent by the first device to the second device, or a downlink network message sent by the second device to the first device, that is, The received network message is a network message transmitted between the first device and the second device.
  • the first device may be a client, and the second device is a server.
  • the application protocol type that identifies the network message is the first application protocol.
  • A3. Acquire the data of interest indicated by the data of interest indication information in the section description information from a current section of the network message described by a section description information in a configuration file corresponding to the first application protocol.
  • the segment description information in the configuration file corresponding to the first application protocol may be the segment description information 2, and the current segment may be a header field portion of the network message.
  • the concern data indication information is a header domain name, and correspondingly, the concern data indicates that the information indicates The data is: a header field value located after the name of the corresponding header field, or a care data represented by the header field name itself;
  • the data of interest indication information is an attribute name, and correspondingly, the data of interest indicated by the information of interest indication information is a property value;
  • the concern data indication information is a label name, and correspondingly, the interest data indicated by the concern data indication information is a label value.
  • the first application protocol is specifically described as a line-based text-based protocol.
  • A4. Perform all or part of the data of interest as a decision condition, execute a decision method in the section description information, and obtain a corresponding decision result.
  • the acquired data of interest may be one or more.
  • the acquired data of interest may be 5-10, and the number of decision conditions may be 2-4. It should be understood that the acquired data of interest can be divided into the following three cases:
  • the first case a part of the acquired data of interest is output to the external application, and another part of the acquired data of interest is used as a decision condition;
  • the second case the acquired data of interest is used as both a decision condition and an external application;
  • the third case The acquired data of interest is used as a decision condition.
  • the decision result includes a processing manner of a next message of the network message, where the network message belongs to the same application as the next message, when the current segment is the last segment of the network message.
  • Layer correspondingly, the atomic method executed can be to change the protocol type of the current data stream, that is, the next message uses a different protocol type than the current network message.
  • the decision result indicates a processing manner of the next segment of the current segment, and correspondingly, the executed atomic method includes: setting the next Section, set the protocol type of the next section, set the length of the next section, and set one or any combination of the decoding algorithms that need to be performed before the next section starts.
  • the decision method is used to describe performing different atomic methods according to different decision conditions; the decision condition includes: one or more care data; the decision result includes one or more of the following atomic methods, and The parameters required when the atomic method is executed;
  • the atomic methods executed include: setting the next section, changing the protocol type of the first section of the next message, setting the protocol type of the next section, and setting one of the decoding algorithms to be performed before the next section starts. Item or any combination.
  • the decision method is used to describe performing different atomic methods according to different decision conditions;
  • the decision condition includes one or more care data;
  • the acquired interest data includes the protocol type information and the length information
  • the protocol type information and the length information are used as a decision condition, and the length information indicates that the current segment is the last segment, and the corresponding decision result includes: changing a protocol type of the first segment of the next message The atomic method, wherein the protocol type of the first segment of the next message is a protocol type represented by the protocol type information;
  • the information of interest indication information includes: first indication information used to indicate protocol type information of a next section, the acquired data of interest includes the protocol type information,
  • the protocol type information is used as a decision condition, and the corresponding decision result includes: an atomic method of changing a protocol type of the first segment of the next message, where the protocol type of the first segment of the next message is The type of protocol represented by the protocol type information.
  • the decision method is used to describe performing different atomic methods according to different decision conditions; the decision conditions include: one or more care data;
  • the information of interest indication information includes: first indication information for indicating protocol type information of a next section, the acquired data of interest includes the protocol type information,
  • the protocol type information is used as a decision condition, and the corresponding decision result includes: an atomic method of setting a protocol type of the next segment, where the protocol type of the next segment is a protocol indicated by the protocol type information. Types of.
  • the decision method is used to describe performing different atomic methods according to different decision conditions; the decision conditions include: one or more care data;
  • the information of interest indication information includes: second indication information for indicating length information of a next section, the acquired data of interest includes the length information,
  • the length information is used as a decision condition, and the corresponding decision result includes an atomic method of setting a next segment to directly skip a segment of a predetermined length, wherein the predetermined length is a length indicated by the length information.
  • the decision method is used to describe performing different atomic methods according to different decision conditions; the decision conditions include: one or more care data;
  • the information of interest indication information includes: third indication information for indicating codec information of a next segment
  • the acquired data of interest includes the codec information
  • the codec information is used as a decision condition
  • the corresponding decision result includes an atomic method of setting a decoding algorithm to be performed before the start of the next segment, where the decoding algorithm to be performed before the start of the next segment is the The decoding algorithm represented by the codec information.
  • the segment description information is used to obtain the data of interest in the segment described by the segment description information, and the decision method in the segment description information is executed according to the data of interest, and the next segment is determined or The processing method of the next network message, such that if the method of parsing the network message changes, it can be implemented by modifying the information indication information and/or the decision method described in the section description information; if a new application protocol needs to be added When the parsing capability is required, only the configuration file of the new application protocol needs to be added, and the implemented hardware and software logic does not need to be reset, and the non-destructive upgrade can be performed.
  • the application service gateway loads and compiles the configuration file.
  • the application service gateway compiles the configuration file, and generates protocol parsing auxiliary data directly read by the computer and saves the data.
  • the application service gateway receives the network message.
  • the network message received in the step may be a network message sent by the server to the client, or may be a network message sent by the client to the server.
  • the application service gateway identifies an application protocol to which the network message belongs, which is assumed to be the first application protocol.
  • the protocol identification method in the prior art may be used to identify an application protocol to which the network message belongs, for example, a Transmission Control Protocol (TCP)/User Data Protocol (UDP) may be used.
  • TCP Transmission Control Protocol
  • UDP User Data Protocol
  • the application service gateway uses the segment description information in the configuration file corresponding to the first application protocol to scan the network message, and obtain the data of interest indicated by the data description information in the segment description information 1 from the network message.
  • the segment description information is the segment description information corresponding to the first row, and the segment description information is a packet.
  • the specific implementation manner of the step is: the application service gateway scans the data indication information from the network message by using the regular expression scanning method, until the segment separator is scanned, where the segment segmentation is divided.
  • the segment is the first line of the application protocol.
  • the section description information 1 may further include the next section information, such as the name of the next section, which is assumed to be the name of the section description information 2 in this embodiment.
  • the application service gateway uses the segment description according to the name of the next segment in the segment description information 1.
  • Information 2 processes the data in the header portion of the network message.
  • the application service gateway continues to scan the network message by using the section description information 2 in the configuration file corresponding to the first application protocol, and obtains the section description information from the section described by the section description information 2 in the network message. Concerned about the data of interest indicated by the data indication information.
  • the section description information 2 is section description information corresponding to the header field part, and the section description information 2 includes: a section name, a section type, a concern data indication information, a decision method, a data separator, and a section separator.
  • the scanning mode represented by the segment type is a fast scanning mode
  • the data indication information is a header field.
  • the specific implementation manner of the step is: the application service gateway uses the fast scanning mode to continue scanning the segment description from the network message.
  • the information of the information in the second information is instructed until the segmentation is scanned, wherein the segment segmented by the segment separator is the segment described by the segment description information 2, specifically the network message.
  • Header section For a quick scan mode, please refer to the detailed description of the subsequent embodiments.
  • the application service gateway uses the data of interest obtained in step B5 as a decision condition, and performs a decision method in the section description information 2 to obtain a decision result.
  • the first indication information for indicating the protocol type information is not scanned in the header field portion of the network message, but the second indication information for indicating the length information is scanned, the corresponding decision result is determined, and the decision is made.
  • the results include: Setting the atomic method of "the next segment is a segment that skips a specific length directly", where the specific length is the length indicated by the length information.
  • the section description information used by the next section at this time may be the section description information 3 described above.
  • the first indication information may be a Content-Type
  • the second indication information may be a Content-Length.
  • the atomic method it may not be based on whether the first indication information is scanned, that is, only Only based on whether the second indication information is scanned or not, in other words, in some implementations, the second indication information can be used to make a decision.
  • the decision result includes: changing the protocol type of the current data stream to an atomic method of the protocol type indicated by the first indication information, for example, the current network message is an HTTP type, and the next The network message is the protocol type indicated by the first indication information, that is, the second application protocol, such as the RTSP type.
  • the relationship between the two protocols is protocol switching. For the definition and related description of the specific protocol switching, refer to the foregoing description. No longer.
  • the header field may be further divided into the last section of the network message.
  • the decision result includes: setting an atomic method of a protocol type of the next segment to a protocol type indicated by the first indication information, such as a second application protocol, where the next segment is a current network message
  • a protocol type indicated by the first indication information such as a second application protocol
  • the next segment is a current network message
  • the message body, the first application protocol to which the network message belongs, and the second application protocol used by the message body are the bearer relationship.
  • the decision result includes: an atomic method of setting a decoding algorithm to be performed before the start of the next segment
  • the codec type indicated by the third indication information may be base64, and the next segment needs to be decoded before the next segment begins to perform operations.
  • SMTP Simple Mail Transfer Protocol
  • the message body of the network message can decode the next segment by using the decoding algorithm corresponding to the codec type.
  • the application service gateway obtains the established policy by using the data of interest obtained in the above steps.
  • the established policy is a policy for processing network messages transmitted between the client and the server. Slightly, it can be a strategy such as blocking, billing, and the like.
  • the segment description information is used to obtain the data of interest in the segment described by the segment description information, and the decision method in the segment description information is executed according to the data of interest, and the next segment is determined.
  • the processing manner in this way, when there is a change in the method for parsing the network message, it can be implemented by modifying the information indication information and/or the decision method described in the segment description information. For example, if the data is changed, it needs to be modified.
  • the data indicates information. For example, when the processing method of the next segment or the next network message changes, the decision method needs to be modified. When it is necessary to add a new application protocol resolution capability, only a new application protocol needs to be added.
  • the configuration file does not need to reset the implementation logic, and can be upgraded without loss. Referring to FIG. 6, the network message parsing method provided by the embodiment of the present invention is described in detail as follows:
  • Figure 6 shows the network message transmitted between the client and the server: where the thick rectangular box represents a network message and the thin rectangular area represents a segment, such as segment 100 to segment 109, as shown in Figure 6.
  • the HTTP protocol message, the RTSP protocol message may include a first line segment, a header field partial segment, and a message body partial segment, for example, the segment 100 corresponds to a first row segment; the segment 101 corresponds to a header domain portion segment; It is understood that in practical applications, some messages may be without a message body segment, for example, there is no message body after segment 101, followed by the first line of the response message. Among them, the bold font is the data indication information, such as Content-type, Content-length and RTP-Info.
  • the attention data indication information in the embodiment of the present invention may be a Content-Type header field (indicated by a bold font in the sections 103, 105), a Content-Length header field (indicated by a bold font in the section 105), The RTP-Info header field (in the section 108 is indicated by a bold font).
  • the data of interest indicated by the data indication information is itself the header field value of the Content-Type header field and the header field value of the Content-Length header field.
  • the header field value of the RTP-Info header field where the section separator of the first line in the HTTP protocol network message and the RTSP protocol network message is " ⁇ r ⁇ n", as shown in the section of the HTTP protocol network message in FIG. 100, section 102, and section 104 of the RTSP protocol network message; the section identifier of the HTTP protocol network message header field part is " ⁇ r ⁇ n ⁇ r ⁇ n” , and the data separator is " ⁇ r ⁇ n" , as shown in the HTTP protocol in Figure 6.
  • the section 109 is data in an RTP format, which may specifically be video data. In one way, a decision needs to be made after the end of one segment or before the start of the next segment.
  • the next segment is already defined, and no decision is needed, for example,
  • the section description information already has the name of the next section, so that the default is to execute the next section after the end of the current section.
  • the segment 100 must be the segment 101.
  • the segment 101 is followed by a decision.
  • the message ends after the segment 101.
  • the configuration file used to resolve the network message shown in Figure 6 is shown as follows:
  • the care data indication includes the start character of the string "User-Agent" ->
  • the parameter is LEN_TRACKING, content_length -- >
  • the set_next_section method whose parameters are "LEN_TRACKING,, and "content_len th,, , , means that the next section of the i is the LEN_TRACKING section - ⁇ , the length of the section is the value stored by the content_length variable ->
  • ⁇ PCREX> A RTSP/( ⁇ d ⁇ . ⁇ d) (? Fset(rtsp_ver, ⁇ -1 ⁇ ))) ⁇ d ⁇ 3 ⁇ [a-zA-Z]+ ⁇ r ⁇ n ⁇ /PCREX> ⁇ ! -- RTSP response to the first line of the regular ⁇ ---> ⁇ Output>rtsp_ver ⁇ /Output> ⁇ !- Output extracted RTSP version number, corresponding to 104 --> ⁇ /Section>
  • the decision condition is all or part of the data of interest obtained in this section;
  • Table 1 below is an example table (referred to as a decision table) for saving the decision condition, in other words, the variable table, and the decision condition is the value of these variables;
  • the network server receives the HTTP request message sent by the client to the server, and after identifying the application protocol type as the HTTP protocol, queries the segment description information in the configuration file corresponding to the HTTP protocol, and the segment description information includes the segment name. That is, HTTP_ FIRST_LINE_REQUEST and the section type is a regular expression, the next section information is HTTP_REQ_HEADER, and the data indication information is the URL, which is represented by the section type in the section description information.
  • the regular expression scanning method the HTTP request message is scanned, and the interest data indication information in the section description information 1 is used, and the data of interest indicated by the interest data indication information is obtained from the HTTP request message until the area is scanned.
  • the segment separator " ⁇ r ⁇ n" at this time, the character between the first character of the HTTP request message and the section separator is the section 100.
  • the data indicating information is the URL
  • the scanned data of interest is "/sweeUgp".
  • section description information includes the next section information, indicating that the next section is HTTP_REQ_HEADER, no decision is needed, and the section description information of the application protocol is used, that is, the name is "HTTP- The section description information of REQ_HEADER" directly processes the next section of the HTTP request message, section 101.
  • the network server scans the first character after the segment 100 by using the fast scanning mode indicated by the segment type in the segment description information 2, and continues to use the data indicating information in the segment description information 2 from the network.
  • the message scans the data of interest indicated by the information of interest indication until the section separator " ⁇ r ⁇ n ⁇ r ⁇ n” is scanned, wherein the next character of the section 100 is to the section separator " ⁇ r The character between ⁇ n ⁇ r ⁇ n" is section 101.
  • the interest data indication information in the section description information 2 is "User-Agent” and "Content-Length", the Content-Length indicates the length of the message body of the HTTP message, and the User-Agent indicates the user browser.
  • the network server receives the HTTP response message sent by the server to the client, that is, "HTTP/1.0 200 0K”, and queries the section description information in the configuration file corresponding to the HTTP protocol. Including the section name is "HTTP- FIRST_LINE_RESPONSE”, the section type is the regular expression, and the next section information is "HTTP-RSP-HEADER", and the information indicating the information in the information of the section description information is used.
  • the character between the first character of the HTTP response message and the section separator is the section 102 (the current section 102 is the first line of the HTTP response message), and the data of interest in the fourth description information according to the section is Indicates that the data of interest that needs to be extracted in this section is the HTTP version number.
  • the section description information 4 includes the next section information, indicating that the next section is HTTP_RSP_HEADER, no decision is needed, and the section description information of the application protocol is directly used (ie, the section name is "section description information of "HTTP-RSP-HEADER"), the next section of the HTTP response message, that is, section 103.
  • the network server queries the section description information 5, and uses the interest data indication information in the section description information 5, and scans the concern from the HTTP response message by using the fast scan mode indicated by the section type in the section description information 5.
  • the data indicates the data of interest indicated by the information until the sector segment is scanned as " ⁇ r ⁇ n ⁇ r ⁇ n", wherein the segment segmented by the segment separator is 103.
  • the interest data indication information in the section description information is “Content-Type” and “Content-Length”.
  • the “Content-Type” header field is scanned in the section 103, and the header field thereof is scanned.
  • the value is exactly matched to the string "x-rtsp-tunnel”. If the match is successful, the value of the variable "is rtsp tunnel" is set to true (for example, the value of the record "is_rtsp_tuny" in the above table 1 is true.
  • the atomic method to be executed is "change_protocol", which is the protocol type of the next network message is switched to RTSP, so The next network message transmitted between the client and the server is parsed using the configuration file corresponding to RTSP.
  • the logical meaning is that the Content-Length header field value indicates that the message does not contain the message body, so it is not a protocol bearer relationship. Further, the Content-Type header field value indicates that the role of this HTTP message is an RTSP tunnel, so subsequent network messages Need to switch to RTSP.
  • the network server receives the RTSP message sent by the server to the client, that is, "RTSP/1.0 200 OK", and queries the section description information in the configuration file corresponding to the RTSP protocol.
  • the section description information includes the section name, that is, RTSP_ FIRST. LINE, the segment type is a regular expression, the next segment information is the RTSP_HEADER and the care data indication information, and the RTSP network message is scanned by using the regular expression scanning mode indicated by the segment type in the segment description information 1.
  • the data indicates that the data of interest that needs to be extracted in this section is the RTSP version number. Since the segment description information includes the next segment information, indicating that the next segment is RTSP_HEADER, no decision is needed, and the segment description information in the configuration file corresponding to the protocol under the RTSP is directly used.
  • the section name is "RTSP_HEADER"
  • the next section of the RTSP message, section 105 is processed.
  • the network server continues to scan the RTSP network message by using the fast scanning mode indicated by the segment type in the segment description information corresponding to the RTSP protocol, until the segment partition is scanned as " ⁇ r ⁇ n ⁇ r ⁇ n".
  • the segment segmented by the segment separator is the segment 105. If the data indication information in the section description information 2 is scanned, the data of interest indicated by the information indicator information is extracted, for example, the data indication information is "Vsrc", "Content-Type", and “Content-Length". " In this example, "Vsrc”, “Content-Type”, and “Content-Length” are scanned in the section.
  • the "Content-Type" header field value indicates that the protocol is switched to the Session Description Protocol (SDP).
  • the SDP protocol message does not care about the data, which can be ignored in this example. Since the header field value does not indicate the Real Time Protocol (RTP) protocol, the value of the variable "is-rtp" is the default value, and the value indicated by the "Content-Length" header field value is 1903.
  • the value of the record variable Content-Length is 1903 (for example, the value of the variable Content-Length is 1903 in Table 1 above), then the value of "is-rtp" is 4 ⁇ , and the value of "Content-Length” is 1903.
  • the decision making method is as follows:
  • the above decision method is applied to the segment 105 and the segment 108, and contains two data of interest and corresponding atomic methods. It can be seen that for the 105 segment, it can be seen from the above decision method that when "is-rtp" is false and the value of Content-Length is non-zero, the decision is made: Determining that the next segment is a direct jump segment The number of characters directly jumped is 1903. Then the number of characters in the subsequent section 106 is 1903, and the network server does not perform any processing on it, skipping directly.
  • the subsequent message uses the segment description information of the first segment of the application protocol (ie, the segment description information corresponding to the RTSP protocol). deal with. Therefore, the 107 segment is handled in the same manner as the 104 segment.
  • the network server continues to scan the RTSP network message by using the fast scan mode indicated by the segment type in the segment description information corresponding to the RTSP protocol, until the segment partition is scanned as " ⁇ r ⁇ n ⁇ r ⁇ n " So far, the segment divided by the segment separator is the segment 108.
  • the decision method is as follows:
  • the decision logic is: When "is-rtp" is true and the content-length value is 0, the decision is made: the protocol is switched to the RTP protocol. It should be noted that, in this example, the content-length value is 0 because the Content-Length header field is not scanned.
  • the decision logic given above is only applicable to the present example. In practical applications, there may be other variables for decision making, and other decision methods may be used, without affecting the implementation of the present invention.
  • the decision result of the decision method is a handover protocol or a bearer protocol.
  • the description information of a certain section in the configuration file may include the following content.
  • FIG. 7 and FIG. 8 illustrate a fast scanning method provided by an embodiment of the present invention, where the fast scanning method can be The information about the data of interest in the scan header field, which specifically includes:
  • the section may be a header field part of a network message.
  • the preset length is determined by the length of the data separator in the segment. The longer the length of the data separator, the longer the predetermined length. Generally, the predetermined length ⁇ data separator + the length of the character concerned n
  • the care data indication information may be a string of characters, and the character of interest is a head character of the string, which may be the first n characters of the string, where n is greater than or equal to 1, for example, when n is equal to 2 , which includes the first character and the second character of the string; wherein the data separator can be recorded in the section description information, the data separator is different from the section separator, and the data separator is used to divide the same
  • the segment separator is a segment for segmenting the corresponding segment description information from the network message, such as segmenting the HTTP first row and the HTTP header field from the HTTP network message.
  • the data separator can be " ⁇ r ⁇ n” and the segment separator can be “ ⁇ r ⁇ n ⁇ r ⁇ n”. If the data separator is " ⁇ r ⁇ n" and one of the characters of interest is taken, the preset length can be 3, that is, 3 characters at a time.
  • the string matching in the HTTP header field part can be "Content-Type” or “Content-Length”.
  • the jumped character is a data separator
  • determining whether the character of the n non-data separators located after the jumped character and closest to the jumped character is the string
  • the first n characters in the middle if yes, according to the first n characters in the string, using the string matching method, matching the string in the segment, indicating the matching string
  • the care data is sent to the policy matching module, and the process ends.
  • n can be 1, or 2, or any other value, without affecting the implementation of the present invention.
  • the above fast scan algorithm can be applied to any protocol, and can be implemented by hardware, for example, by using an FPGA.
  • the fast scanning method provided by the embodiment of the present invention is described in detail in conjunction with the above examples. For example, the segment 105 in FIG. 6:
  • the "ontent-Type" is matched exactly.
  • the string matching method can be used to match. If the matching is successful, the data of interest indicated by the Content-Type is output to the policy matching module.
  • the string matching method may be used for matching. If the matching is successful, the data of interest indicated by the Content-Type is output to the policy matching module.
  • the above description is based on the case where the character of interest is 1 character.
  • the character of interest can also be two characters, that is, the first two characters of the string, namely "Co" and "Vs".
  • the network message parsing method provided by the foregoing embodiments of the present invention can be applied to a fixed network, an access network of a mobile network, and various gateway devices in a core network, such as an application service gateway, which is used for acquiring network messages. Concerning the data and implementing various policies for the network message, such as blocking, traffic limiting, redirection, content charging, etc., wherein FIG. 9 shows a plurality of network message processing flows of the application service gateway, including:
  • the application service gateway receives the network message.
  • the UE uses the UE to log in to the radio access network through authentication, obtains the IP address of the application server from the core network, and then sends a network message to the application server.
  • the application service gateway identifies the application protocol used by the network message.
  • TCP/UDP port identification method or a feature word recognition method, or a protocol behavior recognition method may be used.
  • the application service gateway saves the quintuple of the network message to the flow table.
  • the quintuple of the network message includes: a source IP, a destination IP, a source port, a destination port, and a transport protocol type, and the transport protocol type may be TCP or UDP.
  • the application service gateway saves the source IP address, destination IP address, source port, destination port, and transport protocol type of the network message to the flow table.
  • the application service gateway extracts the data of interest from the network message by using the configuration file corresponding to the application protocol identified in step E2.
  • the method for the application service gateway to extract the data of interest from the network message is specifically based on the configuration file corresponding to the application protocol, and uses the regular expression method or the fast scan method to find the data of interest in the corresponding section of the network message, and uses the found Care about the data as a decision-making basis to execute the decision-making method, decide the next section of the network message or the processing method of the next network message, and then use the regular expression method or the fast scan method to find the concern in the next section or the next network message.
  • the regular expression method or the fast scan method to find the concern in the next section or the next network message.
  • the application service gateway performs policy matching by using the data of interest extracted from the network message.
  • the established policies include: blocking, current limiting, redirection, billing and other strategies.
  • the application service gateway executes the matched established policy.
  • the application service gateway parses the URL "/sweeUgp" in the processing section 101, but only uses the URL without matching any policy until the application When the service gateway processes the section 108, it matches the RTP-Info header field.
  • the application service gateway uses the RTP-Info header field and "/sweeUgp" to learn that the server interacts with the client as a video file and matches the charging policy. Subsequent billing for the content of section 109 can be made.
  • the application service gateway receives the subsequent network message, and matches the source IP, the destination IP address, the source port, the destination port, and the transport protocol type of the newly received network message with the quintuple saved in the flow table, if the match is matched. If the success is successful, the network message is processed by using the established policy that has been matched in step E6. If the matching is unsuccessful, the network message is treated as a new network message, and steps E2-E6 are re-executed. .
  • an embodiment of the present invention provides a communications device, where the communications device can include:
  • the communication module 81 is configured to receive a network message, where the network message includes one or more segments, an identification module 82, configured to identify that the application protocol type of the network message is a first application protocol, and a parsing module 83, Obtaining the data of interest indicated by the data of interest indication information in the section description information from a current section of the network message described by a section description information in a configuration file corresponding to the first application protocol; Acquiring all or part of the data of interest as a decision condition, performing a decision method in the section description information, and obtaining a corresponding decision result; wherein, when the current segment is the last segment of the network message, The decision result includes a processing manner of a next message of the network message, and the network message belongs to the same application layer as the next message.
  • the parsing module 83 includes:
  • the parsing sub-module 8311 is configured to acquire the data of interest indication information in the section description information from a current section of the network message described by a section description information in a configuration file corresponding to the first application protocol. Indicating data of concern;
  • a decision sub-module 8312 configured to execute all or part of the data of interest as a decision condition, execute a decision method in the section description information, and obtain a corresponding decision result
  • the decision method is used to describe performing different atomic methods according to different decision conditions;
  • the decision condition includes one or more pieces of interest data.
  • the interest data indication information includes: first indication information used to indicate protocol type information of a next section and used to indicate a next area.
  • the second indication information of the length information of the segment, the acquired interest data includes the protocol type information and the length information;
  • the parsing module 83 includes:
  • the parsing sub-module 8311 is specifically configured to acquire the data of interest indication information in the section description information from a current section of the network message described by a section description information in a configuration file corresponding to the first application protocol.
  • the indicated data of interest wherein: the data of interest indication information comprises: first indication information for indicating protocol type information of a next segment, and second indication information for indicating length information of a next segment, obtained
  • the care data includes the protocol type information and the length information;
  • the decision sub-module 8312 is specifically configured to use the protocol type information and the length information as a decision condition, and the length information indicates that the current segment is the last segment, and the corresponding decision result is determined, and the decision result includes: An atomic method of changing a protocol type of a first segment of a next message, where a protocol type of a first segment of the next message is a protocol type represented by the protocol type information;
  • the information of interest indication information includes: first indication information used to indicate protocol type information of a next section, where the acquired interest data includes the protocol type information;
  • the parsing module 83 includes:
  • the parsing sub-module 8311 is specifically configured to acquire the data of interest indication information in the section description information from a current section of the network message described by a section description information in a configuration file corresponding to the first application protocol.
  • the indicated data of interest includes: first indication information for indicating protocol type information of the next segment, the acquired data of interest including the protocol type information,
  • the decision sub-module 8312 is specifically configured to use the protocol type information as a decision condition to determine a corresponding decision result, where the decision result includes: an atomic method of changing a protocol type of a first segment of a next message, where The protocol type of the first sector of the next message is the protocol type represented by the protocol type information.
  • the first indication information may be a Content-Type header field, which refers to The care data shown is the specific protocol type located behind the header field. Or, the first indication information is
  • the RTP-info header field whose indicated data of interest is RTP.
  • the parsing module is further configured to: when the current segment is not the last segment of the network message, the decision result indicates processing of a next segment of the current segment the way.
  • the atomic method is characterized by the parameters used, where the atomic method includes setting the atomic method of the next section, changing the atomic method of the protocol type of the first section of the next message, and setting the atom of the protocol type of the next section.
  • the corresponding decision result may be set by the atomic method of the next segment, and the atomic method of setting the protocol type of the next segment.
  • the atomic method of the decoding algorithm that needs to be performed before the start of the next segment is expressed, and which atomic method is specifically determined according to specific decision conditions.
  • the information of interest indication information includes: first indication information used to indicate protocol type information of a next section, where the acquired interest data includes the protocol type information;
  • the parsing module 83 includes:
  • the parsing sub-module 8311 is specifically configured to acquire the data of interest indication information in the section description information from a current section of the network message described by a section description information in a configuration file corresponding to the first application protocol.
  • the indicated data of interest wherein the information of interest data includes: first indication information for indicating protocol type information of the next segment, and the acquired data of interest includes the protocol type information;
  • the decision sub-module 8312 is specifically configured to use the protocol type information as a decision condition to determine a corresponding decision result, where the decision result includes: an atomic method of setting a protocol type of a next segment, where the next segment
  • the protocol type is the protocol type indicated by the protocol type information.
  • the information of interest indication information includes: second indication information used to indicate length information of a next segment, where the acquired data of interest includes the length information;
  • the parsing module 83 includes:
  • the parsing sub-module 8311 is specifically configured to acquire the data of interest indication information in the section description information from a current section of the network message described by a section description information in a configuration file corresponding to the first application protocol.
  • the indicated data of interest wherein the information of interest data includes: second indication information for indicating length information of a next segment, the acquired data of interest including the length information;
  • the decision sub-module 8312 is specifically configured to use the length information as a decision condition to determine a corresponding decision result, where the decision result includes: setting an next atomic method that directly skips a segment of a predetermined length, where The predetermined length is the length indicated by the length information.
  • the section directly skipping the predetermined length may be LEN_TRACKING in the configuration file corresponding to FIG. 6 above. For the specific implementation, refer to the corresponding description of the method embodiment.
  • the information of interest indication information includes: third indication information used to indicate codec information of a next segment, where the acquired data of interest includes the codec information;
  • the parsing module 83 includes:
  • the parsing sub-module 8311 is specifically configured to acquire the data of interest indication information in the section description information from a current section of the network message described by a section description information in a configuration file corresponding to the first application protocol.
  • the indicated data of interest wherein: the data of interest indication information comprises: third indication information for indicating codec information of a next segment, the acquired data of interest comprising the codec information;
  • the decision sub-module 8312 is specifically configured to use the codec information as a decision condition to determine a corresponding decision result, where the decision result includes: an atomic method of setting a decoding algorithm to be performed before starting the next segment, where The decoding algorithm that needs to be performed before the start of the next segment is the decoding algorithm represented by the codec information.
  • the codec type may be base64 or the like.
  • the first section description information includes: a section name, a section type, the concern data indication information, and the decision method, where the section type indicates a scan used by the current section
  • the description may be a fast scan mode, a regular expression scan mode, or the like.
  • the parsing module 83 includes:
  • the scanning submodule 8321 is configured to scan, by using the scan mode indicated by the segment type, the interest data indication information from the current segment corresponding to the segment name;
  • the obtaining sub-module 8322 is configured to acquire the data of interest indicated by the scanned data of interest indication information
  • the decision sub-module 8323 is configured to acquire the data of interest indicated by the scanned data of interest indication information, and perform the decision method in the first segment description information by using all or part of the data of interest to obtain a corresponding decision result.
  • the embodiment of the present invention further provides a fast scanning technology.
  • the scanning submodule 8321 includes:
  • the fast scan sub-module 8321a is configured to jump from a first character of the current segment corresponding to the segment name to a character of a specific length, and when the jumped character is a data separator, determine that the jump is located Whether the character of the n non-data delimiters following the turned-to-character character and closest to the jumped character is the first n characters in the care data indication information; wherein n is greater than or equal to 1; When the transferred character is the character in the data indication information, it is determined whether the character in the non-care data indication information located in front of the jumped character and closest to the jumped character is data segmentation Symbol
  • the exact matching submodule 8321b is configured to determine whether the character of the n non-data delimiters located after the jumped character and closest to the jumped character is in the interest data indication information When the judgment result of the n characters is YES, according to the first n characters in the attention data indication information, the interest data indication information is matched in the current section; and the character located in the jump is determined If the result of the previous non-concern data indicating that the character in the information is the data separator is YES, the jump to the character is used to match in the current segment. To the care data indication information.
  • the scanning sub-module For the specific operation of the scanning sub-module, reference may be made to the detailed description of the embodiment corresponding to FIG. 7 and FIG. 8.
  • the communication device may further include: a policy matching module 84 and a policy execution module 85, where the management of the network message between the first device and the second device is blocked, billed, and the like, wherein:
  • a policy matching module 84 configured to determine, by using the data of interest, that the network message is applicable Established strategy
  • the policy execution module 85 is configured to operate on the data stream in which the network message is located by using the predetermined policy.
  • the established policy may be a charging policy or the like.
  • the communication device in the embodiment of the present invention may be an access network applied to a fixed or mobile network, and various gateway devices in the core network, and may be an application service gateway, but is not limited thereto. It can be used as a supporting technology for implementing various functions of the gateway device, such as flow control, content charging, content matching, network security protection, wireless signaling storm suppression, load sharing, and the like.
  • the embodiment of the present invention uses the header field in the section description information used by the section in the configuration file to acquire the data of interest in the section, and then uses the data of interest to execute the decision method, and decides the next section or the next.
  • a method of processing a message such that if there is a change in the method of parsing the network message, it can be implemented by modifying the data indication information and/or the decision method described in the section description information; if it is necessary to add a new application protocol resolution capability In this case, only the configuration file of the new application protocol needs to be added, and the logic of the implementation is not required to be reset, and the non-destructive upgrade can be performed.
  • an analysis system is provided according to an embodiment of the present invention, including:
  • the compiling engine 91 is configured to compile the configuration file into protocol parsing auxiliary data that can be recognized by the processing engine; wherein different application protocol types correspond to different configuration files;
  • the compilation engine 91 supports loading the configuration file during system initialization and also supports updating the configuration file when the system is online.
  • the processing engine 92 is configured to receive a network message, where the network message includes one or more segments; the application protocol type that identifies the network message is a first application protocol; and the protocol resolution assistance corresponding to the first application protocol
  • the application protocol type that identifies the network message is a first application protocol
  • the protocol resolution assistance corresponding to the first application protocol
  • In the current segment of the network message described by the first segment description information in the data acquiring the data of interest indicated by the data of interest indication information in the first segment description information; using all or part of the data of interest as a decision condition, performing a decision method in the first segment description information, to obtain a decision result; wherein, when the current segment is the last segment of the network message, the decision result includes the network message
  • the processing of the next message, the network message and the next message belong to the same application layer.
  • the configuration file corresponding to the application protocol includes: one or more segment description information, where the segment description information includes a segment name, a segment type, a concern data indication information, and a decision method, where the segment The type indicates the scanning mode used by the segment; the information indicating the information includes: first indication information for indicating protocol type information of the next segment, and second indication information for indicating length information of the next segment One or any combination of third indication information for indicating codec information of the next segment;
  • the decision method is used to describe performing different atomic methods according to different decision conditions, the atomic method includes: setting a next segment, setting a protocol type of a next segment, setting a length of a next segment, determining a complete The message ends, changes the protocol type of the current data stream, and sets one or any combination of the decoding algorithms that need to be performed before the next segment begins.
  • the parsing system further includes: a memory manager 93 (illustrated by 93a and 93b in the figure) for managing memory used by the compiling engine and the processing engine, the compiling engine and the processing engine are different in use. Memory area or the same memory area. In one implementation, the memory used by the compilation engine 91 and the processing engine 92 are separately managed by deploying different memory managers.
  • the resolution system further includes: a loader 94 for reading the configuration file from the internal storage device or the external storage device and loading it to the compilation engine 91.
  • the compiling engine 91 may include:
  • a fast scan compiler 911 configured to compile a header field in each section described in the configuration file into machine-readable protocol parsing auxiliary data, and output a fast scan table;
  • the fast scan table includes: the header field The first n characters and the protocol corresponding to the data separator in the section parse the auxiliary data;
  • An exact match compiler 912 for compiling the multi-mode matching algorithm into a machine-readable protocol parsing auxiliary data
  • the logic decision compiler 913 is configured to compile the decision method in the configuration file into a protocol parsing auxiliary data that can be read by the machine.
  • the method may further include: a regular expression compiler 914, configured to compile the regular expression into a machine-readable protocol parsing auxiliary data, so that when the scan mode used by the segment type representation section is a regular expression scan mode, The processing engine 92 parses the auxiliary data using the compiled protocol, correspondingly The section lookup care data indication information.
  • a regular expression compiler 914 configured to compile the regular expression into a machine-readable protocol parsing auxiliary data, so that when the scan mode used by the segment type representation section is a regular expression scan mode, The processing engine 92 parses the auxiliary data using the compiled protocol, correspondingly The section lookup care data indication information.
  • the processing engine 92 can include:
  • the fast scan module 921 is configured to jump from a first character of the current segment corresponding to the segment name to a character of a specific length, and determine, according to the fast scan table, whether the jumped character is a data separator or The care data indicates that the characters in the first n characters in the information, when the jumped character is a data separator, determine that the character is located after the jumped character and is closest to the jumped character.
  • n non-data delimiters are the first n characters in the care data indication information; when the jumped character is the character of the first n characters in the care data indication information, judging the location Whether the character in the information in front of the jumped character and closest to the jumped character indicates whether the character in the information is a data separator; wherein n is greater than or equal to 1;
  • the exact matching module 922 is configured to determine whether the character of the n non-data delimiters located after the jumped character and closest to the jumped character is the first in the interest data indication information
  • the compiled multi-mode matching algorithm in the protocol parsing auxiliary data is executed according to the first n characters in the information of interest indication to match in the current segment. Go to the care data indication information; when it is judged whether the character in the non-care data indication information located in front of the jumped character and closest to the jumped character is a data separator Performing, by using the jumped character, the compiled multi-mode matching algorithm in the protocol parsing auxiliary data to match the interest data indication information in the current segment;
  • a decision maker 923 configured to acquire the data of interest indicated by the data of interest indication information according to the matched data of interest indication information, and execute the decision method in the first segment description information by using all or part of the data of interest
  • the compiled protocol parses the auxiliary data to obtain the decision result.
  • the processing engine 92 may further include: a regular expression matching module 924, configured to parse the auxiliary data by using a protocol corresponding to the regular expression when the scanning mode used by the segment type indicating segment is a regular expression scanning mode The corresponding section looks for the data indication information of interest.
  • a regular expression matching module 924 configured to parse the auxiliary data by using a protocol corresponding to the regular expression when the scanning mode used by the segment type indicating segment is a regular expression scanning mode The corresponding section looks for the data indication information of interest.
  • the processing engine 92 further includes: an output module 925, configured to output the acquired data of interest to the outside, specifically to the policy matching module, where the policy matching module utilizes the Processing the data of interest obtained by the engine, determining an established policy to which the network message applies; and then the policy execution module utilizes the predetermined policy to the network The data stream in which the message is located operates.
  • the parsing system further includes:
  • the TCP/UDP flow table management module (not shown) is configured to maintain a correspondence between the quintuple of the network message and the first application protocol type, and the quintuple of the network message includes: a source IP, a destination IP, and a source. Port, destination port, and transport protocol type.
  • the transport protocol type can be TCP or UDP. After receiving the network message matching the quintuple, it directly determines the application protocol type corresponding to the quintuple.
  • the TCP/UDP flow table management module is further configured to record the correspondence between the five-tuple and the established policy. After receiving the network message matching the quintuple, the established policy is directly applied to the network message.
  • the configuration file can be stored in the computer medium, and its content can be reloaded when the system is started or in normal operation, and compiled into a data structure form that the computer can directly read (compiled into a calculation from a human readable format can be read The format.
  • Various data structures, such as structures, linked lists, arrays, etc., are saved to the computer memory for reading when the protocol is processed.
  • the format of this file can be any format that can describe the above information, such as XML.
  • the loading, compiling, and data processing of configuration files are separate and not interpretive.
  • FIG. 14 is a schematic structural diagram of a computer system according to an embodiment of the present invention. It should be understood that the following describes an embodiment in which the analysis system of the embodiment of the present invention is deployed in a computer;
  • All software processing logic code is loaded from memory 62 to the processor during the system initialization phase.
  • the parsed configuration file segment information data structure is stored in the memory 65.
  • the processor 63 begins with the software logic to process the network messages in the memory 65, including the application protocol identification, parsing, and the like.
  • the network message is sent from 65 to 15 to 68 to the next hop device of the network, or is discarded because the application discarding policy is discarded and is no longer sent to the next hop device. It should be understood that all or part of the data of interest obtained from the current segment is used as a basis for decision making, and this information can be saved to the computer memory.
  • the network file of various protocol types and the corresponding processing method are described by using the configuration file, and the processing capability is greatly improved while obtaining high flexibility.
  • the configuration file description capability is not limited to the format of a specific protocol. It can also support complex logic such as protocol switching, pre-coding and decoding, etc., but the configuration file logic is very simple.
  • the aforementioned program can be stored in a computer readable storage medium.
  • the program when executed, performs the steps including the foregoing method embodiments; and the foregoing storage medium includes: a medium that can store program codes, such as a ROM, a RAM, a magnetic disk, or an optical disk.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明实施例提供网络消息解析方法及通信设备,网络消息解析方法包括:接收网络消息,所述网络消息包括一个或多个区段;识别出所述网络消息的应用协议类型为第一应用协议;从第一应用协议对应的配置文件中的一个区段描述信息所描述的所述网络消息的当前区段中,获取所述区段描述信息中的关心数据指示信息所指示的关心数据;以所获取的全部或者部分关心数据作为决策条件,执行所述区段描述信息中的决策方法,得到对应的决策结果;其中,当所述当前区段是所述网络消息的最后一个区段时,所述决策结果包括所述网络消息的下一个消息的处理方式,所述网络消息与所述下一个消息属于同一应用层。使用本发明实施例提供的技术方案,能够实现无损升级。

Description

网络消息解析方法及通信设备 技术领域
本发明实施例涉及通信技术领域, 特别涉及一种网络消息解析方法及通 信设备。 背景技术
现在固网宽带业务快速发展, 给运营商带来机遇的同时也带来挑战, 随 着 P2P、 网络游戏、 Web TV、 VoIP等应用的普及, 带来了带宽管理、 内容计 费、 信息安全处理等一系列问题。
深度包检测 (Deep Packet Inspection, DPI )技术被认为是应对网络中多 个业务运行所带来的管理问题的有效方法, 即利用 DPI技术能够对网络中运 行的多种业务的网络消息进行快速的解析, 可以识别出网络消息所归属的应 用协议。
但是, 现在仅解析出网络消息所归属的应用协议是不够的, 还需要解析 出网络消息中携带的关心数据, 比如, 对于超文本传输协议 (Hyper Text Transfer Protocol, HTTP )的网络消息, 现有技术提供一种解析 HTTP协议的 网络消息的方法, 具体的, 网络服务器接收服务器与客户端间传输的 HTTP 协议的网络消息, 网络服务器中的数据解析模块根据 HTTP协议的格式, 预 先设置好实现的逻辑, 收到 HTTP协议的网络消息后按照预先设置的逻辑进 行处理, 以如下网络消息为例对现有技术的解析方法进行描述:
"GET /root.html HTTP/1. l\r\n"
"User-Agent: Mozilla/5.0 \r\n"
"Host: d.wikimedia.org\r\n"
"Accept-Encoding: gzip,deflate\r\n"
"Keep-Alive: 115\r\n"
"Connection: keep-alive\r\n"
' 'Content-Length: 10\r\n\r\n" " 0123456789"
网络服务器中的解析模块针对 HTTP协议的网络消息进行解析时, 预先 设置好的逻辑是利用逐字符扫描方法, 匹配出该网络消息中的请求方法类型 以及 Host头域值, 如上述实例, 匹配出的请求方法类型为 "GET" , 将该请 求方法所请求的信息 URL (具体是 " /root.html " ) 和 Host 头域值 "d.wikimedia.org"输出到网络服务器中的策略匹配模块, 其中, "/root.html" 和 "d.wikimedia.org" 为该网络消息中携带的关心数据, 该策略匹配模块匹 配出数据流所使用的既定策略, 将既定策略输出到网络服务器中的策略执行 模块, 以便网络服务器中的策略执行模块对数据流执行该既定策略, 比如计 费策略等。
现有技术的缺点是:
由于各种协议格式不同, 处理时提取的关心数据也不同, 需要对每种协 议都进行预先分析和处理, 而对于网络服务器接收的服务器和客户端间传递 的网络消息有多种协议进行切换的情况, 比如, 利用 HTTP协议作为实时流传 输协议(Real Time Streaming Protocol, RTSP )的管道( Tunnel ), —段时间后 RTSP协议的网络消息又切换为实时传送协议 ( Real-time Transport Protocol, RTP )协议的网络消息, 现有技术需要针对上述情况重新设置实现的逻辑, 需 要修改软硬件来支持上述协议切换, 无法做到无损升级, 即不需要中断业务 即可实现升级, 影响网络服务器的可靠运行。
发明内容
本发明实施例提供一种网络消息解析方法及通信设备, 由于釆用的是配 置文件, 所以在对下一个消息的处理方式有变化时, 只需要修改应用协议对 应的区段描述信息, 不需要重新设置实现的逻辑, 从而实现无损升级。
有鉴于此, 本发明实施例提供:
一种网络消息解析方法, 包括:
接收网络消息, 所述网络消息包括一个或多个区段;
识别出所述网络消息的应用协议类型为第一应用协议;
从第一应用协议对应的配置文件中的一个区段描述信息所描述的所述网 络消息的当前区段中, 获取所述区段描述信息中的关心数据指示信息所指示 的关心数据;
以所获取的全部或者部分关心数据作为决策条件, 执行所述区段描述信 息中的决策方法, 得到对应的决策结果;
其中, 当所述当前区段是所述网络消息的最后一个区段时, 所述决策结 果包括所述网络消息的下一个消息的处理方式, 所述网络消息与所述下一个 消息属于同一应用层。
一种通信设备, 其包括:
通信模块, 用于接收网络消息, 所述网络消息包括一个或多个区段; 识别模块, 用于识别出所述网络消息的应用协议类型为第一应用协议; 解析模块, 用于从第一应用协议对应的配置文件中的一个区段描述信息 所描述的所述网络消息的当前区段中, 获取所述区段描述信息中的关心数据 指示信息所指示的关心数据; 以所获取的全部或者部分关心数据作为决策条 件, 执行所述区段描述信息中的决策方法, 得到对应的决策结果;
其中, 当所述当前区段是所述网络消息的最后一个区段时, 所述决策结 果包括所述网络消息的下一个消息的处理方式, 所述网络消息与所述下一个 消息属于同一应用层。
一种解析系统, 包括: 编译引擎和处理引擎,
所述编译引擎, 用于将配置文件编译成所述处理引擎能识别的协议解析 辅助数据; 其中, 不同的应用协议类型对应不同的配置文件;
所述处理引擎, 用于接收网络消息, 所述网络消息包括一个或多个区段; 识别出所述网络消息的应用协议类型为第一应用协议; 从所述第一应用 协议对应的协议解析辅助数据中一个区段描述信息所描述的所述网络消息的 当前区段中, 获取所述区段描述信息中的关心数据指示信息所指示的关心数 据; 以所获取的全部或者部分关心数据作为决策条件, 执行所述区段描述信 息中的决策方法, 得到对应的决策结果; 其中, 当所述当前区段是所述网络 消息的最后一个区段时, 所述决策结果包括所述网络消息的下一个消息的处 理方式, 所述网络消息与所述下一个消息属于同一应用层。
本发明实施例利用区段描述信息, 获取该区段描述信息所描述的当前区 段中的关心数据, 并依据关心数据执行该区段描述信息中的决策方法, 决策 出下一个消息的处理方式, 这样, 如果对下一个消息的处理方式有变化, 则 可以通过修改区段描述信息中所描述的决策方法来实现, 不需要重新设置实 现的逻辑, 从而能够做到无损升级, 且灵活性也得以提高。 附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案, 下面将对实 施例或现有技术描述中所需要使用的附图作简单地介绍, 显而易见地, 下面 描述中的附图仅仅是本发明的一些实施例, 对于本领域普通技术人员来讲, 在不付出创造性劳动性的前提下, 还可以根据这些附图获得其他的附图。
图 la是本发明实施例提供的协议承载示意图;
图 lb是本发明实施例提供的协议切换示意图;
图 lc是本发明实施例提供的应用层协议示意图;
图 Id是本发明实施例提供的配置文件的结构示意图;
图 2是本发明实施例提供的区段划分示意图;
图 3是本发明实施例提供的网络消息所釆用的区段分布示意图; 图 4是本发明一实施例提供的网络消息解析方法流程图;
图 5是本发明另一实施例提供的网络消息解析方法流程图;
图 6是本发明实施例提供的网络消息结构图;
图 7是本发明实施例提供的区段中快速扫描示意图;
图 8是本发明实施例提供的快速扫描方法流程图;
图 9是本发明实施例提供的网络消息处理流程图;
图 10a是本发明实施例提供的一种通信设备结构图;
图 10b是本发明实施例提供的另一种通信设备结构图;
图 11是本发明实施例提供的通信设备中扫描子模块的结构图;
图 12是本发明实施例提供的解析系统结构图;
图 13是本发明实施例提供的解析系统中编译引擎和处理引擎的结构图; 图 14是本发明实施例提供的计算机系统结构图。 具体实施方式
为了方便理解, 首先对本发明实施例涉及的一些概念做如下介绍: 如图 1 a所示, 协议承载是指第一应用层的消息中承载第二应用层的消息, 所述第二应用层的消息是所述第一应用层消息的消息体, 且所述第一应用层 是所述第二应用层的上一应用层。 具体的, 网络数据的协议栈是层级关系, 下一应用层消息是由上一应用层消息来封装携带的, 例如网络数据首先出现 的是协议 A消息的头部, 然后是协议 A消息的消息体, 该消息体是协议 B消息, 该协议 B消息内部同样分为头部和消息体, 协议 B的消息体是协议 C消息。 这 样协议 A消息承载协议8消息, 协议 B消息承载协议〇消息。
如图 lb所示, 协议切换是数据流中釆用同一应用层中不同应用协议的网 络消息间的协议切换, 换言之, 协议切换涉及的消息是同一应用层的消息; 比如, 在同一条数据流中, 首先出现的协议 A消息, 该协议 A消息起到一定作 用, 例如作为隧道、 协商能力等。 协议 A消息完全处理完毕后, 切换为协议 B 消息, 然后切换为协议〇消息, 然后切换为协议 D消息, 其中, 协议 A与协议 B 与协议 C与协议 D是同一应用层中的不同应用协议, 比如, HTTP协议切换成 RTSP协议, 然后再切换成 RTP协议。
如图 lc所示, 本发明实施例中的应用层协议的是指 TCP/IP层次中的应用 层协议, TCP/IP层次中的应用层协议包括三个层次, 分别相当于开放式系统 互联( Open System Interconnect, OSI )模型的会话层、 表示层和应用层。
本发明实施例中, 预先配置了各应用协议对应的配置文件, 不同应用协 议对应的配置文件结构是基本相同的, 在配置文件中, 设计人员按照协议结 构及解析详细程度需求将一定协议格式的网络消息描述或划分成为一个或多 个区段, 并对每个区段的特点和处理方法进行描述, 应当理解的是, 有些协 议的网络消息是无法划分的, 比如二进制协议, 如域名系统 (Domain Name System, DNS), 没有明显的分隔符, 那么这类协议就只能使用一个区段来表 示。 但是当前网络上大部分网络流量釆用的协议都是可以划分的。
为了使本发明实施例提供的技术方案更加清楚明白, 如下对配置文件进 行介绍:
每个应用协议对应的配置文件包括: 一个或多个区段描述信息, 其中区 段描述信息用于描述区段的特点和处理方法, 区段描述信息的最小信息集合 是区段名称、 区段类型; 如果配置文件中包括多个区段描述信息, 应当理解 的是, 有的区段描述信息可以包括区段名称、 区段类型、 关心数据指示信息 和决策方法, 有的区段描述信息可能仅仅包括区段名称、 区段类型, 有的区 段描述信息可能包括区段名称、 区段类型、 下一个区段信息; 有的区段描述 信息可能包括区段名称、 区段类型、 关心数据指示信息、 决策方法和分割符 (数据分割符、 区段分隔符中的一项或多项);
需要说明的是, 本发明实施例侧重于介绍当应用协议对应的配置文件中 至少包括一个或多个区段描述信息, 而其中至少有一个区段描述信息包括区 段名称、 区段类型、 关心数据指示信息和决策方法时, 如何解析出网络消息 中的关心数据。
请参见图 Id, 为本发明实施例的配置文件的一种结构示意图, 如图 Id所 示, 应用协议对应的配置文件包括:
1. 对应协议的协议全局配置信息, 如协议名称、 是否大小写敏感等等, 实际应用中, 是否大小写敏感可有可无。
2. 描述每个为此协议划分的区段, 区段中包含区段名称、 区段类型、 关 心数据指示信息和决策方法, 区段类型表示该区段的扫描方式, 例如快速扫 描方式、 正则表达式匹配方式、 按一定长度直接跳转方式等等。
3. 每个区段中需要描述本区段的关心数据指示信息, 以便解析时利用该 关心数据指示信息获得相应的关心数据, 并将该关心数据输出到策略匹配模 块做既定策略的匹配, 或者将该关心数据作为决策的依据。
4. 每个区段可以描述决策条件、 决策方法、 决策结果。 其中, 决策条件 包括一个或者多个关心数据; 如果未提供, 则表示不需要决策直接跳转到下 一个区段。 如果当前已经是最后一个区段, 或者决策结果是不需要进一步处 理, 本区段扫描结束后整个协议数据处理完毕。
应当理解的是, 在一种实现方式下, 不同应用协议对应的配置文件可以 存储在计算机媒质中, 其内容可以在系统启动时或正常运行时重新进行加载, 编译成计算机可以直接读取的协议解析辅助数据(如结构体、 链表、 数组等 等), 保存到计算机内存中供协议解析处理时读取。 配置文件的格式可以釆用 任何能描述以上信息的格式, 例如 XML等等。
本发明实施例中引入 "区段" 的概念, 图 2示意出了某个应用协议的网络 消息的区段划分示意图, 其中, 几个矩形框表示区段, 带有各种底紋的矩形 表示不同的关心数据。 从图 2可以看出, 区段 1的关心数据比较详细, 具体到 每个字符可能都是需要的, 其中, 区段 1通常为某个应用协议的首行, 比如 HTTP协议的首行, 具体为 "GET www.abc.com HTTP/1.1" , 则关心数据包括: 请求的方法 "GET"、 URL "www.abc.com" 以及版本号 "1.1"。 因此, 对于该 首行可以釆用正则表达式扫描方法。 从图 2可以看出, 区段 2中的关心数据比 较少,其中,区段 2通常为某个应用协议的消息的头域部分(也称为头域区段), 图中示出了其仅包含两个关心数据, 其余的数据都是可以忽略的, 该区段可 以釆用快速扫描方式, 后续实施例将对快速扫描方式进行详细介绍; 从图 2可 以看出, 区段 3没有关心数据, 其中, 区段 3通常为网络消息的消息体, 不包 括任何关心数据, 不需要解析, 可以整体跳过。
基于前述某个应用协议的网络消息的区段划分方式, 确定该应用协议对 应的配置文件中的区段描述信息, 其包括: 区段描述信息一, 区段描述信息 二和区段描述信息三, 其中, 区段描述信息一所描述的区段为网络消息的首 行, 区段描述信息二所描述的区段为网络消息的头域部分, 区段描述信息三 所描述的区段为网络消息的消息体。 其中:
其中, 区段描述信息一包括: 区段名称、 区段类型和关心数据指示信息, 该区段类型表示该区段釆用正则表达式扫描方式, 该区段描述信息一还可以 包括: 区段分割符, 该区段分割符用于网络服务器从网络消息中分割出首行, 比如, 该区段分隔符可以为 "\r\n" ;
其中, 区段描述信息二包括: 区段名称、 区段类型、 关心数据指示信息 和决策方法, 该区段类型表示该区段釆用快速扫描方式, 该区段描述信息二 还可以包括: 数据分割符和区段分割符。 其中, 数据分割符是用于分割头域 部分中的数据的, 区段分割符用于网络服务器从网络消息中分割出头域部分, 其中, 该区段分割符可以是 "\r\n\r\n"。
其中, 区段描述信息三包括: 区段名称和区段类型, 该区段类型表示该 区段釆用的扫描方式为跳过预定长度的字符, 该预定长度为网络消息的消息 体的长度。 其中, 区段描述信息一中的区段分割符与区段描述信息二中的区 段分割符可以相同, 也可以不同, 不影响本发明的实现。
其中, 上述区段描述信息一, 区段描述信息二和区段描述信息三所描述 的网络消息为第一设备向第二设备发送的网络消息; 可选的, 该应用协议对 应的配置文件中的区段描述信息还可以包括区段描述信息四、 区段描述信息 五和区段描述信息六等, 此时, 该区段描述信息四、 区段描述信息五和区段 描述信息六所描述的网络消息为第二设备向第一设备发送的网络消息, 其中, 区段描述信息四的定义与区段描述信息一的相似, 区段描述信息五的定义与 区段描述信息二的相似, 区段描述信息六的定义与区段描述信息三的相似, 在此不再赘述。
其中, 区段描述信息一中的关心数据指示信息可以包括: 统一资源定位 符 ( Uniform / Universal Resource Locator, URL )和版本号指示信息等;
其中, 区段描述信息二中的关心数据指示信息可以包括: 用于指示下一 个区段的协议类型信息的第一指示信息、 用于指示下一个区段的长度信息的 第二指示信息、 以及用于指示下一个区段的编解码信息的第三指示信息中至 少一个。
需要说明的是, 区段描述信息一也可以有决策方法, 也可以没有决策方 法, 不影响本发明的实现。
其中, 区段描述信息二中的决策方法表示依据不同的决策条件执行不同 的原子方法, 所述原子方法包括: 如下的一项或多项:
1.设置下一个区段: 明确下一个区段是什么,例如会话初始协议(Session
Initiation Protocol, SIP )消息首行区段后是 SIP请求头域区段, 或者是 SIP响应头域区段,如果是 SIP请求区段,则该区段按照请求区段处理, 如果是 SIP响应区段, 则该区段按照响应区段处理。
2.当下一个区段是直接跳过特定长度的类型时, 设置下一个区段为直接 跳过特定长度的区段, 其中, 特定长度是该原子方法所需要的参数, 例如实时流传输协议 ( Real Time Streaming Protocol, RTSP ) 消息的 Content-Length头域指明其消息体部分的长度。
确定一个完整的消息结束: 相当于是完成一个完整的协议处理循环, 其实质动作是设置下一个区段是当前协议类型的第一个区段, 重新循 环。 例如: 一个 HTTP消息处理完之后, 在同一条流继续发送另外一 个 HTTP消息。
3.更改下一个消息的协议类型 (具体可以理解成更改下一个消息的首个 区段的协议类型): 当前数据流的协议类型发生变化, 需要切换到另 外一种类型的协议, 下一个消息就是釆用变化后的协议。 例如, RTSP 消息体区段结束后, 下一个消息为 RTP协议的消息。
4.设置下一个区段开始前需要进行的解码算法: 表明要在下一个区段中 提取信息之前,需要对其实施某种解码算法以获得真正的信息。例如, 一些简单邮件传输协议( Simple Mail Transfer Protocol, SMTP ) 消息 体是经过 base64编码的, 在处理之前需要进行解码。 再如, 一些 HTTP 协议的消息体是经过 gzip压缩处理的, 在处理之前需要进行解压缩。 其中, 原子方法还可以带有参数的, 所述参数用于传递决策的一些结果 供执行原子方法使用。
其中, 区段与区段是有一定顺序关系的, 但是区段之后却不一定是固定 区段, 也不一定是当前协议格式的数据, 可以切换成另外一种协议。 甚至是 在处理完数条消息后才进行协议切换, 前后协议并不是承载关系。
如图 3所示, 网络消息出现的顺序是从上至下, 在一种情况下, 网络服务 器接收的服务器和客户端间传递的网络消息都是应用协议 A的网络消息,应用 协议 A的网络消息包括多个区段; 在另一种情况下, 网络服务器接收的服务器 和客户端间传递的网络消息有多种协议进行切换的情况,如由协议 A切换成协 议 B; 在当前区段处理结束, 下一个区段即将开始之前, 需要进行决策, 以确 定下一个区段是什么, 举例说明, 如图 3所示, 其中, 区段 1和区段 2分别釆用 协议 A的区段描述信息一和区段描述信息二,网络服务器根据区段描述信息二 中的决策方法进行决策, 在一种情况下, 该网络消息存在下一个区段, 决策 结果表示下一个区段是协议 A的网络消息的下一个区段(例如, SIP消息的头 域区段后是消息体区段 ),该网络消息的区段 3可以继续釆用协议 A的区段描述 信息三; 在另一种情况下, 该网络消息不存在下一个区段, 决策结果表示下 一个网络消息是协议 B的网络消息, 相应的, 也分为多个区段, 如协议 B的区 段 1和协议 B的区段 2等, 此时协议 B与协议 A的关系为协议切换, 即将协议 A 切换为协议 B, 相应的, 协议 B的区段 1和区段 2分别釆用协议 B的区段描述信 息一和区段描述信息二。 参阅图 4, 本发明实施例提供一种网络消息解析方法, 该方法包括:
Al、 接收网络消息, 其中网络消息包括一个或多个区段。
在不同实现方式下, 区段与区段之间可以是以分隔符或者给定的偏移长 度分割。
其中, 本发明实施例各步骤的执行主体可以是网络服务器。 所述网络服 务器位于与第一设备和第二设备通信连接, 所接收的网络消息为第一设备向 第二设备发送的上行网络消息, 或者第二设备向第一设备发送的下行网络消 息, 即所接收的网络消息为第一设备与第二设备之间传输的网络消息。
其中, 第一设备可以为客户端, 第二设备为服务器。
A2、 识别出所述网络消息的应用协议类型为第一应用协议。
A3、 从第一应用协议对应的配置文件中的一个区段描述信息所描述的所 述网络消息的当前区段中, 获取所述区段描述信息中的关心数据指示信息所 指示的关心数据。
其中, 该第一应用协议对应的配置文件中的一个区段描述信息可以为上 述区段描述信息二, 该当前区段可以为网络消息的头域部分。
需要说明的是, 当所述第一应用协议为基于行的文本类协议(如 HTTP、 RTSP ), 所述关心数据指示信息为头域名称, 相应的, 所述关心数据指示信息 所指示的关心数据为: 位于对应头域名称后面的头域值, 或者, 对应头域名 称本身所表示的关心数据;
当所述第一应用协议为非文本类协议(如 DNS、 RTP ), 所述关心数据指 示信息为属性名称, 相应的, 所述关心数据指示信息所指示的关心数据为属 性值;
当所述第一应用协议为标签类协议(如 XML、 HTML ), 所述关心数据指 示信息为标签名称, 相应的, 所述关心数据指示信息所指示的关心数据为标 签值。 在本发明实施例的后文中, 以所述第一应用协议为基于行的文本类协议 具体举例说明。
A4、 以所获取的全部或者部分关心数据作为决策条件, 执行所述区段描 述信息中的决策方法, 得到对应的决策结果。
需要说明的是, 在实际应用中, 所获取的关心数据可以是一个或多个, 例如, 获取的关心数据可以是 5-10个, 其中作为决策条件的可以是 2-4个。 应 当理解的是, 所获取的关心数据可以分成如下三种情况:
第一种情况: 所获取的关心数据中的一部分输出给外部应用使用, 而所 获取的关心数据中的另一部分作为决策条件;
第二种情况: 所获取的关心数据既作为决策条件, 又输出给外部应用使 用;
第三种情况: 所获取的关心数据作为决策条件。
其中, 当所述当前区段是所述网络消息的最后一个区段时, 所述决策结 果包括所述网络消息的下一个消息的处理方式, 所述网络消息与所述下一个 消息属于同一应用层, 相应的, 所执行的原子方法可以为更改当前数据流的 协议类型, 即下一个消息釆用与当前网络消息不同的协议类型。
当所述当前区段不是所述网络消息的最后一个区段时, 所述决策结果表 示所述当前区段的下一个区段的处理方式, 相应的, 所执行的原子方法包括: 设置下一个区段、 设置下一个区段的协议类型、 设置下一个区段的长度和设 置下一个区段开始前需要进行的解码算法中的一项或任意组合。
其中, 所述决策方法用于描述依据不同的决策条件执行不同的原子方法; 所述决策条件包括: 一个或者多个关心数据; 所述决策结果包括如下原子方 法中的一个或多个, 以及所述原子方法被执行时所需要的参数;
所执行的原子方法包括: 设置下一个区段、 更改下一个消息的首个区段 的协议类型、 设置下一个区段的协议类型和设置下一个区段开始前需要进行 的解码算法中的一项或任意组合。
在一种实现方式下, 所述决策方法用于描述依据不同的决策条件执行不 同的原子方法; 所述决策条件包括一个或者多个关心数据;
其中, 当所述关心数据指示信息包括: 用于指示下一个区段的协议类型 信息的第一指示信息和用于指示下一个区段的长度信息的第二指示信息, 所 获取的关心数据包括所述协议类型信息和所述长度信息,
则, 以所述协议类型信息和所述长度信息作为决策条件, 且所述长度信 息表示当前区段为最后一个区段, 对应的决策结果包括: 更改下一个消息的 首个区段的协议类型的原子方法, 其中, 所述下一个消息的首个区段的协议 类型为所述协议类型信息所表示的协议类型;
或者, 当所述关心数据指示信息包括: 用于指示下一个区段的协议类型 信息的第一指示信息 , 所获取的关心数据包括所述协议类型信息 ,
则, 以所述协议类型信息作为决策条件, 对应的决策结果包括: 更改下 一个消息的首个区段的协议类型的原子方法, 其中, 所述下一个消息的首个 区段的协议类型为所述协议类型信息所表示的协议类型。
在另一种实现方式下, 所述决策方法用于描述依据不同的决策条件执行 不同的原子方法; 所述决策条件包括: 一个或者多个关心数据;
当所述关心数据指示信息包括: 用于指示下一个区段的协议类型信息的 第一指示信息 , 所获取的关心数据包括所述协议类型信息 ,
则以所述协议类型信息作为决策条件, 对应的决策结果包括: 设置下一 个区段的协议类型的原子方法, 其中, 所述下一个区段的协议类型为所述协 议类型信息所指示的协议类型。
在又一种实现方式下, 所述决策方法用于描述依据不同的决策条件执行 不同的原子方法; 所述决策条件包括: 一个或者多个关心数据;
当所述关心数据指示信息包括: 用于指示下一个区段的长度信息的第二 指示信息, 所获取的关心数据包括所述长度信息,
则以所述长度信息作为决策条件, 对应的决策结果包括设置下一个区段 为直接跳过预定长度的区段的原子方法, 其中所述预定长度为所述长度信息 所指示的长度
在再一种实现方式下, 所述决策方法用于描述依据不同的决策条件执行 不同的原子方法; 所述决策条件包括: 一个或者多个关心数据;
当所述关心数据指示信息包括: 用于指示下一个区段的编解码信息的第 三指示信息, 所获取的关心数据包括所述编解码信息, 则以所述编解码信息作为决策条件, 对应的决策结果包括设置下一个区 段开始前需要进行的解码算法的原子方法, 其中, 所述下一个区段开始前需 要进行的解码算法为所述编解码信息表示的解码算法。
可见, 本发明实施例利用区段描述信息, 获取该区段描述信息所描述的 区段中的关心数据, 并依据关心数据执行该区段描述信息中的决策方法, 决 策出下一个区段或者下一个网络消息的处理方式, 这样, 如果网络消息解析 的方法有变化, 则可以通过修改区段描述信息中所描述的关心数据指示信息 和 /或决策方法来实现; 如果需要增加新的应用协议解析能力时, 则只需要增 加新的应用协议的配置文件, 不需要重新设置实现的软硬件逻辑, 能够做到 无损升级。
为了使本发明提供的上述技术方案更加清楚明白, 如下以网络服务器为 应用服务网关为例描述网络消息解析方法, 参阅图 4, 如下对本发明实施例提 供的上述技术方案进行详细介绍:
Bl、 应用服务网关加载并编译配置文件。
其中, 应用服务网关编译配置文件, 生成计算机直接读取的协议解析辅 助数据并保存。
B2、 应用服务网关接收网络消息。
其中, 该步骤中接收的网络消息可以是服务器发往客户端的网络消息, 也可以是客户端发往服务器的网络消息。
B3、 应用服务网关识别该网络消息所属的应用协议, 假定为第一应用协 议。
具体的, 可以釆用现有技术中的协议识别方法识别该网络消息所属的应 用协议, 比如, 可以釆用传输控制协议(Transmission Control Protocol , TCP ) /用户数据包协议( User Data Protocol, UDP )端口识别方法, 或者, 特征字 识别方法, 或者, 协议行为识别方法等。
B4、 应用服务网关利用该第一应用协议对应的配置文件中区段描述信息 一, 扫描该网络消息, 从该网络消息中获取区段描述信息一中关心数据指示 信息所指示的关心数据。
其中, 区段描述信息一为首行对应的区段描述信息, 区段描述信息一包 括: 区段名称、 区段类型、 关心数据指示信息和区段分割符, 其中, 区段类 型表示该区段釆用的扫描方式为正则表达式扫描方式。 该步骤的具体实现方 式是: 应用服务网关釆用正则表达式扫描方式, 从网络消息中扫描关心数据 指示信息, 直到扫描到区段分割符为止, 其中, 该区段分割符所分割出的区 段为应用协议的首行。 其中, 该区段描述信息一还可以包括下一个区段信息, 比如下一个区段的名称, 在本实施例中假定是区段描述信息二的名称。 该实 施例中区段描述信息一中没有决策方法, 这样, 应用服务网关在扫描该网络 消息的首行结束后, 根据区段描述信息一中的下一个区段的名称, 釆用区段 描述信息二来处理该网络消息头域部分中的数据。
B5、 应用服务网关利用该第一应用协议对应的配置文件中区段描述信息 二, 继续扫描该网络消息, 从该网络消息中区段描述信息二所描述的区段中 获取区段描述信息二中关心数据指示信息所指示的关心数据。
其中, 区段描述信息二为头域部分对应的区段描述信息, 区段描述信息 二包括: 区段名称、 区段类型、 关心数据指示信息、 决策方法、 数据分割符 和区段分割符。 其中, 该区段类型所表示的扫描方式为快速扫描方式, 关心 数据指示信息为头域, 该步骤的具体实现方式是: 应用服务网关釆用快速扫 描方式, 从网络消息中继续扫描区段描述信息二中的关心数据指示信息, 直 到扫描到区段分割符为止, 其中, 该区段分割符所分割出的区段即为区段描 述信息二所描述的区段, 具体是该网络消息的头域部分。 其中, 快速扫描方 式请参见后续实施例的详细介绍。
B6、 应用服务网关以步骤 B5所获得的关心数据作为决策条件, 执行区段 描述信息二中的决策方法, 得到决策结果。
如果在该网络消息的头域部分中未扫描到用于指示协议类型信息的第一 指示信息, 但扫描到用于指示长度信息的第二指示信息时, 则决策出对应的 决策结果, 该决策结果包括: 设置 "下一个区段为直接跳过特定长度的区段" 的原子方法, 其中, 特定长度为该长度信息所指示的长度。 此时下一个区段 所使用的区段描述信息可以是上述区段描述信息三。 其中, 第一指示信息可 以为 Content-Type, 第二指示信息可以为 Content-Length。 需要说明的, 该段中 决定执行哪些原子方法时也可以不以是否扫描到第一指示信息为依据, 即仅 仅以是否扫描到第二指示信息为依据, 换言之, 有的实现方式中利用第二指 示信息就可以做决策。
一种实施方式中, 如果在该网络消息的头域部分中扫描到第一指示信息, 且该网络消息中区段描述信息二所描述的区段(则该头域部分) 为该网络消 息的最后一个区段, 决策出对应的决策结果, 该决策结果包括: 更改当前数 据流的协议类型为所述第一指示信息所指示的协议类型的原子方法, 比如当 前网络消息为 HTTP类型, 下一个网络消息为第一指示信息所指示的协议类 型, 即第二应用协议, 比如 RTSP类型, 此时两个协议的关系为协议切换, 具 体的协议切换的定义和相关描述请参考前述描述, 在此不再赘述。 具体的, 如果在网络消息的头域部分没有扫描到第二指示信息, 则可以表示该头域部 分为该网络消息的最后一个区段。
又一种实施方式中, 如果在该网络消息的头域部分中扫描到第一指示信 息, 且该网络消息中区段描述信息二所描述的区段不是该网络消息的最后一 个区段, 决策出对应的决策结果, 该决策结果包括: 设置下一个区段的协议 类型为第一指示信息所指示的协议类型的原子方法, 比如第二应用协议, 此 时, 下一个区段为当前网络消息的消息体, 此时该网络消息所属的第一应用 协议与消息体所釆用的第二应用协议为承载关系, 具体的协议承载的定义和 相关描述请参考前述描述, 在此不再赘述。
需要说明的是, 对于上述第二种情况, 后续对该网络消息中消息体的操 作完成后, 还需要重新利用第一应用协议的配置文件继续处理下一个网络消 息。
如果该网络消息的头域部分中扫描到用于指示编解码信息的第三指示信 息, 决策出对应的决策结果, 该决策结果包括: 设置下一个区段开始前需要 进行的解码算法的原子方法, 比如, 第三指示信息指示的编解码类型可以为 base64,则在下一个区段开始执行操作前需要先对下一个区段进行解码。其中, 对于简单邮件传输协议( Simple Mail Transfer Protocol, SMTP ), 网络消息的 消息体可以使用该编解码类型对应的解码算法对下一个区段进行解码。
B7、 应用服务网关利用上述各步骤所获取的关心数据, 获取既定策略。 该既定策略是用于对客户端与服务器间传输的网络消息进行处理的策 略, 其可以是阻断、 计费等策略。
可见, 本发明实施例利用区段描述信息, 获取该区段描述信息所描述的 区段中的关心数据, 并依据关心数据执行该区段描述信息中的决策方法, 决 策出下一个区段的处理方式, 这样, 在网络消息解析的方法有变化时, 则可 以通过修改区段描述信息中所描述的关心数据指示信息和 /或决策方法来实 现, 比如, 关心数据有变化, 则需要修改关心数据指示信息, 再如, 对下一 个区段或者下一个网络消息的处理方式有变化时, 则需要修改决策方法; 在 需要增加新的应用协议解析能力时, 则只需要增加新的应用协议的配置文件, 不需要重新设置实现的逻辑, 能够做到无损升级。 请参阅图 6, 如下举实例对本发明实施例提供的网络消息解析方法进行详 细描述:
图 6示出了客户端与服务器之间传输的网络消息: 其中, 粗线条的矩形框 表示一个网络消息, 细线条的矩形区域表示一个区段, 如区段 100到区段 109 , 如图 6所示, HTTP协议消息、 RTSP协议消息可以包括首行区段、 头域部分区 段和消息体部分区段, 例如区段 100对应是首行区段; 区段 101对应头域部分 区段; 应当理解的是, 在实际应用中, 有的消息可以是没有消息体部分区段, 例如区段 101之后就没有消息体, 紧接着响应消息首行。 其中, 加粗字体为关 心数据指示信息, 比如 Content-type , Content-length和 RTP-Info。 加粗字体并 带有下划线的为关心数据指示信息所指示的关心数据,比如 Content-type 所指 示的关心数据 "application/sdp" , Content-length所指示的关心数据 "1903"等。 换言之, 本发明实施例中的关心数据指示信息可以是 Content-Type头域(在区 段 103、 105以加粗字体示意)、 Content-Length头域(在区段 105以加粗字体示 意)、 RTP-Info头域(在区段 108以加粗字体示意), 相应的, 关心数据指示信 息所指示的关心数据本身就是 Content-Type头域的头域值、 Content-Length头域 的头域值、 RTP-Info头域的头域值, 其中, HTTP协议网络消息和 RTSP协议网 络消息中首行的区段分隔符为 "\r\n" , 如图 6中的 HTTP协议网络消息的区段 100、 区段 102, 以及 RTSP协议网络消息的区段 104; HTTP协议网络消息头域 部分的区段分割符为 "\r\n\r\n" , 数据分割符为 "\r\n" , 如图 6中的 HTTP协议 网络消息的区段 101。 区段 109是 RTP格式的数据, 其具体可以是视频数据。 其中, 一种方式中, 一个区段结束之后或下一个区段开始之前需要决策, 在另一种方式中, 一些区段结束之后已经明确下一区段, 是不需要决策的, 比如, 在该区段描述信息中已有下一个区段的名称, 这样默认为当前区段结 束之后就执行下一个区段。 例如区段 100之后一定是区段 101 , 本例中区段 101 之后是需要决策的, 本例中区段 101之后消息就结束了。 如下示出了解析图 6 所示网络消息所利用的配置文件:
<Protocol Name- ΉΤΤΡ" >
<!--对应 100 -->
<Section name- 'HTTP FIRST LINE REQUEST" isFirst- 'true" type- 'PCREX" next_section="HTTP_REQ_HEADER">
<正则表达式 >Λ[Α-Ζ]+ ([Λ \t])(?Fset(url, {-1 })) HTTP/1. l\r\n〈正则表达式 > <!—
HTTP请求首行的正则表达式 - >
<0utput>urK/0utput> <!--输出提取的 URL, 对应 201 -->
</Section>
<!--对应 102 -->
<Section name="HTTP_FIRST_L腿— RESPONSE" isFirst="true" type="PCREX" next_section="HTTP_RSP_HEADER">
<PCREX>AHTTP/1.1 \d{3 } [a-zA-Z]+\r\n</PCREX> <!-- HTTP响应首行的正则表 达式 ― >
</Section>
<!-对应 101 ~>
< Section name="HTTP_REQ_HEADER" type="fastscan" section_delimiter="\r\n\r\n" data_delimiter="\r\n">
interesting char="U"> <!-- 关心数据指示信息包括字符串 "User-Agent" 的开始字 符- >
<Refine-Match>User- Agent: </Refine-Match> <!- 用于精确匹配 User- Agent ~> </Interesting> <Interesting char="C">
<Refine-Match>Content-Length:</Refme-Match>
<!-- 如果遇到 Content-Length, 将 Content-Length的值保存到变量 content— length— >
<SetInt Value Name="content_length"/>
</Interesting>
<Decision> <!-- 决策方法, 在 101结束后执行— >
<Condition>content_length</Condition>
<!-- 口果 content-length不为 0, 那么执行 set next section,
参数是 LEN— TRACKING, content— length -- >
<Rule action="set_next_section" parameter:" LEN TRACKING,
content_length">non_zero</Rule>
<!-- 如果 content-length为 0, 那么执行 end— of— message原子方法, 当前消息解 析结束 - >
<Rule action="end_of_message"> zero</Rule>
</Decision>
</Section>
<!--对应 103— >
< Section name="HTTP_RSP_HEADER" type="fastscan" section—delimiter: "\r\n\r\n" data_delimiter="\r\n">
interesting char=MCM> <!-- 关心数据指示信息包括字符串 "Content-Type" 的开 始字符 ->
<Refine-Match>Content-Type:</Refme-Match> <!-- 用于精确匹配 Content- Type— >
<!-- 口果 Content-Type的头或值为,,application/x-rtsp-tunndled, 则设置 is— rtsp— tunnel哭量为 true ~>
<SetFlag
Figure imgf000020_0001
value="taie">application/x-rtsp-tunnelled</SetFlag>
</Interesting> interesting char="C"> <!- 关心数据指示信息包括字符串 "Content-Length" 的 开始字符- >
<Refine-Match>Content-Length:</Refme-Match> <!-- 用于精确匹配 Content-Length— >
<SetInt Value Name=" content_length"/>
</Interesting>
<Decision> <!-- 决策方法, 在 103结束后执行 ->
<Condition>is_rtsp_tunnel,content_length</Condition>
<!— :¾口果 is_rtsp_tunnel为 true, 且 content-length为 0, Hi)执行 change—protocol 原子方法, 其 数 "RTSP" , 表示协议切换成 RTSP --> ~
<Rule action= " change_protocol" parameter="RTSP">true, zero</Rule>
<!- 口果 is_rtsp_tunnel为 false, 且 content-length不为 0, 则执行
set_next_section原孚方法, 其参数是 "LEN_TRACKING,,和 "content_len th,, , 表示设 i下一个区段为 LEN_TRACKING区— Ϊ殳 , 区段长度为 content_length变量保 存的数值- >
<Rule action="set_next_section" parameter="LEN_TRACKING,
content_length">false, non zero </Rule>
</Decision>
</Section>
<!—直接跳转区段, 名字为 LEN_TRACKING-->
<Section name= "LEN TRACKING" type="skip_length"/>
</Protocol>
<!-- RTSP协议配置 ― >
<Protocol Name- 'RTSP" >
<!--对应 104 -->
<Section name="RTSP_FIRST_LINE" isFirst="true" type="PCREX"
next_section=""RTSP_HEADER"">
<PCREX>ARTSP/(\d\.\d) (? Fset(rtsp_ver, {-1}))) \d{3} [a-zA-Z]+\r\n</PCREX> <!-- RTSP响应首行的正则 λ达式 --> <Output>rtsp_ver</Output> <!-输出提取的 RTSP版本号, 对应 104 --> </Section>
<!-对应 105-->
<Section name- 'RTSP HEADER" type="fastscan">
<Decision> <!-- 决策方法, 在 105结束后执行 ->
<Condition>is_rtp,content_length</Condition>
<Rule action= " change_protocol" parameter="RTP">true, zero</Rule>
<Rule action="set_next_section" parameter="LEN_TRACKING, content_length">false, non zero </Rule>
</Decision>
</Section>
</Protocol>
<!-- RTP协议配置 -->
<Protocol Name- 'RTP" >
</Protocol>
其中, 决策条件是在本区段中获取的全部或者部分关心数据; 下表 1是保 存决策条件的一张示例表(简称为决策表), 换言之就是变量表, 决策条件就 是这些变量值;
为了使上述实例更加清楚, 如下对决策表中的变量进行简单描述:
Figure imgf000022_0001
表 1 如下结合图 6和上述配置文件对本发明实施例提供的网络消息解析方法 进行详细描述:
网络服务器接收到客户端向服务器发送的 HTTP请求消息, 在识别出其应 用协议类型为 HTTP协议后, 查询 HTTP协议对应的配置文件中区段描述信息 一, 该区段描述信息一包括区段名称即 HTTP— FIRST— LINE— REQUEST和区段 类型即正则表达式, 下一个区段信息即 HTTP— REQ— HEADER, 以及关心数据 指示信息即 URL , 利用该区段描述信息一中的区段类型表示的正则表达式扫 描方式, 对该 HTTP请求消息进行扫描, 利用该区段描述信息一中的关心数据 指示信息, 从 HTTP请求消息中获取该关心数据指示信息所指示的关心数据, 直到扫描到区段分割符 "\r\n" , 此时, HTTP请求消息的第一个字符到该区段 分隔符之间的字符为区段 100。 该区段中关心数据指示信息为 URL, 扫描得到 的关心数据为 "/sweeUgp"。
由于该区段描述信息一中包括下一个区段信息, 指示下一个区段为 HTTP— REQ— HEADER, 故不需要决策, 釆用该应用协议的区段描述信息二, 即名称为 "HTTP— REQ— HEADER" 的区段描述信息, 直接处理该 HTTP请求 消息的下一个区段即区段 101。
网络服务器利用该区段描述信息二中区段类型表示的快速扫描方式, 从 区段 100后面的第一个字符开始扫描, 利用该区段描述信息二中的关心数据指 示信息, 继续从该网络消息中扫描该关心数据指示信息所指示的关心数据, 直到扫描到区段分割符 "\r\n\r\n" 为止, 其中, 区段 100的下一个字符到区段 分割符 "\r\n\r\n"之间的字符为区段 101。 其中, 该区段描述信息二中的关心 数据指示信息为 "User- Agent"和 "Content-Length" , Content-Length指示的是 HTTP消息的消息体的长度, User-Agent指示的是用户浏览器代理, 如果在该 区段 101中没有扫描到 "Content-Length" , 也就是说该 HTTP请求消息中没有 HTTP消息的消息体, 由于没有扫描到 Content-Length, 则 Content-Length为 0 , 所以该区段 101中执行的原子方法为 end— of— message , 即表示消息结束, 复位 上表 1中所有标志位与整型值为初始值。
网络服务器接收到服务器向客户端发送的 HTTP响应消息即 "HTTP/1.0 200 0K", 查询 HTTP协议对应的配置文件中区段描述信息四, 该区段描述信息四 包括区段名称即 "HTTP— FIRST— LINE— RESPONSE" , 区段类型即正则表达式 , 下一个区段信息即 "HTTP— RSP— HEADER" , 利用该区段描述信息四中的关心 数据指示信息, 釆用区段描述信息四中的区段类型表示的正则表达式, 从 HTTP响应消息中扫描该关心数据指示信息所指示的关心数据, 直到扫描到区 段分割符为 "\r\n" , 此时, HTTP响应消息的第一个字符到该区段分隔符之间 的字符为区段 102 (当前区段 102是 HTTP响应消息首行), 依据该区段描述信 息四中的关心数据指示信息, 该区段中需要提取的关心数据是 HTTP版本号。 由于该区段描述信息四中包括下一个区段信息, 指示下一个区段为 HTTP— RSP— HEADER, 故不需要决策, 直接釆用该应用协议的区段描述信息 五 (即区段名称为 "HTTP— RSP— HEADER" 的区段描述信息), 处理该 HTTP 响应消息的下一个区段即区段 103。 网络服务器查询该区段描述信息五, 利用该区段描述信息五中的关心数 据指示信息, 釆用区段描述信息五中的区段类型表示的快速扫描方式, 从 HTTP响应消息中扫描该关心数据指示信息所指示的关心数据, 直到扫描到区 段分割符为 "\r\n\r\n" , 其中, 该区段分割符所分割出的区段为 103。 其中, 该 区段描述信息中的关心数据指示信息为 "Content-Type"和 "Content-Length" , 该实例中, 在该区段 103中扫描到 "Content-Type" 头域, 对其头域值进行精 确匹配字符串 "x-rtsp-tunnel" , 若匹配成功, 则设置变量 "is rtsp tunnel" 的 值为真 (例如在上表 1中记录变量 "is— rtsp— tunnel" 的值为 true ), 由于没有扫 描到 "Content-Length" , 所以记录变量 Content-Length的值为 0 (例如在上表 1 中记录变量 Content-Length的值为 0 , 或者, 不用更新上表 1中变量 Content-Length的值;需要说明的是;如果在区段 103中扫描到 "Content-Length" 头域,就将其头域值保存到变量 "content-length"中), 然后以 "is— rtsp— tunnel" 为真, Content-Length的值为 0作为决策条件, 执行决策方法, 如下:
"<Decision>
<Condition>is_rtsp_tunnel,content_length</Condition>
<Rule action= " change_protocol" parameter="RTSP">true, zero</Rule>
<Rule action=" set next section" parameter="LEN_TRACKINQ content_length">false, non zero </Rule>
</Decision>"
可见, 当 "is— rtsp— tunnel" 为真, Content-Length的值为 0时, 决策出要执 行的原子方法为 "change_protocol" , 该原子方法是下一网络消息的协议类型切 换为 RTSP ,所以客户端和服务器间传输的下一个网络消息就釆用 RTSP对应的 配置文件来进行解析。 其逻辑含义是, 由于 Content-Length头域值表明此消息 不包含消息体, 因此不是协议承载关系, 进一步的, Content-Type头域值表明 了此 HTTP消息的作用是 RTSP隧道, 因此后续网络消息需要切换成 RTSP。
网络服务器接收服务器向客户端发送的 RTSP消息即 "RTSP/1.0 200 OK", 查询 RTSP协议对应的配置文件中的区段描述信息一, 该区段描述信息 一包括区段名称即 RTSP— FIRST— LINE、 区段类型即正则表达式, 下一个区段 信息即 RTSP— HEADER和关心数据指示信息,利用该区段描述信息一中的区段 类型表示的正则表达式扫描方式, 扫描该 RTSP网络消息, 直到扫描到区段分 割符 "\r\n"为止, 其中, 该区段分割符 "\r\n"所分割出的区段为区段 104, 依 据该区段描述信息一中的关心数据指示信息, 该区段中需要提取的关心数据 是 RTSP版本号。 由于该区段描述信息一中包括下一个区段信息, 指示下一个 区段为 RTSP— HEADER, 故不需要决策, 直接釆用该 RTSP下协议对应的配置 文件中的区段描述信息二(其中区段名称为 "RTSP— HEADER" ),处理该 RTSP 消息的下一个区段即区段 105。
网络服务器利用该 RTSP协议对应的区段描述信息二中区段类型表示的快 速扫描方式, 继续扫描该 RTSP网络消息, 直到扫描到区段分割符为 "\r\n\r\n" 为止, 其中, 该区段分割符分割出的区段为区段 105。 如果扫描到该区段描述 信息二中关心数据指示信息, 则将该关心数据指示信息所指示的关心数据提 取出来,比如关心数据指示信息为 "Vsrc"、 "Content-Type"和" Content-Length" , 在此例子中在该区段中扫描到 "Vsrc"、 "Content-Type" 和 "Content-Length" , "Content-Type" 头域值指示协议切换为会话描述协议(Session Description Protocol, SDP ), SDP协议的消息中没有关心数据, 本例中可以忽略。 由于头 域值没有指示实时传输协议( Real Time Protocol, RTP )协议,所以变量 "is— rtp" 的值为默认值, 保持为 "Content-Length" 头域值指示的值为 1903 , 所 以记录变量 Content-Length的值为 1903 ( 例如在上表 1中记录变量 Content-Length的值为 1903 ) , 然后以 "is— rtp" 的值为 4叚, "Content-Length" 的值为 1903作为决策条件, 执行决策方法, 如下:
<Decision>
<Condition>is_rtp,content_length</Condition>
<Rule action:" switch _protocol" parameter="RTP">true, zero</Rule> <Rule action="set_next_section" parameter="LEN_TRACKING, content_length">false, non zero </Rule>
</Decision>
需要说明的是: 如上决策方法是应用于区段 105和区段 108的, 包含两个 关心数据及对应的原子方法。 可见, 针对 105区段来说, 从上述决策方法可以 看出, 当 "is— rtp" 为假, Content-Length的值非 0时, 决策得出: 确定下一区 段为直接跳转区段, 直接跳转的字符数为 1903。 则后续区段 106的字符数为 1903 , 网络服务器不对其进行任何处理, 直接跳过。
由于 106区段结束后就没有后续区段了,说明此 RTSP消息结束, 则后续消 息釆用本应用协议第一个区段的区段描述信息 (即 RTSP协议对应的区段描述 信息一) 来处理。 因此 107区段的处理方式与 104区段一致。
同理, 处理到区段 108时, 发现存在 RTP-Info头域, 决策后协议类型要切 换为 RTP。 具体的, 网络服务器利用该 RTSP协议对应的区段描述信息二中区 段类型表示的快速扫描方式, 继续扫描该 RTSP网络消息, 直到扫描到区段分 割符为 "\r\n\r\n" 为止, 其中, 该区段分割符分割出的区段为区段 108。 如果 扫描到该区段描述信息二中关心数据指示信息, 则将该关心数据指示信息所 指示的关心数据提取出来, 在此例子中在该区段中扫描到 "RTP-Info " , "RTP-Info" 头域值为 url=rtsp:〃10.13.4.3:554/sweet.3gp/, 该头域值可以不是 关心数据, 也不需要参与后续既定策略的匹配。 由于关心数据指示信息本身 指示了 RTP协议, 所以设置变量 "is— rtp" 的值为真, 然后以 "is— rtp" 的值为 真, "Content-Length" 的值为 0作为决策依据, 执行决策方法, 如下:
<Decision>
<Condition>is_rtp,content_length</Condition> <Rule action:" switch _protocol" parameter="RTP">true, zero</Rule> <Rule action="set_next_section" parameter="LEN_TRACKINQ content_length">false, non zero </Rule>
</Decision>
决策逻辑为, 当 "is— rtp" 为真, content-length值为 0时, 决策出:协议切换 成 RTP协议。 需要说明的是, 在本例中, 因为没有扫描到 Content-Length头域, 所以 content-length的值为 0。
需要说明的是, 上述给出的决策逻辑仅仅适用于本实例, 在实际应用中, 可以有其他用于决策的变量, 也可以有其他决策方法, 不影响本发明的实现。 在另一具体实施例中, 决策方法的决策结果为切换协议或者承载协议, 具体的, 配置文件中某个区段的描述信息可以包括如下内容,
<EndSectionTreatment>
<Parameters>HTTP_IS_RTSP,HTTP_IS_MIME,HTTP_IS_MMS,HTTP_IS_KJAVA</Parameters> <Decision action="switch— Protocol" protocol="RTSP">TRUE,FALSE,FALSE,FALSE< Decision>; 表示本协议切换成 RTSP;
<Decisionaction="Embedded— Protocor'protocol="MIME">FALSE,TRUE,FALSE,FALSE< Decision>; 表示本协议 载多用途网际邮件扩充协议(Multipurpose Internet Mail Extensions, MIME ) , 下一步将自动跳转到 MIME协议的第一个 Section, 当整 个 MIME处理完毕后还会跳转回来本协议继续处理
<Decision action="Embedded— Protocol" protocol="MMS">FALSE,FALSE,TRUE,FALSE< Decision>; 表示本协议承载多媒体服务协议(Multi Media Serve, MMS ) , 下一步将自动 跳转到 MMS协议的第一个 Section, 当整个 MMS处理完毕后还会跳转回来本 协议继续处理
<Decisionaction=''Embedded_Protocol"protocol="KJAVA">FALSE,FALSE,FALSE,TRUE< Decision> 表示本协议承载协议 KJAVA, 下一步将自动跳转到 KJAVA协议的第一个 Section, 当整个 KJAVA处理完毕后还会跳转回来本协议继续处理
< EndSectionTreatment>
图 7和图 8示出了本发明实施例提供的快速扫描方法, 该快速扫描方法可 用于扫描头域部分中的关心数据指示信息, 其具体包括:
Cl、 从区段的第一个字符开始, 跳转预设长度的字符;
其中, 该区段可以是一网络消息的头域部分。
其中, 所述预设长度由区段中的数据分隔符的长度决定, 数据分隔符的 长度越长, 则该预定长度就越长, 一般的, 预定长度〈数据分隔符 +关心的字 符长度 n; 其中, 关心数据指示信息可以是一串字符串, 该关心的字符为字符 串的头部字符, 其可以为字符串的前 n个字符, 其中, n大于或者等于 1 , 比如 n等于 2时, 其包括该字符串的第一个字符和第二个字符; 其中, 数据分割符 可以记载在该区段描述信息中, 数据分隔符与区段分割符不同, 数据分割符 是用于分割同一区段中的数据的, 区段分割符是用于从网络消息中分割出对 应区段描述信息的区段的, 比如从 HTTP网络消息中分割出 HTTP首行和 HTTP 头域部分。 具体的, 数据分割符可以为 "\r\n" , 区段分割符可以为 "\r\n\r\n"。 其中, 如果数据分隔符为 "\r\n" , 关心的字符取一个, 则预设长度可以为 3 , 即每次跳转 3个字符。
C2、 当跳转到的字符是所述字符串中的字符时, 判断位于所述跳转到的 字符前面、 且与所述跳转到的字符最近的非字符串中的字符是否是数据分割 符, 如果是, 利用所述跳转到的字符, 釆用字符串匹配方法, 在所述区段中 匹配到所述字符串, 将匹配的字符串所指示的关心数据发送给策略匹配模块, 结束本流程。
其中, 在 HTTP头域部分中匹配的字符串可以是 " Content-Type " 或者 "Content-Length"。
C3、 当跳转到的字符是数据分割符时, 判断位于所述跳转到的字符后面、 且与所述跳转到的字符最近的 n个非数据分隔符的字符是否是所述字符串中 的前 n个字符, 如果是, 根据所述字符串中的前 n个字符, 釆用字符串匹配方 法, 在所述区段中匹配到所述字符串, 将匹配的字符串所指示的关心数据发 送给策略匹配模块, 结束本流程。
其中, n可以为 1 , 或者 2, 或者其他任意数值, 不影响本发明的实现。 需要说明的是, 上述快速扫描算法可以适用于任何协议, 其完全可以用 硬件实现, 比如用 FPGA实现。 如下结合上述实例, 对本发明实施例提供的快速扫描方法进行详细描述: 比如图 6中的区段 105:
RTSP/1.0 200 OK\r\n
CSeq: lV\n
Date: Wed, 31 Mar 2004 01 :18:50 GMT\r\n
Vsrc: htt :〃10.13.4.3 : 8888/viewsource/eqDreAl \r\n
Last-Modified: Wed, 10 Mar 2004 02:07:17 GMT\r\n
Content-base: rts :〃10.13.4.3:554/ sweet.3 gp/\r\n
Vary: User-Agent, ClientID\r\n
Content-type: application/ sdp\r\n
Content-length: 1903\r\n\r\n
假定关心的字符是 V和 C, 即字符串 "Vsrc" 和 "Content-type" 的首个字 符,每次跳转的预设长度为 3个字符,数据分割符为 "\r\n" ,在扫描 Content-type 时, 会出现如下几种情况:
1、 如果跳转到的字符为 Content-Type之前的 "\r" , 此时需要检查后续两 个字符是否是 "\n" 和 "C" , 如果是, 再对剩余字符 "ontent-Type" 进行精确 匹配,具体可以釆用字符串匹配方法进行匹配,如果匹配成功,将 Content-Type 所指示的关心数据输出到策略匹配模块, 即将 "application/sdp" 输出到策略 匹配模块。
2、 如果跳转到的字符为 Content-Type之前的 "\n" , 此时需要检查后续字 符是否是 " C " , 以及前面的字符是否是 "\r" , 如果是, 再对剩余字符
"ontent-Type"进行精确匹配, 具体可以釆用字符串匹配方法进行匹配, 如果 匹配成功, 将 Content-Type所指示的关心数据输出到策略匹配模块。
3、 如果跳转到的字符为 "C" , 此时需要检查前面两个字符是否是 "\r" 和 "\n" , 如果是, 再对剩余字符 "ontent-Type" 进行 ^"确匹配, 具体可以釆 用字符串匹配方法进行匹配, 如果匹配成功, 将 Content-Type所指示的关心数 据输出到策略匹配模块。
上述是以关心的字符为 1个字符为例进行描述, 其关心的字符也可以是两 个字符, 即字符串的头两个字符, 即 "Co" 和 "Vs"。 本发明上述实施例提供的网络消息解析方法可以应用到固网络、 移动网 络的接入网、 核心网中各种网关设备, 如可使用在应用服务网关上, 其作用 是用于获取网络消息中关心数据并针对该网络消息实施各种既定策略, 例如 阻断、 限流、 重定向、 内容计费等策略, 其中, 图 9示出了应用服务网关的多 个网络消息处理流程, 具体包括:
El、 应用服务网关接收网络消息。
具体的, 客户端使用 UE通过认证登录到无线接入网, 并从核心网获得应 用服务器的 IP地址, 然后向该应用服务器发送网络消息。
E2、 应用服务网关识别出该网络消息所使用的应用协议。
具体可以釆用 TCP/UDP端口识别方法, 或者, 特征字识别方法, 或者, 协议行为识别方法。
E3、 应用服务网关将该网络消息的五元组保存到流表中。
其中, 网络消息的五元组包括: 源 IP、 目的 IP、 源端口、 目的端口和传输 协议类型,传输协议类型可以是 TCP或者 UDP。应用服务网关将该网络消息的 源 IP、 目的 IP、 源端口、 目的端口和传输协议类型保存到流表中。
E4、 应用服务网关利用步骤 E2中识别出的应用协议所对应的配置文件, 从网络消息中提取关心数据。
其中, 应用服务网关从网络消息中提取关心数据的方法具体是依据应用 协议对应的配置文件, 釆用正则表达式方式或者快速扫描方式在网络消息的 对应区段中找到关心数据, 并利用找到的关心数据作为决策依据执行决策方 法, 决策出网络消息的下一个区段或者下一个网络消息的处理方式, 进而釆 用正则表达式方式或者快速扫描方式在下一个区段或者下一个网络消息中找 到关心数据, 具体的实现方式可参见图 5所对应实施例的相应描述, 在此不再 赘述。
E5、 应用服务网关利用从网络消息中提取到的关心数据进行策略匹配。 其中, 既定策略包括: 阻断、 限流、 重定向、 计费等策略。
E6、 应用服务网关执行匹配到的既定策略。
比如, 对于上述图 6所示的网络消息, 应用服务网关在处理区段 101中解 析出 URL "/sweeUgp" , 但是仅仅釆用该 URL没有匹配到任何策略, 直到应用 服务网关处理区段 108时,匹配到 RTP-Info头域,该应用服务网关利用 RTP-Info 头域与 "/sweeUgp" , 才获知服务器与客户端交互的是视频文件, 匹配到计费 策略, 后续就可以针对区段 109的内容进行计费了。
E7、 该应用服务网关接收到后续网络消息, 将新接收到的网络消息的源 IP、 目的 IP、 源端口、 目的端口和传输协议类型与保存到流表中五元组的进行 匹配, 如果匹配成功, 则利用步骤 E6中已匹配到的既定策略对该网络消息进 行处理; 如果匹配不成功, 则将该网络消息当作一个新的网络消息, 重新执 行步骤 E2-E6, 在此不再赘述。
该实施例可以对客户端和服务器间的网络消息进行解析并匹配出既定策 略, 以便利用该既定策略对客户端与服务器的通信进行计费等处理。 参阅图 10a和图 10b, 本发明实施例提供一种通信设备, 该通信设备可以 包括:
通信模块 81 , 用于接收网络消息, 所述网络消息包括一个或多个区段; 识别模块 82, 用于识别出所述网络消息的应用协议类型为第一应用协议; 解析模块 83 , 用于从第一应用协议对应的配置文件中的一个区段描述信 息所描述的所述网络消息的当前区段中, 获取所述区段描述信息中的关心数 据指示信息所指示的关心数据; 以所获取的全部或者部分关心数据作为决策 条件, 执行所述区段描述信息中的决策方法, 得到对应的决策结果; 其中, 当所述当前区段是所述网络消息的最后一个区段时, 所述决策结果包括所述 网络消息的下一个消息的处理方式, 所述网络消息与所述下一个消息属于同 一应用层。
其中, 参阅图 10a, 该解析模块 83包括:
解析子模块 8311 , 用于从第一应用协议对应的配置文件中的一个区段描 述信息所描述的所述网络消息的当前区段中, 获取所述区段描述信息中的关 心数据指示信息所指示的关心数据;
和, 决策子模块 8312 , 用于以所获取的全部或者部分关心数据作为决策 条件, 执行所述区段描述信息中的决策方法, 得到对应的决策结果,
其中, 所述决策方法用于描述依据不同的决策条件执行不同的原子方法; 所述决策条件包括一个或者多个关心数据; 在一种实现方式下, 所述关心数据指示信息包括: 用于指示下一个区段 的协议类型信息的第一指示信息和用于指示下一个区段的长度信息的第二指 示信息, 所获取的关心数据包括所述协议类型信息和所述长度信息;
相应的, 所述解析模块 83包括:
解析子模块 8311具体用于从第一应用协议对应的配置文件中的一个区段 描述信息所描述的所述网络消息的当前区段中, 获取所述区段描述信息中的 关心数据指示信息所指示的关心数据; 其中, 所述关心数据指示信息包括: 用于指示下一个区段的协议类型信息的第一指示信息和用于指示下一个区段 的长度信息的第二指示信息, 所获取的关心数据包括所述协议类型信息和所 述长度信息;
决策子模块 8312具体用于以所述协议类型信息和所述长度信息作为决策 条件, 且所述长度信息表示当前区段为最后一个区段, 决策出对应的决策结 果, 所述决策结果包括: 更改下一个消息的首个区段的协议类型的原子方法, 其中, 所述下一个消息的首个区段的协议类型为所述协议类型信息所表示的 协议类型;
或者, 在另一种实现方式下, 所述关心数据指示信息包括: 用于指示下 一个区段的协议类型信息的第一指示信息, 所获取的关心数据包括所述协议 类型信息; 相应的, 所述解析模块 83包括:
解析子模块 8311具体用于从第一应用协议对应的配置文件中的一个区段 描述信息所描述的所述网络消息的当前区段中, 获取所述区段描述信息中的 关心数据指示信息所指示的关心数据; 其中, 所述关心数据指示信息包括: 用于指示下一个区段的协议类型信息的第一指示信息, 所获取的关心数据包 括所述协议类型信息,
决策子模块 8312具体用于以所述协议类型信息作为决策条件, 决策出对 应的决策结果, 所述决策结果包括: 更改下一个消息的首个区段的协议类型 的原子方法, 其中, 所述下一个消息的首个区段的协议类型为所述协议类型 信息所表示的协议类型。 此时第一指示信息可以是 Content-Type头域, 其所指 示的关心数据为位于该头域后面的具体的协议类型。 或者, 第一指示信息为
RTP-info头域, 其所指示的关心数据为 RTP。
在另一种实施方式中, 所述解析模块还用于当所述当前区段不是所述网 络消息的最后一个区段时, 所述决策结果表示所述当前区段的下一个区段的 处理方式。 原子方法所需要使用的参数来表征, 其中, 原子方法包括设置下一个区段的 原子方法、 更改下一个消息的首个区段的协议类型的原子方法、 设置下一个 区段的协议类型的原子方法和设置下一个区段开始前需要进行的解码算法的 原子方法中的一项或任意组合。 其中, 这些原子方法所执行功能的描述请参 见方法实施例的相应描述, 在此不再赘述。 尤其需要说明的是, 当所述当前 区段不是所述网络消息的最后一个区段时, 相应的决策结果可以用设置下一 个区段的原子方法、 设置下一个区段的协议类型的原子方法和设置下一个区 段开始前需要进行的解码算法的原子方法中的一项或任意组合来表示, 具体 是哪一种原子方法, 是根据具体的决策条件来确定的。
其中, 在一种实施方式中, 所述关心数据指示信息包括: 用于指示下一 个区段的协议类型信息的第一指示信息, 所获取的关心数据包括所述协议类 型信息;
相应的, 所述解析模块 83包括:
解析子模块 8311具体用于从第一应用协议对应的配置文件中的一个区段 描述信息所描述的所述网络消息的当前区段中, 获取所述区段描述信息中的 关心数据指示信息所指示的关心数据; 其中, 所述关心数据指示信息包括: 用于指示下一个区段的协议类型信息的第一指示信息, 所获取的关心数据包 括所述协议类型信息;
决策子模块 8312具体用于以所述协议类型信息作为决策条件, 决策出对 应的决策结果, 所述决策结果包括: 设置下一个区段的协议类型的原子方法, 其中, 所述下一个区段的协议类型为所述协议类型信息所指示的协议类型。
其中, 另一种实施方式中, 所述关心数据指示信息包括: 用于指示下一 个区段的长度信息的第二指示信息, 所获取的关心数据包括所述长度信息; 相应的, 所述解析模块 83包括:
解析子模块 8311具体用于从第一应用协议对应的配置文件中的一个区段 描述信息所描述的所述网络消息的当前区段中, 获取所述区段描述信息中的 关心数据指示信息所指示的关心数据; 其中, 所述关心数据指示信息包括: 用于指示下一个区段的长度信息的第二指示信息, 所获取的关心数据包括所 述长度信息;
决策子模块 8312具体用于以所述长度信息作为决策条件, 决策出对应的 决策结果, 所述决策结果包括: 设置下一个区段为直接跳过预定长度的区段 的原子方法, 其中所述预定长度为所述长度信息所指示的长度。 其中, 直接 跳过预定长度的区段可以是上述图 6所对应配置文件中的 LEN— TRACKING , 具体实现请参见方法实施例的相应描述。
其中, 又一种实施方式中, 所述关心数据指示信息包括: 用于指示下一 个区段的编解码信息的第三指示信息, 所获取的关心数据包括所述编解码信 息;
相应的, 所述解析模块 83包括:
解析子模块 8311具体用于从第一应用协议对应的配置文件中的一个区段 描述信息所描述的所述网络消息的当前区段中, 获取所述区段描述信息中的 关心数据指示信息所指示的关心数据; 其中, 所述关心数据指示信息包括: 用于指示下一个区段的编解码信息的第三指示信息, 所获取的关心数据包括 所述编解码信息;
决策子模块 8312具体用于以所述编解码信息作为决策条件, 决策出对应 的决策结果, 所述决策结果包括: 设置下一个区段开始前需要进行的解码算 法的原子方法, 其中, 所述下一个区段开始前需要进行的解码算法为所述编 解码信息表示的解码算法。 其中, 编解码类型可以是 base64等。
其中, 该实施例中配置文件的结构请参见上述方法实施例的相应描述, 在此不再赘述。 上述多种实施方式可以分别实施, 也可以彼此结合实施, 不 影响本发明的实现。
具体的, 所述第一区段描述信息包括: 区段名称, 区段类型, 所述关心 数据指示信息和所述决策方法, 所述区段类型表示所述当前区段所使用的扫 描方式, 具体可以是快速扫描方式、 正则表达式扫描方式等等; 在一种实现 方式下, 参见图 10b, 所述解析模块 83 , 包括:
扫描子模块 8321 , 用于以所述区段类型表示的扫描方式, 从所述区段名 称对应的所述当前区段中扫描到所述关心数据指示信息;
获取子模块 8322 , 用于获取所扫描到的关心数据指示信息所指示的关心 数据;
决策子模块 8323 , 用于获取所扫描到的关心数据指示信息所指示的关心 数据, 利用所述全部或部分关心数据, 执行所述第一区段描述信息中的决策 方法, 得到对应的决策结果。
为了进一步的提高解析的效率, 本发明实施例还提供快速扫描技术, 参 阅图 11 , 所述扫描子模块 8321包括:
快速扫描子模块 8321a, 用于从所述区段名称对应的当前区段的第一个字 符开始, 跳转特定长度的字符, 当跳转到的字符是数据分割符时, 判断位于 所述跳转到的字符后面、 且与所述跳转到的字符最近的 n个非数据分隔符的字 符是否是所述关心数据指示信息中的前 n个字符; 其中, n大于或者等于 1 ; 当 跳转到的字符是所述关心数据指示信息中的字符时, 判断位于所述跳转到的 字符前面、 且与所述跳转到的字符最近的非关心数据指示信息中的字符是否 是数据分割符;
精确匹配子模块 8321b, 用于在判断位于所述跳转到的字符后面、 且与所 述跳转到的字符最近的 n个非数据分隔符的字符是否是所述关心数据指示信 息中的前 n个字符的判断结果为是时, 根据所述关心数据指示信息中的前 n个 字符, 在所述当前区段中匹配到所述关心数据指示信息; 在判断位于所述跳 转到的字符前面、 且与所述跳转到的字符最近的非关心数据指示信息中的字 符是否是数据分割符的判断结果为是时, 利用所述跳转到的字符, 在所述当 前区段中匹配到所述关心数据指示信息。 其中, 扫描子模块的具体操作可参 见图 7、 图 8所对应的实施例的详细描述。
为了实现对第一设备与第二设备间的网络消息进行阻断、 计费等管理, 所述通信设备还可以包括: 策略匹配模块 84和策略执行模块 85 , 其中:
策略匹配模块 84 , 用于利用所述关心数据, 确定所述网络消息所适用的 既定策略;
策略执行模块 85 , 用于利用所述既定策略, 对所述网络消息所在的数据 流进行操作。 其中, 既定策略可以是计费策略等。
需要说明的是, 本发明实施例的通信设备可以是应用到固定、 移动网络 的接入网、 核心网中各种网关设备, 具体可以是应用服务网关, 但不限于此。 可以作为实现网关设备各功能的支撑技术, 如流量控制、 内容计费、 内容适 配、 网络安全防护、 无线信令风暴抑制、 负荷分担等等。
本发明实施例利用配置文件中区段所釆用的区段描述信息中的头域, 获 取该区段中的关心数据, 然后利用该关心数据, 执行决策方法, 决策出下一 个区段或者下一个消息的处理方法,这样,如果网络消息解析的方法有变化, 则可以通过修改区段描述信息中所描述的关心数据指示信息和 /或决策方法 来实现; 如果需要增加新的应用协议解析能力时, 则只需要增加新的应用协 议的配置文件, 不需要重新设置实现的逻辑, 能够做到无损升级。
请参阅图 12 , 为本发明实施例提供一种解析系统, 包括:
编译引擎 91 , 用于将配置文件编译成所述处理引擎能识别的协议解析辅 助数据; 其中, 不同的应用协议类型对应不同的配置文件;
在一种实现方式下, 编译引擎 91支持系统初始化时加载配置文件, 也支 持系统在线时更新配置文件。
处理引擎 92 , 用于接收网络消息, 所述网络消息包括一个或多个区段; 识别出所述网络消息的应用协议类型为第一应用协议; 从所述第一应用协议 对应的协议解析辅助数据中第一区段描述信息所描述的所述网络消息的当前 区段中, 获取第一区段描述信息中的关心数据指示信息所指示的关心数据; 以所获取的全部或者部分关心数据作为决策条件, 执行所述第一区段描述信 息中的决策方法, 得到决策结果; 其中, 当所述当前区段是所述网络消息的 最后一个区段时, 所述决策结果包括所述网络消息的下一个消息的处理方式, 所述网络消息与所述下一个消息属于同一应用层。
应当了解的是, 处理引擎 92决策出决策结果后, 该决策结果用原子方法 以及所述原子方法被执行时所需要的参数表征, 换言之, 处理引擎 92决策出 原子方法和参数后, 将执行这些原子方法。 其中, 所述应用协议对应的配置文件包括: 一个或多个区段描述信息, 所述区段描述信息包括区段名称, 区段类型, 关心数据指示信息和决策方法, 其中, 所述区段类型表示区段所使用的扫描方式; 所述关心数据指示信息包 括: 用于指示下一个区段的协议类型信息的第一指示信息, 用于指示下一个 区段的长度信息的第二指示信息, 用于指示下一个区段的编解码信息的第三 指示信息中的一个或任意组合;
所述决策方法用于描述依据不同的决策条件执行不同的原子方法, 所述 原子方法包括: 设置下一个区段、 设置下一个区段的协议类型、 设置下一个 区段的长度、 确定一个完整的消息结束、 更改当前数据流的协议类型和设置 下一个区段开始前需要进行的解码算法中的一项或任意组合。
为了实现对内容的合理管理, 该解析系统还包括: 内存管理器 93 (图中 以 93a和 93b示意), 用于管理编译引擎和处理引擎使用的内存, 所述编译引擎 和处理引擎使用不同的内存区域或者相同的内存区域。 在一种实现方式, 通 过部署不同的内存管理器来分别管理编译引擎 91和处理引擎 92所使用的内 存。
为了加载配置文件, 该解析系统还包括: 加载器 94 , 用于从内部储存设 备或外部储存设备中读取配置文件并加载到所述编译引擎 91。
如图 13所示, 为了将述配置文件编译成机器能读取的协议解析辅助数据, 该编译引擎 91可以包括:
快速扫描编译器 911 , 用于将配置文件中描述的各区段中的头域编译成机 器能读取的协议解析辅助数据, 并输出快速扫描表; 所述快速扫描表包括: 所述头域的前 n个字符和区段中的数据分割符对应的协议解析辅助数据;
精确匹配编译器 912, 用于将多模匹配算法编译成机器能读取的协议解析 辅助数据;
逻辑决策编译器 913 , 用于将配置文件中的决策方法编译成机器能读取的 协议解析辅助数据。
还可以包括: 正则表达式编译器 914 , 用于将正则表达式编译成机器能读 取的协议解析辅助数据, 以便在区段类型表示区段所使用的扫描方式为正则 表达式扫描方式时, 处理引擎 92利用该编译成的协议解析辅助数据, 在相应 区段查找关心数据指示信息。
如图 13所示, 所述处理引擎 92可以包括:
快速扫描模块 921 , 用于从所述区段名称对应的当前区段的第一个字符开 始, 跳转特定长度的字符, 根据所述快速扫描表, 判断跳转到的字符是数据 分割符还是所述关心数据指示信息中的前 n个字符中的字符, 当跳转到的字符 是数据分割符时, 判断位于所述跳转到的字符后面、 且与所述跳转到的字符 最近的 n个非数据分隔符的字符是否是所述关心数据指示信息中的前 n个字 符; 当跳转到的字符是所述关心数据指示信息中的前 n个字符中的字符时, 判 断位于所述跳转到的字符前面、 且与所述跳转到的字符最近的非关心数据指 示信息中的字符是否是数据分割符; 其中, n大于或者等于 1 ;
精确匹配模块 922 , 用于在判断位于所述跳转到的字符后面、 且与所述跳 转到的字符最近的 n个非数据分隔符的字符是否是所述关心数据指示信息中 的前 n个字符的判断结果为是时, 根据所述关心数据指示信息中的前 n个字符, 执行所述协议解析辅助数据中的所编译成的多模匹配算法, 以在所述当前区 段中匹配到所述关心数据指示信息; 在判断位于所述跳转到的字符前面、 且 与所述跳转到的字符最近的非关心数据指示信息中的字符是否是数据分割符 的判断结果为是时, 利用所述跳转到的字符, 执行所述协议解析辅助数据中 的所编译成的多模匹配算法, 以在所述当前区段中匹配到所述关心数据指示 信息;
决策器 923 , 用于根据匹配到的关心数据指示信息, 获取所述关心数据指 示信息所指示的关心数据, 利用所述全部或部分关心数据, 执行所述第一区 段描述信息中的决策方法所编译成的协议解析辅助数据, 得到决策结果。
该处理引擎 92还可以包括: 正则表达式匹配模块 924, 用于在区段类型表 示区段所使用的扫描方式为正则表达式扫描方式时, 利用正则表达式所对应 的协议解析辅助数据, 在相应区段查找关心数据指示信息。
为了使外部模块能利用关心数据匹配既定策略, 该处理引擎 92还包括: 输出模块 925 , 用于将所获取的关心数据输出到外部, 具体可以是输出给策略 匹配模块, 策略匹配模块利用所述处理引擎所获取的关心数据, 确定所述网 络消息所适用的既定策略; 然后策略执行模块利用所述既定策略, 对所述网 络消息所在的数据流进行操作。
为了快速确定后续网络消息的应用协议类型, 该解析系统还包括:
TCP/UDP流表管理模块(图中未示出 ), 用于维护该网络消息的五元组与 第一应用协议类型的对应关系, 网络消息的五元组包括: 源 IP、 目的 IP、 源端 口、 目的端口和传输协议类型, 传输协议类型可以是 TCP或者 UDP。 后续再接 收到与该五元组匹配的网络消息, 就直接确定其釆用该五元组所对应的应用 协议类型。
TCP/UDP流表管理模块, 还用于记录该五元组与所述既定策略的对应关 系。 后续再接收到与该五元组匹配的网络消息, 就直接对该网络消息釆用该 既定策略。
配置文件可以存储在计算机媒质中, 其内容可以在系统启动时或正常运 行时重新进行加载, 编译成计算机可以直接读取的数据结构形式(是从人类 可以读取的格式编译成计算可以读取的格式。 各种数据结构, 如结构体、 链 表、 数组等等)保存到计算机内存中供协议处理时读取。 此文件的格式可以 釆用任何能描述以上信息的格式, 例如 XML等等。 配置文件的加载、 编译过 程与数据处理过程是分开的, 并不是解释性脚本。 请参阅图 14, 为本发明实施例提供一种计算机系统的结构示意图, 应当 理解的是, 下面针对本发明实施例的解析系统部署于计算机的情况下进行介 绍;
1. 所有软件处理逻辑代码都在系统初始化阶段从存储器 62加载到处理器
63处。 同时, 解析后的配置文件各区段信息数据结构保存在存储器 65 处。
2. 当系统从接口 68收到网络消息时, 直接通过系统总线 15写入到存储 器 65, 并通过中断技术通知处理器 63收到网络消息事件。
3. 处理器 63釆用软件逻辑开始对存储器 65中的网络消息进行处理, ^ 括应用协议识别、 解析等本发明提到的各步骤。
4. 处理完毕后,网络消息被从 65通过 15回到 68发送到网络下一跳设备, 或者由于应用丟弃策略直接被丟弃掉而不再发送到下一跳设备。 应当理解的是, 将从当前区段中获取的全部或部分关心的数据作为决策 的依据, 这些信息可以保存到计算机内存中。
综上所述, 本发明上述实施例中, 利用配置文件描述各种协议类型的网 络消息以及相应的处理方法, 在获得很高的灵活性的同时, 也很大程度的提 高了处理能力。
灵活性体现在:
1.配置文件描述能力不仅仅局限于特定协议的格式, 还可以支持协议切 换, 预先编解码等等复杂逻辑, 但是配置文件逻辑却很简洁。
2.使用配置文件描述网络数据处理的方法, 当出现新的协议数据处理需 求,或者对已经支持的协议数据处理方法切换时,不需要重新修改程序实现, 仅需要更改配置文件, 重新加载配置文件即可达到提升协议数据处理能力的 目的, 即。
高性能体现在:
釆用快速扫描技术, 解析的速度与分隔符的长度有关, 不必每次仅跳跃 一个字符, 获得更高的性能。
本领域普通技术人员可以理解: 实现上述各方法实施例的全部或部分步 骤可以通过程序指令相关的硬件来完成。 前述的程序可以存储于一计算机可 读取存储介质中。 该程序在执行时, 执行包括上述各方法实施例的步骤; 而 前述的存储介质包括: ROM、 RAM, 磁碟或者光盘等各种可以存储程序代 码的介质。
以上对本发明实施例所提供的网络消息解析方法及通信设备进行了详细 实施例的说明只是用于帮助理解本发明的方法及其核心思想; 同时, 对于本 领域的一般技术人员, 依据本发明的思想, 在具体实施方式及应用范围上均 会有改变之处, 综上所述, 本说明书内容不应理解为对本发明的限制。

Claims

权 利 要 求 书
1、 一种网络消息解析方法, 其特征在于, 包括:
接收网络消息, 所述网络消息包括一个或多个区段;
识别出所述网络消息的应用协议类型为第一应用协议;
从第一应用协议对应的配置文件中的一个区段描述信息所描述的所述网 络消息的当前区段中, 获取所述区段描述信息中的关心数据指示信息所指示 的关心数据;
以所获取的全部或者部分关心数据作为决策条件, 执行所述区段描述信 息中的决策方式, 得到对应的决策结果;
其中, 当所述当前区段是所述网络消息的最后一个区段时, 所述决策结 果包括所述网络消息的下一个消息的处理方式, 所述网络消息与所述下一个 消息属于同一应用层。
2、 根据权利要求 1所述的方法, 其特征在于,
所述关心数据指示信息为头域名称, 所述关心数据指示信息所指示的关 心数据为位于对应头域后面的头域值;
或者, 所述关心数据指示信息为头域名称, 所述关心数据指示信息所指 示的关心数据为对应头域名称本身所表示的关心数据;
或者, 所述关心数据指示信息为属性名称, 所述关心数据指示信息所指 示的关心数据为属性值;
或者, 所述关心数据指示信息为标签名称, 所述关心数据指示信息所指 示的关心数据为标签值。
3、 根据权利要求 1所述的方法, 其特征在于,
所述决策方式用于描述依据不同的决策条件执行不同的原子动作; 所述 决策条件包括: 一个或者多个关心数据; 所述决策结果包括如下原子动作中 的一个或多个, 以及所述原子动作被执行时所需要的参数;
所执行的原子动作包括: 设置下一个区段、 更改下一个消息的首个区段 的协议类型、 设置下一个区段的协议类型和设置下一个区段开始前需要进行 的解码算法中的一项或任意组合。
4、 根据权利要求 1所述的方法, 其特征在于, 所述决策方式用于描述依据不同的决策条件执行不同的原子动作; 所述 决策条件包括一个或者多个关心数据;
其中, 当所述关心数据指示信息包括: 用于指示下一个区段的协议类型 信息的第一指示信息和用于指示下一个区段的长度信息的第二指示信息, 所 获取的关心数据包括所述协议类型信息和所述长度信息,
则, 以所述协议类型信息和所述长度信息作为决策条件, 且所述长度信 息表示当前区段为最后一个区段, 对应的决策结果包括: 更改下一个消息的 首个区段的协议类型的原子动作, 其中, 所述下一个消息的首个区段的协议 类型为所述协议类型信息所表示的协议类型;
或者, 当所述关心数据指示信息包括: 用于指示下一个区段的协议类型 信息的第一指示信息 , 所获取的关心数据包括所述协议类型信息 ,
则, 以所述协议类型信息作为决策条件, 对应的决策结果包括: 更改下 一个消息的首个区段的协议类型的原子动作, 其中, 所述下一个消息的首个 区段的协议类型为所述协议类型信息所表示的协议类型。
5、 根据权利要求 1所述的方法, 其特征在于,
当所述当前区段不是所述网络消息的最后一个区段时, 所述决策结果表 示所述当前区段的下一个区段的处理方式。
6、 根据权利要求 5所述的方法, 其特征在于,
所述决策方式用于描述依据不同的决策条件执行不同的原子动作; 所述 决策条件包括: 一个或者多个关心数据;
当所述关心数据指示信息包括: 用于指示下一个区段的协议类型信息的 第一指示信息 , 所获取的关心数据包括所述协议类型信息 ,
则以所述协议类型信息作为决策条件, 对应的决策结果包括: 设置下一 个区段的协议类型的原子动作, 其中, 所述下一个区段的协议类型为所述协 议类型信息所指示的协议类型。
7、 根据权利要求 5所述的方法, 其特征在于,
所述决策方式用于描述依据不同的决策条件执行不同的原子动作; 所述 决策条件包括: 一个或者多个关心数据;
当所述关心数据指示信息包括: 用于指示下一个区段的长度信息的第二 指示信息, 所获取的关心数据包括所述长度信息,
则以所述长度信息作为决策条件, 对应的决策结果包括设置下一个区段 为直接跳过预定长度的区段的原子动作, 其中, 所述预定长度为所述长度信 息所指示的长度。
8、 根据权利要求 5所述的方法, 其特征在于,
所述决策方式用于描述依据不同的决策条件执行不同的原子动作; 所述 决策条件包括: 一个或者多个关心数据;
当所述关心数据指示信息包括: 用于指示下一个区段的编解码信息的第 三指示信息, 所获取的关心数据包括所述编解码信息,
则以所述编解码信息作为决策条件, 对应的决策结果包括: 设置下一个 区段开始前需要进行的解码算法的原子动作, 其中, 所述下一个区段开始前 需要进行的解码算法为所述编解码信息表示的解码算法。
9、 根据权利要求 1至 8任一项所述的方法, 其特征在于,
所述区段描述信息包括: 区段名称, 区段类型, 所述关心数据指示信息 和所述决策方式, 所述区段类型表示所述当前区段所使用的扫描方式;
所述从第一应用协议对应的配置文件中的一个区段描述信息所描述的所 述网络消息的当前区段中, 获取第一区段描述信息中的关心数据指示信息所 指示的关心数据, 包括:
以所述区段类型表示的扫描方式, 从所述区段名称对应的所述当前区段 中扫描到所述关心数据指示信息, 获取所述关心数据指示信息所指示的关心 数据。
10、 根据权利要求 9所述的方法, 其特征在于, 所述区段类型表示快速扫 描方式;
所述以所述区段类型表示的扫描方式, 从所述区段名称对应的所述当前 区段中扫描到所述关心数据指示信息包括:
从所述区段名称对应的当前区段的第一个字符开始, 跳转特定长度的字 付;
当跳转到的字符是数据分割符时, 判断位于所述跳转到的字符后面、 且 与所述跳转到的字符最近的 η个非数据分隔符的字符是否是所述关心数据指 示信息中的前 n个字符, 如果是, 根据所述关心数据指示信息中的前 n个字符, 在所述当前区段匹配到所述关心数据指示信息, 其中, n大于或者等于 1 ; 当跳转到的字符是所述关心数据指示信息中的前 n个字符中的字符时, 判 断位于所述跳转到的字符前面、 且与所述跳转到的字符最近的非关心数据指 示信息中的字符是否是数据分割符, 如果是, 利用所述跳转到的字符, 在所 述当前区段中匹配到所述关心数据指示信息。
11、 一种通信设备, 其特征在于, 包括:
通信模块, 用于接收网络消息, 所述网络消息包括一个或多个区段; 识别模块, 用于识别出所述网络消息的应用协议类型为第一应用协议; 解析模块, 用于从第一应用协议对应的配置文件中的一个区段描述信息 所描述的所述网络消息的当前区段中, 获取所述区段描述信息中的关心数据 指示信息所指示的关心数据; 以所获取的全部或者部分关心数据作为决策条 件, 执行所述区段描述信息中的决策方式, 得到对应的决策结果;
其中, 当所述当前区段是所述网络消息的最后一个区段时, 所述决策结 果包括所述网络消息的下一个消息的处理方式, 所述网络消息与所述下一个 消息属于同一应用层。
12、 根据权利要求 11所述的通信设备, 其特征在于,
所述决策方式用于描述依据不同的决策条件执行不同的原子动作; 所述 决策条件包括一个或者多个关心数据;
所述解析模块包括:
解析子模块, 用于从第一应用协议对应的配置文件中的一个区段描述信 息所描述的所述网络消息的当前区段中, 获取所述区段描述信息中的关心数 据指示信息所指示的关心数据; 其中, 所述关心数据指示信息包括: 用于指 示下一个区段的协议类型信息的第一指示信息和用于指示下一个区段的长度 信息的第二指示信息, 所获取的关心数据包括所述协议类型信息和所述长度 信息;
决策子模块, 用于以所述协议类型信息和所述长度信息作为决策条件, 且所述长度信息表示当前区段为最后一个区段, 决策出对应的决策结果, 所 述决策结果包括: 更改下一个消息的首个区段的协议类型的原子动作, 其中, 所述下一个消息的首个区段的协议类型为所述协议类型信息所表示的协议类 型;
或者,
所述解析模块包括:
解析子模块, 用于从第一应用协议对应的配置文件中的一个区段描述信 息所描述的所述网络消息的当前区段中, 获取所述区段描述信息中的关心数 据指示信息所指示的关心数据; 其中, 所述关心数据指示信息包括: 用于指 示下一个区段的协议类型信息的第一指示信息, 所获取的关心数据包括所述 协议类型信息,
决策子模块, 用于以所述协议类型信息作为决策条件, 决策出对应的决 策结果, 所述决策结果包括: 更改下一个消息的首个区段的协议类型的原子 动作, 其中, 所述下一个消息的首个区段的协议类型为所述协议类型信息所 表示的协议类型。
13、 根据权利要求 11所述的通信设备, 其特征在于,
所述解析模块, 还用于当所述当前区段不是所述网络消息的最后一个区 段时, 所述决策结果表示所述当前区段的下一个区段的处理方式。
14、 根据权利要求 13所述的通信设备, 其特征在于,
所述决策方式用于描述依据不同的决策条件执行不同的原子动作; 所述 决策条件包括一个或者多个关心数据;
所述解析模块包括:
解析子模块, 用于从第一应用协议对应的配置文件中的一个区段描述信 息所描述的所述网络消息的当前区段中, 获取所述区段描述信息中的关心数 据指示信息所指示的关心数据; 其中, 所述关心数据指示信息包括: 用于指 示下一个区段的协议类型信息的第一指示信息, 所获取的关心数据包括所述 协议类型信息;
决策子模块, 用于以所述协议类型信息作为决策条件, 决策出对应的决 策结果, 所述决策结果包括: 设置下一个区段的协议类型的原子动作, 其中, 所述下一个区段的协议类型为所述协议类型信息所指示的协议类型。
15、 根据权利要求 13所述的通信设备, 其特征在于, 所述决策方式用于描述依据不同的决策条件执行不同的原子动作; 所述 决策条件包括一个或者多个关心数据;
所述解析模块包括:
解析子模块, 用于从第一应用协议对应的配置文件中的一个区段描述信 息所描述的所述网络消息的当前区段中, 获取所述区段描述信息中的关心数 据指示信息所指示的关心数据; 其中, 所述关心数据指示信息包括: 用于指 示下一个区段的长度信息的第二指示信息, 所获取的关心数据包括所述长度 信息;
决策子模块, 用于以所述长度信息作为决策条件, 决策出对应的决策结 果, 所述决策结果包括: 设置下一个区段为直接跳过预定长度的区段的原子 动作, 其中所述预定长度为所述长度信息所指示的长度。
16、 根据权利要求 13所述的通信设备, 其特征在于,
所述决策方式用于描述依据不同的决策条件执行不同的原子动作; 所述 决策条件包括一个或者多个关心数据;
所述解析模块包括:
解析子模块, 用于从第一应用协议对应的配置文件中的一个区段描述信 息所描述的所述网络消息的当前区段中, 获取所述区段描述信息中的关心数 据指示信息所指示的关心数据; 其中, 所述关心数据指示信息包括: 用于指 示下一个区段的编解码信息的第三指示信息, 所获取的关心数据包括所述编 解码信息;
决策子模块, 用于以所述编解码信息作为决策条件, 决策出对应的决策 结果, 所述决策结果包括: 设置下一个区段开始前需要进行的解码算法的原 子动作, 其中, 所述下一个区段开始前需要进行的解码算法为所述编解码信 息表示的解码算法。
17、 根据权利要求 11所述的通信设备, 其特征在于,
所述第一区段描述信息包括: 区段名称, 区段类型, 所述关心数据指示 信息和所述决策方式, 所述区段类型表示所述当前区段所使用的扫描方式; 所述解析模块, 包括:
扫描子模块, 用于以所述区段类型表示的扫描方式, 从所述区段名称对 应的所述当前区段中扫描到所述关心数据指示信息;
获取子模块, 用于获取所扫描到的关心数据指示信息所指示的关心数据; 决策子模块, 用于利用所述全部或部分关心数据, 执行所述第一区段描 述信息中的决策方式, 得到对应的决策结果。
18、 根据权利要求 17所述的通信设备, 其特征在于,
所述扫描子模块包括:
快速扫描子模块, 用于从所述区段名称对应的当前区段的第一个字符开 始, 跳转特定长度的字符, 当跳转到的字符是数据分割符时, 判断位于所述 跳转到的字符后面、 且与所述跳转到的字符最近的 n个非数据分隔符的字符是 否是所述关心数据指示信息中的前 n个字符; 其中, n大于或者等于 1 ; 当跳转 到的字符是所述关心数据指示信息中的字符时, 判断位于所述跳转到的字符 前面、 且与所述跳转到的字符最近的非关心数据指示信息中的字符是否是数 据分割符;
精确匹配子模块, 用于在判断位于所述跳转到的字符后面、 且与所述跳 转到的字符最近的 n个非数据分隔符的字符是否是所述关心数据指示信息中 的前 n个字符的判断结果为是时, 根据所述关心数据指示信息中的前 n个字符, 在所述当前区段中匹配到所述关心数据指示信息; 在判断位于所述跳转到的 字符前面、 且与所述跳转到的字符最近的非关心数据指示信息中的字符是否 是数据分割符的判断结果为是时, 利用所述跳转到的字符, 在所述当前区段 中匹配到所述关心数据指示信息。
19、 根据权利要求 11至 18任一项所述的通信设备, 其特征在于, 所述通信设备还包括: 策略匹配模块和策略执行模块;
策略匹配模块, 用于利用所述关心数据, 确定所述网络消息所适用的既 定策略;
策略执行模块, 用于利用所述既定策略, 对所述网络消息所在的数据流 进行操作。
20、 一种解析系统, 其特征在于, 包括: 编译引擎和处理引擎, 所述编译引擎, 用于将配置文件编译成所述处理引擎能识别的协议解析 辅助数据; 其中, 不同的应用协议类型对应不同的配置文件; 所述处理引擎, 用于接收网络消息, 所述网络消息包括一个或多个区段; 识别出所述网络消息的应用协议类型为第一应用协议; 从所述第一应用协议 对应的协议解析辅助数据中一个区段描述信息所描述的所述网络消息的当前 区段中, 获取所述区段描述信息中的关心数据指示信息所指示的关心数据; 以所获取的全部或者部分关心数据作为决策条件, 执行所述区段描述信息中 的决策方式, 得到对应的决策结果; 其中, 当所述当前区段是所述网络消息 的最后一个区段时, 所述决策结果包括所述网络消息的下一个消息的处理方 式, 所述网络消息与所述下一个消息属于同一应用层。
21、 根据权利要求 20所述的系统, 其特征在于,
所述应用协议对应的配置文件包括:
一个或多个区段描述信息, 所述区段描述信息包括区段名称, 区段类型, 关心数据指示信息和决策方式, 其中, 所述区段类型表示区段所使用的扫描 方式;
所述决策方式用于描述依据不同的决策条件执行不同的原子动作; 所述 决策条件包括: 一个或者多个关心数据; 所述决策结果包括如下原子动作中 的一个或多个, 以及所述原子动作被执行时所需要的参数;
所执行的原子动作包括: 设置下一个区段、 更改下一个消息的首个区段 的协议类型、 设置下一个区段的协议类型和设置下一个区段开始前需要进行 的解码算法中的一项或任意组合。
22、 根据权利要求 20或 21所述的系统, 其特征在于, 还包括:
内存管理器, 用于管理所述编译引擎和所述处理引擎使用的内存, 所述 编译引擎和处理引擎使用不同的内存区域或者相同的内存区域。
23、 根据权利要求 20或 21所述的系统, 其特征在于, 还包括:
加载器, 用于从内部储存设备或外部储存设备中读取所述配置文件并加 载到所述编译引擎。
24、 根据权利要求 20或 21所述的系统, 其特征在于,
所述编译引擎包括:
快速扫描编译器, 用于将配置文件中描述的各区段中的关心数据指示信 息编译成机器能读取的协议解析辅助数据, 并输出快速扫描表; 所述快速扫 描表包括: 所述关心数据指示信息的前 n个字符和区段中的数据分割符对应的 协议解析辅助数据;
精确匹配编译器, 用于将多模匹配算法编译成机器能读取的协议解析辅 助数据;
逻辑决策编译器, 用于将配置文件中的决策方式编译成机器能读取的协 议解析辅助数据。
25、 根据权利要求 24所述的系统, 其特征在于,
所述处理引擎包括:
快速扫描模块, 用于从所述区段名称对应的当前区段的第一个字符开始, 跳转特定长度的字符, 根据所述快速扫描表, 判断跳转到的字符是数据分割 符还是所述关心数据指示信息中的前 n个字符中的字符, 当跳转到的字符是数 据分割符时, 判断位于所述跳转到的字符后面、 且与所述跳转到的字符最近 的 n个非数据分隔符的字符是否是所述关心数据指示信息中的前 n个字符; 当 跳转到的字符是所述关心数据指示信息中的前 n个字符中的字符时, 判断位于 所述跳转到的字符前面、 且与所述跳转到的字符最近的非关心数据指示信息 中的字符是否是数据分割符; 其中, n大于或者等于 1 ;
精确匹配模块, 用于在判断位于所述跳转到的字符后面、 且与所述跳转 到的字符最近的 n个非数据分隔符的字符是否是所述关心数据指示信息中的 前 n个字符的判断结果为是时, 根据所述关心数据指示信息中的前 n个字符, 执行所述协议解析辅助数据中所编译成的多模匹配算法, 以在所述当前区段 中匹配到所述关心数据指示信息; 在判断位于所述跳转到的字符前面、 且与 所述跳转到的字符最近的非关心数据指示信息中的字符是否是数据分割符的 判断结果为是时, 利用所述跳转到的字符, 执行所述协议解析辅助数据中所 编译成的多模匹配算法, 以在所述当前区段中匹配到所述关心数据指示信息; 决策器, 用于根据匹配到的关心数据指示信息, 获取所述关心数据指示 信息所指示的关心数据, 利用所述全部或部分关心数据, 执行所述协议解析 辅助数据中的所编译成的区段描述信息中的决策方式, 得到决策结果。
26、 根据权利要求 20所述的系统, 其特征在于,
所述处理引擎还包括: 输出模块, 用于将所获取的关心数据输出到外部。
PCT/CN2012/085494 2011-11-30 2012-11-29 网络消息解析方法及通信设备 WO2013079003A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP12853692.7A EP2770687B1 (en) 2011-11-30 2012-11-29 Network message parsing method and communication device
US14/292,086 US9819719B2 (en) 2011-11-30 2014-05-30 Method for parsing network message and communication device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201110389258.1 2011-11-30
CN201110389258.1A CN102413141B (zh) 2011-11-30 2011-11-30 网络消息解析方法及通信设备

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/292,086 Continuation US9819719B2 (en) 2011-11-30 2014-05-30 Method for parsing network message and communication device

Publications (1)

Publication Number Publication Date
WO2013079003A1 true WO2013079003A1 (zh) 2013-06-06

Family

ID=45914991

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2012/085494 WO2013079003A1 (zh) 2011-11-30 2012-11-29 网络消息解析方法及通信设备

Country Status (4)

Country Link
US (1) US9819719B2 (zh)
EP (1) EP2770687B1 (zh)
CN (1) CN102413141B (zh)
WO (1) WO2013079003A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111371655A (zh) * 2020-04-07 2020-07-03 中移雄安信息通信科技有限公司 深度报文检测方法、dpi设备、中转设备、系统及存储介质
CN114760256A (zh) * 2022-04-14 2022-07-15 曙光网络科技有限公司 数据处理方法、装置、设备及存储介质
CN115412532A (zh) * 2022-08-15 2022-11-29 深圳市风云实业有限公司 一种sip及扩展协议会话控制流识别及处理的方法

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102413141B (zh) * 2011-11-30 2014-10-08 华为技术有限公司 网络消息解析方法及通信设备
CN102761543B (zh) * 2012-06-27 2016-03-16 北京中创信测科技股份有限公司 一种实现sip协议通用编解码的方法和装置
CN102916967B (zh) * 2012-10-29 2015-11-25 华为技术有限公司 协议解析的方法和装置
CN103166973B (zh) * 2013-03-27 2016-06-22 华为技术有限公司 协议识别的方法和装置
CN105337932A (zh) * 2014-06-30 2016-02-17 杭州迪普科技有限公司 一种web应用防护方法及装置
US10289384B2 (en) 2014-09-12 2019-05-14 Oracle International Corporation Methods, systems, and computer readable media for processing data containing type-length-value (TLV) elements
JP5925287B1 (ja) * 2014-12-26 2016-05-25 株式会社Pfu 情報処理装置、方法およびプログラム
CN107251517B (zh) * 2015-03-13 2020-10-16 华为技术有限公司 接入网系统、处理数据包的方法及装置
US10735438B2 (en) * 2016-01-06 2020-08-04 New York University System, method and computer-accessible medium for network intrusion detection
CN105721451B (zh) * 2016-01-27 2019-03-05 深圳市盛弘电气股份有限公司 一种可拓展的Modbus协议解析方法及装置
US10193802B2 (en) 2016-09-13 2019-01-29 Oracle International Corporation Methods, systems, and computer readable media for processing messages using stateful and stateless decode strategies
US10341411B2 (en) * 2017-03-29 2019-07-02 Oracle International Corporation Methods, systems, and computer readable media for providing message encode/decode as a service
CN107370806B (zh) * 2017-07-12 2020-11-24 北京京东尚科信息技术有限公司 Http状态码监控方法、装置、存储介质和电子设备
CN107704567A (zh) * 2017-09-29 2018-02-16 郑州云海信息技术有限公司 一种二进制文件的解析方法、装置、设备及存储介质
CN108933779B (zh) * 2018-05-23 2021-12-07 和芯星通科技(北京)有限公司 输入混合数据流识别方法和装置、计算机可读存储介质
CN109167726B (zh) * 2018-08-23 2021-11-05 新华三技术有限公司 报文的数据预取方法、装置及网络设备
CN109889375A (zh) * 2019-01-23 2019-06-14 中国银行股份有限公司 业务报文校验方法、装置及计算机存储介质
US11561997B2 (en) 2019-03-13 2023-01-24 Oracle International Corporation Methods, systems, and computer readable media for data translation using a representational state transfer (REST) application programming interface (API)
US11095691B2 (en) 2019-06-26 2021-08-17 Oracle International Corporation Methods, systems, and computer readable media for establishing a communication session between a public switched telephone network (PSTN) endpoint and a web real time communications (WebRTC) endpoint
CN110225062A (zh) * 2019-07-01 2019-09-10 北京微步在线科技有限公司 一种监控网络攻击的方法和装置
CN110300193B (zh) * 2019-07-01 2021-07-06 北京微步在线科技有限公司 一种获取实体域名的方法和装置
CN111092785A (zh) * 2019-12-05 2020-05-01 深圳市任子行科技开发有限公司 数据监测方法及装置
CN114818656B (zh) * 2022-06-30 2022-09-23 深圳华锐分布式技术股份有限公司 基于灰度升级的二进制文件解析方法、装置、设备及介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070150478A1 (en) * 2005-12-23 2007-06-28 Microsoft Corporation Downloading data packages from information services based on attributes
WO2010145853A1 (en) * 2009-06-17 2010-12-23 Telefonaktiebolaget Lm Ericsson (Publ) Network cache architecture
CN102413141A (zh) * 2011-11-30 2012-04-11 华为技术有限公司 网络消息解析方法及通信设备

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5907678A (en) * 1997-05-07 1999-05-25 International Business Machines Corporation Client/server system in which protocol caches for multiple sessions are selectively copied into a common checkpoint cache upon receiving a checkpoint request
US6175867B1 (en) * 1998-03-23 2001-01-16 Mci World Com, Inc. System and method for managing networks addressed via common network addresses
US6483804B1 (en) * 1999-03-01 2002-11-19 Sun Microsystems, Inc. Method and apparatus for dynamic packet batching with a high performance network interface
US6598034B1 (en) * 1999-09-21 2003-07-22 Infineon Technologies North America Corp. Rule based IP data processing
US6581108B1 (en) * 1999-11-30 2003-06-17 Lucent Technologies Inc. Managing multiple private data networks using network and payload address translation
US6862267B1 (en) * 2000-05-08 2005-03-01 Nortel Networks Limited Determining network addresses and ports using table from a description file
US6952425B1 (en) 2000-11-14 2005-10-04 Cisco Technology, Inc. Packet data analysis with efficient and flexible parsing capabilities
US7136385B2 (en) * 2001-12-07 2006-11-14 International Business Machines Corporation Method and system for performing asymmetric address translation
US7284039B2 (en) * 2002-12-17 2007-10-16 International Business Machines Corporation Apparatus and method for flexible web service deployment
US7565497B1 (en) * 2005-05-26 2009-07-21 Sun Microsystems, Inc. Coarse write barrier control mechanism
US7570661B2 (en) 2005-06-14 2009-08-04 Microsoft Corporation Script-based parser
US8010695B2 (en) * 2005-12-30 2011-08-30 Sap Ag Web services archive
CN101577704A (zh) * 2008-05-08 2009-11-11 北京东华合创数码科技股份有限公司 一种网络应用层协议识别方法和系统
CN101557329B (zh) * 2009-05-27 2011-05-11 杭州迪普科技有限公司 一种基于应用层的数据分割方法及装置
US9871807B2 (en) 2009-06-12 2018-01-16 Microsoft Technology Licensing, Llc Generic protocol decoder for generic application-level protocol signatures
US8831014B2 (en) * 2009-09-26 2014-09-09 Cisco Technology, Inc. Providing services at a communication network edge
CN102098331B (zh) * 2010-12-29 2013-06-19 北京锐安科技有限公司 一种还原web类应用内容的方法及其系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070150478A1 (en) * 2005-12-23 2007-06-28 Microsoft Corporation Downloading data packages from information services based on attributes
WO2010145853A1 (en) * 2009-06-17 2010-12-23 Telefonaktiebolaget Lm Ericsson (Publ) Network cache architecture
CN102413141A (zh) * 2011-11-30 2012-04-11 华为技术有限公司 网络消息解析方法及通信设备

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111371655A (zh) * 2020-04-07 2020-07-03 中移雄安信息通信科技有限公司 深度报文检测方法、dpi设备、中转设备、系统及存储介质
CN114760256A (zh) * 2022-04-14 2022-07-15 曙光网络科技有限公司 数据处理方法、装置、设备及存储介质
CN114760256B (zh) * 2022-04-14 2024-01-30 曙光网络科技有限公司 数据处理方法、装置、设备及存储介质
CN115412532A (zh) * 2022-08-15 2022-11-29 深圳市风云实业有限公司 一种sip及扩展协议会话控制流识别及处理的方法
CN115412532B (zh) * 2022-08-15 2023-07-21 深圳市风云实业有限公司 一种sip及扩展协议会话控制流识别及处理的方法

Also Published As

Publication number Publication date
US20140280924A1 (en) 2014-09-18
EP2770687A1 (en) 2014-08-27
EP2770687A4 (en) 2014-10-29
CN102413141B (zh) 2014-10-08
EP2770687B1 (en) 2016-03-16
US9819719B2 (en) 2017-11-14
CN102413141A (zh) 2012-04-11

Similar Documents

Publication Publication Date Title
WO2013079003A1 (zh) 网络消息解析方法及通信设备
WO2018107943A1 (zh) 一种网络访问控制方法、装置及系统
US8935424B2 (en) Method and apparatus for signaling presentation description updates in HTTP streaming
US8782068B2 (en) Method, apparatus and system for protocol identification
US8966078B2 (en) Method and apparatus for detecting tethering in a communications network
EP3539269B1 (en) Node type based control of assistance for data streaming
Shang et al. NDN. JS: A javascript client library for named data networking
WO2012171166A1 (zh) 协议解析方法及装置
CN111510476B (zh) 通信方法、装置、计算机设备和计算机可读存储介质
WO2023103318A1 (zh) 媒体流传输方法和系统
JP2023109838A (ja) 外部システム統合のためのシステムおよび方法
CN105324978A (zh) 控制dash客户端速率适配
RU2621961C2 (ru) Шлюз и соответствующие ему способ, компьютерная программа и носитель информации
WO2017088460A1 (zh) 一种业务报文传输控制的方法、设备及系统
US20020181507A1 (en) System and method of incremental parsing
CN113704647A (zh) 跳转多种类型页面的方法、装置及电子设备
US8738801B2 (en) Methods and apparatus for updating index information while adding and updating documents in a distributed network
WO2011157007A1 (zh) 多媒体数据内容的适配转发方法及装置
CN117062043A (zh) 数据处理方法、装置、计算机可读介质及终端设备
CN113079029B (zh) 配置信息订阅方法及装置
US9143352B2 (en) Method and device for monitoring service quality in a network
CN117240735B (zh) 一种音视频流的过滤方法、系统、设备及存储介质
WO2012167477A1 (zh) 一种IPv6报文处理方法及装置
EP4340318A1 (en) Routing obtaining method and apparatus, storage medium, and electronic apparatus
CN116233317A (zh) 面向网络流量的实时VoLTE语音还原、检测方法和装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12853692

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2012853692

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE