A Cross-Domain Processing Method and System for Application Services

Abstract

The present invention provides a cross - domain processing method and system for application services, which relates to the computer field and is executed under an eBPF program. The method includes: presetting a variable storing the protocol, domain name / host, and port of a backend service; obtaining an access request sent from a frontend service to a backend service; determining whether the access request is a cross - domain access based on the variable; if not, establishing an access link between the frontend service and the backend service according to the access request; if so, performing cross - domain marking on the transmission data packet associated with the access request; obtaining the transmission data packet in the backend service response obtained according to the access request, and determining whether it has a cross - domain marking; if so, modifying the message header parameters in the transmission data packet in the backend service response obtained for the access request, and returning it to the frontend service, thereby establishing an access link between the frontend service and the backend service, so as to solve the problem that the existing cross - domain of application services is complex in operation and consumes more resources by modifying code, protocol, or using a third - party proxy.

Description

Technical Field

[0001] The present invention relates to the field of computers, and in particular to a method and system for cross-domain processing of application services. Background Art

[0002] The "same-origin policy" restriction is the most basic and core security function of the browser. The so-called same-origin (same domain) means that two front-end pages have the same protocol, host and port number. Cross-domain means that any one of the protocol, domain name and port of a request URL is different from the current page URL. However, in actual development projects, a front-end may need to connect to multiple back-ends. At this time, the problem of front-end access cross-domain needs to be solved.

[0003] Most of the existing cross-domain solutions are implemented by modifying the front-end or back-end code, such as cross-domain resource sharing (CORS), cross-domain through jsonp, cross-subdomain by modifying document.domain, using window.name for cross-domain, using HTML5's window.postMessage method for cross-domain, providing an interface proxy on the back-end or directly setting the response header when the back-end returns, etc., all of which require code-level changes; or changing the protocol, such as cross-domain through WebSocket, but the premise is that the server supports the web socket protocol; or through a third-party proxy, such as through nginx reverse proxy, but this method must rely on proxy services, adding a new proxy service on the basis of the original application service system, increasing system complexity and server resource consumption. Summary of the invention

[0004] In order to overcome the above technical defects, the purpose of the present invention is to provide a method and system for cross-domain processing of application services to solve the problem that the existing cross-domain application services are complex to operate and consume a lot of resources by modifying codes, protocols or using third-party agents.

[0005] The present invention discloses a cross-domain processing method for application services, which is executed under an eBPF program and includes:

[0006] Pre-set a variable to store the protocol, domain name / host and port of the backend service;

[0007] Obtaining an access request sent by a front-end service to a back-end service;

[0008] Obtaining the protocol, domain name / host and port of the front-end service according to the message header in the transmission data packet associated with the access request;

[0009] Determining whether the access request is a cross-domain access based on the variable;

[0010] If not, establish an access link between the front-end service and the back-end service according to the access request;

[0011] If so, perform cross-domain marking on the transmission data packet associated with the access request, and request to access the back-end service;

[0012] Obtain the transmission data packet in the back-end service response obtained according to the access request, and determine whether it has a cross-domain mark;

[0013] If so, modify the message header parameters in the transmission data packet in the back-end service response obtained by the access request, and return it to the front-end service, thereby establishing an access link between the front-end service and the back-end service.

[0014] Preferably, the message header parameters in the transmission data packet include: access control allow credentials, access control allow application protocol, access control allow method, access control allow domain name.

[0015] The cross-domain marking of the transmission data packet associated with the access request includes:

[0016] Obtain the transmission data packet associated with the access request, and parse it to obtain an Ethernet frame, a network protocol header, and a transport protocol header;

[0017] Store the new field value corresponding to the cross-domain mark at a preset address accessible by the eBPF program;

[0018] Call a function to search for BPF map table elements, obtain the new field value from the preset address, encode the field value into the format of the protocol header option of the transport protocol, and write it into the transport protocol header to form a transport protocol header with a cross-domain mark;

[0019] Call a function to update the transport protocol header checksum to perform an update check based on the transport protocol header with a cross-domain mark.

[0020] Preferably, the determination of whether there is a cross-domain mark includes:

[0021] Based on the socket buffer, determine whether there is a cross-domain mark in the transmission data packet in the back-end service response obtained by the access request.

[0022] Preferably, the modification of the message header parameters in the transmission data packet in the back-end service response obtained by the access request includes:

[0023] Use the socket buffer to represent the transmission data packet, and after locating the message header parameters in the transmission data packet, modify the message header parameters in the transmission data packet.

[0024] Preferably, an auxiliary function is used to modify the message header parameters in the transmission data packet associated with the access request.

[0025] Preferably, the eBPF program is deployed on an intermediate server between the front-end service and the back-end service.

[0026] Preferably, before obtaining an access request sent from a front-end service to a back-end service, it further includes:

[0027] Pre-compile the eBPF program to trigger the eBPF program according to the access request and load it for execution under the kernel.

[0028] The present invention also provides an application service cross-domain processing system, including an application layer and a kernel; the application layer includes a front-end server and a back-end server, where the front-end server provides a front-end service and the server side provides a back-end service; an eBPF program is loaded under the kernel and executed:

[0029] Pre-set a variable storing the protocol, domain name / host, and port of the back-end service;

[0030] Obtain an access request sent from a front-end service to a back-end service;

[0031] Obtain the protocol, domain name / host, and port of the front-end service according to the message header in the transmission data packet associated with the access request;

[0032] Based on the variable, determine whether the access request is a cross-domain access;

[0033] If not, establish an access link between the front-end service and the back-end service according to the access request;

[0034] If so, perform a cross-domain mark on the transmission data packet associated with the access request and request to access the back-end service;

[0035] Obtain the transmission data packet in the response of the back-end service obtained according to the access request, and determine whether it has a cross-domain mark;

[0036] If so, modify the message header parameters in the transmission data packet in the response of the back-end service obtained for the access request, and return it to the front-end service, thereby establishing an access link between the front-end service and the back-end service.

[0037] Preferably, the eBPF program is deployed on an intermediate server between the front-end service and the back-end service.

[0038] After adopting the above technical solutions, compared with the prior art, it has the following beneficial effects:

[0039] The cross - domain processing method and system provided by this application use eBPF programs to determine whether an access request sent by a front - end service is a cross - domain access. When it is a cross - domain access, the access request is marked. After the access request is sent to the back - end service, the response of the back - end service is obtained. When it is recognized that there is a mark, the message - header parameters in the transmission data packet of the back - end service response obtained for the access request are modified and returned to the front - end service to solve the cross - domain problem. It is processed under the kernel, can be independently deployed, and does not require any code modification to the front - end and back - end application services, and does not require a third - party proxy, solving the problem that the existing cross - domain application services are complex to operate and consume more resources by modifying code, protocols, or using third - party proxies. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 FIG. is a flowchart of the first embodiment of the cross - domain processing method and system for application services according to the present invention;

[0041] Figure 2 FIG. is a flowchart of cross - domain marking of the transmission data packet associated with the access request in the first embodiment of the cross - domain processing method and system for application services according to the present invention;

[0042] Figure 3 FIG. is a schematic structural diagram of the second embodiment of the cross - domain processing method and system for application services according to the present invention.

[0043] Reference Numerals:

[0044] 81 - Application layer; 811 - Front - end server; 812 - Back - end server; 83 - Kernel. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0045] The advantages of the present invention are further elaborated below in conjunction with the accompanying drawings and specific embodiments.

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

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

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

[0049] In the description of the present invention, it should be understood that the orientation or positional relationship indicated by the terms "longitudinal", "transverse", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc. is based on the orientation or positional relationship shown in the drawings, and is only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the present invention.

[0050] In the description of the present invention, unless otherwise specified and limited, it should be noted that the terms "mounted", "connected", and "connected" should be understood in a broad sense. For example, it may be a mechanical connection or an electrical connection, or it may be the communication inside two elements. It may be directly connected, or indirectly connected through an intermediate medium. For those of ordinary skill in the art, the specific meanings of the above terms may be understood according to specific circumstances.

[0051] In the subsequent description, the suffixes such as "module", "component", or "unit" used to represent elements are only for the convenience of describing the present invention, and they do not have a specific meaning in themselves. Therefore, "module" and "component" may be used interchangeably.

[0052] Embodiment 1: This embodiment discloses an application service cross-domain processing method, which is executed under an eBPF program. eBPF is an abbreviation for Extended Berkeley Packet Filter. eBPF can be regarded as a framework that allows users to load and run custom programs in the kernel of an operating system, and can be used to extend or even modify kernel behavior. Therefore, the cross-domain processing method in this embodiment is executed in the kernel, and has the advantages of not requiring code transformation of the original application service, having no invasiveness to the original application service code, having no restrictions on http and https request methods, not requiring replacement of the web protocol, and not requiring additional proxy services (nginx), etc.

[0053] In this embodiment, it is mainly applied to solve the browser cross - domain problem, that is, in a software system with a B / S (Browser / Server) architecture mode. In the B / S architecture mode, the client web browser sends requests to the server. Common modes include: browser - front - end server - load balancer (gateway) - back - end service, or browser - front - end server - back - end service. Therefore, the eBPF program can be deployed on the intermediate server for front - end access to the back - end, such as a gateway or a load - balancing server, that is, the eBPF program can be deployed on the intermediate server between a front - end service and a back - end service, such as a gateway or a load - balancing server.

[0054] It should also be noted that since the cross - domain processing provided in this embodiment depends on the eBPF program, before obtaining the access request sent from a front - end service to a back - end service, it also includes: pre - compiling the eBPF program to trigger the eBPF program according to the access request and load it for execution under the kernel. For example, ① Save the written eBPF program in a file named handle_cross_domain_li.c. ② Use Clang&LLVM or other supported compilers to compile the written ebpf program into BPF bytecode. ③ Load the eBPF program into the kernel: Tools provided in the libbpf library can be used to load the eBPF program into the kernel. For example: The following command can be used to load the eBPF program into the kernel: sudo bpftool prog load handle_cross_domain_li.o / sys / fs / bpf / handle_cross_domain_li, which will load the eBPF program in the handle_cross_domain_li.o file into the kernel and attach it to the / sys / fs / bpf / handle_cross_domain_li path. ④ Load the eBPF program into the kernel, for example, tools provided in the libbpf library can be used to load the eBPF program into the kernel.

[0055] Furthermore, to ensure the smooth call of the eBPF program, after loading the eBPF program into the kernel, check whether the eBPF program is successfully loaded into the kernel according to the program information. Specifically, after the above 4 steps, ⑤ Check whether the eBPF program is successfully loaded, sudo bpftool prog show / sys / fs / bpf / handle_cross_domain_li. If the eBPF program has been successfully loaded into the kernel, information about the program should be displayed. Those skilled in the art should understand that the specific operations of pre - compiling the eBPF program to trigger the eBPF program according to the access request and load it for execution under the kernel are only examples and are not limited.

[0056] Based on the above, the eBPF program has been compiled and loaded into the kernel. Specifically, refer to Figure 1 , the cross-domain processing in this embodiment specifically includes the following:

[0057] First, variables for storing the protocol, domain name / host, and port of a backend service are preset in the eBPF program;

[0058] It should be noted that a variable refers to a container for storing data information and is used to save data. In this implementation, it is necessary to first determine whether it is a cross-domain access request based on the protocol, domain name / host, and port of the front-end service and the back-end service. Therefore, this variable prestores the protocol, domain name / host, and port of the back-end service. Among them, the host can be understood as the host IP address. The content stored in the variable is changeable or dynamically adjustable so as to be changed and adjusted according to the actual request for use in the determination of whether it is a cross-domain access in the following steps.

[0059] S100: Obtain an access request sent from a front-end service to a back-end service;

[0060] In this embodiment, the front-end service and the back-end service can be on the same server or on different servers. Invoking services within the same domain (protocol, domain name / host, port) does not require cross-domain access. That is, if the front-end and back-end codes are deployed to the same server, there will be no cross-domain. However, in actual development projects, a front-end service may need to interface with multiple back-end services. In this case, it is necessary to solve the problem of cross-domain access for the front-end service.

[0061] S200: Obtain the protocol, domain name / host, and port of the front-end service according to the message headers in the transmission data packet associated with the access request;

[0062] In the above step, the protocol, domain name / host, and port of the URL in the message headers (such as HTTPHeader) of the request transmission data packet (such as TCP network data packet, etc.) are compared with the protocol, domain name / host, and port of the back-end service request url prestored in the variable, thereby determining whether the network (access) request is cross-domain. Among them, either the domain name or the host can be selected.

[0063] S300: Determine whether the access request is a cross-domain access based on the variable;

[0064] In the above steps, based on the variable judgment, that is, as described above, compare the protocol, domain name / host, and port of the front-end service with the protocol, domain name / host, and port of the subsequent service pre-stored in the variable. When all three of the protocol, domain name / host, and port are the same for both, it is a non-cross-domain access. When any one of the protocol, domain name / host, and port is inconsistent between the two, it is determined as a cross-domain access at this time. At this time, perform a cross-domain marking on it, and for non-cross-domain, no processing is required and the access link can be directly established.

[0065] S400: If not, establish an access link between the front-end service and the back-end service according to the access request;

[0066] That is, when the access request is judged as non-cross-domain access, the front-end service can directly retrieve the resources of the back-end service through the access link.

[0067] S500: If so, after performing a cross-domain marking on the transmission data packet associated with the access request, request to access the back-end service;

[0068] When the access request is judged as cross-domain access, perform a cross-domain marking on the transmission data packet associated with the access request. Specifically, for the above-mentioned cross-domain marking of the transmission data packet associated with the access request, refer to Figure 2 , including:

[0069] S510: Obtain the transmission data packet associated with the access request and parse it to obtain an Ethernet frame, a network protocol header, and a transport protocol header;

[0070] In the above steps, parse the Ethernet frame, network protocol header (such as an IP header, etc.), and transport protocol header (that is, such as a TCP header, etc., or it can also be other transport protocols) in the transmission data packet. The Ethernet frame is a data packet on the Ethernet link. The IP data packet is transmitted at the network layer and consists of an IP header and IP packet data. The length of the IP header is generally between 20 and 60 bytes. The TCP header is the protocol header of the transport layer (transmission control protocol).

[0071] S520: Store the value of the new field corresponding to the cross-domain marking at a preset address accessible by the eBPF program;

[0072] In the above steps, as an example, the preset address accessible by the ebpf program is a BPF_MAP named cross_domain_map. That is, cross_domain_map is a data structure (key-value structure) of BPF Maps, which is used to store new fields and their corresponding values. In this embodiment, the new field is the above-mentioned cross-domain marking.

[0073] S530: Call the function to search for BPF map elements, obtain the value of the newly added field from the preset address, encode the field value into the format of the protocol header option of the transport protocol, and write it into the transport protocol header to form a transport protocol header with a cross-domain tag;

[0074] In the above steps, by way of example, in the eBPF program, call the function to search for BPF map elements (such as the bpf_map_lookup_elem function, etc.), search for the value (value) corresponding to a specific key (key) in the cross_domain_map, obtain the value in the aforementioned cross_domain_map, and perform encoding and decoding according to the format of the protocol header of the transport protocol. Then, write the newly added field (such as the CrossDomainFlag field, that is, the above-mentioned newly added field, the cross-domain tag) into the transport protocol header (such as the TCP header, etc.), and set the value. Finally, write the modified transport protocol header back into the data packet. Thus, the cross-domain tag is carried in the transport protocol header.

[0075] S540: Call the function to update the transport protocol header checksum to perform an update check based on the transport protocol header with a cross-domain tag.

[0076] In the above steps, use the function to update the transport protocol header checksum (such as the bpf_l4_csum_replace function, etc.) to update the TCP protocol header checksum. Obtain the transport data packet with a cross-domain tag based on the above steps S510 - S540.

[0077] S600: Obtain the transport data packet in the backend service response obtained according to the access request, and determine whether it has a cross-domain tag;

[0078] After the above steps S100 - S500 (i.e., the request process), in the eBPF program, determine whether it is a cross-domain access, and mark the access request for cross-domain access. Then, the access request reaches the backend service, and the backend service processes it, thereby obtaining the transport data packet in the backend service response, and further determining whether it has a cross-domain tag based on the transport data packet in the backend service response.

[0079] Specifically, the determination of whether there is a cross - domain flag includes: determining whether there is a cross - domain flag in the transmission data packet in the backend service response obtained by the access request based on the socket buffer. Specifically, functions provided by the kernel are used to obtain the parameters in the transmission data packet (such as TCP network data packets, etc.) for the processed completed request (i.e., the backend service response). As an example, the socket buffer (such as skb (socket buffer), etc.) structure in the eBPF program can be used to represent the received data packet, and the data structures and functions in skb are used to obtain the parameter content in the transmission data packet to determine whether the above CrossDomainFlag cross - domain flag exists in the transmission data packet.

[0080] S700: If so, modify the message header parameters in the transmission data packet in the backend service response obtained by the access request, and return to the front - end service, thereby establishing an access link between the front - end service and the backend service.

[0081] In this embodiment, the message header parameters in the transmission data packet in the backend service response obtained by the access request are modified to solve the cross - domain problem. Specifically, the modification of the message header parameters in the transmission data packet in the backend service response obtained by the access request includes:

[0082] The transmission data packet is represented by a socket buffer. After locating the message header parameters in the transmission data packet, the message header parameters in the transmission data packet are modified. Specifically, auxiliary functions in the eBPF program can be used to modify the message header parameters in the transmission data packet associated with the access request.

[0083] For example, when it is recognized that the CrossDomainFlag is present in the transmission data packet in the back-end service response, the socket buffer (such as skb, etc.) structure is used to represent the transmission data packet (such as TCP network data packet, etc.) in the received back-end service response, and the data structure and functions in the skb are used to obtain and modify the message header (such as HTTP header, etc.) parameters in the transmission data packet in the back-end service response. Among them, the message header parameters include the following 4 parameters: Access-Control-Allow-Credentials (i.e., access control allows credentials), Access-Control-Allow-Headers (i.e., access control allows application protocols), Access-Control-Allow-Methods (i.e., access control allows methods), and Access-Control-Allow-Origin (i.e., access control allows domain names), that is, the skb is used to modify the above 4 message header parameters. Specifically, as an explanation, Access-Control-Allow-Credentials (i.e., access control allows credentials) is used to determine whether to allow the request to carry authentication information and whether to respond to the request; Access-Control-Allow-Headers (i.e., access control allows application protocols) can be used to determine which HTTP headers can be used in the actual CORS (Cross-Origin Resource Sharing) request; Access-Control-Allow-Methods (i.e., access control allows methods) can be used to determine which HTTP methods are allowed to access the requested resources in the response to the request; Access-Control-Allow-Origin (i.e., access control allows domain names) indicates to which domains the requested resources can be shared.

[0084] Specifically, as an example, the TCP header and data part in the skb can be obtained, and the starting position of the message header (such as the HTTP header) can be found. According to the starting position, after the HTTP header is found, the positions of the message header parameters can be further searched, such as the positions of the Access-Control-Allow-Credentials, Access-Control-Allow-Headers, Access-Control-Allow-Methods, and Access-Control-Allow-Origin parameters, and the above auxiliary functions (such as the bpf_probe_write_user() and skb_store_bits() functions, etc.) are used to modify them. Preferably, they are modified to the following new values:

[0085] Access-Control-Allow-Credentials: true

[0086] Access-Control-Allow-Headers: *

[0087] Access-Control-Allow-Methods: *

[0088] Access-Control-Allow-Origin: *

[0089] For illustration, in the above steps, * represents all domains. In some other embodiments, the Access-Control-Allow-Headers, Access-Control-Allow-Methods, and Access-Control-Allow-Origin parameters can also be modified to parameter values consistent with the host address or domain name of the front-end service. It can be set to be modified autonomously, or a mapping table can be provided to modify according to the host address or domain name of the front-end service. Specific modification rules can be preset to trigger the modification autonomously, and the rules can also be set according to the actual usage scenario. When returning to the front-end service, since the relevant parameters are changed, it can be determined as a non-cross-origin request at this time, thereby establishing the access link between the front-end service and the back-end service, enabling the front-end service to normally receive the return result of the back-end service, and solving the cross-origin problem.

[0090] To further elaborate on the cross-origin processing method of the application service described in this embodiment, the following example is provided:

[0091] Front-end service: Browser A system, URL: https: / / hiclouds.com / labor / admin / complaint / index

[0092] When A accesses the back-end interface:

[0093] A1 system (URL: https: / / hiclouds.com / labor / api / complaints / page-list)

[0094] A2 system (URL: https: / / hiar.com / user / api / page-list)

[0095] When accessing the A2 system, a cross-origin problem will occur. That is, when the A system requests the A2 system and the A2 system successfully returns, due to cross-origin, the A browser will be restricted from reading and writing the return result of A2, resulting in an error.

[0096] For the cross - domain processing method of application services provided in this embodiment, when System A requests cross - domain access to System A2, it triggers the eBPF program to modify and reorganize TCP network packets, and adds a CrossDomainFlag cross - domain flag to the TCP network packets. When the request to System A2 is successfully returned, the eBPF program will parse the TCP network packets to check if there is a CrossDomainFlag cross - domain flag. If there is a CrossDomainFlag cross - domain flag, it will search for the above - mentioned 4 parameters and use an auxiliary function to modify them to new values (such as the above *). When the result of accessing System A2 is returned to the browser, because the above - mentioned parameters are modified, the browser can normally obtain the return result.

[0097] For the cross - domain processing method of application services provided in this embodiment, the eBPF program is used to determine whether an access request sent by the front - end service is a cross - domain access. When it is a cross - domain access, the access request is marked. During the feedback process after the access request is sent to the back - end service, the response of the back - end service is obtained. When it is recognized that there is a mark, the message - header parameters in the transmission data packets of the back - end service response obtained for the access request are modified and then returned to the front - end service again to solve the cross - domain problem. The processing method provided in this embodiment does not need to be coupled with the application side and can be independently deployed; moreover, the cost is extremely low, and no code needs to be modified for the front - end and back - end application services; it can dynamically load the business logic in the eBPF program into the kernel for operation, realizing dynamic execution of hot updates; the compiled program runs in the kernel, with high performance; when processing data packets in the kernel, the system resource consumption is small, and it also reduces the waste of system resources caused by transferring network data packets to the user space; and there is no need to add an additional third - party proxy service.

[0098] Embodiment 2: The present invention also provides an application service cross - domain processing system. Refer to Figure 3 , which includes an application layer 81 and a kernel 82; the application layer includes a front - end server 811 and a back - end server 812. Among them, the front - end server provides front - end services, and the server - side provides back - end services. It should be noted that generally, the front - end server and the back - end server are not the same server, and in this case, a cross - domain problem will occur, but it is not limited to this, and they can also be the same server.

[0099] Specifically, to solve the cross - domain problem, an eBPF program is loaded under the kernel and the cross - domain processing method described in Embodiment 1 is executed, including: presetting variables storing the protocol, domain name / host, and port of a storage backend service; obtaining an access request sent from a front - end service to a backend service; obtaining the protocol, domain name / host, and port of the front - end service according to the message headers in the transmission data packet associated with the access request; judging whether the access request is a cross - domain access based on the variables. If so, performing cross - domain marking on the transmission data packet in the backend service response obtained for the access request; judging whether the access request has a cross - domain marking; if not, establishing an access link between the front - end service and the backend service according to the access request; if so, modifying the message header parameters in the transmission data packet in the backend service response obtained for the access request according to the variables, and returning to the front - end service, thereby establishing an access link between the front - end service and the backend service.

[0100] An improved method for cross - domain requests of front - end and back - end separated applications in the cloud - native field is implemented under the eBPF program. During the request process, the protocol, domain name / host, and port of the URL in the message headers (such as HTTP Header) of the transmission data packet (such as TCP network data packet, etc.) of the request are compared with the protocol, domain name / host, and port of the backend service request url pre - stored in the variables, thereby judging whether the network (access) request is cross - domain, and marking the access request corresponding to the cross - domain access. Specifically, a new field, such as the CrossDomainFlag field, is added in the transmission protocol header (such as TCP header, etc.). During the return process, the message header parameters in the transmission data packet in the backend service response obtained for the access request are modified. For example, the transmission data packet is represented by a socket buffer to locate the message header parameters (access - control - allow - credentials, access - control - allow - origin, access - control - allow - methods, access - control - allow - headers) in the transmission data packet, and then the message header parameters are modified to preset values or automatically modified according to preset modification rules.

[0101] More specifically, the eBPF program is deployed on an intermediate server between a front - end service and a backend service. Specifically, this system is applied to the B / S architecture mode. For example, when a client web browser sends a request to a server, common modes include: browser - front - end server - load balancer (gateway) - backend service, or browser - front - end server - backend service. Therefore, the eBPF program is deployed on the intermediate server for front - end access to the backend, such as a gateway or a load - balancer server.

[0102] Based on the application service cross - domain processing system provided by this embodiment, the cross - domain problem when the front - end of the cloud - native application service accesses a non - homologous back - end service is solved through an eBPF program. The eBPF program is called under the kernel. After marking the cross - domain access request and obtaining the back - end service response, the message - header parameters (Access - Control - Allow - Credentials, Access - Control - Allow - Origin, Access - Control - Allow - Methods, Access - Control - Allow - Headers) are modified, solving the problem that the existing application service cross - domain operation is complex and resource - consuming by modifying code, protocols or using third - party proxies. And all are executed under the kernel, independent of the application service. Executing under the kernel has high performance, security, less consumption and faster response; it reduces the system complexity.

[0103] It should be noted that the embodiments of the present invention have better implementability and are not any form of limitation to the present invention. Any person skilled in the art may use the disclosed technical content to change or modify it into an equivalent effective embodiment. However, as long as it does not depart from the technical solution of the present invention, any modification, equivalent change or modification made to the above embodiments according to the technical essence of the present invention still falls within the scope of the technical solution of the present invention.

Claims

1. A cross - domain processing method for application services, characterized in that Execute under the eBPF program, including: Pre-set a variable storing the protocol, host, and port of a storage backend service or a variable storing the protocol, domain name, and port of a storage backend service; Obtain an access request sent from a front-end service to a back-end service; Obtain the protocol, host, and port of the front-end service or the protocol, domain name, and port of the front-end service according to the message header in the transmission data packet associated with the access request; Judge whether the access request is a cross-domain access based on the variable; If not, establish an access link between the front-end service and the back-end service according to the access request; If so, after performing cross-domain marking on the transmission data packet associated with the access request, request to access the back-end service; obtain the transmission data packet in the response of the back-end service obtained according to the access request, and judge whether it has a cross-domain marking; If so, modify the message header parameters in the transmission data packet in the response of the back-end service obtained for the access request, and return it to the front-end service, thereby establishing an access link between the front-end service and the back-end service; The cross-domain marking of the transmission data packet associated with the access request includes: Obtain the transmission data packet associated with the access request, and parse it to obtain an Ethernet frame, a network protocol header, and a transmission protocol header; Store the new field value corresponding to the cross-domain marking at a preset address accessible by the eBPF program; Call a function to find the BPF mapping table element to obtain the new field value from the preset address, encode the field value into the format of the protocol header option of the transmission protocol, and write it into the transmission protocol header to form a transmission protocol header with a cross-domain marking; Call a function to update the transmission protocol header checksum to perform an updated check based on the transmission protocol header with a cross-domain marking.

2. The processing method according to claim 1, characterized in that: The message header parameters in the transmission data packet include: access control allow credentials, access control allow application protocol, access control allow method, access control allow domain name.

3. The processing method according to claim 1, characterized in that The judgment of whether there is a cross-domain marking includes: Judge whether there is a cross-domain marking in the transmission data packet in the response of the back-end service obtained for the access request based on the socket buffer.

4. The processing method according to claim 1, characterized in that, The modification of the message header parameters in the transmission data packet in the response of the back-end service obtained for the access request includes: Use the socket buffer to represent the transmission data packet, and after positioning the message header parameters in the transmission data packet, modify the message header parameters in the transmission data packet.

5. The processing method according to claim 1 or 4, characterized in that: Use an auxiliary function to modify the message header parameters in the transmission data packet associated with the access request.

6. The processing method according to claim 1, characterized in that: The eBPF program is deployed on an intermediate server between the front-end service and the back-end service.

7. The processing method according to claim 1, wherein Before obtaining an access request sent from a front-end service to a back-end service, it further includes: Pre-compile the eBPF program to trigger the eBPF program according to the access request and load it for execution under the kernel.

8. An application service cross-domain processing system, characterized in that, It includes an application layer and a kernel; the application layer includes a front-end server and a back-end server. Among them, the front-end server provides front-end services, and the back-end server provides back-end services; an eBPF program is loaded under the kernel and executes as follows: Preset a variable storing the protocol, host, and port of the back-end service or a variable storing the protocol, domain name, and port of the back-end service; Obtain an access request sent from a front-end service to a back-end service; Obtain the protocol, host, and port of the front-end service or the protocol, domain name, and port of the front-end service according to the message header in the transmission data packet associated with the access request; Based on the variable, determine whether the access request is a cross-domain access; If not, establish an access link between the front-end service and the back-end service according to the access request; If so, perform cross-domain marking on the transmission data packet associated with the access request, and request to access the back-end service; obtain the transmission data packet in the response of the back-end service obtained according to the access request, and determine whether it has a cross-domain marking; If so, modify the message header parameters in the transmission data packet in the response of the back-end service obtained from the access request, and return it to the front-end service, thereby establishing an access link between the front-end service and the back-end service; The performing cross-domain marking on the transmission data packet associated with the access request includes: Obtain the transmission data packet associated with the access request, and parse it to obtain an Ethernet frame, a network protocol header, and a transport protocol header; Store the value of the new field corresponding to the cross-domain marking at a preset address accessible by the eBPF program; Call a function to find the BPF map table element to obtain the value of the new field from the preset address, encode the field value into the format of the protocol header option of the transport protocol, and write it into the transport protocol header to form a transport protocol header with a cross-domain marking; Call a function to update the transport protocol header checksum to perform an updated check based on the transport protocol header with a cross-domain marking.

9. The processing system according to claim 8, wherein: The eBPF program is deployed on an intermediate server between the front-end service and the back-end service.

Images