Communication Method and Device

Abstract

The present application provides a communication method and apparatus. The method is applied to a network device and includes: obtaining a first read response data packet sent by a server to a client, where the first read response data packet includes first file content and a first request sequence number; obtaining a second request sequence number from a first node included in a first queue, where the first node is the head node of the first queue; determining whether the first request sequence number is the same as the second request sequence number; if they are the same, performing DPI service processing on the first file content; if they are different, caching the first response data packet; where the first queue includes at least one node, and the request sequence number stored in the head node included in the first queue is the minimum value.

Description

Technical Field

[0001] This application relates to the field of communication technologies, and in particular, to a communication method and apparatus. Background Art

[0002] Deep Packet Inspection (DPI) is a security mechanism for detecting and controlling service traffic passing through network devices based on application layer information.

[0003] In increasingly complex network security threats, many malicious behaviors (such as worm viruses, spam, vulnerabilities, etc.) are hidden in the application layer payloads of data packets. Traditional security protection technologies relying solely on security detection technologies at the network layer and transport layer can no longer meet network security requirements. Therefore, network devices must have DPI capabilities to implement detection and control of network application layer information to ensure the security of data content and improve network security.

[0004] In one scenario, a client pre-reads a file from a server (for example, a Server Message Block (SMB) server). The specific process is as follows:

[0005] The client first sends an NT_CREATE_ANDX Request packet to the server to request the server to open the file. The server returns an NT_CREATE_ANDX Response packet to inform the client that the file has been opened. The client sends a READ_ANDX Request packet to the server to request to read the file. The READ_ANDX Response packet returned by the server is used to transmit the file content to the client. After the transmission is completed, the client sends a CLOSE Request packet to the server to request to close the file. The server returns a CLOSE Response packet to inform the client that the file has been closed.

[0006] In the above process, when the client sends READ_ANDX Request packets, it sequentially sends multiple packets in the order of reading the file content. However, when the server returns READ_ANDX Response packets, it does not sequentially respond to the READ_ANDX Request packets in the order of reading the file content. As such, the file content will be out of order.

[0007] The out-of-order content of the above-mentioned file specifically refers to the out-of-order content at the application layer, rather than the out-of-order content at the IP network layer and the TCP transport layer. Since the processing of the Deepth Inspect Manager (DIM) engine is flow-based, if the content of the file is out of order during the file transfer process, it will lead to algorithm-level errors, protocol recognition failures, parsing failures, file recognition failures, and missed reports of attack feature recognition during the parsing of the message. Summary of the Invention

[0008] In view of this, the present application provides a communication method and device to solve the problem that the content of the file is prone to out-of-order during the file transfer process between the existing client and the server.

[0009] In a first aspect, the present application provides a communication method, which is applied to a network device, and the method includes:

[0010] Obtain a first read response data packet sent by the server to the client, where the first read response data packet includes first file content and a first request sequence number;

[0011] Obtain a second request sequence number from the first node included in the first queue, where the first node is the head node of the first queue;

[0012] Determine whether the first request sequence number is the same as the second request sequence number;

[0013] If they are the same, perform DPI service processing on the first file content;

[0014] If they are different, cache the first response data packet;

[0015] Wherein, the first queue includes at least one node, and the request sequence number stored in the head node included in the first queue is the minimum value.

[0016] In a second aspect, the present application provides a communication device, which is applied to a network device, and the device includes:

[0017] A first obtaining unit, configured to obtain a first read response data packet sent by the server to the client, where the first read response data packet includes first file content and a first request sequence number;

[0018] A second obtaining unit, configured to obtain a second request sequence number from the first node included in the first queue, where the first node is the head node of the first queue;

[0019] A first determining unit, configured to determine whether the first request sequence number is the same as the second request sequence number;

[0020] A service processing unit, configured to perform DPI service processing on the first file content if they are the same;

[0021] A cache unit, configured to cache the first response data packet if they are different;

[0022] Wherein, the first queue includes at least one node, and the request sequence number stored in the head node included in the first queue is the minimum value.

[0023] In a third aspect, the present application provides a network device, including a processor and a machine-readable storage medium. The machine-readable storage medium stores machine-executable instructions that can be executed by the processor, and the processor is prompted by the machine-executable instructions to execute the method provided in the first aspect of the present application.

[0024] Therefore, by applying the communication method and device provided in the present application, the network device obtains a first read response data packet sent by the server to the client. The first read response data packet includes the first file content and the first request sequence number. The network device obtains a second request sequence number from the first node included in the first queue, and the first node is the head node of the first queue. The network device determines whether the first request sequence number is the same as the second request sequence number. If they are the same, the network device performs DPI service processing on the first file content. If they are different, the network device caches the first response data packet. Wherein, the first queue includes at least one node, and the request sequence number stored in the head node included in the first queue is the minimum value.

[0025] In this way, by using the request sequence numbers sent between the client and the server, the network device processes the matching file content according to the request sequence number. It solves the problem that the file content is prone to out-of-order during the file transfer process between the existing client and the server. It ensures the sequential processing of the file content, thereby improving the ability to detect files. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 It is a flowchart of the communication method provided by the embodiment of the present application;

[0027] Figure 2 It is a structural diagram of the communication device provided by the embodiment of the present application;

[0028] Figure 3 It is a hardware structure diagram of the network device provided by the embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0029] Exemplary embodiments will be described in detail herein, and examples thereof are shown in the accompanying drawings. When the following description refers to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0030] The terms used in the present application are for the purpose of describing specific embodiments only and are not intended to limit the present application. The singular forms "a", "the", and "said" used in the present application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the corresponding listed items.

[0031] It should be understood that although the terms first, second, third, etc. may be used in the present application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of the present application, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "when" or "while" or "in response to determining".

[0032] The communication method provided by the embodiments of the present application will be described in detail below. Refer to Figure 1 , Figure 1 which is a flowchart of the communication method provided by the embodiments of the present application. This method is applied to a network device, which may specifically be a firewall device capable of processing DPI services. The communication method provided by the embodiments of the present application may include the following steps.

[0033] Step 110: Obtain a first read response packet sent by the server to the client, where the first read response packet includes first file content and a first request sequence number;

[0034] Specifically, the client, the network device, and the server are in the same local area network. The network device is between the client and the server, and it can capture various packets exchanged between the client and the server. For example, read request packets, read response packets, write request packets, write response packets, and so on.

[0035] After the server receives the first read request data packet (e.g., READ_ANDX Request) sent by the client, according to the first read request data packet, it obtains the first file content in the corresponding file. The server generates a first read response data packet (e.g., READ_ANDX Response), and this first read response data packet includes the first file content and the first request sequence number.

[0036] The server sends the first read response data packet to the client.

[0037] After the network device obtains the first read response data packet, it obtains the first file content and the first request sequence number therefrom.

[0038] It should be noted that the first read request data packet includes the length of the first file content, the starting position of the first file content, and the second request serial number. The server can obtain the first file content from the file according to the length of the first file content and the starting position of the first file content.

[0039] Normally, after the server receives the read request data packet, it uses the request sequence number included in the read request data packet as the request sequence number included in the read response data packet corresponding to the read request data packet.

[0040] Optionally, before step 110, it further includes that the network device obtains the first read request data packet sent by the client to the server, and the network device stores the content included in the read request data packet corresponding to the node of the first queue, that is, Req_Queue1.

[0041] Taking the example that the client pre-reads a file from the server (e.g., SMB server) for illustration.

[0042] When accessing a file through file sharing within a local area network, an SMB session authentication is first performed between the client and the server. The client first sends a create request (e.g., NT_CREATE_ANDX Request) data packet to the server to request the server to open the file. The server returns a create response (e.g., NT_CREATE_ANDX Response) data packet to inform the client that the file has been opened.

[0043] The client sends a first read request data packet to the server to request to read the file. The network device obtains this first read request data packet, and this first read request data packet includes the length (len) of the first file content to be read by the client, the starting position of the first file content (which can also be called the offset) and the second request sequence number (messageID).

[0044] Among them, len is the length of the file content to be read currently. Offset is the offset position of the file content to be read currently in the entire file. The messageID can be specifically a number, for example, 1, 2, 3, etc. After the client sends each read request data packet, the messageID is incremented by 1. In the embodiments of the present application, the messageIDs of the request data packet and the response data packet should be correspondingly matched.

[0045] If the offset is 0 and the messageID is 1, the network device determines that the first read request data packet is the first read request data packet for reading the file, and the network device can use this messageID as the lastReqID. If the sum of len and offset is file_size, that is, the sum value is the total length of the file to be read currently, the network device determines that the first read request data packet is the last read request data packet for reading the file. The network device can set the messageID as the endOfFileID.

[0046] In the embodiments of the present application, the network device uses Req_Queue1 locally to record the request sequence number, len, and offset. Req_Queue1 includes at least one node, and each node is used to store the request sequence number. The nodes are sorted in ascending order of the request sequence number. The request sequence number stored in the first node of Req_Queue1 is the minimum value of all request sequence numbers. Of course, the content such as len and offset can also be stored at the node where the corresponding request sequence number is located.

[0047] After the network device obtains the first read request data packet, it caches the second request sequence number to the first node included in Req_Queue1 (the network device caches it to the corresponding node according to the size of the second request sequence number. Here, the first node is taken as an example for illustration). The network device calculates the sum of the first file content length and the starting position of the first file content to obtain a first value, that is, the first value = len + offset. The network device obtains the second value stored in the SMB protocol parsing plugin locally. The network device determines whether the second value is the same as the starting position of the first file content.

[0048] If they are the same, the network device determines that the current client reads the file content in sequential order, and the network device updates the second value with the first value; if they are different, the network device determines that the current client reads the file content in disorder and keeps the second value unchanged. The network device also caches the first file content length and the starting position of the first file content to the first node.

[0049] Similarly, when the network device obtains the second read request data packet sent by the client to the server, the network device caches the third request sequence number included in the second read request data packet at the third node (taking the third node as an example for illustration here, it can also be the second node) included in Req_Queue1. The network device compares whether the second value is the same as the second file content start position included in the second read request data packet.

[0050] If they are not the same, the network device determines that the current client reads the file content in disorder and keeps the second value unchanged. The network device caches the second file content length and the second file content start position included in the second read request data packet at the third node. If they are the same, the network device determines that the current client reads the file content in sequence. The network device calculates the sum value of the second file content length and the second file content start position to obtain the third value, and updates the second value with the third value.

[0051] In the embodiment of the present application, the network device locally includes an SMB protocol parsing plugin. The second value stored in the SMB protocol parsing plugin is specifically NextReqOffset. That is, the offset value that the next request data packet should carry. NextReqOffset corresponds to different values according to different request types. For example, when it is a read request data, NextReqOffset is specifically the second value; when it is a write request data packet, NextReqOffset is specifically the fourth value (taking the fourth value as an example for illustration here, it can also be the third value). In subsequent embodiments, the fourth value will be specifically introduced.

[0052] In an example, the second value stored in the local SMB protocol parsing plugin of the network device is 0. The network device receives the first read request data packet, the first file content length (len) is 40, the first file content start position (offset) is 0, and the second request sequence number (messageID) is 1.

[0053] The network device caches the second request sequence number 1 at the first node and determines that the first read request data packet is the first read request data packet. The network device calculates the sum value of the first file content length and the first file content start position to obtain the first value as 40. The network device obtains the second value from the SMB protocol parsing plugin and compares whether the second value is the same as the first file content start position.

[0054] In this example, the second value is the same as the first file content start position. The network device determines that the current client reads the file content in sequence. The network device updates the second value 0 with the first value 40. At this time, the second value is 40.

[0055] At this time, the network device obtains the second read request data packet sent by the client to the server. The second file content length (len) is 40, the second file content start position (offset) is 120, and the third request sequence number (messageID) is 2.

[0056] The network device caches the third request sequence number 2 at the third node. It can be understood that the third node is adjacent to the first node and is behind the first node. The network device obtains the second value 40 from the SMB protocol parsing plugin and compares whether the second value is the same as the second file content start position.

[0057] In this example, the second value is different from the second file content start position. The network device determines that the current client reads the file content in disorder, and the network device caches the second file content length and the second file content start position at the third node.

[0058] In another example, at this time, the network device obtains the second read request data packet sent by the client to the server. The second file content length (len) is 40, the second file content start position (offset) is 40, and the third request sequence number (messageID) is 2.

[0059] The network device caches the third request sequence number 2 at the third node. It can be understood that the third node is adjacent to the first node and is behind the first node. The network device obtains the second value 40 from the SMB protocol parsing plugin and compares whether the second value is the same as the second file content start position.

[0060] In this example, the second value is the same as the second file content start position. The network device determines that the current client reads the file content sequentially. The network device calculates the sum of the second file content length and the second file content start position, obtains the first value as 80, and updates the second value 40 with the first value 80. At this time, the second value is 80.

[0061] It can be understood that after the network device obtains each read request data packet sent by the client to the server, it first stores the request sequence number at the node of Req_Queue1 in ascending order. Then, the network device compares whether the value in the SMB protocol parsing plugin is the same as the file content start position.

[0062] If they are the same, the network device determines that the client reads the file content sequentially. The network device calculates the sum of the file content length and the file content start position and updates the value in the SMB protocol parsing plugin with the sum.

[0063] If they are different, the network device determines that the client reads the file content in an out-of-order manner. The network device maintains the values in the SMB protocol parsing plugin and caches the file content length and the starting position of the file content at the node where the request sequence number is located.

[0064] The network device repeats the above process.

[0065] Step 120: Obtain a second request sequence number from the first node included in the first queue, where the first node is the head node of the first queue;

[0066] Specifically, according to the description in step 110, the network device obtains the second request sequence number cached in the head node included in Req_Queue1.

[0067] Step 130: Determine whether the first request sequence number is the same as the second request sequence number;

[0068] Specifically, according to the description in step 120, after the network device obtains the second request sequence number, it compares whether the first request sequence number is the same as the second request sequence number. If they are the same, the network device executes step 140; if they are different, the network device executes step 150.

[0069] Step 140: If they are the same, perform DPI service processing on the first file content;

[0070] Specifically, according to the description in step 130, if the first request sequence number is the same as the second request sequence number, the network device determines that the first read response packet is the response packet corresponding to the first read request packet.

[0071] The network device performs DPI service processing on the first file content.

[0072] Optionally, after the network device performs DPI service processing on the first file content, the network device deletes the first node from Req_Queue1. At this time, the next node adjacent to the first node is upgraded to the head node of the first queue, and the request sequence number cached in this node is the minimum value of all request sequence numbers.

[0073] Step 150: If they are different, cache the first response packet.

[0074] Specifically, according to the description in step 130, if the first request sequence number is different from the second request sequence number, the network device determines that the first read response packet is not the response packet corresponding to the first read request packet, and determines that the server does not return the read response packets in order. The network device does not perform DPI service processing on the first file content first.

[0075] The network device caches the first response packet.

[0076] Optionally, the network device caches the first response data packet. The specific process is as follows: The network device caches the first request sequence number at the second node included in Req_Queue1, and caches the first file content at the second node.

[0077] Therefore, by applying the communication method provided in this application, the network device obtains the first read response data packet sent by the server to the client. The first read response data packet includes the first file content and the first request sequence number. The network device obtains the second request sequence number from the first node included in the first queue. The first node is the head node of the first queue. The network device determines whether the first request sequence number is the same as the second request sequence number. If they are the same, the network device performs DPI service processing on the first file content. If they are different, the network device caches the first response data packet. Among them, the first queue includes at least one node, and the request sequence number stored in the head node included in the first queue is the minimum value.

[0078] In this way, by using the request sequence numbers sent by the client and the server to each other, the network device performs service processing on the matching file content according to the request sequence number. This solves the problem that the file content is prone to out-of-order during the file transmission process between the existing client and the server. It ensures the sequential processing of the file content, thereby improving the ability to detect files.

[0079] Optionally, in the embodiment of this application, it further includes the process in which the network device identifies whether the first request sequence number is the final sequence number, and then ends the current file transmission process.

[0080] Specifically, the network device repeatedly executes the foregoing step 110-step 150. After obtaining the first request sequence number each time, it determines whether the first request sequence number is the final sequence number, that is, whether the first request sequence number is endOfFileID.

[0081] If so, it is determined that the server has transmitted the last part of the file content, and the network device traverses the file content. If the file end marker is traversed, the network device ends the current file transmission process.

[0082] Among them, the value of endOfFileID is the total file length of the file to be obtained. The total file length of the file to be obtained is the sum of the file content length of the file to be obtained and the starting position of the file content of the file to be obtained.

[0083] Optionally, if the file end marker is not traversed, the network device determines that the file transmission in the current file transmission process is incomplete, and the network device cannot end the current file transmission process.

[0084] If the current file transmission process is not ended, then when the network device obtains a close request data packet (for example, a CLOSE Request data packet) sent by the client to the server, it ends the current file transmission process.

[0085] Optionally, in the embodiments of the present application, the above descriptions are all given by taking the interaction of read request data packets and read response data packets between the client and the server as an example. In the actual process, write request data packets and write response data packets are also interacted between the client and the server.

[0086] The following takes the interaction of write request data packets and write response data packets between the client and the server as an example for description.

[0087] Specifically, an SMB session authentication is first performed between the client and the server. The client first sends a create request (for example, NT_CREATE_ANDX Request) data packet to the server to request the server to create and open a new file. The server returns a create response (for example, NT_CREATE_ANDX Response) data packet to inform the client that the file has been created and opened.

[0088] The client sends a first write request data packet (for example, WRITE_ANDX Request) to the server. The first write request data packet includes the third file content to be written by the client, the length of the third file content, the starting position of the third file content, and the fourth request sequence number.

[0089] The network device obtains the first write request data packet, and obtains the third file content, the length of the third file content, the starting position of the third file content, and the fourth request sequence number from the first write request data packet.

[0090] The network device calculates the sum value of the length of the third file content and the starting position of the third file content to obtain a third value. The network device obtains a fourth value stored in the local SMB protocol parsing plugin. The network device determines whether the fourth value is the same as the starting position of the third file content.

[0091] If they are the same, the network device determines that the file content written by the client is sequential writing, and updates the fourth value with the third value; if they are different, the network device determines that the file content written by the client is out-of-order writing, and maintains the fourth value stored in the local SMB protocol parsing plugin.

[0092] Further, after the network device updates the fourth value with the third value, DPI service processing is performed on the third file content.

[0093] After the network device maintains the fourth value stored in the local SMB protocol parsing plugin, it caches the third file content, the length of the third file content, and the starting position of the third file content at the first node included in the second queue (for example, Req_Queue2).

[0094] It can be understood that Req_Queue2 has the same structure and function as Req_Queue1. Each node can be used to record len, offset, and file content. Req_Queue1 corresponds to the obtained read request data packet and read response data packet; Req_Queue2 corresponds to the obtained write request data packet.

[0095] In the embodiment of the present application, the network device no longer caches the fourth request sequence number in the node. The reason is that after the server receives the write request data packet and writes the file content to the corresponding position, it generates and sends a write response data packet (for example, WRITE_ANDX Response) to the client to inform the client of the write execution result. The write response data packet no longer includes the corresponding request sequence number, but includes whether the write is successful or failed.

[0096] It should be noted that after the network device maintains the fourth value stored in the local SMB protocol parsing plugin, if it subsequently receives a write request data packet, after the above calculations and judgments, if the fourth value is different from the starting position of the file content, the network device can traverse the offset stored in each node included in Req_Queue2 to find whether there is an offset that is the same as the fourth value. If it exists, the network device calculates the sum value of the offset and the len in the node and updates the fourth value with the sum value. After updating the fourth value, the network device performs DPI service processing on the file content stored in the node. After performing DPI service processing, the network device deletes the offset, len, and file content stored in the node.

[0097] In an example, the fourth value stored in the local SMB protocol parsing plugin of the network device is 0. The network device receives the first write request data packet, the length of the third file content (len) is 40, the starting position of the third file content (offset) is 0, and the fourth request sequence number (messageID) is 1.

[0098] The network device calculates the sum value of the length of the third file content and the starting position of the third file content, and obtains the third value as 40. The network device obtains the fourth value from the SMB protocol parsing plugin and compares whether the fourth value is the same as the starting position of the third file content.

[0099] In this example, the fourth value is the same as the starting position of the third file content. The network device determines that the file content written by the current client is written sequentially. The network device updates the fourth value 0 with the third value 40. At this time, the fourth value is 40. The network device performs DPI service processing on the third file content.

[0100] At this time, the network device obtains the second write request data packet sent by the client to the server, where the fourth file content length (len) is 40, the fourth file content start position (offset) is 120, and the fifth request sequence number (messageID) is 2.

[0101] The network device obtains the fourth value 40 from the SMB protocol parsing plugin again and compares whether the fourth value is the same as the fourth file content start position.

[0102] In this example, the fourth value is different from the fourth file content start position. The network device determines that the current client reads the file content in disorder. The network device caches the fourth file content length, the fourth file content start position, and the fourth file content at the first node included in Req_Queue2.

[0103] In another example, the fourth value stored in the local SMB protocol parsing plugin of the network device is 40. The nodes 1, 2, and 3 included in Req_Queue2 all store the corresponding offset, len, and file content.

[0104] Node 1 stores offset1 as 40, len1 as 40, and file content 1; Node 2 stores offset2 as 120, len2 as 40, and file content 2; Node 3 stores offset3 as 200, len3 as 40, and file content 3.

[0105] At this time, the network device obtains the second read request data packet sent by the client to the server, where the third file content length (len) is 40, the third file content start position (offset) is 160, and the fourth request sequence number (messageID) is 2.

[0106] The network device obtains the fourth value 40 from the SMB protocol parsing plugin and compares whether the fourth value is the same as the third file content start position.

[0107] In this example, the fourth value is different from the third file content start position. The network device determines that the current client reads the file content in disorder. The network device traverses the offsets stored in nodes 1, 2, and 3 and finds that the offset1 stored in node 1 is the same as the fourth value. The network device calculates the sum value of offset1 and len1 as 80 and updates the fourth value with this sum value 80. After updating the fourth value to 80, the network device performs DPI service processing on file content 1. After performing DPI service processing, the network device deletes offset1, len1, and file content 1 stored in node 1.

[0108] Based on the same inventive concept, the embodiments of the present application also provide a communication device. SeeFigure 2 , Figure 2 A communication device provided by an embodiment of this application. The device is applied to a network device and includes:

[0109] A first acquisition unit 210, configured to acquire a first read response data packet sent by a server to a client, where the first read response data packet includes first file content and a first request sequence number;

[0110] A second acquisition unit 220, configured to acquire a second request sequence number from a first node included in a first queue, where the first node is the head node of the first queue;

[0111] A first determination unit 230, configured to determine whether the first request sequence number is the same as the second request sequence number;

[0112] A service processing unit 240, configured to, if they are the same, perform DPI service processing on the first file content;

[0113] A cache unit 250, configured to, if they are different, cache the first response data packet;

[0114] Wherein, the first queue includes at least one node, and the request sequence number stored in the head node included in the first queue is the minimum value.

[0115] Optionally, the first acquisition unit 210 is further configured to acquire a first read request data packet sent by the client to the server, where the first read request data packet includes the length of the first file content to be read by the client, the starting position of the first file content, and a second request sequence number;

[0116] The cache unit 250 is further configured to cache the second request sequence number at the first node;

[0117] The device further includes: a calculation unit (not shown in the figure), configured to calculate the sum value of the length of the first file content and the starting position of the first file content to obtain a first value;

[0118] A third acquisition unit (not shown in the figure), configured to acquire a second value stored in a local SMB protocol parsing plug-in;

[0119] A second determination unit (not shown in the figure), configured to determine whether the second value is the same as the starting position of the first file content;

[0120] An update unit (not shown in the figure), configured to, if they are the same, update the second value with the first value;

[0121] The cache unit 250 is further configured to, if they are different, maintain the second value stored in the local SMB protocol parsing plugin, and cache the first file content length and the starting position of the first file content at the first node;

[0122] Wherein, the first file content is determined by the server according to the first file content length and the starting position of the first file content.

[0123] Optionally, the device further includes: a deletion unit (not shown in the figure), configured to delete the first node from the first queue.

[0124] Optionally, the cache unit 250 is specifically configured to cache the first request sequence number at a second node included in the first queue, and cache the first file content at the second node.

[0125] Optionally, the device further includes: a third determination unit (not shown in the figure), configured to determine whether the first request sequence number is the final sequence number;

[0126] An end unit (not shown in the figure), configured to, if so, end the current file transfer process;

[0127] Wherein, the value of the final sequence number is the total length of the file to be obtained, and the total length of the file to be obtained is the sum of the file content length of the file to be obtained and the starting position of the file content of the file to be obtained.

[0128] Optionally, the end unit (not shown in the figure) is further configured to, if the current file transfer process has not ended, end the current file transfer process when a close request data packet sent by the client to the server is received.

[0129] Optionally, the first acquisition unit 210 is further configured to acquire a first write request data packet sent by the client to the server, where the first write request data packet includes a third file content to be written by the client, a third file content length, and a starting position of the third file content;

[0130] The calculation unit (not shown in the figure) is further configured to calculate a sum value of the third file content length and the starting position of the third file content to obtain a third value;

[0131] The third acquisition unit (not shown in the figure) is further configured to acquire a fourth value stored in the local SMB protocol parsing plugin;

[0132] The second determination unit (not shown in the figure) is further configured to determine whether the fourth value is the same as the starting position of the third file content;

[0133] The update unit (not shown in the figure) is further configured to, if they are the same, use the third one to update the fourth value;

[0134] The cache unit 250 is further configured to, if they are different, maintain the fourth value stored in the local SMB protocol parsing plug-in.

[0135] Optionally, the service processing unit 240 is further configured to perform DPI service processing on the third file content.

[0136] Optionally, the cache unit 250 is further configured to cache the third file content, the third file content length, and the third file content start position at the first node included in the second queue;

[0137] Wherein, the second queue includes at least one node, and each node is used to store the file content, the file content length, and the file content start position.

[0138] Therefore, by applying the communication device provided in this application, the network device obtains the first read response data packet sent by the server to the client, and the first read response data packet includes the first file content and the first request sequence number; the network device obtains the second request sequence number from the first node included in the first queue, and the first node is the head node of the first queue; the network device determines whether the first request sequence number is the same as the second request sequence number; if they are the same, the network device performs DPI service processing on the first file content; if they are different, the network device caches the first response data packet; wherein, the first queue includes at least one node, and the request sequence number stored in the head node included in the first queue is the minimum value.

[0139] In this way, by using the request sequence numbers mutually sent by the client and the server, the network device processes the matching file content according to the request sequence number. It solves the problem that the file content is prone to out-of-order during the file transfer process between the existing client and the server. It ensures the sequential processing of the file content, thereby improving the ability to detect files.

[0140] Based on the same inventive concept, an embodiment of this application further provides a network device, as Figure 3 shown, including a processor 310, a transceiver 320, and a machine-readable storage medium 330. The machine-readable storage medium 330 stores machine-executable instructions that can be executed by the processor 310, and the processor 310 is prompted by the machine-executable instructions to execute the communication method provided in the embodiment of this application. The foregoing Figure 2 shown communication device can be implemented by using the hardware structure of the network device as Figure 3 shown.

[0141] The above computer-readable storage medium 330 may include a Random Access Memory (RAM), and may also include a Non-volatile Memory (NVM), such as at least one disk memory. Optionally, the computer-readable storage medium 330 may also be at least one storage device located away from the aforementioned processor 310.

[0142] The above processor 310 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0143] In the embodiment of the present application, the processor 310 is caused by the machine-executable instructions read from the machine-readable storage medium 330 to be capable of implementing itself and invoking the transceiver 320 to execute the communication method described in the foregoing embodiment of the present application.

[0144] In addition, the embodiment of the present application provides a machine-readable storage medium 330. The machine-readable storage medium 330 stores machine-executable instructions. When the machine-executable instructions are called and executed by the processor 310, the machine-executable instructions cause the processor 310 itself and the transceiver 320 to be invoked to execute the communication method described in the foregoing embodiment of the present application.

[0145] The implementation processes of the functions and roles of each unit in the above device are specifically described in detail in the implementation processes of the corresponding steps in the above method, and will not be elaborated here.

[0146] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the descriptions of the method embodiments. The device embodiments described above are only illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this application. Those of ordinary skill in the art can understand and implement it without creative efforts.

[0147] For the communication device and machine-readable storage medium embodiments, since the method content involved is basically similar to the foregoing method embodiments, the descriptions are relatively simple, and the relevant parts can be referred to the descriptions of the method embodiments.

[0148] The above are only the preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of this application shall be included in the scope of protection of this application.

Claims

1. A communication method, characterized in that, The method is applied to a network device, and the method includes: Obtain a first read response data packet sent by a server to a client, where the first read response data packet includes first file content and a first request sequence number; Obtain a second request sequence number from a first node included in a first queue, where the first node is the head node of the first queue; Determine whether the first request sequence number is the same as the second request sequence number; If they are the same, perform DPI service processing on the first file content; If they are different, cache the first response data packet; Before obtaining the first read response data packet sent by the server to the client, the method further includes: Obtain a first read request data packet sent by the client to the server, where the first read request data packet includes the length of the first file content to be read by the client, the starting position of the first file content, and a second request sequence number; Cache the second request sequence number at the first node; Wherein, the first queue includes at least one node, and the request sequence number stored in the head node included in the first queue is the minimum value; each node also stores the file content length and the starting position of the file content corresponding to the request sequence number.

2. The method according to claim 1, wherein After caching the second request sequence number at the first node, the method further includes: Calculate the sum value of the first file content length and the starting position of the first file content to obtain a first value; Obtain a second value stored in a local SMB protocol parsing plugin; Determine whether the second value is the same as the starting position of the first file content; If they are the same, update the second value with the first value; If they are different, maintain the second value stored in the local SMB protocol parsing plugin, and cache the first file content length and the starting position of the first file content at the first node; Wherein, the first file content is determined by the server according to the first file content length and the starting position of the first file content.

3. The method according to claim 1, characterized in that, After performing DPI service processing on the first file content, the method further includes: Delete the first node from the first queue.

4. The method according to claim 1, wherein The caching of the first response data packet specifically includes: Cache the first request sequence number at a second node included in the first queue, and cache the first file content at the second node.

5. The method according to claim 1, wherein The method further includes: Determine whether the first request sequence number is the final sequence number; If so, end the current file transfer process; Wherein, the value of the final sequence number is the total length of the file to be obtained, and the total length of the file to be obtained is the sum of the file content length of the file to be obtained and the starting position of the file content of the file to be obtained.

6. The method according to claim 5, characterized in that, The method further includes: If the current file transfer process has not ended, then when a close request data packet sent by the client to the server is obtained, end the current file transfer process.

7. The method according to claim 1, characterized in that, The method further includes: Obtain a first write request data packet sent by the client to the server, where the first write request data packet includes the third file content to be written by the client, the third file content length, and the starting position of the third file content; Calculate the sum value of the length of the third file content and the starting position of the third file content to obtain a third value; Obtain a fourth value stored in the local SMB protocol parsing plugin; Determine whether the fourth value is the same as the starting position of the third file content; If they are the same, update the fourth value with the third value; If they are different, maintain the fourth value stored in the local SMB protocol parsing plugin.

8. The method according to claim 7, characterized in that, After updating the fourth value with the third value, the method further includes: Perform DPI service processing on the third file content.

9. The method according to claim 7, characterized in that After maintaining the fourth value stored in the local SMB protocol parsing plugin, the method further includes: Cache the third file content, the length of the third file content, and the starting position of the third file content at a first node included in a second queue; Wherein, the second queue includes at least one node, and each node is used to store file content, the length of the file content, and the starting position of the file content.

10. A communication device, characterized in that, The apparatus is applied to a network device, and the apparatus includes: A first acquisition unit, configured to acquire a first read response data packet sent by a server to a client, where the first read response data packet includes first file content and a first request sequence number; A second acquisition unit, configured to acquire a second request sequence number from a first node included in a first queue, where the first node is the head node of the first queue; A first determination unit, configured to determine whether the first request sequence number is the same as the second request sequence number; A service processing unit, configured to, if they are the same, perform DPI service processing on the first file content; A caching unit, configured to, if they are different, cache the first response data packet; The first acquisition unit is further configured to acquire a first read request data packet sent by the client to the server, where the first read request data packet includes the length of the first file content to be read by the client, the starting position of the first file content, and the second request sequence number; The caching unit is further configured to cache the second request sequence number at the first node; Wherein, the first queue includes at least one node, the request sequence number stored in the head node included in the first queue is the minimum value; and the length of the file content corresponding to the request sequence number and the starting position of the file content are further stored in each node.

Images