Session flow determination method, apparatus, device, and storage medium

Abstract

The application relates to the technical field of communication, in particular to a session flow determination method and device, equipment and a storage medium. The method comprises the following steps: analyzing network traffic collected by bypass mirroring to obtain request logs containing request paths and field information, then taking field information with the same field name and field value in different request paths as first candidate identification fields, and taking field information with the same field name but different field values in the same request path as second candidate identification fields; determining a target field name according to the occurrence times of each field name in each first candidate identification field and each second candidate identification field, and determining a corresponding session flow from the request logs according to the target field name; the discrete, disordered and interleaved original requests obtained by bypass mirroring are restored into continuous session flows facing a single logical subject without modifying business codes and deploying software development kits.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method, apparatus, device and storage medium for determining a session flow. Background Technology

[0002] In scenarios such as enterprise-level API governance, network security auditing, business traffic analysis, and user behavior reconstruction, how to recover the continuous access process of a single logical entity from raw network traffic has always been a fundamental challenge for data flow governance systems. Especially with the increasing prevalence of microservices, cloud-native architectures, and front-end / back-end separation architectures, a single user front-end operation is often broken down into multiple concurrent Application Programming Interface (API) requests at the underlying level. These requests manifest on the network side as large-scale, heterogeneous, out-of-order, and highly intertwined raw Hypertext Transfer Protocol (HTTP) messages. The mirror port only collects "physical traffic," not the organized "business session." To achieve the above-mentioned session restoration using existing technologies, either the specific authentication field names need to be known in advance, or the business system needs to cooperate in embedding a trace identifier (Trace-ID) or software development kit (SDK). This is difficult to apply in a zero-intrusion deployment environment on the image side. Therefore, how to restore the discrete, disordered, and intertwined original requests obtained by the bypass image into a continuous session stream oriented towards a single logical subject has become a technical problem that urgently needs to be solved. Summary of the Invention

[0003] The main objective of this application is to provide a method, apparatus, device, and storage medium for determining a session flow, which aims to solve the existing technical problem of being unable to restore the discrete, disordered, and intertwined original requests obtained from bypass mirroring into a continuous session flow oriented towards a single logical subject.

[0004] To achieve the above objectives, this application proposes a session flow determination method, the method comprising: The network traffic collected by the bypass mirror is parsed to obtain request logs. The request logs contain at least two request paths to be analyzed and corresponding field information, including field names and corresponding field values. The field information in the requests to be analyzed from different request paths, where the field name and the corresponding field value are the same, is taken as the first candidate identifier field; In the requests to be analyzed with the same request path, the field information with the same field name but different corresponding field values ​​is used as the second candidate identifier field; The target field name is determined based on the number of occurrences of each field name in each of the first candidate identifier fields and each of the second candidate identifier fields, and the corresponding session stream is determined from the request log based on the target field name.

[0005] In one embodiment, before the step of using the field information in the requests to be analyzed from different request paths, where the field name and the corresponding field value are the same, as the first candidate identifier field, the method includes: The request log is divided into time windows according to a preset time length to obtain request windows. The number of requests contained in each request window is determined by statistics. Each request window whose number of requests exceeds a preset request threshold is designated as a high-density window, and the requests within the high-density windows are designated as the requests to be analyzed.

[0006] In one embodiment, the step of determining the target field name based on the frequency of occurrence of each field name in each of the first candidate identifier fields and each of the second candidate identifier fields includes: Obtain the number of occurrences of each field name in each of the first candidate identifier fields and each of the second candidate identifier fields in each of the high-density windows; Sort the occurrence counts of each field name to obtain a count list, and determine the field name that appears most frequently in the count list as the target field name.

[0007] In one embodiment, the step of sorting the occurrence counts of each field name to obtain a count list, and determining the field name with the highest occurrence count in the count list as the target field name, includes: The frequency of occurrence of each field name is sorted to obtain a frequency list. The field names whose ranking in the frequency list is less than a preset selection threshold are transmitted to the user so that the user can determine the target field name from the field names.

[0008] In one embodiment, the step of determining the corresponding session flow from the request log based on the target field name includes: The field name of the target field name is determined as the target field name; Based on the target field name, extract the corresponding field value from the request log, and group the requests with the same field value into a group to obtain each target request group; Based on the request initiation time of each request in each target request group, the requests in each target request group are sorted to obtain each target request sequence, and each target request sequence is used as the session stream of the corresponding target subject.

[0009] In one embodiment, determining the target field name based on the frequency of occurrence of each field name in each of the first candidate identifier fields and each of the second candidate identifier fields includes: Obtain the first candidate hit count and the second candidate hit count corresponding to each candidate identifier field. The first candidate hit count is the number of times the candidate identifier field is hit as the first candidate identifier field, and the second candidate hit count is the number of times the candidate identifier field is hit as the second candidate identifier field. The first candidate hit count is weighted according to a preset first weight to obtain a first weighted score, and the second candidate hit count is weighted according to a preset second weight to obtain a second weighted score. The first weighted score and the second weighted score corresponding to each candidate identifier field are summed to obtain the comprehensive score corresponding to each candidate identifier field. The target field name is determined based on the comprehensive score described above.

[0010] In one embodiment, the step of determining the target field name based on the frequency of occurrence of each field name in each of the first candidate identifier fields and each of the second candidate identifier fields includes: The field names of each candidate identifier field are matched with a preset identity identifier keyword library to obtain matching results, and the corresponding semantic score of the field name is determined based on the matching results. The field values ​​corresponding to each candidate identifier field are compared with the preset structure rules to obtain the comparison results, and the field value structure score is determined based on the comparison results. Based on the semantic score of the field name and the structural score of the field value, the auxiliary confidence level corresponding to the candidate identifier field is determined, and the target field name is determined based on the auxiliary confidence level and the cumulative number of times each candidate identifier field is hit.

[0011] Furthermore, to achieve the above objectives, this application also proposes a session flow determination apparatus, the apparatus comprising: The traffic parsing module is used to parse the network traffic collected by the bypass mirror to obtain request logs. The request logs contain at least two request paths to be analyzed and corresponding field information, including field names and corresponding field values. The first field confirmation module is used to select the field information in the requests to be analyzed from different request paths, where the field name and the corresponding field value are the same, as the first candidate identifier field. The second field confirmation module is used to select the field information in the requests to be analyzed that have the same field name but different corresponding field values ​​as the second candidate identifier field; The session flow determination module is used to determine the target field name based on the number of occurrences of each field name in each of the first candidate identifier fields and each of the second candidate identifier fields, and to determine the corresponding session flow from the request log based on the target field name.

[0012] In addition, to achieve the above objectives, this application also proposes a session flow determination device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the session flow determination method as described above.

[0013] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the session flow determination method described above.

[0014] This application provides a session flow determination method, apparatus, device, and storage medium. The method includes: parsing network traffic collected by bypass mirroring to obtain request logs, wherein the request logs contain at least two request paths to be analyzed and corresponding field information, wherein the field information includes field names and corresponding field values; selecting field information from the requests to be analyzed along different request paths where the field names and corresponding field values ​​are the same as first candidate identifier fields; selecting field information from the requests to be analyzed along the same request path where the field names are the same but the corresponding field values ​​are different as second candidate identifier fields; determining a target field name based on the frequency of occurrence of each field name in each of the first and second candidate identifier fields; and determining the corresponding session flow from the request logs based on the target field name.

[0015] The technical solution proposed in this application has at least the following beneficial effects: The session flow determination method of this application obtains request logs containing request paths and field information by parsing the network traffic collected by the bypass mirror. Then, field information with the same field name and field value in different request paths is used as the first candidate identifier field, and field information with the same field name but different field value in the same request path is used as the second candidate identifier field. The target field name is determined according to the occurrence frequency of each field name in each of the first and second candidate identifier fields, and the corresponding session flow is determined from the request log according to the target field name. Since it does not rely on pre-configured field names or intrusive tracing identifiers, but only on the statistical characteristics of the mirror traffic itself to complete the determination of candidate fields and the restoration of session flow, it can restore the discrete, disordered, and intertwined original requests obtained by the bypass mirror into a continuous session flow oriented towards a single logical subject without modifying business code or deploying software development kits. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of the device structure of the hardware operating environment involved in the embodiments of this application; Figure 2 This is a flowchart illustrating the first embodiment of the session flow determination method of this application; Figure 3 This is a flowchart illustrating the second embodiment of the session flow determination method of this application; Figure 4 This is a flowchart illustrating the third embodiment of the session flow determination method of this application; Figure 5 This is a structural block diagram of the session flow determination device of this application.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] Reference Figure 1 , Figure 1This is a schematic diagram of the device structure of the hardware operating environment involved in the embodiments of this application.

[0022] like Figure 1 As shown, the session flow determination device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to establish communication between these components. The user interface 1003 may be connected to a display screen; optionally, the user interface 1003 may include a standard wired interface or a wireless interface. In this application, the wired interface of the user interface 1003 may be a USB interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wireless-Fidelity (Wi-Fi) interface). The memory 1005 may be high-speed random access memory (RAM) or non-volatile memory (NVM), such as a disk storage device. The memory 1005 may also optionally be a storage device independent of the aforementioned processor 1001.

[0023] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a limitation on the device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0024] like Figure 1 As shown, the memory 1005, which is identified as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a session flow determination program.

[0025] exist Figure 1 In the device shown, the network interface 1004 is mainly used to connect to the backend server and communicate with the backend server; the user interface 1003 is mainly used to connect to the user equipment; the device calls the session flow determination program stored in the memory 1005 through the processor 1001 and executes the steps of the session flow determination method provided in the embodiments of this application.

[0026] It's important to note that in scenarios such as enterprise-level API governance, network security auditing, business traffic analysis, and user behavior reconstruction, how to recover the continuous access process of a single logical entity from raw network traffic remains a fundamental challenge for data flow governance systems. Especially with the increasing prevalence of microservices, cloud-native architectures, and front-end / back-end separation architectures, a single user front-end operation is often broken down into multiple concurrent Application Programming Interface (API) requests at the underlying level. These requests manifest on the network side as large-scale, heterogeneous, out-of-order, and highly intertwined raw Hypertext Transfer Protocol (HTTP) messages. The mirror port only collects "physical traffic," not the organized "business session." To achieve the above-mentioned session restoration using existing technologies, either the specific authentication field names need to be known in advance, or the business system needs to cooperate in embedding a trace identifier (Trace-ID) or software development kit (SDK). This is difficult to apply in a zero-intrusion deployment environment on the image side. Therefore, how to restore the discrete, disordered, and intertwined original requests obtained by the bypass image into a continuous session stream oriented towards a single logical subject has become a technical problem that urgently needs to be solved.

[0027] Therefore, to address the aforementioned deficiencies, this embodiment provides a session flow determination method, apparatus, device, and storage medium. The method includes: parsing network traffic collected by bypass mirroring to obtain request logs, wherein the request logs contain at least two request paths to be analyzed and corresponding field information, wherein the field information includes field names and corresponding field values; selecting field information from requests to be analyzed along different request paths where the field names and corresponding field values ​​are the same as first candidate identifier fields; selecting field information from requests to be analyzed along the same request path where the field names are the same but the corresponding field values ​​are different as second candidate identifier fields; determining a target field name based on the frequency of occurrence of each field name in each of the first and second candidate identifier fields; and determining the corresponding session flow from the request logs based on the target field name.

[0028] The session flow determination method in this embodiment obtains network traffic collected by the bypass mirror and parses it to obtain request logs containing request paths and field information. Then, field information with the same field name and field value in different request paths is used as the first candidate identifier field, and field information with the same field name but different field value in the same request path is used as the second candidate identifier field. Next, the target field name is determined according to the cumulative number of times each candidate identifier field is hit, and finally, the corresponding session flow is determined from the request log based on the target field name. Since it does not rely on pre-configured field names or intrusive tracking identifiers, but only on the statistical characteristics of the mirror traffic itself to complete the mining of candidate fields and the restoration of session flow, it can restore the discrete, disordered, and intertwined original requests obtained by the bypass mirror into a continuous session flow oriented towards a single logical subject without modifying business code or deploying software development kits.

[0029] For ease of understanding, the following is combined with Figures 2 to 5 The session flow determination method provided in the embodiments of this application will be described in detail.

[0030] Reference Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of the session flow determination method of this application. The first embodiment of the session flow determination method of this application is presented as follows: Figure 2 As shown, in this embodiment, the method includes: Step S10: Analyze the network traffic collected by the bypass mirror to obtain request logs. The request logs contain at least two request paths to be analyzed and their corresponding field information, including field names and corresponding field values.

[0031] It is understood that the method of this embodiment can be applied to the aforementioned session flow determination device, which can be any device with data processing, program execution and data acquisition functions, such as a computer, server, etc., and is not limited in this embodiment.

[0032] It should be understood that the above-mentioned bypass mirroring acquisition can be a passive traffic acquisition method that copies and obtains network packet data from the physical link without affecting the normal communication of the original network link, through methods such as optical splitters, switch port mirroring (SPAN) or network splitters. For example, a port mirroring policy can be configured on the core switch to copy all packets entering and leaving a certain service server and send them to the analysis device.

[0033] It should also be understood that the aforementioned network traffic can be a bit stream or data packet sequence formed on the transmission medium by application layer protocol messages such as Hypertext Transfer Protocol (HTTP) and Hypertext Transfer Protocol Secure (HTTPS), for example, HTTP request and response messages carried between the client and the server via the Transmission Control Protocol (TCP) connection. This embodiment does not limit this.

[0034] It should be noted that the above request logs can be a collection of data records generated by parsing the collected raw network traffic according to the protocol and extracting and recording key fields in a preset format. For example, each request log corresponds to an HTTP request and includes the request time, request path, and key-value pair information in the message header and cookie. This embodiment does not impose any restrictions on this.

[0035] It should also be noted that the above-mentioned requests to be analyzed can be requests in the request log that need to be statistically analyzed and candidate identifier fields mined.

[0036] It is important to emphasize that the above request path can be the path part of the Uniform Resource Identifier (URI) used to indicate the specific resource or interface address on the server side, such as / api / user / info.

[0037] It should also be emphasized that the above field information can be data units organized in the form of key-value pairs in the HTTP request message, such as header fields or cookie fields.

[0038] It should be clarified that the above field name can be the key in the key-value pair that constitutes the field information, used to identify the data type or semantics represented by the field, such as the field name Token. It should be further clarified that the above field value can be the value in the key-value pair that constitutes the field information, used to represent the actual content of the field in a specific request, such as the field value corresponding to the field name Token being abc.

[0039] In its implementation, the aforementioned session flow determination device can receive raw network packet data from the bypass mirror acquisition transmission. Subsequently, the device can sequentially unpack and reassemble these raw network packet data according to the TCP / IP protocol stack to recover complete application layer protocol data. Next, the device can parse at least two HTTP requests from the recovered application layer data and extract the request path, corresponding field names, and field values ​​from each request. Then, the device can write the extracted information into a request log according to a preset data structure, with each request log entry containing at least the request path, field names, and corresponding field values ​​for the corresponding request. At this point, the device has completed the structured parsing of the raw network traffic and obtained request logs that can be used in subsequent steps.

[0040] Step S20: Select the field information in the requests to be analyzed from different request paths, where the field name and the corresponding field value are the same, as the first candidate identifier field.

[0041] It should be understood that the aforementioned first candidate identifier field can be field information whose field name and corresponding field value remain unchanged in the requests to be analyzed in different request paths. This field information has cross-path stability, such as the authentication token field carried by the same user in different interface requests.

[0042] In its implementation, after obtaining the request logs, the session flow determination device can retrieve the request paths and field information corresponding to each request to be analyzed. Next, the device can group different requests according to their request paths and extract the field information of the requests to be analyzed from each group. Then, the device can perform pairwise comparisons of the field information of each request under different request paths to determine if there are fields with the same name and corresponding value. When a field is detected to have the same name and value in requests across different request paths, the device can identify this field as the first candidate identifier field. In this way, the session flow determination device completes the initial screening of candidate fields with cross-path consistency.

[0043] To facilitate understanding, the following examples are provided for illustration, but they do not impose specific limitations on this embodiment. For instance, based on the three request logs in the aforementioned example, the first request has a request path of / api / user / profile and contains the field information token=abc123; the second request has a request path of / api / order / list and contains the field information token=abc123. Although the request paths of these two requests are different, the field name is "token" and the corresponding field value is "abc123". Therefore, the session flow determining device can use the field name "token" and the corresponding field value "abc123" as the first candidate identifier field.

[0044] Step S30: Select the field information with the same field name but different field values ​​from the requests to be analyzed along the same request path as the second candidate identifier field.

[0045] It is understood that the aforementioned second candidate identifier field can be field information with the same field name but different corresponding field values ​​in the requests to be analyzed along the same request path. This field information includes the field name and its corresponding field value, and has the ability to distinguish the subject under the same path. For example, when the same interface is accessed concurrently by multiple different users, it is used to distinguish the user identifier field information of different user identities. This embodiment does not impose any restrictions on this.

[0046] In its implementation, after obtaining the request logs, the session flow determination device can retrieve the request paths and field information corresponding to each request to be analyzed. Next, the device can group different requests according to their request paths, grouping requests with the same request path into the same group. Then, for multiple requests within the same request path group, the device can extract the field information of each request and compare it. When a field name appears in multiple requests under the same request path, and the field values ​​corresponding to that field name are different in each request, the device can identify the field name and the corresponding field values ​​in each request as the second candidate identifier field. In this way, the session flow determination device completes the initial screening of candidate fields capable of distinguishing entities along the same path.

[0047] To facilitate understanding, the following example illustrates the concept, but does not impose specific limitations on this embodiment. For instance, consider three request logs: the first request has the path / api / user / profile and contains the field user_id=001; the second request has the path / api / user / profile and contains the field user_id=002; and the third request has the path / api / user / profile and contains the field user_id=003. These three requests share the same request path and the field name is user_id, but the field values ​​corresponding to user_id in the three requests are 001, 002, and 003, respectively, and are all different. Therefore, the session flow determining device can consider the fields user_id=001, user_id=002, and user_id=003 as the second candidate identifier fields.

[0048] Step S40: Determine the target field name based on the number of occurrences of each field name in each of the first candidate identifier fields and each of the second candidate identifier fields, and determine the corresponding session stream from the request log based on the target field name.

[0049] It should be noted that the target field name mentioned above can be a field name used to identify the logical subject, determined from the first candidate identifier field and the second candidate identifier field based on the frequency of occurrence of each field name. For example, the field name token or user_id that is repeatedly hit in each of the first candidate identifier field and each of the second candidate identifier fields. This embodiment does not limit this.

[0050] It should be understood that the above-mentioned session flow can be a continuous sequence of requests belonging to the same logical subject, obtained by grouping requests with the same field value into a group and sorting them according to the initiation time of each request. For example, it can be a sequence formed by arranging all HTTP requests issued by a user within a login validity period in chronological order.

[0051] In its implementation, after obtaining the first candidate identifier field and each of the second candidate identifier fields, the session flow determination device can extract each field name from each of the first and second candidate identifier fields, and count the number of times each field name appears in all candidate identifier fields. Subsequently, the session flow determination device can determine the target field name based on the statistical results. After determining the target field name, the session flow determination device can extract all requests with that target field name from the request log, and group requests with the same field value into the same logical subject group based on the field value corresponding to that target field name in each request. Next, the session flow determination device can obtain the request initiation time corresponding to each request, and sort the requests within each logical subject group according to the request initiation time from earliest to latest, thereby obtaining the session flow corresponding to each logical subject. At this point, the session flow determination device has completed the filtering from candidate identifier fields to target field names, and based on the target field name, restores the discrete requests into a continuous session flow oriented towards a single logical subject.

[0052] To facilitate understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For instance, the session flow determination device, through statistical analysis, finds that the field name "token" appears 120 times in each of the first and second candidate identifier fields, the field name "session_id" appears 80 times, and the field name "user_id" appears 50 times. Therefore, the session flow determination device can identify the most frequently occurring "token" as the target field name. Subsequently, the session flow determination device extracts all requests containing the "token" field from the request log, grouping requests with the same "token" field value into the same group. Assuming there are three requests with "token=abc123" initiated at 10:00:01, 10:00:05, and 10:00:12 respectively, the session flow determination device arranges these three requests in chronological order to form the session flow of this logical subject.

[0053] This embodiment obtains request logs by parsing the network traffic collected by the bypass mirror. Fields with the same field name and value in different request paths are used as first candidate identifier fields, and fields with the same field name but different field values ​​in the same request path are used as second candidate identifier fields. The target field name is determined based on the frequency of occurrence of each field name in each first and second candidate identifier field. The corresponding session flow is then determined from the request log based on the target field name. This allows the discovery of fields that can truly identify the logical subject based solely on the original HTTP request logs obtained by the bypass mirror, without modifying business code, deploying SDK or Agent, or relying on Trace-ID, and restoring discrete requests into a continuous session flow of a single logical subject.

[0054] Reference Figure 3 , Figure 3 This is a flowchart illustrating the second embodiment of the session flow determination method of this application. Based on the first embodiment described above, a second embodiment of the session flow determination method of this application is proposed.

[0055] Considering that in real-world application scenarios, network traffic collected from the mirror side is typically massive, disordered, and highly intertwined, directly mining candidate identifier fields from the entire request log would not only incur enormous computational overhead, but also result in a large number of irrelevant requests severely interfering with the statistical results of field distribution characteristics, making it difficult to effectively reveal the true subject identifier relationships. To reduce computational complexity while ensuring analytical accuracy, in this embodiment, before the step of using the field information with the same field name and corresponding field value from the requests to be analyzed across different request paths as the first candidate identifier field, the following steps are included: Step S021: Divide the request log into time windows according to a preset time length to obtain request windows, and statistically determine the number of requests contained in each request window.

[0056] It should be understood that the aforementioned preset time length can be a pre-set time span value used to divide the time window, such as 3 seconds.

[0057] It should be understood that the above request window can be a collection of request data within time segments obtained after dividing the request log according to a preset time length. For example, if the request log is divided into segments with a time length of 3 seconds, all requests within each 3-second time segment constitute a request window.

[0058] In its implementation, after obtaining the request log, the session flow determination device can divide the request log into time windows based on the request initiation time of each request according to a preset time length. Requests within the same time segment are grouped into the same request window, thus obtaining several request windows. Subsequently, the session flow determination device can perform statistics on each request window, counting the total number of requests contained in each request window.

[0059] Step S022: Select each request window whose number of requests exceeds a preset request threshold as a high-density window, and select the requests in the high-density window as the requests to be analyzed.

[0060] It is understood that the aforementioned preset request threshold can be a pre-set critical value for determining whether a request window is a high-density window, such as 2. This embodiment does not limit this.

[0061] It is also understood that the aforementioned high-density window can be a request window containing more requests than a preset request threshold, and this embodiment does not impose any restrictions on this.

[0062] In its implementation, after counting the number of requests contained in each request window, the session flow determination device can compare the number of requests corresponding to each request window with a preset request threshold, and filter out all request windows whose number of requests exceeds the preset request threshold. Subsequently, the session flow determination device can identify these filtered request windows as high-density windows and extract all requests contained in the high-density windows as requests to be analyzed.

[0063] This embodiment divides the request log into time windows, counts the number of requests in each window, and designates windows with more than a preset request threshold as high-density windows. Requests in these high-density windows are then used as the requests to be analyzed. This compresses massive, unordered full logs into local high-density windows that are easier to observe the short-term behavioral characteristics of the same subject. This effectively reduces the computational scale of subsequent candidate identifier field mining, increases the density of effective samples, and reduces the interference of irrelevant requests on field distribution characteristics. This creates a more favorable data foundation for subsequent cross-path invariance analysis and same-path difference analysis.

[0064] Considering that in practical applications, the candidate identifier fields obtained through the aforementioned cross-path invariance analysis and same-path difference analysis are often more than one, directly determining the target field name based solely on the preliminary discovery results of the candidate fields makes it difficult to guarantee that the finally selected field truly has the ability to stably identify the logical subject. To stably filter out the most suitable target field for serialization from multiple candidate fields, in this embodiment, the step of determining the target field name based on the frequency of occurrence of each field name in each of the first and second candidate identifier fields includes: Step S401: Obtain the number of occurrences of each field name in each of the first candidate identifier fields and each of the second candidate identifier fields in each of the high-density windows.

[0065] In its implementation, after determining the high-density window, the first candidate identifier field, and the second candidate identifier field, the session flow determination device can traverse each high-density window and count the number of times each field name corresponding to the first candidate identifier field and the number of times each field name corresponding to the second candidate identifier field appears in each high-density window. Then, the session flow determination device can sum the statistical results of each high-density window to obtain the total number of times each field name appears in all high-density windows.

[0066] To facilitate understanding, the following examples are provided for illustration, but they do not impose specific limitations on this embodiment. For instance, there are two high-density windows. In high-density window 1, the field name "token" appears a total of 5 times in both the first and second candidate identifier fields, and the field name "session_id" appears a total of 3 times. In high-density window 2, the field name "token" appears a total of 4 times, and the field name "session_id" appears a total of 6 times. After the session flow determination device adds up the statistical results of the two windows, it obtains a total of 9 occurrences of the field name "token" and 9 occurrences of the field name "session_id".

[0067] Step S402: Sort the occurrence counts of each field name to obtain a count list, and determine the field name that appears most frequently in the count list as the target field name.

[0068] It should be understood that the above-mentioned frequency list can be an ordered sequence obtained by sorting the frequency of each field name, such as a list of field names and their corresponding frequencies arranged in descending order of frequency. This embodiment does not impose any restrictions on this.

[0069] In its implementation, after obtaining the number of times each field name appears in all high-density windows, the session flow determination device can sort the field names in descending order of their frequency of occurrence, thereby generating a frequency list. Then, the device can extract the field name that appears first, i.e., the most frequently appearing field name, from this frequency list and designate that field name as the target field name.

[0070] To facilitate understanding, the following examples are provided for illustration, but they do not impose specific limitations on this embodiment. For instance, the session flow determination device obtained the following statistics: the field name "token" appeared 120 times, the field name "session_id" appeared 80 times, and the field name "user_id" appeared 50 times. The session flow determination device sorted these fields from most frequent to least frequent, resulting in a list of occurrences: token (120 times), session_id (80 times), and user_id (50 times). The field name "token," which appeared first in the list, was then identified as the target field name.

[0071] This embodiment improves the accuracy and reliability of target field name selection by obtaining the cumulative number of times each candidate identifier field is hit in multiple high-density windows, sorting the cumulative number of hits, and determining the candidate identifier field with the highest cumulative number of hits as the target field name. This avoids the randomness and misjudgment risk caused by relying on a single window or local evidence for selection.

[0072] Furthermore, considering that in practical application scenarios, relying solely on automated sorting mechanisms to directly determine the most frequently occurring field name as the target field name may still face the risk of misjudgment in some scenarios. For example, although the global link fingerprint field has an extremely high hit rate, its semantics are not equivalent to the core login credential. If it is directly used as the serialization primary key without manual confirmation, it will affect the accuracy of subsequent session reconstruction. In order to introduce a manual confirmation mechanism on the basis of automated statistical sorting to further improve the reliability of target field name selection, in this embodiment, the step of sorting the occurrence frequency of each field name to obtain a frequency list, and determining the most frequently occurring field name in the frequency list as the target field name includes: Step S4021: Sort the occurrence counts of each field name to obtain a count list, and transmit the field names whose sorting position in the count list is less than a preset selection threshold to the user so that the user can determine the target field name from each field name.

[0073] It should be understood that the aforementioned preset selection threshold can be a pre-set sorting position threshold for filtering the field names to be transmitted. For example, 3 means that field names with a sorting position less than 3 will be transmitted to the user. The specific value can be set according to the actual situation, and this embodiment does not limit it.

[0074] In its implementation, after sorting the field names in descending order of frequency and obtaining a frequency list, the session flow determination device can filter out field names whose sorting rank is lower than a preset selection threshold. Then, the session flow determination device can transmit these filtered field names to the user, allowing the user to select a field name from these field names as the target field name.

[0075] To facilitate understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For example, with a preset threshold of 3, after the session flow determination device sorts the occurrence counts, it obtains a count list: the first-ranked field name sr_fp_value appears 12679 times, the second-ranked field name SX-Token appears 12625 times, the third-ranked field name token appears 12622 times, and the fourth-ranked field name fingerprintId appears 1957 times. The session flow determination device transmits the field names with a ranking less than 3, i.e., the first-ranked sr_fp_value and the second-ranked SX-Token, to the user, who then determines the target field name from these two field names.

[0076] This embodiment obtains a list of counts by sorting the cumulative counts, and transmits the candidate identifier fields whose sorting positions are less than the preset selection threshold to the user, so that the user can determine the target field name from each candidate identifier field. This introduces a manual confirmation step, thereby improving the accuracy of the final selection result of the target field name while ensuring the overall processing efficiency.

[0077] Reference Figure 4 , Figure 4 This is a flowchart illustrating the third embodiment of the session flow determination method of this application. Based on the above embodiments, a third embodiment of the session flow determination method of this application is proposed.

[0078] Furthermore, considering that after determining the target field name, if we only stay at the candidate field confirmation stage and cannot apply the field to the request reorganization of the full log, then all the aforementioned analysis results will hardly play a real role. Therefore, it is necessary to aggregate and sort discrete requests based on the target field name. In order to translate the candidate field identification results into usable session stream data, in this embodiment, the step of determining the corresponding session stream from the request log based on the target field name includes: Step S411: Extract the corresponding field value from the request log according to the target field name, and group the requests with the same field value into a group to obtain each target request group.

[0079] It is understood that the aforementioned target request group can be a set of requests belonging to the same logical subject obtained by grouping requests according to the field value corresponding to the target field name. For example, all requests with the token field value of abc123 can be grouped into the same target request group. This embodiment does not limit this.

[0080] In its implementation, after determining the target field name, the session flow determination device can iterate through each request in the request log and extract the field value corresponding to the target field name from each request. Subsequently, the session flow determination device can group all requests with the same field value into the same group, thereby obtaining each target request group.

[0081] To facilitate understanding, the following example illustrates the concept, but does not impose specific limitations on this embodiment. For instance, the target field name is "token," and the request log contains five requests: the first request contains "token=abc123," the second request contains "token=abc123," the third request contains "token=def456," the fourth request contains "token=abc123," and the fifth request contains "token=def456." The session flow determining device groups the first, second, and fourth requests, all with the "token" field value of "abc123," into one group, obtaining target request group A; and groups the third and fifth requests, all with the "token" field value of "def456," into another group, obtaining target request group B.

[0082] Step S412: Sort the requests in each target request group according to the request initiation time of each request in each target request group to obtain each target request sequence, and use each target request sequence as the session stream of the corresponding target subject.

[0083] It should be noted that the above-mentioned request initiation time can be the initiation time of a single HTTP request recorded in the request log, such as the timestamp field parsed from the request message. This timestamp can be generated by the client that initiated the request or marked by the collection device when receiving the message. This embodiment does not impose any restrictions on this.

[0084] It should also be noted that the above target request sequence can be an ordered list of requests obtained by sorting the requests within the same target request group according to the time of request initiation. For example, it can be an ordered sequence formed by arranging multiple requests issued by a user within a certain period of time in chronological order.

[0085] It should be understood that the aforementioned target entity can be a unique logical entity identified by the same field value corresponding to the target field name, such as a single user identified by the same token field value.

[0086] In its implementation, after obtaining each target request group, the session flow determination device can retrieve the request initiation time of each request within each target request group from the request log. Next, for each target request group, the session flow determination device can sort all requests within that group in ascending order of their initiation times to obtain the target request sequence for each target request group. Finally, the session flow determination device can use each target request sequence as the session flow for its corresponding target subject, thereby completing the recovery from discrete requests to a continuous session flow for a single subject.

[0087] For ease of understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For instance, consider a target request group A containing three requests: the first request is initiated at 10:00:01, the second at 10:00:05, and the third at 10:00:12. The session flow determination device sorts these three requests from earliest to latest according to their initiation times, obtaining the target request sequence: first request (10:00:01), second request (10:00:05), and third request (10:00:12). Subsequently, this target request sequence is used as the session flow for the corresponding target subject.

[0088] This embodiment extracts the corresponding field value from the request log based on the target field name, groups the requests with the same field value into a group to obtain each target request group, sorts the requests in each target request group according to the request initiation time of each request in each target request group to obtain each target request sequence, and uses each target request sequence as the session stream of the corresponding target subject. This realizes the realization of the candidate field identification results into usable session stream data, so that the discrete requests that were originally scattered on the mirror side and arranged according to the physical arrival order are reorganized into a continuous session stream oriented towards a single logical subject.

[0089] Considering that in practical applications, candidate identifier fields from different sources may contribute differently to the identifier logic body, for example, fields hit by cross-path invariance analysis often have high session-level stability, while fields hit by same-path difference analysis may have some misjudgments. If we simply add up the occurrence counts of each field name, we cannot distinguish the difference in confidence of different analysis paths for the same field name, which may lead to non-core authentication fields interfering with the sorting results due to a large number of hits. In order to improve the accuracy of target field name selection, in this embodiment, the step of determining the target field name based on the occurrence counts of each field name in each of the first candidate identifier fields and each of the second candidate identifier fields includes: Step S421: Obtain the first candidate hit count and the second candidate hit count corresponding to each candidate identifier field. The first candidate hit count is the number of times the candidate identifier field is hit as the first candidate identifier field, and the second candidate hit count is the number of times the candidate identifier field is hit as the second candidate identifier field.

[0090] It is understandable that the number of times the first candidate is hit can be the cumulative number of times a certain field name is hit as the first candidate identifier field in the high-density window, that is, the number of times the field name and the corresponding field value are the same in the requests to be analyzed in different request paths.

[0091] It is also understandable that the number of times the second candidate is hit can be the cumulative number of times a certain field name is hit as the second candidate identifier field in the high-density window, that is, the number of times the field name is the same but the corresponding field value is different in the requests to be analyzed in the same request path.

[0092] In its specific implementation, after obtaining the first candidate identifier field and each second candidate identifier field in each high-density window, the session flow determination device can traverse all high-density windows and count the number of times each candidate identifier field is identified as the first candidate identifier field in each high-density window, which is taken as the first candidate hit count for that candidate identifier field. Then, the session flow determination device can count the number of times each candidate identifier field is identified as the second candidate identifier field in each high-density window, which is taken as the second candidate hit count for that candidate identifier field.

[0093] To facilitate understanding, the following examples are provided for illustration, but they do not impose specific limitations on this embodiment. For instance, if the field name "token" is identified as a first candidate identifier field once in high-density window 1 and once in high-density window 2, then the number of first candidate hits for the field name "token" is 2. Simultaneously, if the same field name is identified as a second candidate identifier field once in high-density window 1 and once in high-density window 3, then the number of second candidate hits for the field name "token" is 2.

[0094] Step S422: Weight the number of hits of the first candidate according to the preset first weight to obtain a first weighted score, and weight the number of hits of the second candidate according to the preset second weight to obtain a second weighted score.

[0095] It should be understood that the aforementioned preset first weight can be a pre-set coefficient value used to weight the number of hits of the first candidate. This weight value reflects the confidence contribution of the hit evidence obtained by the cross-path invariance analysis path to the overall score. Similarly, the aforementioned preset second weight can be a pre-set coefficient value used to weight the number of hits of the second candidate. This weight value reflects the confidence contribution of the hit evidence obtained by the same-path difference analysis path to the overall score.

[0096] It should also be understood that the first weighted score mentioned above can be the value obtained by weighting the number of first candidate hits corresponding to the candidate identifier field with a preset first weight. Similarly, the second weighted score mentioned above can be the value obtained by weighting the number of second candidate hits corresponding to the candidate identifier field with a preset second weight.

[0097] In its specific implementation, after obtaining the number of first candidate hits and the number of second candidate hits corresponding to each candidate identifier field, the aforementioned session flow determination device can perform a weighted calculation by multiplying the number of first candidate hits by the preset first weight to obtain a first weighted score. Next, the aforementioned session flow determination device can perform a weighted calculation by multiplying the number of second candidate hits by the preset second weight to obtain a second weighted score.

[0098] Step S423: Add the first weighted score and the second weighted score corresponding to each candidate identifier field to obtain the comprehensive score corresponding to each candidate identifier field.

[0099] It is understandable that the above comprehensive score can be a quantitative score obtained by accumulating the first weighted score and the second weighted score corresponding to the candidate identifier field. This score is used to comprehensively measure the confidence level of the candidate identifier field as the target field name.

[0100] In a specific implementation, after calculating the first weighted score and the second weighted score corresponding to each candidate identifier field, the aforementioned session flow determination device can accumulate the first weighted score and the second weighted score corresponding to each candidate identifier field, that is, add the first weighted score to the second weighted score to obtain the comprehensive score corresponding to the candidate identifier field.

[0101] Step S424: Determine the target field name based on the comprehensive score described above.

[0102] In its implementation, after calculating the comprehensive score for each candidate identifier field, the session flow determination device compares the comprehensive scores of each candidate identifier field and determines the target field name based on the comparison results. Specifically, the session flow determination device sorts the candidate identifier fields in descending order of comprehensive score and determines the field name corresponding to the candidate identifier field with the highest comprehensive score as the target field name. Thus, the session flow determination device completes the target field name filtering operation based on the weighted comprehensive score mechanism.

[0103] This embodiment obtains the number of hits of the first candidate and the number of hits of the second candidate for each candidate identifier field. It then calculates a first weighted score and a second weighted score by weighting the candidate identifier fields according to a preset first weight and a preset second weight, respectively. Finally, it sums the first weighted score and the second weighted score for each candidate identifier field to obtain a comprehensive score. Finally, it determines the target field name based on each comprehensive score. This achieves the assignment of differentiated confidence weights to candidate identifier fields from different sources, avoiding the problem that the simple summation of occurrence counts cannot distinguish the different confidence contributions of cross-path invariance analysis and same-path difference analysis to the same field name. This improves the accuracy and rationality of target field name selection.

[0104] Furthermore, while the hit count of candidate identifier fields is an important criterion for determining their suitability as target field names, relying solely on the count may still present difficulties in certain special scenarios. For example, some fields may have a low hit count but possess clear identity identification semantics in their naming, or some fields may have a high hit count but, based on their value structure, clearly belong to device fingerprints or link tracing identifiers rather than core authentication credentials. In such cases, if sorting and selection are based solely on the count count, it is difficult to accurately distinguish between genuine login status fields and randomly hit noise fields. To more comprehensively evaluate the confidence level of each candidate identifier field and improve the accuracy of target field name selection, in this embodiment, the step of determining the target field name based on the occurrence count of each field name in each of the first and second candidate identifier fields includes: Step S431: Match the field names in each of the first candidate identifier fields and each of the second candidate identifier fields with the preset identity identifier keyword library to obtain the matching results, and determine the corresponding semantic score of the field name based on each matching result.

[0105] It should be noted that the aforementioned preset identity identifier keyword library can be a pre-built collection of one or more words with identity identifier semantics. The words in this keyword library are used to match the field names of candidate identifier fields to identify their semantic tendencies. For example, the keyword library contains words such as token, session, auth, user, and login.

[0106] It should also be noted that the semantic score of the above field name can be a value determined based on the matching results of the field name of the candidate identifier field and the preset identity identifier keyword library. This score is used to quantitatively evaluate the likelihood that the field name carries identity identifier information at the semantic level.

[0107] In its implementation, after obtaining each first candidate identifier field and each second candidate identifier field, the aforementioned session flow determination device can extract the field names corresponding to each first candidate identifier field and each second candidate identifier field, respectively. Next, the session flow determination device can match each field name with words in a preset identity identifier keyword library to determine whether each field name matches a word in the keyword library, thereby obtaining the matching result for each field name. Subsequently, based on the matching result, the session flow determination device can determine the corresponding semantic score for each candidate identifier field.

[0108] For ease of understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For instance, the preset identity identifier keyword library contains the words "token," "session," and "user." When the field name of a candidate identifier field is "token," the aforementioned session flow determination device matches this field name with the preset identity identifier keyword library. If the match is successful, the semantic score of the field name corresponding to the candidate identifier field is determined to be high (e.g., 10 points). When the field name of another candidate identifier field is "timestamp," and the match with the preset identity identifier keyword library fails, the semantic score of the field name corresponding to the candidate identifier field is determined to be low (e.g., 0 points).

[0109] Step S432: Compare the field values ​​in each of the first candidate identifier fields and each of the second candidate identifier fields with the preset structure rules to obtain the comparison results, and determine the field value structure score based on the comparison results.

[0110] It should be understood that the aforementioned preset structural rules can be pre-defined criteria for identifying whether field values ​​conform to certain structural features. These preset structural rules are used to evaluate whether field values ​​have typical morphological features of identity information at the structural level. For example, the rules can include judgment conditions for structural features such as JWT three-segment structure, high-entropy random strings, and Universally Unique Identifier (UUID) format.

[0111] It should also be understood that the above field value structure score can be a value determined based on the comparison result of the field value of the candidate identifier field with the preset structure rules. This score is used to quantitatively evaluate how much the structural characteristics of the field value conform to the typical form of identity information.

[0112] In its implementation, after obtaining each first candidate identifier field and each second candidate identifier field, the session flow determination device can extract the field values ​​corresponding to each first candidate identifier field and each second candidate identifier field. Next, the session flow determination device can compare each field value with a preset structural rule to determine whether each field value conforms to the structural features defined by the preset structural rule, thereby obtaining the comparison result for each field value. Subsequently, based on the comparison result, the session flow determination device can determine the corresponding field value structure score for each candidate identifier field.

[0113] To facilitate understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For example, the preset structure rule includes a JWT three-segment structure determination condition. When the field value of a candidate identifier field is eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dBvP8, the aforementioned session flow determination device compares this field value with the preset structure rule. If the field value conforms to the JWT three-segment structure characteristics, then the field value structure score corresponding to the candidate identifier field is determined to be higher. When the field value of another candidate identifier field is abc123, this field value does not conform to the preset structure rule, then the field value structure score corresponding to the candidate identifier field is determined to be lower or zero.

[0114] Step S433: Determine the auxiliary confidence level corresponding to each first candidate identifier field and each second candidate identifier field based on the semantic score of the field name and the structural score of the field value, and determine the target field name based on the auxiliary confidence level and the number of occurrences of each field name in each first candidate identifier field and each second candidate identifier field.

[0115] It is understandable that the aforementioned auxiliary confidence score can be a comprehensive quantitative value obtained by combining the semantic score of the field name and the structural score of the field value corresponding to the candidate identifier field in a predetermined manner. This value is used to measure the probability that the candidate identifier field belongs to the identity identifier field in terms of field naming semantics and field value structural features. For example, the auxiliary confidence score can be obtained by adding or weighting the field name semantic score and the field value structural score.

[0116] In its implementation, after determining the semantic score of the field name and the structural score of the field value for each candidate identifier field, the session flow determination device can combine these scores for each candidate identifier field, for example, by adding or weighted summing, to determine the auxiliary confidence level for that candidate identifier field. Next, the session flow determination device can obtain the cumulative number of hits for each candidate identifier field. Subsequently, the session flow determination device can jointly determine the target field name based on the auxiliary confidence level of each candidate identifier field and the cumulative number of hits for each candidate identifier field.

[0117] To facilitate understanding, the following examples are provided for illustration, but they do not impose specific limitations on this embodiment. For instance, the candidate identifier field SX-Token has a semantic score of 9 points for its field name and a structural score of 8 points for its field value. The aforementioned session flow determination device adds these two scores to obtain an auxiliary confidence score of 17 points, and the candidate identifier field has been hit a cumulative total of 12,625 times. The candidate identifier field sr_fp_value has a semantic score of 2 points for its field name and a structural score of 7 points for its field value. The aforementioned session flow determination device adds these two scores to obtain an auxiliary confidence score of 9 points, and the candidate identifier field has been hit a cumulative total of 12,679 times. The aforementioned session flow determination device comprehensively considers both auxiliary confidence and cumulative counts. Although sr_fp_value has a higher cumulative count, its auxiliary confidence score is significantly lower than that of SX-Token. Therefore, SX-Token is determined as the target field name.

[0118] This embodiment obtains the semantic score of the field name by matching the field names in each first candidate identifier field and each second candidate identifier field with a preset identity identifier keyword library, and obtains the field value structure score by comparing the field values ​​in each first candidate identifier field and each second candidate identifier field with preset structure rules. Then, it determines the auxiliary confidence level corresponding to each candidate identifier field based on the field name semantic score and the field value structure score. Finally, it determines the target field name based on each auxiliary confidence level and the occurrence frequency of each field name. This realizes that in addition to statistical hit count, it further introduces the semantic features of field naming and the structural features of field value as auxiliary discrimination criteria, which effectively avoids the risk of misselecting non-login state fields such as global link fingerprint and device identifier as target field names when simply relying on the occurrence frequency, thereby significantly improving the accuracy of target field name selection.

[0119] In addition, refer to Figure 5 , Figure 5 This is a structural block diagram of the session flow determination device of this application. Figure 5 As shown in the embodiments of this application, a session flow determination device is also proposed, which includes: The traffic parsing module 501 is used to parse the network traffic collected by the bypass mirror to obtain request logs. The request logs contain at least two request paths to be analyzed and corresponding field information, including field names and corresponding field values. The first field confirmation module 502 is used to select the field information in the requests to be analyzed from different request paths, where the field name and the corresponding field value are the same, as the first candidate identifier field. The second field confirmation module 503 is used to select the field information in the requests to be analyzed with the same field name but different corresponding field values ​​as the second candidate identifier field; The session flow determination module 504 is used to determine the target field name based on the number of occurrences of each field name in each of the first candidate identifier fields and each of the second candidate identifier fields, and to determine the corresponding session flow from the request log based on the target field name.

[0120] Furthermore, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements the steps of the session flow determination method described above.

[0121] Other embodiments or specific implementations of the session flow determination device described in this example can be found in the above-described method embodiments, and will not be repeated here.

[0122] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0123] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0124] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as a read-only memory image (ROM) / random access memory (RAM), magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0125] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for determining a session flow, characterized in that, The method includes: The network traffic collected by the bypass mirror is parsed to obtain request logs. The request logs contain at least two request paths to be analyzed and corresponding field information, including field names and corresponding field values. The field information in the requests to be analyzed from different request paths, where the field name and the corresponding field value are the same, is taken as the first candidate identifier field; In the requests to be analyzed with the same request path, the field information with the same field name but different corresponding field values ​​is used as the second candidate identifier field; The target field name is determined based on the number of occurrences of each field name in each of the first candidate identifier fields and each of the second candidate identifier fields, and the corresponding session stream is determined from the request log based on the target field name.

2. The method as described in claim 1, characterized in that, Before the step of using the field information in the requests to be analyzed from different request paths, where the field name and the corresponding field value are the same, as the first candidate identifier field, the following steps are included: The request log is divided into time windows according to a preset time length to obtain request windows. The number of requests contained in each request window is determined by statistics. Each request window whose number of requests exceeds a preset request threshold is designated as a high-density window, and the requests within the high-density windows are designated as the requests to be analyzed.

3. The method as described in claim 2, characterized in that, The step of determining the target field name based on the occurrence frequency of each field name in each of the first candidate identifier fields and each of the second candidate identifier fields includes: Obtain the number of occurrences of each field name in each of the first candidate identifier fields and each of the second candidate identifier fields in each of the high-density windows; Sort the occurrence counts of each field name to obtain a count list, and determine the field name that appears most frequently in the count list as the target field name.

4. The method as described in claim 3, characterized in that, The step of sorting the occurrence counts of each field name to obtain a count list, and determining the field name with the highest occurrence count in the count list as the target field name, includes: The frequency of occurrence of each field name is sorted to obtain a frequency list. The field names whose ranking in the frequency list is less than a preset selection threshold are transmitted to the user so that the user can determine the target field name from the field names.

5. The method as described in claim 1, characterized in that, The step of determining the corresponding session stream from the request log based on the target field name includes: Based on the target field name, extract the corresponding field value from the request log, and group the requests with the same field value into a group to obtain each target request group; Based on the request initiation time of each request in each target request group, the requests in each target request group are sorted to obtain each target request sequence, and each target request sequence is used as the session stream of the corresponding target subject.

6. The method as described in claim 1, characterized in that, The step of determining the target field name based on the frequency of occurrence of each field name in each of the first candidate identifier fields and each of the second candidate identifier fields includes: Obtain the first candidate hit count and the second candidate hit count corresponding to each candidate identifier field. The first candidate hit count is the number of times the candidate identifier field is hit as the first candidate identifier field, and the second candidate hit count is the number of times the candidate identifier field is hit as the second candidate identifier field. The first candidate hit count is weighted according to a preset first weight to obtain a first weighted score, and the second candidate hit count is weighted according to a preset second weight to obtain a second weighted score. The first weighted score and the second weighted score corresponding to each candidate identifier field are summed to obtain the comprehensive score corresponding to each candidate identifier field. The target field name is determined based on the comprehensive score described above.

7. The method as described in claim 1, characterized in that, The step of determining the target field name based on the occurrence frequency of each field name in each of the first candidate identifier fields and each of the second candidate identifier fields includes: The field names in each of the first candidate identifier fields and each of the second candidate identifier fields are matched with a preset identity identifier keyword library to obtain matching results, and the corresponding semantic score of the field name is determined based on the matching results; The field values ​​in each of the first candidate identifier fields and each of the second candidate identifier fields are compared with the preset structure rules to obtain the comparison results, and the field value structure score is determined based on the comparison results. Based on the semantic score of the field name and the structural score of the field value, the auxiliary confidence level corresponding to each first candidate identifier field and each second candidate identifier field is determined, and the target field name is determined based on each auxiliary confidence level and the number of occurrences of each field name in each first candidate identifier field and each second candidate identifier field.

8. A session flow determination device, characterized in that, The device includes: The traffic parsing module is used to parse the network traffic collected by the bypass mirror to obtain request logs. The request logs contain at least two request paths to be analyzed and corresponding field information, including field names and corresponding field values. The first field confirmation module is used to select the field information in the requests to be analyzed from different request paths, where the field name and the corresponding field value are the same, as the first candidate identifier field. The second field confirmation module is used to select the field information in the requests to be analyzed that have the same field name but different corresponding field values ​​as the second candidate identifier field; The session flow determination module is used to determine the target field name based on the number of occurrences of each field name in each of the first candidate identifier fields and each of the second candidate identifier fields, and to determine the corresponding session flow from the request log based on the target field name.

9. A session flow determination device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the session flow determination method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the session flow determination method as described in any one of claims 1 to 7.

Images