Full Station HTTPS

1.HTTPS Foundation

HTTPS (Secure hypertext Transfer Protocol) Secure Hypertext Transfer Protocol It is a secure communication channel that is based on HTTP development and is used to exchange information between client computers and servers. It uses Secure Sockets Layer (SSL) for information exchange, which is simply a secure version of HTTP and an HTTP protocol that uses TLS/SSL encryption.

The HTTP protocol transmits the information in clear text, there is the risk of information eavesdropping, information tampering and information hijacking, and the protocol Tls/ssl has the functions of authentication, information encryption and integrality checking, which can avoid such problems.

TLS/SSL Full Name Secure Transport Layer Protocol Transport layer Security, which is a secure protocol between TCP and HTTP, does not affect the original TCP protocol and HTTP protocol, so using HTTPS basically does not require too many HTTP pages The transformation.

2.tls/ssl principle

The main functions of the HTTPS protocol are basically dependent on the TLS/SSL protocol, this section analyzes the implementation principle of the security protocol. The function implementation of TLS/SSL mainly relies on three kinds of basic algorithms: hash function hash, symmetric encryption and asymmetric encryption, which realizes identity authentication and key negotiation using asymmetric encryption, the symmetric encryption algorithm uses negotiated key to encrypt data, and verifies the integrality of information based on hash function.

Hash function hash, common with MD5, SHA1, SHA256, the function of the function is one-way irreversible, the input is very sensitive, the output length is fixed, any modification to the data will change the result of the hash function, to prevent information tampering and verify the integrity of the data; symmetric encryption, common AES-CBC, DES, 3DES, AES-GCM, and so on, the same key can be used for information encryption and decryption, master the key to obtain information, to prevent information eavesdropping, communication mode is 1 to 1, asymmetric encryption, that is, the common RSA algorithm, including ECC, DH and other algorithms, algorithm features are, Key in pairs appear, commonly called public key (public) and private key (confidential), public key encryption information can only be the private key to untie, private key encryption information can only be solved by public key. Therefore, the different clients mastering the public key can not decrypt information with each other, only with the private key to the server to encrypt communication, the server can achieve 1-to-many communication, the client can also be used to verify the identity of the server to master the private key.

In the information transmission process, the hash function cannot implement the information tamper-proof, because the clear text transmits, the intermediary can revise the information after the information summary, therefore needs to transmit the information as well as the information digest to encrypt; The advantage of symmetric encryption is that the information is transmitted 1 to 1, and the same password needs to be shared. The security of the password is the basis of guaranteeing information security, the server and N client communication, need to maintain n password record, and lack the mechanism to change the password; Asymmetric encryption is characterized by 1-to-many information transmission, the server only need to maintain a private key to be able to communicate with multiple clients encrypted However, the information sent by the server can be decrypted by all the clients, and the algorithm is computationally complex and the encryption is slow.

Combined with the characteristics of three kinds of algorithms, the basic way of TLS is that the client uses asymmetric encryption to communicate with the server, realizes authentication and negotiates the key used by symmetric encryption, and then encrypts the information and information digest using the negotiation key, and the symmetric key is different between different nodes. This ensures that the information can only be obtained by the communication Parties.

3.PKI System
3.1 The hidden danger of RSA authentication

Authentication and key negotiation are the basic functions of TLS, and the prerequisite is that the legitimate server is in possession of the corresponding private key. However, the RSA algorithm can not ensure the legitimacy of the server identity, because the public key does not contain information about the server, there is a security risk: Client C and server S for communication, intermediate node M intercept the communication between the two; node M computes a pair of public key pub_m and private key pri_m; When C asks for a public key, M sends its public key pub_m to C; C using the public key pub_m encrypted data can be decrypted by M, because M master the corresponding private key pri_m, and C cannot judge the identity of the server according to the public key information, thus establishing a "trusted" encrypted connection between C and M; The intermediate node m and the server s between the establishment of a legitimate connection, so that the communication between C and S is fully M master, M can be information interception, tampering and other operations. In addition, the server can also deny their own information, do not recognize the relevant information is issued by themselves. Therefore, there are at least two types of problems under this scheme: Man-in-the-middle attack and information repudiation.

3.2 Authentication-ca and certificates

The key to resolving the above authentication problem is to ensure that the public key path obtained is legal and capable of validating the identity of the server, which requires the introduction of an authoritative third-party agency CA. The CA is responsible for verifying the information of the owner of the public key and issuing the certificate of authentication, as well as providing the user with a certificate verification service, the PKI system.

The basic principle is that the CA is responsible for auditing the information, then "signing" the key information with the private key, exposing the corresponding public key, and the client can use the public key to verify the signature. CAS can also revoke certificates that have already been issued, including two types of CRL files and OCSP in the basic way. The specific process for CA use is as follows:

A. The service party S submits the public key, organizes the information, the personal information (domain name) and so on to the third party agency CA information and requests the authentication; b.ca to verify the authenticity of the information provided by the applicant, such as the existence of the Organization, the legality of the enterprise, the ownership of the domain name, etc. if the information is approved, CA The applicant will be issued a certification document-certificate. The certificate contains the following information: The applicant's public key, the applicant's organization information and personal information, the issuing agency CA information, the effective time, the certificate serial number and other information of the clear text, including a signature; the Signature generation algorithm: First, the summary of the information that is exposed to the plaintext is computed using the hash function, and then, using the CA The private key to the information digest is encrypted, ciphertext is signed; d. When client C makes a request to server S, s returns the certificate file; e. Client C reads the relevant plaintext information from the certificate, computes the information digest using the same hash function, and then decrypts the signature data with the public key of the corresponding CA, and compares the information summary of the certificate. , if it is consistent, it can confirm the legality of the certificate, that is, the public key is valid; F. The client then verifies the information about the domain name, valid time, etc. of the certificate; G. The client will have the certificate information (including the public key) built into the trusted CA, and if the CA is not trusted, the certificate will be found to be

Note the points in this process: A. The application certificate does not require a private key to ensure that the private key is always available to the server; B. The legitimacy of the certificate still relies on the asymmetric encryption algorithm, the certificate mainly increases the server information and signature; c. The certificate for the built-in CA is called the root certificate, the issuer and the consumer are the same Own signature, that is, self-signed certificate; d. Certificate = Public key + requester and issuer information + signature;

3.3 Certificate Chain

such as CA root certificate and server certificate in the middle of adding a certificate authority, that is, intermediate certificate, the certificate generation and validation principle is unchanged, just add a layer of verification, as long as the last can be trusted by any CA root certificate authentication can be legitimate. A. The issuer of the server certificate Server.pem is the intermediary Certificate Authority inter,inter The certificate INTER.PEM verifies the valid certificate that the SERVER.PEM does for itself; B. Intermediate Certificate Inter.pem issuing CA is Root,root Verify the legitimate certificate issued by INTER.PEM for yourself according to the certificate Root.pem. C. The client built-in trust CA's ROOT.PEM certificate, so the server certificate Server.pem is trusted.

The server certificate, the intermediate certificate and the root certificate are combined together into a valid certificate chain, and the verification of the certificate chain is the process of the bottom-up trust passing. The advantages of secondary certificate structure: A. Reduce the management of root certificate structure, can be more efficient audit and issuance of certificates; b. The root certificate is generally built into the client, the private key is normally stored offline, and once the private key is compromised, the revocation process is very difficult and cannot be remedied in time; C. The private key of the intermediate certificate structure is compromised, it can be quickly revoked online, and a new certificate is issued again for the user; d. The certificate chain level four generally does not significantly affect the performance of HTTPS.

The certificate chain has the following characteristics: A. There may be multiple legitimate certificate chains for the same server certificate. Because certificate generation and validation is based on public and private key pairs, if different intermediate certificates are generated with the same public and private key, the issuing authority is a legitimate CA for the issuer, but differs from the issuing authority of the intermediate certificate; b. The hierarchy of different certificate chains may not be the same, possibly two-, three-, or four-level certificate chains. The issuing authority for intermediate certificates may be the root certificate authority or another intermediate certificate authority, so the certificate chain hierarchy is not necessarily the same.

3.4 Certificate Revocation

CA institutions can issue certificates, and there are mechanisms to announce that previously issued certificates are invalid. The certificate consumer is illegal, the CA needs to discard the certificate, or the private key is lost, and the user requests that the certificate be invalid. There are two main types of mechanisms: CRLs and OCSP.

(a) CRL Certificate revocation list, certificate revocation lists, a separate file. The file contains the certificate serial number (unique) and the revocation date that the CA has revoked, and the file contains the effective date and notifies the next time the file is updated, which, of course, must contain the signature of the CA private key to verify the file's legitimacy. The certificate typically contains a URL address CRL distribution point, which notifies the consumer where to download the corresponding CRL to verify that it is revoked. The advantage of this revocation method is that it does not need to be updated frequently, but the certificate cannot be revoked in a timely manner because the CRL update time is typically several days, which may have caused a significant loss.

(b) OCSP online Certificate status Protocol, certificate status on-line query protocol, how a real-time query certificate is revoked. The requestor sends the certificate's information and requests the query, and the server returns to either a normal, revoked, or unknown state. The certificate also typically contains a URL address for OCSP, which requires good performance from the query server. Some CAs or most self-signed CAs (root certificates) do not provide CRLs or OCSP addresses, which can be a cumbersome task for revoking certificates.

4.tls/ssl Handshake Process

4.1 Handshake and key negotiation process

Client Authentication server based on RSA handshake and key exchange The handshake process is detailed in the example.

1.client_helloThe client initiates the request, transmits the request information in clear text, contains the version information, the Cipher Suite candidate list, the compression algorithm candidate list, the random number, the extension field and other information, related information as follows: The highest TSL protocol version supported, from low to high SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2, the current basic no longer uses a version less than TLSV1, the client-supported cryptographic Suite cipher Suites list, each cipher suite corresponding to the previous TLS principle of four features of the combination: Authentication algorithm Au (authentication), key exchange algorithm Keyexchange (key Negotiation), symmetric encryption algorithm ENC (information encryption) and Information digest Mac (integrity check); Supported compression algorithm compression methods list for subsequent information compression transmission, random number random_c for subsequent key generation, extended field extensions, support protocol and algorithm parameters and other ancillary information, common SNI Belongs to the extended field, and the field is later discussed separately.

2.server_hello+server_certificate+sever_hello_done(a) Server_hello, the server returns the negotiated information results, including the option to use the version of the protocol, the selected cryptographic Suite cipher suite, the selected compression algorithm compression method, the random number random_s, etc. Where the random number is used for subsequent key negotiation; (b) Server_certificates, the server-side configuration of the corresponding certificate chain for authentication and key exchange, (c) Server_hello_done, notify the client Server_hello the end of the message sent;

3. Certificate VerificationThe client verifies the legality of the certificate, if the validation through the subsequent communication, otherwise according to the error conditions to make the prompt and operation, the legitimacy verification includes the following: The credibility of the certificate chain trusted certificate path, as described earlier, the certificate is revoked revocation, There are two types of offline CRLs and online OCSP, different client behavior will be different; validity expiry date, whether the certificate is in a valid time range, domain name, verify that the certificate domain name matches the current access domain name, matching rules follow-up analysis;

4.client_key_exchange+change_cipher_spec+encrypted_handshake_message(a) Client_key_exchange, after the legitimacy verification is passed, the client calculates a random digital pre-master, encrypts it with the public key of the certificate, and sends it to the server; (b) The client has obtained all the information needed to compute the negotiation key: two plaintext random numbers Random_c and random_s with their own calculation of the resulting pre-master, calculated to obtain a negotiated key; Enc_key=fuc (Random_c, random_s, Pre-master) (C) Change_cipher_spec, the client notifies the server that subsequent communication uses the negotiated communication key and encryption algorithm to encrypt the communication; (d) Encrypted_handshake_message, combining the hash value of all previous communication parameters with other related information to generate a piece of data, using the negotiation key session secret and algorithm encryption, and then sent to the server for data and handshake verification;

5.change_cipher_spec+encrypted_handshake_message(a) The server decrypts the encrypted pre-master data with the private key, and calculates the negotiated key based on the two plaintext random numbers random_c and random_s previously exchanged: Enc_key=fuc (Random_c, random_s, pre-master); (b) Computes the hash value of all previously received information, then decrypts the Encrypted_handshake_message sent by the client, verifies the data and key correctness, and (c) Change_cipher_spec, after the authentication is passed, the server also sends Change_cipher_spec to inform the client that subsequent communications are encrypted with the negotiated key and algorithm, (d) Encrypted_handshake_message, the server also generates a piece of data in conjunction with all current communication parameter information and uses the negotiation key Session secret and algorithms are encrypted and sent to the client;

6. End of handshakeThe client calculates the hash value of all received information, and uses the negotiated key to decrypt the Encrypted_handshake_message, verifies the data and keys sent by the server, and verifies that the handshake is completed by the verification.

7. Encrypted communicationBegins encrypting communication with the algorithm using the negotiation key. Note: (a) The server can also request authentication client, namely two-way authentication, can send client_certificate_request information in procedure 2, the client sends Client_certificate and Certificate_ in procedure 4 first Verify_message information, certificate authentication method is basically the same, Certificate_verify_message is using the client's private key encryption of a section based on the negotiated communication information to obtain data, the server can use the corresponding public key decryption and verification; (b) Depending on the key exchange algorithm used, such as ECC, the negotiation details are slightly different and generally similar; (c) Sever key exchange's role is that when the server certificate does not carry enough information, it is sent to the client to calculate pre-master, such as the D-based H of the certificate, the public key is not included in the certificate, it needs to be sent separately; (d) Change cipher spec can actually be used to notify the peer revision of the currently used encrypted communication mode, not currently in-depth analysis; (e) ALTER message Used to indicate the state change or error message during handshake or communication, general alarm information trigger condition is connection close, receive illegal information, information decryption failure, user cancel operation, etc., after receiving the alarm message, communication will be disconnected or the receiver decides whether to disconnect.

4.2 Session Cache Handshake Process

In order to speed up the handshake, reduce the performance and resource consumption of the Protocol (specifically analyzed in the following article), the TLS protocol has two types of session caching mechanisms: The session ID sessions are logged to the conversation log session ticket. Session ID by the server-side support, the standard fields in the protocol, so basic all servers are supported, server-side save session ID and negotiated communication information, Nginx 1 m memory can save about 4,000 session ID machine-related information, occupy more server resources; Session ticket requires both server and client support, belongs to an extension field, supporting a range of about 60% (no reliable statistics and sources), the negotiated communication information is encrypted and sent to the client to save, the key only the server knows, the server resource is very small.

In contrast, the main point is to save the negotiation information in different ways, similar to the session and cookie in HTTP. In the case of both, the (Nginx implementation) takes precedence over the use of session_ticket. The handshake process is as follows:

Note: Although the handshake process has 1.5 back and forth, the first application data sent by the client to the server does not need to wait for the information returned by the server, so the handshake delay is 1*rtt.

1. Session ID(a) If a connection has been established between the client and the server, the server returns the session ID after the handshake succeeds and saves the corresponding communication parameters in the server; (b) If the client needs to establish a connection with the server again, the session ID in Client_hello (c) The server retrieves the cached records based on the session ID received, and if the arrival cache is not expired, follow the normal handshake process; (d) if the corresponding cache record is retrieved, return the Change_cipher_spec and Encrypted_handshake_message information, two information function similar, encrypted_handshake_message is to the current communication parameters and Master_secret hash value; (f) If the client is able to verify data encrypted through the server, the client also sends Change_cipher_spec and encrypted_handshake_message information, and (g) The server verifies that the data is passed, and the handshake is established successfully to begin normal encrypted data communication.

2. Session Log Ticket(a) If a connection has been established between the client and the server, the server carries the encrypted Session_ticket information in the New_session_ticket data, the client saves it, and (b) if the client needs to establish a connection with the server again, the Client_ The extended field in Hello Session_ticket carries the encrypted information to the server, and (c) the server decrypts the Sesssion_ticket data, and if it fails to decrypt it, it follows the normal handshake process; (d) returns if decryption succeeds Change_ Cipher_spec and Encrypted_handshake_message information, two information functions similar to the session ID; (f) If the client is able to verify data encrypted through the server, the client also sends the CHANGE_CIPHER_ Spec and encrypted_handshake_message information; (g) When the server verifies that the data is passed, the handshake is successful and the normal encrypted data communication begins.

4.3 Rebuilding the connection

Rebuilding the connection renegotiation the TLS connection that is being used, the new authentication and key negotiation process, characterized by the ability to re-authenticate, update the key or algorithm without disconnecting the current data transfer, so that both server-side storage and cached information can be maintained. Both the client and the server are able to initiate the process of rebuilding the connection, which is currently not supported by Windows & XP and SSL 2.0. 1. Server Rebuild ConnectionServer-side rebuild connections typically occurs when a client accesses a protected data. The basic process is as follows: (a) A valid TLS connection is established and communicated between the client and server, (b) The client accesses the protected information, and (c) the server side returns hello_request information; (d) The client sends Client_hello information after receiving hello_request information and begins to reestablish the connection.

2. Client Rebuild ConnectionThe client rebuilds the connection generally in order to update the communication key. (a) A valid TLS connection is established and communicated between the client and the server, and (b) the client needs to update the key, proactively issue Client_hello information, and (c) the server side cannot immediately identify the non-application data after receiving the Client_hello information, so it is submitted to the next processing , the message is returned to inform the request to reestablish the connection, and (d) the server does not immediately stop sending data to the client until the connection is determined, possibly at the same time or with the cached data to be sent to the client, but the client no longer sends any information to the server; (e) The server identifies the rebuild connection request , send Server_hello information to the client, (f) The client is also unable to immediately determine the information non-application data, also submitted to the next processing, after processing will return to notify the information to require rebuilding the connection, (g) The client and the server to start a new process of rebuilding the connection.

4.4 Key Calculation

The previous section mentions the two random numbers transmitted in plaintext Random_c and random_s and the pre-master exchanged between the server and the client via encryption, and three parameters as the basis of the key negotiation. This section discusses the basic computational procedures for key negotiation and the use of keys during communication.

1. Calculate KeyInvolving the parameters random client and random server, Pre-master, master secret, key material, compute keys, both the server and the client have these basic information, the interchange method is described in the previous section, the calculation process is as follows: (A The client uses cryptographic algorithms such as RSA or Diffie-hellman to generate Pre-master, and (b) pre-master with random client and randomly server two randomized numbers through pseudorandomfunct Ion (PRF) calculates Master secret; (c) Master secret combined with the random client and randomly server two stochastic numbers to get the Key material by iterative computation;

Here are some important records that can solve some of the love in-depth research friends of the doubts, copy of the material, share to everyone: (a) Premaster secret the first two bytes is the version number of TLS, which is a more important version number to check the handshake data, because the Client Hello Phase, the client sends a list of cryptographic suites and the version number of the currently supported SSL/TLS to the server, and is transmitted in clear text, and if the handshake packet is cracked, the attacker is likely to string the packet, select a less secure cryptographic suite and version to the server, to crack the data. Therefore, the server needs to decrypt the ciphertext in the Premaster version number with the previous Client Hello phase of the version number, if the version number is lower, then the string changed, immediately stop sending any message. (copy) (b) A random number is required for both the client and the server, so that the generated key will not be the same every time. Because the certificate is static in the SSL protocol, it is necessary to introduce a stochastic factor to guarantee the randomness of the negotiated key.

For RSA key exchange algorithm, the Pre-master-key itself is a random number, plus the random in the Hello message, three random numbers through a key exporter to finally export a symmetric key. The presence of the pre master is that the SSL protocol does not trust each host to produce a completely random random number, and if the random number is not random, then the pre-master secret is likely to be guessed, then only the pre-master secret as the key is inappropriate, so you must introduce New random factors, then the client and server plus pre-master secret three random number generated by the key is not easy to guess, a pseudo-random may not be random, but three pseudo-random is very close to random, each increase of one degree of freedom, the randomness is not one of the increase.

2. Key UsageKey after 12 rounds of iterative calculation will get to 12 hash values, grouped into 6 elements, the list is as follows: (a) Mac key, encryption key and IV are a set of cryptographic elements, which are used by both the client and the server, but both are acquired by both sides, and (b) the client uses The client group element encrypts the data, the server decrypts with the client element, the server uses the server element encryption, the client decrypts with the server element, and (c) the two-way communication uses different keys in different directions, and the cracked communication needs to be cracked at least two times; (d) Encrypti The on key is used for symmetric encryption data, (e) IV is used as an initialization vector for many cryptographic algorithms, the symmetric encryption algorithm can be studied, and (f) Mac key is used for data integrity checking;

4.4 Data Encryption Communication process

(a) Partitioning the application layer data into a suitable block; (b) To prevent replay attacks by numbering the Shard data, (c) compressing the data using the negotiated compression algorithm, (d) calculating the MAC value and compressing the data to compose the transmitted data, and (e) encrypting the data using the client encryption key and sending it to server servers; (f) Serve R after receiving data, use client encrytion key to decrypt, verify data, extract data, reassemble. Note: The calculation of Mac values includes two hash values: Client Mac key and hash (number, package type, length, compressed data).

4.5 Packet Capture Analysis

About the grab bag no longer detailed analysis, according to the previous analysis, the basic situation can be matched, according to the usual positioning problem of the process, the individual to make some points that need attention: 1. Packet HTTP communication, can clearly see the communication of the head and the plaintext of the message, but HTTPS is encrypted communication, can not see the HTTP protocol related header and data of the plaintext information, 2. Packet capture HTTPS communication consists of three processes: TCP establishes a connection, TLS handshake, TLS encrypted communication, mainly analyzes the handshake establishment and status of HTTPS communication and other information. 3.client_hello is able to know the highest protocol version number supported by the client based on version information, and if it is a low-version protocol such as SSL 3.0 or TLS 1.0, it is very important to note that some handshake failures may occur due to low version; Serv in the extension field The Er_name field determines whether SNI is supported, is supported, is not supported, is useful for locating handshake failures or certificate return errors, session ID is a standard protocol section, if no connection is established, the corresponding value is NULL, and NOT NULL indicates that the corresponding connection was established and cached; Session Ticke T is the Extension Protocol section, there is the field Description protocol support Sesssion ticket, otherwise unsupported, exists and the value is NULL, indicating that the connection was not established and cached before, exists and the value is not empty, indicating that there is a cache connection. 4.server_hello according to the TLS version field can be inferred that the server supports the highest version of the protocol, different versions may cause handshake failure, based on the Cipher_suite information to determine the priority of the server-supported encryption protocol; 5.ceritficate The server configures and returns the certificate chain, judging by the certificate information and comparing to the server profile, to determine whether the request is consistent with expectations, and if not, whether the default certificate is returned. 6.alert Alarm Information alert indicates that the cause of the connection failure is the type of alarm, which is important for locating the problem.

5.HTTPS performance and optimization

5.1 HTTPS Performance loss= The preceding article discusses the principle and advantages of HTTPS: Authentication, information encryption and integrity checking, and no modifications to the TCP and HTTP protocols. But by adding new protocols to achieve more secure communications, there is a cost, and the performance loss of the HTTPS protocol is mainly reflected in the following: 1. Increase delayAnalysis of the previous handshake process, a full handshake requires at least two sides in turn two communication, at least increase the delay 2 RTT, which uses session caching to reuse connections, with a delay of at least 1rtt*. 2. Consume more CPU resourcesIn addition to data transmission, HTTPS communication mainly includes symmetric plus decryption, asymmetric plus decryption (the server mainly uses private key to decrypt data); TS8 single core CPU: Symmetric encryption algorithm aes-cbc-256 throughput 600Mbps, asymmetric RSA private key decryption 200 times/s. Regardless of the other software level of overhead, 10G network card for symmetric encryption needs to consume about 17 cores CPU, 24 cores CPU access HTTPS connection 4800, the static node current 10G network card TS8 model of the HTTP single access capacity of about 10w/s, if all the HTTP connection to the H TTPs, the decryption of RSA becomes the bottleneck first. Therefore, the decryption capability of RSA is the main problem of the current disturbing HTTPS access.

5.2 HTTPS Access Optimization

1.CDN AccessHTTPS increased delay is mainly the transmission delay Rtt,rtt is characterized by a smaller node delay, the CDN natural away from the user recently, so choose to use the CDN as an entry for HTTPS access, will be able to greatly reduce the access delay. The CDN node greatly reduces the latency caused by HTTPS by maintaining a controllable method such as long connection, session multiplexing, and link quality optimization for the Business Server. 2. Session CachingAlthough the previous reference to HTTPS even with the session cache must be at least 1*rtt delay, but at least the delay has been reduced to the original half, obvious delay optimization; At the same time, the HTTPS connection based on the session cache does not require the server to decrypt the RSA private key to obtain pre-master information. Can eliminate the CPU consumption. If the business access connection is set and the cache hit ratio is high, HTTPS's access capability is significantly increased. The current TRP platform cache hit rate peak time greater than 30%,10k/s access resources can actually carry 13k/access, the results are very impressive. 3. Hardware accelerationInstall a dedicated SSL hardware accelerator card for the Access server, acting like a GPU, freeing up the CPU and being able to have higher HTTPS access without impacting business processes. Testing a hardware accelerator card can provide 35k decryption capacity, equivalent to 175 core CPU, at least 7 24-core server, considering the cost of Access server other programs, a hardware card can achieve access to nearly 10 servers. 4. Remote decryptionLocal access consumes too much CPU resources, waste network cards and hard disk resources, consider the most CPU-intensive RSA Decryption computing task to other servers, so you can fully play the server's access, make full use of bandwidth and network card resources. The remote decryption server can choose a machine with low CPU load to perform machine resource reuse, or it can be a server dedicated to optimizing high computational performance. Today is also one of the solutions for large-scale HTTPS access for CDNs. 5.SPDY/HTTP2The previous method improves the HTTPS access performance from the method of reducing transmission delay and single load, but the method is based on the optimization method which does not change the HTTP protocol, SPDY/HTTP2 uses the advantages of TLS/SSL, and improves the performance of HTTPS by modifying the protocol method. Increase download speed and more.

Full Station HTTPS