Network request processing method and device, equipment and storage medium

Abstract

The invention provides a network request processing method and device, equipment and a storage medium, and relates to the technical field of Internet, in particular to the technical field of cloud mobile phone, virtual machine and network security. The method comprises the following steps: identifying a target application program running on the cloud mobile phone; intercepting a network request initiated by a target application program; obtaining response data of the network request by using client equipment paired with the cloud mobile phone; and forwarding the response data to the target application program. According to the scheme of the invention, the client device initiates the network request, so that the application on the cloud mobile phone can perform network access by using the local real IP address of the user.

Description

Technical Field

[0001] This disclosure relates to the field of Internet technology, and in particular to cloud phone technology, virtual machine technology, and network security, specifically to a method, apparatus, device, and storage medium for processing network requests. Background Technology

[0002] In today's digital network environment, network security and risk control (referred to as "risk control") has become an indispensable part of enterprise operations. Many internet applications and services (such as finance, social networking, and e-commerce) have established their own risk control strategies, among which the characteristic analysis and identification of accessing IP addresses is the core foundation of the risk control system. As a common risk control measure, the system will mark IP addresses originating from data centers (IDC) or exhibiting abnormal behavior patterns (such as high-density sharing and high-frequency switching), and may take measures such as restricting access, increasing authentication, or directly blocking access.

[0003] Cloud phones, as an emerging virtualized mobile device solution, deploy mobile operating system instances in cloud data centers, allowing users to access them remotely via the network. This technical architecture gives cloud phone services certain network characteristics in terms of product form. Summary of the Invention

[0004] This disclosure provides a method, apparatus, device, and storage medium for processing network requests to solve or alleviate one or more technical problems in the prior art.

[0005] Firstly, this disclosure provides a method for processing network requests, applied to a cloud phone operating system, including: Identify the target application running on the cloud phone; Intercept network requests initiated by the target application; The client device paired with the cloud phone is used to obtain the response data of the network request; the response data is the data obtained by the client device after it initiates a request using its local network IP address. Forward the response data to the target application.

[0006] Secondly, this disclosure provides a network request processing method applied to a client device, which is paired with a cloud phone, including: Receive encapsulated data from the cloud phone through the preset end-to-cloud channel; Parse and encapsulate the data to determine the original target address of the network request; Use the client device's local network IP address to initiate a network request to the original target address; Receive response data for network requests; The response data is sent to the cloud phone via the end-to-cloud channel.

[0007] Thirdly, this disclosure provides a processing apparatus for network requests applied to a cloud phone server, comprising: The identification module is used to identify the target application running on the cloud phone; The interception module is used to intercept network requests initiated by the target application; The acquisition module is used to acquire response data of network requests using a client device paired with the cloud phone; the response data is the data obtained by the client device after initiating a request using its local network IP address. The forwarding module is used to forward response data to the target application.

[0008] Fourthly, this disclosure provides a network request processing apparatus for a client device, which is paired with a cloud phone, including: The first receiving module is used to receive encapsulated data from the cloud phone through a preset end-to-cloud channel; The parsing module is used to parse the encapsulated data to determine the original target address of the network request; The request module is used to initiate a network request to the original target address using the local network IP address of the client device; The second receiving module is used to receive response data for network requests; The sending module is used to send response data to the cloud phone via the end-to-cloud channel.

[0009] Fifthly, an electronic device is provided, comprising: At least one processor; and The memory is communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method described in any one of the embodiments of this disclosure.

[0010] In a sixth aspect, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform the method according to any one of the embodiments of the present disclosure.

[0011] In a seventh aspect, a computer program product is provided, including a computer program that, when executed by a processor, implements the method according to any one of the embodiments of the present disclosure.

[0012] The beneficial effects of the technical solution provided in this disclosure include at least the following: By having the client device initiate network requests on behalf of the user, applications on the cloud phone can access the network using the user's real local IP address. This allows the cloud phone's network behavior to resemble that of a real user, thus circumventing the detection of the risk control system to the greatest extent possible.

[0013] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0014] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments provided according to this disclosure and should not be construed as limiting the scope of this disclosure.

[0015] Figure 1 This is a schematic flowchart illustrating a method for processing network requests according to an embodiment of the present disclosure; Figure 2 This is a flowchart illustrating a network request processing method according to another embodiment of the present disclosure; Figure 3 This is an architecture diagram of a method for processing network requests based on an end-to-cloud collaborative channel according to an embodiment of this disclosure; Figure 4 This is a timing diagram of a traffic redirection method based on an end-to-cloud channel according to an embodiment of this disclosure; Figure 5 This is a schematic diagram of a network request processing device applied to a cloud mobile phone server according to an embodiment of the present disclosure; Figure 6 This is a schematic diagram of a network request processing apparatus applied to a client device according to an embodiment of the present disclosure; Figure 7 This is a block diagram of an electronic device used to implement the network request processing method of the embodiments of this disclosure. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. The components of the embodiments of this disclosure described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this disclosure provided in the accompanying drawings is not intended to limit the scope of the claimed disclosure, but merely represents selected embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without inventive effort are within the scope of protection of this disclosure.

[0017] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0018] In this document, the term "and / or" merely describes a relationship, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. Furthermore, the term "at least one" in this document means any combination of at least two of any one or more elements. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.

[0019] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions of this disclosure will be clearly and completely described below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments.

[0020] In related technologies, cloud phone service providers typically deploy a massive number of cloud phone instances within data centers. In terms of network architecture, these instances need to access the network through the data center's egress IP address. A common deployment method is for multiple (e.g., dozens to hundreds) cloud phone instances to share the same or the same set of egress IP addresses for internet access.

[0021] The usage pattern of cloud phone services may involve different users accessing the same application service through the same IP address within a short period of time.

[0022] The network characteristics of highly reused IP addresses and concentrated access behavior are similar to the abnormal patterns monitored by some risk control systems. This means that when cloud phone services access certain applications that are sensitive to the IP environment, they may face the challenge of being identified by the risk control system and triggering corresponding management policies.

[0023] In response to this technological background, several solutions have been proposed in related technical fields to optimize the IP network characteristics of cloud phones.

[0024] One solution is to expand the IP pool. This approach reduces the density of cloud phone instances hosted on a single IP address by increasing the total number of egress IP addresses, thereby diluting the concentrated nature of data center IPs to some extent.

[0025] Another approach is to implement dynamic IP allocation. This approach attempts to dynamically assign IP addresses to cloud phone instances, or periodically change IP addresses, to simulate the network usage scenarios of real users.

[0026] Another approach is to distribute IP addresses geographically. This approach improves the diversity and flexibility of IP addresses by using distributed IP resources from multiple regions and carriers.

[0027] However, all three solutions mentioned above rely on additional resource investment, such as purchasing a large number of IP addresses and deploying corresponding network infrastructure. Given the increasing depletion of IPv4 address resources and the still unsatisfactory adoption rate of IPv6, the cost-effectiveness and sustainability of these solutions face challenges. Especially since a large number of services still rely primarily on IPv4 traffic, simply increasing IP resources cannot fundamentally solve the IP risk control problems faced by cloud phones.

[0028] To at least partially address one or more of the aforementioned problems and other potential issues, embodiments of this disclosure provide a method for processing network requests. This method utilizes end-to-cloud channel technology to redirect the network traffic of a cloud phone to a local terminal device, enabling the cloud phone to directly access the network using the real user's local IP address. By employing the technical solution of this disclosure, the network behavior of the cloud phone can resemble the network usage patterns of a real user, including the geographical distribution of IP addresses and carrier characteristics, thereby circumventing the detection of risk control systems to the greatest extent possible. Since this solution utilizes the user's own local network, it naturally achieves IP address diversity and dispersion, eliminating the need for additional IP resource management costs.

[0029] Figure 1 This is a flowchart illustrating a method for processing network requests according to an embodiment of this disclosure. This method is applied to a cloud phone operating system. A cloud phone can be understood as a virtualized mobile device solution deployed in a data center, simulating one or more Android (or other mobile operating system) instances on a server. This method aims to solve the network access risk control problem caused by cloud phones sharing data center IPs. Figure 1 As shown, the method includes the following steps: S110: Identifies the target application running on the cloud phone.

[0030] In this embodiment, the target application can be understood as an application with strict risk control policies regarding network environment and IP address, such as financial, social, or e-commerce applications. The identification process aims to accurately identify these applications requiring special network processing from among the numerous applications in the cloud phone. This step is a prerequisite for subsequent traffic interception.

[0031] For example, if a cloud phone instance has three applications installed: a game, a video app, and a banking app, this step will identify the banking app as the target application.

[0032] S120: Intercept network requests initiated by the target application.

[0033] Interception can be understood as intercepting network data packets sent by a target application at the operating system level from its default network path (i.e., accessing the Internet through the exit IP of the cloud phone data center).

[0034] For example, when a banking application (the target application) is identified and attempts to connect to its server, the system blocks it from directly accessing the cloud phone's IP address and captures this network request.

[0035] S130: Use a client device paired with a cloud phone to obtain response data for network requests.

[0036] The client device for cloud phone pairing refers to the physical terminal used by the user to access and control the cloud phone, such as the user's personal computer, local mobile phone, or tablet.

[0037] This step is a general overview. Its core idea is that the cloud phone itself (in the data center) no longer directly initiates network requests, but instead delegates the requests to the user's local client device. The client device's network environment (such as home broadband, 4G / 5G mobile network) is used to initiate the requests on its behalf, and finally the execution result (i.e., response data) is retrieved.

[0038] The response data is the data obtained by the client device after it initiates a request using its local network IP address.

[0039] This limitation specifies the source of the response data, clarifying that the network request was completed on the client device using its local IP (a real, non-data center IP), which is key to circumventing risk control.

[0040] S140: Forward the response data to the target application.

[0041] In this step, after the cloud phone operating system obtains the response data from the client device through step S130, it will return this data (such as JSON data packets or HTML pages returned by the server) to the target application running inside the cloud phone.

[0042] For example, a login request initiated by a banking application is executed via the client device using its local IP address, and a "login successful" response is obtained. The cloud phone system then returns this "login successful" data to the banking application.

[0043] For the target application running in the cloud phone, the whole process is transparent. It will think that it has initiated a network request and received a normal response, and will not be aware that the request was actually completed on the user's local client device.

[0044] According to the scheme of this disclosure embodiment, by identifying and intercepting the requests of the target application and using the client device to initiate network requests on behalf of the user, the application on the cloud phone can use the user's local real IP address to access the network, thereby making the network usage pattern of the cloud phone present a feature highly consistent with that of the real user, fundamentally avoiding various risk control detections caused by the centralized and shared IP of the data center.

[0045] In one possible implementation, step S110 identifies the target application running on the cloud phone, and further includes the following steps: S111: Get the list of global risk control applications.

[0046] In this embodiment of the disclosure, the global risk control application list can be a list or database centrally stored on a cloud server. This list is dynamically maintained by the service provider and is used to record all applications known to be sensitive to IP environments and prone to triggering risk control measures.

[0047] The list can include information such as the application's package name, risk level, and when it was added. For example, { "packageName": "com.tencent.mm", "riskLevel": "high"}.

[0048] S112: Based on the list of risk control applications, identify the target application among the applications already installed on the cloud phone.

[0049] The cloud phone operating system obtains a list of locally installed applications and compares it with the global risk control application list obtained in step S111. If a locally installed application (e.g., its package name) exists in the risk control list, then that application is identified as the target application.

[0050] For example, if the global list contains com.eg.android.ABCD, the cloud phone will detect that the application is installed locally and identify it as the target application.

[0051] According to the solution of this disclosure, a flexible and dynamically adjustable target application identification mechanism is achieved by establishing a dynamically updated risk control list in the cloud and allowing the cloud phone to perform comparisons locally. Service providers can update the list at any time to address new risk control threats, while the cloud phone does not need to update the entire system, thus improving the flexibility and adaptability of the solution.

[0052] When performing network control at the operating system level, it is usually not possible to directly base it on the package name; instead, it needs to be based on the UID (Unique Identifier). Therefore, a mapping from package name to UID needs to be established. In one possible implementation, step S112, based on the list of risk control applications, determines the target application among the applications already installed on the cloud phone, and further includes the following steps: S112-1: Monitor application installation and uninstallation events on cloud phones.

[0053] A monitoring service is established within the cloud phone operating system. This service can utilize the BroadcastReceiver mechanism provided by the Android system to listen for system-level packet events.

[0054] For example, register a custom BroadcastReceiver to listen for broadcasts such as ACTION_PACKAGE_ADDED (application installation), ACTION_PACKAGE_REPLACED (application update), and ACTION_PACKAGE_REMOVED (application uninstallation).

[0055] S112-2: Establish a mapping relationship between the package names of applications installed on the cloud phone and their corresponding identifiers.

[0056] In this step, the identifier refers to the User Identifier (UID). In systems like Android with a Linux kernel, it is a unique integer ID assigned to each application by the system. The operating system uses the UID to manage application permissions and identify processes. It's important to note that in the context of this technical solution, the UID specifically refers to the unique ID used by the Android / Linux operating system kernel to identify and isolate applications, not the user's login account ID. The identifier can also be understood as the Application Identifier.

[0057] Based on its security sandbox model, the Android system assigns a unique UID to each application when it is installed, which is different from other applications. Therefore, although only one user is operating a cloud phone, the different applications running inside it (such as WeChat and Alipay) each correspond to a unique UID (such as 10001, 10002).

[0058] When the monitoring service detects an application installation (such as when the onPackageAdded callback is triggered), it retrieves detailed information about the newly installed application from the PackageManager, especially its package name and system-assigned UID, and records this mapping in a local database or list. When the application is uninstalled, this mapping is removed.

[0059] S112-3: Based on the package names in the list of risk control applications and using the mapping relationship, determine the identifier corresponding to the target application.

[0060] After determining the package name of the target application in step S112, the system will query the mapping relationship established in step S112-2 to find the UID currently corresponding to the package name.

[0061] For example, the risk control list requires blocking com.eg.mm. The system queries the mapping table and finds that its UID is 10001. Therefore, 10001 is the object that subsequent firewall rules need to process.

[0062] According to the solution of this disclosure, by monitoring application changes in real time and establishing a mapping from package name to UID, the problem of conversion between application package name and underlying traffic identifier is solved. This ensures that subsequent traffic interception can be accurate to the specific application. Even if the application is updated or reinstalled, causing the UID to change, the system can adapt dynamically, ensuring the accuracy and real-time performance of the interception.

[0063] In one possible implementation, step S120 intercepts the network request initiated by the target application, and further includes the following steps: S121: Dynamically configure firewall rules based on the identifier corresponding to the target application.

[0064] In this embodiment of the disclosure, firewall rules may refer to network filtering rules in the cloud phone operating system, such as iptables or nftables rules.

[0065] Once the target UID is determined, a firewall dynamic management service will be started to create one or more network rules specifically for that UID.

[0066] S122: Using firewall rules, redirect network requests belonging to this identifier to the proxy service inside the cloud phone.

[0067] In this step, the proxy service is a local service pre-deployed within the cloud phone operating system that listens on a specific local port (e.g., 8888).

[0068] Redirection refers to a firewall rule's action of forwarding a data packet to the listening port of an internal proxy service instead of dropping or rejecting it.

[0069] For example, the firewall dynamic management service adds a rule: all TCP and UDP traffic originating from UID=10001 is redirected to local port 8888.

[0070] According to the scheme of this disclosure, a highly efficient and accurate traffic interception mechanism is achieved by dynamically configuring firewall rules based on UID and utilizing their redirection function. This mechanism controls traffic at the operating system kernel level, is transparent to the target application, and has low performance overhead.

[0071] In one possible implementation, the dynamic configuration of firewall rules in step S121 further includes the following steps: S121-1: Calls the underlying operating system via the virtual machine-local interaction interface to change iptables rules in order to redirect network requests.

[0072] In this embodiment of the disclosure, the virtual machine-native interaction interface can be understood as a mechanism that allows code running in a virtual machine environment (such as a Java service running on the Android ART virtual machine) to communicate and call the native code of the operating system (usually referring to code written in C / C++). JNI (Java Native Interface) is a specific implementation of this interaction interface. JNI is a mechanism that allows code running in the Java Virtual Machine (JVM) to call native applications.

[0073] iptables is a command-line tool in the Linux kernel used to configure firewall rules.

[0074] Because directly modifying iptables rules in the upper-level virtual machine environment of Android (such as ART or Dalvik) is limited and inefficient, the firewall dynamic management service in this solution (a service running on the virtual machine) can call a pre-built C / C++ native library through virtual machine-native interaction interface technology. This native library runs in the local environment of the operating system, has sufficient permissions, and can efficiently execute iptables commands.

[0075] For example, when it is necessary to intercept UID10001, the Java service calls a native C++ function through JNI. This function performs the equivalent of the system call iptables -t nat -A OUTPUT -m owner --uid-owner 10001 -j REDIRECT --to-port 8888.

[0076] According to the solution of this disclosure embodiment, iptables is manipulated by calling C++ through JNI, which solves the problem that Android upper-layer applications cannot directly and efficiently manage the underlying firewall rules, and provides a high-performance and low-latency way to achieve dynamic rule configuration.

[0077] In one possible implementation, step S130 utilizes a client device paired with the cloud phone to obtain response data for the network request, and further includes the following steps: S131: Process network requests to generate encapsulated data.

[0078] In this embodiment of the disclosure, the encapsulated data can be understood as a custom data structure that packages the original network request together with its metadata (such as the original target address) for transmission in the end-to-cloud channel.

[0079] S132: The encapsulated data is sent to the client device paired with the cloud phone through the end-to-cloud channel established between the cloud phone and the client device.

[0080] The end-to-cloud channel is a secure and stable data transmission link established between cloud phones (cloud) and client devices (terminals).

[0081] S133: Receive response data returned by the client device through the end-to-cloud channel.

[0082] In this step, the cloud phone waits through this channel and receives the result returned by the client device after making a request on its behalf.

[0083] For example, an intercepted request is processed and encapsulated, and then sent to the client through a channel; after the client executes the request, it sends the result (such as a webpage HTML) back through the same channel, and the cloud phone receives the HTML data in this step.

[0084] According to the scheme of this disclosure embodiment, by specifying it as a closed-loop process of "processing-sending-receiving", the interaction method between the cloud phone and the client device is clearly defined, providing a complete operation path for realizing traffic redirection.

[0085] In one possible implementation, S131 processes the network request to generate encapsulated data, further including: S131-1: The proxy service receives the redirected network request.

[0086] In this embodiment of the disclosure, network traffic redirected by iptables rules is captured by an internal proxy service listening on a predetermined port. The proxy service can efficiently handle concurrent connections using I / O multiplexing techniques such as epoll or select.

[0087] S131-2: The proxy service parses network requests to obtain the original target address and port.

[0088] Because the traffic is redirected, the proxy service receives connections destined for itself (localhost:8888). Therefore, the proxy service needs to query the kernel via a specific system call (such as getsockopt(SO_ORIGINAL_DST) on Linux) to obtain the "original target address and port" of the connection before it was redirected.

[0089] For example, if a request is redirected to port 8888, the proxy service can find out that its original target is 47.98.xx:443 by querying the port.

[0090] S131-3: The proxy service encapsulates network requests and the original target address and port to generate encapsulated data.

[0091] The proxy service uses a custom protocol format to package key information such as the original request data (Payload), the original target address, the original target port, and the session ID into a unified data structure, i.e., encapsulated data.

[0092] For example, generate a data packet: { "sessionId": "abc-123", "targetHost": "47.98.xx", "targetPort": 443, "payload": "..."}.

[0093] According to the scheme of this disclosure embodiment, the redirected traffic is received, parsed and encapsulated through a proxy service, which solves two key problems: "how to find the original target address from the intercepted traffic" and "how to package the request information for cross-device transmission". This is the core technical link to realize traffic forwarding.

[0094] In one possible implementation, the end-to-cloud channel is a WebSocket channel.

[0095] In this embodiment of the disclosure, WebSocket is a protocol for full-duplex communication over a single TCP connection, which allows for real-time, bidirectional data transmission between the server and the client.

[0096] In this solution, a long-lived WebSocket connection is established between the end-to-cloud collaboration SDK within the cloud phone operating system and the SDK on the client device. This connection constitutes the end-to-cloud channel.

[0097] WebSocket was chosen because of its good web compatibility (connections can be established via standard HTTP / HTTPS ports, easily traversing firewalls and NAT) and low latency. The SDK handles WebSocket connection establishment, heartbeat maintenance, and reconnection after disconnection, ensuring a stable and reliable channel.

[0098] According to the scheme of this disclosure embodiment, WebSocket is used as the specific implementation of the end-to-cloud channel, providing a stable, efficient and highly compatible link for data transmission between cloud phones and clients.

[0099] In one possible implementation, step S111, obtaining the global risk control application list, further includes: S111-1: When the cloud phone starts up or at a fixed frequency, it pulls the latest list of global risk control applications through a preset interface.

[0100] In this embodiment of the disclosure, the preset interface can be an HTTP API provided by a cloud server.

[0101] To ensure the real-time availability of the risk control list, the services within the cloud phone are configured to call this interface to retrieve the latest list every time it starts up.

[0102] In addition, the service will automatically perform a background fetch update at a fixed frequency (e.g., every 24 hours).

[0103] According to the solution of this disclosure embodiment, the update mechanism combining "start-up pull" and "fixed-frequency pull" ensures that the risk control list on the cloud phone is always synchronized with the cloud, enabling it to respond promptly to new risk control strategies or applications.

[0104] Figure 2 This is a flowchart illustrating a network request processing method according to an embodiment of this disclosure. The method is applied to a client device paired with a cloud phone to coordinate with the cloud phone in redirecting network requests. Figure 2 As shown, the method includes the following steps: S210: Receives encapsulated data from the cloud phone through a preset end-to-cloud channel.

[0105] This step corresponds to S132 on the cloud phone side. The SDK on the client device (e.g., the user's PC) continuously listens through the WebSocket channel and receives the encapsulated data packets sent by the cloud phone.

[0106] For example, the received data packet is: { "sessionId": "abc-123", "targetHost": "47.98.xx", ...}.

[0107] S220: Parse the encapsulated data to determine the original target address of the network request.

[0108] The client SDK parses the received data packets and extracts the original target address (targetHost) and port (targetPort) as well as the original request data (payload).

[0109] S230: Use the local network IP address of the client device to initiate a network request to the original target address.

[0110] In this step, the client SDK uses the local device's network stack (such as home WiFi or 5G network) to initiate a new network connection (TCP or UDP) to the extracted original target address and port on the local device.

[0111] For example, the client PC uses its home broadband IP (220.181.xx) to initiate a TCP connection to 47.98.xx:443 and sends the payload there.

[0112] S240: Receive response data for network requests.

[0113] The client device receives the response from the target server locally (e.g., login confirmation information returned by a bank server).

[0114] S250: Sends response data to the cloud phone via the end-to-cloud channel.

[0115] The client SDK sends the response data received in step S240, along with the session ID, back to the cloud phone via the WebSocket channel.

[0116] According to the solution of this disclosure embodiment, the client device receives instructions from the cloud phone, uses its local network environment (i.e., the real user's IP address) to execute network requests on its behalf, and returns the results to the cloud. This makes the network access behavior appear completely equivalent to a real user's local operation from the perspective of the risk control system, thereby completely solving the problem of cloud phone data center IP being subject to risk control.

[0117] This embodiment provides a method for processing network requests based on an end-to-cloud collaborative channel, the architecture of which is shown in the figure below. Figure 3 As shown. The main entities implementing this method include: Cloud phone server: As the operating environment for cloud phones, it deploys cloud phone instances.

[0118] Cloud phone instance: A virtualized operating system running on the server side, which is the execution environment for core components such as firewall and proxy service in this solution.

[0119] Cloud mobile client: The user's local physical device (such as a personal mobile phone or computer) is the execution entity that collaborates with the server in this solution and ultimately initiates real network requests.

[0120] Risk control APP list interface: An external service used to provide the cloud phone server with a list of target applications that need to be redirected for traffic.

[0121] Internet services: The target servers that applications on cloud phones need to access.

[0122] The specific implementation steps of this method are as follows: S310: Establish risk control interface service.

[0123] As shown in step 1 of the diagram, the first step is to establish a risk control APP list interface. This interface is a database service maintained in the cloud, used to centrally manage and store information (such as package names) of high-risk or special applications.

[0124] S320: Monitor and update the firewall.

[0125] As shown in step 2 of the diagram, an update firewall module is deployed within the cloud phone instance. This module actively connects to the risk control APP list interface in step S310 to retrieve the latest risk control list. This process can be periodic or triggered when the cloud phone instance starts up, ensuring that the local firewall policy is always up-to-date.

[0126] S330: Redirect traffic.

[0127] As shown in step 3 of the diagram, when an application within the cloud phone instance (not shown in the diagram, but representing the traffic initiator) initiates a network request, the firewall forwarding module will match it according to the rules updated in step S320. If the request originates from an application on the risk control list, the firewall will block the request and redirect (forward) it to the proxy service within the cloud phone instance, instead of allowing it to pass through the default network exit of the cloud phone server.

[0128] S340: Proxy service forwards traffic.

[0129] As shown in step 4 of the figure, after receiving the traffic redirected by the firewall (step S330), the proxy service will process the request, such as resolving the original target address and port, and encapsulating it into a specific data format.

[0130] S350: Establishes an end-to-cloud collaboration channel, enabling cloud mobile clients to obtain requests for proxy services.

[0131] As shown in step 5 of the diagram, a cloud-to-end collaborative channel (e.g., WebSocket) is established between the proxy service on the cloud phone server and the cloud phone client. The proxy service sends the encapsulated request data to the cloud phone client through this channel.

[0132] Next, as shown by the dotted arrow between the client and the internet service in the diagram, after receiving the request, the cloud phone client will use its own local network (i.e., local IP address) to initiate a real access request to the internet service.

[0133] S360: The cloud phone client returns the result of the request.

[0134] As shown in step 6 of the diagram, the internet service returns the response data to the cloud phone client (local device). The cloud phone client then sends this response back to the proxy service on the cloud phone server via the end-to-cloud collaboration channel. The proxy service finally delivers this result back to the application within the cloud phone instance that initially initiated the request, completing the entire loop.

[0135] According to the scheme of this disclosure embodiment, through the collaborative work of the cloud phone server (firewall and proxy deployed within the instance) and the cloud phone client, specific application traffic within the cloud phone instance is transferred to the client device via an end-to-cloud collaborative channel. The client device then uses its local IP address to access internet services and returns the results. This approach makes the access request appear from a real, distributed local IP address, rather than a centralized and easily blocked data center IP, thus effectively solving the IP risk control problem of cloud phones.

[0136] This embodiment provides a traffic redirection method based on an end-to-cloud channel, the execution flow of which is as follows: Figure 4 As shown, it involves components such as cloud mobile client, cloud mobile operating system, traffic redirection module, proxy service, end-to-cloud collaboration channel, client SDK and target server.

[0137] The method includes: S401: The cloud phone operating system performs initialization.

[0138] When the system starts up, the cloud phone operating system first performs initialization settings.

[0139] S402: Scan application list.

[0140] After initialization, the operating system will scan the applications currently installed on the system and generate an application list.

[0141] S403: Monitor the installation or uninstallation of the monitoring app.

[0142] The system continuously monitors the application status and triggers corresponding events when a new app is installed or an existing app is uninstalled.

[0143] S404: The cloud mobile client (APP) initiates a network request.

[0144] An application running on the cloud phone operating system (i.e., the cloud phone client in the diagram) initiates a network request, such as attempting to log in.

[0145] S405: The cloud phone operating system sends network requests to the traffic redirection module.

[0146] The operating system captures the network request and hands it over to the traffic redirection module for processing.

[0147] S406: The traffic redirection module redirects traffic to the proxy service.

[0148] The traffic redirection module determines whether the request originates from the target application that needs to be managed, based on preset rules (such as iptables rules). If so, it prevents the request from passing through the data center IP exit and instead redirects it to the proxy service inside the cloud phone.

[0149] S407: Proxy service encapsulates request.

[0150] After receiving the redirected traffic, the proxy service will parse its original target address, port and other information, and package it into a custom encapsulated request.

[0151] S408: The proxy service sends a packaged request to the end-to-cloud collaboration channel.

[0152] The proxy service sends the encapsulated request data to the end-to-cloud collaboration channel.

[0153] S409: The end-to-end cloud collaboration channel transmits encapsulated requests via WebSocket.

[0154] The edge-cloud collaboration channel (such as a WebSocket service) encapsulates the request and transmits it to the client SDK running on the user's local device via a secure long connection.

[0155] S410: Client SDK parsing request.

[0156] After receiving the WebSocket message, the client SDK parses it to reconstruct the original request target and data.

[0157] S411: The client SDK sends a TCP / UDP request to the target server.

[0158] The client SDK utilizes the user's local device network and uses the local IP address to initiate real TCP or UDP requests to the target server.

[0159] S412: The target server returns a response.

[0160] After processing the request, the target server returns the response data to the client SDK.

[0161] S413: The client SDK transmits the response via WebSocket.

[0162] The client SDK will send back the response data received from the target server via the WebSocket connection.

[0163] S414: The end-to-end cloud collaboration channel will respond and transfer the proxy service.

[0164] The proxy service receives the returned response data from the channel.

[0165] S415: Proxy service parsing response.

[0166] The proxy service parses the response data.

[0167] S416: The agent service will return a response to the cloud mobile client (APP).

[0168] The proxy service returns the parsed response data to the cloud phone operating system, which then returns it to the application that initially initiated the request (the cloud phone client).

[0169] In addition, this embodiment also includes a parallel update process: S417: The cloud phone operating system performs regular updates.

[0170] The system's internal services will automatically perform update tasks according to a set period (e.g., daily).

[0171] S418: Update the application manifest.

[0172] This task will pull the latest list of risk control applications.

[0173] S419: Update iptables rules.

[0174] The cloud phone operating system updates the iptables rules in the traffic redirection module according to the updated application list to ensure that the traffic of newly identified applications can be correctly blocked.

[0175] According to the scheme of this disclosure embodiment, the cloud phone operating system and the client SDK work together to forward network requests and responses of specific applications through the end-to-cloud channel. The actual network access is completed by the client SDK on the local device, so that the access IP perceived by the target server is the user's real local IP, rather than the cloud phone's data center IP, effectively avoiding IP risk control issues.

[0176] Figure 5 This is a schematic diagram of a network request processing apparatus 500 applied to a cloud phone server according to an embodiment of this disclosure. Figure 5 As shown, the device includes at least: The identification module 501 is used to identify the target application running on the cloud phone; Interception module 502 is used to intercept network requests initiated by the target application; The acquisition module 503 is used to acquire response data of network requests using a client device paired with the cloud phone; wherein, the response data is the data obtained by the client device after initiating a request using its local network IP address; Forwarding module 504 is used to forward response data to the target application.

[0177] In one possible implementation, the identification module 501 is used for: Obtain the global list of risk control applications; Based on the list of risk control applications, the target application is identified among the applications already installed on the cloud phone.

[0178] In one possible implementation, the identification module 501 is used for: Monitor application installation and uninstallation events on cloud phones; Establish a mapping relationship between the package names of applications installed on the cloud phone and their corresponding identifiers; Based on the package names in the list of risk control applications, and using the mapping relationship, the identifier corresponding to the target application is determined.

[0179] In one possible implementation, the interception module 502 is used for: Firewall rules are dynamically configured based on the identifier corresponding to the target application. By using firewall rules, network requests belonging to this identifier are redirected to the proxy service inside the cloud phone.

[0180] In one possible implementation, the interception module 502 is used for: By calling the underlying operating system through the virtual machine-local interaction interface, iptables rules are modified to redirect network requests.

[0181] In one possible implementation, the acquisition module 503 is used for: Process network requests to generate encapsulated data; The packaged data is sent to the client device paired with the cloud phone through a preset end-to-cloud channel; Receive response data returned by the client device through the edge-cloud channel.

[0182] In one possible implementation, the acquisition module 503 is used for: The proxy service receives the redirected network requests; The proxy service parses network requests to obtain the original target address and port; The proxy service encapsulates network requests and the original target address and port to generate encapsulated data.

[0183] In one possible implementation, the end-to-cloud channel is a WebSocket channel.

[0184] In one possible implementation, the identification module 501 is used for: When the cloud phone starts up, or at a fixed frequency, it retrieves the latest list of global risk control applications through a preset interface.

[0185] The specific functions and examples of each module and submodule of the apparatus in this disclosure can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

[0186] Figure 6 This is a schematic diagram of a network request processing apparatus 600 applied to a client device according to an embodiment of the present disclosure. The client device is paired with a cloud phone, and the apparatus includes: The first receiving module 601 is used to receive encapsulated data from the cloud phone through a preset end-to-cloud channel; The parsing module 602 is used to parse the encapsulated data to determine the original target address of the network request; Request module 603 is used to initiate a network request to the original target address using the local network IP address of the client device; The second receiving module 604 is used to receive response data for network requests; The sending module 605 is used to send response data to the cloud phone through the end-to-cloud channel.

[0187] The specific functions and examples of each module and submodule of the apparatus in this disclosure can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

[0188] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0189] Figure 7 This is a structural block diagram of an electronic device according to an embodiment of the present disclosure. Figure 7 As shown, the electronic device includes a memory 710 and a processor 720. The memory 710 stores a computer program that can run on the processor 720. The number of memories 710 and processors 720 can be one or more. The memory 710 can store one or more computer programs, which, when executed by the electronic device, cause the electronic device to perform the methods provided in the above-described method embodiments. The electronic device may also include a communication interface 730 for communicating with external devices and performing data exchange and transmission.

[0190] If the memory 710, processor 720, and communication interface 730 are implemented independently, they can be interconnected via a bus to communicate with each other. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0191] Optionally, in a specific implementation, if the memory 710, processor 720, and communication interface 730 are integrated on a single chip, then the memory 710, processor 720, and communication interface 730 can communicate with each other through an internal interface.

[0192] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Machines (ARM) architecture.

[0193] Further, optionally, the aforementioned memory may include read-only memory and random access memory, and may also include non-volatile random access memory. The memory may be volatile or non-volatile, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. Many forms of RAM are available by way of example, but not limitation. Examples include Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct RAMBUS RAM (DR RAM).

[0194] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this disclosure are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line, DSL) or wireless (e.g., infrared, Bluetooth, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer, or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)). It is worth noting that the computer-readable storage media mentioned in this disclosure can be non-volatile storage media; in other words, it can be non-transient storage media.

[0195] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0196] In the description of the embodiments of this disclosure, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this disclosure. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0197] Finally, it should be noted that the above-described embodiments are merely specific implementations of this disclosure, used to illustrate the technical solutions of this disclosure, and not to limit it. The protection scope of this disclosure is not limited thereto. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this disclosure. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be covered within the protection scope of this disclosure. Therefore, the protection scope of this disclosure should be determined by the protection scope of the claims.

Claims

1. A method for processing network requests, applied to a cloud phone operating system, comprising: Identify the target application running on the cloud phone; Intercept network requests initiated by the target application; The response data of the network request is obtained using a client device paired with the cloud phone; wherein, the response data is the data obtained by the client device after initiating a request using its local network IP address; The response data is forwarded to the target application.

2. The method according to claim 1, characterized in that, The identification of the target application running on the cloud phone includes: Obtain the global list of risk control applications; Based on the list of risk control applications, the target application is determined from the applications already installed on the cloud phone.

3. The method according to claim 2, characterized in that, The process of identifying the target application from the list of risk control applications installed on the cloud phone includes: Monitor application installation and uninstallation events on the cloud phone; Establish a mapping relationship between the package names of applications installed on the cloud phone and their corresponding identifiers; Based on the package names in the list of risk control applications and using the mapping relationship, the identifier corresponding to the target application is determined.

4. The method according to claim 3, characterized in that, The interception of network requests initiated by the target application includes: Firewall rules are dynamically configured based on the identifier corresponding to the target application. Using the firewall rules, network requests belonging to the identifier are redirected to the proxy service inside the cloud phone.

5. The method according to claim 4, characterized in that, The dynamically configured firewall rules include: By calling the underlying operating system through the virtual machine-local interaction interface, iptables rules are modified to redirect network requests.

6. The method according to claim 1, characterized in that, The step of obtaining the response data of the network request using a client device paired with the cloud phone includes: Process the network request to generate encapsulated data; The encapsulated data is sent to the client device paired with the cloud phone through the end-to-cloud channel established between the cloud phone and the client device. The response data returned by the client device is received through the cloud-edge channel.

7. The method according to claim 6, characterized in that, The process of processing the network request to generate encapsulated data includes: The redirected network request is received by the proxy service; The proxy service parses the network request to obtain the original target address and port; The proxy service encapsulates the network request and the original target address and port to generate the encapsulated data.

8. The method according to claim 6, characterized in that, The cloud-end channel is a WebSocket channel.

9. The method according to claim 2, characterized in that, The process of obtaining the global risk control application list includes: The cloud phone retrieves the latest global risk control application list through a preset interface upon startup or at a fixed frequency.

10. A method for processing network requests, applied to a client device, said client device being paired with a cloud phone, comprising: The encapsulated data from the cloud phone is received through a preset end-to-cloud channel; Parse the encapsulated data to determine the original target address of the network request; The network request is initiated to the original target address using the local network IP address of the client device; Receive response data for the network request; The response data is sent to the cloud phone via the end-to-cloud channel.

11. A processing apparatus for network requests applied to a cloud phone server, comprising: The identification module is used to identify the target application running on the cloud phone; The interception module is used to intercept network requests initiated by the target application; The acquisition module is used to acquire response data of the network request using a client device paired with the cloud phone; wherein, the response data is the data obtained by the client device after initiating a request using its local network IP address; The forwarding module is used to forward the response data to the target application.

12. A network request processing apparatus for a client device, the client device being paired with a cloud phone, comprising: The first receiving module is used to receive encapsulated data from the cloud phone through a preset end-to-cloud channel; A parsing module is used to parse the encapsulated data to determine the original target address of the network request; The request module is used to initiate the network request to the original target address using the local network IP address of the client device; The second receiving module is used to receive the response data of the network request; The sending module is used to send the response data to the cloud phone through the end-to-cloud channel.

13. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method of any one of claims 1-10.

14. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-10.

15. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-10.

Images