HTTPS request acceleration method and device and computer readable medium

Abstract

The invention provides an HTTPS request acceleration method and device and a computer readable medium, and the method comprises the steps: a client device informs a server device of handshake negotiation information which needs to be used for recovering an HTTP session through session multiplexing information in a ClientHello message of TLS handshake; and the server device and the client device find the handshake negotiation information in respective shared spaces for multiplexing so as to recover the HTTP session, so that the mode of transmitting the handshake negotiation information through multiplexing logic of the protocol is replaced by a sharing mode, and the defect that the protocol switching cannot be realized due to different multiplexing logic after the protocol switching is overcome. According to the method and the device, the problem that the handshake negotiation information negotiated by the first complete handshake cannot be shared in the prior art is solved, so that the scheme can also realize rapid session recovery when the HTTP protocol is switched, the TLS complete handshake is prevented from being carried out again, the handshake negotiation delay of one RTT is reduced, the session recovery process is optimized, the processing efficiency of the HTTPS request is improved, and the access speed is higher.

Description

Technical Field

[0001] The present application relates to the field of information technology, and in particular to a HTTPS request acceleration method, device, and computer-readable medium. Background Art

[0002] HTTP3 (Hypertext Transfer Protocol 3) is the latest hypertext transfer protocol, built on top of the QUIC (Quick UDP Internet Connections) protocol. By using the QUIC protocol, HTTP3 not only provides faster connection establishment and data transmission speeds, but also provides better performance in unstable network environments, improving the performance and reliability of the entire Internet. Therefore, many cloud vendors currently support the HTTP3 protocol in their cloud services, allowing client devices using these cloud services to access server devices using older versions of HTTP2 and HTTP1 as well as the latest version of HTTP3.

[0003] When a client device initiates an HTTPS (HyperText Transfer Protocol Secure) request to a server device through the HTTP protocol, the first secure connection usually requires a complete TLS (Transport Layer Security) handshake process to complete the establishment of the HTTP session. When the same version of the HTTP protocol is used to initiate an HTTPS request subsequently, the handshake negotiation information negotiated during the previous TLS full handshake can be reused during the handshake process to directly restore the session and avoid performing a full TLS handshake again. However, if the client device subsequently initiates an HTTPS request and a protocol switch occurs, such as switching from HTTP3 to HTTP2, etc., due to the different reuse logic of different versions of the HTTP protocol, the handshake negotiation information negotiated before the version switch cannot be directly reused to restore the session, and a complete TLS handshake process needs to be performed again.

[0004] Therefore, compared with the scenario where the handshake negotiation information is directly reused to resume the session when the protocol is not switched, the session establishment process after the protocol switch will introduce an additional RTT (Round-Trip Time) to complete the negotiation process during the TLS full handshake, thereby reducing the processing efficiency of HTTPS requests and affecting access speed. Summary of the Invention

[0005] One purpose of the present application is to provide an HTTPS request acceleration method, device and computer-readable medium, at least to solve the problem in the prior art that a complete handshake needs to be re-performed after the HTTP protocol is switched, resulting in low processing efficiency and affecting access speed.

[0006] To solve the above problems, an embodiment of the present application provides a method for accelerating HTTPS requests, which is applied to a server device and includes:

[0007] receiving an HTTPS request initiated by a client, performing a TLS complete handshake with the client device based on a first HTTP protocol to establish an HTTP session, during which the server device and the client device jointly negotiate and determine handshake negotiation information for resuming the HTTP session, saving the handshake negotiation information in a first shared space, and sending the handshake negotiation information to the client device so that the client device saves the handshake negotiation information in a second shared space;

[0008] When performing a TLS handshake with the client device based on the second HTTP protocol, receiving a ClientHello message including session multiplexing information from the client device, where the session multiplexing information is determined by the client device according to handshake negotiation information received during the TLS full handshake;

[0009] According to the session reuse information in the ClientHello message, the corresponding handshake negotiation information is queried from the first shared space, and the TLS handshake is completed with the client device having the same handshake negotiation information according to the queried handshake negotiation information to resume the HTTP session.

[0010] The present application also provides an HTTP request acceleration method, which is applied to a client device and includes:

[0011] Initiate an HTTPS request to the server device, perform a TLS complete handshake with the server device based on the first HTTP protocol to establish an HTTP session, during which the client device obtains handshake negotiation information for resuming the HTTP session from the server device, and saves the handshake negotiation information in the second shared space, wherein the handshake negotiation information is determined by negotiation between the server device and the client device, and is saved by the server device in the first shared space;

[0012] When performing a TLS handshake with the server device based on the second HTTP protocol, handshake negotiation information is obtained from the second shared space, and a ClientHello message including session multiplexing information is sent to the server device. The session multiplexing information is determined by the client device based on the handshake negotiation information received during the TLS complete handshake, so that the server device queries the corresponding handshake negotiation information from the first shared space based on the session multiplexing information in the ClientHello message, and completes the TLS handshake with the client device having the same handshake negotiation information based on the queried handshake negotiation information to resume the HTTP session.

[0013] The present application also provides a server device for accelerating HTTP requests, the server device comprising:

[0014] a complete handshake module, configured to receive an HTTPS request initiated by a client, and perform a TLS complete handshake with the client device based on a first HTTP protocol to establish an HTTP session. During the TLS complete handshake, the server device and the client device jointly negotiate to determine handshake negotiation information for resuming the HTTP session, save the handshake negotiation information in a first shared space, and send the handshake negotiation information to the client device so that the client device saves the handshake negotiation information in a second shared space;

[0015] A multiplexing handshake module is used to receive a ClientHello message including session multiplexing information from the client device when performing a TLS handshake with the client device based on a second HTTP protocol, where the session multiplexing information is determined by the client device based on the handshake negotiation information received during the TLS complete handshake; and based on the session multiplexing information in the ClientHello message, query the corresponding handshake negotiation information from the first shared space, and complete the TLS handshake with the client device having the same handshake negotiation information based on the queried handshake negotiation information to restore the HTTP session.

[0016] The embodiment of the present application further provides a client device for accelerating HTTP requests, the client device comprising:

[0017] a complete handshake module, configured to initiate an HTTPS request to a server device, and perform a TLS complete handshake with the server device based on a first HTTP protocol to establish an HTTP session. During the TLS complete handshake, the client device obtains handshake negotiation information for resuming the HTTP session from the server device, and saves the handshake negotiation information in a second shared space. The handshake negotiation information is determined by negotiation between the server device and the client device, and saved by the server device in the first shared space.

[0018] A multiplexing handshake module is used to obtain handshake negotiation information from the second shared space when performing a TLS handshake with the server device based on the second HTTP protocol, and send a ClientHello message including session multiplexing information to the server device. The session multiplexing information is determined by the client device based on the handshake negotiation information received during the TLS complete handshake, so that the server device queries the corresponding handshake negotiation information from the first shared space based on the session multiplexing information in the ClientHello message, and completes the TLS handshake with the client device having the same handshake negotiation information based on the queried handshake negotiation information to restore the HTTP session.

[0019] In addition, an embodiment of the present application also provides a computing device, which includes a memory for storing computer program instructions and a processor for executing computer program instructions, wherein when the computer program instructions are executed by the processor, the device is triggered to execute the HTTP request acceleration method.

[0020] An embodiment of the present application also provides a computer-readable medium having computer program instructions stored thereon, and the computer program instructions can be executed by a processor to implement the HTTP request acceleration method.

[0021] Compared with the existing technology, in the HTTPS request acceleration solution provided by the embodiment of the present application, the server device and the client device perform a TLS complete handshake based on the first HTTP protocol. In the process of building an HTTP session, the server device will negotiate with the client device to determine the handshake negotiation information used to restore the HTTP session, save the handshake negotiation information in a first shared space, and send the handshake negotiation information to the client device. After obtaining the handshake negotiation information, the client device will save it in the second shared space for use in subsequent handshake reuse. When the client device initiates an HTTPS request again after switching to a different second HTTP protocol and performs a TLS handshake with the server device, there is no need to perform a TSL full handshake. The client device can obtain the negotiated handshake negotiation information from the second shared space and carry the session multiplexing information in the ClientHello message sent to the server device. The session multiplexing information is determined by the client device based on the handshake negotiation information received during the TLS full handshake. After receiving the ClientHello message carrying the session multiplexing information, the server device can query the corresponding handshake negotiation information from the shared space based on the session multiplexing information in the ClientHello message, and complete the TLS handshake between the client device and the client device with the same handshake negotiation information based on the queried handshake negotiation information to restore the HTTP session.

[0022] This solution does not use the conventional reuse logic of the HTTP protocol to implement HTTP session recovery. Instead, the client device uses session reuse information in the ClientHello message of the TLS handshake to inform the server device of the handshake negotiation information needed to restore the HTTP session. The server and client devices then find this handshake negotiation information in their respective shared spaces and reuse it to restore the HTTP session. This sharing method replaces the method of transmitting handshake negotiation information through the protocol's own reuse logic, overcoming the problem that the handshake negotiation information negotiated in the first full handshake cannot be shared due to different reuse logic after protocol switching. This allows this solution to achieve fast session recovery when the HTTP protocol is switched, avoiding a new TLS full handshake, reducing the handshake negotiation delay by 1 RTT, optimizing the session recovery process, improving the processing efficiency of HTTPS requests, and making access faster. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 A schematic diagram of the interaction process between a server device and a client device when implementing an HTTPS request acceleration method provided in an embodiment of the present application;

[0024] Figure 2This is a schematic diagram of the interaction process of a TLS complete handshake between a server device and a client device in an embodiment of the present application;

[0025] Figure 3 Schematic diagram of the handshake process when the server device and the client device resume the HTTP session by reusing the PSK in an embodiment of the present application;

[0026] Figure 4 A schematic diagram of the structure of a server-side device for accelerating HTTPS requests provided in an embodiment of the present application;

[0027] Figure 5 A schematic diagram of the structure of a client device for accelerating HTTPS requests provided in an embodiment of the present application;

[0028] Figure 6 This is a structural diagram of a computing device for implementing HTTPS request acceleration in an embodiment of the present application. DETAILED DESCRIPTION

[0029] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0030] In a typical configuration of the present application, the terminal and the equipment of the service network each include one or more processors (CPUs), input / output interfaces, network interfaces and memories.

[0031] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0032] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology for information storage. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc-read only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices or any other non-transmission medium that can be used to store information that can be accessed by a computing device.

[0033] The HTTPS request acceleration method provided by the embodiment of the present application is used to achieve rapid session recovery when the HTTP protocol is switched. In this method, the conventional multiplexing logic of the HTTP protocol is not used to achieve HTTP session recovery. Instead, the client device informs the server device of the handshake negotiation information needed to restore the HTTP session through session multiplexing information in the ClientHello message of the TLS handshake. The server device and the client device find this handshake negotiation information in their respective shared spaces for multiplexing, thereby restoring the HTTP session. In this way, the method of transmitting handshake negotiation information through the multiplexing logic of the protocol itself is replaced by sharing, overcoming the problem that the handshake negotiation information negotiated in the first full handshake cannot be shared due to different multiplexing logic after the protocol is switched. This allows the solution to achieve rapid session recovery when the HTTP protocol is switched, avoiding re-performing a full TLS handshake, reducing the handshake negotiation delay of 1 RTT, optimizing the session recovery process, improving the processing efficiency of HTTPS requests, and making access faster.

[0034] Among them, the client device is a device that initiates an HTTPS request, and its specific implementation may include but is not limited to various types of user terminal devices such as computers, mobile phones, and tablet computers. The server device may be a device that responds to the HTTPS request initiated by the client device, and its specific implementation may include but is not limited to various types of network devices such as network hosts, single network servers, multiple network server sets, or servers in a distributed cloud network. The distributed cloud network described herein is composed of a large number of hosts or network servers based on cloud computing (Cloud Computing). The distributed cloud network may be an edge cloud network, which can be based on the core of cloud computing technology and the ability of edge computing to build a cloud computing platform on the edge infrastructure to form an elastic cloud platform with comprehensive computing, networking, storage, security, application and other capabilities at the edge. It should be noted that the embodiments of the present application do not limit the specific type of network the distributed network is, and any network with a distributed architecture composed of multiple computing devices is applicable to the present application.

[0035] Figure 1 The following illustrates the interaction process between a server device and a client device when implementing an HTTPS request acceleration method provided in an embodiment of the present application, including the following steps:

[0036] In step S101, a client device initiates an HTTPS request to a server device. After receiving the HTTPS request initiated by the client, the server device performs a TLS full handshake with the client device based on the first HTTP protocol to establish an HTTP session. During the TLS full handshake, the server device and the client device jointly negotiate to determine handshake negotiation information for resuming the HTTP session, save the handshake negotiation information in a first shared space, and send the handshake negotiation information to the client device so that the client device saves the handshake negotiation information in a second shared space.

[0037] Among them, the handshake negotiation information is the multiplexing information necessary for realizing session recovery between the client device and the server device in the subsequent interaction process, and its specific form can be flexibly set according to the needs of the actual application scenario. For example, the handshake negotiation information may include a session identifier (session id), a session ticket (session ticket) or a pre-shared key (PSK), etc. In actual scenarios, any one of the above-mentioned forms of handshake negotiation information can be adopted according to the different versions of the TLS protocol used. For example, the TSL1.2 version protocol can use session id or session ticket as handshake negotiation information to realize session recovery in the subsequent interaction process, while in the TLS1.3 version protocol, PSK can be used as handshake negotiation information to realize session recovery in the subsequent interaction process.

[0038] Those skilled in the art should understand that the specific form of the handshake negotiation information described above is for illustrative purposes only, and that other existing or future forms based on similar principles, if applicable to the present application, should also be included within the scope of protection of the present application and incorporated herein by reference. For example, when using other versions of the TLS protocol or other protocols for ensuring transmission security, the corresponding form of handshake negotiation information can be used as the multiplexing information for subsequent session recovery.

[0039] The first shared space is a storage space used by the server device. The server device can save the handshake negotiation information jointly negotiated with the client device for resuming the HTTP session in the first shared space during the TLS full handshake process, and retrieve the handshake negotiation information from the first shared space for reuse during the subsequent HTTP session recovery process. The specific form of the first shared space may include the server device's memory, local disk, or storage cluster, etc.

[0040] Accordingly, the second shared space is a storage space used by the client device. The client device can save the handshake negotiation information jointly negotiated with the server device for resuming the HTTP session in the second shared space during the TLS full handshake process, and retrieve the handshake negotiation information from the second shared space for reuse during the subsequent HTTP session recovery process. The specific form of the second shared space can also include the client device's memory, local disk, or storage cluster, etc.

[0041] Step S102, when the client device and the server device perform a TLS handshake based on the second HTTP protocol, obtain handshake negotiation information from the second shared space, and send a ClientHello message including session multiplexing information to the server device, so that the server device can receive the ClientHello message including session multiplexing information from the client device, and then query the corresponding handshake negotiation information from the first shared space according to the session multiplexing information in the ClientHello message, and complete the TLS handshake with the client device having the same handshake negotiation information according to the queried handshake negotiation information to restore the HTTP session.

[0042] The second HTTP protocol is any HTTP protocol with a different protocol version from the first HTTP protocol. For example, the first HTTP protocol for the TLS full handshake is HTTP3, and the second HTTP protocol can be any HTTP protocol other than HTTP3, such as HTTP2 or HTTP1.

[0043] The session reuse information is determined by the client device based on the handshake negotiation information received during the TLS full handshake, and is used to notify the server device that the handshake negotiation information that has been negotiated and determined before is required for this TLS handshake, and carries specific information for finding the handshake negotiation information. As a result, when the server device receives the ClientHello message that includes the session reuse information, it can determine that this TLS handshake is not a TLS full handshake, and can query the corresponding handshake negotiation information from the first shared space based on the session reuse information in the ClientHello message, and reuse it during this TLS handshake process, without the need to renegotiate and determine a new handshake negotiation information.

[0044] For example, in an actual scenario, the handshake negotiation information may be a negotiated PSK, and the session reuse information may include the specific identifier or storage address of the PSK. When the server device receives a ClientHello message including the session reuse information, it can search for the PSK in the first shared space based on the specific identifier or storage address of the PSK and reuse it during this TLS handshake, thereby reducing the interactive process of negotiating and determining the handshake negotiation information, allowing the HTTP session to be quickly replied, and improving processing efficiency.

[0045] When the solution of the embodiment of the present application is applied to a scenario with a large concurrent HTTPS request processing volume, since the handshake negotiation information that has been negotiated in the previous session can be directly reused, repeated handshake negotiation processes are avoided. Therefore, the processing efficiency of the server-side device can be greatly improved, the processing requirements of a large number of concurrent requests can be met, and the service quality and user experience can be improved.

[0046] Taking TLS 1.3 as an example, the complete TLS handshake process in the embodiment of the present application is described. The specific interaction process between the client device and the server device is as follows: Figure 2 As shown, the following steps are included:

[0047] In step S201, a client device sends a ClientHello message with a keyshare extension field to a server. The keyshare extension field in the ClientHello message lists the cipher suites supported by the client device, including TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256, and other cipher suites.

[0048] In step S202, the server device responds to the ClientHello message with a ServerHello message containing a keyshare extension field. The keyshare extension field in the ServerHello message contains the encryption method that the server device wants to use for key exchange.

[0049] Step S203, the server device sends an Encrypted Extensions message and a Certificate Request message to the client device, which is used to send its server parameters to the client device and request the client device to obtain the client device's certificate. The server parameters may include the server name, version number,

[0051] Supported encryption algorithms, etc.

[0052] In step S204, the server device sends a Certificate message to the client device, sends its own certificate to the client device, and then sends a Certificate Verify message to the client device to prove to the client device that it holds the certificate. Then the server device sends a Finished message to the client device, indicating that the information required for the handshake process has been sent.

[0053] In step S205, the client device will also send a Certificate message and a CertificateVerify message to the server device to send the certificate to the server device and prove that it holds the certificate, and then send a Finished message to the server device. During the processing of the above steps S204 and S205, the server device and the client device exchange identity authentication messages with each other. The server device can generate a PSK based on the key used by the server device and the client device during the verification process as the handshake negotiation information in the embodiment of the present application, and save it in the first shared space.

[0054] In step S206, the server sends a NewSessionTicket message to the client, which includes the PSK. After receiving the NewSessionTicket message, the client can save the PSK in the second shared space for use in the subsequent TLS handshake process.

[0055] In completing Figure 2 After the TLS full handshake process shown, if the application layer protocol between the client device and the server device switches from the original HTTP2 to HTTP3. At this time, if the solution in the embodiment of the present application is not adopted, since the reuse logic of the two versions of the HTTP protocol is independent of each other, the previously negotiated PSK cannot be reused. Instead, authentication messages need to be exchanged between the server device and the client device to generate a new PSK.

[0056] When the solution provided by the embodiment of the present application is used, the subsequent TLS handshake process can be as follows: Figure 3 As shown, after the application layer protocol is switched, the handshake negotiation information previously negotiated can still be shared, thereby realizing the reuse of the handshake negotiation information. The specific interaction process is as follows Figure 3 As shown, the following steps are included:

[0057] In step S301, the client device sends a ClientHello message with a keyshare extension field and session multiplexing information to the server device. The session multiplexing information may be in the form of an extension field, for example, the session multiplexing information may be carried in the ClientHello message as the content of the pre_shared_key extension field.

[0058] In step S302, the server device responds to the ClientHello message using a ServerHello message with a keyshare extension field and a pre_shared_key extension field, agreeing to reuse the PSK determined by the TLS full handshake.

[0059] Step S303: The server device sends an EncryptedExtensions message and a Finished message to the client device.

[0060] In step S304, the client device sends a Finished message to the server device. The server and client devices do not need to exchange authentication messages for verification. Instead, they can query the corresponding PSK from the first shared space based on the session reuse information in the ClientHello message. Based on the queried PSK, the server and client device complete the TLS handshake with the client device that has the same PSK, thereby resuming the HTTP session.

[0061] This sharing method replaces the method of transmitting handshake negotiation information through the protocol's own reuse logic, overcoming the problem that the handshake negotiation information negotiated in the first full handshake cannot be shared due to different reuse logic after the application layer protocol is switched. This allows this solution to achieve fast session recovery when the application layer protocol is switched, avoiding re-performing a full TLS handshake, reducing the handshake negotiation delay by 1 RTT, optimizing the session recovery process, improving the processing efficiency of HTTPS requests, and making access faster.

[0062] In addition, the embodiment of the present application also provides a server device for accelerating HTTP requests, the structure of the server device is as follows: Figure 4 As shown, it includes a full handshake module 410 and a reuse handshake module 420. The full handshake module 410 is used to receive an HTTPS request initiated by a client and perform a TLS full handshake with the client device based on the first HTTP protocol to establish an HTTP session. During the TLS full handshake, the server device and the client device jointly negotiate to determine handshake negotiation information for resuming the HTTP session, save the handshake negotiation information in a first shared space, and send the handshake negotiation information to the client device so that the client device saves the handshake negotiation information in a second shared space. The reuse handshake module 420 is used to receive a ClientHello message including session reuse information from the client device when performing a TLS handshake with the client device based on the second HTTP protocol. The session reuse information is determined by the client device based on the handshake negotiation information received during the TLS full handshake; and based on the session reuse information in the ClientHello message, query the first shared space for the corresponding handshake negotiation information, and complete the TLS handshake with the client device having the same handshake negotiation information based on the query handshake negotiation information to resume the HTTP session.

[0063] The embodiment of the present application also provides a client device for accelerating HTTP requests. The structure of the client device is as follows: Figure 5 As shown, it includes a full handshake module 510 and a reuse handshake module 520. The full handshake module 510 is used to initiate an HTTPS request to a server device and perform a TLS full handshake with the server device based on the first HTTP protocol to establish an HTTP session. During the TLS full handshake, the client device obtains handshake negotiation information for resuming the HTTP session from the server device and stores the handshake negotiation information in a second shared space. The handshake negotiation information is determined by negotiation between the server device and the client device and stored by the server device in the first shared space. The reuse handshake module 520 is used to obtain handshake negotiation information from the second shared space when performing a TLS handshake with the server device based on the second HTTP protocol, and send a ClientHello message including session reuse information to the server device. The session reuse information is determined by the client device based on the handshake negotiation information received during the TLS full handshake, so that the server device queries the first shared space for the corresponding handshake negotiation information based on the session reuse information in the ClientHello message, and completes the TLS handshake with the client device having the same handshake negotiation information based on the queried handshake negotiation information to resume the HTTP session.

[0064] In addition, the present application also provides a computing device, the structure of which is as follows: Figure 6 As shown, it includes a memory 610 for storing computer program instructions and a processor 620 for executing computer program instructions, wherein when the computer program instructions are executed by the processor, the processor is triggered to execute the HTTPS request acceleration method.

[0065] The methods and / or embodiments in the embodiments of the present application can be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for executing the method shown in the flowchart. When the computer program is executed by a processing unit, the above-mentioned functions defined in the method of the present application are performed.

[0066] It should be noted that the computer-readable medium described in this application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the two. Computer-readable media may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or component, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to, an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this application, a computer-readable medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device.

[0067] In the present application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0068] Computer program code for performing the operations of the present application can be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0069] The flow chart or block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the equipment, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code include one or more executable instructions for realizing the logical function of the specification. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a sequence different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented with a dedicated system for hardware that performs the function or operation of the specification, or can be implemented with a combination of dedicated hardware and computer instructions.

[0070] As another aspect, embodiments of the present application further provide a computer-readable medium, which may be included in the device described in the above embodiments, or may exist independently and not incorporated into the device. The computer-readable medium carries one or more computer program instructions, which are executable by a processor to implement the steps of the methods and / or technical solutions of the aforementioned embodiments of the present application.

[0071] In addition, an embodiment of the present application also provides a computer program, which is stored in a computer device, so that the computer device executes the HTTPS request acceleration method.

[0072] It should be noted that the present application can be implemented in a combination of software and / or software and hardware, for example, can be implemented using an application specific integrated circuit (ASIC), a general purpose computer or any other similar hardware device. In certain embodiments, the software program of the present application can be executed by a processor to implement the above steps or functions. Similarly, the software program of the present application (including related data structures) can be stored in a computer-readable recording medium, for example, a RAM memory, a magnetic or optical drive or a floppy disk and similar devices. In addition, some steps or functions of the present application can be implemented using hardware, for example, as a circuit that cooperates with a processor to perform each step or function.

[0073] It is obvious to those skilled in the art that the present application is not limited to the details of the above-mentioned exemplary embodiments, and that the present application can be implemented in other specific forms without departing from the spirit or basic characteristics of the present application. Therefore, from any point of view, the embodiments should be regarded as exemplary and non-restrictive, and the scope of the present application is defined by the appended claims rather than the above description, and it is intended that all changes that fall within the meaning and scope of the equivalent elements of the claims are included in the present application. Any figure mark in the claims should not be regarded as limiting the claims involved. In addition, it is obvious that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices stated in the device claim can also be implemented by one unit or device through software or hardware. Words such as first and second are used to indicate names and do not indicate any particular order.

Claims

1. A method for accelerating HTTPS requests, characterized in that: The method is applied to a server device, comprising: Receive an HTTPS request initiated by a client, and perform a TLS complete handshake with the client device based on a first HTTP protocol to establish an HTTP session. During the TLS complete handshake, the server device and the client device jointly negotiate to determine handshake negotiation information for resuming the HTTP session, save the handshake negotiation information in a first shared space, and send the handshake negotiation information to the client device, so that the client device saves the handshake negotiation information in a second shared space; When performing a TLS handshake with the client device based on the second HTTP protocol, receiving a ClientHello message including session multiplexing information from the client device, where the session multiplexing information is determined by the client device according to the handshake negotiation information received during the TLS full handshake; According to the session reuse information in the ClientHello message, the corresponding handshake negotiation information is queried from the first shared space, and the TLS handshake is completed with the client device having the same handshake negotiation information according to the queried handshake negotiation information to resume the HTTP session.

2. The method according to claim 1, characterized in that The handshake negotiation information includes a session identifier, a session ticket or a pre-shared key.

3. The method according to claim 1, characterized in that The first shared space includes the memory, local disk or storage cluster of the server device, and the second shared space includes the memory, local disk or storage cluster of the client device.

4. A method for accelerating HTTP requests, characterized in that: The method is applied to a client device, comprising: Initiate an HTTPS request to the server device, and perform a TLS complete handshake with the server device based on the first HTTP protocol to establish an HTTP session. During the TLS complete handshake, the client device obtains handshake negotiation information for resuming the HTTP session from the server device, and saves the handshake negotiation information in the second shared space. The handshake negotiation information is determined by the server device and the client device through negotiation, and is saved by the server device in the first shared space. When performing a TLS handshake with the server device based on the second HTTP protocol, handshake negotiation information is obtained from the second shared space, and a ClientHello message including session multiplexing information is sent to the server device, where the session multiplexing information is determined by the client device based on the handshake negotiation information received during the TLS complete handshake, so that the server device queries the corresponding handshake negotiation information from the first shared space based on the session multiplexing information in the ClientHello message, and completes the TLS handshake with the client device having the same handshake negotiation information based on the queried handshake negotiation information, so as to restore the HTTP session.

5. The method according to claim 4, characterized in that The handshake negotiation information includes a session identifier, a session ticket or a pre-shared key.

6. The method according to claim 4, characterized in that The first shared space includes the memory, local disk or storage cluster of the server device, and the second shared space includes the memory, local disk or storage cluster of the client device.

7. A server device for accelerating HTTP requests, characterized in that: The server device comprises: A complete handshake module, configured to receive an HTTPS request initiated by a client, and perform a TLS complete handshake with a client device based on a first HTTP protocol to establish an HTTP session. During the TLS complete handshake, the server device and the client device jointly negotiate to determine handshake negotiation information for resuming the HTTP session, save the handshake negotiation information in a first shared space, and send the handshake negotiation information to the client device, so that the client device saves the handshake negotiation information in a second shared space. A multiplexing handshake module is used to receive a ClientHello message including session multiplexing information from the client device when performing a TLS handshake with the client device based on a second HTTP protocol, wherein the session multiplexing information is determined by the client device according to the handshake negotiation information received during the TLS complete handshake; and according to the session multiplexing information in the ClientHello message, query the corresponding handshake negotiation information from the first shared space, and complete the TLS handshake with the client device having the same handshake negotiation information according to the queried handshake negotiation information to restore the HTTP session.

8. A client device for accelerating HTTP requests, characterized in that: The client device comprises: A complete handshake module, used to initiate an HTTPS request to a server device, and perform a TLS complete handshake with the server device based on a first HTTP protocol to establish an HTTP session. During the TLS complete handshake, the client device obtains handshake negotiation information for resuming the HTTP session from the server device, and saves the handshake negotiation information in a second shared space. The handshake negotiation information is determined by the server device and the client device through negotiation, and is saved by the server device in the first shared space. A multiplexing handshake module is used to obtain handshake negotiation information from the second shared space when performing a TLS handshake with the server device based on a second HTTP protocol, and send a ClientHello message including session multiplexing information to the server device. The session multiplexing information is determined by the client device based on the handshake negotiation information received during the TLS complete handshake, so that the server device queries the corresponding handshake negotiation information from the first shared space based on the session multiplexing information in the ClientHello message, and completes this TLS handshake with the client device having the same handshake negotiation information based on the queried handshake negotiation information to restore the HTTP session.

9. A computing device comprising a memory for storing computer program instructions and a processor for executing the computer program instructions, wherein: When the computer program instructions are executed by the processor, the device is triggered to execute the method according to any one of claims 1 to 6.

10. A computer readable medium having computer program instructions stored thereon, wherein the computer program instructions can be executed by a processor to implement the method according to any one of claims 1 to 6.

Images