WO2023273693A1 - 签名算法的动态加载方法、装置、设备及存储介质 - Google Patents

签名算法的动态加载方法、装置、设备及存储介质 Download PDF

Info

Publication number
WO2023273693A1
WO2023273693A1 PCT/CN2022/094381 CN2022094381W WO2023273693A1 WO 2023273693 A1 WO2023273693 A1 WO 2023273693A1 CN 2022094381 W CN2022094381 W CN 2022094381W WO 2023273693 A1 WO2023273693 A1 WO 2023273693A1
Authority
WO
WIPO (PCT)
Prior art keywords
signature algorithm
script
url
target signature
api
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2022/094381
Other languages
English (en)
French (fr)
Inventor
洪子伦
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing ByteDance Network Technology Co Ltd
Original Assignee
Beijing ByteDance Network Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing ByteDance Network Technology Co Ltd filed Critical Beijing ByteDance Network Technology Co Ltd
Priority to US18/562,163 priority Critical patent/US12432074B2/en
Publication of WO2023273693A1 publication Critical patent/WO2023273693A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/901—Indexing; Data structures therefor; Storage structures
    • G06F16/9014—Indexing; Data structures therefor; Storage structures hash tables
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services

Definitions

  • the embodiments of the present application relate to the field of computer technology, and in particular to a dynamic loading method, device, device and storage medium of a signature algorithm.
  • CDN Content Delivery Network
  • edge servers that is, cache servers, and distribute these edge servers to areas or networks where user access is relatively concentrated, and utilize global load when users access websites.
  • the technology directs the user's access to the nearest edge server that works normally, and the edge server directly responds to user requests, improving the response speed and hit rate of user access.
  • the process of user accessing the website can be as follows: the client signs the Uniform Resource Locator (Uniform Resource Locator, URL) through the private key (Secret Key, SK) and signature algorithm, and the obtained signature, URL and access key ( Access Key, AK) is carried in the Hyper Text Transfer Protocol (Hyper Text Transfer Protocol, HTTP) request.
  • the edge server corresponding to the client determines the SK corresponding to the AK, and uses the signature algorithm to match the SK with the SK.
  • the URL is signed, and the obtained signature is compared with the signature carried in the HTTP request to verify the authenticity of the URL. If the URL is authentic, the edge server sends an HTTP response, or, when the edge server does not save the user locally When the required data is obtained, it will go back to the origin site to obtain the data required by the user.
  • the signature algorithm is embedded in the corresponding edge server in the traditional hard-coded way.
  • Algorithm Algorithm, resulting in low signature algorithm loading efficiency.
  • different clients may use different signature algorithms, that is, the client may need a customized signature algorithm, and there are a large number of edge servers in the CDN.
  • the edge server corresponding to the client is embedded with the signature algorithm according to the traditional hard-coded method, which leads to the problem of low loading efficiency of the signature algorithm in the entire CDN, and finally leads to an obvious bottleneck in the efficiency of user access or service adaptation.
  • the present application provides a dynamic loading method, device, equipment and storage medium of a signature algorithm, so that the loading efficiency of the signature algorithm can be improved.
  • the loading efficiency of the signature algorithm in the entire CDN can be improved, so that The efficiency of user access or service adaptation is improved.
  • a method for dynamically loading a signature algorithm including: acquiring a script corresponding to the dynamic part of the target signature algorithm, the script including: at least one script API; at least one general API encapsulating the static part of the target signature algorithm, at least one The script API has a mapping relationship with at least one common API; according to the mapping relationship between the at least one script API and the at least one common API, the script and the static part are combined to generate a target signature algorithm; and the target signature algorithm is compiled.
  • a dynamic loading device for a signature algorithm including: a first acquisition module, an encapsulation module, a generation module, and a compilation module, wherein the first acquisition module is used to acquire the script corresponding to the dynamic part of the target signature algorithm, and the script Including: at least one script API; the encapsulation module is used to encapsulate at least one general API of the static part of the target signature algorithm, and at least one script API has a mapping relationship with at least one general API; the generation module is used to communicate with at least one general API according to at least one script API The mapping relationship between APIs combines the script and static parts to generate the target signature algorithm; the compilation module is used to compile the target signature algorithm.
  • an electronic device including: a processor and a memory, the memory is used to store a computer program, the processor is used to call and run the computer program stored in the memory, and perform the same as the first aspect or various implementations thereof method in .
  • a computer-readable storage medium for storing a computer program, and the computer program causes a computer to execute the method in the first aspect or various implementations thereof.
  • a computer program product including computer program instructions, where the computer program instructions cause a computer to execute the method in the first aspect or various implementations thereof.
  • a computer program which enables a computer to execute the method in the first aspect or various implementations thereof.
  • the script corresponding to the dynamic part of the signature algorithm can be hot-swappably implanted on the software statically compiled by the edge server, so that the loading efficiency of the signature algorithm can be improved.
  • it can improve the loading efficiency of the signature algorithm in the entire CDN, so that the efficiency of user access or service adaptation has been improved.
  • the dynamic loading method provided by this application can be performed before the edge server obtains the HTTP request, that is, the loading process of the above-mentioned target signature algorithm is a pre-loading process, and the loading process involves encapsulating at least the static part of the target signature algorithm
  • a common API can be called a pre-packaging process, and compiling the target signature algorithm is also a pre-compilation process, which can further improve the loading efficiency of the signature algorithm.
  • Fig. 1 is a kind of CDN distribution system architecture diagram that the embodiment of the present application provides;
  • FIG. 2 is a flow chart of a dynamic loading method of a signature algorithm provided by an embodiment of the present application
  • FIG. 3 is a schematic diagram of the mapping relationship between at least one script API and at least one general API provided by the embodiment of the present application;
  • FIG. 4 is a flow chart of a method for using a signature algorithm provided in an embodiment of the present application.
  • FIG. 5 is a schematic diagram of a script preloading process provided by an embodiment of the present application.
  • Fig. 6 is the schematic diagram of the KFC600 that the application embodiment provides
  • FIG. 7 is a schematic block diagram of an electronic device 700 provided by an embodiment of the present application.
  • CDN is a content distribution network built on the Internet. Relying on the edge servers deployed in various places, through the load balancing, content distribution, scheduling and other functions of the central platform, users can obtain the required content nearby, reduce network congestion, and improve user access response speed and Hit rate, the core technology is content storage and distribution technology.
  • an edge server is also referred to as a cache server, a CDN edge server, a CDN cache server, an edge node, or a CDN edge node, etc., which is not limited in this application.
  • FIG. 1 is a CDN distribution system architecture diagram provided by the embodiment of the present application.
  • N N data centers in the world
  • multiple cache servers are deployed in these data centers to form a cache cluster system
  • users can access the data nearby.
  • edge servers which are closest to users, but are small in scale and cache less data, and users may not be able to hit them.
  • regional nodes need to be deployed on edge servers, which are larger in scale than edge servers and have more cached data;
  • Above the regional server is the central server, which has a larger scale and more cached data. If there is no hit, you can only go back to the source site to access the data.
  • the CDN distribution system shown in Figure 1 is only an example.
  • the CDN distribution system may include at least one layer of servers.
  • the CDN distribution system only includes one layer of edge servers.
  • the CDN distribution system includes a layer of edge servers and a layer of regional servers.
  • users fail to hit the edge server they first go to the regional server to obtain data. If the regional server is not named in China, then they can directly return to the source. The station accesses the data.
  • an area server is also referred to as an area node, a CDN area server, a CDN area node, etc., which is not limited in this application.
  • the central server is also referred to as a master node, a CDN central server, a CDN master node, etc., which is not limited in this application.
  • the origin server may be a World Wide Web (WWW) server.
  • WWW World Wide Web
  • the process for a user to access a website can be as follows: the client signs the URL through the SK and the signature algorithm, and carries the obtained signature, URL, and AK in the HTTP request.
  • the edge server corresponding to the client determine the SK corresponding to the AK, and sign the URL through the signature algorithm and the SK, and compare the obtained signature with the signature carried in the HTTP request to verify the authenticity of the URL. If the URL is authentic, Then the edge server sends an HTTP response, or, when the edge server does not store the data required by the user locally, it returns to the origin server to obtain the data required by the user.
  • signature algorithm here can be any signature algorithm, for example: Hash-based Message Authentication Code (Hash-based Message Authentication Code, HMAC), message digest algorithm (Message-Digest Algorithm, MD5), etc. No restrictions.
  • AK is a kind of public key (Public Key, PK).
  • the URL includes: a protocol part, a domain name part, a port part, a file name part, an anchor part, and a parameter part.
  • the protocol part of the URL is "http:", which means that the webpage uses the HTTP protocol.
  • Various protocols can be used in the Internet, such as HTTP, File Transfer Protocol (File Transfer Protocol, FTP), etc., and the HTTP protocol is used in this example.
  • the "//" behind “HTTP” is a separator, and the domain name part of the URL is "www.aspxfans.com”.
  • an IP address can also be used as a domain name. From the first "/" after the domain name to the last "/”, it is the virtual directory part. Virtual directories are also not a required part of a URL.
  • the virtual directory in this example is "/news/”. From the last "/" after the domain name to "?” is the file name part, if there is no "?”, it is the file part from the last "/" to "#” after the domain name, if Without "?” and "#”, then from the last "/" after the domain name to the end, it is the file name part.
  • the file name in this example is "index.asp".
  • the file name part is also not a mandatory part of a URL, if this part is omitted, the default file name will be used. From “#" to the end, it is the anchor part.
  • the anchor part in this example is "name”.
  • the anchor part is also not a required part of a URL.
  • the part from "?" to "#” is the parameter part, also known as the search part and the query part.
  • HTTP is a transfer protocol used to transmit hypertext from a web server to a local browser.
  • HTTP is a communication protocol based on Transmission Control Protocol/Internet Protocol (TCP/IP) to transfer data, such as hypertext tags Language (Hyper Text Markup Language, HTML) files, picture files, query results, etc.
  • HTTP is an object-oriented protocol belonging to the application layer. It is suitable for distributed hypermedia information systems due to its simple and fast method.
  • the HTTP protocol works on a client-server architecture. As an HTTP client, the browser sends all requests, ie, HTTP requests, to the HTTP server, that is, the Web server, through the URL. After receiving the request, the web server sends response information to the client, that is, HTTP response.
  • HTTP requests generally include the following four parts: the first part: the request line, which is used to describe the request type, the resource to be accessed, and the HTTP version used; the second part: the request header (Header), followed by the request line (that is, the first line) to specify additional information to be used by the server.
  • the third part blank line, the blank line after the request header is required.
  • the fourth part The request data is also called the body, and any other data can be added.
  • An HTTP response generally includes the following four parts: status line, message header, blank line, and response body.
  • the current signature algorithm is embedded in the corresponding edge server in the traditional hard-coded way.
  • a certain edge server needs to load a certain signature Import the signature algorithm, resulting in the problem of low loading efficiency of the signature algorithm.
  • different clients may use different signature algorithms, that is, the client may need a customized signature algorithm, and there are a large number of edge servers in the CDN.
  • the edge server corresponding to the client is embedded with the signature algorithm according to the traditional hard-coded method, which leads to the problem of low loading efficiency of the signature algorithm in the entire CDN, and finally leads to an obvious bottleneck in the efficiency of user access or service adaptation.
  • this application provides a dynamic loading method, device, device and storage medium of a signature algorithm.
  • the script corresponding to the dynamic part of the signature algorithm can be implanted in a hot-swappable manner. , so that the loading efficiency of the signature algorithm can be improved.
  • it can improve the loading efficiency of the signature algorithm in the entire CDN, so that the efficiency of user access or service adaptation has been improved.
  • Fig. 2 is a flow chart of a dynamic loading method of a signature algorithm provided by an embodiment of the present application, wherein the method is applied to an edge server of a target signature algorithm to be loaded.
  • the edge server can be constructed using GO, but is not limited to this.
  • the loading here can be understood as the edge server loading the target signature algorithm for the first time, or that the edge server has deleted the target signature algorithm of the old version and loaded the new version of the target signature algorithm for the first time, etc.
  • the method includes the following steps:
  • S210 Obtain a script corresponding to the dynamic part of the target signature algorithm, where the script includes: at least one script application programming interface (Application Programming Interface, API).
  • API Application Programming Interface
  • S220 Encapsulate at least one common API of the static part of the target signature algorithm, and at least one script API has a mapping relationship with the at least one common API.
  • the application scenarios of the technical solution of this application may be as follows, but not limited thereto:
  • Scenario 1 A user adjusts the business logic and expects to use another set of algorithm rules, that is, the above-mentioned target signature algorithm.
  • Scenario 2 A user is a new access user and proposes his own business logic, such as using a private encryption algorithm, such as the target signature algorithm mentioned above.
  • the target signature algorithm may be any signature algorithm to be loaded, for example, the current signature algorithm may be the HMAC algorithm or MD5 algorithm to be loaded, and this application does not limit this.
  • user A adjusted the business logic, using the header["a”], header["b”] requested by the client, and arg["a”] in the question mark string, separated by " ⁇ t” and spliced together , it is expected to use the target signature algorithm, that is, the HMAC algorithm for signature, and finally the signature can be saved in the request header ["c"].
  • the target signature algorithm that is, the HMAC algorithm for signature
  • user B is a new access user, using the header["c"] requested by the client, and the HTTP protocol, separated by " ⁇ n” and spliced together, signed by the target signature algorithm, that is, the MD5 algorithm, and finally can Save the signature into the question mark string ["xx"].
  • the target signature algorithm can be a customized signature algorithm
  • this part is The dynamic part of the target signature algorithm, which may be some dynamic parameters, dynamic logic, etc. in the target signature algorithm.
  • This dynamic part is also referred to as the variable part of the target signature algorithm.
  • the edge server can encapsulate at least one script API of the script according to the division of each functional module of the above script, for example: the functional module corresponding to script API1 includes: the parameter of character string conversion, and the functional module corresponding to script API2 Including: parameters for converting strings to lowercase.
  • the script above can be a Lua script, and based on this, the script API in this application can also be called the Lua API.
  • the edge server can encapsulate at least one general API of the static part according to the division of each functional module of the static part of the target signature algorithm, for example: the function module corresponding to the general API1 is used to complete the operation of converting a string to uppercase, The function module corresponding to script API2 is used to complete the operation of converting character strings to lowercase.
  • the edge server can be built using GO.
  • the general API in this application can also be called GO API.
  • the edge server may establish the mapping relationship between the above at least one script API and at least one general API, or may also be a smart device, such as other servers establishing the mapping relationship between the above at least one script API and at least one general API , and send it to the edge server, which is not limited in this application.
  • FIG. 3 is a schematic diagram of the mapping relationship between at least one script API and at least one general API provided by the embodiment of the present application. As shown in FIG. 3, the at least one script API and at least one general API here The mapping relationship is a one-to-one correspondence.
  • the function modules corresponding to script API1 include: parameters for converting character strings to uppercase
  • the function modules corresponding to script API2 include: parameters for converting character strings to lowercase.
  • the function module corresponding to general API1 is used to complete the operation of converting character strings to uppercase
  • the function module corresponding to script API2 is used to complete the operation of converting character strings to lowercase.
  • the script API1 corresponds to the general API1
  • the script API2 corresponds to the general API2.
  • mapping relationship between at least one scripting API and at least one general API is not limited to a one-to-one mapping relationship, for example, a many-to-one mapping relationship, or a one-to-many mapping relationship, or a many-to-many mapping relationship , this application does not limit it.
  • the edge server may combine the script and the static part according to the mapping relationship to generate a target signature algorithm. For example: according to the mapping relationship, the edge server will pass the dynamic parameter in the script to the corresponding general API of the API through the script API, and then pass the dynamic parameter to the corresponding general function through the general API. Another example: the edge server will pass the dynamic logic in the script to the corresponding general API through the script API according to the mapping relationship, and then pass the dynamic logic to the corresponding general function through the general API.
  • the edge server will pass the dynamic parameters and dynamic logic in the script to the corresponding general API of the API through the script API, and then pass the dynamic parameters and dynamic logic to the corresponding general function through the general API .
  • the edge server will pass the general function of the static part to the script API through the corresponding general API according to the mapping relationship, and then pass the general function to the script through the script API.
  • the script has the general function and Dynamic parameters, or general functions and dynamic logic, or general functions and dynamic parameters and dynamic logic.
  • the function modules corresponding to the script API1 include: parameters for converting character strings to uppercase
  • the function modules corresponding to script API2 include: parameters for converting character strings to lowercase.
  • the function module corresponding to general API1 is used to complete the operation of converting character strings to uppercase
  • the function module corresponding to script API2 is used to complete the operation of converting character strings to lowercase.
  • Script API1 corresponds to general API1
  • script API2 corresponds to general API2.
  • the edge server can transfer the parameters of character string conversion to general API1 through script API1, so as to realize the function of character string conversion in the target signature algorithm.
  • the edge server can transmit the parameter of character string conversion to the general API2 through the script API2, so as to realize the function of character string conversion in the target signature algorithm.
  • the edge server After the edge server generates the target signature algorithm, it needs to convert the target signature algorithm into recognizable content, that is, it needs to compile the target signature algorithm.
  • the edge server can obtain the script corresponding to the dynamic part of the target signature algorithm, and the script includes: at least one script API, at least one general API encapsulating the static part of the target signature algorithm, at least one script API and at least A general API has a mapping relationship, and according to the mapping relationship between at least one script API and at least one general API, the script and the static part are combined to generate a target signature algorithm, and the target signature algorithm is compiled. That is, on the statically compiled software of the edge server, the script corresponding to the dynamic part of the signature algorithm can be hot-swapped, so as to improve the loading efficiency of the signature algorithm. In addition, from the perspective of the entire CDN distribution system, it can improve the loading efficiency of the signature algorithm in the entire CDN, so that the efficiency of user access or service adaptation has been improved.
  • the dynamic loading method provided by this application can be performed before the edge server obtains the HTTP request, that is, the loading process of the above-mentioned target signature algorithm is a pre-loading process, and the loading process involves encapsulating at least the static part of the target signature algorithm
  • a common API can be called a pre-packaging process, and compiling the target signature algorithm is also a pre-compilation process, which can further improve the loading efficiency of the signature algorithm.
  • the edge server may also store the identification of the target signature algorithm and the compilation result in a hash table.
  • the identification of the target signature algorithm and the compilation result corresponding to the target signature algorithm may not be stored in the form of entries in the hash table. limit.
  • the identifier of the target signature algorithm is the name of the target signature algorithm, or the name of the script corresponding to the dynamic part of the target signature algorithm, because the uniqueness or customization of each signature algorithm is mainly reflected in The script corresponding to the dynamic part, therefore, the signature algorithm can also be uniquely identified through the name of the script.
  • Fig. 4 is a flow chart of a method for using a signature algorithm provided by an embodiment of the present application, where the method is applied to an edge server that has loaded a target signature algorithm.
  • the edge server can be constructed using GO, but is not limited thereto .
  • the method includes the following steps:
  • the acquisition client sends an HTTP request.
  • the HTTP request includes: URL, first signature, and AK.
  • the first signature is obtained after the URL is signed by the target signature algorithm and SK.
  • S440 Sign the URL according to the target signature algorithm and the private key to obtain a second signature.
  • S450 Verify authenticity of the URL according to the first signature and the second signature.
  • SK and AK have a corresponding relationship, and the two are a pair of public and private keys, that is, SK can be determined through AK.
  • the first signature is a signature obtained by the client signing the URL according to the target signature algorithm and the SK.
  • the second signature is a signature obtained by the edge server signing the URL according to the target signature algorithm and SK. If the first signature and the second signature are the same, it means that the URL is authentic, and if the first signature and the second signature are different, it means that the URL is not authentic.
  • the client can determine the signature algorithm it needs, that is, the signature algorithm corresponding to the above-mentioned client, and then notify the edge server of the corresponding signature algorithm, or the edge server can determine the client's signature algorithm according to the client's domain name configuration.
  • the corresponding signature algorithm is the target signature algorithm. In short, this application does not limit how the edge server determines the signature algorithm corresponding to the client.
  • the domain name configuration of the client includes: the signature algorithm that the client needs to use, that is, the signature algorithm corresponding to the above client.
  • the domain name configuration of the client further includes at least one of the following: key parameters, business logic, expiration time of the signature algorithm corresponding to the client, and the like.
  • key parameters include: AK and SK, but not limited thereto.
  • the CDN distribution system only includes edge servers, but does not include regional servers and central servers.
  • the edge server judges whether the access data corresponding to the URL is locally cached, such as HTML files, image files, query results, and the like. If the local cache has access data corresponding to the URL, the edge server sends the access data to the client, and the access data can be carried in the HTTP response. If the access data corresponding to the URL is not cached locally, then the edge server performs back-to-origin according to the second signature, that is, sends the second tag to the origin site.
  • the CDN distribution system includes edge servers and regional servers. If the verified URL is real, the edge server judges whether the access data corresponding to the URL is locally cached, such as HTML files, image files, query results, and the like. If the local cache has access data corresponding to the URL, the edge server sends the access data to the client, and the access data can be carried in the HTTP response. If the access data corresponding to the URL is not locally cached, then the edge server first sends the second tag to its corresponding region server, and then the region server checks whether it locally caches the access data corresponding to the URL. If the local cache has access data corresponding to the URL, the region server sends the access data to the client. If the access data corresponding to the URL is not locally cached, then the region server returns to the origin according to the second signature, that is, sends the second tag to the origin site.
  • the edge server judges whether the access data corresponding to the URL is locally cached, such as HTML files, image files, query results, and the like. If the local cache has access data corresponding to the
  • the CDN distribution system includes an edge server, a regional server, and a central server. If the verified URL is real, the edge server judges whether the access data corresponding to the URL is locally cached, such as HTML files, image files, query results, and the like. If the local cache has access data corresponding to the URL, the edge server sends the access data to the client, and the access data can be carried in the HTTP response. If the access data corresponding to the URL is not locally cached, then the edge server first sends the second tag to its corresponding region server, and then the region server checks whether it locally caches the access data corresponding to the URL.
  • the edge server judges whether the access data corresponding to the URL is locally cached, such as HTML files, image files, query results, and the like. If the local cache has access data corresponding to the URL, the edge server sends the access data to the client, and the access data can be carried in the HTTP response. If the access data corresponding to the URL is not locally cached, then the edge server first sends the second tag to its corresponding region server,
  • the region server sends the access data to the client. If the access data corresponding to the URL is not cached locally, the regional server first sends the second tag to the central server, and then the central server checks whether the access data corresponding to the URL is locally cached. If there is access data corresponding to the URL in the local cache, the central server sends the access data to the client. If the access data corresponding to the URL is not locally cached, then the central server returns to the source according to the second signature, that is, sends the second tag to the source site.
  • this application does not impose restrictions on the structure of the CDN distribution system, and accordingly, does not impose restrictions on how to send access data to the client.
  • the dynamic loading method of the above-mentioned signature algorithm can be specifically executed by at least one processor or at least one chip in the edge server, for example: the method can be implemented by the simple, easy-to-use, high-efficiency cache (KISS and Fast Cache) in the edge server , KFC) implementation, KISS means concise and easy to use (Keep It Simple and Stupid).
  • KISS and Fast Cache high-efficiency cache
  • KISS means concise and easy to use
  • FIG. 5 is a schematic diagram of a script preloading process provided by the embodiment of the present application.
  • script 1 includes: script API1, script API2 and script API3, and script 1 can be preloaded Load it into KFC, and further, KFC can compile the target key algorithm, and finally store the compiled result in the hash table, as shown in Figure 5, the hash table stores the script 1 identifier and the corresponding compilation Result 1.
  • the compilation result can be a binary value.
  • the hash table can also store the identification of other key algorithms and the corresponding compilation result, for example: as shown in Figure 5, the hash table also stores the identification of script 2 and the corresponding compilation result 2 .
  • the KFC may include the following functional modules, but not limited thereto: HTTP access module, back-to-source module, monitoring module and storage module.
  • Fig. 6 is the schematic diagram of the KFC600 provided by the embodiment of the present application, as shown in Fig. 6, the monitoring module 610 in KFC600 is responsible for monitoring whether the script under the script file directory changes, for example: whether the monitoring module 610 monitors whether If a new signature algorithm is added or a signature algorithm is updated, if a new signature algorithm is added in this directory or a signature algorithm is updated, then the monitoring module 610 completes the signature algorithm according to the above dynamic loading method of the monitoring algorithm. Load and store the compilation result of the signature algorithm into the storage module 620.
  • the identification of the signature algorithm and the compilation result corresponding to the signature algorithm may be stored in a hash table, and the hash table is stored in the storage module 620 .
  • the compilation result corresponding to the signature algorithm may not be stored in the form of a hash table entry, and this application does not limit the storage method of the compilation result of the signature algorithm.
  • the identification of the above signature algorithm is the name of the signature algorithm, or the name of the script of the signature algorithm, because the uniqueness or customization of each signature algorithm is mainly reflected in the script corresponding to the dynamic part, Therefore, the signature algorithm can also be uniquely identified by the name of the script.
  • the HTTP access module 630 in the KFC can obtain an HTTP request, which includes: URL, first signature, AK, the first signature is that the URL is obtained after the target signature algorithm and SK signature, and the HTTP
  • the request is sent to the source-returning module 640, which is used to determine the SK corresponding to AK, and search the target signature algorithm in the hash table, and sign the URL according to the target signature algorithm and private key to obtain the second signature,
  • the authenticity of the URL is verified based on the first signature and the second signature. If the first signature and the second signature are the same, it means that the URL is authentic, and if the first signature and the second signature are different, it means that the URL is not authentic.
  • the back-to-source module 640 can check whether the storage module 620 caches the access data corresponding to the URL. If the access data corresponding to the URL is cached locally, the back-to-source module 640 sends the access data to the client. After accessing the data, the back-to-source module 640 performs back-to-source according to the second signature, that is, sends the second tag to the source station. It should be noted that the one-layer structure adopted by the CDN distribution system is assumed here. Of course, the CDN distribution system may also adopt a multi-layer structure. If a multi-layer structure is adopted, then the returned access data or Send its second label to the upper server until the client obtains the access data.
  • the signature algorithm is upgraded from the original rolling upgrade of tens of thousands of machines to one-click push scripts across the network to complete the upgrade in an instant, and the upgrade efficiency is increased by more than 100 times. And through the technical solution provided by the application, the CPU consumption burden is reduced, and the access quality is hardly affected.
  • the embodiment of the present application also provides a dynamic loading device for a signature algorithm.
  • the dynamic loading device includes: a first acquisition module, an encapsulation module, a generation module and a compilation module, wherein the first acquisition module is used to acquire the script corresponding to the dynamic part of the target signature algorithm, and the script includes: at least one script API.
  • the encapsulation module is used to encapsulate at least one general API of the static part of the target signature algorithm, and at least one script API has a mapping relationship with at least one general API.
  • the generation module is used to combine the script and the static part according to the mapping relationship between at least one script API and at least one general API, so as to generate the target signature algorithm.
  • the compilation module is used to compile the target signature algorithm.
  • the dynamic loading device further includes: a storage module, configured to store the identification of the target signature algorithm and the compilation result of the target signature algorithm in the hash table after the compilation module compiles the target signature algorithm.
  • a storage module configured to store the identification of the target signature algorithm and the compilation result of the target signature algorithm in the hash table after the compilation module compiles the target signature algorithm.
  • the dynamic loading device further includes: a second acquisition module, a first determination module, a search module, a signature module, a second acquisition module, the first determination module, a search module, a signature module and a verification module, wherein the second The obtaining module is used to obtain the HTTP request sent by the client.
  • the HTTP request includes: URL, first signature, and access key.
  • the first signature is obtained after the URL is signed by the target signature algorithm and private key.
  • the first determination module is used to determine the private key corresponding to the access key.
  • the lookup module is used to look up the target signature algorithm in the hash table.
  • the signature module is used to sign the URL according to the target signature algorithm and the private key to obtain the second signature.
  • the verification module is used to verify the authenticity of the URL according to the first signature and the second signature.
  • the dynamic loading device further includes: a third obtaining module and a second determining module, wherein the third obtaining module is used to obtain the domain name configuration of the client before the searching module searches the target signature algorithm in the hash table.
  • the second determination module is configured to determine that the signature algorithm corresponding to the client is the target signature algorithm according to the domain name configuration of the client.
  • the dynamic loading device further includes: a judging module, a sending module and a back-to-source module, wherein the judging module is used to judge whether the access data corresponding to the URL is cached locally if the verification URL is authentic.
  • the sending module is used to send the access data to the client if the access data corresponding to the URL is cached locally.
  • the back-to-source module is used to perform back-to-source according to the second signature if the access data corresponding to the URL is not cached locally.
  • the verification module is specifically configured to: if the first signature and the second signature are the same, determine that the URL is authentic. If the first signature and the second signature are different, it is determined that the URL is not authentic.
  • the identifier of the target signature algorithm is the name of the target signature algorithm or the name of the script.
  • the dynamic loading device of the signature algorithm is built with GO.
  • the device embodiment and the method embodiment may correspond to each other, and similar descriptions may refer to the method embodiment. To avoid repetition, details are not repeated here.
  • the dynamic loading device of the signature algorithm can execute the above-mentioned method embodiments, and the aforementioned and other operations and/or functions of the various modules in the dynamic loading device of the signature algorithm are for each method in the above-mentioned method embodiments For the sake of brevity, the corresponding process is not repeated here.
  • the functional modules may be implemented in the form of hardware, may also be implemented by instructions in the form of software, and may also be implemented by a combination of hardware and software modules.
  • each step of the method embodiment in the embodiment of the present application can be completed by an integrated logic circuit of the hardware in the processor and/or instructions in the form of software, and the steps of the method disclosed in the embodiment of the present application can be directly embodied as hardware
  • the decoding processor is executed, or the combination of hardware and software modules in the decoding processor is used to complete the execution.
  • the software module may be located in a mature storage medium in the field such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, and registers.
  • the storage medium is located in the memory, and the processor reads the information in the memory, and completes the steps in the above method embodiments in combination with its hardware.
  • FIG. 7 is a schematic block diagram of an electronic device 700 provided by an embodiment of the present application, and the electronic device 700 can be used as an edge server.
  • the electronic device 700 may include:
  • a memory 710 and a processor 720 the memory 710 is used to store computer programs and transmit the program codes to the processor 720 .
  • the processor 720 can invoke and run a computer program from the memory 710, so as to implement the method in the embodiment of the present application.
  • the processor 720 can be used to execute the above-mentioned method embodiments according to the instructions in the computer program.
  • the processor 720 may include but not limited to:
  • DSP Digital Signal Processor
  • ASIC Application Specific Integrated Circuit
  • FPGA Field Programmable Gate Array
  • the memory 710 includes but is not limited to:
  • non-volatile memory can be read-only memory (Read-Only Memory, ROM), programmable read-only memory (Programmable ROM, PROM), erasable programmable read-only memory (Erasable PROM, EPROM), electronically programmable Erase Programmable Read-Only Memory (Electrically EPROM, EEPROM) or Flash.
  • the volatile memory can be Random Access Memory (RAM), which acts as external cache memory.
  • RAM Static Random Access Memory
  • SRAM Static Random Access Memory
  • DRAM Dynamic Random Access Memory
  • Synchronous Dynamic Random Access Memory Synchronous Dynamic Random Access Memory
  • SDRAM double data rate synchronous dynamic random access memory
  • Double Data Rate SDRAM, DDR SDRAM double data rate synchronous dynamic random access memory
  • Enhanced SDRAM, ESDRAM enhanced synchronous dynamic random access memory
  • SLDRAM synchronous connection dynamic random access memory
  • Direct Rambus RAM Direct Rambus RAM
  • the computer program can be divided into one or more modules, and the one or more modules are stored in the memory 710 and executed by the processor 720 to complete the method.
  • the one or more modules may be a series of computer program instruction segments capable of accomplishing specific functions, and the instruction segments are used to describe the execution process of the computer program in the electronic device.
  • the electronic device may also include:
  • a transceiver 730 which can be connected to the processor 720 or the memory 710 .
  • the processor 720 can control the transceiver 730 to communicate with other devices, specifically, can send information or data to other devices, or receive information or data sent by other devices.
  • Transceiver 730 may include a transmitter and a receiver.
  • the transceiver 730 may further include an antenna, and the number of antennas may be one or more.
  • bus system includes not only a data bus, but also a power bus, a control bus and a status signal bus.
  • the present application also provides a computer storage medium, on which a computer program is stored, and when the computer program is executed by a computer, the computer can execute the methods of the above method embodiments.
  • the embodiments of the present application further provide a computer program product including instructions, and when the instructions are executed by a computer, the computer executes the methods of the foregoing method embodiments.
  • the computer program product includes one or more computer instructions.
  • the computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable device.
  • the computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transferred from a website, computer, server, or data center by wire (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) to another website site, computer, server or data center.
  • the computer-readable storage medium may be any available medium that can be accessed by a computer, or a data storage device such as a server or a data center integrated with one or more available media.
  • the available medium may be a magnetic medium (such as a floppy disk, a hard disk, or a magnetic tape), an optical medium (such as a digital video disc (digital video disc, DVD)), or a semiconductor medium (such as a solid state disk (solid state disk, SSD)), etc.
  • a magnetic medium such as a floppy disk, a hard disk, or a magnetic tape
  • an optical medium such as a digital video disc (digital video disc, DVD)
  • a semiconductor medium such as a solid state disk (solid state disk, SSD)
  • a method for dynamically loading a signature algorithm including: acquiring a script corresponding to the dynamic part of the target signature algorithm, the script including: at least one script API; encapsulating the static part of the target signature algorithm At least one general API, at least one script API has a mapping relationship with at least one general API; according to the mapping relationship between at least one script API and at least one general API, combine the script and static parts to generate a target signature algorithm; compile the target Signature algorithm.
  • the target signature algorithm after compiling the target signature algorithm, it further includes: storing the identification of the target signature algorithm and the compilation result of the target signature algorithm in a hash table.
  • the HTTP request after storing the identification of the target signature algorithm and the compilation result of the target signature algorithm in the hash table, it further includes: obtaining the HTTP request sent by the client, the HTTP request includes: URL, One signature, access key, the first signature is obtained after the URL is signed by the target signature algorithm and private key; determine the private key corresponding to the access key; look up the target signature algorithm in the hash table; according to the target signature algorithm and private key Sign the URL to obtain the second signature; verify the authenticity of the URL according to the first signature and the second signature.
  • the target signature algorithm in the hash table before searching the target signature algorithm in the hash table, it also includes: obtaining the domain name configuration of the client; determining that the signature algorithm corresponding to the client is the target signature algorithm according to the domain name configuration of the client.
  • the verified URL after verifying the authenticity of the URL according to the first signature and the second signature, it further includes: if the verified URL is authentic, then judging whether the access data corresponding to the URL is locally cached; if the local cache If there is access data corresponding to the URL, the access data is sent to the client; if the access data corresponding to the URL is not cached locally, the source is returned according to the second signature.
  • verifying the authenticity of the URL according to the first signature and the second signature includes: if the first signature and the second signature are the same, determining that the URL is authentic; if the first signature and the second signature If not, it is determined that the URL is not authentic.
  • the identifier of the target signature algorithm is the name of the target signature algorithm or the name of the script.
  • the method is applied to an edge server, and the edge server is constructed using GO.
  • a dynamic loading device for a signature algorithm including: a first acquisition module, a package module, a generation module, and a compilation module, wherein the first acquisition module is used to acquire the target signature algorithm
  • the script corresponding to the dynamic part, the script includes: at least one script API.
  • the encapsulation module is used to encapsulate at least one general API of the static part of the target signature algorithm, and at least one script API has a mapping relationship with at least one general API.
  • the generation module is used to combine the script and the static part according to the mapping relationship between at least one script API and at least one general API, so as to generate the target signature algorithm.
  • the compilation module is used to compile the target signature algorithm.
  • the dynamic loading device further includes: a storage module, configured to store the identification of the target signature algorithm and the compilation result of the target signature algorithm in a hash table after the compilation module compiles the target signature algorithm middle.
  • the dynamic loading device further includes: a second acquisition module, a first determination module, a search module, a signature module, a second acquisition module, a first determination module, a search module, a signature module and The verification module, wherein the second obtaining module is used to obtain the HTTP request sent by the client, the HTTP request includes: URL, a first signature, and an access key, and the first signature is obtained after the URL is signed by a target signature algorithm and a private key.
  • the first determination module is used to determine the private key corresponding to the access key.
  • the lookup module is used to look up the target signature algorithm in the hash table.
  • the signature module is used to sign the URL according to the target signature algorithm and the private key to obtain the second signature.
  • the verification module is used to verify the authenticity of the URL according to the first signature and the second signature.
  • the dynamic loading device further includes: a third acquisition module and a second determination module, wherein the third acquisition module is used to search the target signature algorithm in the hash table before the search module, Get the domain name configuration of the client.
  • the second determination module is configured to determine that the signature algorithm corresponding to the client is the target signature algorithm according to the domain name configuration of the client.
  • the dynamic loading device further includes: a judging module, a sending module, and a back-to-source module, wherein the judging module is used to judge whether the access corresponding to the URL is locally cached if the verified URL is authentic. data.
  • the sending module is used to send the access data to the client if the access data corresponding to the URL is cached locally.
  • the back-to-source module is used to perform back-to-source according to the second signature if the access data corresponding to the URL is not cached locally.
  • the verification module is specifically configured to: if the first signature and the second signature are the same, determine that the URL is authentic. If the first signature and the second signature are different, it is determined that the URL is not authentic.
  • the identifier of the target signature algorithm is the name of the target signature algorithm or the name of the script.
  • the dynamic loading device of the signature algorithm is constructed using GO.
  • an electronic device including: a processor and a memory, the memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory to execute the above signature algorithm Dynamic loading method.
  • a computer-readable storage medium for storing a computer program, and the computer program enables a computer to execute the above method for dynamically loading a signature algorithm.
  • modules and algorithm steps of the examples described in conjunction with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed by hardware or software depends on the specific application and design constraints of the technical solution. Skilled artisans may use different methods to implement the described functions for each specific application, but such implementation should not be regarded as exceeding the scope of the present application.
  • the disclosed systems, devices and methods may be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of the modules is only a logical function division. In actual implementation, there may be other division methods.
  • multiple modules or components can be combined or can be Integrate into another system, or some features may be ignored, or not implemented.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or modules may be in electrical, mechanical or other forms.
  • a module described as a separate component may or may not be physically separated, and a component displayed as a module may or may not be a physical module, that is, it may be located in one place, or may also be distributed to multiple network units. Part or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. For example, each functional module in each embodiment of the present application may be integrated into one processing module, each module may exist separately physically, or two or more modules may be integrated into one module.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Software Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

一种签名算法的动态加载方法、装置、设备及存储介质，包括：获取目标签名算法的动态部分对应的脚本，该脚本包括：至少一个脚本API；封装目标签名算法的静态部分的至少一个通用API，至少一个脚本API与至少一个通用API具有映射关系；根据至少一个脚本API与至少一个通用API之间的映射关系，对脚本和静态部分进行组合，以生成目标签名算法；编译目标签名算法，从而可以提高签名算法的加载效率，另外，从整个CDN分发系统来看，可以提高整个CDN中的签名算法加载效率，使得用户接入或者业务适配的效率得到了提升。

Description

签名算法的动态加载方法、装置、设备及存储介质
相关申请的交叉引用
本申请要求于2021年06月30日提交的，申请号为202110733971.7、发明名称为“签名算法的动态加载方法、装置、设备及存储介质”的中国专利申请的优先权，该申请的全部内容通过引用结合在本申请中。
技术领域
本申请实施例涉及计算机技术领域，尤其涉及一种签名算法的动态加载方法、装置、设备及存储介质。
背景技术
内容分发网络(Content Delivery Network，CDN)的基本原理是广泛采用各种边缘服务器，即缓存服务器，将这些边缘服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的边缘服务器上，由边缘服务器直接响应用户请求，提高用户访问响应速度和命中率。
其中，用户访问网站的过程可以如下：客户端通过私钥(Secret Key，SK)和签名算法对统一资源定位符(Uniform Resource Locator，URL)进行签名，将得到的签名、URL和访问密钥(Access Key，AK)携带在超文本传输协议(Hyper Text Transfer Protocol，HTTP)请求中，该客户端对应的边缘服务器接收到HTTP请求后，确定该AK对应的SK，并通过签名算法和该SK对该URL进行签名，对得到的签名和HTTP请求中携带的签名进行比对，以验证该URL的真实性，如果URL是真实的，则边缘服务器发送HTTP响应，或者，当边缘服务器本地未保存用户所需的数据时，则会回源至源站获取用户所需的数据。
目前，签名算法是以传统的硬编码方式植入对应的边缘服务器中，然而，一方面，当某一台边缘服务器需要加载某签名算法时，如果按照这种传统的硬编码方式植入该签名算法，导致签名算法加载效率较低的问题。另一方面，在一些场景中，不同的客户端可能采用的签名算法不同，也就是客户端可能需要定制化的签名算法，而CDN中存在海量的边缘服务器，如果这种需要定制化的签名算法的客户端对应的边缘服务器都按照传统的硬编码方式植入签名算法，导致整个CDN中的签名算法加载效率较低的问题，最终导致用户接入或者业务适配的效率上存在明显的瓶颈。
发明内容
本申请提供一种签名算法的动态加载方法、装置、设备及存储介质，从而可以提高签名算法的加载效率，另外，从整个CDN分发系统来看，可以提高整个CDN中的签名算法加载效率，使得用户接入或者业务适配的效率得到了提升。
第一方面，提供一种签名算法的动态加载方法，包括：获取目标签名算法的动态部分对应的脚本，脚本包括：至少一个脚本API；封装目标签名算法的静态部分的至少一个通用API，至少一个脚本API与至少一个通用API具有映射关系；根据至少一个脚本API与至少一个通用API之间的映射关系，对脚本和静态部分进行组合，以生成目标签名算法；编译目标签名算法。
第二方面，提供一种签名算法的动态加载装置，包括：第一获取模块、封装模块、生成模块和编译模块，其中，第一获取模块用于获取目标签名算法的动态部分对应的脚本，脚本包括：至少一个脚本API；封装模块用于封装目标签名算法的静态部分的至少一个通用API，至少一个脚本API与至少一个通用API具有映射关系；生成模块用于根据至少一个脚本API与至少一个通用API之间的映射关系，对脚本和静态部分进行组合，以生成目标签名算法；编译模块用于编译目标签名算法。
第三方面，提供一种电子设备，包括：处理器和存储器，该存储器用于存储计算机程序，该处理器用于调用并运行该存储器中存储的计算机程序，执行如第一方面或其各实现方式中的方法。
第四方面，提供一种计算机可读存储介质，用于存储计算机程序，计算机程序使得计算机执行如第一方面或其各实现方式中的方法。
第五方面，提供一种计算机程序产品，包括计算机程序指令，该计算机程序指令使得计算机执行如第一方面或其各实现方式中的方法。
第六方面，提供一种计算机程序，计算机程序使得计算机执行如第一方面或其各实现方式中的方法。
综上，通过本申请技术方案，在边缘服务器静态编译的软件上，可热插拔地植入签名算法的动态部分对应的脚本，从而可以提高签名算法的加载效率。另外，从整个CDN分发系统来看，可以提高整个CDN中的签名算法加载效率，使得用户接入或者业务适配的效率得到了提升。
进一步的，本申请提供的动态加载方法可以在边缘服务器获取到HTTP请求之前进行，也就是上述目标签名算法的加载过程是一个预加载过程，该加载过程涉及的封装目标签名算法的静态部分的至少一个通用API可以被称为预封装过程，编译目标签名算法也是一种预编译过程，从而可以进一步的提高签名算法的加载效率。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的一种CDN分发系统架构图；
图2为本申请实施例提供的一种签名算法的动态加载方法的流程图；
图3为本申请实施例提供的至少一个脚本API与至少一个通用API之间的映射关系的示意图；
图4为本申请实施例提供的一种签名算法的使用方法的流程图；
图5为本申请实施例提供的一种脚本预加载过程的示意图；
图6为本申请实施例提供的KFC600的示意图；
图7是本申请实施例提供的电子设备700的示意性框图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。
需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
CDN是构建在网络上的内容分发网络，依靠部署在各地边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率，核心技术是内容存储和分发技术。
应理解的是，在本申请中，边缘服务器也被称为缓存服务器、CDN边缘服务器、CDN缓存服务器、边缘节点或者CDN边缘节点等，本申请对此不做限制。
示例性的，图1为本申请实施例提供的一种CDN分发系统架构图，如图1所示，假设 全球有N个数据中心，在这些数据中心里部署多台缓存服务器，形成缓存集群系统来缓存部分数据，用户访问数据就可以就近访问了。边缘服务器数目众多，最贴近用户，但是规模小，缓存的数据少，会出现用户无法命中的情况，那边缘服务器之上就需要部署区域节点，规模比边缘服务器更大，缓存数据更多；在区域服务器之上就是中心服务器，规模更大，缓存数据更多，如果还没有命中，只能回源到源站访问数据了。
需要说明的是，图1所示的CDN分发系统仅是一种示例，实际上，CDN分发系统可以包括：至少一层服务器即可，例如：该CDN分发系统只包括一层边缘服务器，当用户无法命中时，直接可以回源到源站访问数据了。再例如：该CDN分发系统包括一层边缘服务器和一层区域服务器，当用户无法在边缘服务器命中时，先去区域服务器获取数据，如果在区域服务器也未名中国，那么直接可以回源到源站访问数据了。
应理解的是，在本申请中，区域服务器也被称为区域节点、CDN区域服务器、CDN区域节点等，本申请对此不做限制。
应理解的是，在本申请中，中心服务器也被称为总节点、CDN中心服务器、CDN总节点等，本申请对此不做限制。
应理解的是，源站可以是万维网(World Wide Web，WWW)服务器。
如上所述，用户访问网站的过程可以如下：客户端通过SK和签名算法对URL进行签名，将得到的签名、URL和AK携带在HTTP请求中，该客户端对应的边缘服务器接收到HTTP请求后，确定该AK对应的SK，并通过签名算法和该SK对该URL进行签名，对得到的签名和HTTP请求中携带的签名进行比对，以验证该URL的真实性，如果URL是真实的，则边缘服务器发送HTTP响应，或者，当边缘服务器本地未保存用户所需的数据时，则会回源至源站获取用户所需的数据。
应理解的是，这里的签名算法可以是任何签名算法，例如：哈希消息认证码(Hash-based Message Authentication Code，HMAC)、消息摘要算法(Message-Digest Algorithm，MD5)等，本申请对此不做限制。
应理解的是，上述AK是一种公共密钥(Public Key，PK)。
应理解的是，URL包括：协议部分、域名部分、端口部分、文件名部分、锚部分、参数部分。例如：假设URL为http://www.aspxfans.com:8080/news/index.asp？boardID＝5&ID＝24618&page＝1#name，该URL的协议部分为“http：”，这代表网页使用的是HTTP协议。在Internet中可以使用多种协议，如HTTP，文件传输协议(File Transfer Protocol，FTP)等等，该例子中使用的是HTTP协议。在"HTTP"后面的“//”为分隔符，该URL的域名部分为“www.aspxfans.com”。一个URL中，也可以使用IP地址作为域名使用。从域名后的第一个“/”开始到最后一个“/”为止，是 虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是“/news/”。从域名后的最后一个“/”开始到“？”为止，是文件名部分，如果没有“？”,则是从域名后的最后一个“/”开始到“#”为止，是文件部分，如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名。从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分。从“？”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。本例中的参数部分为“boardID＝5&ID＝24618&page＝1”。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。
HTTP用于从Web服务器传输超文本到本地浏览器的传送协议，HTTP是一个基于传输控制协议/因特网互联协议(Transmission Control Protocol/Internet Protocol，TCP/IP)通信协议来传递数据，如超文本标记语言(Hyper Text Markup Language，HTML)文件、图片文件、查询结果等。HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。HTTP协议工作于客户端-服务端架构为上。浏览器作为HTTP客户端通过URL向HTTP服务端即Web服务器发送所有请求，即HTTP请求。Web服务器根据接收到的请求后，向客户端发送响应信息，即HTTP响应。
HTTP请求一般包括如下四部分：第一部分：请求行，用来说明请求类型,要访问的资源以及所使用的HTTP版本；第二部分：请求头部(Header)，紧接着请求行(即第一行)之后的部分，用来说明服务器要使用的附加信息。第三部分：空行，请求头部后面的空行是必须的。第四部分：请求数据也叫主体，可以添加任意的其他数据。
HTTP响应一般包括如下四部分：状态行、消息报头、空行和响应正文。
如上所述，目前签名算法是以传统的硬编码方式植入对应的边缘服务器中，然而，一方面，当某一台边缘服务器需要加载某签名算法时，如果按照这种传统的硬编码方式植入该签名算法，导致签名算法加载效率较低的问题。另一方面，在一些场景中，不同的客户端可能采用的签名算法不同，也就是客户端可能需要定制化的签名算法，而CDN中存在海量的边缘服务器，如果这种需要定制化的签名算法的客户端对应的边缘服务器都按照传统的硬编码方式植入签名算法，导致整个CDN中的签名算法加载效率较低的问题，最终导致用户接入或者业务适配的效率上存在明显的瓶颈。
为了解决上述技术问题，本申请提供一种签名算法的动态加载方法、装置、设备及存储介质，在边缘服务器在静态编译的软件上，可热插拔地植入签名算法的动态部分对应的脚本，从而可以提高签名算法的加载效率。另外，从整个CDN分发系统来看，可以提高整个CDN中的签名算法加载效率，使得用户接入或者业务适配的效率得到了提升。
下面将对本申请技术方案进行详细阐述：
图2为本申请实施例提供的一种签名算法的动态加载方法的流程图，其中该方法应用于待加载目标签名算法的边缘服务器，可选的，该边缘服务器可以采用GO构建，但不限于此。需要说明的是，这里的加载可以被理解为该边缘服务器首次加载目标签名算法，或者被理解为该边缘服务器已删除旧版本的目标签名算法，首次加载新版本的目标签名算法等。如图2所示，该方法包括如下步骤：
S210：获取目标签名算法的动态部分对应的脚本，该脚本包括：至少一个脚本应用程序接口(Application Programming Interface，API)。
S220：封装目标签名算法的静态部分的至少一个通用API，至少一个脚本API与至少一个通用API具有映射关系。
S230：根据至少一个脚本API与至少一个通用API之间的映射关系，对脚本和静态部分进行组合，以生成目标签名算法。
S240：编译目标签名算法。
可选的，本申请技术方案的应用场景可以如下，但不限于此：
场景一：某用户调整了业务逻辑，期望使用另外一套算法规则，即上述的目标签名算法。
场景二：某用户是新接入用户，提出了自己的业务逻辑，比如用私有加密算法，如上述的目标签名算法。
应理解的是，该目标签名算法可以是待加载的任一签名算法，例如：该目前签名算法可以是待加载的HMAC算法或者MD5算法等，本申请对此不做限制。
示例性的，用户A调整了业务逻辑，使用客户端请求的header["a"],header["b"]，以及问号串中的arg["a"]，通过"\t"分隔拼接起来，期望使用目标签名算法，即HMAC算法进行签名，最终可以将签名保存到请求头["c"]中。
示例性的，用户B是新接入用户，使用客户端请求的header["c"]，以及HTTP协议，通过"\n"分隔拼接起来，通过目标签名算法，即MD5算法进行签名，最终可以将签名保存到问号串["xx"]中。
应理解的是，目标签名算法中通常涉及一些通用的函数，如查询(Query)函数、主机(Host)查询函数、头部(Header)增加函数、头部(Header)删除函数、头部(Header)修改函数、头部(Header)查询函数、HTTP协议查询函数、加密计算函数、业务参数查询函数等，这些通用的函数构成该目标签名算法的静态部分，也就是该目标签名函数的不变部分。
相反的，每个签名算法之间存在一定的差异，或者，即使针对同一目标签名算法，针 对不同的用户可能稍有不同，即目标签名算法可以是一种定制化的签名算法，这部分内容就是目标签名算法的动态部分，该动态部分可以是该目标签名算法中的一些动态参数、动态逻辑等。该动态部分也被称为目标签名算法的可变部分。
可选的，边缘服务器可以按照上述脚本的各个功能模块的划分情况，封装该脚本的至少一个脚本API，例如：脚本API1对应的功能模块包括：字符串转大写的参数，脚本API2对应的功能模块包括：字符串转小写的参数。
可选的，上述脚本可以是Lua脚本，基于此，本申请中的脚本API也可以被称为Lua API。
可选的，边缘服务器可以按照目标签名算法的静态部分的各个功能模块的划分情况，封装该静态部分的至少一个通用API，例如：通用API1对应的功能模块用于完成字符串转大写的操作，脚本API2对应的功能模块用于完成字符串转小写的操作。
可选的，如上所述，边缘服务器可以采用GO构建，基于此，本申请中的通用API也可以被称为GO API。
可选的，边缘服务器可以建立上述至少一个脚本API与至少一个通用API之间的映射关系，或者也可以是智能设备，如其他服务器建立上述至少一个脚本API与至少一个通用API之间的映射关系，并发送给该边缘服务器，本申请对此不做限制。示例性的，图3为本申请实施例提供的至少一个脚本API与至少一个通用API之间的映射关系的示意图，如图3所示，这里的至少一个脚本API与至少一个通用API之间的映射关系是一一对应关系，例如：脚本API1对应的功能模块包括：字符串转大写的参数，脚本API2对应的功能模块包括：字符串转小写的参数。通用API1对应的功能模块用于完成字符串转大写的操作，脚本API2对应的功能模块用于完成字符串转小写的操作。那么脚本API1与通用API1对应，脚本API2与通用API2对应。
应理解的是，至少一个脚本API与至少一个通用API之间的映射关系不限于一一对应关系，例如是多对一的映射关系，或者是一对多，又或者是多对多的映射关系，本申请对此不做限制。
进一步的，边缘服务器在获取到至少一个脚本API与所述至少一个通用API之间的映射关系之后，可以根据该映射关系对脚本和该静态部分进行组合，以生成目标签名算法。例如：边缘服务器将按照该映射关系，将脚本中的动态参数通过脚本API传递给该API对应的通用API，然后通过该通用API将该动态参数传递给对应的通用函数。再例如：边缘服务器将按照该映射关系，将脚本中的动态逻辑通过脚本API传递给该API对应的通用API，然后通过该通用API将该动态逻辑传递给对应的通用函数。又例如：边缘服务器将按照该映射关系，将脚本中的动态参数和动态逻辑通过脚本API传递给该API对应的通用API，然后通过该通用API将该动态参数和动态逻辑传递给对应的通用函数。或者，例如： 边缘服务器将按照该映射关系，将静态部分的通用函数通过对应的通用API传递给脚本API，然后通过该脚本API将该通用函数传递给脚本，这时脚本就有了通用函数以及动态参数，或者，通用函数以及动态逻辑，又或者，通用函数以及动态参数、动态逻辑。
示例性的，假设脚本API1对应的功能模块包括：字符串转大写的参数，脚本API2对应的功能模块包括：字符串转小写的参数。通用API1对应的功能模块用于完成字符串转大写的操作，脚本API2对应的功能模块用于完成字符串转小写的操作。脚本API1与通用API1对应，脚本API2与通用API2对应。边缘服务器根据脚本API1与通用API1的对应关系，可以将字符串转小写的参数通过脚本API1传输给通用API1，从而可以实现目标签名算法中的字符串转小写的功能。类似的，边缘服务器根据脚本API2与通用API2的对应关系，可以将字符串转大写的参数通过脚本API2传输给通用API2，从而可以实现目标签名算法中的字符串转大写的功能。
进一步的，在边缘服务器生成目标签名算法之后，其需要将目标签名算法转化为可以识别的内容，即需要编译目标签名算法。
综上，在本申请中，边缘服务器可以获取目标签名算法的动态部分对应的脚本，该脚本包括：至少一个脚本API，封装目标签名算法的静态部分的至少一个通用API，至少一个脚本API与至少一个通用API具有映射关系，根据至少一个脚本API与至少一个通用API之间的映射关系，对脚本和静态部分进行组合，以生成目标签名算法，编译目标签名算法。即在边缘服务器静态编译的软件上，可热插拔地植入签名算法的动态部分对应的脚本，从而可以提高签名算法的加载效率。另外，从整个CDN分发系统来看，可以提高整个CDN中的签名算法加载效率，使得用户接入或者业务适配的效率得到了提升。
进一步的，本申请提供的动态加载方法可以在边缘服务器获取到HTTP请求之前进行，也就是上述目标签名算法的加载过程是一个预加载过程，该加载过程涉及的封装目标签名算法的静态部分的至少一个通用API可以被称为预封装过程，编译目标签名算法也是一种预编译过程，从而可以进一步的提高签名算法的加载效率。
可选的，边缘服务器还可以将目标签名算法的标识以及编译结果存储至哈希表中。
应理解的是，该目标签名算法的标识和该目标签名算法对应的编译结果也可以不以哈希表的表项的形式存储，本申请对任何签名算法的编译结果以及标识的存储方式不做限制。
可选的，该目标签名算法的标识是该目标签名算法的名称，又或者是该目标签名算法的动态部分对应的脚本的名称，这是因为每个签名算法的唯一性或者定制化主要体现在动态部分对应的脚本上，因此，通过脚本的名称也可以唯一标识签名算法。
图4为本申请实施例提供的一种签名算法的使用方法的流程图，其中该方法应用于已加载目标签名算法的边缘服务器，可选的，该边缘服务器可以采用GO构建，但不限于此。 如图4所示，该方法包括如下步骤：
S410：获取客户端发送HTTP请求，HTTP请求包括：URL、第一签名、AK，第一签名是URL经过目标签名算法和SK签名后得到的。
S420：确定AK对应的SK。
S430：在哈希表中查找目标签名算法。
S440：根据目标签名算法和私钥对URL进行签名，以得到第二签名。
S450：根据第一签名和第二签名验证URL的真实性。
需要说明的是，本申请对如何根据目标签名算法和SK对URL进行签名不做限制。
应理解的是，SK与AK具有对应关系，二者是一对公私钥，即通过AK可以确定SK。
应理解的是，第一签名是客户端根据目标签名算法和SK对URL进行签名得到的签名。而第二签名是边缘服务器根据目标签名算法和SK对URL进行签名得到的签名。如果第一签名和第二签名相同，则表示该URL是真实的，如果第一签名和第二签名不同，则表示该URL不是真实的。
可选的，客户端可以决定自己所需的签名算法，即上述客户端对应的签名算法，接着将其对应的签名算法可以通知给边缘服务器，或者，边缘服务器可以根据客户端的域名配置确定客户端对应的签名算法是目标签名算法。总之，本申请对边缘服务器如何确定客户端对应的签名算法不做限制。
可选的，客户端的域名配置包括：客户端需要使用的签名算法，即上述客户端对应的签名算法。
可选的，该客户端的域名配置还包括以下至少一项：密钥参数、业务逻辑、客户端对应的签名算法的过期时间等。其中，该密钥参数包括：AK和SK，但不限于此。
可选的，针对一层结构的CDN分发系统，即该CDN分发系统只包括边缘服务器，而不包括区域服务器以及中心服务器。若验证URL是真实的，则边缘服务器判断本地是否缓存URL对应的访问数据，如HTML文件、图片文件、查询结果等。若本地缓存有URL对应的访问数据，则边缘服务器向客户端发送访问数据，该访问数据可以携带在HTTP响应中。若本地未缓存URL对应的访问数据，则该边缘服务器根据第二签名进行回源，即将第二标签发送给源站。
可选的，针对两层结构的CDN分发系统，即该CDN分发系统包括边缘服务器和区域服务器。若验证URL是真实的，则边缘服务器判断本地是否缓存URL对应的访问数据，如HTML文件、图片文件、查询结果等。若本地缓存有URL对应的访问数据，则边缘服务器向客户端发送访问数据，该访问数据可以携带在HTTP响应中。若本地未缓存URL对应的访问数据，这时该边缘服务器先将第二标签发送给其对应的区域服务器，接着区域服 务器查看其本地是否缓存URL对应的访问数据。若本地缓存有URL对应的访问数据，则区域服务器向客户端发送访问数据。若本地未缓存URL对应的访问数据，这时该区域服务器根据第二签名进行回源，即将第二标签发送给源站。
可选的，针对三层结构的CDN分发系统，即该CDN分发系统包括边缘服务器、区域服务器和中心服务器。若验证URL是真实的，则边缘服务器判断本地是否缓存URL对应的访问数据，如HTML文件、图片文件、查询结果等。若本地缓存有URL对应的访问数据，则边缘服务器向客户端发送访问数据，该访问数据可以携带在HTTP响应中。若本地未缓存URL对应的访问数据，这时该边缘服务器先将第二标签发送给其对应的区域服务器，接着区域服务器查看其本地是否缓存URL对应的访问数据。若本地缓存有URL对应的访问数据，则区域服务器向客户端发送访问数据。若本地未缓存URL对应的访问数据，这时该区域服务器先将第二标签发送给中心服务器，接着中心服务器查看其本地是否缓存URL对应的访问数据。若本地缓存有URL对应的访问数据，则中心服务器向客户端发送访问数据。若本地未缓存URL对应的访问数据，这时该中心服务器根据第二签名进行回源，即将第二标签发送给源站。
需要说明的是，本申请对CDN分发系统的结构不做限制，相应的，对如何向客户端发送访问数据不做限制。
可选的，上述签名算法的动态加载方法可以具体由边缘服务器中的至少一个处理器或者至少一个芯片执行，例如：该方法可以由边缘服务器中的简洁、易用、高效缓存(KISS and Fast Cache，KFC)执行，KISS表示简洁、易用(Keep It Simple and Stupid)。
如上所述，目标密钥算法可以预加载至边缘服务器，而该目标密钥算法中的动态部分的脚本是该目标密钥算法的一部分，因此，可以理解该脚本也被预加载至边缘服务器。示例性的，图5为本申请实施例提供的一种脚本预加载过程的示意图，如图5所示，脚本1中包括：脚本API1、脚本API2和脚本API3，通过这些API可以将脚本1预加载至KFC中，进一步的，KFC可以对目标密钥算法进行编译，最终将编译结果存储至哈希表中，如图5所示，该哈希表中存储了脚本1的标识以及对应的编译结果1，在本申请中，编译结果可以是二进制数值。可选的，该哈希表中还可以存储其他密钥算法的标识和对应的编译结果，例如：如图5所示，该哈希表中还存储了脚本2的标识以及对应的编译结果2。
可选的，该KFC中可以包括如下的功能模块，但不限于此：HTTP接入模块、回源模块、监听模块和存储模块。示例性的，图6为本申请实施例提供的KFC600的示意图，如图6所示，KFC600中的监听模块610负责监听脚本文件目录下脚本是否有变化，例如：监听模块610监听该目录下是否增加了新的签名算法或者是否有签名算法发生了更新，如果该目录下新增了签名算法或者有签名算法发生了更新，那么监听模块610按照上述监听算 法的动态加载方法，完成该签名算法的加载，并对该签名算法的编译结果存储至存储模块620中。
可选的，该签名算法的标识以及该签名算法对应的编译结果可以存储在哈希表中，而该哈希表被存储在存储模块620中。
应理解的是，该签名算法对应的编译结果也可以不以哈希表的表项的形式存储，本申请对签名算法的编译结果的存储方式不做限制。
可选的，上述签名算法的标识是该签名算法的名称，又或者是该签名算法的脚本的名称，这是因为每个签名算法的唯一性或者定制化主要体现在动态部分对应的脚本上，因此，通过脚本的名称也可以唯一标识签名算法。
可选的，KFC中的HTTP接入模块630可以获取HTTP请求，该HTTP请求包括：URL、第一签名、AK，第一签名是URL经过目标签名算法和SK签名后得到的，并将该HTTP请求发送给回源模块640，该回源模块640用于确定AK对应的SK，并在哈希表中查找目标签名算法，根据目标签名算法和私钥对URL进行签名，以得到第二签名，根据第一签名和第二签名验证URL的真实性。如果第一签名和第二签名相同，则表示该URL是真实的，如果第一签名和第二签名不同，则表示该URL不是真实的。进一步的，该回源模块640可以查看存储模块620是否缓存URL对应的访问数据，如果本地缓存了URL对应的访问数据，则回源模块640向客户端发送访问数据，若本地没有缓存URL对应的访问数据，则回源模块640根据第二签名进行回源，即将第二标签发送给源站。需要说明的是，这里假设CDN分发系统采用的一层结构的情况，当然，该CDN分发系统也可以采用多层结构，如果采用多层结构，那么回源模块640上文记载的返回访问数据或者将其第二标签发送给上层服务器，直至客户端获取到访问数据为止。
通过本申请提供的技术方案，签名算法由原先上万个机器的滚动升级，到一键全网推送脚本瞬间即完成升级，升级效率提升100倍以上。并且通过本申请提供的技术方案，降低了CPU消耗负担，且对访问质量几乎无影响。
上文结合图1至图6，详细描述了本申请的方法实施例，下文结合图7，详细描述本申请的装置实施例，应理解，装置实施例与方法实施例相互对应，类似的描述可以参照方法实施例。
本申请实施例还提供一种签名算法的动态加载装置。该动态加载装置包括：第一获取模块、封装模块、生成模块和编译模块，其中，第一获取模块用于获取目标签名算法的动态部分对应的脚本，脚本包括：至少一个脚本API。封装模块用于封装目标签名算法的静态部分的至少一个通用API，至少一个脚本API与至少一个通用API具有映射关系。生成模块用于根据至少一个脚本API与至少一个通用API之间的映射关系，对脚本和静态部分 进行组合，以生成目标签名算法。编译模块用于编译目标签名算法。
可选的，该动态加载装置还包括：存储模块，用于在编译模块编译目标签名算法之后，将目标签名算法的标识和目标签名算法的编译结果存储至哈希表中。
可选的，该动态加载装置还包括：第二获取模块、第一确定模块、查找模块、签名模块、第二获取模块、第一确定模块、查找模块、签名模块和验证模块，其中，第二获取模块用于获取客户端发送的HTTP请求，HTTP请求包括：URL、第一签名、访问密钥，第一签名是URL经过目标签名算法和私钥签名后得到的。第一确定模块用于确定访问密钥对应的私钥。查找模块用于在哈希表中查找目标签名算法。签名模块用于根据目标签名算法和私钥对URL进行签名，以得到第二签名。验证模块用于根据第一签名和第二签名验证URL的真实性。
可选的，该动态加载装置还包括：第三获取模块、第二确定模块，其中，第三获取模块用于查找模块在在哈希表中查找目标签名算法之前，获取客户端的域名配置。第二确定模块用于根据客户端的域名配置确定客户端对应的签名算法是目标签名算法。
可选的，该动态加载装置还包括：判断模块、发送模块和回源模块，其中，判断模块用于若验证URL是真实的，则判断本地是否缓存URL对应的访问数据。发送模块用于若本地缓存有URL对应的访问数据，则向客户端发送访问数据。回源模块用于若本地未缓存URL对应的访问数据，则根据第二签名进行回源。
可选的，验证模块具体用于：若第一签名和第二签名相同，则确定URL真实。若第一签名和第二签名不相同，则确定URL不真实。
可选的，目标签名算法的标识是目标签名算法的名称或者脚本的名称。
可选的，该签名算法的动态加载装置采用GO构建。
应理解的是，装置实施例与方法实施例可以相互对应，类似的描述可以参照方法实施例。为避免重复，此处不再赘述。具体地，该签名算法的动态加载装置可以执行上述方法实施例，并且该签名算法的动态加载装置中的各个模块的前述和其它操作和/或功能分别为了上述方法实施例中的各个方法中的相应流程，为了简洁，在此不再赘述。
上文中结合附图从功能模块的角度描述了本申请实施例的动态加载装置。应理解，该功能模块可以通过硬件形式实现，也可以通过软件形式的指令实现，还可以通过硬件和软件模块组合实现。具体地，本申请实施例中的方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路和/或软件形式的指令完成，结合本申请实施例公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。可选地，软件模块可以位于随机存储器，闪存、只读存储器、可编程只读存储器、电可擦写可编程存储器、寄存器等本领域的成熟的存储介质中。该存储介质位于存储器，处理器 读取存储器中的信息，结合其硬件完成上述方法实施例中的步骤。
图7是本申请实施例提供的电子设备700的示意性框图，该电子设备700可用作边缘服务器。
如图7所示，该电子设备700可包括：
存储器710和处理器720，该存储器710用于存储计算机程序，并将该程序代码传输给该处理器720。换言之，该处理器720可以从存储器710中调用并运行计算机程序，以实现本申请实施例中的方法。
例如，该处理器720可用于根据该计算机程序中的指令执行上述方法实施例。
在本申请的一些实施例中，该处理器720可以包括但不限于：
通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等等。
在本申请的一些实施例中，该存储器710包括但不限于：
易失性存储器和/或非易失性存储器。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double Data Rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synch link DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM，DR RAM)。
在本申请的一些实施例中，该计算机程序可以被分割成一个或多个模块，该一个或者多个模块被存储在该存储器710中，并由该处理器720执行，以完成本申请提供的方法。该一个或多个模块可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述该计算机程序在该电子设备中的执行过程。
如图7所示，该电子设备还可包括：
收发器730，该收发器730可连接至该处理器720或存储器710。
其中，处理器720可以控制该收发器730与其他设备进行通信，具体地，可以向其他设备发送信息或数据，或接收其他设备发送的信息或数据。收发器730可以包括发射机和 接收机。收发器730还可以进一步包括天线，天线的数量可以为一个或多个。
应当理解，该电子设备中的各个组件通过总线系统相连，其中，总线系统除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。
本申请还提供了一种计算机存储介质，其上存储有计算机程序，该计算机程序被计算机执行时使得该计算机能够执行上述方法实施例的方法。或者说，本申请实施例还提供一种包含指令的计算机程序产品，该指令被计算机执行时使得计算机执行上述方法实施例的方法。
当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机程序指令时，全部或部分地产生按照本申请实施例该的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，该计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如数字视频光盘(digital video disc，DVD))、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。
根据本公开的一个或多个实施例，提供一种签名算法的动态加载方法，包括：获取目标签名算法的动态部分对应的脚本，脚本包括：至少一个脚本API；封装目标签名算法的静态部分的至少一个通用API，至少一个脚本API与至少一个通用API具有映射关系；根据至少一个脚本API与至少一个通用API之间的映射关系，对脚本和静态部分进行组合，以生成目标签名算法；编译目标签名算法。
根据本公开的一个或多个实施例，编译目标签名算法之后，还包括：将目标签名算法的标识和目标签名算法的编译结果存储至哈希表中。
根据本公开的一个或多个实施例，将目标签名算法的标识和目标签名算法的编译结果存储至哈希表中之后，还包括：获取客户端发送的HTTP请求，HTTP请求包括：URL、第一签名、访问密钥，第一签名是URL经过目标签名算法和私钥签名后得到的；确定访问密钥对应的私钥；在哈希表中查找目标签名算法；根据目标签名算法和私钥对URL进行签名，以得到第二签名；根据第一签名和第二签名验证URL的真实性。
根据本公开的一个或多个实施例，在哈希表中查找目标签名算法之前，还包括：获取 客户端的域名配置；根据客户端的域名配置确定客户端对应的签名算法是目标签名算法。
根据本公开的一个或多个实施例，根据第一签名和第二签名验证URL的真实性之后，还包括：若验证URL是真实的，则判断本地是否缓存URL对应的访问数据；若本地缓存有URL对应的访问数据，则向客户端发送访问数据；若本地未缓存URL对应的访问数据，则根据第二签名进行回源。
根据本公开的一个或多个实施例，根据第一签名和第二签名验证URL的真实性，包括：若第一签名和第二签名相同，则确定URL真实；若第一签名和第二签名不相同，则确定URL不真实。
根据本公开的一个或多个实施例，目标签名算法的标识是目标签名算法的名称或者脚本的名称。
根据本公开的一个或多个实施例，方法应用于边缘服务器中，边缘服务器采用GO构建。
根据本公开的一个或多个实施例，提供一种签名算法的动态加载装置，包括：第一获取模块、封装模块、生成模块和编译模块，其中，第一获取模块用于获取目标签名算法的动态部分对应的脚本，脚本包括：至少一个脚本API。封装模块用于封装目标签名算法的静态部分的至少一个通用API，至少一个脚本API与至少一个通用API具有映射关系。生成模块用于根据至少一个脚本API与至少一个通用API之间的映射关系，对脚本和静态部分进行组合，以生成目标签名算法。编译模块用于编译目标签名算法。
根据本公开的一个或多个实施例，该动态加载装置还包括：存储模块，用于在编译模块编译目标签名算法之后，将目标签名算法的标识和目标签名算法的编译结果存储至哈希表中。
根据本公开的一个或多个实施例，该动态加载装置还包括：第二获取模块、第一确定模块、查找模块、签名模块、第二获取模块、第一确定模块、查找模块、签名模块和验证模块，其中，第二获取模块用于获取客户端发送的HTTP请求，HTTP请求包括：URL、第一签名、访问密钥，第一签名是URL经过目标签名算法和私钥签名后得到的。第一确定模块用于确定访问密钥对应的私钥。查找模块用于在哈希表中查找目标签名算法。签名模块用于根据目标签名算法和私钥对URL进行签名，以得到第二签名。验证模块用于根据第一签名和第二签名验证URL的真实性。
根据本公开的一个或多个实施例，该动态加载装置还包括：第三获取模块、第二确定模块，其中，第三获取模块用于查找模块在在哈希表中查找目标签名算法之前，获取客户端的域名配置。第二确定模块用于根据客户端的域名配置确定客户端对应的签名算法是目标签名算法。
根据本公开的一个或多个实施例，该动态加载装置还包括：判断模块、发送模块和回源模块，其中，判断模块用于若验证URL是真实的，则判断本地是否缓存URL对应的访问数据。发送模块用于若本地缓存有URL对应的访问数据，则向客户端发送访问数据。回源模块用于若本地未缓存URL对应的访问数据，则根据第二签名进行回源。
根据本公开的一个或多个实施例，验证模块具体用于：若第一签名和第二签名相同，则确定URL真实。若第一签名和第二签名不相同，则确定URL不真实。
根据本公开的一个或多个实施例，目标签名算法的标识是目标签名算法的名称或者脚本的名称。
根据本公开的一个或多个实施例，该签名算法的动态加载装置采用GO构建。
根据本公开的一个或多个实施例，提供一种电子设备，包括：处理器和存储器，存储器用于存储计算机程序，处理器用于调用并运行存储器中存储的计算机程序，以执行上述签名算法的动态加载方法。
根据本公开的一个或多个实施例，提供一种计算机可读存储介质，用于存储计算机程序，计算机程序使得计算机执行上述签名算法的动态加载方法。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的模块及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，该模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。
作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。例如，在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。
以上该，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在 本申请的保护范围之内。因此，本申请的保护范围应以该权利要求的保护范围为准。

Claims (11)

  1. 一种签名算法的动态加载方法，其特征在于，包括：
    获取目标签名算法的动态部分对应的脚本，所述脚本包括：至少一个脚本应用程序接口API；
    封装所述目标签名算法的静态部分的至少一个通用API，所述至少一个脚本API与所述至少一个通用API具有映射关系；
    根据所述至少一个脚本API与所述至少一个通用API之间的映射关系，对所述脚本和所述静态部分进行组合，以生成所述目标签名算法；
    编译所述目标签名算法。
  2. 根据权利要求1所述的方法，其特征在于，所述编译所述目标签名算法之后，还包括：
    将所述目标签名算法的标识和所述目标签名算法的编译结果存储至哈希表中。
  3. 根据权利要求2所述的方法，其特征在于，所述将所述目标签名算法的标识和所述目标签名算法的编译结果存储至哈希表中之后，还包括：
    获取客户端发送的超文本传输协议HTTP请求，所述HTTP请求包括：统一资源定位符URL、第一签名、访问密钥，所述第一签名是所述URL经过所述目标签名算法和私钥签名后得到的；
    确定所述访问密钥对应的所述私钥；
    在所述哈希表中查找所述目标签名算法；
    根据所述目标签名算法和所述私钥对所述URL进行签名，以得到第二签名；
    根据所述第一签名和所述第二签名验证所述URL的真实性。
  4. 根据权利要求3所述的方法，其特征在于，所述在所述哈希表中查找所述目标签名算法之前，还包括：
    获取所述客户端的域名配置；
    根据所述客户端的域名配置确定所述客户端对应的签名算法是所述目标签名算法。
  5. 根据权利要求3或4所述的方法，其特征在于，所述根据所述第一签名和所述第二签名验证所述URL的真实性之后，还包括：
    若验证所述URL是真实的，则判断本地是否缓存所述URL对应的访问数据；
    若本地缓存有所述URL对应的访问数据，则向所述客户端发送所述访问数据；
    若本地未缓存所述URL对应的访问数据，则根据所述第二签名进行回源。
  6. 根据权利要求3或4所述的方法，其特征在于，所述根据所述第一签名和所述第二签名验证所述URL的真实性，包括：
    若所述第一签名和所述第二签名相同，则确定所述URL真实；
    若所述第一签名和所述第二签名不相同，则确定所述URL不真实。
  7. 根据权利要求2-4任一项所述的方法，其特征在于，所述目标签名算法的标识是所述目标签名算法的名称或者所述脚本的名称。
  8. 根据权利要求1-4任一项所述的方法，其特征在于，所述方法应用于边缘服务器中，所述边缘服务器采用GO构建。
  9. 一种签名算法的动态加载装置，其特征在于，包括：
    第一获取模块，用于获取目标签名算法的动态部分对应的脚本，所述脚本包括：至少一个脚本API；
    封装模块，用于封装所述目标签名算法的静态部分的至少一个通用API，所述至少一个脚本API与所述至少一个通用API具有映射关系；
    生成模块，用于根据所述至少一个脚本API与所述至少一个通用API之间的映射关系，对所述脚本和所述静态部分进行组合，以生成所述目标签名算法；
    编译模块，用于编译所述目标签名算法。
  10. 一种电子设备，其特征在于，包括：
    处理器和存储器，所述存储器用于存储计算机程序，所述处理器用于调用并运行所述存储器中存储的计算机程序，以执行权利要求1至8中任一项所述的方法。
  11. 一种计算机可读存储介质，其特征在于，用于存储计算机程序，所述计算机程序使得计算机执行如权利要求1至8中任一项所述的方法。
PCT/CN2022/094381 2021-06-30 2022-05-23 签名算法的动态加载方法、装置、设备及存储介质 Ceased WO2023273693A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US18/562,163 US12432074B2 (en) 2021-06-30 2022-05-23 Dynamic loading method and apparatus for signature algorithm, and device and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110733971.7 2021-06-30
CN202110733971.7A CN113378095B (zh) 2021-06-30 2021-06-30 签名算法的动态加载方法、装置、设备及存储介质

Publications (1)

Publication Number Publication Date
WO2023273693A1 true WO2023273693A1 (zh) 2023-01-05

Family

ID=77580284

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/094381 Ceased WO2023273693A1 (zh) 2021-06-30 2022-05-23 签名算法的动态加载方法、装置、设备及存储介质

Country Status (3)

Country Link
US (1) US12432074B2 (zh)
CN (1) CN113378095B (zh)
WO (1) WO2023273693A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118250010A (zh) * 2024-03-04 2024-06-25 北京中知智慧科技有限公司 一种基于国产化操作系统的签名验证方法

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113378095B (zh) * 2021-06-30 2023-08-04 抖音视界有限公司 签名算法的动态加载方法、装置、设备及存储介质
CN114880390A (zh) * 2022-05-19 2022-08-09 中国银行股份有限公司 一种数据加工方法及装置
CN115080059B (zh) * 2022-06-28 2024-09-13 北京火山引擎科技有限公司 边缘计算方法、装置和边缘服务器
CN116346446B (zh) * 2023-03-10 2026-02-10 天翼云科技有限公司 一种基于密钥的弹性文件系统鉴权方法和装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190362344A1 (en) * 2018-05-24 2019-11-28 Capital One Services, Llc Secure element to protect transactions made by or within a vehicle
CN111541542A (zh) * 2019-12-31 2020-08-14 远景智能国际私人投资有限公司 请求的发送和验证方法、装置及设备
CN111835523A (zh) * 2020-05-25 2020-10-27 北京齐尔布莱特科技有限公司 一种数据请求方法、系统及计算设备
CN113378095A (zh) * 2021-06-30 2021-09-10 北京字节跳动网络技术有限公司 签名算法的动态加载方法、装置、设备及存储介质

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7834784B1 (en) * 2007-01-18 2010-11-16 Cisco Technology, Inc. Data redundancy elimination mechanism including fast lookup of data patterns exhibiting spatial locality
US10289657B2 (en) * 2011-09-25 2019-05-14 9224-5489 Quebec Inc. Method of retrieving information elements on an undisplayed portion of an axis of information elements
WO2015142765A1 (en) * 2014-03-17 2015-09-24 Coinbase, Inc Bitcoin host computer system
US9772890B2 (en) * 2014-12-31 2017-09-26 International Business Machines Corporation Sophisticated run-time system for graph processing
US10410211B2 (en) * 2015-06-15 2019-09-10 Intel Corporation Virtual POS terminal method and apparatus
US9832024B2 (en) * 2015-11-13 2017-11-28 Visa International Service Association Methods and systems for PKI-based authentication
US10305871B2 (en) * 2015-12-09 2019-05-28 Cloudflare, Inc. Dynamically serving digital certificates based on secure session properties
CN105653933B (zh) * 2016-01-06 2019-04-30 北京京东尚科信息技术有限公司 插件加载方法及装置
US10867058B2 (en) * 2017-12-29 2020-12-15 Niall Joseph Duffy Method and system for protecting secure computer systems from insider threats
US10542003B1 (en) * 2018-06-28 2020-01-21 CallFire, Inc. Protected user information verification system
CN110190950B (zh) * 2019-06-11 2021-04-27 飞天诚信科技股份有限公司 一种安全签名的实现方法及装置
CN112434286B (zh) * 2020-11-12 2024-10-29 浙江大华技术股份有限公司 动态库的调用方法、装置、电子装置和存储介质
CN112989325A (zh) * 2021-03-12 2021-06-18 远光软件股份有限公司 服务调用方法、装置、存储介质和电子设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190362344A1 (en) * 2018-05-24 2019-11-28 Capital One Services, Llc Secure element to protect transactions made by or within a vehicle
CN111541542A (zh) * 2019-12-31 2020-08-14 远景智能国际私人投资有限公司 请求的发送和验证方法、装置及设备
CN111835523A (zh) * 2020-05-25 2020-10-27 北京齐尔布莱特科技有限公司 一种数据请求方法、系统及计算设备
CN113378095A (zh) * 2021-06-30 2021-09-10 北京字节跳动网络技术有限公司 签名算法的动态加载方法、装置、设备及存储介质

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118250010A (zh) * 2024-03-04 2024-06-25 北京中知智慧科技有限公司 一种基于国产化操作系统的签名验证方法

Also Published As

Publication number Publication date
CN113378095A (zh) 2021-09-10
US12432074B2 (en) 2025-09-30
US20240259215A1 (en) 2024-08-01
CN113378095B (zh) 2023-08-04

Similar Documents

Publication Publication Date Title
CN113378095B (zh) 签名算法的动态加载方法、装置、设备及存储介质
US9628554B2 (en) Dynamic content delivery
CN113886743B (zh) 缓存资源的刷新方法、装置及系统
US9479476B2 (en) Processing of DNS queries
US9021128B2 (en) Request routing using network computing components
US8713156B2 (en) Request routing based on class
US9930132B2 (en) Content specific router caching
CN111600909A (zh) 数据处理方法、装置、协议转换设备及存储介质
US9253278B2 (en) Using entity tags (ETags) in a hierarchical HTTP proxy cache to reduce network traffic
KR101560185B1 (ko) Ｕｒｌ을 이용한 분산 컨트롤 방법 및 장치
US9444780B1 (en) Content provided DNS resolution validation and use
CN110650112B (zh) 一种通用鉴权方法、装置及云服务网络系统
US10735528B1 (en) Geographic relocation of content source in a content delivery network
CN111917900A (zh) 一种域名代理的请求处理方法及装置
US10075553B1 (en) Systems and methods for automatically rewriting network page code
CN108259521A (zh) 热点资源共享方法及装置
WO2022057002A1 (zh) 一种异常请求处理方法和装置
WO2025246660A1 (zh) 通过原生应用加载网页应用内容的方法、装置、电子设备、计算机可读存储介质和计算机程序产品
CN106959975B (zh) 一种转码资源缓存处理方法、装置及设备
CN116366272B (zh) 资源处理方法、装置、服务器及存储介质
CN112866356B (zh) Cdn缓存方法、装置及电子设备
CN120316369A (zh) 网页资源的获取方法、装置、电子设备及存储介质
US12282667B1 (en) Metadata checking with zero storage overhead
HK40032087B (zh) 一种鉴权方法、装置、存储介质及计算机设备
CN119788636A (zh) 域名系统配置信息的更新方法、装置、设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22831517

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 18562163

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 220424)

122 Ep: pct application non-entry in european phase

Ref document number: 22831517

Country of ref document: EP

Kind code of ref document: A1

WWG Wipo information: grant in national office

Ref document number: 18562163

Country of ref document: US