Application access method and apparatus, and application experience assurance method and apparatus

Abstract

Provided in the embodiments of the present application are an application access method and apparatus, and an application experience assurance method and apparatus. In an encrypted packet sent by a zero-trust SDP client to a network device, a packet header including an application identifier is further encapsulated in an outer layer of an encrypted tunnel header, such that when the encrypted packet reaches the network device through which an encrypted tunnel passes, the network device can obtain the application identifier from the outer layer of the encrypted tunnel header. Since the application identifier indicates an application corresponding to a service packet, the network device can perceive the application corresponding to the service packet without decrypting the encrypted packet, thereby reducing the difficulty for the network device to perform application identification, and thus reducing the difficulty for the network device to implement application experience assurance.

Description

Application access methods, application experience assurance methods and devices

[0001] This application claims priority to Chinese Patent Application No. 202510207156.5, filed on February 24, 2025, entitled "Application Access Method, Application Experience Protection Method and Apparatus", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of network security, and in particular to an application access method, an application experience protection method, and an apparatus. Background Technology

[0003] Application experience assurance refers to using application identification technology to identify the application to which a packet belongs, and managing the packet forwarding process based on the corresponding assurance policy for that application, thereby ensuring the user's application experience. One of the initial motivations for application experience assurance strategies was that, with the increasing richness of network applications, packets from various applications are mixed together, easily leading to non-critical application packets consuming excessive bandwidth, critical application packets experiencing packet loss, uncontrollable latency jitter, and compromised service quality for critical applications. Therefore, by adopting application experience assurance technology, it is possible to identify packets belonging to critical and non-critical applications, and apply differentiated experience assurance policies to these packets. For example, when a packet is identified as belonging to a video conferencing application with high service quality requirements, the packet is forwarded with a higher priority, thus ensuring a good video conferencing experience; when a packet is identified as belonging to an application with low service quality requirements, the packet is forwarded with a lower priority, thus providing sufficient network resources for packets from applications with high service quality requirements.

[0004] When using application experience assurance technology in a zero-trust software-defined perimeter (SDP) architecture, the encrypted tunnel between the zero-trust SDP client and the SDP gateway will traverse multiple network devices, making it difficult for network devices to ensure application experience based on application identification technology. Summary of the Invention

[0005] This application provides an application access method, an application experience assurance method, and an apparatus, which can reduce the difficulty for network devices to ensure application experience. The technical solution is as follows.

[0006] In a first aspect, an application access method is provided, the method comprising: a zero-trust SDP client obtaining an application identifier of an application; in response to an access operation to the application, the zero-trust SDP client encapsulating a service message corresponding to the application to obtain an encrypted message, the encrypted message including the service message, an encrypted tunnel header, and a first message header encapsulated on the outer layer of the encrypted tunnel header, the first message header including the application identifier; and the zero-trust SDP client sending the encrypted message to a network device.

[0007] Based on the above method, since the encrypted message sent by the Zero Trust SDP client to the network device is further encapsulated with a message header containing an application identifier on the outer layer of the encrypted tunnel header, when the encrypted message reaches the network device through which the encrypted tunnel passes, the network device can obtain the application identifier from the outer layer of the encrypted tunnel header. Since the application identifier indicates the application corresponding to the service message, the network device can perceive the application corresponding to the service message without decrypting the encrypted message, thereby reducing the difficulty for the network device to identify the application and thus reducing the difficulty for the network device to ensure the application experience.

[0008] In addition, network devices do not need to be configured with separate application identification cards to identify applications, which also reduces the deployment cost of network devices.

[0009] In some implementations, the first message header includes a TCP header, the TCP header includes TCP options, and the TCP options include the application identifier.

[0010] Because TCP options reserve a large number of bits, they are relatively easy to extend. By carrying application identifiers through TCP options, application identifiers can occupy more bits, making them more unique.

[0011] In some implementations, the first header includes an IP header, the IP header includes a DSCP field, and the DSCP field includes the application identifier.

[0012] The above methods support carrying application identifiers at the IP layer, enabling a wider range of application scenarios.

[0013] In some implementations, the zero-trust SDP client obtains the application identifier of the application by: after the identity authentication initiated by the zero-trust SDP client to the zero-trust SDP controller is successful, during the authorization process, the zero-trust SDP client receives the application identifier from the zero-trust SDP controller.

[0014] The above method supports issuing application identifiers to zero-trust SDP clients during the authorization process in the zero-trust SDP mechanism, and has good compatibility with existing zero-trust SDP mechanisms.

[0015] Secondly, a method for ensuring application experience is provided, the method comprising:

[0016] The network device receives an encrypted message from a zero-trust SDP client. The encrypted message includes an encrypted tunnel header and a first message header encapsulated on the outer layer of the encrypted tunnel header. The first message header includes the application identifier.

[0017] The network device obtains the experience guarantee policy corresponding to the application identifier;

[0018] The network device executes the experience guarantee policy on the encrypted message.

[0019] Because the encrypted tunnel header received by the network device is further encapsulated with a header containing an application identifier, the network device can obtain the application identifier from the outer layer of the encrypted tunnel header. Since the application identifier indicates the application corresponding to the service message, the network device can perceive the application corresponding to the service message without decrypting the encrypted message, thereby reducing the difficulty for the network device to identify the application and thus reducing the difficulty for the network device to ensure the application experience.

[0020] In some implementations, the network device obtains the experience guarantee policy corresponding to the application identifier, including: the network device receiving the application identifier and the experience guarantee policy from the network controller.

[0021] In some implementations, before the network device receives the application identifier and the experience guarantee policy from the network controller, the method further includes: the network device sending the application identifier, the flow identifier of the data stream, and the transmission rate of the data stream to the network controller.

[0022] By reporting application identifiers, flow identifiers, and data flow transmission rates to the network controller, network devices can present application experience information to the network controller. This helps administrators understand which applications have received experience guarantees and allows the network controller to make decisions on whether to enable experience guarantee policies for applications based on whether the data flow transmission rate is lagging, thus providing greater flexibility.

[0023] In some implementations, the first message header includes a TCP header, the TCP header includes TCP options, and the TCP options include the application identifier.

[0024] In some implementations, the first header includes an IP header, the IP header includes a DSCP field, and the DSCP field includes the application identifier.

[0025] Thirdly, a method for ensuring application experience is provided, the method comprising:

[0026] In response to an application registration operation, the Zero Trust SDP controller obtains the application identifier of the application.

[0027] The zero-trust SDP controller sends the application identifier to the network controller;

[0028] After the Zero Trust SDP controller successfully authenticates the Zero Trust SDP client, it sends the application identifier to the Zero Trust SDP client during the authorization process.

[0029] The Zero Trust SDP controller synchronizes application identifiers with the network controller, enabling collaboration between the two. This avoids the risk of application experience guarantee failure on network devices if the Zero Trust SDP controller fails to send application identifiers that need to be guaranteed to the Zero Trust SDP client due to the absence of such identifiers on the Zero Trust SDP controller. Consequently, the application identifiers cannot be encapsulated in the outer layer of the encrypted tunnel header.

[0030] In some implementations, the zero-trust SDP controller sends the application identifier to the network controller, including:

[0031] The zero-trust SDP controller sends an HTTPS message to the network controller, the HTTPS message including the application identifier.

[0032] The zero-trust SDP controller sends the application identifier to the network controller using HTTPS messages, which provides good security for the transmission of the application identifier.

[0033] Fourthly, a method for ensuring application experience is provided, the method comprising:

[0034] The network controller receives the application identifier from the zero-trust SDP controller;

[0035] The network controller determines the experience guarantee strategy corresponding to the application identifier;

[0036] The network controller sends the application identifier and the experience guarantee policy to the network device.

[0037] By issuing application identifiers and experience guarantee policies, the network controller effectively informs network devices of the correspondence between application identifiers and experience guarantee policies. This allows network devices to know which experience guarantee policy to apply to packets carrying a specific application identifier.

[0038] In some implementations, the network controller determines an experience guarantee policy corresponding to the application identifier, including: the network controller receiving the application identifier, the flow identifier of the data stream, and the transmission rate of the data stream from the network device; and the network controller determining the experience guarantee policy based on the flow identifier of the data stream and the transmission rate of the data stream.

[0039] The network controller determines the experience guarantee policy based on the transmission rate of the data stream corresponding to the application, so that the experience guarantee policy corresponding to the application matches the lag situation of the data stream sent to the application. For example, the application experience guarantee policy is enabled for the application corresponding to the slow data stream (manifested as application lag), thereby improving the user experience of the application corresponding to the slow data stream and making the application experience guarantee method more suitable for the actual network transmission situation.

[0040] In some implementations, the method further includes: the network controller presenting the user with experience information of the application, the experience information of the application including the stream identifier of the data stream, the transmission rate of the data stream, and the experience guarantee policy.

[0041] The network controller presents the data stream identifier, the data stream transmission rate, and the experience guarantee policy, making it easy for users to know the lag status of the data stream corresponding to the application and the application's experience guarantee policy.

[0042] Fifthly, a zero-trust SDP client is provided, including:

[0043] The acquisition unit is used to acquire the application identifier of the application.

[0044] A processing unit is configured to encapsulate a service message corresponding to the application in response to an access operation to the application, thereby obtaining an encrypted message. The encrypted message includes the service message, an encrypted tunnel header, and a first message header encapsulated on the outer layer of the encrypted tunnel header. The first message header includes the application identifier.

[0045] The sending unit is used to send the encrypted message to the network device.

[0046] In some implementations, the first message header includes a TCP header, the TCP header includes TCP options, and the TCP options include the application identifier.

[0047] In some implementations, the first header includes an IP header, the IP header includes a DSCP field, and the DSCP field includes the application identifier.

[0048] In some implementations, the acquisition unit is configured to receive the application identifier from the zero-trust SDP controller during the authorization process after the identity authentication initiated by the zero-trust SDP client to the zero-trust SDP controller is successful.

[0049] Sixthly, a network device is provided, comprising:

[0050] The receiving unit is configured to receive encrypted messages from a zero-trust SDP client, the encrypted messages including an encrypted tunnel header and a first message header encapsulated on the outer layer of the encrypted tunnel header, the first message header including the application identifier;

[0051] The acquisition unit is used to acquire the experience guarantee strategy corresponding to the application identifier;

[0052] The processing unit is used to execute the experience protection policy on the encrypted message.

[0053] In some implementations, the acquisition unit is configured to receive the application identifier and the experience guarantee policy from the network controller.

[0054] In some embodiments, the network device further includes a sending unit for sending the application identifier, the stream identifier of the data stream, and the transmission rate of the data stream to the network controller.

[0055] In some implementations, the first header includes a TCP header, the TCP header includes TCP options, and the TCP options include the application identifier.

[0056] In some implementations, the first header includes an IP header, the IP header includes a DSCP field, and the DSCP field includes the application identifier.

[0057] Seventhly, a zero-trust SDP controller is provided, comprising:

[0058] The acquisition unit is used to acquire the application identifier of the application in response to the registration operation of the application;

[0059] The sending unit is used to send the application identifier to the network controller; after the zero-trust SDP controller authenticates the zero-trust SDP client, the application identifier is sent to the zero-trust SDP client during the authorization process.

[0060] In some implementations, the sending unit is configured to send an HTTPS message to the network controller, the HTTPS message including the application identifier.

[0061] Eighthly, a network controller is provided, comprising:

[0062] The receiving unit is used to receive the application identifier from the zero-trust SDP controller;

[0063] The processing unit is used to determine the experience guarantee strategy corresponding to the application identifier;

[0064] The sending unit is used to send the application identifier and the experience guarantee policy to the network device.

[0065] In some implementations, the receiving unit is further configured to receive the application identifier, the stream identifier of the data stream, and the transmission rate of the data stream from the network device;

[0066] The processing unit is used to determine the experience guarantee strategy based on the stream identifier of the data stream and the transmission rate of the data stream;

[0067] The processing unit is also used to present the user with the application's experience information, which includes the stream identifier of the data stream, the transmission rate of the data stream, and the experience guarantee strategy.

[0068] A ninth aspect provides a zero-trust SDP client, comprising a processor coupled to a memory storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by the processor to enable the zero-trust SDP client to implement the method provided by the first aspect or any alternative method of the first aspect. Specific details of the zero-trust SDP client provided in the ninth aspect can be found in the first aspect or any alternative method of the first aspect, and will not be repeated here.

[0069] A tenth aspect provides a network device including a processor coupled to a memory storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by the processor to enable the network device to implement the method provided in the second aspect or any alternative embodiment of the second aspect described above. Specific details of the network device provided in the tenth aspect can be found in the second aspect or any alternative embodiment of the second aspect described above, and will not be repeated here.

[0070] Eleventhly, a zero-trust SDP controller is provided, comprising a processor coupled to a memory storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by the processor to enable the zero-trust SDP controller to implement the method provided by the third aspect or any alternative embodiment of the third aspect. Specific details of the zero-trust SDP controller provided in the eleventh aspect can be found in the third aspect or any alternative embodiment of the third aspect, and will not be repeated here.

[0071] In a twelfth aspect, a network controller is provided, comprising a processor coupled to a memory storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by the processor to cause the network controller to implement the method provided in the fourth aspect or any alternative embodiment of the fourth aspect. Specific details of the network controller provided in the twelfth aspect can be found in the fourth aspect or any alternative embodiment of the fourth aspect, and will not be repeated here.

[0072] In a thirteenth aspect, a computer-readable storage medium is provided, the storage medium storing at least one instruction that, when executed on a computer, causes the computer to perform the method provided in the first aspect or any alternative method of the first aspect.

[0073] In a fourteenth aspect, a computer-readable storage medium is provided, the storage medium storing at least one instruction that, when executed on a computer, causes the computer to perform the method provided in the second aspect or any alternative method of the second aspect.

[0074] In a fifteenth aspect, a computer-readable storage medium is provided, the storage medium storing at least one instruction that, when executed on a computer, causes the computer to perform the method provided in the third aspect or any alternative method of the third aspect.

[0075] In a sixteenth aspect, a computer-readable storage medium is provided, the storage medium storing at least one instruction that, when executed on a computer, causes the computer to perform the method provided in the fourth aspect or any alternative method of the fourth aspect.

[0076] In a seventeenth aspect, a computer program product is provided, the computer program product comprising one or more computer program instructions, which, when loaded and run by a computer, cause the computer to perform the method provided by the first aspect or any alternative method of the first aspect.

[0077] In an eighteenth aspect, a computer program product is provided, the computer program product comprising one or more computer program instructions that, when loaded and run by a computer, cause the computer to perform the method provided in the second aspect or any alternative method of the second aspect.

[0078] In a nineteenth aspect, a computer program product is provided, the computer program product comprising one or more computer program instructions that, when loaded and run by a computer, cause the computer to perform the method provided in the third aspect or any alternative method of the third aspect.

[0079] In a twentieth aspect, a computer program product is provided, the computer program product comprising one or more computer program instructions, which, when loaded and run by a computer, cause the computer to perform the method provided in the fourth aspect or any alternative method of the fourth aspect.

[0080] In a twenty-first aspect, a chip is provided, including a memory and a processor, the memory for storing computer instructions, and the processor for calling and executing the computer instructions from the memory to perform the methods described in the first aspect and any possible implementation thereof.

[0081] In a twenty-second aspect, a chip is provided, including a memory and a processor, the memory for storing computer instructions, and the processor for calling and executing the computer instructions from the memory to perform the methods of the second aspect described above and any possible implementation thereof.

[0082] In a twentieth aspect, a chip is provided, including a memory and a processor, the memory for storing computer instructions, and the processor for calling and executing the computer instructions from the memory to perform the methods of the third aspect described above and any possible implementation thereof.

[0083] In a twentieth aspect, a chip is provided, including a memory and a processor, the memory for storing computer instructions, and the processor for calling and executing the computer instructions from the memory to perform the methods of the fourth aspect described above and any possible implementation thereof.

[0084] In a twenty-fifth aspect, a network system is provided, comprising a zero-trust SDP client as described in the fifth aspect or any alternative of the fifth aspect, a network device as described in the sixth aspect or any alternative of the sixth aspect, a zero-trust SDP controller as described in the seventh aspect or any alternative of the seventh aspect, and a network controller as described in the eighth aspect or any alternative of the eighth aspect. Attached Figure Description

[0085] Figure 1 is a schematic diagram of the architecture of a network system provided in an embodiment of this application;

[0086] Figure 2 is a flowchart of an application access method provided in an embodiment of this application;

[0087] Figure 3 is a schematic diagram of the process of a zero-trust SDP controller synchronizing application information to a network controller according to an embodiment of this application;

[0088] Figure 4 is a flowchart of a method for ensuring application experience according to an embodiment of this application;

[0089] Figure 5 is a schematic diagram of a TCP header format carrying an application identifier provided in an embodiment of this application;

[0090] Figure 6 is a schematic diagram of the structure of a zero-trust SDP client provided in an embodiment of this application;

[0091] Figure 7 is a schematic diagram of the structure of a network device provided in an embodiment of this application;

[0092] Figure 8 is a schematic diagram of the structure of a zero-trust SDP controller provided in an embodiment of this application;

[0093] Figure 9 is a schematic diagram of the structure of a network controller provided in an embodiment of this application;

[0094] Figure 10 is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0095] This application's embodiments apply to scenarios where application experience assurance technology is implemented under a zero-trust SDP architecture. In a zero-trust SDP architecture, service packets sent from a service client to an application are transmitted through an encrypted tunnel between the zero-trust SDP client and the zero-trust SDP gateway, thereby improving the security of service packet transmission. When a network device traversed by the encrypted tunnel receives a packet from the zero-trust SDP client, the network device needs to identify the application to which the packet is intended in order to ensure application experience. However, since the packet received by the network device is an encrypted packet encapsulated with an encrypted tunnel header, the application information is encapsulated within the encrypted tunnel header and is invisible to the network device. This makes it difficult for the network device to identify the application, thus making it challenging to ensure application experience.

[0096] In view of this, in the embodiments of this application, the Zero Trust SDP client encapsulates an application identifier on the outer layer of the encrypted tunnel header during the process of encapsulating the encrypted tunnel header into the service message. This enables the network device through which the encrypted tunnel passes to obtain the application identifier from the outer layer of the encrypted tunnel header in the received message when it receives the message from the Zero Trust SDP client. This allows the network device to obtain the application identifier without decrypting the message. Based on the application identifier, the network device can identify the application to which the message is to be sent, thereby reducing the difficulty for the network device to identify the application and thus reducing the difficulty for the network device to ensure the application experience.

[0097] The following explains some terms and concepts involved in the embodiments of this application.

[0098] (1) Zero Trust SDP

[0099] SDP is a network architecture that provides security protection. SDP transforms the traditional "access first, authentication later" approach into an "authentication first, admission later" approach. Access requests from external networks must first pass identity or device authentication before authorized users can access internal network applications, thereby reducing the risk of unauthorized access. In the SDP specification, the overall architecture consists of three parts: the SDP initiating host (SDP client), the SDP controller, and the SDP receiving host (SDP gateway). SDP adopts a control plane and data plane separation architecture. The control plane mainly involves the interaction of control commands between the SDP controller and various components, while the data plane mainly involves the encrypted channels required for business data transmission.

[0100] When a Zero Trust SDP client accesses an application, it uses the application access message as the payload, encapsulates it with an encrypted tunnel header, and obtains a data packet containing the encrypted tunnel header. The encrypted tunnel header, for example, is a Hypertext Transfer Protocol Secure (HTTPS) tunnel header, used to establish an encrypted tunnel between the Zero Trust SDP client and the Zero Trust SDP gateway. The data packet sent by the Zero Trust SDP client reaches a network device such as a switch, which forwards the data packet to the Zero Trust SDP gateway. The Zero Trust SDP gateway decapsulates the encrypted tunnel header and forwards the packet to the corresponding application based on the destination IP address in the inner packet.

[0101] (2) Application identifier (APP ID)

[0102] An application identifier is used to identify the corresponding application. The application identified by the application identifier is the application that the Zero Trust SDP mechanism needs to manage. Messages from the application identified by the application identifier need to be forwarded to the application through an encrypted tunnel between the Zero Trust SDP client and the SDP gateway. The application identifier can be, for example, a combination of any one or more of letters, numbers, and symbols. In some implementations, the application identifier is unique; that is, there is a one-to-one relationship between the application identifier and the application. Each application has one and only one application identifier, and different applications have different application identifiers. In some implementations, the application identifier is immutable.

[0103] (3) Network applications (hereinafter referred to as applications)

[0104] A web application is an application accessed remotely via a network. It is also called the accessed object or the accessed resource. For example, applications can be based on a client / server (C / S) architecture or a browser / server (B / S) architecture. Examples include World Wide Web (web) applications, email applications, file storage and sharing applications, remote desktop applications, and instant messaging applications.

[0105] The following is an example illustrating the system architecture used in the embodiments of this application.

[0106] Please refer to Figure 1, which is a schematic diagram of the architecture of a network system 100 provided in an embodiment of this application. The system 100 shown in Figure 1 can provide an application experience guarantee system based on network and security collaboration. The network system 100 shown in Figure 1 includes a terminal 110, a network device 120, a zero-trust SDP controller 130, a network controller 140, a server 150, and a zero-trust SDP gateway 160.

[0107] Terminal 110 runs a zero-trust SDP client and one or more service clients. The service clients are used to generate service packets destined for network applications. The service client is software installed and running on terminal 110. For example, in a B / S architecture, the service client is browser software. In a C / S architecture, the service client is client software. The zero-trust SDP client is used to establish an encrypted tunnel with the zero-trust SDP gateway 160. When a service client sends a service packet to an application, the zero-trust SDP client intercepts the service packet, encapsulates it with an encrypted tunnel header and a packet header carrying the application identifier, thus obtaining an encrypted packet.

[0108] Network device 120 includes, but is not limited to, firewalls, gateway devices, switches, or routers. For example, network device 120 includes access switch 121, aggregation switch 122, or core switch 123. Network device 120 is used to forward encrypted packets from zero-trust SDP clients to zero-trust SDP gateway 160. During the forwarding of encrypted packets, network device 120 can ensure application experience through the method provided in this application embodiment.

[0109] The Zero Trust SDP controller 130 manages and controls security protection functions, such as those involved in the Zero Trust SDP mechanism. The network controller 140 manages and controls network forwarding functions, such as those involved in application experience assurance.

[0110] Server 150 runs a network application (hereinafter referred to as the application).

[0111] Based on the architecture shown in Figure 1, network device 120, network controller 140, zero-trust SDP client, zero-trust SDP gateway 160, and zero-trust SDP controller 130 work together by executing the method shown in Figure 2, thereby jointly ensuring the application experience based on network and security collaboration.

[0112] In some implementations, the Zero Trust SDP controller 130 and the network controller 140 are co-located, integrated into the same hardware device. For example, in the case where the network and security are managed by the same hardware device, the hardware device implements the functions of both the Zero Trust SDP controller 130 and the network controller 140.

[0113] In other embodiments, the zero-trust SDP controller 130 and the network controller 140 are implemented separately, with the zero-trust SDP controller 130 and the network controller 140 located in different hardware devices that are mutually coupled.

[0114] The following section, with reference to the corresponding flowchart, provides a detailed explanation of the solution provided in this application.

[0115] Figure 2 is a flowchart of an application access method provided in an embodiment of this application.

[0116] The method shown in Figure 2 is applied, for example, to zero-trust access solutions across campus networks, wide area networks, or the Internet. In some embodiments, the method shown in Figure 2 is applied to the system shown in Figure 1. For example, in the method shown in Figure 2, the zero-trust SDP client is located at terminal 110 in Figure 1; the network device in the method shown in Figure 2 is network device 120 in Figure 1; the network device in the method shown in Figure 2 is any one of switch 121, aggregation switch 122, or core switch 123 in Figure 1; the zero-trust SDP controller in the method shown in Figure 2 is zero-trust SDP controller 130 in Figure 1; the network controller in the method shown in Figure 2 is network controller 140 in Figure 1; the application in the method shown in Figure 2 is located at server 150 in Figure 1; and the zero-trust SDP gateway in the method shown in Figure 2 is zero-trust SDP gateway 160 in Figure 1. The method shown in Figure 2 includes steps S210 to S280.

[0117] In step S210, the administrator registers the application with the Zero Trust SDP controller. In response to the registration operation of the application, the Zero Trust SDP controller obtains the application identifier.

[0118] The data source for application identification includes various scenarios, and two examples are given below.

[0119] Scenario 1: The application identifier comes from the administrator's input.

[0120] For example, when an administrator registers an application that needs to be protected by the Zero Trust SDP mechanism on the Zero Trust SDP controller, the administrator enters the application information during the registration process. The application information includes the application name, application IP address, application transport layer protocol identifier, application port number, and application identifier.

[0121] In some implementations, the Zero Trust SDP controller also verifies the uniqueness of application identifiers. For example, after an administrator enters the identifier for application A, the Zero Trust SDP controller compares the identifier for application A with each previously registered application identifier. If the identifier for application A is the same as any previously registered application identifier, an error message is output to prompt the administrator to re-enter the application identifier, thereby preventing duplicate application identifiers.

[0122] Scenario 2: The application identifier is automatically generated by the zero-trust SDP controller.

[0123] For example, the Zero Trust SDP controller uses hash algorithms, preset rules, timestamps, and other methods to generate a string of random numbers based on the application's information as an application identifier.

[0124] In some implementations, when an administrator registers an application on the Zero Trust SDP controller, they also configure a list of accounts corresponding to that application. This list includes at least one account with permission to access the application. The Zero Trust SDP controller maintains the mapping between the account list and the application's information to control which accounts receive the application's information.

[0125] In step S220, the Zero Trust SDP controller sends an application identifier to the network controller. Correspondingly, the network controller receives the application identifier from the Zero Trust SDP controller. The application identifier is used by the network controller to issue experience guarantee policies.

[0126] The Zero Trust SDP controller synchronizes application identifiers with the network controller by sending application identifiers to the network controller. In some implementations, the Zero Trust SDP controller also sends application information beyond the application identifier to the network controller, such as the application name, the application's Internet Protocol (IP) address, the application's Transport Layer Protocol (TLS) identifier, and the application's port number. This allows the network controller to display application information such as the application name, IP address, TLS identifier, and port number on the interface, and enables collaboration of application information between the Zero Trust SDP controller and the network controller.

[0127] In steps S210 and S220 above, the application identifier may be one application identifier or multiple application identifiers. For example, in a scenario where multiple applications are registered simultaneously, the zero-trust SDP controller synchronizes the application identifier of each application to the network controller.

[0128] When the zero-trust SDP controller and network controller are implemented in a co-located manner, step S220 is implemented, for example, through communication between different components within the device. For instance, the zero-trust SDP controller sends the application identifier to the network controller via an inter-process communication (IPC) protocol. When the zero-trust SDP controller and network controller are implemented in a separate manner, step S220 is implemented, for instance, through network communication between different devices.

[0129] In step S230, the Zero Trust SDP client responds to the login operation by initiating identity authentication to the Zero Trust SDP controller, and the Zero Trust SDP controller performs identity authentication on the Zero Trust SDP client.

[0130] For example, a Zero Trust SDP client presents a login authentication interface. The user initiates a login operation on this interface, entering their username and password. In response to the login operation, the Zero Trust SDP client sends an authentication request to the Zero Trust SDP controller, carrying the username and password. The Zero Trust SDP controller receives the authentication request, retrieves the username and password from it, and performs authentication on the Zero Trust SDP client based on the username and password to verify the user's legitimacy.

[0131] Step S230 is also known as the Zero Trust SDP authentication process. In some implementations, before executing step S230, the Zero Trust SDP client initiates a single packet authorization (SPA) authentication with the Zero Trust SDP controller. After the single packet SPA authentication is successful, the Zero Trust SDP controller sends the login authentication interface content to the Zero Trust SDP client, and the Zero Trust SDP client presents the login authentication interface based on the login authentication interface content.

[0132] In step S232, after the Zero Trust SDP client is successfully authenticated, the Zero Trust SDP controller sends an application list to the Zero Trust SDP client during the authorization process, and the Zero Trust SDP client receives the application list accordingly.

[0133] The application list includes information about one or more applications that a user has permission to access. Each application's information includes its application identifier. The application list is equivalent to a whitelist, instructing Zero Trust SDP clients to encapsulate encrypted tunnel headers in service messages destined for any application in the list. By sending the application list to Zero Trust SDP clients, the Zero Trust SDP controller enables the clients to know which applications' service messages require encrypted tunnel headers and the first message header.

[0134] In some implementations, the Zero Trust SDP controller sends application information to the Zero Trust SDP client that includes other dimensions of application information besides the application identifier, such as the application's IP address, application name, application's transport layer protocol identifier, and application's port number.

[0135] After the Zero Trust SDP client is successfully authenticated, the Zero Trust SDP controller can determine that the user of the Zero Trust SDP client is a legitimate user. The Zero Trust SDP controller enables the user to access the application through the Zero Trust SDP client by sending application information to the Zero Trust SDP client.

[0136] The process of the Zero Trust SDP controller sending application information to the Zero Trust SDP client is part of the authorization process within the Zero Trust SDP architecture. In some implementations, the Zero Trust SDP controller looks up the correspondence between the account list and application information based on the account logged into the Zero Trust SDP client, thereby determining the applications that the logged-in account has permission to access. The Zero Trust SDP controller then sends the application information that the account has permission to access to the Zero Trust SDP client.

[0137] In step S240, in response to the access operation to the application, the zero-trust SDP client encapsulates the business message corresponding to the application to obtain an encrypted message.

[0138] The encrypted message includes a business message, an encrypted tunnel header, and a first message header. The first message header includes the identifier of the application to be accessed. The first message header is encapsulated outside the encrypted tunnel header. The encrypted tunnel header is encapsulated outside the business message. The encrypted tunnel header is, for example, a Hypertext Transfer Protocol Secure (HTTPS) tunnel header. For example, a zero-trust SDP client generates an encrypted tunnel header and a first message header. The zero-trust SDP client uses the business message from the business client accessing the application as the payload, encapsulates the encrypted tunnel header outside the business message, and encapsulates the first message header outside the encrypted tunnel header.

[0139] The encrypted tunnel header is used to establish an encrypted tunnel between the Zero Trust SDP client and the Zero Trust SDP gateway. The source IP address in the encrypted tunnel header is the IP address of the Zero Trust SDP client, and the destination IP address in the encrypted tunnel header is the IP address of the Zero Trust SDP gateway.

[0140] A business message includes the business data to be sent to the application and a message header encapsulated within the business data. For example, a business message might be an access request message sent by a business client to an application. The message header includes the application's IP address, the application's transport layer protocol identifier, and the application's port number.

[0141] Regarding the triggering conditions for encapsulating service packets by the Zero Trust SDP client, in some implementations, after a user triggers an access operation on an application, the Zero Trust SDP client compares the information of the application to be accessed with the application information received from the Zero Trust SDP controller in step S232. If the information of the application to be accessed matches the application information received from the Zero Trust SDP controller in step S232, it indicates that the application to be accessed needs to be managed through the Zero Trust SDP mechanism. In this case, the Zero Trust SDP client performs the encapsulation process of step S240 on the service packets sent to the application to be accessed, enabling the service packets to be forwarded to the Zero Trust gateway through an encrypted tunnel. If the information of the application to be accessed does not match the application information received from the Zero Trust SDP controller in step S232, it indicates that the application to be accessed is not an application that needs to be managed through the Zero Trust SDP mechanism. In this case, the Zero Trust SDP client does not need to perform the encapsulation process of step S240 on the service packets sent to the application to be accessed.

[0142] As an example, a service client generates a service message, and a zero-trust SDP client intercepts the service message generated by the service client at the network interface card (NIC) driver layer. The zero-trust SDP client obtains application information (such as the application's IP address, transport layer protocol identifier, and port number) from the header of the service message. The zero-trust SDP client compares the application information obtained from the service message with the application information received from the zero-trust SDP controller in step S232, thereby triggering step S240.

[0143] In some implementations, the zero-trust SDP client encapsulates an encrypted tunnel header and a first header into each service packet destined for an application. This ensures that the outer layer of the encrypted tunnel header in each encrypted packet includes an application identifier, enabling the network device to identify the corresponding application based on the application identifier in the first header of each received encrypted packet. In other implementations, the zero-trust SDP client encapsulates an encrypted tunnel header and a first header into the first service packet in a data stream destined for an application. Subsequent service packets in a data stream encapsulate encrypted tunnel headers but do not require the first header. The network device determines the application identification result of subsequent service packets based on the data stream to which they belong and the application identification result of the first service packet.

[0144] In step S250, the zero-trust SDP client sends an encrypted message to the network device, and correspondingly, the network device receives the encrypted message from the zero-trust SDP client. The encrypted message includes an encrypted tunnel header and a first message header encapsulated outside the encrypted tunnel header. The first message header includes an application identifier, which the network device obtains from the application identifier in the first message header outside the encrypted tunnel header.

[0145] Step S260: The network device obtains the experience guarantee policy corresponding to the application identifier.

[0146] For example, network devices maintain a mapping between application identifiers and experience guarantee policies. After obtaining the application identifier from an encrypted message, the network device uses the application identifier to look up the mapping between the application identifier and the experience guarantee policy, thereby obtaining the experience guarantee policy corresponding to the application identifier.

[0147] In step S270, the network device executes the experience guarantee policy on the encrypted message and sends the encrypted message to the zero-trust SDP gateway, and the zero-trust SDP gateway receives the encrypted message.

[0148] As an example of implementing an experience assurance policy, this policy includes a target priority. Network devices modify the original priority carried in the priority field of encrypted packets to the target priority specified in the policy. This allows encrypted packets to be scheduled or forwarded according to the modified target priority, thereby managing application data flow and ensuring a good user experience. Modifying the priority of encrypted packets can also be called packet remarking. For example, modifying the priority of encrypted packets can be achieved by remarking the 802.1p value in Virtual Local Area Network (VLAN) packets or remarking the Differentiated Services Code Point (DSCP) value in IP packets. Another example is that the experience assurance policy includes the identifier of a target network slice; network devices send encrypted packets through the target network slice indicated by the policy.

[0149] In some implementations, during the forwarding of encrypted packets from the zero-trust SDP client to the zero-trust SDP gateway through an encrypted tunnel, each network device traversed by the encrypted tunnel performs steps S250 to S270, which are the steps the network device is responsible for executing. This ensures that each network device can identify the application, thereby guaranteeing application experience. For example, in Figure 1, the access switch, aggregation switch, and core switch all perform steps S250 to S270 on the encrypted packets. In other implementations, the access layer network device (e.g., an access switch or access router) communicating with the zero-trust SDP client is responsible for performing steps S250 to S270, enabling the access layer network device to identify the application and thus guaranteeing application experience. This embodiment does not limit which network device the encrypted tunnel traversed is responsible for performing the application identification based on the application identifier to guarantee application experience.

[0150] In step S280, the zero-trust SDP gateway decrypts the encrypted message to obtain the service message. The zero-trust SDP gateway then forwards the message to the application.

[0151] In some implementations, the zero-trust SDP gateway performs a trusted verification on the encrypted message based on the encrypted tunnel header within the encrypted message. After the encrypted message passes the trusted verification, the zero-trust SDP gateway decapsulates the encrypted tunnel header to obtain the service message inside the encrypted tunnel header. The zero-trust SDP gateway then forwards the message to the application according to the application address in the service message.

[0152] Regarding the decapsulation process of the first header containing the application identifier, in some implementations, the zero-trust SDP gateway decapsulates the first header containing the application identifier while decapsulating the encrypted tunnel header from the encrypted packet. In other implementations, after obtaining the application identifier from the first header in the encrypted packet, the last-hop network device in the encrypted tunnel decapsulates the first header in the encrypted packet and sends the decapsulated encrypted packet to the zero-trust SDP gateway.

[0153] The method provided in this embodiment allows the zero-trust SDP client to further encapsulate an application identifier into the outer layer of the encrypted tunnel header during the process of encapsulating the encrypted tunnel header into the service message. This enables the network device, upon receiving the encrypted message and traversing the encrypted tunnel, to obtain the application identifier from the outer layer of the encrypted tunnel header. This allows the network device to obtain the application identifier without decrypting the message. Based on the application identifier, the network device can identify the application to which the message is destined, thus reducing the difficulty of application identification and consequently lowering the difficulty of ensuring application experience. Furthermore, the network device does not need to configure a separate application identification card to identify applications, reducing deployment costs.

[0154] The embodiment shown in Figure 2 above describes the overall process from application registration to the zero-trust SDP client sending the message destined for the application to the zero-trust SDP gateway. The implementation details of steps S210 to S220 in the embodiment shown in Figure 2 are illustrated below.

[0155] Please refer to Figure 3, which is a schematic diagram of the process of synchronizing application information (including application identifier) ​​from the zero-trust SDP controller to the network controller according to the embodiment of this application. The embodiment shown in Figure 3 includes the following steps.

[0156] Step S211: The administrator registers application information on the Zero Trust SDP controller. The application information includes the application identifier.

[0157] Step S221: The Zero Trust SDP controller calls the HTTPS interface provided by the network controller, thereby the network controller announces the information of the newly added application. Correspondingly, the network controller receives the information of the newly added application through the HTTPS interface, saves the information of the newly added application, and the information of the newly added application includes the application identifier.

[0158] Step S222: The network controller confirms the information of the newly added application, which includes the application identifier.

[0159] For example, the Zero Trust SDP controller generates an HTTPS message based on application information. This HTTPS message includes application information, including an application identifier. The Zero Trust SDP controller then sends the HTTPS message to the network controller. Correspondingly, the network controller receives the HTTPS message and obtains the application information carried within it. For instance, the application layer payload in the HTTPS message includes application information, including an application identifier.

[0160] Step S223: The Zero Trust SDP controller calls the HTTPS interface provided by the network controller to notify the network controller of the information of the deleted application. Correspondingly, the network controller receives the information of the deleted application through the HTTPS interface and deletes the application from the local machine. The information of the deleted application includes the application identifier.

[0161] For example, when an application no longer needs to be managed through the Zero Trust SDP mechanism—such as when the application's lifecycle ends and users no longer need to use it—the application's information becomes redundant for the Zero Trust SDP controller. Therefore, the Zero Trust SDP controller deletes the locally stored application information. Furthermore, the Zero Trust SDP controller notifies the network controller to delete the application's information to ensure synchronization of application information between the network controller and the Zero Trust SDP controller.

[0162] Step S224: The network controller confirms the deletion of application information (including application identifier).

[0163] The method provided in this embodiment enables the Zero Trust SDP controller to add and delete applications by calling the HTTPS interface of the network controller. This ensures that the application information on the Zero Trust controller and the network controller is consistent, avoiding the risk that the Zero Trust SDP controller cannot send the application identifier that needs to be guaranteed to the Zero Trust SDP client because it does not store the application identifier that needs to be guaranteed. Consequently, the application identifier cannot be encapsulated in the outer layer of the encrypted tunnel header, which could lead to the failure of application experience guarantee for network devices.

[0164] The implementation details of step S260 in the embodiment shown in Figure 2 are illustrated below.

[0165] For example, please refer to Figure 4, which is a flowchart of a method for ensuring application experience provided by an embodiment of this application. The method shown in Figure 4 includes the following steps.

[0166] Step S202: The administrator enables the application visibility function on the network controller.

[0167] Enabling the application visibility function triggers the network controller to subsequently display the application's experience information in the interface and execute the following step S204.

[0168] In step S204, the network controller sends an application identification command to the network device. The application identification command is used to instruct the network device to extract the application identifier from the first header of the received encrypted message to identify the application. Correspondingly, the network device receives the application identification command.

[0169] Since the network controller sends an application identification command to the network device, thereby enabling the network device to identify the application based on the application identifier in the first packet header, when the network device executes step S250 in the method shown in Figure 2, when it receives an encrypted packet from the zero-trust SDP client, it will extract the application identifier from the first packet header of the encrypted packet and then execute steps S260 and S270.

[0170] In particular, when there are many network devices that need to perform application experience protection, the controller can send an application identification command to each network device that needs to perform application experience protection, thereby enabling the network devices to identify applications based on the application identifier in the first packet header in batches. This is more efficient than the method of the administrator to input the application identification command to each network device that needs to perform application experience protection individually.

[0171] In step S250, the network device receives an encrypted message from a zero-trust SDP client. The encrypted message includes an encrypted tunnel header and a first message header encapsulated outside the encrypted tunnel header. The first message header includes an application identifier.

[0172] In step S261, the network device obtains the application identifier, the flow identifier of the data stream, and the transmission rate of the data stream based on the encrypted message.

[0173] A flow identifier is used to identify the corresponding data flow. The flow identifier of a data flow is, for example, a 5-tuple. For instance, the flow identifier of a data flow includes the source IP address, source port number, destination IP address, destination port number, and transport layer protocol identifier. The source IP address of the data flow is, for example, the IP address of a zero-trust SDP client; the source port number is, for example, the port number of the zero-trust SDP client; the destination IP address is, for example, the IP address of a zero-trust SDP gateway; the destination port number is, for example, the port number of the zero-trust SDP gateway; and the transport layer protocol identifier is, for example, the identifier of the transport layer protocol used for communication between zero-trust SDP clients. Exemplarily, a network device obtains the flow identifier of a data flow from the transport layer protocol header (such as the TCP header) of an encrypted message.

[0174] Data stream transmission quality information includes at least one of the following: data stream transmission rate, data stream transmission delay, or data stream jitter. The data stream transmission rate can also be referred to as the data stream bandwidth. Data stream transmission quality information can be obtained by network devices based on statistics from the same received data stream.

[0175] In step S262, the network device sends an application identifier, a flow identifier of the data stream, and transmission quality information of the data stream to the network controller. Correspondingly, the network controller receives the application identifier, the flow identifier of the data stream, and the transmission quality information of the data stream from the network device.

[0176] Because network devices send application identifiers, flow identifiers of data streams, and data stream transmission quality information to the network controller, the network controller can establish the correspondence between application identifiers, flow identifiers of data streams, and data stream transmission quality information. The network controller can know which subject (indicated by the source IP address) accessed which application (indicated by the application identifier) ​​through the zero-trust SDP gateway, the amount of traffic that subject used to access the application (indicated by the data stream transmission quality information), and whether the subject experienced any lag when accessing the application (indicated by the data stream transmission quality information).

[0177] In some implementations, for the protocol messages upon which network devices send application identifiers, flow identifiers of data flows, and transmission quality information of data flows, the network device generates and sends a management protocol message A to the network controller. Management protocol message A includes the application identifier, flow identifier of the data flow, and transmission quality information of the data flow. Management protocol message A can be, for example, a Network Configuration Protocol (NETCOF) message, a Simple Network Management Protocol (SNMP) message, a Telemetry message, a Representational State Transfer (RESTful) message, or a BGP link-state (BGP-LS) message.

[0178] Regarding the timing of network devices sending application identifiers, flow identifiers of data streams, and data stream transmission quality information, in some implementations, network devices adopt a periodic reporting method, whereby the network controller sends application identifiers, flow identifiers of data streams, and data stream transmission quality information at the end of each time period.

[0179] In step S263, the network controller presents the application's experience information to the administrator.

[0180] Application identifiers, data stream identifiers, and data stream transmission quality information sent by network devices are used to visualize application experience information. For example, the network controller provides an interface to the administrator that includes application experience information, such as data stream identifiers, data stream transmission quality information, and experience assurance policies.

[0181] In step S264, the network controller determines the experience guarantee policy corresponding to the application identifier.

[0182] In some implementations of determining the experience guarantee strategy, when the network device reports the application identifier, the flow identifier of the data stream, and the transmission quality information of the data stream, the network controller determines the experience guarantee strategy based on the application identifier, the flow identifier of the data stream, and the transmission quality information of the data stream. For example, the network controller collects the transmission quality information of multiple data streams corresponding to the same application identifier. The transmission quality information of multiple data streams corresponding to the same application identifier indicates the transmission quality of data streams sent by multiple zero-trust SDP clients to the same application. Based on the transmission quality information of multiple data streams corresponding to the same application identifier, if the network controller determines that the transmission quality of data streams sent by multiple zero-trust SDP clients to the same application does not meet the requirements (e.g., accessing the application generally results in lag), then it determines to enable application experience guarantee for the application identified by the application identifier corresponding to that data stream, and therefore the network controller issues the experience guarantee strategy to the network device.

[0183] In other implementations of the experience protection strategy, the network controller presents an application management interface, where a user triggers a protection operation for an application, and the administrator determines to enable application experience protection for that application.

[0184] In step S265, the network controller sends the application identifier and experience guarantee policy to the network device, and the network device receives the application identifier and experience guarantee policy from the network controller.

[0185] By issuing application identifiers and experience guarantee policies, the network controller effectively informs network devices of the correspondence between application identifiers and experience guarantee policies, enabling network devices to know which experience guarantee policy to use for packets carrying a certain application identifier.

[0186] In some implementations, the network controller generates a management protocol message B and sends it to the network device. The management protocol message B includes the mapping between application identifiers and experience assurance policies, instructing the network device to apply the corresponding experience assurance policy to encrypted messages including application identifiers. The management protocol message B can be, for example, a NETCOF message, an SNMP message, a Telemetry message, a RESTful message, or a BGP-LS message.

[0187] In step S250, the zero-trust SDP client sends an encrypted message to the network device, and correspondingly, the network device receives the encrypted message from the zero-trust SDP client. The encrypted message includes an encrypted tunnel header and a first message header encapsulated outside the encrypted tunnel header. The first message header includes an application identifier.

[0188] Step S260: The network device obtains the experience guarantee policy corresponding to the application identifier.

[0189] For example, the network device compares the application identifier obtained from the encrypted message with the application identifier issued by the network controller. If the application identifier obtained from the encrypted message matches the application identifier issued by the network controller, the network device determines that the experience guarantee policy issued by the network controller should be executed on the encrypted message.

[0190] Step S270: The network device executes an experience protection policy for encrypted messages.

[0191] Step S280: The administrator configures the network controller to stop the application experience guarantee policy from being executed for the application corresponding to the specified application identifier.

[0192] In step S290, the network controller sends a stop command to the network device, which instructs the user experience protection policy to be stopped for the application corresponding to the specified application identifier.

[0193] In step S211, the network device responds to the stop command by stopping the execution of the experience protection policy on encrypted messages carrying the specified application identifier.

[0194] The following examples illustrate the encapsulation format of the message header carrying the application identifier in the embodiments of this application, using two different scenarios.

[0195] Scenario 1: The application identifier is carried in the Transmission Control Protocol (TCP) header.

[0196] In one scenario, the first header of the encrypted message in the method shown in Figure 2 includes a TCP header, which includes TCP options, and the TCP options include an application identifier. For example, the TCP extended options include an application identifier.

[0197] For example, please refer to Figure 5, which is a schematic diagram of a TCP header format carrying an application identifier provided in an embodiment of this application. The TCP header includes a source port number field, a destination port number field, a sequence number field, a checksum field, other options fields, and TCP extension options. The TCP extension options are extended by 20 bytes, which are used to fill in the application identifier.

[0198] Because TCP options reserve a relatively large number of bits, they are easily expandable. Carrying an application identifier through TCP options allows the application identifier to occupy more bits (i.e., the application identifier can be longer), thus making it more unique. Especially when there are a large number of applications requiring guaranteed user experience, the m-bit application identifier in the TCP options can identify 2... m The application is relatively usable.

[0199] Scenario 2: The application identifier is carried in the IP header.

[0200] In scenario two, the first header of the encrypted message in the method shown in Figure 2 includes an IP header. The IP header is, for example, an Internet Protocol version 4 (IPv4) header. The IP header includes a DSCP field, which contains an application identifier.

[0201] Figure 6 is a schematic diagram of the structure of a zero-trust SDP client 600 provided in an embodiment of this application. The zero-trust SDP client 600 includes an acquisition unit 610, a processing unit 620, and a sending unit 630. In some embodiments, the zero-trust SDP client 600 runs on the terminal 110 in Figure 1. In some embodiments, the acquisition unit 610 is used to execute step S232 in the method shown in Figure 2; the processing unit 620 is used to execute step S240 in the method shown in Figure 2; and the sending unit 630 is used to execute step S230 in the method shown in Figure 2.

[0202] The device embodiment described in Figure 6 is merely illustrative. For example, the division of the units described above is only a logical functional division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. The functional units in the various embodiments of this application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0203] Each unit in the Zero Trust SDP Client 600 is implemented, in whole or in part, through software, hardware, firmware, or any combination thereof.

[0204] The following section, in conjunction with the computer device 500 described later, describes some possible implementation methods for using hardware or software to implement the various functional units in the zero-trust SDP client 600.

[0205] In the case of software implementation, for example, the above-mentioned acquisition unit 610 and processing unit 620 are software functional units generated by at least one processor 501 in Figure 10 after reading the program code stored in memory 502.

[0206] In the case of hardware implementation, for example, the various units described above in Figure 6 are implemented by different hardware components in a computer device. For instance, processing unit 620 is implemented by a portion of the processing resources of at least one processor 501 in Figure 10 (e.g., one or two cores of a multi-core processor), or by a programmable device such as a field-programmable gate array (FPGA) or a coprocessor. Acquisition unit 610 and transmission unit 630 are implemented by network interface 503 in Figure 10.

[0207] Figure 7 is a schematic diagram of the structure of a network device 700 provided in an embodiment of this application, including a receiving unit 710, an acquiring unit 720, and a processing unit 730. In some embodiments, the network device 700 is the network device 120 in Figure 1. For example, the network device 700 is an access switch 121, an aggregation switch 122, or a core switch 123.

[0208] In some embodiments, the receiving unit 710 is used to perform the receiving step in step S250 of the method shown in FIG2. The acquiring unit 720 is used to perform step S260 of the method shown in FIG2; the processing unit 730 is used to perform step S270 of the method shown in FIG2 and step S211 of the method shown in FIG4.

[0209] In some embodiments, the acquisition unit 720 is used to perform steps S261 and S265 in the method shown in FIG4.

[0210] In some embodiments, the network device further includes a transmitting unit 740 for performing step S262.

[0211] The device embodiment described in Figure 7 is merely illustrative. For example, the division of the units described above is only a logical functional division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. The functional units in the various embodiments of this application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0212] Each unit in the network device 700 is implemented, in whole or in part, through software, hardware, firmware, or any combination thereof.

[0213] The following section, in conjunction with the computer device 500 described later, describes some possible implementation methods of the various functional units in the network device 700 using hardware or software.

[0214] In the case of software implementation, for example, the acquisition unit 720 and processing unit 730 described above are software functional units generated by at least one processor 501 in Figure 10 after reading the program code stored in memory 502.

[0215] In the case of hardware implementation, for example, the various units described above in FIG7 are implemented by different hardware in a computer device. For example, processing unit 730 is implemented by a portion of the processing resources of at least one processor 501 in FIG10 (e.g., one or two cores of a multi-core processor), or by a programmable device such as a field-programmable gate array (FPGA) or a coprocessor. Receiving unit 710 and transmitting unit 740 are implemented by network interface 503 in FIG10.

[0216] Figure 8 is a schematic diagram of a zero-trust SDP controller 800 provided in an embodiment of this application, including an acquisition unit 810 and a transmission unit 820. In some embodiments, the zero-trust SDP controller 800 is the zero-trust SDP controller 130 in Figure 1.

[0217] In some embodiments, the acquisition unit 810 is used to execute step S210 in the method shown in FIG2; the sending unit 820 is used to execute step S220 in the method shown in FIG2.

[0218] The device embodiment described in Figure 8 is merely illustrative. For example, the division of the units described above is only a logical functional division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. The functional units in the various embodiments of this application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0219] Each unit in the Zero Trust SDP Controller 800 is implemented, in whole or in part, through software, hardware, firmware, or any combination thereof.

[0220] The following section describes, in conjunction with the computer device 500 described later, some possible implementations of the various functional units in the Zero Trust SDP controller 800 using hardware or software.

[0221] In the case of software implementation, for example, the acquisition unit 810 described above is a software functional unit generated by at least one processor 501 in Figure 10 reading the program code stored in the memory 502.

[0222] In the case of hardware implementation, for example, the various units described above in Figure 8 are implemented by different hardware components in a computer device. For instance, the acquisition unit 810 is implemented by a portion of the processing resources of at least one processor 501 in Figure 10 (e.g., one or two cores of a multi-core processor), or by a programmable device such as a field-programmable gate array (FPGA) or a coprocessor. The transmission unit 820 is implemented by the network interface 503 in Figure 10.

[0223] Figure 9 is a schematic diagram of a network controller 900 provided in an embodiment of this application, including a receiving unit 910, a processing unit 920, and a transmitting unit 930. In some embodiments, the network controller 900 is the network controller 140 in Figure 1.

[0224] The receiving unit 910 is used to execute steps S221 and S223 in the method shown in FIG3 and step S262 in the method shown in FIG4; the processing unit 920 is used to execute steps S222 in the method shown in FIG3, steps S263 and S264 in the method shown in FIG4; and the sending unit 930 is used to execute steps S204, S265 and S290 in the method shown in FIG4.

[0225] The device embodiment described in Figure 9 is merely illustrative. For example, the division of the units described above is only a logical functional division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. The functional units in the various embodiments of this application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0226] Each unit in the network controller 900 is implemented, in whole or in part, through software, hardware, firmware, or any combination thereof.

[0227] The following section describes some possible implementations of the various functional units in the network controller 900 using hardware or software, in conjunction with the computer device 500 described later.

[0228] In the case of software implementation, for example, the processing unit 920 described above is a software functional unit generated by at least one processor 501 in Figure 10 after reading the program code stored in the memory 502.

[0229] In the case of hardware implementation, for example, the various units described above in Figure 9 are implemented by different hardware components in a computer device. For instance, processing unit 920 is implemented by a portion of the processing resources of at least one processor 501 in Figure 10 (e.g., one or two cores of a multi-core processor), or by a programmable device such as a field-programmable gate array (FPGA) or a coprocessor. Receiving unit 910 and transmitting unit 930 are implemented by network interface 503 in Figure 10.

[0230] This application also provides a computer device. For example, Figure 10 is a structural schematic diagram of a computer device 500 provided in this application embodiment.

[0231] Computer device 500 includes at least one processor 501, memory 502 and at least one network interface 503.

[0232] Processor 501 may be, for example, a general-purpose central processing unit (CPU), a network processor (NP), a graphics processing unit (GPU), a neural-network processing unit (NPU), a data processing unit (DPU), a microprocessor, or one or more integrated circuits for implementing the embodiments of this application. For example, processor 501 may include an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. A PLD may be, for example, a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0233] Memory 502 may be, for example, read-only memory (ROM) or other types of static storage devices capable of storing static information and instructions; random access memory (RAM) or other types of dynamic storage devices capable of storing information and instructions; electrically erasable programmable read-only memory (EEPROM); compact disc read-only memory (CD-ROM) or other optical disc storage; optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile optical discs, Blu-ray discs, etc.); magnetic disk storage media or other magnetic storage devices; or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, such as a hard disk drive (HDD) or a solid-state drive (SSD). Optionally, memory 502 exists independently and is connected to processor 501 via internal connection 504. Alternatively, memory 502 and processor 501 may be integrated together.

[0234] Network interface 503 uses a device such as a network interface card or transceiver to communicate with other devices or communication networks. Network interface 503 includes at least one of a wired network interface or a wireless network interface. The wired network interface is, for example, an Ethernet interface. The Ethernet interface is, for example, an optical interface, an electrical interface, or a combination thereof. The wireless network interface is, for example, a wireless local area network (WLAN) interface, a cellular network interface, or a combination thereof.

[0235] In some embodiments, processor 501 includes one or more CPUs, such as CPU0 and CPU1 shown in Figure 10.

[0236] In some embodiments, the computer device 500 may optionally include a plurality of processors, such as processor 501 and processor 505 shown in Figure 10. Each of these processors may be, for example, a single-core processor (single-CPU) or a multi-core processor (multi-CPU). Here, a processor may optionally refer to one or more devices, circuits, and / or processing cores for processing data (such as computer program instructions).

[0237] In some embodiments, the computer device 500 further includes an internal connection 504. The processor 501, memory 502, and at least one network interface 503 are connected via the internal connection 504. The internal connection 504 includes pathways for transmitting information between the aforementioned components. Optionally, the internal connection 504 is a single board or a bus. Optionally, the bus is a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be categorized as an address bus, data bus, control bus, etc. A single board may include, for example, a system backplane or a switching fabric board.

[0238] In some embodiments, the computer device 500 further includes an input / output interface 506. The input / output interface 506 is connected to the internal connection 504.

[0239] Optionally, the processor 501 implements the method in the above embodiments by reading program code stored in the memory 502, or the processor 501 implements the method in the above embodiments by internally stored program code. When the processor 501 implements the method in the above embodiments by reading program code stored in the memory 502, the memory 502 stores program code 510 that implements the method provided in the embodiments of this application.

[0240] For more details on how processor 501 implements the above functions, please refer to the descriptions in the previous method embodiments, which will not be repeated here.

[0241] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0242] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, they 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 program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application 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 website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., a solid-state disk (SSD)).

[0243] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. An application access method, characterized in that, The method includes: Zero-trust SDP clients obtain the application identifier of the application. In response to an access operation to the application, the zero-trust SDP client encapsulates the business message corresponding to the application to obtain an encrypted message. The encrypted message includes the business message, an encrypted tunnel header, and a first message header encapsulated on the outer layer of the encrypted tunnel header. The first message header includes the application identifier. The zero-trust SDP client sends the encrypted message to the network device.

2. The method according to claim 1, characterized in that, The first message header includes a TCP header, the TCP header includes TCP options, and the TCP options include the application identifier.

3. The method according to claim 1, characterized in that, The first message header includes an IP header, the IP header includes a DSCP field, and the DSCP field includes the application identifier.

4. The method according to any one of claims 1 to 3, characterized in that, The zero-trust SDP client obtains the application identifier of the application, including: After the authentication initiated by the Zero Trust SDP client to the Zero Trust SDP controller is successful, during the authorization process, the Zero Trust SDP client receives the application identifier from the Zero Trust SDP controller.

5. A method for ensuring application experience, characterized in that, The method includes: The network device receives an encrypted message from a zero-trust SDP client. The encrypted message includes an encrypted tunnel header and a first message header encapsulated on the outer layer of the encrypted tunnel header. The first message header includes the application identifier. The network device obtains the experience guarantee policy corresponding to the application identifier; The network device executes the experience guarantee policy on the encrypted message.

6. The method according to claim 5, characterized in that, The network device obtains the experience guarantee policy corresponding to the application identifier, including: The network device receives the application identifier and the experience guarantee policy from the network controller.

7. The method according to claim 6, characterized in that, Before the network device receives the application identifier and the experience guarantee policy from the network controller, the method further includes: The network device sends the application identifier, the flow identifier of the data stream, and the transmission rate of the data stream to the network controller.

8. The method according to any one of claims 5 to 7, characterized in that, The first message header includes a TCP header, the TCP header includes TCP options, and the TCP options include the application identifier.

9. The method according to any one of claims 5 to 7, characterized in that, The first message header includes an IP header, the IP header includes a DSCP field, and the DSCP field includes the application identifier.

10. A method for ensuring application experience, characterized in that, The method includes: In response to an application registration operation, the Zero Trust SDP controller obtains the application identifier of the application. The zero-trust SDP controller sends the application identifier to the network controller; After the Zero Trust SDP controller successfully authenticates the Zero Trust SDP client, it sends the application identifier to the Zero Trust SDP client during the authorization process.

11. The method according to claim 10, characterized in that, The zero-trust SDP controller sends the application identifier to the network controller, including: The zero-trust SDP controller sends an HTTPS message to the network controller, the HTTPS message including the application identifier.

12. A method for ensuring application experience, characterized in that, The method includes: The network controller receives the application identifier from the zero-trust SDP controller; The network controller determines the experience guarantee strategy corresponding to the application identifier; The network controller sends the application identifier and the experience guarantee policy to the network device.

13. The method according to claim 12, characterized in that, The network controller determines the experience guarantee policy corresponding to the application identifier, including: The network controller receives the application identifier, the stream identifier of the data stream, and the transmission rate of the data stream from the network device; The network controller determines the experience guarantee strategy based on the flow identifier of the data stream and the transmission rate of the data stream; The method further includes: the network controller presenting the application's experience information to the user, the application's experience information including the stream identifier of the data stream, the transmission rate of the data stream, and the experience guarantee policy.

14. A zero-trust SDP client, characterized in that, include: The acquisition unit is used to acquire the application identifier of the application. A processing unit is configured to encapsulate a service message corresponding to the application in response to an access operation to the application, thereby obtaining an encrypted message. The encrypted message includes the service message, an encrypted tunnel header, and a first message header encapsulated on the outer layer of the encrypted tunnel header. The first message header includes the application identifier. The sending unit is used to send the encrypted message to the network device.

15. A network device, characterized in that, include: The receiving unit is configured to receive encrypted messages from a zero-trust SDP client, the encrypted messages including an encrypted tunnel header and a first message header encapsulated on the outer layer of the encrypted tunnel header, the first message header including the application identifier; The acquisition unit is used to acquire the experience guarantee strategy corresponding to the application identifier; The processing unit is used to execute the experience protection policy on the encrypted message.

16. A zero-trust SDP controller, characterized in that, include: The acquisition unit is used to acquire the application identifier of the application in response to the registration operation of the application; A sending unit is used to send the application identifier to the network controller; After the Zero Trust SDP controller successfully authenticates the Zero Trust SDP client, it sends the application identifier to the Zero Trust SDP client during the authorization process.

17. A network controller, characterized in that, include: The receiving unit is used to receive the application identifier from the zero-trust SDP controller; The processing unit is used to determine the experience guarantee strategy corresponding to the application identifier; The sending unit is used to send the application identifier and the experience guarantee policy to the network device.

18. A computer device, characterized in that, The computer device includes: a processor coupled to a memory, the memory storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by the processor to enable the computer device to implement the method of any one of claims 1-13.

19. A network system, characterized in that, The system includes the zero-trust SDP client as described in claim 14, the network device as described in claim 15, the zero-trust SDP controller as described in claim 16, and the network controller as described in claim 17.

20. A computer-readable storage medium, characterized in that, The storage medium stores at least one instruction, which, when executed on a computer, causes the computer to perform the method as described in any one of claims 1-13.

21. A computer program product, characterized in that, The computer program product includes one or more computer program instructions that, when loaded and run by a computer, cause the computer to perform the method of any one of claims 1-13.

Images