Method for processing packet by routing device, routing device, storage medium, and chip system

Abstract

The present application relates to the technical field of terminals, and provides a method for processing a packet by a routing device, a routing device, a storage medium, and a chip system. The method comprises: a routing device may perform URL reassembly on a plurality of segmented handshake packets in an HTTPS request, and parse for a URL requested to be accessed by an electronic device. The routing device may further block URLs that are not allowed to be accessed, thereby reducing attacks from insecure URLs on the electronic device and improving the security of the electronic device.

Description

Routing device packet processing methods, routing devices, storage media and chip systems

[0001] This application claims priority to Chinese Patent Application No. 202510048349.0, filed on January 10, 2025, entitled “Method for Processing Messages by Routing Device, Routing Device, Storage Medium and Chip System”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of terminal technology, and in particular to a method for processing messages in a routing device, a routing device, a storage medium, and a chip system. Background Technology

[0003] Electronic devices can connect to the internet through routing devices and access resources on servers. In some scenarios, applications on electronic devices may access insecure websites, which routing devices can block. Insecure websites can be understood as URLs that the routing device does not allow to be accessed.

[0004] However, in some implementations, routing devices may fail to block insecure URLs, reducing the security of electronic devices. Summary of the Invention

[0005] This application provides a method for processing packets in a routing device, a routing device, a storage medium, and a chip system. The routing device can reassemble the URLs of multiple segmented handshake packets in an HTTPS request and resolve the URL requested by the electronic device. The routing device can also block inaccessible URLs, thereby reducing attacks from insecure URLs on electronic devices and improving the security of the electronic devices.

[0006] The first aspect provides a method for a routing device to process packets, applied to a routing device, the method including:

[0007] The system receives N segmented packets from an electronic device and sends N segmented packets, where the routing device cannot parse the URL from the N segmented packets, and N is a positive integer greater than or equal to 1. It then receives the (N+1)th segmented packet from the electronic device and parses the URL from the (N+1)th segmented packet, where the N segmented packets and the (N+1)th segmented packet are from the same data stream. If the first information includes a URL, the routing device does not send the (N+1)th segmented packet. The first information includes one or more disallowed URLs. Thus, even if the previous segmented packets from the first to the Nth segmented packets are sent, the server will not receive the complete packet and therefore cannot parse the complete URL, preventing the electronic device from accessing insecure URLs.

[0008] In one possible implementation, the method further includes: re-acquiring the (N+1)th segment packet from the electronic device, but the routing device does not send the (N+1)th segment packet. In this way, the routing device can intercept subsequent packets related to this data stream, thereby intercepting the retransmitted segment packets and preventing the electronic device from accessing insecure websites.

[0009] In one possible implementation, the method further includes: if the first information includes a URL, adding an identifier to the data stream containing the (N+1)th segment packet. This identifier indicates that the data stream contains a URL that is not allowed. By adding this identifier, the router can not only identify that the URL is insecure, but also that the corresponding data stream is insecure. Thus, when a segment packet is retransmitted, the router can successfully intercept the retransmitted packet, preventing electronic devices from accessing insecure URLs.

[0010] In one possible implementation, the method further includes: acquiring the (N+1)th segment packet from the electronic device again, and, based on the identifier, the routing device not sending the (N+1)th segment packet. The routing device can determine, based on the identifier, that the data stream corresponding to the (N+1)th segment packet is an insecure data stream, which includes a URL that is not allowed to be accessed. Therefore, the routing device can choose not to send the (N+1)th segment packet, thereby achieving the interception of insecure packets by the routing device.

[0011] In one possible implementation, N segmented messages are acquired from an electronic device, and then N segmented messages are sent. This includes: acquiring the i-th segmented message from the electronic device; updating and saving the first anchor message, which is obtained based on the i-th segmented messages from the first segmented message to the i-th segmented message, where i is a positive integer less than or equal to N; and sending the i-th segmented message, where the routing device cannot parse the URL from the first anchor message. If the updated anchor message cannot parse the URL, since the routing device cannot determine whether the message sent by the electronic device contains an insecure URL, in order to avoid blocking network services, the routing device can back up the new anchor message and send the i-th segmented message.

[0012] In one possible implementation, the first anchor message is obtained by combining i segmented messages based on the sequence number and the next sequence number information. In this way, based on the sequence number and the next sequence number information, the routing device can append subsequent segmented messages to the copy of the first anchor message, thereby gradually obtaining the complete message and achieving message reassembly.

[0013] One possible implementation further includes deleting the second anchor packet if the first information includes a URL. The second anchor packet is obtained from N+1 segmented packets, from the first segmented packet to the (N+1)th segmented packet. This allows for the long-term processing of numerous segmented packets from different data streams within a limited memory space, effectively managing the routing device's space usage, promptly clearing unnecessary memory data from the router, and thus improving the router's operating efficiency.

[0014] In one possible implementation, the method further includes: if the number of matches for the second information is greater than or equal to a preset number of matches, then the first anchor message is deleted. The second information is used to indicate that N segmented messages and the (N+1)th segmented message are messages from the same data stream; or, if the time interval from obtaining the first segmented message from the electronic device to determining that the first information includes a URL is greater than or equal to a preset matching duration, then the first anchor message is deleted. This allows for the long-term processing of a large number of segmented messages from different data streams within a limited memory space, promptly clearing unnecessary memory data in the router. This saves router memory space and improves router operating efficiency.

[0015] In one possible implementation, the second information includes the five-tuple information of the data stream, the URL including a URL of type HTTPS (Hypertext Transfer Security Protocol), and N segmented messages representing the handshake messages of the Secure Sockets Layer (SSL) protocol. The routing device can reassemble the URLs of the multiple SSL handshake segments in an HTTPS request and parse the requested URL from the electronic device based on the five-tuple information. The routing device can also block inaccessible URLs, thereby reducing attacks from insecure URLs on electronic devices and improving their security.

[0016] The second aspect provides a routing device including one or more processors and a memory for storing one or more programs, and the one or more processors for invoking one or more programs to perform the methods described in the first aspect or any possible implementation thereof.

[0017] A third aspect provides a chip or chip system applied to a routing device, comprising one or more processors. The one or more processors are used to invoke instructions to execute the methods described in the first aspect or any possible implementation thereof. The communication interface in the chip can be an input / output interface, pins, or circuits, etc.

[0018] In one possible implementation, the chip or chip system described above in this application further includes at least one memory storing instructions. The memory can be an internal storage unit of the chip, such as a register or cache, or it can be a storage unit of the chip itself (e.g., read-only memory, random access memory, etc.).

[0019] The fourth aspect provides a readable storage medium (also referred to as a computer-readable storage medium) storing a program that, when run on a routing device, causes the routing device to perform the methods described in the first aspect or any possible implementation thereof.

[0020] The fifth aspect provides a program product (also referred to as a computer program product) comprising a program. When the program is run on a routing device, it causes the routing device to perform the methods described in the first aspect or any possible implementation thereof.

[0021] It should be understood that the second to fifth aspects of this application correspond to the technical solutions of the first aspect of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be repeated here. Attached Figure Description

[0022] Figure 1 is a schematic diagram of a routing device blocking insecure URLs according to an embodiment of this application;

[0023] Figure 2 is a schematic diagram of device interaction for a routing device to intercept an insecure URL according to an embodiment of this application;

[0024] Figure 3 is a schematic diagram of another routing device provided in an embodiment of this application blocking insecure URLs;

[0025] Figure 4 is a schematic diagram of another routing device intercepting insecure URLs provided in an embodiment of this application;

[0026] Figure 5 is a flowchart illustrating a method for a routing device to process packets according to an embodiment of this application;

[0027] Figure 6 is a schematic diagram of a router parsing a handshake message according to an embodiment of this application;

[0028] Figure 7 is a schematic diagram of a protocol retransmission mechanism provided in an embodiment of this application;

[0029] Figure 8 is a schematic diagram of a method for a routing device with a mark identifier to process packets according to an embodiment of this application;

[0030] Figure 9 is a schematic diagram of a packet processing method for a routing device provided in an embodiment of this application;

[0031] Figure 10 is a schematic diagram of the structure of a routing device provided in an embodiment of this application;

[0032] Figure 11 is a schematic diagram of a chip system provided in an embodiment of this application. Detailed Implementation

[0033] To facilitate a clear description of the technical solutions in the embodiments of this application, some terms and technologies involved in the embodiments of this application will be briefly introduced below:

[0034] 1. Terminology

[0035] In the embodiments of this application, terms such as "first" and "second" are used to distinguish identical or similar items with substantially the same function and purpose. For example, "first chip" and "second chip" are used only to distinguish different chips and do not limit their order of execution. Those skilled in the art will understand that terms such as "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply that they are different.

[0036] It should be noted that, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0037] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0038] Electronic devices can connect to the internet through routing devices and access resources on servers. In some scenarios, applications on electronic devices may access insecure websites, which routing devices can block. Insecure websites can be understood as URLs that the routing device does not allow to be accessed.

[0039] In some implementations, as shown in Figure 1, when applications in electronic devices, such as browsers, access servers through routing devices, the routing devices can perform Domain Name System (DNS) resolution on the URLs that the applications want to access and block insecure URLs.

[0040] For example, as shown in Figure 2, a user can enter an insecure domain name into the browser of an electronic device, assuming the insecure domain name is www.xxx.com. The browser can trigger the electronic device to initiate a DNS request to the server (referred to as the target server) through the routing device. Before the routing device forwards the DNS request, it can intercept the DNS request and resolve the domain name in the DNS request. If the routing device determines that the resolved domain name is an insecure domain name, it can intercept the insecure domain name and will not forward it to the target server.

[0041] However, in the above implementation process, the routing device may fail to intercept insecure domain names. When the browser does not receive a response to the DNS request for an extended period, such as when the browser fails to obtain the IP address corresponding to the insecure domain name after a preset time, the browser may encapsulate the insecure domain name into a Hypertext Transfer Protocol (HTTP) request or a Hypertext Transfer Protocol Secure (HTTPS) request, triggering the electronic device to access the proxy server through the routing device. The proxy server can be understood as an intermediary server that acts as a bridge between the electronic device and the target server.

[0042] After receiving an HTTP or HTTPS request, the proxy server can resolve the insecure domain name and initiate a DNS request to the server hosting the insecure domain name (referred to as the insecure server). The insecure server can return a DNS response to the proxy server, which may include the IP address corresponding to the insecure domain name. Furthermore, the proxy server can request content that is not allowed to be accessed from the insecure server based on the IP address, and the insecure server can return the insecure content to the proxy server. It is understandable that routing devices may have a pre-configured URL blacklist, which includes one or more URLs. The insecure content that is not allowed to be accessed can be understood as the insecure content on the server corresponding to those one or more URLs.

[0043] After obtaining prohibited content, the proxy server can return an HTTP or HTTPS response to the electronic device via a routing device. This response can include the prohibited content. The browser can then trigger the electronic device to display the prohibited content based on the HTTP or HTTPS response. For example, if the HTTP or HTTPS response includes prohibited Hypertext Markup Language (HTML) content, the electronic device can display that HTML content.

[0044] In other implementations, as shown in Figure 3, some routing devices can also intercept HTTP URLs.

[0045] For example, the routing device may not intercept DNS requests. This allows the browser to obtain the IP address returned by the insecure server, which the browser can then encapsulate in the HTTP request. When the browser triggers an HTTP request from an electronic device, because the HTTP request does not use Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocols to encrypt the data, the routing device can obtain the HTTP URL and intercept it. After identifying the HTTP URL as insecure, the routing device can redirect the HTTP request to a pre-configured resource on its local machine. This pre-configured resource can be used to inform the user that the website being accessed is not allowed, not recommended, or a risky website. However, in the implementation process shown in Figure 3, the routing device can only intercept HTTP requests with a high probability and cannot effectively intercept HTTPS requests.

[0046] In some implementations, as shown in Figure 4, some routing devices can also intercept HTTPS requests.

[0047] It is understandable that HTTPS requests can encrypt the data to be transmitted using either the SSL or TLS protocols. For ease of description, the following explanation uses the SSL protocol as an example; the implementation of the TLS protocol is similar to that of the SSL protocol and will not be repeated. It is also understandable that the SSL handshake phase is unencrypted; that is, during the SSL handshake phase, the electronic device and the server exchange data in plaintext. Therefore, the routing device can obtain the `server_name` field in the SSL handshake message, which can be used to indicate the hostname or server name. If the SSL handshake message is a complete message, or if the handshake message includes a complete HTTPS URL, the routing device can intercept the HTTPS URL to determine whether the HTTPS URL is insecure.

[0048] However, in some scenarios, the `server_name` field might be stored in the payload of the handshake message, which can then serve as the data carrier. When a single handshake message cannot carry all the SSL handshake information (also known as handshake data), the electronic device will segment the handshake message, dividing the SSL handshake information into multiple payloads, and sending them through multiple segmented handshake messages. In this case, the routing device obtains individual `sk_buff` structures, each of which can contain a payload, and each payload corresponds to a portion of the handshake information. Each `sk_buff` structure can be abbreviated as `skb`. That is, in this situation, the routing device cannot obtain all the SSL handshake information from a single `skb`, meaning it cannot obtain the complete URL from the segmented handshake message. Consequently, the routing device cannot identify insecure URLs, and its interception of insecure URLs fails.

[0049] In view of this, embodiments of this application provide a method for a routing device to process packets. The routing device can reassemble the URLs of multiple segmented handshake packets in an HTTPS request and parse out the URL requested by the electronic device. The routing device can also block URLs that are not allowed, thereby reducing attacks on electronic devices from insecure URLs and improving the security of electronic devices.

[0050] It is understood that the routing device in this application embodiment can be used to forward data packets in a network, such as forwarding data packets from one network interface to another, to ensure that data can be transmitted between electronic devices and network devices (such as servers). This routing device may include, but is not limited to, routers, gateway devices, optical modems, optical network terminals (ONTs), switches, bridges, repeaters, portable Wi-Fi devices, customer premises equipment (CPEs), firewalls, etc., and is not limited in this application embodiment. For ease of description, the routing device will be described using a router as an example thereafter.

[0051] A router can include a kernel forwarding plane and a kernel control plane. The kernel forwarding plane is responsible for packet lookup, forwarding, and processing. Based on the routing table generated by the kernel control plane, the kernel forwarding plane forwards incoming packets to the appropriate output interface. The kernel forwarding plane can also be simply referred to as the forwarding plane or data plane. The kernel control plane is responsible for network management and configuration, including route selection, network protocol operation, and routing table construction and maintenance. The kernel control plane can also be simply referred to as the control plane.

[0052] A router may include a Wi-Fi network interface card (NIC) and / or an Ethernet interface card (ENIC). The Wi-Fi NIC and / or ENIC can be used to forward data between a server and electronic devices. In this embodiment, the Wi-Fi NIC and / or ENIC can also be used to parse the server_name field in an SSL handshake message and the host field in an HTTP message. It is understood that the router can support electronic devices requesting URLs using either the IPv4 or IPv6 protocol, and can also receive escape characters. The connection between the router and the electronic device can be wired or wireless.

[0053] Electronic devices can be any form of device. For example, electronic devices may include: mobile phones, tablets, handheld computers, laptops, mobile internet devices (MIDs), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, devices in industrial control, devices in self-driving, devices in remote medical surgery, devices in smart grids, devices in transportation safety, devices in smart cities, devices in smart homes, cellular phones, cordless phones, session initiation protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), handheld devices, computing devices or other processing devices connected to a wireless modem, in-vehicle devices, devices in 5G networks, or devices in future evolved public land mobile networks (PLMNs), etc. The embodiments in this application are not limited to these.

[0054] In this embodiment of the application, the electronic device may include a Wi-Fi network card and / or an Ethernet card. The Wi-Fi network card and / or Ethernet card can be used to connect to a router for sending and receiving messages.

[0055] The methods of this application will be described in detail below through specific embodiments. The following embodiments can be combined with each other or implemented independently, and the same or similar concepts or processes may not be described again in some embodiments.

[0056] Figure 5 shows a flowchart illustrating the packet processing method of the routing device according to an embodiment of this application.

[0057] The packet processing method of the routing device in this application involves the interaction between an electronic device, a router, a DNS server, and a resource server. The electronic device includes an application that accesses websites, such as a browser. The DNS server may include a DNS response system that can respond to DNS requests initiated by the electronic device. The resource server may include a web server system that can respond to resource access requests initiated by the electronic device.

[0058] The packet processing method of the routing device may include the following steps S501 to S510. It is understood that the processes or steps in the embodiment corresponding to Figure 5 do not necessarily need to be executed in sequence. This application embodiment does not limit the execution order of steps S501 to S510, as long as the packet processing method of the routing device can be implemented.

[0059] S501, Electronic device request domain name.

[0060] In one possible scenario, a user might search for a domain name, such as www.xxx.com, in the browser of an electronic device. The browser can then encapsulate this domain name into a message and trigger the electronic device to send it to the server via a router.

[0061] S502, the router forwards the packets corresponding to the domain name.

[0062] After receiving the message corresponding to the domain name, the router can forward the message to the DNS server.

[0063] S503, the DNS server returns a response message to the router.

[0064] In a possible implementation, the DNS server can locally cache a mapping table of domain names and IP addresses. After receiving a message requesting a domain name, the DNS server can look up the corresponding URL from this mapping table, such as the IP address corresponding to www.xxx.com. The DNS server can then encapsulate the retrieved IP address into a response message and return it to the router.

[0065] S504. The router returns a response message to the electronic device.

[0066] After receiving a response message from a DNS server, the router can forward the response message to electronic devices. The browser on the electronic device can then receive the response message.

[0067] S505, Electronic devices send HTTP or HTTPS requests.

[0068] A browser on an electronic device can trigger the device to send HTTP or HTTPS requests based on the response message. For example, the browser can obtain the IP address corresponding to www.xxx.com from the response message and encapsulate it into an HTTP or HTTPS request. The browser can also trigger the electronic device to send HTTP or HTTPS requests.

[0069] S506, the router performs HTTP parsing or SSL handshake message parsing.

[0070] The process of a router parsing an SSL handshake message can include identifying the header anchor message, reassembling fragmented messages, and resolving the URL. The specific process of a router parsing an SSL handshake message can be referred to the relevant description in the embodiment corresponding to Figure 6 below, and will not be repeated here. After resolving the URL, the router can execute step S507.

[0071] Of course, the router can also perform HTTP resolution and execute step S507. It's understandable that, since HTTP messages are unencrypted, there is no handshake message. Therefore, the router can obtain the host identifier of the server domain name in the HTTP message without needing to parse the handshake message.

[0072] S507: The router matches the resolved URL with resource information.

[0073] Routers can match the resolved URL with resource information stored in the router to determine whether the resolved packet should be blocked. This resource information can be stored in the router's local memory and may include one or more insecure URLs.

[0074] In one possible implementation, the router could convert string matching into matching with a tree-like numerical structure of resource information, and combine this with collision string comparison to achieve the matching of URLs and resource information. This tree-like numerical structure can be understood as storing values ​​using hash buckets.

[0075] For example, for one or more insecure URLs, the router can store them in one or more hash buckets. A hash bucket is a basic unit in a hash table data structure and can be used to store elements in the hash table. Understandably, each hash bucket can have a corresponding hash identifier, and different hash buckets have different hash identifiers. Each hash bucket can store one or more insecure URLs, and the hash values ​​corresponding to the one or more insecure URLs stored in the same hash bucket are all the same. Optionally, the hash value corresponding to the one or more insecure URLs can be used as the hash identifier of the hash bucket containing the one or more insecure URLs.

[0076] For example, the first hash bucket stores A insecure URLs, each with a hash value of hashA. The hash identifier for the first hash bucket can be hashA. The second hash bucket stores B insecure URLs, each with a hash value of hashB. The hash identifier for the second hash bucket can be hashB. Furthermore, hashA and hashB are different, and A and B are both positive integers.

[0077] Once the router resolves the URL, it processes the URL using a hash function to obtain a hash value, and then matches this hash value against the hash identifiers of one or more hash buckets. If the URL's hash value matches the hash identifier of a hash bucket, to prevent hash collisions, the router can further compare the URL with one or more insecure URLs in that hash bucket. A hash collision can be understood as two different strings obtaining the same hash value after being processed by a hash function.

[0078] If the strings are the same, it means the parsed URL matches the URL in the resource information, indicating that the URL is insecure and can be blocked by the router. This improves URL matching latency and increases the router's data processing speed while maintaining a high success rate in blocking.

[0079] In another possible implementation, the router can use a method that converts string matching into matching with array values ​​of resource information to achieve the matching of URLs and resource information.

[0080] For example, for one or more insecure URLs, the router can store them in an array. Each element of this array can be used to store an instance of a data structure. Each instance of the data structure can include an insecure URL and its corresponding hash value. It is understood that instances of different data structures can have the same or different hash values.

[0081] For example, an instance of the first data structure can be an insecure URL C, and the hash value corresponding to URL C is hashC. An instance of the second data structure can be an insecure URL D, and the hash value corresponding to URL D is hashD. hashC and hashD can be the same or different.

[0082] After the router resolves the URL, it processes the URL using a hash function to obtain a hash value, and then matches this hash value with the hash values ​​corresponding to instances of data structures in the array. If the URL's hash value matches the hash value of an instance of a certain data structure, the router can further compare the URL with insecure URLs in that data structure's instances. If the strings match, it means the resolved URL successfully matches the URL in the resource information, indicating that the URL is insecure and the router can block it.

[0083] Optionally, the router can also sort the instances of each data structure in the array in ascending or descending order based on the size of the hash value corresponding to the instance of the data structure. It then employs a binary search algorithm to search for the hash value in the array based on the hash value of the URL. Understandably, sorting the array and using a binary search algorithm for URL matching can improve search efficiency and reduce the time and space complexity of the search, thereby improving URL matching latency and increasing the router's data processing speed while maintaining the interception success rate.

[0084] Of course, routers can also use other methods to match URLs with resource information, and this application embodiment does not limit this.

[0085] S508: The router forwards unmatched HTTP or HTTPS requests to the resource server.

[0086] If the resolved URL does not match the URL in the resource information, it means that the resolved URL is not an insecure URL and should not be blocked. In this case, the router can forward the HTTP or HTTPS request to the resource server.

[0087] If the resolved URL matches the URL in the resource information, it indicates that the resolved URL is insecure and should be blocked. Therefore, the router will not forward the HTTP or HTTPS request to the resource server. In this way, the router can reassemble the URL in the segmented handshake messages of HTTPS requests initiated by electronic devices and resolve the URL domain name, thus effectively blocking access to insecure URLs.

[0088] S509. The resource server returns a response message for an HTTP request or an HTTPS request to the router.

[0089] S510: The router returns response messages for HTTP requests or HTTPS requests to electronic devices.

[0090] After receiving an HTTP or HTTPS request, the resource server can query the requested content based on the IP address in the request, encapsulate the retrieved content into a response message, and return it to the browser of the electronic device through the router. The browser can then trigger the electronic device to display the content in the response message.

[0091] Figure 6 shows a schematic diagram of a router parsing a handshake message according to an embodiment of this application.

[0092] It is understood that the implementation process of the embodiment corresponding to Figure 6 may include the implementation process of steps S506 and S507 of the embodiment corresponding to Figure 5, such as the process of the router parsing the SSL protocol handshake message. The various processes or steps in the embodiment corresponding to Figure 6 do not necessarily need to be executed sequentially. This application embodiment does not limit the execution order of steps S601 to S604, as long as the method for the routing device to process messages can be implemented. In a possible implementation, the embodiment corresponding to Figure 6 may be executed by the kernel forwarding plane of the router. For ease of description, the following explanation uses the kernel forwarding plane parsing the handshake message as an example.

[0093] S601, the router's kernel forwarding plane introduces the forwarded packets into the parsing logic of the IP_FORWARD node.

[0094] The kernel forwarding plane can introduce forwarded packets into the parsing logic of the IP_FORWARD node. The IP_FORWARD node can then be used to control packet forwarding.

[0095] For example, in the resolution logic of the IP_FORWARD node, the kernel forwarding plane can obtain connection traces corresponding to each skb from the IP_FORWARD node. It is understandable that during network data transmission using protocols such as Transmission Control Protocol (TCP) or User Datagram Protocol (UDP), an end-to-end data flow can be established between electronic devices and servers. The protocol internally stores a connection trace table corresponding to the data flow. The connection trace table records information such as five-tuples and aging times, used to manage the state of network connections. In the connection trace table, one data flow can correspond to one connection trace. Electronic devices and servers can transmit one or more packets based on the connection trace.

[0096] The kernel forwarding plane can obtain the 5-tuple information from the connection trace corresponding to the packet. The 5-tuple information can be understood as a set of five key fields used to uniquely identify a data stream. These key fields, combined, can be used to distinguish different data streams. This set can include: source IP address, destination IP address, source port number, destination port number, and protocol type. Specifically, the source IP address indicates the IP address of the packet sender; the destination IP address indicates the IP address of the packet receiver; the source port number indicates the port number used by the sender; the destination port number indicates the port number used by the receiver; and the protocol type indicates the protocol type used by the transport layer, such as TCP or UDP.

[0097] The kernel forwarding plane can filter packets destined for port 443 using the destination port information in the 5-tuple. It's understandable that packets destined for port 443 are HTTPS packets. Filtering packets on port 443 can be understood as filtering HTTPS packets. For HTTP packets, the corresponding port can be 80 or 8080.

[0098] S602, the router's kernel forwarding plane manages the segmented handshake messages of the SSL protocol based on data flow.

[0099] For example, the kernel forwarding plane can identify the first anchor segment of an SSL handshake message. This first anchor segment can be understood as the beginning of the handshake message. The first anchor segment may include, but is not limited to, one or more of the following: message content type, SSL protocol version, length of subsequent data, etc. The message content type may include handshake messages, alert messages, application data messages, etc.

[0100] Understandably, HTTPS messages can include packet headers, such as MAC headers, IP headers, and TCP headers, as well as a data body (payload). The data body can include information such as the format and data of the handshake message. The kernel forwarding plane can first determine whether the parsed content type of the segmented message is a handshake message. If the parsed content type of the segmented message is the identifier for a handshake message, the kernel forwarding plane can further determine whether the handshake message type is Client Hello. This Client Hello message is a message sent by the browser to the server to indicate the start of the handshake process. If the handshake message type is Client Hello, the kernel forwarding plane can determine that this segmented message is the first anchor segment, also known as the first segmented message. For example, if the kernel forwarding plane determines that the content type of the segmented message is the identifier for a handshake message (Handshake), and the handshake message type is Client Hello, then this segmented message is the first anchor segment, i.e., the first segmented message.

[0101] The kernel forwarding plane can also back up the first anchor segment. For example, the kernel forwarding plane can cache a backup of the first anchor segment in the data management (DM) flow table to facilitate the reassembly of subsequent segmented packets. This backup of the first anchor segment can also be referred to as a copy of the first anchor segment. The DM flow table can record information such as the 5-tuple information of the first anchor segment, the number of matches, and the buffer for the data backup.

[0102] The kernel forwarding plane can also allow the backup of the first anchor segment packet, meaning it sends the backup of the first anchor segment packet out. Understandably, since the kernel forwarding plane hasn't yet obtained the complete URL when acquiring the first anchor segment packet, it cannot determine whether the current packet contains an insecure URL. To avoid blocking network traffic, the kernel forwarding plane can allow the first anchor segment packet to pass after backup.

[0103] S603: The router's kernel forwarding process handles segmented SSL protocol packets following the same data stream.

[0104] The kernel forwarding plane can identify subsequent segments of the same data stream based on information such as the 5-tuple, sequence number (seq), and next sequence number (nseq). Subsequent segments can also be understood as subsequent data packets within the same data stream. It's understood that the 5-tuple information of the same packet is identical; that is, the 5-tuple information of all segments of the same packet is the same. Therefore, it's possible to determine whether they belong to the same packet, i.e., the same data stream, based on the 5-tuple information.

[0105] Sequence numbers are used to track the order of data packets, enabling data to be reassembled in the correct sequence. Sequence number and next sequence number information can also be abbreviated as seq & nseq information. Here, seq represents the sequence number of the current data packet, and nseq represents the sequence number of the next expected data packet.

[0106] The kernel forwarding plane can also reassemble subsequent segmented packets with the copy of the first anchor packet in the DM flow table to resolve the URL of the server_name field.

[0107] For example, the kernel forwarding plane can parse the 5-tuple information of a segmented packet conforming to port 443 and determine whether the 5-tuple information of the segmented packet is the same as the 5-tuple information of the cached copy of the first anchor packet. If the 5-tuple information of the segmented packet is the same as the 5-tuple information of the copy of the first anchor packet, the kernel forwarding plane can determine that the segmented packet is a subsequent segmented packet of the first anchor packet.

[0108] To ensure that fragmented packets can be reassembled in the correct order, the kernel forwarding plane can obtain the seq and nseq information of each fragmented packet. For fragmented packets with identical parsed 5-tuple information and matching sequence numbers, the kernel forwarding plane can append to the copy of the first anchor packet, gradually obtaining the complete packet, thereby achieving packet reassembly. It can be understood that if the fragmented handshake packet consists of N segments, the kernel forwarding plane can reassemble these N segments until the URL corresponding to the server_name field is parsed.

[0109] For example, if the URL cannot be resolved from the first anchor packet, the kernel forwarding plane can back up the first anchor packet in the DM flow table and allow the first anchor packet to pass. In other words, the kernel forwarding plane can save a copy of the first anchor packet and send it out.

[0110] After the kernel forwarding plane identifies the second segment of the handshake message based on the 5-tuple information and seq & nseq information, it can append a copy of the second segment to the copy of the first anchor segment (i.e., the first segment), and then reassemble the first anchor segment copy and the second segment copy into a new anchor segment. At this point, it can be understood that the first anchor segment has a match count of 1. If the new anchor segment cannot resolve to a URL, the kernel forwarding plane can back up the new anchor segment and send out the second segment.

[0111] Similarly, after the kernel forwarding plane identifies the third segment of the handshake message based on the 5-tuple information and seq & nseq information, it can append a copy of the third segment to the anchor message (i.e., the anchor message reassembled from the copies of the first and second segments), and then reassemble the anchor message and the copy of the third segment into a new anchor message. In this case, the matching count of the first anchor segment can be understood as 2. If the new anchor message cannot resolve to a URL, the kernel forwarding plane can back up the new anchor message and send out the third segment.

[0112] Similarly, the kernel forwarding plane can reassemble the fourth segment, ..., the Nth segment, until the URL corresponding to the server_name field is parsed, or until the preset number of matches or the preset match duration is exceeded. If the anchor packet and the copy of the Nth segment can be reassembled into a new anchor packet, then the matching count of the first anchor packet can be understood as N-1.

[0113] Understandably, after resolving the URL corresponding to the server_name field, the kernel forwarding plane can match the resolved URL with the URL in the resource information to determine whether the resolved URL is an insecure URL, i.e., whether it should be blocked.

[0114] If the resolved URL does not match the URL in the resource information, it means the resolved URL is not an insecure URL, and the kernel forwarding plane can choose not to intercept it. Alternatively, if the resolved URL is not insecure, the kernel forwarding plane can send out the last identified segmented packet, ensuring the server receives a complete packet. For example, if the kernel forwarding plane reassembles the Nth segmented packet, resolves the URL corresponding to the `server_name` field, and determines that the URL is not insecure, then the kernel forwarding plane can send out the Nth segmented packet. In this way, the server can receive the complete packet, resolve the complete URL, and allow electronic devices to access that URL.

[0115] If the resolved URL matches the URL in the resource information, it indicates that the resolved URL is an insecure URL, and the kernel forwarding plane can intercept it. In other words, if the resolved URL is insecure, the kernel forwarding plane will not send the last identified segmented packet, resulting in the server receiving an incomplete packet. For example, if the kernel forwarding plane reassembles the Nth segmented packet copy, resolves the URL corresponding to the `server_name` field, and determines that the URL is insecure, the kernel forwarding plane will not send the Nth segmented packet. Thus, even if the first to N-1th segments are sent, the server will not receive the complete packet, making it impossible to resolve the complete URL and preventing electronic devices from accessing insecure URLs.

[0116] Optionally, in this embodiment of the application, the router can reassemble, parse, match, intercept, or forward the segmented packets at the network layer of the protocol.

[0117] S604, the router's kernel forwarding face performs memory management of the DM flow table.

[0118] Optionally, if the URL corresponding to the server_name field is resolved, the kernel forwarding plane can release the first anchor packet copy and subsequent segment packet copies in the DM flow table.

[0119] Optionally, when the number of matches for the five-tuple information in the first anchor segment exceeds the preset number of matches, it can also be understood that the number of matches for the first anchor segment exceeds the preset number of matches, indicating that the probability of reassembling the packet based on the first anchor segment is low. To save memory space, the kernel forwarding plane can release anchor segments in the DM flow table. The preset number of matches can be pre-set by the router and can be determined based on experimental testing or empirical values. The specific value of the preset number of matches is not limited in this embodiment.

[0120] Optionally, when the matching time of the first anchor packet exceeds a preset matching time, the kernel forwarding plane can release the anchor packet in the DM flow table. The preset matching time can be pre-set by the router and can be determined based on experimental testing or empirical values; for example, it can be set to 2 seconds or a value close to 2 seconds. The specific value of the preset matching time is not limited in this embodiment.

[0121] Of course, the kernel forwarding plane can also periodically release the first anchor packet copy and subsequent segment packet copies that meet the above conditions in the DM flow table; this application embodiment does not limit this. The memory release process can also be understood as an aging process, or a process of destroying unnecessary or no longer valid data. In this way, a large number of segmented packets from different data streams can be processed for a long time in a limited memory space, effectively managing the space occupation of the DM flow table and promptly cleaning up unnecessary memory data in the router. This saves router memory space and improves router operating efficiency.

[0122] It is understandable that even for protocols with retransmission mechanisms, there may still be situations where routers cannot block insecure URLs.

[0123] As shown in Figure 7, an electronic device can send SSL handshake packets to a router. However, when the length of the SSL handshake information generated by the electronic device exceeds the maximum segment size (MSS), the electronic device can send data to the router using segmented packets. For example, a segmented packet includes a first segmented packet and a second segmented packet. The first segmented packet includes a MAC header, IP header, TCP header, and a first part of the data body, while the second segmented packet includes a MAC header, IP header, TCP header, and a second part of the data body. In some implementations, the maximum segment size can be set to 1438 bytes; this embodiment does not limit this.

[0124] When a router receives the first segmented message, it can use it as the first anchor segment. After backing up the first anchor segment, the router can allow it to pass. When the router receives and identifies the second segmented message, it can reassemble the copy of the first anchor segment and the copy of the second segmented message. If the URL resolved after reassembly is an insecure URL, the router can intercept the second segmented message and not send it out.

[0125] However, protocols such as SSL and TCP have retransmission mechanisms, including congestion control, packet loss retransmission, and timeout retransmission. Taking the timeout retransmission mechanism as an example, when an electronic device detects that a preset time has elapsed since it sent a second segmented message, and has not yet received a response message for that second segmented message, the electronic device can retransmit the second segmented message.

[0126] Since the router has already reassembled the first anchor packet copy and the second segment copy, and the URL resolution was successful, it will delete the anchor packet generated based on the first anchor packet copy and the second segment copy from the DM flow table to save memory space. In this case, for the second segment packet retransmitted by the electronic device, since there is no anchor packet in the router's DM flow table to match it, the router will send the second segment packet out. The server can then receive all the segment packets, reassemble the complete URL, and cause the router to fail to intercept the insecure URL.

[0127] Regarding the situation in Figure 7, this embodiment of the application can add a mark identifier to the connection tracking of the data stream corresponding to the URL after reassembling the segmented message and parsing out the insecure URL. This mark identifier indicates that the data stream corresponding to the URL is an insecure data stream. The router can then intercept subsequent messages related to this data stream based on the mark identifier, thereby achieving the interception of retransmitted segmented messages.

[0128] For example, as shown in Figure 8, the network layer of the protocol may include an IP_FORWARD node. The IP_FORWARD node can be used to control packet forwarding, for example, allowing the router to process packets that need to be forwarded before they are forwarded. In a possible implementation, the router's kernel forwarding plane can introduce forwarding messages into the parsing logic of the IP_FORWARD node.

[0129] In the resolution logic of the IP_FORWARD node, when the router receives a fragmented packet, the router's kernel forwarding plane can obtain the 5-tuple information from the connection trace. On one hand, this 5-tuple information can be used to filter out packets destined for port 443 (i.e., HTTPS packets). On the other hand, this 5-tuple information can be used to look up the connection trace corresponding to the 5-tuple information in the connection trace table and determine whether the connection trace includes the mark identifier.

[0130] If the connection tracking includes a mark identifier, it means that the data stream containing the segmented packet has been identified as containing an insecure URL, and the segmented packet needs to be discarded. The router can then intercept the segmented packet.

[0131] If the connection tracking does not include the mark identifier, it means that the data stream containing the segmented packet has not been identified as a data stream containing an insecure URL, and the kernel forwarding plane can further process the segmented packet.

[0132] If the kernel forwarding plane recognizes that the segmented packet includes a Client Hello identifier, it indicates that the segmented packet is the first anchor segment packet, i.e., the first segmented packet. The kernel forwarding plane can then cache a copy of the first anchor segment packet in the DM flow table and send the first anchor segment packet. For the specific method of identifying the first anchor segment packet, please refer to the relevant description in step S602 of the corresponding embodiment in Figure 6, which will not be repeated here.

[0133] If the kernel forwarding plane does not recognize the Client Hello identifier, it can match the segmented packet with the copy of the first anchor packet (i.e., the copy of the first segmented packet) in the DM flow table. If subsequent segmented packets of the first anchor packet are identified based on the 5-tuple information and seq & nseq information, the kernel forwarding plane can cache copies of these subsequent segmented packets in the DM flow table and reassemble them with the copy of the first anchor packet. For the specific method of identifying subsequent segmented packets, please refer to the relevant description in step S603 of the corresponding embodiment in Figure 6, which will not be repeated here.

[0134] For subsequent fragmented packets, if the URL resolved after reassembly is an insecure URL, the router can intercept the subsequent fragmented packet and add a mark to the connection tracking table. Understandably, through the mark, the router can not only identify that the URL is insecure, but also that the corresponding data stream is insecure. Thus, when the fragmented packet is retransmitted, the router can successfully intercept the retransmitted fragmented packet, preventing electronic devices from accessing insecure URLs.

[0135] On the other hand, routers can promptly clean up information such as the first anchor packet copy and subsequent segment packet copies in the DM flow table. Understandably, timely cleaning of the DM flow table allows for the processing of a large number of segmented packets from different data streams within a limited memory space, effectively managing the DM flow table's space usage, thereby saving router memory and improving router operating efficiency.

[0136] For example, taking an electronic device sending a handshake message in three segments, with the `server_name` field in the third segment, a possible implementation would be to use a packet capture tool like Wireshark to obtain information about these three segments. Alternatively, the segmented messages sent by the router can be obtained through WAN-side packet capture. This WAN-side packet capture method could include using switch mirroring to capture the segmented messages sent by the router. Since the `server_name` field is in the third segment, when the router receives the third segment, it can parse the URL. If the parsed URL is determined to be insecure, the router can intercept the third segment, i.e., not send it. Thus, if the segmented messages sent by the router obtained through switch mirroring do not include the third segment, it can be assumed that the router has intercepted the insecure URL.

[0137] The router can also add a mark to the data stream containing the third segmented packet. When the electronic device triggers the retransmission mechanism, it can retransmit the third segmented packet. Wireshark packet capture tools can then be used to obtain information about the multiple times the electronic device has sent the third segmented packet. Since the router can prevent the retransmission of the third segmented packet based on the mark, it can still successfully intercept the retransmitted third segmented packet. Therefore, even if the electronic device retransmits the third segmented packet, the segmented packets sent by the router obtained through switch mirroring packet capture will still not include the third segmented packet. Through the above method, it can be verified that the packet processing method of the routing device in this embodiment can successfully intercept insecure URLs. This reduces attacks from insecure URLs on electronic devices and improves the security of electronic devices.

[0138] Figure 9 illustrates a packet processing method for a routing device according to an embodiment of this application. Applied to a routing device, the method includes:

[0139] S901. The routing device receives N segmented packets from the electronic device and sends N segmented packets. The routing device cannot parse the URL from the N segmented packets, where N is a positive integer greater than or equal to 1.

[0140] In this embodiment, the N segmented messages may include the N segmented handshake messages of the SSL protocol mentioned above. Taking the N segmented handshake messages as an example, the routing device can obtain these N segmented handshake messages based on N sk_buff structures. Each of these N segmented handshake messages contains only a portion of the handshake information; the routing device cannot obtain all the SSL protocol handshake information from a single message. In this case, the routing device needs to reassemble the segmented handshake messages to resolve the complete URL. Here, the N segmented messages can also be referred to as N segmented messages.

[0141] The specific routing device's identification, reassembly, and parsing of segmented packets can be referred to the relevant descriptions of steps S602 and S603 in the corresponding embodiment of Figure 6, which will not be repeated here. It is understood that if the routing device cannot parse a URL from N segmented packets, and cannot determine whether the packets sent by the electronic device contain insecure URLs, the routing device may send out the N segmented packets to avoid blocking network services.

[0142] S902. The routing device obtains the N+1th segment message from the electronic device and parses the URL from the N+1th segment message. The Nth segment message and the N+1th segment message are messages from the same data stream.

[0143] S903. If the first information includes a URL, the routing device does not send the N+1th segment message. The first information includes one or more URLs that are not allowed to be accessed.

[0144] The first piece of information can be understood as the resource information in the router mentioned above. This resource information can be information in the local memory of the routing device, and it may include one or more insecure URLs.

[0145] The specific process by which the routing device resolves the URL from the N+1 segmented packets can be referred to in the relevant description of subsequent segmented packet processing in step S603 of the corresponding embodiment in Figure 6, and will not be repeated here.

[0146] When the routing device parses the URL from N+1 segmented packets, it can match the parsed URL with the URL in the first information to determine whether the parsed URL is an insecure URL, i.e., whether it should be blocked. The specific process of the routing device matching the parsed URL with the URL in the first information can be referred to the relevant description in step S507 of the corresponding embodiment in Figure 5, and the relevant description in step S603 of the corresponding embodiment in Figure 6, and will not be repeated here.

[0147] It's understandable that if the first piece of information includes a URL, it indicates that the resolved URL is insecure, and the routing device can block it. Alternatively, if the resolved URL is insecure, the routing device won't send the last identified segmented packet, resulting in the server receiving an incomplete packet. Thus, even if the first to Nth segmented packets are sent, the server won't receive the complete packet, making it unable to resolve the complete URL and preventing electronic devices from accessing insecure URLs.

[0148] Optionally, based on the embodiment corresponding to Figure 9, the method may further include: obtaining the N+1th segment message from the electronic device again, and the routing device not sending the N+1th segment message.

[0149] Understandably, some network protocols have retransmission mechanisms. When an electronic device detects that a preset time has elapsed since sending the (N+1)th segment, and the device has not received a response message for that segment, it can retransmit the second segment. The routing device can then retrieve the (N+1)th segment from the electronic device again.

[0150] In this embodiment, for the (N+1)th segment packet acquired again from the electronic device, the routing device may still not send the (N+1)th segment packet. For example, after resolving an insecure URL, the routing device can add a mark to the connection tracking of the data stream corresponding to that URL to indicate that the data stream corresponding to that URL is an insecure data stream. The specific interception of retransmitted segment packets by the routing device can be referred to the relevant description in the corresponding embodiment of Figure 8, and will not be repeated here. In this way, the routing device can intercept subsequent packets related to that data stream, thereby intercepting the retransmitted segment packets and preventing the electronic device from accessing the insecure URL.

[0151] Optionally, based on the embodiment corresponding to Figure 9, the method may further include: if the first information includes a URL, adding an identifier to the data stream where the N+1th segment message is located, the identifier being used to indicate that the data stream includes a URL that is not allowed to be accessed.

[0152] In this embodiment, the identifier can be understood as the mark identifier mentioned above. This mark identifier can be used to indicate that the data stream includes a URL that is not allowed to be accessed, or it can be understood as the data stream corresponding to that URL being an insecure data stream. Specifically, the process of adding the identifier to the data stream containing the (N+1)th segment packet can be referred to the relevant description in the corresponding embodiment of Figure 8, and will not be repeated here.

[0153] Understandably, by adding identifiers, routers can not only identify insecure URLs but also the corresponding data streams. This allows routers to successfully intercept retransmitted segments, preventing electronic devices from accessing insecure URLs.

[0154] Optionally, based on the embodiment corresponding to Figure 9, the method may further include: obtaining the N+1th segment message from the electronic device again, and based on the identifier, the routing device does not send the N+1th segment message.

[0155] When the routing device receives the (N+1)th segment packet from the electronic device, it can determine, based on the identifier, that the data stream corresponding to the (N+1)th segment packet is an insecure data stream, containing a URL that is not allowed. Therefore, the routing device can choose not to send the (N+1)th segment packet, thus intercepting insecure packets.

[0156] Optionally, based on the embodiment corresponding to Figure 9, obtaining N segmented messages from the electronic device and sending N segmented messages may include: obtaining the i-th segmented message from the electronic device; updating and saving the first anchor message, which is obtained based on the i-th segmented messages from the first segmented message to the i-th segmented message, where i is a positive integer less than or equal to N; and sending the i-th segmented message, wherein the routing device cannot parse the URL from the first anchor message.

[0157] The first anchor message can be understood as the anchor message generated by the routing device during the acquisition of N segmented messages. This first anchor message can be continuously updated as segmented messages are received.

[0158] For example, when the routing device receives the first segmented packet, it can identify a copy of the first segmented packet as the first anchor segment. When the routing device receives the second segmented packet, it can reassemble the copy of the first anchor segment and the copy of the second segmented packet into a new anchor segment. When the routing device receives the third segmented packet, it can reassemble the previously updated anchor segment and the copy of the third segmented packet into a new anchor segment, thereby achieving continuous updating of the anchor segment. The specific updating and saving of the anchor segment can be found in the relevant description of step S603 in the corresponding embodiment of Figure 6, and will not be repeated here.

[0159] Understandably, if the updated anchor message cannot resolve to a URL, the routing device cannot determine whether the message sent by the electronic device contains an insecure URL. To avoid blocking network services, the routing device can back up the new anchor message and send out the i-th segment message.

[0160] Optionally, based on the embodiment corresponding to Figure 9, the first anchor message is obtained by combining i segmented messages based on the sequence number and the next sequence number information.

[0161] The sequence number and next sequence number information (seq & nseq information) can be used to track the order of segmented messages, enabling the segmented messages to be reassembled in the correct order to obtain the first anchor message. For details regarding the sequence number and next sequence number information, and the implementation of obtaining the first anchor message based on the sequence number and next sequence number information, please refer to the relevant description in step S603 of the corresponding embodiment in Figure 6, which will not be repeated here.

[0162] In this way, based on the sequence number and the next sequence number information, the routing device can append subsequent segmented messages to the copy of the first anchor message, thereby gradually obtaining a complete message and realizing message reassembly.

[0163] Optionally, based on the embodiment corresponding to Figure 9, the method may further include: deleting the second anchor message when the first information includes a URL, wherein the second anchor message is obtained based on N+1 segmented messages from the first segmented message to the N+1th segmented message.

[0164] The second anchor message can be understood as the anchor message generated by the routing device when obtaining the (N+1)th segment message, based on the first anchor message and the (N+1)th segment message. The routing device can parse the URL from the second anchor message.

[0165] In this embodiment, the second anchor packet can be released once the routing device resolves the URL. This allows for the long-term processing of numerous segmented packets from different data streams within a limited memory space, effectively managing the routing device's space usage, promptly clearing unnecessary memory data from the router, and thus improving the router's operating efficiency.

[0166] Optionally, based on the embodiment corresponding to Figure 9, the method may further include: if the number of matches of the second information is greater than or equal to a preset number of matches, then delete the first anchor message, wherein the second information is used to indicate that the N segmented messages and the N+1th segmented message are messages in the same data stream; or, if the time interval from obtaining the first segmented message from the electronic device to determining that the first information includes a URL is greater than or equal to a preset matching duration, then delete the first anchor message.

[0167] The second piece of information can be understood as the five-tuple information mentioned above. The five-tuple information can be used to uniquely identify a data stream. Based on the five-tuple information, it can be determined that N segmented packets and the (N+1)th segmented packet belong to the same data stream. Since the routing device starts matching from the first segmented packet, the number of times the second piece of information is matched can be understood as the number of times the five-tuple information of the first segmented packet (the first anchor packet) is matched.

[0168] In this embodiment, when the number of matches for the five-tuple information of the first anchor segment exceeds a preset number of matches, it indicates that the probability of reassembling the packet based on the first anchor segment is low. To save memory space, the routing device can delete the first anchor segment.

[0169] The time interval from receiving the first segmented message from the electronic device to determining that the first information includes a URL can also be understood as the matching duration of the first anchor message. When the matching duration exceeds the preset matching duration, the routing device can delete the first anchor message.

[0170] The preset number of matches and preset match duration can be found in the relevant description of step S604 in the corresponding embodiment of Figure 6, and will not be repeated here. This allows for the long-term processing of a large number of segmented packets from different data streams within a limited memory space, promptly clearing unnecessary memory data in the router. This saves router memory space and improves router operating efficiency.

[0171] Optionally, based on the embodiment corresponding to Figure 9, the second information includes the five-tuple information of the data stream, the URL includes a URL of type HTTPS (Hypertext Transfer Security Protocol), and the N segmented messages are handshake messages of the Secure Sockets Layer (SSL) protocol.

[0172] The routing device processing method provided in this application embodiment can reassemble the URLs of multiple SSL protocol segmented handshake messages in an HTTPS request and parse the URL requested by the electronic device based on 5-tuple information. The routing device can also block inaccessible URLs, thereby reducing attacks from insecure URLs on electronic devices and improving the security of the electronic devices.

[0173] The above detailed embodiments have provided a comprehensive description of the purpose, technical solutions, and beneficial effects of the embodiments of this application. It should be understood that the above are merely specific implementation methods of the embodiments of this application and are not intended to limit the scope of protection of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solutions of the embodiments of this application should be included within the scope of protection of the embodiments of this application.

[0174] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0175] The foregoing mainly describes the technical solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, it includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that the method steps described in conjunction with the embodiments of this application can be implemented in hardware or a combination of hardware and software. Whether a function is executed in a hardware-driven or software-driven manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0176] This application provides a routing device. Figure 10 shows a schematic diagram of the routing device provided in this application. The routing device 1000 may include one or more processors 1001 and a memory 1002. The memory 1002 may be used to store one or more programs. The one or more processors 1001 may call one or more programs to cause the routing device 1000 to execute the technical solutions described in the above embodiments.

[0177] This application provides a chip system. This chip system is applied to a routing device and may include one or more processors. The one or more processors can be used to call a program to cause the routing device to execute the technical solutions described in the above embodiments.

[0178] Figure 11 is a schematic diagram of a chip system provided in an embodiment of this application. The chip system 1100 includes one or more processors 1101, communication lines 1102, communication interfaces 1103, and memory 1104.

[0179] In some implementations, memory 1104 stores elements such as executable modules or data structures, or subsets thereof, or extended sets thereof.

[0180] The methods described in the embodiments of this application can be applied to, or implemented by, processor 1101. Processor 1101 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above methods can be completed by integrated logic circuits in the hardware of processor 1101 or by instructions in software form. Processor 1101 may be a general-purpose processor (e.g., a microprocessor or conventional processor), a DSP, an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (OPG) or other programmable logic devices, discrete gates, transistor logic devices, or discrete hardware components. Processor 1101 can implement or execute the processing-related methods, steps, and logic block diagrams in the embodiments of this application.

[0181] The method described in this application embodiment can be executed by a hardware decoding processor, or by a combination of hardware and software modules within the decoding processor. The software modules can be located in the memory 1104, and the processor 1101 can read information from the memory 1104 and, in conjunction with its hardware, complete the steps of the above method. The processor 1101, the memory 1104, and the communication interface 1103 can communicate via the communication line 1102.

[0182] This application also provides a readable storage medium (also referred to as a computer-readable storage medium). The readable storage medium includes a program. When the program runs on the routing device, it causes the routing device to perform the technical solutions described in the above embodiments.

[0183] The methods described in the above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. If implemented in software, the functionality can be stored or transmitted on a readable medium as one or more instructions or programs. The readable medium can include storage media and communication media, and can also include any medium that can transfer a program from one place to another. The storage medium can be any accessible target medium.

[0184] In possible implementations, the readable medium may include random access memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, optical disc read-only memory, or other optical disc storage. The readable medium may also include disk storage or other disk storage devices, or be directed to any other medium or store the required program in the form of instructions or data structures, and be accessible.

[0185] This application also provides a program product (also referred to as a computer program product). The program product includes a program. When the program runs on a routing device, it causes the routing device to execute the technical solutions described in the above embodiments.

[0186] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions between the various embodiments are consistent and can be referenced by each other. Technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0187] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for processing packets using a routing device, characterized in that, Applied to routing devices, the method includes: Obtain N segmented packets from an electronic device and send the N segmented packets, wherein the routing device cannot parse the URL from the N segmented packets, and N is a positive integer greater than or equal to 1; Obtain the (N+1)th segment message from the electronic device, and parse the URL from the (N+1)th segment message, wherein the Nth segment message and the (N+1)th segment message are messages from the same data stream; If the first information includes the URL, the routing device does not send the (N+1)th segment message, where the first information includes one or more URLs that are not allowed to be accessed.

2. The method as described in claim 1, characterized in that, The method further includes: The routing device acquires the (N+1)th segment message from the electronic device again, but does not send the (N+1)th segment message.

3. The method as described in claim 1 or 2, characterized in that, The method further includes: If the URL is included in the first information, an identifier is added to the data stream containing the (N+1)th segment message. The identifier is used to indicate that the data stream contains a URL that is not allowed to be accessed.

4. The method as described in claim 3, characterized in that, The method further includes: The routing device acquires the (N+1)th segment message from the electronic device again, and based on the identifier, does not send the (N+1)th segment message.

5. The method according to any one of claims 1-4, characterized in that, The step of acquiring N segmented messages from the electronic device and sending the N segmented messages includes: Obtain the i-th segment message from the electronic device; Update and save the first anchor message, which is obtained based on the i segmented messages from the first segmented message to the i-th segmented message, where i is a positive integer less than or equal to N; Send the i-th segment message, wherein the routing device cannot parse the URL from the first anchor message.

6. The method as described in claim 5, characterized in that, The first anchor message is obtained by combining the i segmented messages based on the sequence number and the next sequence number information.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: If the URL is included in the first information, the second anchor message is deleted, wherein the second anchor message is obtained based on the N+1 segment messages from the first segment message to the N+1th segment message.

8. The method according to any one of claims 1-7, characterized in that, The method further includes: If the number of matches of the second information is greater than or equal to the preset number of matches, then the first anchor message is deleted. The second information is used to indicate that the N segmented messages and the N+1th segmented message are messages in the same data stream. Alternatively, if the time interval from obtaining the first segmented message from the electronic device to determining that the first information includes the URL is greater than or equal to a preset matching time, then the first anchor message is deleted.

9. The method as described in claim 8, characterized in that, The second information includes the five-tuple information of the data stream, the URL includes a URL of type HTTPS (Hypertext Transfer Security Protocol), and the N segmented messages are handshake messages of the Secure Sockets Layer (SSL) protocol.

10. A routing device, characterized in that, The routing device includes: one or more processors and memory; The memory is used to store one or more programs, which are invoked by the one or more processors to cause the routing device to perform the method as described in any one of claims 1-9.

11. A chip system, characterized in that, The chip system is applied to a routing device, the chip system including one or more processors, the one or more processors being configured to invoke instructions to cause the routing device to perform the method as described in any one of claims 1-9.

12. A readable storage medium, characterized in that, The readable storage medium includes a program that, when run on a routing device, causes the routing device to perform the method as described in any one of claims 1-9.

13. A program product, characterized in that, The program product includes a program that, when run on a routing device, causes the routing device to perform the method as described in any one of claims 1-9.

Images