TECHNICAL FIELD

This application relates to the field of network traffic analysis, and in particular, to a traffic analysis method, a common service traffic attribution method, a corresponding computer system.

BACKGROUND

As the mobile Internet rapidly develops in recent years, popularity of network traffic increases year by year. To ensure that a network user enjoys a reliable service and to help a network management party manage and monitor activities between network elements in real time, a traffic analysis technology is widely applied to various network devices, including a network transition device or a network packet device, such as a gateway or a router. Currently, an operator provides, by using the technology, information assurance for performing network services such as charging, blocking, and policy control.

One of objectives of traffic analysis is to attribute packets (or data streams) included in traffic to different applications, and this process is referred to as application identification in this application. For example, the operator may need to charge for traffic of a mobile phone application of a user. Therefore, traffic generated when the user uses the application in a time period, namely, traffic that belongs to the application, needs to be calculated. To calculate the traffic, the traffic in the time period first needs to be analyzed to identify a packet that belongs to the application. Based on application identification, the operator can perform distinguished charging to provide a consumer with richer services, and can also monitor a real-time network status to dynamically adjust allocation of network resources of the operator.

However, as Internet Protocol technologies and application program technologies evolve, the traffic analysis technology faces some challenges.

In the prior art, a plaintext feature of a packet is usually used for application identification, and the plaintext feature of the packet is a feature including a character or a digit that can be directly obtained from the packet through parsing. However, with wide use of Internet Protocol encryption technologies, some plaintext features of packets in an original non-encryption protocol are hidden, and only an unhidden feature is used for application identification. Consequently, application identification accuracy is reduced.

In addition, one application may invoke a plurality of services, and the existing traffic analysis technology can be used to distinguish, to some extent, between traffic that belongs to different applications, but is rarely used to perform more fine-grained distinguishing, for example, distinguishing between traffic that belongs to different services (in this application, the distinguishing is referred to as service identification, which is another objective of traffic analysis). Especially after the Internet Protocol encryption technologies are introduced, many original plaintext features of packets are hidden. Consequently, service identification is more difficult.

Further, when a plurality of applications invoke a same service, traffic with a relatively high similarity, namely, common service traffic, is generated. How to identify similar common service traffic and attribute the similar common service traffic to respective applications is currently not resolved in the art.

SUMMARY

The following describes a traffic analysis method, a service identification method and a corresponding apparatus that are provided in this application. It should be understood that the following aspects do not necessarily cover all implementations proposed in this application, and for implementations and benefits of different aspects, mutual reference may be made.

According to a first aspect, this application provides a traffic analysis method. The method is used to improve traffic analysis accuracy in an Internet Protocol encryption scenario, and to specifically improve application identification accuracy or service identification accuracy. The method may be applied to a gateway or another type of network device. The method includes: obtaining a feature of a packet in traffic, where the feature includes a ciphertext feature, and the ciphertext feature includes any one or more of a sequence, a length, and a transmission direction of an encrypted packet; and analyzing the traffic based on the feature, to identify a service or an application to which the traffic belongs.

“Traffic” may be generally one or more data streams. There may be one or more packets whose features are extracted. The “packet” mentioned in this application includes a “data packet” and another type of packet, for example, a packet without data and with only a header.

The “encrypted packet” may be different packets in different encryption manners. This is not limited in this embodiment. The “service” is a function component that is smaller than or equal to an application, and a function provided by the service is usually invoked by the application through an interface. One application may invoke one or more services.

A packet sequence is a location in which a single packet appears in one data stream, or a sequence of a plurality of packets.

A length of a packet may be usually obtained from a field in the packet. If there is no field indicating the packet length, the packet length may be calculated in real time.

A packet transmission direction includes an uplink direction or a downlink direction.

For example, the ciphertext feature may be as follows: A packet length of a first packet A (the packet A is an encrypted packet) in one piece of traffic is m bytes, and a packet length of a second packet A is n bytes; or a length of a first packet A in an uplink direction is m bytes, and a packet length of a second packet A (or another type of packet) in a downlink direction is n bytes; or a first packet A in an uplink direction is an nthpacket in the traffic. There may be many feature combination manners that are not enumerated herein one by one.

It can be learned that the method provides a method for efficiently identifying a service or an application in traffic, so as to resolve a problem that a service or an application cannot be identified in an Internet Protocol encryption scenario, and improve identification accuracy by considering a ciphertext feature of a packet in a service identification process or an application identification process.

In some embodiments, the ciphertext feature may be used in combination with a plaintext feature. The plaintext feature includes a feature including a character and/or a digit that can be directly obtained from the packet through parsing. The “feature including a character and/or a digit” mentioned herein includes a single character or a single digit, or may include a character string or another possible combination. During specific engineering implementation, a character type is, for example, char; and a character string type is, for example, string.

In some embodiments, the method is applied to a deep packet inspection (DPI) device. The DPI device may be an independent network device, or may be built in a gateway general packet radio service (GPRS) support node (GGSN). After the method is applied to the DPI device, the DPI device may perform charging by using a policy and charging rules function (PCRF). In some other embodiments, the method is applied to another network traffic parsing device.

In some embodiments, a packet whose plaintext feature is extracted includes a Transport Layer Security (TLS) handshake message (some or all information).

In some embodiments, a packet whose ciphertext feature is extracted includes a data packet such as application data.

In some embodiments, the analyzing the traffic based on the feature, to identify a service or an application to which the traffic belongs includes: performing matching between the feature and a service identification rule or an application identification rule to identify the service or the application to which the traffic belongs. The two identification rules that may be used herein are obtained based on the feature by using a machine learning algorithm. The service identification rule or the application identification rule is obtained through machine learning, so that an entire traffic analysis process is more intelligent, and traffic analysis accuracy is improved.

It should be understood that a packet used when an identification rule is learned by using the machine learning algorithm is not a currently to-be-analyzed packet, and instead, the packet is a packet obtained from history traffic, or a packet obtained from emulation traffic that is obtained by using another method and that has a feature the same as or similar to that of real traffic.

In some embodiments, the traffic may be filtered before traffic analysis. For a filtering method, refer to filtering methods provided in the following aspects.

In some embodiments, after traffic analysis, traffic of various services may continue to be attributed. Refer to traffic attribution methods provided in the following aspects.

According to a second aspect, this application provides a common service traffic attribution method. A common service is a service invoked by two or more applications. Therefore, an application that generates traffic that is identified in traffic analysis and that belongs to a common service invoked by the application needs to be determined. In other words, an application to which the traffic belongs needs to be determined, so that a subsequent operation such as application traffic charging can be supported.

First, a feature of a packet in traffic is obtained. The feature includes a ciphertext feature, and the ciphertext feature includes any one or more of a sequence, a length, and a transmission direction of an encrypted packet. Then the traffic is analyzed based on the feature, to identify a start service, an exclusive service, and a common service in the traffic. An application is determined based on an exclusive service whose identification time is between an identification time of a start service A and an identification time of a start service B. It is determined that traffic of a common service whose identification time is between the identification time of the start service A and the identification time of the start service B belongs to the application. Herein, the start service A and the start service B are any two adjacent services that have a sequence of time at which the services are identified in the traffic (namely, the identification time). In other words, the start service B is a first start service whose identification time is after the identification time of the start service A. The two services may be the same or different. Herein, A and B are used only to distinguish between the two services. For ease of understanding, “first” and “second” may also be used for distinguishing. Herein, “between” may include endpoints.

In some embodiments, the feature further includes a plaintext feature.

In some embodiments, services invoked by an application are classified into three types: the start service, the common service, and the exclusive service. The start service is a service that runs in an application startup phase (not merely an application startup service), for example, a startup service, a login service, or a registration service. The common service is a service that may be invoked by a plurality of applications. Different from the common service, the exclusive service is a service that is invoked by only one application, so that the application can be uniquely determined by using the exclusive service.

It should be understood that the common service and the exclusive service are mutually exclusive, but the start service may be the exclusive service or the common service.

In some embodiments, the “identification time” may not be represented by a real time value during specific implementation, provided that a service identification sequence is recorded.

In some embodiments, a service identification time is not a time at which a service is actually identified, and may be represented by some other digits or other types of information that can be used to identify the service identification sequence.

Because the start service is the service in the application startup phase, a time period may be determined by using identification time of two start services, and traffic generated in the time period belongs to an application to which a previous start service belongs. However, because the start service may also be the common service, the application cannot be determined by using only the start service. Therefore, the application needs to be determined by using an exclusive service in the time period. Because of a feature of the exclusive service, an application corresponding to the exclusive service in the time period is the application to which the previous start service belongs, or an application to which all traffic generated in the time period belongs. Therefore, traffic generated by the common service in the time period certainly belongs to the application. Although the common service is invoked by a plurality of applications, according to the method provided in this application, an application that invokes each identified common service can be determined, in other words, an application to which traffic generated by each identified common service belongs can be determined.

In some embodiments, the traffic may be filtered before traffic analysis. Specifically, in some implementations, a filtering criterion is a maximum quantity of incoming packets, and the maximum quantity of incoming packets is a quantity of packets determined according to an identification rule. Because the identification rule is obtained in advance by using some methods, the maximum quantity of packets required for enabling the identification rule may be obtained directly or through calculation. In some other implementations, the traffic is filtered based on Internet Protocol (IP) information of the traffic. Specifically, an autonomous system number (ASN) domain of a type of application that requires traffic analysis is obtained through calculation by using the IP information, and the traffic is filtered by using the ASN domain. Performing filtering before analysis can reduce a quantity of to-be-analyzed packets and improve traffic analysis efficiency. In addition, the maximum quantity of incoming packets may be adaptively adjusted according to the identification rule, thereby improving filtering flexibility.

In some embodiments, the analyzing the traffic based on the feature, to identify a start service, an exclusive service, and a common service in the traffic includes: performing matching between the feature and each of a first identification rule, a second identification rule, and a third identification rule to identify the start service, the exclusive service, and the common service in the traffic, where the first identification rule, the second identification rule, and the third identification rule are obtained based on the feature by using a machine learning algorithm.

In some embodiments, the first identification rule, the second identification rule, and the third identification rule are identification rules respectively used to identify three services: the start service, the exclusive service, and the common service. The three identification rules are obtained based on a combination of the plaintext feature and the ciphertext feature of the packet by using the machine learning algorithm, before traffic analysis is performed. As described above, the packet herein is derived from history traffic data, or data emulated by using a mathematical method.

In some embodiments, each of the foregoing three identification rules may include a plurality of identification rules for respectively identifying a plurality of services of a same type. In other words, that the first identification rule, the second identification rule, or the third identification rule is only one identification rule is not limited in this application.

In some embodiments, a feature of traffic of an application is extracted (and is used as a sample); the feature is input into the machine learning algorithm (usually a supervised machine learning algorithm); and the three service identification rules are output by using a machine learning process: the first identification rule used to identify a start service, the second identification rule used to identify an application exclusive service, and the third identification rule used to identify a common service. The feature that is input in the machine learning process includes the plaintext feature and/or the ciphertext feature of the packet.

In some embodiments, the machine learning process may be performed offline or online. Service identification rules of a plurality of applications may be simultaneously or separately learned. Optionally, an association relationship between an application and a service rule is established according to a service identification rule learned in a same application.

In some embodiments, in a real-time system, after to-be-analyzed traffic arrives, the three services are distinguished according to the three previously learned service identification rules, and an identification result includes location information of each service (equivalent to a service identification time). Then traffic for a single user is segmented based on a location of a start service; an application to which each segment belongs is determined based on an exclusive service in the segment; and then a common service in each segment is attributed to the application to which each segment belongs. The service location information is used to indicate a service sequence, and may be specifically represented by using the service identification time.

In some embodiments, a correspondence between an exclusive service and an application that invokes the service may be pre-stored in a memory, and the application is determined based on the correspondence information.

According to a third aspect, this application provides another common service traffic attribution method. Compared with the foregoing method, only one of a start service and an exclusive service can be used in the method.

In some embodiments, a feature of a packet in traffic is obtained. The feature includes a ciphertext feature, and the ciphertext feature includes any one or more of a sequence, a length, and a transmission direction of an encrypted packet. The traffic is analyzed based on the feature, to identify an exclusive service and a common service in the traffic. The exclusive service is a service invoked by only one application, and the common service is a service invoked by two or more applications. An application is determined based on an identified exclusive service A, and the application is an application that invokes the exclusive service A. Traffic of a common service whose identification time is between an identification time of the exclusive service A and an identification time of a next identified exclusive service B is attributed to the application. It should be understood that an application that invokes the exclusive service B may be the application that invokes the exclusive service A. Herein, A and B are used only to distinguish between the two services. For ease of understanding, “first” and “second” may also be used for distinguishing. Herein, “between” may include endpoints.

In some other embodiments, the start service is used to replace the exclusive service in the foregoing process.

Any embodiment of the third aspect may be applied to a case in which no other traffic exists between a start service and an exclusive service (a first exclusive service after the start service) in a same application, because the exclusive service is equivalent to a start service.

For another implementation of the third aspect, refer to the embodiment provided in the second aspect, and details are not described herein again. The third aspect and the second aspect may be separately or simultaneously implemented in a product. During simultaneous implementation, it may be first determined whether other traffic exists between the start service and the exclusive service; and if no other traffic exists between the start service and the exclusive service, the method provided in any one of the third aspect or the embodiments of the third aspect is used; or if other traffic exists between the start service and the exclusive service, the method provided in any one of the second aspect or the embodiments of the second aspect is used.

According to a fourth aspect, this application further provides a traffic filtering method, and the method is usually performed before traffic analysis. A service identification rule or an application identification rule (or another type of analysis rule) is used in traffic analysis. In the filtering method, before traffic analysis, a maximum quantity of incoming packets used during traffic analysis is determined by using one or more of these identification rules to be used subsequently, and data packets beyond the quantity are filtered out. For example, all identification rules are related to application data packets (this is only an example of an identification rule). According to a sequence of packets in the traffic, if a last related application data packet is an nthapplication data packet, an application data packet after the nthapplication data packet may be filtered out, where n may be used as the maximum quantity of incoming packets. The maximum quantity of incoming packets may be one value, or may be a plurality of values respectively corresponding to different types of data packets.

According to a fifth aspect, this application further provides a traffic filtering method. In the method, an ASN domain is calculated based on IP information in traffic, and then the traffic is filtered by using the ASN domain.

According to a sixth aspect, this application further provides a traffic analysis apparatus, including one or more units, configured to implement any method in the first aspect. In addition, this application further provides a common service traffic attribution apparatus, including one or more units, configured to implement any method in the second aspect or any method in the third aspect. In addition, this application further provides a traffic filtering apparatus, including one or more units, configured to implement any method in the fourth aspect or any method in the fifth aspect.

According to a seventh aspect, this application provides a computer system, including a memory and a processor. The memory is configured to store a computer readable instruction, and the processor is configured to: read the computer readable instruction and implement any one or more methods in the first aspect to the fifth aspect.

According to an eighth aspect, this application further provides a computer readable storage medium. The medium is usually nonvolatile, and the medium is used to store a computer readable instruction. After the computer readable instruction is read by one or more processors, any one or more methods in the first aspect to the fifth aspect are implemented.

“A plurality of” or “a plurality of times” in this application means “at least two” or “at least two times”, unless otherwise specified. “First” and “second” in this application are not intended to limit a sequence, but are merely intended to distinguish between two subjects in some description contexts for ease of understanding. However, indicated subjects do not need to be different in all embodiments. “A/B” or “A and/or B” in this application includes three cases: A, B, and both A and B. In this application, “A®” means that A is a trademark name, and a term without “®” may also be a trademark name.

