CN117579288A - Handshake multiplexing method, device and computer readable medium - Google Patents

Handshake multiplexing method, device and computer readable medium Download PDF

Info

Publication number
CN117579288A
CN117579288A CN202210945473.3A CN202210945473A CN117579288A CN 117579288 A CN117579288 A CN 117579288A CN 202210945473 A CN202210945473 A CN 202210945473A CN 117579288 A CN117579288 A CN 117579288A
Authority
CN
China
Prior art keywords
handshake
information
server
request
multiplexing
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.)
Pending
Application number
CN202210945473.3A
Other languages
Chinese (zh)
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.)
Guizhou Baishancloud Technology Co Ltd
Original Assignee
Guizhou Baishancloud 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 Guizhou Baishancloud Technology Co Ltd filed Critical Guizhou Baishancloud Technology Co Ltd
Priority to CN202210945473.3A priority Critical patent/CN117579288A/en
Publication of CN117579288A publication Critical patent/CN117579288A/en
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)

Abstract

The application provides a handshake multiplexing method, equipment and a computer readable medium, wherein in the scheme, a first service end equipment can return handshake information to a client end equipment in the process of performing TLS handshake, the handshake information comprises digital certificates corresponding to a plurality of reusable domain names, the client end equipment can generate session information about the TLS handshake after the TLS handshake is successful, and the session information is added in a second handshake request sent to a second service end equipment meeting the conditions, so that the second service end equipment can complete the TLS handshake by multiplexing the session information when receiving the second handshake request carrying the session information. Therefore, according to the scheme of the embodiment of the application, by using a set of more efficient handshake multiplexing sharing mechanism, handshake multiplexing can be performed among different domain names, the multiplexing rate of handshake is improved, the buffer quantity of client session information is reduced, and the handshake performance is effectively improved.

Description

Handshake multiplexing method, device and computer readable medium
Technical Field
The present disclosure relates to the field of information technologies, and in particular, to a handshake multiplexing method, apparatus, and computer readable medium.
Background
In order to ensure the safety of internet information interaction, most of traffic currently adopts an HTTPS (Hyper Text Transfer Protocol over Secure Socket Layer, hypertext transfer protocol based on secure socket layer) encryption mode basically, so that the safety of interaction information is ensured. HTTPS is a network protocol capable of encrypted transmission and authentication constructed by TLS (Transport Layer Security, secure transport layer)/SSL (Secure Socket Layer ) protocol based on HTTP (Hyper Text Transfer Protocol ). SSL or TLS handshakes are required before the connection is established.
In order to accelerate the handshake process when performing TLS handshake, a handshake multiplexing manner may be used to replace the complete handshake flow, so as to reduce the time consumption of handshake. However, according to the existing handshake multiplexing mechanism, session (Session) information of TLS handshake is saved at granularity according to domain name, so that handshake between a client device and a server device of different domain names cannot share the same Session information. Therefore, if the client device is expected to realize the multiplexing of the session information with the service devices of different domain names, the client device needs to store the session information of the domain names according to the granularity of the domain names, which results in that the client device needs to use more storage resources to meet the storage requirement of the session information.
Disclosure of Invention
An object of the present application is to provide a handshake multiplexing method, apparatus and computer readable medium, at least to solve the problem that in the existing solution, when implementing TLS handshake multiplexing, more storage resources are required to be used in a client to meet the storage requirement of session information.
To achieve the above object, some embodiments of the present application provide a handshake multiplexing method, which is applied to a client device, the method including:
the client device obtains handshake information returned by first service device, wherein the handshake information is generated by the first service device according to a first handshake request from the client device, and the handshake information contains digital certificates corresponding to a plurality of reusable domain names;
after the TLS handshake is successful, the client device generates session information about the TLS handshake;
and when the client device sends a second handshake request to a second server device corresponding to any reusable domain name, adding the session information into the second handshake request, so that the second server device completes TLS handshake by multiplexing the session information when receiving the second handshake request carrying the session information.
The embodiment of the application also provides a handshake multiplexing method, which is applied to the first server device and comprises the following steps:
the first server side equipment acquires a first handshake request from the client side equipment;
the first service end device completes TLS handshake with the client device according to the first handshake request;
in the process of performing TLS handshake, the first server side equipment generates handshake information of the TLS handshake and returns the handshake information to the client side equipment, wherein the handshake information comprises digital certificates corresponding to a plurality of reusable domain names, so that the client side equipment generates session information after the TLS handshake is successful, and adds the session information in a second handshake request when the second handshake request is sent to a second server side equipment corresponding to any reusable domain name.
The embodiment of the application also provides another handshake multiplexing method, which is applied to the second server-side equipment and comprises the following steps:
the second server equipment acquires a second handshake request from the client equipment, wherein the second handshake request comprises session information, the session information is generated by the client equipment after TLS handshake with the first server equipment is completed, the handshake information is generated by the first server equipment according to the first handshake request from the client equipment, the handshake information comprises digital certificates corresponding to a plurality of reusable domain names, and the second server is any server equipment corresponding to the reusable domain name;
And the second server side equipment completes TLS handshake by multiplexing the session information.
The embodiment of the application also provides a client device for realizing handshake multiplexing, wherein the client device comprises:
the data transmission module is used for acquiring handshake information returned by the first service end equipment, wherein the handshake information is generated by the first service end equipment according to a first handshake request from the client equipment, and the handshake information comprises digital certificates corresponding to a plurality of reusable domain names; and sending a second handshake request to a second server device corresponding to any reusable domain name;
a data processing module, configured to generate session information about a TLS handshake after the TLS handshake is successful; and when a second handshake request is sent to a second server device corresponding to any reusable domain name, adding the session information in the second handshake request, so that the second server device completes TLS handshake by multiplexing the session information when receiving the second handshake request carrying the session information.
The embodiment of the application also provides first service end equipment for realizing handshake multiplexing, wherein the first service end equipment comprises:
The data transmission module is used for acquiring a first handshake request from the client equipment and returning handshake information of the TLS handshake to the client equipment, wherein the handshake information comprises digital certificates corresponding to a plurality of reusable domain names, so that the client equipment generates session information after the TLS handshake is successful, and adds the session information into a second handshake request when the second handshake request is sent to a second service end equipment corresponding to any reusable domain name;
and the data processing module is used for completing TLS handshake with the client device according to the first handshake request, and the first server device generates handshake information of the TLS handshake in the process of carrying out the TLS handshake.
The embodiment of the application also provides a second server device for realizing handshake multiplexing, where the second server device includes:
the data transmission module is used for acquiring a second handshake request from the client device, wherein the second handshake request comprises session information, the session information is generated by the client device after TLS handshake with the first service device is completed, the handshake information is generated by the first service device according to the first handshake request from the client device, the handshake information comprises digital certificates corresponding to a plurality of reusable domain names, and the second server is any service device corresponding to the reusable domain name;
And the data processing module is used for completing TLS handshake by multiplexing the session information.
The embodiment of the application also provides equipment for realizing handshake multiplexing, which comprises a memory for storing computer program instructions and a processor for executing the computer program instructions, wherein the computer program instructions, when executed by the processor, trigger the equipment to execute the handshake multiplexing method.
Furthermore, embodiments of the present application provide a computer readable medium having stored thereon computer program instructions executable by a processor to implement the handshake multiplexing method described.
Compared with the prior art, in the handshake multiplexing scheme provided by the embodiment of the application, after the first service side device obtains the first handshake request from the client side device, the TLS handshake can be completed according to the first handshake request and the client side device, in the process of performing the TLS handshake, the first service side device can generate handshake information of the TLS handshake and return the handshake information to the client side device, the handshake information contains digital certificates corresponding to a plurality of reusable domain names, the client side device can generate session information about the TLS handshake after the TLS handshake is successful, and when the client side device sends a second handshake request to a second service side device corresponding to any reusable domain name, the session information can be added in the second handshake request, so that the second service side device completes the TLS handshake by multiplexing the session information when receiving the second handshake request carrying the session information. Therefore, according to the scheme of the embodiment of the application, by using a set of more efficient handshake multiplexing sharing mechanism, handshake multiplexing can be performed among different domain names, the multiplexing rate of handshake is improved, the buffer quantity of client session information is reduced, and the handshake performance is effectively improved.
Drawings
Fig. 1 is an interaction flow chart of a handshake multiplexing method according to an embodiment of the present application;
fig. 2 is a schematic structural diagram of a client device implementing handshake multiplexing according to an embodiment of the present application;
fig. 3 is a schematic structural diagram of a first service side device for implementing handshake multiplexing according to an embodiment of the present application;
fig. 4 is a schematic structural diagram of a second server device for implementing handshake multiplexing according to an embodiment of the present application;
fig. 5 is a schematic structural diagram of a device for implementing handshake multiplexing according to an embodiment of the present application.
Detailed Description
For the purposes of making the objects, technical solutions and advantages of the embodiments of the present application more clear, the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, are intended to be within the scope of the present application.
In a typical configuration of the present application, the terminals, the devices of the services network each include one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
Computer-readable media include both permanent and non-permanent, removable and non-removable media, and information storage may be implemented by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer 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 Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape storage or other magnetic storage devices, or any other non-transmission medium which can be used to store information that can be accessed by a computing device.
In the method, after a first service side device obtains a first handshake request from a client side device, TLS handshake can be completed with the client side device according to the first handshake request, in the process of performing TLS handshake, the first service side device can generate handshake information of the TLS handshake and return the handshake information to the client side device, the handshake information contains digital certificates corresponding to a plurality of reusable domain names, the client side device can generate session information about the TLS handshake after TLS handshake is successful, and when the client side device sends a second handshake request to a second service side device corresponding to any reusable domain name, the session information can be added in the second handshake request, so that the second service side device completes TLS handshake by multiplexing the session information when receiving the second handshake request carrying the session information. Therefore, according to the scheme of the embodiment of the application, by using a set of more efficient handshake multiplexing sharing mechanism, handshake multiplexing can be performed among different domain names, the multiplexing rate of handshake is improved, the buffer quantity of client session information is reduced, and the handshake performance is effectively improved.
In a practical scenario, the device for executing the method may include a user device, a network device, or a device formed by integrating the user device and the network device through a network, or may be an application program running on the device. The user equipment comprises, but is not limited to, various terminal equipment such as computers, mobile phones, tablet computers and the like. The network device includes, but is not limited to, a network host, a single network server, a server in a plurality of network servers or a server in a distributed cloud network, etc. The distributed Cloud network described herein is made up of a large number of hosts or web servers based on Cloud Computing (Cloud Computing).
It should be noted that the distributed cloud network may be a CDN (Content Delivery Network ), and the CDN network may include a plurality of distributed nodes. In addition to the CDN network, the distributed network may be a server cluster formed by a plurality of servers according to a distributed architecture, where a distributed node is any server in the server cluster. In another example, the distributed cloud network may also be an edge cloud network, and the edge cloud network may construct a cloud computing platform above an edge infrastructure based on the core of the cloud computing technology and the capability of edge computing, so as to form an elastic cloud platform with comprehensive capabilities of computing, networking, storage, security, application, and the like of the edge location. It should be noted that embodiments of the present application are not limited to what a distributed network is in particular, and any network of a distributed architecture of multiple computing devices is suitable for use in the present application.
Fig. 1 shows an interaction flow of a handshake multiplexing method provided in the embodiment of the present application, where handshake multiplexing is implemented by interaction of messages among a first server device 110, a client device 120, and a second server device 130, and a specific interaction process includes:
in step S101, the client device sends a first handshake request to the first server device. The first handshake request is a handshake request sent when a handshake multiplexing mechanism is not used between the client device and the server device, and session information for performing handshake multiplexing is not carried in the handshake request, so that the first server device cannot perform handshake multiplexing based on the first handshake request.
In a practical scenario, when session information that can be used for handshake multiplexing is not available in the client device, the first handshake request is sent to the first server device. For example, when the user uses the client device, if the user needs to operate the client device to access the URL (Uniform Resource Locator ) https:// a.example.com/URL1, the client device initiates an initiation resolution request to the DNS server through the DNS (Domain Name System ) to obtain an IP (Internet Protocol, internet protocol) address corresponding to the URL. If the session information that can be used for handshake multiplexing of the IP address is not cached in the client device at this time, the client device sends a first handshake request to a first service device corresponding to the IP address.
In some embodiments of the present application, in addition to using DNS to resolve the IP address corresponding to the obtained URL, http DNS may also be used to resolve the IP address corresponding to the obtained URL. The HTTP (Hyper Text Transfer Protocol ) is used by the HTTP DNS to initiate a resolution request to the HTTPDNS server, instead of UDP (User Datagram Protocol ) used in the traditional DNS method, so that the Local DNS server of the operator is bypassed, the complexity of the request is simplified, and hijacking and cross-network problems caused by using the Local DNS server of the operator are avoided. Thus, when the client device sends the first handshake request to the first service device, the client device may initiate an http DNS scheduling request to the http DNS server, so that the DNS server returns a response message containing an IP address corresponding to the URL https:// a.sample.com/URL 1, instead of DNS resolution.
In addition, the solution of the embodiment of the present application may also be redirected in combination with 302 when resolving by using DNS or http DNS. Therefore, when the client device initiates a resolution request of the target domain name to the DNS server or the HTTPDNS server in a DNS or HTTPDNS mode, firstly, a URL request of the original domain name can be initiated to the scheduling server, so that the scheduling server can redirect 302 the URL request of the original domain name, and the corresponding target domain name is returned. The URL request of the original domain name refers to a URL that the user wants to access by using the client device, for example, in this embodiment, the URL that the user wants to access is https:// origin. Com/URL1, and the returned target URL is the URL actually accessed after redirection, which may be, for example: https:// a. Example. Com/origin. Com/url1. And after the target domain name corresponding to the target URL is a.example.com and the target domain name returned by the scheduling server is obtained, the client device initiates an analysis request of the target domain name to a DNS server or an http DNS server in a DNS or http DNS manner, so that a corresponding IP address can be obtained, and a first handshake request is initiated to a first service end device corresponding to the IP address.
In step S102, the first server device obtains a first handshake request from the client device.
Step S103, the first service end device completes a complete TLS handshake with the client device according to the first handshake request. Subsequent data may be transferred between the client device and the first server device after the TLS handshake is successful. In the process of performing the TLS handshake, the first server device generates handshake information of the TLS handshake, and returns the handshake information to the client device, so that the client device obtains the handshake information. The handshake information includes at least a digital certificate, where the digital certificate includes a plurality of reusable domain names supported by the digital certificate, for example, in this embodiment, the reusable domain name may be expressed as: * Example, com, wherein the wild card "×" may represent any character, indicating that all of the first two levels of domain names are in the domain of reusable domain names. After receiving the handshake information, the client device can parse the handshake information to obtain the digital certificate from the handshake information, and can learn the multiplexing domain name capable of performing handshake multiplexing through the digital certificate. Thus, when the client device accesses URLs corresponding to the reusable domain names, handshake multiplexing with the second server device can be achieved by using session information about the current TLS handshake.
In step S104, after the TLS handshake is successful, the client device may use session information about the TLS handshake. The session information includes necessary information for handshake multiplexing, and the client device may provide the session information to attempt handshake multiplexing during TLS handshake with the server device.
Step S105, when the client device sends a second handshake request to a second server device corresponding to any reusable domain name, the handshake information is added in the second handshake request.
The second handshake request is a handshake request sent by the client device and the server device when a handshake multiplexing mechanism is used, and the handshake request carries necessary information for performing handshake multiplexing, wherein the necessary information is session information generated by the client device after completing a complete TLS handshake. The second server device is a server device which receives the second handshake request and has the capability of performing handshake multiplexing based on session information in the second handshake request. Thus, the second server device may attempt handshake multiplexing based on the session information in the second handshake request, i.e. complete TLS handshake by multiplexing the session information.
When the client device sends a second handshake request to the second server device, the client device first needs to determine a target IP address corresponding to the second server device. In an actual scenario, the client device may initiate a resolution request of a target domain name to a DNS server or an http DNS server by adopting a DNS or an http DNS manner, and obtain a target IP address corresponding to the target domain name.
Meanwhile, a 302 redirection mode can be combined, namely, the client device initiates a URL request of an original domain name to a dispatching server, so that the dispatching server carries out 302 redirection on the URL request of the original domain name, a corresponding target URL is returned, then the client device obtains the target URL returned by the dispatching server, and a DNS or HTTPDNS mode is adopted to initiate an analysis request of the target domain name corresponding to the target URL to a DNS server or HTTPDNS server.
In an actual scenario, the second server device may be the same device as the first server device, or may be a different device, and when the second server device has the digital certificate carried by the handshake request, the second server device may support handshake multiplexing.
In some embodiments of the present application, when the client device sends a second handshake request to a second server device corresponding to any reusable domain name, the client device may first obtain a corresponding target IP address according to a target domain name, and determine whether the reusable domain name includes the target domain name.
In an actual scenario, after the client device obtains the handshake information, the client device may parse and obtain the digital certificate from the handshake information and cache the digital certificate, and when a handshake request needs to be sent to a server device corresponding to the target domain name, the client device may invoke the cached digital certificate and parse and obtain a plurality of reusable domain names contained in the digital certificate from the cached digital certificate, so as to determine whether the reusable domain name includes the accessed target domain name. Or when the client device acquires the digital certificate, the digital certificate can be further analyzed, and a plurality of reusable domain names in the digital certificate can be acquired and cached. Thus, it is no longer necessary to parse the digital certificate again to obtain the corresponding reusable domain name at each judgment, but the judgment can be directly performed based on the reusable domain name which is cached in advance.
If the cached reusable domain name comprises the target domain name, the client device can try handshake multiplexing, generate a second handshake request added with corresponding session information, and send the second handshake request to a second server device corresponding to the target IP. For example, the URL accessed by the client device at this time is https:// b.example.com/URL2, and the corresponding target domain name is b.example.com, if the name of the multiplex domain cached by the client device is the aforementioned ". Example.com", it is known that the multiplex domain name includes the target domain name. At this time, the client device may generate a second handshake request to which the session information is added, and send the second handshake request to a second server device corresponding to the target IP.
In another case, if the cached reusable domain name does not include the target domain name, it indicates that the target domain name corresponding to the URL accessed this time cannot be handshake multiplexed, and at this time, the client device may send a first access request to the corresponding server device to perform a complete TLS handshake. For example, the URL accessed by the client device at this time is https:// b.example exyz.cn/URL, and the corresponding target domain name is b.example exyz.cn, if the name of the multiplex domain cached by the client device is the aforementioned ". Example.com", it is known that the multiplex domain name does not include the target domain name. At this time, the client device may generate a first handshake request and send the first handshake request to the server device corresponding to the target IP.
In some embodiments of the present application, the handshake information received by the client device may include a multiplexing identifier, which is used to mark the multiplexing sharing function of different domain names, so that the scheme may control the on or off of the multiplexing function through the multiplexing identifier. In an actual scenario, the multiplexing identifier may be a flag bit or extension information carried in the handshake information, and when one handshake information carries the flag bit or extension information, it means that any server having a digital certificate included in the handshake information has a capability of receiving corresponding session information and performing handshake multiplexing. The client device that receives the handshake information containing the flag bit or the extension information can try to handshake multiplexing with any server device with handshake multiplexing capability, even if the domain name of the server device is different from the original server device that returns the handshake information.
For example, if the handshake information includes a multiplexing identifier, it indicates that the client device may add session information to a server device corresponding to a domain name included in the digital certificate when initiating a handshake request, and attempt to complete TLS handshake by multiplexing the session information. On the contrary, when the handshake information does not include the multiplexing identifier, the client device does not add the session information to the server device corresponding to the domain name included in the digital certificate when the handshake request is initiated to the server device even if the session information about the TLS handshake is already cached, so as to attempt to complete the TLS handshake by multiplexing the session information.
Of course, those skilled in the art should also understand that, in other implementation scenarios, the client device and the server device may also agree in advance, and handshake multiplexing sharing is directly performed by default on the reusable domain name included in the digital certificate, without marking by means of carrying a multiplexing identifier.
In step S106, the second server device obtains a second handshake request from the client device. Wherein the second handshake request includes session information.
In step S107, the second server device completes TLS handshake by multiplexing the session information. Because the client device determines based on certain conditions when sending the second handshake request carrying session information, the determining conditions are related to the reusable domain name in the digital certificate received when the TLS handshake was successful before. Therefore, by configuring the information in the digital certificate, the second service end device can be ensured to complete the TLS handshake in a manner of multiplexing session information.
In some embodiments of the present application, the second server device may query, when obtaining the session information, whether the second server device has a corresponding digital certificate, where the digital certificate is the same as a digital certificate provided to the client device by the first server device through handshake information. If the corresponding digital certificate is provided, the second server device can complete TLS handshake by multiplexing the session information. Different from TLS handshake between the client device and the first service device, the TLS handshake between the client device and the second service device adopts a multiplexing mode, and session information generated after complete TLS handshake between the client device and the first service device can be directly used, so that time consumption of the TLS handshake is reduced, data interacted between the client device and the second service device in the handshake process is reduced, and handshake efficiency is improved.
Taking the foregoing scenario as an example, when the client device accesses the URL of https:// b.example.com/URL2, it resolves, through DNS, that its corresponding target IP is IP2, where the IP2 points to the second server device server2. After the client device queries the cached reusable domain name, it finds that the target domain name b.example.com corresponding to the URL is included in the reusable domain name, so that the existing session information can be utilized to generate a second handshake request req2 added with the session information, and the second handshake request req2 is sent to a second server device server2 corresponding to the target IP.
After receiving the second handshake request req2, the second server device server2 may extract the session information carried by the second server device req2, and then complete TLS handshake with the client device by multiplexing the session information, thereby greatly improving handshake efficiency. Meanwhile, because multiplexing of handshake is extended from the same domain name to all the reusable domain names supported in the digital certificate, a mechanism for multiplexing and sharing handshake of different domain names is realized, and the multiplexing rate of handshake is also improved.
The embodiment of the application also provides a client device for realizing handshake multiplexing, and the structure of the client device is shown in fig. 2, and the client device comprises a data transmission module 210 and a data processing module 220. The data transmission module 210 is configured to obtain handshake information returned by a first service side device, where the handshake information is generated by the first service side device according to a first handshake request from the client side device, and the handshake information includes digital certificates corresponding to multiple reusable domain names; and sending a second handshake request to a second server device corresponding to any reusable domain name. The data processing module 220 is configured to generate session information about the TLS handshake after the TLS handshake is successful; and when a second handshake request is sent to a second server device corresponding to any reusable domain name, adding the session information in the second handshake request, so that the second server device completes TLS handshake by multiplexing the session information when receiving the second handshake request carrying the session information.
In addition, the embodiment of the application further provides a first service side device for implementing handshake multiplexing, where the structure of the first service side device is shown in fig. 3 and includes a data transmission module 310 and a data processing module 320. The data transmission module 310 is configured to obtain a first handshake request from a client device, and return handshake information of the TLS handshake to the client device, where the handshake information includes digital certificates corresponding to a plurality of reusable domain names, so that the client device generates session information after TLS handshake is successful, and when sending a second handshake request to a second server device corresponding to any reusable domain name, adds the session information to the second handshake request. The data processing module 320 is configured to complete TLS handshake with the client device according to the first handshake request, and in a process of performing TLS handshake, the first server device generates handshake information of the TLS handshake.
The embodiment of the application also provides a second server device for implementing handshake multiplexing, where the structure of the second server device is shown in fig. 4 and includes a data transmission module 410 and a data processing module 420. The data transmission module 410 is configured to obtain a second handshake request from a client device, where the second handshake request includes session information, the session information is generated by the client device after TLS handshake with a first service device is completed, the handshake information is generated by the first service device according to the first handshake request from the client device, the handshake information includes digital certificates corresponding to a plurality of reusable domain names, and the second server is a service device corresponding to any reusable domain name. The data processing module 420 is configured to complete TLS handshake by multiplexing the session information.
In addition, the embodiment of the application further provides a device for implementing handshake multiplexing, where the structure of the device is shown in fig. 5, and the device includes a memory 510 for storing computer readable instructions and a processor 520 for executing the computer readable instructions, where the computer readable instructions, when executed by the processor, trigger the processor to execute the handshake multiplexing method.
The methods and/or embodiments of the present application may be implemented as a computer software program. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flowcharts. The above-described functions defined in the method of the present application are performed when the computer program is executed by a processing unit.
It should be noted that, the computer readable medium described in the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, 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 disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
In the present application, however, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations of the present application may be written in one or more programming languages, including an object oriented programming language such as Java, smalltalk, C ++ and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).
The flowchart or block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of devices, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
As another aspect, the present application also provides a computer-readable medium, which may be contained in the apparatus described in the above embodiments; or may be present alone without being fitted into the device. The computer readable medium carries one or more computer readable instructions executable by a processor to implement the steps of the methods and/or techniques of the various embodiments of the present application described above.
In addition, the embodiment of the application also provides a computer program which is stored in the computer equipment, so that the computer equipment executes the method for executing the control code.
It should be noted that the present application may be implemented in software and/or a combination of software and hardware, for example, using Application Specific Integrated Circuits (ASIC), a general purpose computer or any other similar hardware device. In some embodiments, the software programs of the present application may be executed by a processor to implement the above steps or functions. Likewise, the software programs of the present application (including associated data structures) may be stored on a computer readable recording medium, such as RAM memory, magnetic or optical drive or diskette and the like. In addition, some steps or functions of the present application may be implemented in hardware, for example, as circuitry that cooperates with the processor to perform various steps or functions.
It will be evident to those skilled in the art that the present application is not limited to the details of the foregoing illustrative embodiments, and that the present application may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive, the scope of the application being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. Any reference sign in a claim should not be construed as limiting the claim concerned. Furthermore, it is evident that the word "comprising" does not exclude other elements or steps, and that the singular does not exclude a plurality. A plurality of units or means recited in the apparatus claims can also be implemented by means of one unit or means in software or hardware. The terms first, second, etc. are used to denote a name, but not any particular order.

Claims (14)

1. A handshake multiplexing method, the method being applied to a client device, the method comprising:
the client device obtains handshake information returned by first service device, wherein the handshake information is generated by the first service device according to a first handshake request from the client device, and the handshake information contains digital certificates corresponding to a plurality of reusable domain names;
after the TLS handshake is successful, the client device generates session information about the TLS handshake;
and when the client device sends a second handshake request to a second server device corresponding to any reusable domain name, adding the session information into the second handshake request, so that the second server device completes TLS handshake by multiplexing the session information when receiving the second handshake request carrying the session information.
2. The method according to claim 1, wherein the handshake information includes a multiplexing identifier;
when the client device sends a second handshake request to a second server device corresponding to any reusable domain name, adding the session information in the second handshake request, including:
If the client device obtains the multiplexing identifier in the handshake information when analyzing the handshake information, when sending a second handshake request to a second server device corresponding to any multiplexing domain name, adding the session information in the second handshake request.
3. The method according to claim 1, wherein the client device, when sending a second handshake request to a second server device corresponding to any one of the reusable domain names, adds the handshake information to the second handshake request, including:
the client device obtains a corresponding target IP address according to a target domain name and judges whether the reusable domain name comprises the target domain name or not;
and if the reusable domain name comprises the target domain name, generating a second handshake request added with the handshake information, and sending the second handshake information to second server equipment corresponding to the target IP.
4. A method according to claim 3, wherein the client device obtains the corresponding target IP address according to the target domain name, comprising:
and the client equipment initiates a resolution request of a target domain name to a DNS server or an HTTPDNS server in a DNS or HTTPDNS mode, and acquires a target IP address corresponding to the target domain name.
5. The method according to claim 4, wherein the client device initiates the resolution request of the target domain name to the DNS server or the http DNS server by means of DNS or http DNS, including:
the client device initiates a URL request of an original domain name to a scheduling server, so that the scheduling server redirects 302 the URL request of the original domain name and returns a corresponding target URL;
and the client equipment acquires the target URL returned by the scheduling server and initiates a resolution request of a target domain name corresponding to the target URL to a DNS server or an HTTPDNS server in a DNS or HTTPDNS mode.
6. A handshake multiplexing method, the method being applied to a first service-side device, the method comprising:
the first server side equipment acquires a first handshake request from the client side equipment;
the first service end device completes TLS handshake with the client device according to the first handshake request;
in the process of performing TLS handshake, the first server side equipment generates handshake information of the TLS handshake and returns the handshake information to the client side equipment, wherein the handshake information comprises digital certificates corresponding to a plurality of reusable domain names, so that the client side equipment generates session information after the TLS handshake is successful, and adds the session information in a second handshake request when the second handshake request is sent to a second server side equipment corresponding to any reusable domain name.
7. The method according to claim 6, wherein the handshake information includes a multiplexing identifier, where the multiplexing identifier is used to trigger the client device to add the session information in a second handshake request when sending the second handshake request to a second server device corresponding to any reusable domain name.
8. A handshake multiplexing method, the method being applied to a second server device, the method comprising:
the second server equipment acquires a second handshake request from the client equipment, wherein the second handshake request comprises session information, the session information is generated by the client equipment after TLS handshake with the first server equipment is completed, the handshake information is generated by the first server equipment according to the first handshake request from the client equipment, the handshake information comprises digital certificates corresponding to a plurality of reusable domain names, and the second server is any server equipment corresponding to the reusable domain name;
and the second server side equipment completes TLS handshake by multiplexing the session information.
9. The method of claim 8, wherein the second server device completes TLS handshake by multiplexing the handshake information, comprising:
When the second server side equipment obtains the session information, inquiring whether the second server side equipment has a corresponding digital certificate or not;
and if the corresponding digital certificate exists, the second server side equipment completes TLS handshake by multiplexing the handshake information.
10. A client device implementing handshake multiplexing, the client device comprising:
the data transmission module is used for acquiring handshake information returned by the first service end equipment, wherein the handshake information is generated by the first service end equipment according to a first handshake request from the client equipment, and the handshake information comprises digital certificates corresponding to a plurality of reusable domain names; and sending a second handshake request to a second server device corresponding to any reusable domain name;
a data processing module, configured to generate session information about a TLS handshake after the TLS handshake is successful; and when a second handshake request is sent to a second server device corresponding to any reusable domain name, adding the session information in the second handshake request, so that the second server device completes TLS handshake by multiplexing the session information when receiving the second handshake request carrying the session information.
11. A first service-side device for implementing handshake multiplexing, wherein the first service-side device includes:
the data transmission module is used for acquiring a first handshake request from the client equipment and returning handshake information of the TLS handshake to the client equipment, wherein the handshake information comprises digital certificates corresponding to a plurality of reusable domain names, so that the client equipment generates session information after the TLS handshake is successful, and adds the session information into a second handshake request when the second handshake request is sent to a second service end equipment corresponding to any reusable domain name;
and the data processing module is used for completing TLS handshake with the client device according to the first handshake request, and the first server device generates handshake information of the TLS handshake in the process of carrying out the TLS handshake.
12. A second server device for implementing handshake multiplexing, wherein the second server device includes:
the data transmission module is used for acquiring a second handshake request from the client device, wherein the second handshake request comprises session information, the session information is generated by the client device after TLS handshake with the first service device is completed, the handshake information is generated by the first service device according to the first handshake request from the client device, the handshake information comprises digital certificates corresponding to a plurality of reusable domain names, and the second server is any service device corresponding to the reusable domain name;
And the data processing module is used for completing TLS handshake by multiplexing the session information.
13. An apparatus implementing handshake multiplexing, the apparatus comprising a memory for storing computer program instructions and a processor for executing the computer program instructions, wherein the computer program instructions, when executed by the processor, trigger the apparatus to perform the method of any of claims 1 to 9.
14. A computer readable medium having stored thereon computer program instructions executable by a processor to implement the method of any of claims 1 to 9.
CN202210945473.3A 2022-08-08 2022-08-08 Handshake multiplexing method, device and computer readable medium Pending CN117579288A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210945473.3A CN117579288A (en) 2022-08-08 2022-08-08 Handshake multiplexing method, device and computer readable medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210945473.3A CN117579288A (en) 2022-08-08 2022-08-08 Handshake multiplexing method, device and computer readable medium

Publications (1)

Publication Number Publication Date
CN117579288A true CN117579288A (en) 2024-02-20

Family

ID=89885004

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210945473.3A Pending CN117579288A (en) 2022-08-08 2022-08-08 Handshake multiplexing method, device and computer readable medium

Country Status (1)

Country Link
CN (1) CN117579288A (en)

Similar Documents

Publication Publication Date Title
TWI657682B (en) Method and system for realizing precise dispatch request on content distribution network (CDN)
JP5765836B2 (en) Identity provider discovery service using publish-subscribe model
US9871850B1 (en) Enhanced browsing using CDN routing capabilities
US8832271B2 (en) Identity provider instance discovery
US8423650B2 (en) Transferring session data between network applications
EP2381647A1 (en) Session migration over content-centric networks
US9712523B2 (en) Secure transfer of web application client persistent state information into a new domain
CN108418847B (en) Network traffic caching system, method and device
TW201545520A (en) Method and system for acquiring web pages
WO2023103318A1 (en) Media streaming method and system
WO2024021405A1 (en) Data transmission system and method
CN113315706A (en) Private cloud flow control method, device and system
CN110958279B (en) Data processing method and device
US10044788B2 (en) Native client multimedia redirection
US10764402B2 (en) Leveraging time-windows generated by web browser pre-connections
CN116800765A (en) P2P point-to-point data throttling acceleration implementation method, device and storage medium
CN116684703A (en) Streaming media data transmission method and related equipment based on proximity service communication protocol
CN116566945A (en) Access method and device for decentralised application, electronic equipment and storage medium
CN117579288A (en) Handshake multiplexing method, device and computer readable medium
US8615548B1 (en) System and method for deferred data downloading
US20130024543A1 (en) Methods for generating multiple responses to a single request message and devices thereof
US20170142199A1 (en) Decentralized Discovery Across Different Networks
CN110555180A (en) Web page object request method and HTTPS request response method
JP6054799B2 (en) Web content distribution device
CN118018612A (en) Scheduling method, scheduling device, and computer-readable medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination