TLS handshake processing method and device, electronic equipment and storage medium
By performing the binding operation of the acceleration card instance on the new process and determining the hardware resources based on the binding results, the problems of large CPU overhead and insufficient acceleration card resources in the TLS handshake are solved, and efficient TLS handshake processing and maximizing the utilization of computing resources are achieved.
Patent Information
- Application Number
- CN202311284378.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-09-28
- Publication Date
- 2025-03-28
AI Technical Summary
In the prior art, when handling TLS handshakes, the CPU overhead is high and the acceleration card instance is insufficient, the process snatching the acceleration card leads to abnormal errors, or when the number of processes is equal to the number of acceleration card support, the computing resources cannot be fully utilized.
By obtaining all new processes newly launched by the gateway and performing accelerator card instance binding operation on it, determine the corresponding hardware resources for each process. Even if the accelerator card instance is insufficient, the CPU is used to implement the process's TLS handshake calculation, thereby maximizing the utilization of device resources.
It effectively avoids the accelerator card grabbing error caused by excessive processes, and makes full use of computing resources to ensure efficient handling of TLS handshake.
Smart Images
Figure CN119728782A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of data processing technology, and in particular to a TLS handshake processing method and device, an electronic device, and a storage medium. Background Art
[0002] At present, TLS (i.e., Transport Layer Security) has become the main transmission protocol for Internet security. While TLS brings higher security, it also brings more performance overhead. Especially in the connection handshake phase, the CPU overhead of TLS is much larger than that of TCP. The industry has made many software and protocol level optimizations to optimize TLS performance, including: Session multiplexing, OCSP Stapling, TLS1.3, etc. However, today when Moore's Law is "invalid", software-level optimizations can hardly meet the growing traffic, and using dedicated hardware technology to offload CPU calculations has become a common solution. Intel provides a complete solution for TLS asynchronous acceleration: Intel QuickAssist Technology (QAT), referred to as Intel QAT technology
[0003] QAT Engine is the core module of the QAT technical solution. Its main function is to serve as an intermediate layer between the application and the hardware. It is responsible for transmitting the encryption and decryption calculation results between the user application and the hardware card for the "input and output data of the encryption and decryption operation". QAT Engine is provided to users in the form of an OpenSSL third-party plug-in, which means that users can use the OpenSSL standard API to accelerate TLS. They only need to make OpenSSL asynchronous transformations to the original code to enjoy the TLS performance acceleration brought by QAT technology, which is less invasive to the business. QAT Engine supports two acceleration methods: 1. Software acceleration (qat_sw), using Multi-Buffer (SIMD) technology to optimize the parallel processing of cryptographic algorithms; 2. Hardware acceleration (qat_hw), using the QAT accelerator card to transfer the cryptographic algorithm calculation from the CPU OffLoad to the accelerator card.
[0004] The core of hardware acceleration is to separate the asymmetric encryption and decryption operations in TLS and put them into the QAT acceleration card for calculation, which not only frees up the CPU, but also the dedicated acceleration card provides higher encryption and decryption performance.
[0005] In the related art, the number of processes of online services is limited and is limited to the number of processes supported by the QAT acceleration card (generally half of the number of all processes contained in the QAT acceleration card). If too many processes are opened, too many processes will grab the QAT acceleration card and cause abnormal errors; if the number of opened processes is equal to the number of processes supported by the QAT acceleration card, the computing resources of the device (acceleration card, CPU, memory, etc.) cannot be fully used, which will lead to a waste of computing resources.
[0006] It can be seen that the related technology has the technical problems mentioned above. Summary of the invention
[0007] The present application provides a TLS handshake processing method and device, an electronic device and a storage medium to at least solve at least one technical problem existing in the related art.
[0008] According to one aspect of an embodiment of the present application, a method for processing a TLS handshake is provided, including:
[0009] Get all new processes started by the gateway;
[0010] Performing an accelerator card instance binding operation on all the new processes, and obtaining binding results between all the new processes and all the accelerator card instances, wherein each accelerator card instance is used to bind at least one new process;
[0011] According to the binding result, determine the hardware resources corresponding to each process in all the processes, wherein the all the processes include the all the new processes and the old processes that the gateway has left to calculate on the accelerator card before starting all the new processes, and the hardware resources include: a CPU or the accelerator card;
[0012] According to the hardware resources corresponding to each process, the hardware resources for calculating each TLS handshake to be executed are determined, wherein the TLS handshake to be executed includes: a new TLS handshake executed by the new process or an old TLS handshake executed by the old process.
[0013] Optionally, as in the aforementioned method, before performing the accelerator card instance binding operation on all the new processes and obtaining the binding results between all the new processes and all the accelerator card instances, the method further includes:
[0014] After the new process is successfully started, an exit signal is sent to the old process, wherein the exit signal is used to instruct the old process to transfer the old TLS handshake from the accelerator card calculation to the CPU calculation;
[0015] The old process transfers the old TLS handshake according to the exit signal.
[0016] Optionally, as in the aforementioned method, the old process transfers the old TLS handshake according to the exit signal, including:
[0017] The old process determines, according to the exit signal, whether there is a first old TLS handshake in the calculation process and a second old TLS handshake that has not started calculation;
[0018] In the case where the second old TLS handshake exists, the old process transfers the second old TLS handshake to the CPU;
[0019] In the case where the first old TLS handshake exists, the old process waits for the first old TLS handshake to be calculated on the accelerator card and then releases the accelerator card instance bound to the old process;
[0020] Determining the hardware resources corresponding to each process in all the processes according to the binding result includes:
[0021] It is determined that the hardware resource corresponding to the old process is a CPU.
[0022] Optionally, as in the aforementioned method, the method further comprises:
[0023] The old process releases the accelerator card instance bound to the old process when it is determined according to the exit signal that there is no unfinished old TLS handshake.
[0024] Optionally, as in the aforementioned method, performing an accelerator card instance binding operation on all new processes and obtaining binding results between all new processes and all accelerator card instances includes:
[0025] After executing the accelerator card binding operation, a first binding result is obtained in which a first new process among all the new processes is successfully bound to the target accelerator card instance;
[0026] Initializing the target accelerator card instance according to the first binding result;
[0027] Determining the hardware resources corresponding to each process in all the processes according to the binding result includes:
[0028] According to the first binding result, it is determined that the hardware resource corresponding to the first new process is an accelerator card.
[0029] Optionally, as in the aforementioned method, performing an accelerator card instance binding operation on all new processes and obtaining binding results between all new processes and all accelerator card instances includes:
[0030] After executing the accelerator card binding operation, a second binding result is obtained in which a second new process among all the new processes is not successfully bound to the accelerator card instance;
[0031] Binding the second new process to the CPU according to the second binding result;
[0032] Determining the hardware resources corresponding to each process in all the processes according to the binding result includes:
[0033] According to the second binding result, it is determined that the hardware resource corresponding to the second new process is a CPU.
[0034] Optionally, as in the foregoing method, after determining that the hardware resource corresponding to the second new process is a CPU, the method further includes:
[0035] After a preset time interval, determining whether there is a released idle accelerator card instance among all the accelerator card instances;
[0036] In the case where the idle acceleration card instance exists, the second new process is bound to the idle acceleration card instance.
[0037] According to another aspect of an embodiment of the present application, a TLS handshake processing device is also provided, including:
[0038] The acquisition module is used to obtain all new processes newly started by the gateway;
[0039] A binding module, used to perform an accelerator card instance binding operation on all the new processes, and obtain binding results between all the new processes and all the accelerator card instances, wherein each accelerator card instance is used to bind at least one new process;
[0040] A first determination module is used to determine, according to the binding result, a hardware resource corresponding to each process in all processes, wherein the all processes include all new processes and old processes that are calculated by the gateway on the acceleration card before the gateway newly starts all new processes, and the hardware resources include: a CPU or the acceleration card;
[0041] The second determination module is used to determine the hardware resources for calculating each TLS handshake to be executed according to the hardware resources corresponding to each process, wherein the TLS handshake to be executed includes: a new TLS handshake executed by the new process or an old TLS handshake executed by the old process.
[0042] According to another aspect of the embodiments of the present application, there is also provided an electronic device, including a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus; wherein the memory is used to store a computer program; and the processor is used to execute the method steps in any of the above embodiments by running the computer program stored in the memory.
[0043] According to another aspect of the embodiments of the present application, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the method steps in any of the above embodiments when executed.
[0044] In an embodiment of the present application, by performing an accelerator card instance binding operation on all new processes and determining the hardware resources corresponding to each process in all processes based on the binding result; even when the accelerator card instances are insufficient, the CPU can be used to implement the TLS handshake calculation of the corresponding process, so that even if all accelerator card instances included in the accelerator card are used; there will be no situation where the accelerator card instance is snatched because the sum of the number of new processes and old processes is greater than the total number of accelerator card instances. Therefore, while there is no need to limit the number of accelerator card instances in use to half, the device resources can be maximized; thereby effectively overcoming the technical problem in the related art that too many processes are opened, too many processes will snatch the accelerator card instance, causing abnormal errors; if the number of opened processes is equal to the number of processes supported by the accelerator card (for example, the number of accelerator card instances in use is limited to half), the computing resources of the device cannot be fully used, which will lead to a waste of computing resources. BRIEF DESCRIPTION OF THE DRAWINGS
[0045] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.
[0046] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.
[0047] Figure 1 is a schematic diagram of a hardware environment of an optional TLS handshake processing method according to an embodiment of the present application;
[0048] Figure 2 It is a flowchart of an optional TLS handshake processing method according to an embodiment of the present application;
[0049] Figure 3 is a structural block diagram of an optional TLS handshake processing device according to an embodiment of the present application;
[0050] Figure 4 It is a structural block diagram of an optional electronic device according to an embodiment of the present application. DETAILED DESCRIPTION
[0051] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.
[0052] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.
[0053] According to one aspect of an embodiment of the present application, a method for processing a TLS handshake is provided. Optionally, in this embodiment, the method for processing a TLS handshake can be applied to Figure 1 In the hardware environment composed of terminal 1402 and server 1404 shown in FIG. Figure 1 As shown, server 1404 is connected to terminal 1402 via a network, and can be used to provide services (such as game services, application services, etc.) for the terminal or a client installed on the terminal. A database can be set up on the server or independently of the server to provide data storage services for server 1404.
[0054] The above network may include but is not limited to at least one of the following: wired network, wireless network. The above wired network may include but is not limited to at least one of the following: wide area network, metropolitan area network, local area network, and the above wireless network may include but is not limited to at least one of the following: WIFI (Wireless Fidelity), Bluetooth. The terminal may not be limited to a PC, a mobile phone, a tablet computer, etc.
[0055] The TLS handshake processing method of the embodiment of the present application can be executed by a server, or by a terminal, or by both a server and a terminal. The terminal can also execute the TLS handshake processing method of the embodiment of the present application by a client installed thereon.
[0056] Taking the processing method of the TLS handshake in this embodiment executed by the server as an example, Figure 2 An optional TLS handshake processing method provided in an embodiment of the present application includes the following steps:
[0057] Step S101, obtaining all new processes newly started by the gateway.
[0058] The TLS handshake processing method in this embodiment can be applied to the scenario of scheduling the process of online services to hardware resources, for example, the scenario of executing TLS handshake by CPU and / or executing TLS handshake by QAT accelerator card. It is especially aimed at the scenario of flexible offloading of TLS encryption and decryption based on accelerator card in a large concurrency scenario.
[0059] Specifically, when the gateway (i.e., NGINX) soft restarts (i.e., reloads, for example, to implement software configuration changes) or hot starts (i.e., upgrades, for example, to implement software upgrades), it will start a new batch of processes, which need to be bound to hardware resources to implement process calculations.
[0060] Step S102, performing an accelerator card instance binding operation on all new processes, and obtaining binding results between all new processes and all accelerator card instances, wherein each accelerator card instance is used to bind at least one new process.
[0061] Specifically, after all new processes are acquired, a binding operation may be performed to bind the new processes to the accelerator card instance.
[0062] The binding operation may include but is not limited to: binding a new process to an idle accelerator card instance, and after releasing the accelerator card instance bound to the old process (i.e., unbinding the accelerator card instance from the old process), binding the accelerator card instance to the new process so that the calculation corresponding to the new process can be processed through the accelerator card instance; binding the new process to the CPU so that the calculation corresponding to the new process can be processed through the CPU.
[0063] After the binding operation is completed, the binding results between the new process and all accelerator card instances can be obtained. Generally, a process is only allowed to be bound to one accelerator card instance.
[0064] In this embodiment, all accelerator card instances are all instances included in the accelerator card.
[0065] Step S103, according to the binding result, determine the hardware resources corresponding to each process in all processes, wherein all processes include all new processes and old processes left on the accelerator card for calculation before the gateway starts all new processes, and the hardware resources include: CPU or accelerator card.
[0066] Specifically, after obtaining the binding result, the hardware resources corresponding to each process in all processes can be determined.
[0067] That is to say, when a new process is bound to an idle accelerator card instance, the hardware resource corresponding to the new process is the accelerator card; when the new process requires the old process to release the accelerator card instance in order to bind the accelerator card instance, the hardware resource corresponding to the new process is the accelerator card, and the hardware resource corresponding to the old process changes from the accelerator card to the CPU; when a new process cannot be bound to an accelerator card instance (for example, when there are not enough accelerator card instances), it can only be bound to the CPU, so the hardware resource corresponding to the new process is the CPU.
[0068] Step S104, determining and calculating the hardware resources for each TLS handshake to be executed according to the hardware resources corresponding to each process, wherein the TLS handshake to be executed includes: a new TLS handshake executed by a new process or an old TLS handshake executed by an old process.
[0069] Specifically, since each process is used to execute one or more TLS handshakes, after determining the hardware resources corresponding to each process, the hardware resources corresponding to each process can be determined as the hardware resources used to calculate the TLS handshakes that need to be executed by the process.
[0070] Through the method of this embodiment, by performing the accelerator card instance binding operation on all new processes, and determining the hardware resources corresponding to each process in all processes based on the binding results; even when the accelerator card instances are insufficient, the CPU can be used to implement the TLS handshake calculation of the corresponding process, so that even if all the accelerator card instances included in the accelerator card are used; there will be no situation where the accelerator card instance is snatched because the sum of the number of new processes and old processes is greater than the total number of accelerator card instances. Therefore, while there is no need to limit the number of accelerator card instances in use to half, the device resources can be maximized; thereby, the technical problem that too many processes are opened in the related art, too many processes will snatch the accelerator card instance, causing abnormal errors; if the number of opened processes is equal to the number of processes supported by the accelerator card (for example, the number of accelerator card instances in use is limited to half), the computing resources of the device cannot be fully used, which will lead to a waste of computing resources.
[0071] As an optional embodiment, as in the above method, before performing the accelerator card instance binding operation on all new processes in step S102 and obtaining the binding results between all new processes and all accelerator card instances, the method further includes the following steps:
[0072] After the new process is successfully started, an exit signal is sent to the old process, wherein the exit signal is used to instruct the old process to transfer the old TLS handshake from the accelerator card calculation to the CPU calculation; the old process transfers the old TLS handshake according to the exit signal.
[0073] Specifically, this embodiment takes any old process as an example: when nginx is soft-restarted (i.e., reloaded), a batch of new processes will be started. When this batch of new processes is started successfully, an exit signal can be sent to the previous old process to make the old process exit, that is, to instruct the old process to transfer the old TLS handshake from the accelerator card calculation to the CPU calculation.
[0074] After receiving the exit signal, the old process can respond to the exit signal and transfer the old TLS handshake calculation performed by the old process from the accelerator card to the CPU calculation.
[0075] Through the method of this embodiment, the old process can be unbound from the acceleration card so that the acceleration card can be used to bind a new process.
[0076] As an optional embodiment, as in the aforementioned method, the step of transferring the old TLS handshake according to the exit signal by the old process includes the following steps:
[0077] Step S201: The old process determines whether there is a first old TLS handshake in the process of calculation and a second old TLS handshake that has not started calculation according to the exit signal.
[0078] That is, after the old process obtains the exit signal, it can be determined whether there is a first old TLS handshake in the calculation process and a second old TLS handshake that has not started calculation among all the old TLS handshakes corresponding to the old process.
[0079] Step S202: If the second old TLS handshake exists, the old process transfers the second old TLS handshake to the CPU.
[0080] Among all the old TLS handshakes corresponding to the old process, if there is a second old TLS handshake, the old process transfers the second old TLS handshake to the CPU. The accelerator card instance bound to the old process does not continue to perform the calculation of the second old TLS handshake, but transfers the second old TLS handshake to the CPU, and the CPU performs the calculation of the second old TLS handshake.
[0081] Step S203: When the first old TLS handshake exists, the old process waits for the first old TLS handshake to be calculated on the accelerator card, and then releases the accelerator card instance bound to the old process;
[0082] In the case where the first old TLS handshake exists, the old process waits for the first old TLS handshake to be calculated on the accelerator card before releasing the accelerator card instance bound to the old process.
[0083] As an optional embodiment, as in the above method, the method further includes:
[0084] The old process releases the accelerator card instance bound to the old process according to the exit signal and determines that there is no unfinished old TLS handshake.
[0085] That is to say, when all old TLS handshakes of the old process itself have been completed, the accelerator card instance bound to the old process is directly released.
[0086] According to the binding result, the hardware resources corresponding to each process in all processes are determined, including:
[0087] It is determined that the hardware resource corresponding to the old process is the CPU.
[0088] After the old process releases the accelerator card instance to which it is bound, the later stages of the TLS handshake processed by the old process are all calculated by the CPU, so the hardware resource corresponding to the old process is the CPU.
[0089] The method of this embodiment can achieve the purpose of releasing the accelerator card instance bound to the old process.
[0090] As an optional embodiment, as in the above method, step S102 performs an accelerator card instance binding operation on all new processes and obtains binding results between all new processes and all accelerator card instances, including the following steps:
[0091] After the accelerator card binding operation is performed, a first binding result is obtained in which the first new process among all new processes is successfully bound to the target accelerator card instance; and the accelerator card instance is initialized according to the first binding result.
[0092] Specifically, after executing the accelerator card binding operation, the newly started new process attempts to bind to the accelerator card instance. If the first new process among all new processes is successfully bound to the target accelerator card instance, a first binding result is obtained to indicate that the first new process is successfully bound to the target accelerator card instance; then the initialization of the target accelerator card instance is completed according to the first binding result, and the subsequent processing of the TLS handshake by the first new process will be offloaded to the accelerator card (qat) for calculation.
[0093] The first new process may be any new process that is successfully bound to the accelerator card instance.
[0094] According to the binding result, the hardware resources corresponding to each process in all processes are determined, including:
[0095] According to the first binding result, it is determined that the hardware resource corresponding to the first new process is an accelerator card.
[0096] After obtaining the first binding result, it can be determined that the hardware resource corresponding to the first new process is the accelerator card, that is, all TLS handshakes corresponding to the first new process are calculated by the accelerator card.
[0097] As an optional embodiment, as in the above method, step S102 performs an accelerator card instance binding operation on all new processes and obtains binding results between all new processes and all accelerator card instances, including the following steps:
[0098] After the acceleration card binding operation is performed, a second binding result is obtained in which the second new process in all the new processes is not successfully bound to the acceleration card instance; according to the second binding result, the second new process is bound to the CPU.
[0099] Specifically, after executing the accelerator card binding operation, the newly started new process attempts to bind to the accelerator card instance. If 3) if the newly started second new process fails to bind to the accelerator card instance (for example, there are insufficient accelerator card instances), a second binding result is obtained to indicate that the second new process failed to successfully bind to the target accelerator card instance; then the initialization work of the target accelerator card instance is completed according to the second binding result, and the CPU will complete the calculation of the TLS handshake processed by the second new process.
[0100] The second new process may be any new process that fails to successfully bind to the accelerator card instance.
[0101] According to the binding result, the hardware resources corresponding to each process in all processes are determined, including:
[0102] According to the second binding result, it is determined that the hardware resource corresponding to the second new process is the CPU.
[0103] After obtaining the second binding result, it can be determined that the hardware resource corresponding to the second new process is the CPU, that is, all TLS handshakes corresponding to the second new process are calculated by the CPU.
[0104] As an optional embodiment, as in the above method, after determining that the hardware resource corresponding to the second new process is the CPU, the method further includes the following steps:
[0105] After a preset time interval, it is determined whether there is a released idle accelerator card instance in all accelerator card instances; if there is an idle accelerator card instance, the second new process is bound to the idle accelerator card instance.
[0106] Specifically, if the newly started second new process fails to bind to the accelerator card instance, the CPU will complete the calculation of the TLS handshake processed by the second new process.
[0107] However, at the same time, it is still desired to offload the TLS handshake to the accelerator card for calculation. Therefore, in this embodiment, a timer can be started to try to bind the accelerator card instance at a preset time interval to determine whether there is an idle accelerator card instance that has been released among all accelerator card instances; if there is an idle accelerator card instance, the second new process is bound to the idle accelerator card instance.
[0108] That is to say, the second new process waits for other processes bound to the accelerator card instance to release the idle accelerator card instance, and binds the idle accelerator card instance to its own second new process. If the timer is not used (that is, the method of this embodiment is not executed at a preset time interval), the second new process will try to bind the idle accelerator card instance for each TLS handshake, which will cause very poor performance.
[0109] As described below, an application example of applying any of the above embodiments is provided:
[0110] 1) When nginx (i.e., gateway) is soft-reloaded or hot-restarted, a new batch of processes will be started. After these new processes are successfully started, an exit signal will be sent to the previous old processes to make them exit.
[0111] 2) The new process attempts to bind to the accelerator card instance. If the binding is successful, the initialization of the accelerator card instance bound to the first new process is continued. The subsequent TLS handshake processing of the first new process will be offloaded to the accelerator card (qat) for calculation.
[0112] 3) If the second new process fails to bind to the accelerator card instance (insufficient accelerator card instances), the CPU will complete the calculation of the TLS handshake processing in the second new process, and start the timer to try to bind to the accelerator card instance at fixed intervals (in fact, it is to wait for other processes to release instances and bind the accelerator card instance to the second new process. If the timer is not used, each TLS handshake will try to bind to the accelerator card instance, which will result in very low performance).
[0113] 4) As soon as the old process receives the exit signal, it transfers the first old TLS handshake from the accelerator card calculation to the CPU calculation, and checks the TLS handshakes that have not been calculated on the accelerator card. If there are still TLS handshakes that have not been calculated (i.e., the first old TLS handshake), wait for the calculation to be completed. If the accelerator card has no unfinished calculations, the accelerator card instance is actively released (if not, the bound accelerator card instance is actively released, and it is automatically released when the process exits. The active release here is to complete the action of releasing the accelerator card instance as soon as possible, so that the new process can complete the accelerator card instance binding earlier). This embodiment adopts a multi-process service architecture. During a soft restart, the location of the TLS handshake calculation (CPU, accelerator card) is flexibly switched through the new and old processes, and the new process actively detects the number of available instances of the accelerator card, and the old process releases the accelerator card instance as soon as possible, so as to achieve a breakthrough in the limitation of the accelerator card hardware resources in software services.
[0114] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.
[0115] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM (Read-Only Memory) / RAM (Random Access Memory), a disk, or an optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present application.
[0116] According to another aspect of an embodiment of the present application, a TLS handshake processing device for implementing the above-mentioned TLS handshake processing method is also provided. Figure 3 is a structural block diagram of an optional TLS handshake processing device according to an embodiment of the present application, such as Figure 3 As shown, the device may include:
[0117] Acquisition module 1 is used to acquire all new processes newly started by the gateway;
[0118] Binding module 2, used to perform accelerator card instance binding operation on all new processes, and obtain binding results between all new processes and all accelerator card instances, wherein each accelerator card instance is used to bind at least one new process;
[0119] The first determination module 3 is used to determine the hardware resources corresponding to each process in all processes according to the binding result, wherein all processes include all new processes and old processes that the gateway has left on the accelerator card for calculation before starting all new processes, and the hardware resources include: CPU or accelerator card;
[0120] The second determination module 4 is used to determine the hardware resources for calculating each TLS handshake to be executed according to the hardware resources corresponding to each process, wherein the TLS handshake to be executed includes: a new TLS handshake executed by a new process or an old TLS handshake executed by an old process.
[0121] It should be noted that the acquisition module 1 in this embodiment can be used to execute the above step S101, the binding module 2 in this embodiment can be used to execute the above step S102, the first determination module 3 in this embodiment can be used to execute the above step S103, and the second determination module 4 in this embodiment can be used to execute the above step S104.
[0122] The device in this embodiment, in addition to the above-mentioned modules, may also include a module for executing any method in any of the aforementioned TLS handshake processing methods.
[0123] It should be noted that the examples and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the contents disclosed in the above embodiments. It should be noted that the above modules as part of the device can be run in Figure 1 In the hardware environment shown, it can be implemented by software or by hardware, wherein the hardware environment includes a network environment.
[0124] According to another aspect of an embodiment of the present application, an electronic device for implementing the above-mentioned TLS handshake processing method is also provided. The electronic device may be a server, a terminal, or a combination thereof.
[0125] According to another embodiment of the present application, there is also provided an electronic device, including: Figure 4 As shown, the electronic device may include: a processor 1501 , a communication interface 1502 , a memory 1503 and a communication bus 1504 , wherein the processor 1501 , the communication interface 1502 , and the memory 1503 communicate with each other via the communication bus 1504 .
[0126] Memory 1503, used for storing computer programs;
[0127] The processor 1501 is used to implement the following steps when executing the program stored in the memory 1503:
[0128] Step S101, obtaining all new processes newly started by the gateway.
[0129] Step S102, performing an accelerator card instance binding operation on all new processes, and obtaining binding results between all new processes and all accelerator card instances, wherein each accelerator card instance is used to bind at least one new process.
[0130] Step S103, according to the binding result, determine the hardware resources corresponding to each process in all processes, wherein all processes include all new processes and old processes left on the accelerator card for calculation before the gateway starts all new processes, and the hardware resources include: CPU or accelerator card.
[0131] Step S104, determining and calculating the hardware resources for each TLS handshake to be executed according to the hardware resources corresponding to each process, wherein the TLS handshake to be executed includes: a new TLS handshake executed by a new process or an old TLS handshake executed by an old process.
[0132] Optionally, in this embodiment, the above-mentioned communication bus can be a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus. The communication interface is used for communication between the above-mentioned electronic device and other devices.
[0133] The memory may include a random access memory (RAM) or a non-volatile memory (NVM), such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.
[0134] As an example, the memory 1503 may include, but is not limited to, the acquisition module 1, the binding module 2, the first determination module 3, and the second determination module 4 in the TLS handshake processing device. In addition, other module units in the TLS handshake processing device may also be included but are not limited to, which will not be repeated in this example.
[0135] The above-mentioned processor can be a general-purpose processor, which can include but not be limited to: CPU (Central Processing Unit), NP (Network Processor), etc.; it can also be DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.
[0136] An embodiment of the present application further provides a computer-readable storage medium, the storage medium including a stored program, wherein the method steps of the above method embodiment are executed when the program is run.
[0137] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media that can store program codes, such as a USB flash drive, a ROM, a RAM, a mobile hard disk, a magnetic disk, or an optical disk.
[0138] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.
[0139] If the integrated units in the above embodiments are implemented in the form of software functional units and sold or used as independent products, they can be stored in the above computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application.
[0140] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.
[0141] In the several embodiments provided in the present application, it should be understood that the disclosed client can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.
[0142] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution provided in this embodiment.
[0143] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.
[0144] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.
Claims
1. A method for processing a TLS handshake, characterized in that: include: Get all new processes started by the gateway; Performing an accelerator card instance binding operation on all the new processes, and obtaining binding results between all the new processes and all the accelerator card instances, wherein each accelerator card instance is used to bind at least one new process; According to the binding result, determine the hardware resources corresponding to each process in all the processes, wherein the all the processes include the all the new processes and the old processes that the gateway has left to calculate on the accelerator card before starting all the new processes, and the hardware resources include: a CPU or the accelerator card; According to the hardware resources corresponding to each process, the hardware resources for calculating each TLS handshake to be executed are determined, wherein the TLS handshake to be executed includes: a new TLS handshake executed by the new process or an old TLS handshake executed by the old process.
2. The method according to claim 1, characterized in that Before performing the accelerator card instance binding operation on all the new processes and obtaining the binding results between all the new processes and all the accelerator card instances, the method further includes: After the new process is successfully started, an exit signal is sent to the old process, wherein the exit signal is used to instruct the old process to transfer the old TLS handshake from the accelerator card calculation to the CPU calculation; The old process transfers the old TLS handshake according to the exit signal.
3. The method according to claim 2, characterized in that The old process transfers the old TLS handshake according to the exit signal, including: The old process determines, according to the exit signal, whether there is a first old TLS handshake in the calculation process and a second old TLS handshake that has not started calculation; In the case where the second old TLS handshake exists, the old process transfers the second old TLS handshake to the CPU; In the case where the first old TLS handshake exists, the old process waits for the first old TLS handshake to be calculated on the accelerator card and then releases the accelerator card instance bound to the old process; Determining the hardware resources corresponding to each process in all the processes according to the binding result includes: It is determined that the hardware resource corresponding to the old process is a CPU.
4. The method according to claim 2, characterized in that: The method further comprises: The old process releases the accelerator card instance bound to the old process when it is determined according to the exit signal that there is no unfinished old TLS handshake.
5. The method according to claim 1, characterized in that The performing the accelerator card instance binding operation on all the new processes and obtaining the binding results between all the new processes and all the accelerator card instances includes: After executing the accelerator card binding operation, a first binding result is obtained in which a first new process among all the new processes is successfully bound to the target accelerator card instance; Initializing the target accelerator card instance according to the first binding result; Determining the hardware resources corresponding to each process in all the processes according to the binding result includes: According to the first binding result, it is determined that the hardware resource corresponding to the first new process is an accelerator card.
6. The method according to claim 1, characterized in that The performing the accelerator card instance binding operation on all the new processes and obtaining the binding results between all the new processes and all the accelerator card instances includes: After executing the accelerator card binding operation, a second binding result is obtained in which a second new process among all the new processes is not successfully bound to the accelerator card instance; Binding the second new process to the CPU according to the second binding result; Determining the hardware resources corresponding to each process in all the processes according to the binding result includes: According to the second binding result, it is determined that the hardware resource corresponding to the second new process is a CPU.
7. The method according to claim 6, characterized in that After determining that the hardware resource corresponding to the second new process is a CPU, the method further includes: After a preset time interval, determining whether there is a released idle accelerator card instance among all the accelerator card instances; In the case where the idle acceleration card instance exists, the second new process is bound to the idle acceleration card instance.
8. A TLS handshake processing device, characterized in that: include: The acquisition module is used to obtain all new processes newly started by the gateway; A binding module, used to perform an accelerator card instance binding operation on all the new processes, and obtain binding results between all the new processes and all the accelerator card instances, wherein each accelerator card instance is used to bind at least one new process; A first determination module is used to determine, according to the binding result, a hardware resource corresponding to each process in all processes, wherein the all processes include all new processes and old processes that are calculated by the gateway on the acceleration card before the gateway newly starts all new processes, and the hardware resources include: a CPU or the acceleration card; The second determination module is used to determine the hardware resources for calculating each TLS handshake to be executed according to the hardware resources corresponding to each process, wherein the TLS handshake to be executed includes: a new TLS handshake executed by the new process or an old TLS handshake executed by the old process.
9. An electronic device comprising a processor, a communication interface, a memory and a communication bus, wherein: The processor, the communication interface and the memory communicate with each other via the communication bus, wherein: The memory is used to store computer programs; The processor is configured to execute the method steps of any one of claims 1 to 7 by running the computer program stored in the memory.
10. A computer-readable storage medium, characterized in that: The storage medium stores a computer program, wherein the computer program is configured to execute the method steps described in any one of claims 1 to 7 when run.