CN113179323B

CN113179323B - HTTPS request processing method, device and system for load balancing equipment

Info

Publication number: CN113179323B
Application number: CN202110471768.7A
Authority: CN
Inventors: 李亮
Original assignee: Hangzhou DPTech Technologies Co Ltd
Current assignee: Hangzhou DPTech Technologies Co Ltd
Priority date: 2021-04-29
Filing date: 2021-04-29
Publication date: 2023-07-04
Anticipated expiration: 2041-04-29
Also published as: CN113179323A

Abstract

The disclosure relates to an HTTPS request processing method, device and system for load balancing equipment. The method comprises the following steps: acquiring an HTTPS request from a client based on an HTTPS connection; determining a target server from the server cluster based on a scheduling algorithm; establishing an HTTP connection with the target server; attaching the client's certificate to the HTTPS request; the HTTPs request is forwarded to the target server for processing based on an HTTP connection. The HTTPS request processing method, the HTTPS request processing device, the HTTPS request processing system, the HTTPS request processing electronic equipment and the HTTPS request processing computer readable medium can reduce the pressure of the server, and meanwhile, the server can provide personalized services for the client according to the acquired certificate information.

Description

HTTPS request processing method, device and system for load balancing equipment

Technical Field

The present disclosure relates to the field of computer information processing, and in particular, to a method, an apparatus, a system, an electronic device, and a computer readable medium for HTTPS request processing.

Background

With the continuous improvement of network security, more and more websites start to provide services based on HTTPS, and in particular, the finance industry basically uses HTTPS technology, in order to provide stable network services, load balancing products are generally used, and unified network services are provided to the outside through a load balancer. When a 7-layer server load device adopting an OSI model provides a network service, since communication is performed based on an HTTPS protocol, an encryption and decryption process is involved, and this process needs to occupy a large amount of server resources. In the prior art, HTTPS communication is usually adopted between a client and load balancing equipment, and common HTTP communication is adopted between the load balancing equipment and a real server, so that the pressure of the server can be greatly reduced,

however, in some environments where network security requirements are high, as in the financial industry described above, HTTPS mutual authentication is required to ensure data security. In the HTTPS bidirectional authentication method, a server needs to verify a certificate of a client, and provides targeted and personalized services for different clients based on the certificate. In this mode, if the existing load balancing device communication framework is followed: the load balancing device and the client adopt HTTPS communication, and the load balancing device and the server still use HTTP communication, so that the server cannot know the certificate information used by the client and cannot provide personalized service.

Accordingly, there is a need for a new HTTPS request processing method, apparatus, system, electronic device, and computer readable medium.

The above information disclosed in the background section is only for enhancement of understanding of the background of the disclosure and therefore it may include information that does not form the prior art that is already known to a person of ordinary skill in the art.

Disclosure of Invention

In view of this, the disclosure provides a HTTPS request processing method, apparatus, system, electronic device, and computer readable medium, which can reduce the pressure of a server, and at the same time, the server can provide personalized services for a client according to acquired certificate information.

Other features and advantages of the present disclosure will be apparent from the following detailed description, or may be learned in part by the practice of the disclosure.

According to an aspect of the disclosure, an HTTPS request processing method is provided, which may be used for a load balancing device, the method including: acquiring an HTTPS request from a client based on an HTTPS connection; determining a target server from the server cluster based on a scheduling algorithm; establishing an HTTP connection with the target server; attaching the client's certificate to the HTTPS request; the HTTPs request is forwarded to the target server for processing based on an HTTP connection.

In an exemplary embodiment of the present disclosure, before obtaining the HTTPS request from the client based on the HTTPS connection, further includes: acquiring an HTTPS connection request from a client; acquiring a certificate of the client based on the HTTPS connection request; verifying whether the client is valid based on the certificate; and when the client is valid, recording the certificate and establishing HTTPS connection with the client.

In an exemplary embodiment of the present disclosure, further comprising: enabling a client authentication function in the load balancing device; the pass-through client certificate functionality is enabled in the load balancing device.

In an exemplary embodiment of the present disclosure, further comprising: and generating a preset condom interface layer strategy based on the attribute information of the hypertext transfer protocol.

In one exemplary embodiment of the present disclosure, appending the client's certificate to the HTTPS request includes: comparing the attribute of the HTTPS request with the preset condom interface layer strategy; and when the preset condom interface layer strategy is met, the certificate is encrypted and then is added to the HTTPS request.

In an exemplary embodiment of the present disclosure, encrypting the certificate and appending the certificate to the HTTPS request includes: the certificate is encrypted based on a base64 mode and then is added to the HTTPS request.

According to an aspect of the disclosure, there is provided an HTTPS request processing method, which may be used for servers in a server cluster, the method including: receiving an HTTPS request from a load balancing device; decrypting the HTTPS request to obtain a certificate; and processing the HTTPS request based on the certificate.

In one exemplary embodiment of the present disclosure, processing the HTTPS request based on the certificate includes: determining a processing mode based on the certificate; and processing the HTTPS request according to the processing mode.

According to an aspect of the disclosure, an HTTPS request processing apparatus is provided, the apparatus being usable for a load balancing device, the apparatus comprising: the request module is used for acquiring an HTTPS request from a client based on an HTTPS connection; the scheduling module is used for determining a target server from the server cluster based on a scheduling algorithm; the connection module is used for establishing HTTP connection with the target server; an attaching module, configured to attach the certificate of the client to the HTTPS request; and the forwarding module is used for forwarding the HTTPS request to the target server for processing based on HTTP connection.

According to an aspect of the disclosure, an HTTPS request processing apparatus is provided, the apparatus being usable for servers in a server cluster, the apparatus comprising: the receiving module is used for receiving an HTTPS request from the load balancing equipment; the decryption module is used for decrypting the HTTPS request to obtain a certificate; and the processing module is used for processing the HTTPS request based on the certificate.

According to an aspect of the present disclosure, there is provided an HTTPS request processing system, including: the load balancing device is used for acquiring an HTTPS request from the client based on the HTTPS connection; determining a target server from the server cluster based on a scheduling algorithm; establishing an HTTP connection with the target server; attaching the client's certificate to the HTTPS request; forwarding the HTTPs request to the target server for processing based on an HTTP connection; a server cluster receives an HTTPS request from load balancing equipment; decrypting the HTTPS request to obtain a certificate; and processing the HTTPS request based on the certificate.

According to an aspect of the present disclosure, there is provided an electronic device including: one or more processors; a storage means for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors are caused to implement the methods as described above.

According to an aspect of the present disclosure, a computer-readable medium is presented, on which a computer program is stored, which program, when being executed by a processor, implements a method as described above.

According to the HTTPS request processing method, the HTTPS request processing device, the HTTPS request processing system, the electronic equipment and the computer readable medium, an HTTPS request from a client is acquired based on HTTPS connection; determining a target server from the server cluster based on a scheduling algorithm; establishing an HTTP connection with the target server; attaching the client's certificate to the HTTPS request; and forwarding the HTTPS request to the target server based on HTTP connection for processing, so that the server can provide personalized service for the client according to the acquired certificate information while reducing the pressure of the server.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The above and other objects, features and advantages of the present disclosure will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings. The drawings described below are merely examples of the present disclosure and other drawings may be obtained from these drawings without inventive effort for a person of ordinary skill in the art.

FIG. 1 is a schematic diagram of an HTTPS request processing system, according to an example embodiment.

FIG. 2 is a flowchart illustrating a method of HTTPS request processing, according to an example embodiment.

FIG. 3 is a flowchart illustrating a method of HTTPS request processing, according to another exemplary embodiment.

FIG. 4 is a flowchart illustrating a method of HTTPS request processing, according to another exemplary embodiment.

FIG. 5 is a block diagram illustrating an HTTPS request processing apparatus according to an example embodiment.

Fig. 6 is a block diagram illustrating an HTTPS request processing apparatus according to another exemplary embodiment.

Fig. 7 is a block diagram of an electronic device, according to an example embodiment.

Fig. 8 is a block diagram of a computer-readable medium shown according to an example embodiment.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. However, the exemplary embodiments can be embodied in many forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the example embodiments to those skilled in the art. The same reference numerals in the drawings denote the same or similar parts, and thus a repetitive description thereof will be omitted.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the disclosure. One skilled in the relevant art will recognize, however, that the disclosed aspects may be practiced without one or more of the specific details, or with other methods, components, devices, steps, etc. In other instances, well-known methods, devices, systems, implementations, or operations have not been shown or described in detail to avoid obscuring aspects of the disclosure.

The block diagrams depicted in the figures are merely functional entities and do not necessarily correspond to physically separate entities. That is, the functional entities may be implemented in software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices.

The flow diagrams depicted in the figures are exemplary only, and do not necessarily include all of the elements and operations/steps, nor must they be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the order of actual execution may be changed according to actual situations.

It will be understood that, although the terms first, second, third, etc. may be used herein to describe various components, these components should not be limited by these terms. These terms are used to distinguish one element from another element. Accordingly, a first component discussed below could be termed a second component without departing from the teachings of the concepts of the present disclosure. As used herein, the term "and/or" includes any one of the associated listed items and all combinations of one or more.

Those skilled in the art will appreciate that the drawings are schematic representations of example embodiments and that the modules or flows in the drawings are not necessarily required to practice the present disclosure, and therefore, should not be taken to limit the scope of the present disclosure.

The technical abbreviations to which the present disclosure relates are explained as follows:

load balancing: the load balancing is to form a server set by a plurality of servers, each server can independently provide the same service, external requests are distributed to one of the server sets through a certain load algorithm, the server provides services for the request equipment, and the service with high reliability and high stability can be provided for the outside through balancing the load, and meanwhile, the pressure of a single server is relieved.

Real service group-a server cluster composed of a plurality of devices, wherein a plurality of servers are centralized to provide the same service, each server can provide the same service.

Virtual address: the load balancing device provides an IP address to the outside, which does not have a fixed server and does not correspond to a certain server that exists in reality.

SSL Security Socket Layer condom interface layer, a safety data transmission standard used on Internet. It uses encryption technology to transmit data over the internet, ensuring that the data is not eavesdropped and modified.

HTTPS: hyper Text Transfer Protocol over SecureSocket Layer is an HTTP channel with security as a target, and ensures the security of the transmission process by transmission encryption and identity authentication on the basis of HTTP. HTTPS adds the SSL layer on an HTTP basis, with the security basis of HTTPS being SSL.

Because the HTTPS connection server needs SSL encryption and decryption, in the prior art, the client and the load balancing device are connected by adopting an HTTPS protocol, and the server directly acquires SSL certificate information through the HTTPS protocol, so that the burden of the server is increased. The present disclosure provides an HTTPS request processing method, when HTTPS bidirectional authentication is adopted, a load balancing device may transparently transmit a client certificate to a server, and HTTPS connection is also established without the load balancing device and the server, and only relevant certificate information needs to be inserted into an HTTP header, so that the server can obtain the certificate information used by a current client in a convenient manner. The following is a detailed description with the aid of specific examples.

FIG. 1 is a system block diagram of a method, apparatus, system, electronic device, and computer readable medium for HTTPS request processing, according to an example embodiment.

As shown in fig. 1, the system architecture 10 may include a server cluster, which may include: the

servers

101, 102, 103, the system architecture 10 may further include: a network 104 and a load balancing device 105, a client 106. The network 104 is the medium used to provide communication links between the

servers

101, 102, 103 and the load balancing device 105, and between the load balancing device 105 and the clients 106. The network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.

A user may use a client 106 to interact with the

servers

101, 102, 103 via the network 104, the load balancing device 105, to receive or send messages, etc. The client 106 may have installed thereon various communication client applications such as shopping class applications, web browser applications, search class applications, instant messaging tools, mailbox clients, social platform software, and the like.

The client 106 may be a variety of electronic devices having a display screen and supporting web browsing, including but not limited to smartphones, tablets, laptop and desktop computers, and the like.

The load balancing device 105 may be a device that provides load balancing services, and the load balancing device 105 may provide support for websites browsed by users using clients 106. The load balancing device 105 may obtain the HTTPS requests from the clients 106, and the load balancing device 105 may determine a target server (

server

101 or 102 or 103) from the server cluster and forward the HTTPS requests to the target server.

The load balancing device 105 may obtain an HTTPS request from a client, for example, based on an HTTPS connection; the load balancing device 105 may determine a target server from the server cluster, e.g., based on a scheduling algorithm; the load balancing device 105 may, for example, establish an HTTP connection with the target server; the load balancing device 105 may, for example, append the client's credentials in the HTTPS request; the load balancing device 105 may forward the HTTPs request to the target server for processing, for example, based on an HTTP connection.

The

servers

101, 102, 103 may provide request handling services, and the

servers

101, 102, 103 may provide request handling services that may support websites browsed by users using clients 106. The

servers

101, 102, 103 may analyze and process the received data such as the product information query request, and feed back the processing result to the terminal device.

The server 101 (or 102 or 103) may, for example, receive HTTPS requests from the load balancing device; the server 101 may, for example, decrypt the HTTPS request to obtain a certificate; the server 101 may process the HTTPS request, for example, based on the certificate.

It should be noted that, the HTTPS request processing method provided by the embodiment of the present disclosure may be executed by the load balancing device 105 and the

servers

101, 102, 103, and accordingly, the HTTPS request processing apparatus may be disposed in the load balancing device 105 and the

servers

101, 102, 103.

FIG. 2 is a flowchart illustrating a method of HTTPS request processing, according to an example embodiment. The HTTPS request processing method 20 may be used for a load balancing device, and includes at least steps S202 to S210.

As shown in fig. 2, in S202, an HTTPS request from a client is acquired based on an HTTPS connection. After the load balancing device and the client establish a connection based on the HTTPS protocol, an HTTPS request from the client may be received. After the connection is established, after the load balancing device receives the first HTTP request sent by the client, the load balancing device selects a certain server according to a scheduling algorithm and establishes the connection by adopting the HTTP protocol.

Wherein before the HTTPS connection is used for acquiring the HTTPS request from the client, the method further comprises: acquiring an HTTPS connection request from a client; acquiring a certificate of the client based on the HTTPS connection request; verifying whether the client is valid based on the certificate; and when the client is valid, recording the certificate and establishing HTTPS connection with the client.

In S204, a target server is determined from the server cluster based on the scheduling algorithm. In embodiments of the present disclosure, the load balancing device may provide a wide variety of scheduling methods, which may include Round Robin (Round Robin), weighted Round Robin (Weighted Round Robin), least Connection (Least Connection), least Connection slow start time (Least Connection Slow Start Time), weighted Least Connection (Weighted Least Connection), proxy-based adaptive load balancing (Agent Based Adaptive Balancing), fixed weights (Fixed weights), weighted responses (Weighted Response), source IP Hash (Source IP Hash), and so on.

In S206, an HTTP connection is established with the target server. The load balancing device may establish an HTTP connection with the target server, the HTTP communicating data based on the TCP/IP communication protocol. The HTTP protocol works on a client-server architecture. The browser serves as an HTTP client and sends all requests to an HTTP server, namely a WEB server, through a URL.

In S208, the certificate of the client is appended to the HTTPS request.

In one embodiment, further comprising: enabling a client authentication function in the load balancing device; client authentication (Client Authentication, CA) is an authentication mechanism based on the user's client host IP address that allows a system administrator to customize access rights for authorized users having a particular IP address. The CA is associated with an IP address and does not directly limit the protocol of access. The server and client do not need to add or modify any software. The system administrator may decide on the authorization for each user, the server resources that are allowed to access, the application, the access time, the number of sessions allowed to be established, etc. In the application, by starting the client authentication function, the client can be set to send a certificate option, and a corresponding trusted issuer is selected for judging whether the client SSL certificate is trusted or not in a subsequent process.

In one embodiment, further comprising: and generating a preset condom interface layer strategy based on the attribute information of the hypertext transfer protocol. The condom interface layer policy may specify which conditions the HTTP protocol may conform to for transmission. Wherein appending the client's certificate to the HTTPS request includes: comparing the attribute of the HTTPS request with the preset condom interface layer strategy; and when the preset condom interface layer strategy is met, the certificate is encrypted and then is added to the HTTPS request. More specifically, the certificate may be encrypted based on the base64 manner and then appended to the HTTPS request.

After the client initiates the virtual service access request, the load balancing device plays a role of a server at the moment, after the client verifies the certificate of the server, the client can send the certificate of the client used by the client because the client is started to send the certificate option, and the load balancing device can verify whether the client is a valid user or not, and can establish connection and record certificate information if the client passes the verification.

In S210, the HTTPs request is forwarded to the target server for processing based on the HTTP connection.

In one embodiment, further comprising: the pass-through client certificate functionality is enabled in the load balancing device. The pass-through client certificate function can be enabled in the load balancing device, the HTTP header name of the inserted certificate is configured, the inserted client function can select to match attributes in some HTTP requests, such as Host, cookie, url and the like, SSL certificate information can be passed through only when the attributes are met, otherwise, SSL certificate information cannot be passed through, and if relevant matched attributes are not configured, the SSL certificate information is unconditionally passed through.

According to the HTTPS request processing method, an HTTPS request from a client is acquired based on HTTPS connection; determining a target server from the server cluster based on a scheduling algorithm; establishing an HTTP connection with the target server; attaching the client's certificate to the HTTPS request; and forwarding the HTTPS request to the target server based on HTTP connection for processing, so that the server can provide personalized service for the client according to the acquired certificate information while reducing the pressure of the server.

It should be clearly understood that this disclosure describes how to make and use particular examples, but the principles of this disclosure are not limited to any details of these examples. Rather, these principles can be applied to many other embodiments based on the teachings of the present disclosure.

FIG. 3 is a flowchart illustrating a method of HTTPS request processing, according to another exemplary embodiment. The HTTPS request processing method 30 may be used for servers in a server cluster, and includes at least steps S302 to S306.

As shown in fig. 3, in S302, an HTTPS request is received from a load balancing device. After one of the servers in the server cluster and the load balancing device establish an HTTP connection, an HTTPS request from the client is received.

In S304, the HTTPS request is decrypted to obtain a certificate. Decryption may be performed based on Base64, which is one of the most common encoding schemes used to transmit 8Bit bytecodes on a network, base64 being a method of representing binary data based on 64 printable characters. See RFC 2045-RFC 2049, supra, detailed specifications for MIME. Base64 encoding is a binary to character process that can be used to convey longer identification information in an HTTP environment. The Base64 code is unreadable and needs to be decoded before reading. An improved Base64 encoding of URL may be employed, which is filled with '=' numbers at the end and changes "+" and "/" in standard Base64 to "-" and "_" respectively, thus eliminating the need for conversion during URL encoding and decoding and database storage, avoiding the increase in encoded information length during this process, and unifying the formats of object identifiers at databases, forms, etc.

In S306, the HTTPS request is processed based on the certificate. A processing means may be determined, for example, based on the certificate; and processing the HTTPS request according to the processing mode. The certificate information used by the current client can be known through base64 decryption, and different services can be provided by the certificate information.

FIG. 4 is a flowchart illustrating a method of HTTPS request processing, according to another exemplary embodiment. The flow 40 shown in fig. 4 is a detailed description of the processing of the HTTPS request processing system.

As shown in fig. 4, in S401, the load balancing device makes an initial setting, and may enable a client authentication function in the load balancing device, for example; the pass-through client certificate functionality may also be enabled, for example, in a load balancing device, and a preset condom interface layer policy may also be generated, for example, based on attribute information of the hypertext transfer protocol.

In S402, the client requests and load balancing device to establish an HTTPS connection.

In S403, the load balancing device acquires a client certificate and performs verification.

In S404, after the verification passes, an HTTPS connection is established.

In S405, an HTTPS request is sent based on the HTTPS connection client.

In S406, a target server is determined and an HTTP connection is established with the target server.

In S407, the certificate of the client is appended to the HTTPS request.

In S408, the HTTPs request is forwarded to the target server based on the HTTP connection.

In S409, the HTTPS request is decrypted to obtain a certificate and processed.

The method comprises the steps that connection is established between a client and load balancing equipment based on an HTTPS protocol, connection is established between the load balancing equipment and a server based on an HTTP protocol, the load balancing equipment records SSL certificate information used by the client, when an HTTP request initiated by the client arrives at the load balancing equipment, the load balancing equipment firstly inserts the certificate information used by the client into the HTTP request sent by the client, and then the information is forwarded to the server.

After the load balancing device and the server are connected, the HTTP request of the client is forwarded, the function of inserting the client certificate is judged to be started when the HTTP request is forwarded, if the function of inserting the certificate is started, whether the attribute in the HTTP request initiated by the client is consistent with the value of the attribute in the configured HTTP request is judged, if the attribute is consistent with the value of the attribute in the HTTP request, SSL certificate information (including but not limited to a certificate issuer, a certificate user and the like) used by the client is added in the HTTP request after being encrypted by a base64, and after the server receives the certificate information, the server can know the certificate information used by the current client through decryption of the base64 and can provide different services by the certificate information.

The HTTPS request processing system disclosed by the invention can be used for load balancing equipment with bidirectional HTTPS authentication enabled, and has the following advantages:

1. and HTTP protocol is adopted between the load balancing equipment and the server, so that the pressure of the server is relieved.

2. The server may obtain credential information used by the client.

Those skilled in the art will appreciate that all or part of the steps implementing the above described embodiments are implemented as a computer program executed by a CPU. The above-described functions defined by the above-described methods provided by the present disclosure are performed when the computer program is executed by a CPU. The program may be stored in a computer readable storage medium, which may be a read-only memory, a magnetic disk or an optical disk, etc.

Furthermore, it should be noted that the above-described figures are merely illustrative of the processes involved in the method according to the exemplary embodiments of the present disclosure, and are not intended to be limiting. It will be readily appreciated that the processes shown in the above figures do not indicate or limit the temporal order of these processes. In addition, it is also readily understood that these processes may be performed synchronously or asynchronously, for example, among a plurality of modules.

The following are device embodiments of the present disclosure that may be used to perform method embodiments of the present disclosure. For details not disclosed in the embodiments of the apparatus of the present disclosure, please refer to the embodiments of the method of the present disclosure.

FIG. 5 is a block diagram illustrating an HTTPS request processing apparatus according to an example embodiment. As shown in fig. 5, the HTTPS request processing apparatus 50 may be used for a load balancing device, including: a request module 502, a dispatch module 504, a connection module 506, an append module 508, and a forward module 510.

The request module 502 is configured to obtain an HTTPS request from a client based on an HTTPS connection;

the scheduling module 504 is configured to determine a target server from the server cluster based on a scheduling algorithm;

the connection module 506 is configured to establish an HTTP connection with the target server;

an append module 508 is configured to append the certificate of the client to the HTTPS request; the add-in module 508 is further configured to compare the attribute of the HTTPS request with the preset condom interface layer policy; and when the preset condom interface layer strategy is met, the certificate is encrypted and then is added to the HTTPS request. More specifically, the certificate may be encrypted based on the base64 manner and then appended to the HTTPS request.

The forwarding module 510 is configured to forward the HTTPs request to the target server for processing based on an HTTP connection.

Fig. 6 is a block diagram illustrating an HTTPS request processing apparatus according to another exemplary embodiment. As shown in fig. 6, the HTTPS request processing apparatus 60 may be used for servers in a server cluster, including: a receiving module 602, a decrypting module 604, and a processing module 606.

The receiving module 602 is configured to receive an HTTPS request from a load balancing device;

the decryption module 604 is configured to decrypt the HTTPS request to obtain a certificate;

the processing module 606 is configured to process the HTTPS request based on the certificate. The processing module 606 is further configured to determine a processing manner based on the certificate; processing the HTTPS request according to the processing mode

According to the HTTPS request processing device, an HTTPS request from a client is acquired based on HTTPS connection; determining a target server from the server cluster based on a scheduling algorithm; establishing an HTTP connection with the target server; attaching the client's certificate to the HTTPS request; and forwarding the HTTPS request to the target server based on HTTP connection for processing, so that the server can provide personalized service for the client according to the acquired certificate information while reducing the pressure of the server.

An electronic device 700 according to such an embodiment of the present disclosure is described below with reference to fig. 7. The electronic device 700 shown in fig. 7 is merely an example and should not be construed to limit the functionality and scope of use of embodiments of the present disclosure in any way.

As shown in fig. 7, the electronic device 700 is embodied in the form of a general purpose computing device. Components of electronic device 700 may include, but are not limited to: at least one processing unit 710, at least one memory unit 720, a bus 730 connecting the different system components (including the memory unit 720 and the processing unit 710), a display unit 740, and the like.

Wherein the storage unit stores program code that is executable by the processing unit 710 such that the processing unit 710 performs steps described in the present specification according to various exemplary embodiments of the present disclosure. For example, the processing unit 710 may perform the steps as shown in fig. 2, 3, and 4.

The memory unit 720 may include readable media in the form of volatile memory units, such as Random Access Memory (RAM) 7201 and/or cache memory 7202, and may further include Read Only Memory (ROM) 7203.

The storage unit 720 may also include a program/utility 7204 having a set (at least one) of program modules 7205, such program modules 7205 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of which may include an implementation of a network environment.

Bus 730 may be a bus representing one or more of several types of bus structures including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

The electronic device 700 may also communicate with one or more external devices 700' (e.g., keyboard, pointing device, bluetooth device, etc.), devices that enable a user to interact with the electronic device 700, and/or any devices (e.g., routers, modems, etc.) with which the electronic device 700 can communicate with one or more other computing devices. Such communication may occur through an input/output (I/O) interface 750. Also, electronic device 700 may communicate with one or more networks such as a Local Area Network (LAN), a Wide Area Network (WAN) and/or a public network, such as the Internet, through network adapter 760. Network adapter 760 may communicate with other modules of electronic device 700 via bus 730. It should be appreciated that although not shown, other hardware and/or software modules may be used in connection with electronic device 700, including, but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, data backup storage systems, and the like.

From the above description of embodiments, those skilled in the art will readily appreciate that the example embodiments described herein may be implemented in software, or may be implemented in software in combination with the necessary hardware. Thus, as shown in fig. 8, the technical solution according to the embodiments of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (may be a CD-ROM, a U-disk, a mobile hard disk, etc.) or on a network, and includes several instructions to cause a computing device (may be a personal computer, a server, or a network device, etc.) to perform the above-described method according to the embodiments of the present disclosure.

The software product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but is 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 (a non-exhaustive list) of the readable storage medium would include the following: an electrical connection having one or more wires, a portable disk, a hard disk, random Access Memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

The computer readable storage medium may include a data signal propagated in baseband or as part of a carrier wave, with 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 readable storage medium may also be any readable medium 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 readable storage medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Program code for carrying out operations of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C++ or the like 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 computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device, partly on a remote computing device, or entirely on the remote computing device or server. In the case of remote computing devices, the remote computing device may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computing device (e.g., connected via the Internet using an Internet service provider).

The computer-readable medium carries one or more programs, which when executed by one of the devices, cause the computer-readable medium to perform the functions of: acquiring an HTTPS request from a client based on an HTTPS connection; determining a target server from the server cluster based on a scheduling algorithm; establishing an HTTP connection with the target server; attaching the client's certificate to the HTTPS request; the HTTPs request is forwarded to the target server for processing based on an HTTP connection. The computer readable medium can also realize the following functions: receiving an HTTPS request from a load balancing device; decrypting the HTTPS request to obtain a certificate; and processing the HTTPS request based on the certificate.

Those skilled in the art will appreciate that the modules may be distributed throughout several devices as described in the embodiments, and that corresponding variations may be implemented in one or more devices that are unique to the embodiments. The modules of the above embodiments may be combined into one module, or may be further split into a plurality of sub-modules.

From the above description of embodiments, those skilled in the art will readily appreciate that the example embodiments described herein may be implemented in software, or in combination with the necessary hardware. Thus, the technical solutions according to the embodiments of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (may be a CD-ROM, a U-disk, a mobile hard disk, etc.) or on a network, and include several instructions to cause a computing device (may be a personal computer, a server, a mobile terminal, or a network device, etc.) to perform the method according to the embodiments of the present disclosure.

Exemplary embodiments of the present disclosure are specifically illustrated and described above. It is to be understood that this disclosure is not limited to the particular arrangements, instrumentalities and methods of implementation described herein; on the contrary, the disclosure is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

1. An HTTPS request processing method for a load balancing device, comprising:

acquiring an HTTPS request from a client based on an HTTPS connection;

generating a preset condom interface layer strategy based on attribute information of a hypertext transfer protocol;

determining a target server from the server cluster based on a scheduling algorithm;

establishing an HTTP connection with the target server;

comparing the attribute of the HTTPS request with the preset condom interface layer strategy, and encrypting the certificate of the client based on a base64 mode and then adding the encrypted certificate into the HTTPS request when the attribute of the HTTPS request accords with the preset condom interface layer strategy;

the HTTPs request is forwarded to the target server for processing based on an HTTP connection.

2. The method of claim 1, further comprising, prior to obtaining the HTTPS request from the client based on the HTTPS connection:

acquiring an HTTPS connection request from a client;

acquiring a certificate of the client based on the HTTPS connection request;

verifying whether the client is valid based on the certificate;

and when the client is valid, recording the certificate and establishing HTTPS connection with the client.

3. The method as recited in claim 1, further comprising:

enabling a client authentication function in the load balancing device;

the pass-through client certificate functionality is enabled in the load balancing device.

4. An HTTPS request processing apparatus for a load balancing device, comprising:

the receiving module receives an HTTPS request from a client;

a decryption module for decrypting the HTTPS request to obtain a certificate;

and the additional module is used for comparing the attribute of the HTTPS request with a preset condom interface layer strategy generated based on attribute information of a hypertext transfer protocol, and encrypting the certificate of the client based on a base64 mode and then adding the encrypted certificate to the HTTPS request when the attribute of the HTTPS request accords with the preset condom interface layer strategy.

5. An HTTPS request processing apparatus for a load balancing device, comprising:

the request module is used for acquiring an HTTPS request from a client based on an HTTPS connection;

the scheduling module is used for generating a preset condom interface layer strategy based on attribute information of the hypertext transfer protocol and determining a target server from the server cluster based on a scheduling algorithm;

the connection module is used for establishing HTTP connection with the target server;

the adding module is used for comparing the attribute of the HTTPS request with the preset condom interface layer strategy, and adding the encrypted certificate of the client into the HTTPS request based on a base64 mode when the attribute of the HTTPS request accords with the preset condom interface layer strategy;

and the forwarding module is used for forwarding the HTTPS request to the target server for processing based on HTTP connection.

6. An HTTPS request processing apparatus for a load balancing device, comprising:

the receiving module is used for receiving an HTTPS request from a client, comparing the attribute of the HTTPS request with a preset condom interface layer strategy generated based on attribute information of a hypertext transfer protocol by load balancing equipment, and encrypting a certificate of the client by the load balancing equipment based on a base64 mode when the preset condom interface layer strategy is met, and adding the certificate to the HTTPS request;

the decryption module is used for decrypting the HTTPS request to obtain a certificate;

and the processing module is used for processing the HTTPS request based on the certificate.

7. An HTTPS request processing system for a load balancing device, comprising:

the load balancing device is used for acquiring an HTTPS request from the client based on the HTTPS connection; generating a preset condom interface layer strategy based on attribute information of a hypertext transfer protocol; determining a target server from the server cluster based on a scheduling algorithm; establishing an HTTP connection with the target server; comparing the attribute of the HTTPS request with the preset condom interface layer strategy, and encrypting the certificate of the client based on a base64 mode and then adding the encrypted certificate into the HTTPS request when the attribute of the HTTPS request accords with the preset condom interface layer strategy; forwarding the HTTPs request to the target server for processing based on an HTTP connection;

a server cluster receives an HTTPS request from load balancing equipment; decrypting the HTTPS request to obtain a certificate; and processing the HTTPS request based on the certificate.