A KVM communication link monitoring and breakpoint self-recovery reconnection method and system based on TCP / TLS encryption

Abstract

The application discloses a KVM communication link monitoring and breakpoint self-recovery reconnection method and system based on TCP / TLS encryption, relates to the technical fields of KVM remote control communication and encrypted link self-recovery, and comprises the following steps: establishing a TCP connection, loading a CA certificate to complete TLS handshake, and saving a session ticket issued by a server; starting a heartbeat detection thread and acquiring a link on-off signal, and writing a heartbeat timestamp and the link on-off signal into a communication state table; marking a network cable disconnection and a device connection disconnection according to link disconnection or heartbeat timeout, and releasing a TCP connection and TLS resources; triggering TCP reconnection when a link is recovered or a preset period is reached, submitting the session ticket to complete TLS session recovery; and marking a device normal connection and restarting the heartbeat detection thread after receiving a heartbeat response. The application can improve KVM communication link abnormality identification precision and breakpoint recovery efficiency.

Description

Technical Field

[0001] This invention relates to the field of KVM remote control communication and encrypted link self-healing technology, and in particular to a method and system for monitoring and reconnecting KVM communication links based on TCP / TLS encryption. Background Technology

[0002] With the development of remote operation and maintenance, centralized data center management, and unattended industrial site operations, KVM remote control technology has gradually evolved from simple video extension and keyboard / mouse forwarding to a networked remote control method for servers, industrial control computers, and dedicated equipment. These systems typically rely on long-lived TCP connections to carry video previews, keyboard / mouse commands, and device control data, and further introduce TLS encryption mechanisms to improve data confidentiality, integrity, and server identity trust during link transmission. However, KVM communication links are characterized by long-term online operation, real-time interaction, sensitivity to weak network fluctuations, and frequent changes in on-site link status. Relying solely on ordinary TCP connections or basic TLS handshake mechanisms makes it difficult to promptly distinguish between different fault states such as physical network cable disconnection, device-side service anomalies, TLS resource failures, and silent link disconnections. Existing technologies have made some progress in establishing remote control links, but their focus is mainly on link access, server selection, or connection availability assurance. They lack sufficient coordination in the processing of heartbeat timestamps, link connectivity signals, communication status tables, and TLS session recovery in KVM scenarios. This results in delayed detection of communication anomalies, long breakpoint recovery times, and the need for manual restarts or re-initialization of connections in unattended scenarios.

[0003] CN110740162B discloses a method and apparatus for establishing a communication link for a remote control router, an electronic device, and a computer-readable medium. The scheme includes receiving an access request from a target router for accessing a remote control server; responding to the access request; selecting a target message server from a set of available message servers based on message server priority information; and establishing a communication link between the target router and the remote control server based on the selected target message server, enabling the target router to access the remote control server through the communication link. This scheme can improve the availability of the remote control link establishment phase through message server priority selection, reducing the risk of remote authentication failure due to a faulty message server participating in communication. However, its core technology lies in the message server selection and communication link establishment in the remote control router scenario. It does not set up a heartbeat detection thread for the long-connection characteristics of video and keyboard / mouse control of KVM devices, nor does it uniformly write the heartbeat timestamp and link connection / disconnection signals into the communication status table. Therefore, it is difficult to make fine-grained distinctions between physical link disconnection, device connection disconnection, and TLS communication anomalies.

[0004] While CN110740162B involves the establishment of remote control communication links, it does not disclose the processing methods for loading CA certificates and completing TLS handshakes after TCP connection is established, issuing session tickets by the server, and retaining session tickets for TLS session recovery after abnormal disconnection. It also does not disclose differentiated exception handling logic for stopping heartbeat message sending when the link connection signal is broken, or releasing TCP connections and TLS resources when the link connection signal is established but the heartbeat timestamp has expired and not been refreshed. For KVM communication, simply selecting an available message server and establishing a communication link cannot solve the problems of silent disconnection identification during link operation, rapid recovery after TLS resource failure, and automatic reconnection after network recovery. Especially in remote industrial control maintenance, data center server management, and unattended equipment debugging scenarios, manual intervention after link interruption will reduce the continuity of remote operation and maintenance efficiency.

[0005] Therefore, existing remote control communication link establishment technologies suffer from problems such as insufficient granularity of link operation status monitoring, unclear differentiation of KVM long connection anomaly types, low efficiency of TLS breakpoint recovery, and insufficient self-healing and reconnection capabilities in unattended scenarios. This invention provides a method and system for monitoring and self-healing reconnection of KVM communication links based on TCP / TLS encryption. Summary of the Invention

[0006] The purpose of this section is to outline some aspects of the embodiments of the present invention and to briefly introduce some preferred embodiments. Some simplifications or omissions may be made in this section, as well as in the abstract and title of the present application, to avoid obscuring the purpose of this section, the abstract and title of the invention. Such simplifications or omissions shall not be used to limit the scope of the present invention.

[0007] In view of the problems of existing remote KVM communication link monitoring and reconnection technologies, such as lagging link status perception, inability to distinguish between physical link disconnection and device connection disconnection, low recovery efficiency after TLS encrypted link anomalies, and reliance on manual intervention for breakpoint recovery, this invention is proposed.

[0008] Therefore, the problem to be solved by this invention is how to continuously monitor the operating status of the TCP / TLS encrypted communication link during KVM remote control, and complete automated breakpoint self-healing and reconnection after link interruption, device connection abnormality or network recovery.

[0009] To solve the above-mentioned technical problems, the present invention provides the following technical solution: In a first aspect, embodiments of the present invention provide a method for monitoring and self-healing reconnection of KVM communication links based on TCP / TLS encryption, including, Establish a TCP connection, load the CA certificate, complete the TLS handshake, the server sends a session ticket to the client, starts a heartbeat detection thread, and registers a link connectivity interface to obtain link connectivity signals. The heartbeat detection thread receives or sends heartbeat messages according to the heartbeat cycle and updates the heartbeat timestamp. The heartbeat timestamp and the link connection / disconnection signal are written into the communication status table. The heartbeat message includes a heartbeat request message and a heartbeat response message. When the link connection signal is broken, the network cable is marked as disconnected in the communication status table, and heartbeat message transmission is stopped; when the link connection signal is connected and the heartbeat timestamp expires and is not refreshed, the device connection is marked as disconnected in the communication status table, the TCP connection and TLS resources are released, and the session ticket is retained. When the link connection signal is restored or the device connection is disconnected for a duration greater than or equal to the preset period, TCP reconnection is triggered. After the new TCP connection is established, the session ticket is submitted to complete the TLS session recovery without repeating the certificate chain verification. After the TLS session is restored, a heartbeat response message is received, the device is marked as successfully connected in the communication status table, and the heartbeat detection thread is restarted.

[0010] Secondly, embodiments of the present invention provide a KVM communication link monitoring and breakpoint self-healing reconnection system based on TCP / TLS encryption, including: The link establishment initialization module is used to establish a TCP connection, load the CA certificate, complete the TLS handshake, send the session ticket from the server to the client, start the heartbeat detection thread, and register the link connectivity interface to obtain the link connectivity signal. The heartbeat status update module is used by the heartbeat detection thread to receive or send heartbeat messages according to the heartbeat cycle and update the heartbeat timestamp. The heartbeat timestamp and the link connection / disconnection signal are written into the communication status table. The heartbeat message includes a heartbeat request message and a heartbeat response message. The abnormal state determination module is used to mark the network cable as disconnected in the communication status table and stop sending heartbeat messages when the link connection signal is disconnected; when the link connection signal is connected and the heartbeat timestamp has expired and not been refreshed, it marks the device connection as disconnected in the communication status table, releases the TCP connection and TLS resources, and retains the session ticket. The session recovery and reconnection module is used to trigger TCP reconnection when the link connection signal is restored or the duration of the device connection being disconnected is greater than or equal to a preset period. After the new TCP connection is established, the session ticket is submitted to complete the TLS session recovery without repeating the certificate chain verification. The connection confirmation restart module is used to receive heartbeat response messages after the TLS session is restored, mark the device as normally connected in the communication status table, and restart the heartbeat detection thread.

[0011] Compared with existing technologies, the advantages of this invention are as follows: By establishing a TCP connection, loading a CA certificate to complete a TLS handshake, and receiving a session ticket bound to a session identifier, server address, server port, and server certificate fingerprint, an identity-verified KVM encrypted communication link is constructed, and session credentials are retained for subsequent breakpoint recovery; by using a heartbeat detection thread to send and receive heartbeat packets with session identifier, heartbeat sequence number, sending timestamp, and application layer verification fields according to the heartbeat cycle, the heartbeat timestamp corresponding to a valid heartbeat response and the link connectivity signal of the target network interface are synchronously written into the communication status table, reducing packet mismatch, misidentification of old packets, and misjudgments caused by different detection cycle state combinations; by prioritizing the judgment of the target network interface's operational status and media connection status, and then combining whether the heartbeat timestamp has expired, the device connection is distinguished between a disconnected network cable and a physically connected device connection, and the heartbeat sending is stopped or the invalid T is released accordingly. By optimizing CP connections and TLS resources, the probability of physical link interruptions, TCP half-open connections, and TLS silent failures being handled interchangeably is reduced. Two types of TCP reconnection trigger conditions are set based on link recovery events and the duration of device connection disconnection. Before reconnection, the connection status, link connectivity signals, and device connection disconnection start time are checked, reducing duplicate and invalid reconnections caused by concurrent state changes. By verifying the binding relationship and validity period of session tickets, either TLS session recovery or a full handshake is selected on the new TCP connection. This ensures that the reconnection process corresponding to a valid session ticket does not repeatedly execute certificate chain verification, while full identity verification is still performed when the ticket is invalid or the binding information is inconsistent. After TLS session recovery, a valid heartbeat response is used as the communication recovery criterion. Ultimately, this shortens KVM link recovery time, reduces computational overhead and remote control interruption duration during reconnection, and balances communication continuity and access security. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein: Figure 1 This is a flowchart of a method for monitoring and self-healing reconnection of KVM communication links based on TCP / TLS encryption. Figure 2 This is a structural diagram of a KVM communication link monitoring and breakpoint self-healing reconnection system based on TCP / TLS encryption. Detailed Implementation

[0013] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0014] Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without inventive effort should fall within the scope of protection of this invention.

[0015] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0016] As mentioned in the background section, existing remote control communication link establishment technologies mainly focus on establishing the communication link or selecting an available server. They do not address the need for coordinated processing of heartbeat detection, link connectivity signals, communication status tables, TCP resource release, and TLS session recovery for KVM long-term online, low-latency interactive, and unattended operation and maintenance scenarios. To address these issues, this invention provides a KVM communication link monitoring and self-healing reconnection method based on TCP / TLS encryption.

[0017] Reference Figures 1-2 , Figure 1 This is a flowchart illustrating a method for monitoring and self-healing reconnection of KVM communication links based on TCP / TLS encryption according to an embodiment of the present invention. Figure 1 As shown, a method for monitoring and self-healing reconnection of KVM communication links based on TCP / TLS encryption includes: S1: Establish a TCP connection, load the CA certificate, complete the TLS handshake, the server sends a session ticket to the client, starts the heartbeat detection thread, and registers the link connectivity interface to obtain link connectivity signals.

[0018] S1.1: The client reads the pre-configured server address, server port and device identifier, creates a KVM communication session, and establishes a communication status table in the KVM communication session.

[0019] In an optional embodiment, the method for creating a KVM communication session is as follows: the client calls the socket initialization interface provided by the operating system to initialize the network operating environment, allocates a session control block corresponding to the device identifier in local memory, and writes the server address, server port and device identifier into the session control block; the client reads the session creation time and generates a random number, combines the device identifier, session creation time and random number and performs a digest operation, extracts a preset byte from the digest result as the session identifier, and establishes an association between the communication status table and the session identifier.

[0020] Preferably, the session identifier is a 16-byte binary identifier. The session identifier remains unchanged in the communication messages between the client and the server and is used to distinguish different KVM communication sessions established by the same client. When creating the communication status table, the link connection signal is initialized to pending confirmation, the heartbeat timestamp is initialized to zero, the connection status is initialized to not connected, the session ticket storage status is initialized to not received, the TLS handshake status is initialized to not handshake, and the server certificate fingerprint is initialized to null.

[0021] It should be noted that the communication status table includes at least the session identifier, link connection / disconnection signal, heartbeat timestamp, connection status, session ticket storage status, and TLS handshake status, as shown in Table 1.

[0022] Table 1. Communication Status Table

[0023] S1.2: The client creates a socket based on the server address and port, and initiates a TCP connection request to the server through the socket; after receiving the TCP handshake response returned by the server, the client establishes a TCP connection between the client and the server.

[0024] In this embodiment of the application, when the server address is a domain name, the client first performs domain name resolution on the server address to obtain the IP address corresponding to the server address, then generates a server socket address based on the IP address and the server port, and initiates a TCP connection request to the server socket address.

[0025] It should be noted that after the TCP connection is established, the client writes the socket handle corresponding to the socket into the socket identifier in the communication state table, and changes the connection status in the communication state table from not connected to TCP connected, providing the underlying transmission channel for the subsequent TLS handshake.

[0026] Preferably, when a TCP connection is not established within the preset connection time, the client closes the socket, keeps the connection state as disconnected, and records the error information corresponding to this TCP connection failure.

[0027] S1.3: The client loads the pre-configured CA certificate, creates a TLS encryption context based on the CA certificate, and associates the TLS encryption context with the TCP connection.

[0028] In an optional embodiment, the CA certificate is stored on the client in the form of a string constant, binary certificate data, or a protected certificate file; after reading the CA certificate, the client writes the CA certificate to the trusted certificate storage area corresponding to the TLS encryption context as the root of trust for the server certificate chain verification; the TLS encryption context is configured with a TLS protocol version range, certificate verification rules, and a maximum certificate chain verification depth.

[0029] The TLS protocol version ranges from TLS1.2 to TLS1.3. The minimum protocol version for the TLS encryption context is set to TLS1.2, and the maximum protocol version is set to TLS1.3. Establishing TLS connections using protocol versions lower than TLS1.2 is prohibited.

[0030] The certificate verification rules are as follows: The client enables mandatory verification of the server certificate, and verifies the digital signature relationship of the server certificate chain, the certificate validity period, the certificate purpose and the server identity information in sequence; among them, the server identity information comes from the subject alternate name field in the server leaf certificate.

[0031] When the server address is a domain name, the client matches the server address with the domain name identifier in the topic alternate name field; when the server address is an IP address, the client matches the server address with the IP address identifier in the topic alternate name field.

[0032] The maximum certificate chain verification depth is 4 levels. A server-side certificate chain can include a maximum of server-side leaf certificates and three higher-level issued certificates. When a server-side certificate chain exceeds the maximum certificate chain verification depth, or when the server-side certificate chain cannot be traced back to the trust root corresponding to the CA certificate, the certificate chain verification result is recorded as failing, and certificates exceeding the maximum certificate chain verification depth are not ignored.

[0033] In an optional embodiment, the client also loads the certificate revocation list published by the certificate authority and compares the serial numbers of each certificate in the server-side certificate chain with the certificate revocation list; when the serial number of any certificate is recorded in the certificate revocation list, the certificate chain verification result is recorded as failing.

[0034] S1.4: The client writes the TLS handshake state in the communication state table into the handshake, sends a TLS handshake request to the server on the TCP connection, and receives the protocol negotiation result and server certificate chain returned by the server through the TLS encryption context.

[0035] In an optional embodiment, the method for verifying the server-side certificate chain is as follows: The client extracts the server leaf certificate and the certificates issued by each level of the superior certificate from the server certificate chain. Following the order from the server leaf certificate to the corresponding root of trust of the CA certificate, the client verifies the issuer information and subject information between adjacent certificates and uses the public key in the superior certificate to verify the digital signature of the subordinate certificate. The client reads the current system time and compares it with the effective and expiration times of each certificate in the server's certificate chain. If the current system time is earlier than the effective time of any certificate or later than the expiration time of any certificate, the certificate chain verification result is recorded as failing. The client reads the extended key purpose field of the server's leaf certificate and verifies whether the extended key purpose field includes server authentication purpose; the client reads the subject alternate name field of the server's leaf certificate and verifies whether the domain name identifier or IP address identifier in the subject alternate name field is based on the type of server address. When the digital signature relationship, certificate validity period, certificate purpose and server identity information are all verified, the client continues to exchange TLS key negotiation parameters and verifies the handshake completion message returned by the server; when the certificate chain verification or handshake completion message verification fails, the client writes the TLS handshake status as handshake failure, releases the current TLS resources and closes the TCP connection.

[0036] It should be noted that after the server certificate chain verification and handshake completion message verification are both passed, the client writes the TLS handshake status as "handshake passed", extracts the DER encoded data of the server leaf certificate, performs SHA-256 digest operation on the DER encoded data to obtain the server certificate fingerprint, and writes the server certificate fingerprint into the communication status table.

[0037] S1.5: After the TLS handshake is completed, the server generates a session ticket based on the TLS protocol version, cipher suite, key recovery information and session validity period obtained in this TLS handshake negotiation, and sends the session ticket to the client through the established TLS encrypted link.

[0038] It should be noted that the session ticket is ticket data generated and encrypted by the server based on the parameters of this TLS session. The client saves the session ticket as unparseable ticket data and does not decrypt or modify the key recovery information in the session ticket.

[0039] In this embodiment of the application, if TLS 1.2 is used, the server sends a session ticket during the TLS handshake process; if TLS 1.3 is used, the server sends a session ticket through a post-handshake message after the TLS handshake is completed.

[0040] After receiving the session ticket, the client binds the session ticket with the session identifier, server address, server port, server certificate fingerprint, and session ticket validity period, and saves the session ticket in the protected memory area corresponding to the KVM communication session.

[0041] The session ticket storage status includes: Not Received, indicating that the client has not yet received the session ticket sent by the server; Stored, indicating that the client has received the session ticket and has established a binding relationship between the session ticket and the session identifier and the server certificate fingerprint; Submitted, indicating that the client has submitted the session ticket to the server in the subsequent TCP reconnection process; Expired, indicating that the session ticket has expired, been rejected by the server, or the corresponding binding information is inconsistent.

[0042] After the client receives and completes the binding and storage of the session ticket, it changes the session ticket storage status in the communication status table from "not received" to "stored".

[0043] The method for establishing a TLS encrypted link is as follows: The client creates a TLS session instance corresponding to the TLS encryption context and binds the TLS session instance to the TCP connection corresponding to the socket identifier; The client and the server complete TLS protocol version negotiation, cipher suite negotiation, server certificate chain verification, key parameter exchange, and handshake to complete message verification, and encrypt and verify the data transmitted between the client and the server based on the negotiated communication key.

[0044] When the TLS handshake status is successful and the TLS session instance is able to send and receive encrypted messages over the TCP connection, the TCP connection and the TLS session instance are recorded together as a TLS encrypted link.

[0045] S1.6: The client creates a heartbeat detection thread based on the TLS encrypted link and configures the heartbeat period, heartbeat message format, heartbeat sequence number, heartbeat sending permission flag and thread exit flag for the heartbeat detection thread.

[0046] In an optional embodiment, the heartbeat detection thread includes a thread identifier, a session identifier, a heartbeat period, a heartbeat sequence number, a heartbeat sending permission flag, a sending buffer, a receiving buffer, a thread exit flag, and a state table mutex lock. The thread identifier is used to identify the current heartbeat detection thread, the session identifier is used to determine the KVM communication session to which the current heartbeat detection thread belongs, the heartbeat sequence number increments according to the number of heartbeat request messages sent, the heartbeat sending permission flag includes allow sending and prohibit sending, and the state table mutex lock performs mutual exclusion control on the writing process of the communication state table.

[0047] In this embodiment, the heartbeat period is 5 seconds, the heartbeat message adopts a binary message format, and the heartbeat message includes at least a message header, protocol version, message type, message length, session identifier, heartbeat sequence number, sending timestamp, and verification field; wherein, the message type includes heartbeat request type and heartbeat response type, and the heartbeat response message returned by the server carries the same session identifier and heartbeat sequence number as the corresponding heartbeat request message.

[0048] Preferably, the session identifier in the heartbeat message occupies 16 bytes, the heartbeat sequence number occupies 4 bytes, and the sending timestamp occupies 8 bytes. The sending timestamp uses millisecond-level system time. The verification field is used to verify the integrity of the fields in the heartbeat message.

[0049] After the client creates a heartbeat detection thread, it first sets the heartbeat thread status to "waiting" and sets the heartbeat sending permission flag to "disable sending" to avoid sending heartbeat messages before obtaining a link connection signal.

[0050] It should be noted that the client writes the current system time when the TLS encrypted link is established into the heartbeat timestamp in the communication status table, which serves as the initial time base for subsequent heartbeat timeout judgment; when the client subsequently receives a heartbeat response message that matches the session identifier and heartbeat sequence number, it updates the heartbeat timestamp to the reception time of the heartbeat response message.

[0051] S1.7: The client performs a route lookup based on the server address to determine the target network interface carrying the TCP connection, registers the link connectivity interface corresponding to the target network interface with the operating system, and reads the connectivity and disconnection events of the target network interface through the link connectivity interface to obtain the link connectivity signal.

[0052] In this embodiment of the application, the connectivity event is: the operating state of the target network interface changes from non-running state to running state and the medium connection state of the target network interface is medium connected; after receiving the connectivity event, the client writes the link connection signal in the communication status table as connected.

[0053] The disconnection event is defined as follows: the operating state of the target network interface changes from running to non-running, or the media connection state of the target network interface changes from media connection to media disconnection. After receiving the disconnection event, the client writes the link connection signal in the communication status table as disconnected.

[0054] Under the Windows operating system, the client registers the network interface status callback through the network interface change notification interface, and obtains the operation status and media connection status of the target network interface through the network interface information reading interface.

[0055] Specifically, the client can call NotifyIpInterfaceChange to register a network interface change notification callback, and call GetIfEntry2 to read the operation status and media connection status corresponding to the target network interface.

[0056] In an optional embodiment, under the Linux operating system, the client creates a netlink socket, listens for network interface link status change messages, and determines a connectivity event or disconnection event based on the network interface running flag in the link status change message.

[0057] It should be noted that the client only listens on the target network interface carrying the TCP connection to prevent changes in the state of other network interfaces from modifying the link connectivity signal in the communication state table. Once the link connectivity signal is written to the communication state table, it, along with the heartbeat timestamp, serves as the basis for subsequently distinguishing between a disconnected network cable and a disconnected device connection.

[0058] When the link connection signal is "connected", the client sets the heartbeat sending permission flag to "allow sending" and switches the heartbeat detection thread from the waiting state to the running state; when the link connection signal is "disconnected", the client keeps the heartbeat sending permission flag set to "disable sending".

[0059] S1.8: The client reads the connection status, TLS handshake status, heartbeat timestamp, and link connection / disconnection signal from the communication status table, and checks whether the above fields meet the normal connection conditions of the device.

[0060] When the connection status is TCP connected, the TLS handshake status is handshake successful, the heartbeat timestamp is non-zero, and the link connection signal is connected, the client will change the connection status in the communication status table from TCP connected to device normally connected, and keep the heartbeat detection thread running. When the TLS handshake status is handshake successful, but the link connection signal is disconnected, the client will not change the connection status to device normally connected, but will change the connection status to network cable disconnected.

[0061] It should be noted that the session ticket storage state is not a necessary condition for the device to be connected normally as the connection state is written; when the server has not yet issued a session ticket, the session ticket storage state remains as unreceived; when the server subsequently issues a session ticket, the client establishes a binding relationship between the session ticket, the session identifier, and the server certificate fingerprint in accordance with S1.5.

[0062] Preferably, the client saves the binding relationship between the server certificate fingerprint and the session ticket according to the session identifier, so as to perform consistency verification during TLS session recovery after subsequent TCP reconnection.

[0063] During subsequent TCP reconnection, the client reads the session ticket bound to the session identifier from the KVM communication session and verifies whether the server address, server port, server certificate fingerprint, and validity period corresponding to the session ticket are consistent with the information stored in the KVM communication session.

[0064] When the verification passes, the client submits the session ticket on a new TCP connection; when the verification fails, the session ticket expires, or the server rejects the session ticket, the client writes the session ticket storage state to expired and reloads the CA certificate to perform a full TLS handshake; the connection state in the communication state table is that the device is normally connected, and the TLS encrypted link enters the heartbeat monitoring phase.

[0065] S2: The heartbeat detection thread receives or sends heartbeat messages according to the heartbeat cycle and updates the heartbeat timestamp. The heartbeat timestamp and link connection / disconnection signal are written into the communication status table. The heartbeat message includes a heartbeat request message and a heartbeat response message.

[0066] S2.1: The heartbeat detection thread acquires the mutex lock of the state table, reads the session identifier, connection state, TLS handshake state, link connection / disconnection signal and heartbeat thread state from the communication state table, and reads the heartbeat sending permission flag and thread exit flag.

[0067] In this embodiment, when the connection status is normal device connection, the TLS handshake status is successful, the link connection signal is connected, the heartbeat thread status is running, the heartbeat sending permission flag is allowed to send and the thread exit flag is not set, the heartbeat detection thread enters the heartbeat message sending and receiving process; when any condition is not met, the heartbeat detection thread releases the state table mutex lock and remains in a waiting state.

[0068] It should be noted that after the heartbeat detection thread completes reading the above fields, it releases the mutex lock on the state table and does not continuously occupy the communication state table during the heartbeat message transmission and reception.

[0069] S2.2: The heartbeat detection thread generates heartbeat trigger events according to the heartbeat cycle, and when each heartbeat trigger event arrives, it reads the operation status and media connection status of the target network interface through the link connection interface to determine the link connection signal corresponding to the current heartbeat cycle.

[0070] In this embodiment of the application, when the target network interface is in the running state and the medium connection state is in the medium connection state, the link connection signal is determined to be connected; if the link connection signal is connected, the heartbeat detection thread increments the heartbeat sequence number by one, reads the current monotonic time value as the sending timestamp, and writes the message header, protocol version, heartbeat request type, message length, session identifier, incremented heartbeat sequence number and sending timestamp into the sending buffer according to the heartbeat message format, and calculates the application layer verification field based on the above fields to obtain the heartbeat request message.

[0071] When the target network interface is in a non-operating state or the medium connection state is medium disconnected, the link connection signal is determined to be disconnected; if the link connection signal is disconnected, the heartbeat timestamp in the communication status table remains unchanged.

[0072] The heartbeat detection thread acquires the mutex lock of the status table, writes the link connection / disconnection signal obtained in the current heartbeat cycle into the communication status table, and releases the mutex lock of the status table after writing is completed.

[0073] In this embodiment, the heartbeat period is 5 seconds; the session identifier is a 16-byte binary identifier, the heartbeat sequence number is a 4-byte unsigned integer, and the sending timestamp is an 8-byte unsigned integer. After the heartbeat sequence number reaches its maximum value, it restarts from the preset initial sequence number.

[0074] The heartbeat detection thread sends a heartbeat request message to the server via a TLS encrypted link. The heartbeat detection thread does not update the heartbeat timestamp until the heartbeat request message is fully written to the TLS encrypted link.

[0075] S2.3: The server receives heartbeat request messages through the TLS encrypted link, parses the message header, protocol version, message type, message length, session identifier, heartbeat sequence number, sending timestamp, and application layer verification fields in the heartbeat request message, and verifies the application layer verification fields.

[0076] When the message type is a heartbeat request type, the session identifier matches the current KVM communication session saved on the server, and the application layer verification field passes the check, the server writes the session identifier, heartbeat sequence number, and sending timestamp into the heartbeat response message, writes the message type into the heartbeat response type, and sends the heartbeat response message to the client through the TLS encrypted link.

[0077] In an optional embodiment, the client calculates the heartbeat round-trip time based on the sending timestamp carried in the heartbeat response message and the receiving time of the heartbeat response message; the heartbeat round-trip time is saved as a communication log parameter and does not replace the heartbeat timestamp in subsequent heartbeat timeout judgment.

[0078] S2.4: The heartbeat detection thread receives and verifies the heartbeat response message returned by the server to determine the valid heartbeat response message.

[0079] In this embodiment, after sending a heartbeat request message, the heartbeat detection thread listens to the TLS encrypted link within a preset heartbeat response waiting time and writes the decrypted message output by the TLS encrypted link into the receiving buffer; the heartbeat detection thread reads the message to be verified in the receiving buffer and checks the message header, protocol version, message type, message length and application layer verification field of the message to be verified in sequence.

[0080] When the message type of the message to be verified is a heartbeat response type, the process continues to check whether the session identifier in the message to be verified is consistent with the session identifier of the current KVM communication session, and whether the heartbeat sequence number in the message to be verified is consistent with the heartbeat sequence number in the heartbeat request message sent in the current heartbeat cycle. If the above verification results are consistent, the message to be verified is determined to be a valid heartbeat response message; otherwise, the message to be verified is discarded.

[0081] It should be noted that the preset heartbeat response waiting time is less than the heartbeat cycle; when the heartbeat cycle is 5 seconds, the preset heartbeat response waiting time is 2 seconds.

[0082] S2.5: When the heartbeat detection thread receives a valid heartbeat response message, it reads the current monotonic timer value corresponding to the valid heartbeat response message and uses it as the heartbeat timestamp to be written.

[0083] In this embodiment, before writing the heartbeat timestamp, the heartbeat detection thread reads the operation status and medium connection status of the target network interface again through the link connectivity interface to re-determine the link connectivity signal. When the re-determined link connectivity signal is connected, the heartbeat detection thread acquires the state table mutex lock. During the same holding of the state table mutex lock, it writes the current monotonic timer value into the heartbeat timestamp in the communication state table and writes the re-determined link connectivity signal into the communication state table, and then releases the state table mutex lock. When the re-determined link connectivity signal is disconnected, the heartbeat detection thread acquires the state table mutex lock, only writes the link connectivity signal into the communication state table, does not update the heartbeat timestamp, and releases the state table mutex lock after writing is completed.

[0084] By writing the heartbeat timestamp and link on / off signal during the same holding of the state table mutex, S3 avoids reading different combinations of state fields corresponding to different heartbeat cycles.

[0085] In this embodiment of the application, the following steps are taken to handle the situation where no valid heartbeat response message is received: When the preset heartbeat response waiting time expires and no valid heartbeat response message is received, the heartbeat detection thread keeps the heartbeat timestamp in the communication status table unchanged; the heartbeat detection thread reads the operation status and medium connection status of the target network interface again through the link connection interface, determines the link connection signal, acquires the status table mutex lock, writes the link connection signal into the communication status table, and then releases the status table mutex lock.

[0086] When the link connection signal is disconnected, S3 will write the connection status as disconnected based on the link connection signal; when the link connection signal is connected, S3 will determine whether the heartbeat timestamp has timed out and not been refreshed based on the time interval between the current monotonic time value and the heartbeat timestamp.

[0087] It should be noted that if no valid heartbeat response message is received within a single heartbeat cycle, the connection status will not be immediately written as disconnected to avoid misjudgment of the status due to single network jitter, short-term scheduling delay on the server side, or occasional loss of heartbeat response messages.

[0088] S2.6: After the heartbeat detection thread completes the communication state table write operation within the current heartbeat cycle and releases the state table mutex lock, it checks the thread exit flag.

[0089] In this embodiment, when the thread exit flag is not set, the heartbeat detection thread waits for the next heartbeat trigger event; when the thread exit flag is set, the heartbeat detection thread acquires the state table mutex lock, writes the heartbeat thread state as exit, releases the state table mutex lock, and terminates the current thread; after each heartbeat cycle, the communication state table retains at least the current link connection / disconnection signal and the heartbeat timestamp corresponding to the most recent valid heartbeat response message.

[0090] If the link connection signal is disconnected, the heartbeat timestamp remains unchanged; if the link connection signal is connected and a valid heartbeat response message is received, the heartbeat timestamp is updated to the current monotonic time value corresponding to the valid heartbeat response message; if the link connection signal is connected but no valid heartbeat response message is received, the heartbeat timestamp remains at its original value.

[0091] It should be noted that S3 subsequently acquires the state table mutex lock, reads the link connectivity signal and heartbeat timestamp corresponding to the same KVM communication session, and distinguishes between network cable disconnection and device connection disconnection by first judging the link connectivity signal and then judging whether the heartbeat timestamp has timed out.

[0092] S3: When the link connection signal is broken, mark the network cable as disconnected in the communication status table and stop sending heartbeat messages; when the link connection signal is connected and the heartbeat timestamp expires and is not refreshed, mark the device connection as disconnected in the communication status table, release the TCP connection and TLS resources, and retain the session ticket.

[0093] S3.1: Read the communication status field required for communication status determination.

[0094] In this embodiment of the application, the client acquires the state table mutex lock each time the communication state is determined, reads the link connection signal, heartbeat timestamp, connection state, TLS handshake state, socket identifier, heartbeat thread state and session ticket storage state in the communication state table according to the session identifier, and releases the state table mutex lock after reading is completed.

[0095] When the connection status is "device is connected normally", the client enters the current communication status determination; when the connection status is "network cable disconnected", "device connection disconnected", or "automatically recovering connection", the client does not modify the connection status again.

[0096] It should be noted that the link connection / disconnection signal and heartbeat timestamp are status fields written by S2 during the same holding of the state table mutex lock, in order to reduce the number of times the client reads the link connection / disconnection signal and heartbeat timestamp corresponding to different heartbeat periods.

[0097] S3.2: First determine whether the link connection signal is disconnected.

[0098] In this embodiment, the client first determines whether the link connection signal is disconnected; when the link connection signal is disconnected, the client acquires the state table mutex lock, changes the connection status in the communication state table from normal device connection to network cable disconnection, changes the heartbeat sending permission flag to prohibit sending, and changes the heartbeat thread status from running to paused, and then releases the state table mutex lock.

[0099] It should be noted that a disconnect signal indicates that the target network interface carrying the TCP connection is in a non-operational state, or that the media connection of the target network interface is disconnected. Disconnection of the network cable includes the network cable being unplugged, the network interface being disabled, the switch port being closed resulting in the loss of media connection, and the loss of media connection of the target network interface. The above situations are characterized by the disconnection event generated by the link connection interface for the target network interface.

[0100] S3.3: When the connection status is written as disconnected, the heartbeat detection thread will not generate a new heartbeat request message when it reads the heartbeat sending permission flag again, and will keep the heartbeat timestamp corresponding to the most recent valid heartbeat response message unchanged.

[0101] In this embodiment, after the heartbeat detection thread switches from the running state to the paused state, it retains the thread identifier, session identifier, heartbeat period, heartbeat sequence number, sending buffer, and receiving buffer, and does not terminate the current heartbeat detection thread.

[0102] It should be noted that during the period when the connection status is "network cable disconnected", the client does not change the connection status to "device connection disconnected" based on the time interval between the heartbeat timestamp and the current monotonic time value. This is to avoid repeatedly generating the "device connection disconnected" judgment for the same communication anomaly due to the inability to send and receive heartbeat messages after the physical link is disconnected.

[0103] In an optional embodiment, when the connection status is that the network cable is disconnected, the client reads the link connection signal according to a preset link query period; the preset link query period is longer than the heartbeat period, so as to reduce processor usage and invalid network operations during the physical link disconnection period.

[0104] S3.4: When the link connection signal is connected, the client reads the current monotonic timer value, calculates the difference between the current monotonic timer value and the heartbeat timestamp, and records the difference as the duration of the heartbeat not being refreshed.

[0105] In this embodiment of the application, the duration of the heartbeat not being refreshed is calculated according to the following formula: ; in, This indicates the duration the heartbeat hasn't been refreshed. Indicates the current monotonic time value. This represents the heartbeat timestamp recorded in the communication status table.

[0106] The client compares the heartbeat not refresh duration with the preset heartbeat timeout threshold. When the heartbeat not refresh duration is less than the preset heartbeat timeout threshold, the client maintains the connection state as a normal device connection and does not release the TCP connection and TLS resources. When the heartbeat not refresh duration reaches or exceeds the preset heartbeat timeout threshold, the client reads the operation status and media connection status of the target network interface again through the link connectivity interface to obtain the verification link connectivity signal.

[0107] It should be noted that the preset heartbeat timeout threshold is determined by multiplying the number of consecutive heartbeat cycles that are allowed to fail to receive a valid heartbeat response message by the number of heartbeat cycles. The calculation formula is as follows: ; in, This indicates the preset heartbeat timeout threshold. This indicates the number of consecutive heartbeat cycles during which a valid heartbeat response message can not be received. It indicates the heartbeat cycle.

[0108] It should be noted that the heartbeat cycle is 5 seconds, and the number of consecutive heartbeat cycles in which no valid heartbeat response message is received is 2. The preset heartbeat timeout threshold is 10 seconds. If the preset heartbeat timeout threshold is greater than one heartbeat cycle, the delay or loss of a single heartbeat response will not directly trigger the device connection disconnection judgment.

[0109] When the verification link connectivity signal is "disconnected," the client acquires the state table mutex, changes the connection status in the communication state table from "normal device connection" to "network cable disconnected," sets the heartbeat sending permission flag to "prohibited," and changes the heartbeat thread status from "running" to "paused," then releases the state table mutex. The heartbeat detection thread will not generate a new heartbeat request message the next time it reads the heartbeat sending permission flag, and will keep the heartbeat timestamp unchanged. When the verification link connectivity signal is "connected," the client determines this communication anomaly as a heartbeat timeout anomaly under the condition of physical link connectivity.

[0110] Heartbeat timeout anomalies under physical link connectivity conditions include server communication process stopping response, server abnormal offline, TLS encrypted link silent failure, TCP connection in a half-open state, and intermediate network devices continuously discarding communication packets.

[0111] S3.5: When the verification link connection signal is connected and the heartbeat timeout period reaches or exceeds the preset heartbeat timeout threshold, the client acquires the state table mutex lock and reads the link connection signal and heartbeat timestamp from the communication state table again.

[0112] In this embodiment, when the link connection signal is read again as disconnected, the client releases the state table mutex and processes according to S3.2; when the link connection signal is read again as connected, but the heartbeat timestamp read again is inconsistent with the heartbeat timestamp read in S3.1, it indicates that the heartbeat detection thread has received a new valid heartbeat response message, the client maintains the connection state as normal device connection, and releases the state table mutex; when the link connection signal is read again as connected, and the heartbeat timestamp read again is consistent with the heartbeat timestamp read in S3.1, the client reads the current monotonic timer value as the device connection disconnection start time, changes the connection state from normal device connection to device connection disconnection, writes the device connection disconnection start time into the communication state table, writes the heartbeat sending permission flag to prohibit sending, and changes the heartbeat thread state from running to paused, and then releases the state table mutex.

[0113] It should be noted that the communication status table also includes a device connection disconnection start time field, the initial value of which is empty; the client writes the device connection disconnection start time when the connection status is first written as device connection disconnected, and does not update the device connection disconnection start time repeatedly while the connection status remains device connection disconnected.

[0114] The device connection disconnection start time is used as the time base for S4 to calculate the duration of the device connection disconnection; when the duration reaches the preset period, S4 triggers TCP reconnection.

[0115] S3.6: Release the current TCP connection and TLS resources.

[0116] In this embodiment of the application, after the connection state is written as the device connection is disconnected, the client stops performing heartbeat message reading and writing through the current TLS encrypted link, releases the binding relationship between the TLS session instance and the TCP connection corresponding to the socket identifier, releases the TLS session instance, the current TLS session negotiation key, the encrypted send buffer resource and the encrypted receive buffer resource corresponding to the current connection, and closes the socket corresponding to the socket identifier.

[0117] After the client completes socket closure, it acquires the state table mutex, writes the socket identifier to an empty value, writes the TLS handshake status from "handshake passed" to "handshake not passed", records the release results of the TCP connection and TLS resources, and then releases the state table mutex.

[0118] It should be noted that TLS resources refer to the TLS session instance bound to the current TCP connection, the current TLS session negotiation key, and the encrypted read / write buffer resources corresponding to the current TLS session, excluding pre-configured CA certificates, TLS protocol version ranges, certificate verification rules, server certificate fingerprints, and session tickets.

[0119] Preferably, when the TLS resource release interface or socket close interface returns an error message, the client records the error message and continues to process the remaining communication resources, while maintaining the connection state as disconnected and not restoring the connection state to normal connection due to the failure of a single communication resource release.

[0120] S3.7: When the client releases the TCP connection and TLS resources, it retains the session ticket and the binding relationship between the session ticket and the session identifier, server address, server port, server certificate fingerprint and session ticket validity period, and does not clear the protected memory area corresponding to the KVM communication session.

[0121] In this embodiment, when the session ticket storage status is "stored", the client maintains the session ticket storage status as "stored"; when the session ticket storage status is "not received", the client maintains the session ticket storage status as "not received" and does not generate a replacement session ticket.

[0122] It should be noted that the key recovery information encapsulated in the session ticket is encrypted and protected by the server. The client only saves the session ticket and does not read or modify the key recovery information. The validity period of the session ticket is checked when a TCP reconnection is triggered by S4. When the session ticket expires, the client writes the session ticket's stored state as expired and performs a full TLS handshake on the newly established TCP connection.

[0123] After completing the above processing, when the connection status is that the network cable is disconnected, S4 will trigger TCP reconnection when the link connection signal is restored to connection; when the connection status is that the device connection is disconnected, S4 will trigger TCP reconnection when the duration between the current monotonic timer value and the device connection disconnection start time reaches a preset period.

[0124] S4: When the link connection signal is restored or the duration of the device connection being disconnected is greater than or equal to the preset period, TCP reconnection is triggered. After the new TCP connection is established, the session ticket is submitted to complete the TLS session recovery without repeating the certificate chain verification.

[0125] S4.1: Read the communication status field required for TCP reconnection trigger determination.

[0126] In this embodiment, the client acquires the state table mutex lock, reads the link connection / disconnection signal, connection status, device connection / disconnection start time, server address, server port, socket identifier, TLS handshake status, server certificate fingerprint, session ticket, session ticket storage status, and heartbeat thread status from the communication state table according to the session identifier, and releases the state table mutex lock after reading.

[0127] It should be noted that the communication status table also includes the TLS session recovery status, which includes not recovered, recovering, recovery completed, and recovery failed; when a KVM communication session is created, the TLS session recovery status is initialized to not recovered.

[0128] When the connection status is that the network cable is disconnected or the device connection is lost, the client initiates a TCP reconnection trigger decision; when the connection status is that the connection is automatically recovering or the device is normally connected, the client does not initiate a new TCP reconnection.

[0129] S4.2: Determine the first TCP reconnection trigger condition based on the link connection restoration event of the link disconnection signal.

[0130] In this embodiment, the method for determining the first TCP reconnection trigger condition is as follows: During the period when the connection state is that the network cable is disconnected, the client keeps the link connection interface in the registered state and receives the network interface status change notification generated by the target network interface; when the operation state of the target network interface changes from non-running state to running state and the medium connection state of the target network interface changes from medium disconnected to medium connected, the client writes the link connection signal from disconnected to connected; the client acquires the state table mutex lock and reads the connection state and link connection signal in the communication state table again; when the connection state read again is that the network cable is disconnected and the link connection signal is connected, the client determines the current state combination as the first TCP reconnection trigger condition and releases the state table mutex lock after completing the determination; otherwise, it continues to wait for the target network interface to generate a new network interface status change notification.

[0131] It should be noted that the first TCP reconnection trigger condition is triggered by the recovery connectivity event generated by the target network interface carrying the original TCP connection, and is not based on whether the heartbeat timestamp is refreshed, in order to reduce the reconnection delay caused by waiting for the preset heartbeat timeout threshold after the network cable is restored.

[0132] In an optional embodiment, after receiving the connection restoration event, the client performs a routing query again based on the server address; if the network interface obtained by the routing query is consistent with the target network interface, the target network interface is retained; otherwise, the network interface obtained by the routing query is updated to the new target network interface, and the link connection / disconnection interface corresponding to the new target network interface is registered with the operating system.

[0133] S4.3: Determine the second TCP reconnection trigger condition based on the duration of the device connection disconnection.

[0134] In this embodiment, the method for determining the second TCP reconnection trigger condition is as follows: When the connection status is device connection disconnection, the client reads the current monotonic timer value and calculates the difference between the current monotonic timer value and the device connection disconnection start time, recording the difference as the duration of device connection disconnection; the client compares the duration of device connection disconnection with a preset period; if the duration of device connection disconnection is less than the preset period, the client maintains the connection status as device connection disconnection; if the duration of device connection disconnection is greater than or equal to the preset period, the client reads the operation status and medium connection status of the target network interface again through the link connectivity interface to obtain the link connectivity status before reconnection. If the link connection signal is connected before reconnection, the client acquires the state table mutex lock and rechecks the connection status, device connection disconnection start time, and link connection signal. If the connection status is still device connection disconnection, the device connection disconnection start time has not been modified, and the link connection signal is connected, the current state combination is determined as the second TCP reconnection trigger condition, and the state table mutex lock is released. If the link connection signal is disconnected before reconnection, the client acquires the state table mutex lock, writes the link connection signal as disconnected, writes the connection status from device connection disconnection to network cable disconnection, keeps the heartbeat sending permission flag set to prohibited sending, and keeps the heartbeat thread status in paused, and releases the state table mutex lock.

[0135] It should be noted that the second TCP reconnection trigger condition applies to situations where the target network interface remains connected, but the server-side communication process, TCP connection, or TLS encrypted link experiences an anomaly; if the target network interface has already been disconnected, invalid TCP connection requests will not be repeatedly initiated.

[0136] Preferably, the preset period is 5 to 30 seconds, and the duration of the device connection disconnection is calculated using the current monotonic timing value to reduce the impact of system time calibration or system time rollback on the triggering conditions of the second TCP reconnection.

[0137] S4.4: Write the connection status to the automatic recovery connection and clean up the failed communication resources before reconnection.

[0138] In this embodiment, when the first TCP reconnection trigger condition or the second TCP reconnection trigger condition is met, the client acquires the state table mutex lock and checks the connection status again. When the connection status is still "network cable disconnected" or "device disconnected", the client writes the connection status to "automatically recover connection", writes the TLS session recovery status to "not recovered", keeps the heartbeat sending permission flag to "prohibited", and keeps the heartbeat thread status to "paused", and then releases the state table mutex lock.

[0139] By writing the connection state into the auto-recovery connection before creating a new socket, the link connectivity interface, heartbeat detection thread, and other communication status determination threads will no longer repeatedly initiate TCP reconnection for the same KVM communication session after reading the auto-recovery connection.

[0140] When the socket identifier is not null or the original TLS session instance has not been released, the client stops reading and writing messages on the original TLS encrypted link, releases the binding relationship between the original TLS session instance and the original TCP connection corresponding to the socket identifier, releases the original TLS session instance, the original TLS session negotiation key and the encrypted read and write buffer resources corresponding to the original TLS session, and closes the original socket corresponding to the socket identifier.

[0141] After the client completes the cleanup of invalid communication resources, it writes the socket identifier to an empty value, writes the TLS handshake status to "no handshake", and does not delete the CA certificate, server certificate fingerprint, session ticket and their binding relationships.

[0142] S4.5: Verify the binding relationship and validity period of the session tickets, and determine the TLS reconnection method, specifically: The client reads the session ticket from the protected memory area corresponding to the KVM communication session and verifies whether the session ticket storage status is "stored". When the session ticket storage status is "stored", the client reads the session identifier, server address, server port, server certificate fingerprint and session ticket validity period that are bound to the session ticket, and checks them against the session identifier, server address, server port, server certificate fingerprint and current monotonic timer value stored in the current KVM communication session. If the session identifier bound to the session ticket matches the current session identifier, the server address bound to the session ticket matches the current server address, the server port bound to the session ticket matches the current server port, and the server certificate fingerprint bound to the session ticket matches the currently saved server certificate fingerprint, and the session ticket has not exceeded its validity period, then the client records the session ticket as a pending session ticket and determines the TLS reconnection method as the session recovery method; if any binding information is inconsistent, the session ticket has exceeded its validity period, or the session ticket storage status is not "stored", then the client does not generate a pending session ticket and determines the TLS reconnection method as the full handshake method. If the session ticket expires or any binding information is inconsistent, the client acquires the state table mutex, writes the session ticket storage state as expired, keeps the TLS session recovery state as unrecovered, and releases the state table mutex.

[0143] Preferably, when the session ticket expires or any binding information is inconsistent, the client acquires the state table mutex, writes the session ticket storage state as expired, keeps the TLS session recovery state as unrecovered, and then releases the state table mutex.

[0144] It should be noted that the server certificate fingerprint is checked against the server certificate fingerprint saved after the first complete TLS handshake and the server certificate fingerprint bound to the session ticket. The verification process is used to restrict the session ticket to be submitted only to the server corresponding to the original TLS session, and does not replace the verification of the server certificate chain under the complete handshake method.

[0145] In an optional embodiment, when the server address or server port configured by the client is modified during the network cable disconnection, the TLS reconnection method will be determined as a full handshake method even if the session ticket is still within the validity period of the session ticket.

[0146] S4.6: Create a new socket and establish a new TCP connection, specifically as follows: The client creates a new socket based on the server address and server port; if the server address is a domain name, the client re-resolves the server address to obtain the current IP address corresponding to the server address, and generates a new server socket address based on the current IP address and server port; if the server address is an IP address, the client directly generates a new server socket address based on the server address and server port. Configure the connection timeout and read / write timeout for the new socket, and initiate a TCP connection request to the new server socket address through the new socket. Wait for the server to return a TCP handshake response within the preset connection time. When the client receives a TCP handshake response within the preset connection time, the client acquires the state table mutex lock, writes the new socket handle corresponding to the new socket into the socket identifier in the communication state table, keeps the connection state as "automatically recovering connection", and releases the state table mutex lock. The routing information corresponding to the new TCP connection is used to verify whether the network interface carrying the new TCP connection is the target network interface. If the network interface carrying the new TCP connection has changed, the link connectivity interface corresponding to the original target network interface is deregistered, the network interface carrying the new TCP connection is updated to the target network interface, and the link connectivity interface corresponding to the target network interface is re-registered. If a new TCP connection is not established within the preset connection time, or if the new socket returns a connection rejection, connection timeout, or network unreachable error during the establishment of a new TCP connection, the new socket is closed, the state table mutex is acquired, the socket identifier is kept null, the TLS handshake state is kept as not handshake, the TLS session recovery state is written as recovery failed, the connection state is changed from automatic connection recovery to device connection disconnected, the current monotonic timer value is rewritten as the device connection disconnection start time, and the state table mutex is released.

[0147] It should be noted that the successful establishment of a new TCP connection only indicates that the Transmission Control Protocol (TCP) connection between the client and the server has been re-established. Until the TLS session recovery state is written as "recovery complete" and a valid heartbeat response message has been received, the connection state remains "automatically recovering connection," indicating a normal device connection.

[0148] S4.7: Submit the session ticket on the new TCP connection and perform TLS session recovery, specifically as follows: If the TLS reconnection method is session recovery, a new TLS session instance corresponding to the TLS encryption context is created, the new TLS session instance is bound to the new TCP connection corresponding to the socket identifier, the state table mutex is acquired, the TLS handshake state is written to the handshake state, the TLS session recovery state is written to the recovery state, and then the state table mutex is released. Set the session ticket to be submitted as the session recovery credential for the new TLS session instance, and send a TLS handshake request carrying the session ticket to be submitted to the server through a new TCP connection; after the session ticket to be submitted is sent, change the session ticket storage state from stored to submitted. In an embodiment employing TLS 1.2, the client carries the session ticket to be submitted in the session ticket extension field of the client handshake message; after receiving the session ticket to be submitted, the server decrypts the session ticket to be submitted using the ticket protection key stored on the server, verifies the integrity, validity period and corresponding original TLS session parameters of the session ticket to be submitted, and returns abbreviated TLS handshake message to the client after the verification is successful. In an embodiment using TLS 1.3, the client reads the pre-shared key identifier associated with the original TLS session based on the session ticket to be submitted, and carries the pre-shared key identifier and the corresponding binding verification value in the client handshake message; the server verifies the pre-shared key identifier and the binding verification value, and selects the original TLS session parameters corresponding to the pre-shared key identifier to continue the handshake after the verification is successful.

[0149] When the server receives the session ticket to be submitted, the client and server do not transmit the server certificate chain again, and do not repeat the verification of digital signature relationship, certificate validity period, certificate purpose and server identity information in the first complete TLS handshake; the client continues to check the integrity of the handshake message returned by the server, and verify the handshake completion message returned by the server. When the handshake is completed and the message verification is successful, the client derives a new communication key based on the key recovery information corresponding to the session ticket to be submitted and the random parameters exchanged in this TLS handshake, and configures the new communication key to the new TLS session instance.

[0150] It should be noted that skipping certificate chain verification means that after the server receives the session ticket to be submitted, it does not repeatedly transmit and verify the server certificate chain, does not omit the verification of the integrity, validity period and binding relationship of the session ticket to be submitted, and does not omit the integrity verification of the handshake message and the verification of the handshake completion message.

[0151] When the TLS reconnection method is a full handshake, the client does not submit a session ticket, loads the CA certificate on the new TCP connection, and performs a full TLS handshake according to the TLS protocol version range, certificate verification rules, and maximum certificate chain verification depth. After the full TLS handshake is successful, the client re-obtains the server's certificate fingerprint and receives a new session ticket issued by the server.

[0152] S4.8: Process the TLS session recovery result and update the communication state table.

[0153] In this embodiment of the application, when the session ticket to be submitted is received by the server and the client passes the handshake completion message verification, the client writes the TLS handshake status from "handshake passed" to "handshake passed", writes the TLS session recovery status from "recovery passed" to "recovery completed", and records the new TCP connection and the new TLS session instance together as the reconstructed TLS encrypted link.

[0154] The client keeps the connection state set to "automatically resuming connection," keeps the heartbeat sending permission flag set to "prohibited," and keeps the heartbeat thread state set to "paused." Instead of writing "resuming complete" to the TLS session recovery state, the client directly writes the connection state to "device is normally connected."

[0155] When the session ticket to be submitted is rejected by the server, the session ticket cannot be decrypted, or the handshake completion message verification fails, the client writes the session ticket storage state as expired, writes the TLS session recovery state as recovery failed, and releases the new TLS session instance created during this session recovery process.

[0156] The client then reloads the CA certificate on the newly established TCP connection and performs a full TLS handshake according to the TLS protocol version range, certificate verification rules, and maximum certificate chain verification depth. After the full TLS handshake is successful, the client updates the server certificate fingerprint and receives the session ticket reissued by the server.

[0157] When the TLS session is successfully restored or the complete TLS handshake is successful, the connection state remains in "automatic connection recovery" and enters the subsequent heartbeat recovery confirmation phase. Subsequently, the client sends a recovery confirmation heartbeat request message through the rebuilt TLS encrypted link. After receiving a heartbeat response message that matches the session identifier and heartbeat sequence number, the connection state is written as "device is normally connected" and the heartbeat detection thread is restarted.

[0158] S5: After the TLS session is restored, receive the heartbeat response message, mark the device as normally connected in the communication status table, and restart the heartbeat detection thread.

[0159] S5.1: Read the communication status fields required for link recovery confirmation.

[0160] In this embodiment, the client acquires the state table mutex lock, reads the connection state, TLS handshake state, TLS session recovery state, socket identifier, link connection / disconnection signal, heartbeat timestamp, heartbeat thread state, session ticket storage state, and server certificate fingerprint from the communication state table according to the session identifier, and reads the heartbeat sequence number and heartbeat sending permission flag, and then releases the state table mutex lock.

[0161] When the connection status is "Automatic connection recovery in progress", the socket identifier is not empty, the TLS handshake status is "handshake passed", and the TLS session recovery status is "recovery complete", the client enters the recovery confirmation process based on the rebuilt TLS encrypted link.

[0162] When the session ticket expires and a full TLS handshake is initiated and successfully completed, the client also enters the recovery confirmation process. At this time, the client performs subsequent processing based on the TLS encrypted link re-established after the full TLS handshake, without considering the TLS session recovery status as a necessary condition for recovery completion.

[0163] It should be noted that during the recovery confirmation process, the heartbeat sending permission flag remains in the "prohibited" state, the heartbeat thread remains in the "paused" state, and the heartbeat detection thread does not send new heartbeat request messages according to the heartbeat cycle.

[0164] S5.2: Review the target network interface of the reconstructed TLS encrypted link, specifically: The client reads the operation status and media connection status of the target network interface through the link connectivity interface to determine the link connectivity signal before recovery confirmation. When the target network interface is in the running state and the target network interface is in the medium connection state, the link connection signal before recovery confirmation is determined to be connected, and the recovery confirmation heartbeat message sending process begins; otherwise, the link connection signal before recovery confirmation is determined to be disconnected; the client acquires the state table mutex lock, writes the link connection signal to disconnected, writes the connection status from automatic connection recovery to network cable disconnected, keeps the heartbeat sending permission flag set to prohibited and the heartbeat thread status set to paused, and then releases the state table mutex lock; After the connection status is written, no recovery confirmation heartbeat request message is sent. The TLS session instance and socket corresponding to the rebuilt TLS encrypted link are released, while the session identifier, server certificate fingerprint and unexpired session ticket are retained. The connection is then restored by waiting for the link connection signal to be restored.

[0165] It should be noted that reading the target network interface again before sending the recovery confirmation heartbeat request message can reduce invalid heartbeat sending caused by the target network interface being disconnected again after S4 completes the TLS session recovery.

[0166] S5.3: Send a recovery confirmation heartbeat request message through the reconstructed TLS encrypted link.

[0167] In this embodiment of the application, when the link connection signal before the recovery confirmation is connected, the client increments the heartbeat sequence number by one, reads the current monotonic time value as the recovery confirmation sending timestamp, and writes the message header, protocol version, heartbeat request type, message length, session identifier, incremented heartbeat sequence number and recovery confirmation sending timestamp into the sending buffer according to the heartbeat message format configured in S1.6. The application layer verification field is calculated based on the above fields to generate a recovery confirmation heartbeat request message.

[0168] The client sends a recovery confirmation heartbeat request message through the reconstructed TLS encrypted link and records the session identifier and heartbeat sequence number used in this transmission.

[0169] It should be noted that the recovery confirmation heartbeat request message is sent by the client control thread that executes the automatic connection recovery process, and not by the heartbeat detection thread that is in a paused state; the heartbeat detection thread remains in a paused state until a valid heartbeat response message is received.

[0170] If the recovery confirmation heartbeat request message is not fully written to the rebuilt TLS encrypted link, or if the rebuilt TLS encrypted link returns a read / write error, the client will not update the heartbeat timestamp and will record the recovery confirmation result as failed.

[0171] S5.4: Receive, verify, and recover the heartbeat response message corresponding to the heartbeat request message.

[0172] In this embodiment of the application, after sending a recovery confirmation heartbeat request message, the client listens to the reconstructed TLS encrypted link within a preset recovery confirmation waiting time and writes the decrypted message output by the reconstructed TLS encrypted link into the receiving buffer.

[0173] The client sequentially checks the message header, protocol version, message type, message length, and application layer verification field in the decryption message. When the message type is a heartbeat response type, it continues to check whether the session identifier in the decryption message is consistent with the session identifier of the current KVM communication session, and checks whether the heartbeat sequence number in the decryption message is consistent with the heartbeat sequence number in the recovery confirmation heartbeat request message.

[0174] When the message header, protocol version, message type, message length, application layer verification field, session identifier, and heartbeat sequence number all pass the verification, the decrypted message is determined to be a valid heartbeat response message; if any verification result is inconsistent, the client discards the decrypted message.

[0175] Preferably, the preset recovery confirmation waiting time is less than the heartbeat cycle; when the heartbeat cycle is 5 seconds, the preset recovery confirmation waiting time can be set to 2 seconds.

[0176] S5.5: Synchronously update the heartbeat timestamp and link connectivity signal based on valid heartbeat response messages.

[0177] In this embodiment of the application, when the client receives a valid heartbeat response message within a preset recovery confirmation waiting time, it reads the current monotonic time value corresponding to the valid heartbeat response message as the heartbeat timestamp after recovery.

[0178] Before writing the recovery heartbeat timestamp, the client reads the operation status and media connection status of the target network interface again through the link connectivity interface to obtain the link connectivity signal after recovery confirmation.

[0179] When the link connection signal after recovery confirmation is connected, the client acquires the state table mutex lock. During the same holding of the state table mutex lock, the heartbeat timestamp after recovery is written into the heartbeat timestamp in the communication state table, and the link connection signal after recovery confirmation is written into the link connection signal in the communication state table. Then the state table mutex lock is released.

[0180] When the link connection signal is confirmed to be disconnected after recovery, the client acquires the state table mutex lock, only writes the link connection signal as disconnected, does not update the heartbeat timestamp, and writes the connection status from the automatic connection recovery to "network cable disconnected", and then releases the state table mutex lock.

[0181] By writing the heartbeat timestamp and link connectivity signal during the same holding of the state table mutex lock, subsequent communication status determinations can read the same combination of status fields corresponding to the recovery confirmation process.

[0182] S5.6: Change the connection status from automatic connection recovery to normal device connection.

[0183] In this embodiment of the application, when the link connection signal is connected after the recovery confirmation and the client receives a valid heartbeat response message, the client acquires the state table mutex lock and re-verifies the connection status, TLS handshake status, TLS session recovery status, link connection signal and heartbeat timestamp.

[0184] When the connection status is still in automatic connection recovery, the TLS handshake status is handshake passed, the TLS session recovery status is recovery completed, the link connection signal is connected and the heartbeat timestamp is equal to the heartbeat timestamp after recovery, the connection status will be changed from automatic connection recovery to normal device connection, and the device connection disconnection start time will be changed to null.

[0185] When the current TLS encrypted link is established by a complete TLS handshake, after verifying that the TLS handshake status is successful, the connection status is written to "normal connection" in the automatic connection recovery, and the TLS session recovery status is not required to be "recovery complete".

[0186] It should be noted that the client writes the connection status as a normal connection only after receiving a valid heartbeat response message. It does not use the establishment of a new TCP connection or the completion of TLS session recovery as a separate criterion for determining a normal connection, thus distinguishing between transport layer connection recovery and heartbeat message transmission and reception recovery.

[0187] S5.7: Restart the heartbeat detection thread.

[0188] In this embodiment of the application, after the connection status is written as a normal device connection, the client restores the heartbeat detection thread according to the thread identifier, session identifier, heartbeat cycle, heartbeat sequence number, sending buffer, receiving buffer and thread exit flag saved in S1.6.

[0189] When the heartbeat thread is in a paused state, the client acquires the state table mutex, changes the heartbeat sending permission flag from "disallowed" to "allowed", changes the heartbeat thread state from "paused" to "running", then releases the state table mutex and wakes up the heartbeat detection thread, causing the heartbeat detection thread to wait for the next heartbeat trigger event.

[0190] When the heartbeat thread is in the exit state or the thread resources corresponding to the heartbeat detection thread have been released, the client recreates the heartbeat detection thread according to S1.6, associates the newly created heartbeat detection thread with the session identifier, writes the heartbeat sending permission flag as allowed to send, and writes the heartbeat thread state as running.

[0191] The restarted heartbeat detection thread uses the S2 heartbeat message format and heartbeat cycle, and continues to increment the heartbeat sequence number corresponding to the recovery confirmation heartbeat request message, without rewriting the heartbeat sequence number to the initial value.

[0192] S5.8: Handle recovery confirmation failure cases where a valid heartbeat response message has not been received.

[0193] In this embodiment of the application, when the preset recovery confirmation waiting time expires and the client does not receive a valid heartbeat response message, the heartbeat timestamp remains unchanged, and the operation status and media connection status of the target network interface are read again through the link connection interface.

[0194] When the link connection signal is read again and found to be disconnected, the connection status is changed from automatic connection recovery to "network cable disconnected", the heartbeat sending permission flag is kept as "disabled", the heartbeat thread status is kept as "paused", and the TLS session instance and socket corresponding to the rebuilt TLS encrypted link are released.

[0195] When the link connection signal is read again and found to be connected, the connection status is changed from automatic connection recovery to device connection disconnection. The current monotonic timer value is read and written as the new device connection disconnection start time. The heartbeat sending permission flag is kept in the "prohibited" state, and the heartbeat thread status is kept in the "paused" state.

[0196] The client releases the TLS session instance, communication key, encrypted send buffer resources, encrypted receive buffer resources, and socket corresponding to the reconstructed TLS encrypted link; when the session ticket storage state is submitted and the server does not issue a new session ticket, the session ticket storage state is written to expire, so that the next TCP reconnection uses the full handshake method.

[0197] After completing the above processing, when the connection status is "network cable disconnected", the client waits for the link connection signal to be restored to "connected"; when the connection status is "device connection disconnected", the client re-enters the S4TCP reconnection trigger determination process according to the new device connection disconnection start time and preset period.

[0198] Under the teachings of the above embodiments, such as Figure 2 As shown in the embodiments of the present invention, other aspects also disclose a KVM communication link monitoring and breakpoint self-healing reconnection system based on TCP / TLS encryption, comprising: The link establishment initialization module is used to establish a TCP connection, load the CA certificate, complete the TLS handshake, send the session ticket from the server to the client, start the heartbeat detection thread, and register the link connectivity interface to obtain the link connectivity signal. The heartbeat status update module is used by the heartbeat detection thread to receive or send heartbeat messages according to the heartbeat cycle and update the heartbeat timestamp. The heartbeat timestamp and the link connection / disconnection signal are written into the communication status table. The heartbeat message includes a heartbeat request message and a heartbeat response message. The abnormal state determination module is used to mark the network cable as disconnected in the communication status table and stop sending heartbeat messages when the link connection signal is disconnected; when the link connection signal is connected and the heartbeat timestamp has expired and not been refreshed, it marks the device connection as disconnected in the communication status table, releases the TCP connection and TLS resources, and retains the session ticket. The session recovery and reconnection module is used to trigger TCP reconnection when the link connection signal is restored or the duration of the device connection being disconnected is greater than or equal to a preset period. After the new TCP connection is established, the session ticket is submitted to complete the TLS session recovery without repeating the certificate chain verification. The connection confirmation restart module is used to receive heartbeat response messages after the TLS session is restored, mark the device as normally connected in the communication status table, and restart the heartbeat detection thread.

[0199] In summary, this invention establishes a TCP connection, loads a CA certificate to complete a TLS handshake, and receives a session ticket bound to a session identifier, server address, server port, and server certificate fingerprint. This constructs an identity-verified KVM encrypted communication link and retains session credentials for subsequent breakpoint recovery. A heartbeat detection thread sends and receives heartbeat packets with a session identifier, heartbeat sequence number, sending timestamp, and application-layer verification fields according to the heartbeat cycle. The heartbeat timestamp corresponding to a valid heartbeat response is synchronously written to the communication status table along with the link connectivity signal of the target network interface, reducing misjudgments caused by packet mismatch, misidentification of old packets, and different combinations of detection cycle states. By prioritizing the operational status and media connection status of the target network interface, and then considering whether the heartbeat timestamp has expired, the invention distinguishes between a disconnected network cable and a disconnected device connection under physical link connectivity conditions, and accordingly stops heartbeat sending or releases invalid TCP connections and T... LS resources are used to reduce the probability of physical link interruptions, TCP half-open connections, and TLS silent failures being handled interchangeably. Two types of TCP reconnection trigger conditions are set based on the duration of link recovery events and device connection disconnections. Before reconnection, the connection status, link connectivity signals, and device connection disconnection start time are checked to reduce duplicate and invalid reconnections caused by concurrent state changes. By checking the binding relationship and validity period of session tickets, either TLS session recovery or full handshake is selected on the new TCP connection. This ensures that the reconnection process corresponding to a valid session ticket does not repeatedly perform certificate chain verification, while full identity verification is still performed when the ticket is invalid or the binding information is inconsistent. After TLS session recovery, a valid heartbeat response is used as the communication recovery criterion. Ultimately, this shortens the KVM link recovery time, reduces the computational overhead and remote control interruption duration during reconnection, and balances communication continuity and access security.

[0200] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for monitoring and self-healing reconnection of KVM communication links based on TCP / TLS encryption, characterized in that, include: Establish a TCP connection, load the CA certificate, complete the TLS handshake, the server sends a session ticket to the client, starts a heartbeat detection thread, and registers a link connectivity interface to obtain link connectivity signals. The heartbeat detection thread receives or sends heartbeat messages according to the heartbeat cycle and updates the heartbeat timestamp, wherein the heartbeat timestamp and the link connection / disconnection signal are written into the communication status table; the heartbeat message includes a heartbeat request message and a heartbeat response message. When the link connection signal is disconnected, the network cable is marked as disconnected in the communication status table, and heartbeat message transmission is stopped. When the link connection signal is connected and the heartbeat timestamp expires without being refreshed, the device connection is marked as disconnected in the communication status table, the TCP connection and TLS resources are released, and the session ticket is retained; When the duration of the link connection signal being restored or the device connection being disconnected is greater than or equal to a preset period, TCP reconnection is triggered, and after a new TCP connection is established, the session ticket is submitted to complete the TLS session recovery without repeating the certificate chain verification. After the TLS session is restored, a heartbeat response message is received, the device is marked as normally connected in the communication status table, and the heartbeat detection thread is restarted. Read the communication status fields required for TCP reconnection trigger determination; The first TCP reconnection trigger condition is determined based on the link connection restoration event of the link disconnection signal; The second TCP reconnection trigger condition is determined based on the duration of the device connection disconnection. Write the connection status to the automatic recovery connection and clean up the failed communication resources before reconnection; Verify the binding relationship and validity period of the session tickets, and determine the TLS reconnection method; Create a new socket and establish a new TCP connection; Submit the session ticket on the new TCP connection and perform TLS session recovery; Process the TLS session recovery result and update the communication state table; The method for determining the first TCP reconnection triggering condition includes: During the period when the network cable is disconnected, the client keeps the link connection interface in the registered state and receives network interface status change notifications generated by the target network interface. When the operating state of the target network interface changes from non-running state to running state and the media connection state of the target network interface changes from media disconnected to media connected, the client writes the link connection signal from disconnected to connected. The client acquires the mutex lock of the status table and reads the connection status and link on / off signals from the communication status table again. When the connection status is read again and the network cable is disconnected and the link connection signal is connected, the client determines the current state combination as the first TCP reconnection trigger condition and releases the state table mutex lock after the determination is completed; otherwise, it continues to wait for the target network interface to generate a new network interface status change notification. The method for determining the second TCP reconnection trigger condition includes: When the connection status is device disconnection, the client reads the current monotonic timer value and calculates the difference between the current monotonic timer value and the start time of device disconnection, and records the difference as the duration of device disconnection; The client compares the duration of the device connection disconnection with a preset period; if the duration of the device connection disconnection is less than the preset period, the client maintains the connection state as device connection disconnection; if the duration of the device connection disconnection is greater than or equal to the preset period, the client reads the operation status and media connection status of the target network interface again through the link connection interface to obtain the link connection signal before reconnection. If the link connectivity signal before reconnection is "connected", the client acquires the state table mutex lock and rechecks the connection status, device connection disconnection start time, and link connectivity signal. If the connection status is still "device connection disconnected", the device connection disconnection start time has not been modified, and the link connectivity signal is "connected", the current state combination is determined as the second TCP reconnection trigger condition, and the state table mutex lock is released. If the link connectivity signal before reconnection is "disconnected", the client acquires the state table mutex lock, writes the link connectivity signal as "disconnected", writes the connection status from "device connection disconnected" to "network cable disconnected", keeps the heartbeat sending permission flag set to "prohibited" and the heartbeat thread status set to "paused", and releases the state table mutex lock. The method for determining the TLS reconnection mode includes: The client reads the session ticket from the protected memory area corresponding to the KVM communication session and verifies whether the session ticket storage status is "stored". When the session ticket storage status is "stored", the client reads the session identifier, server address, server port, server certificate fingerprint and session ticket validity period that are bound to the session ticket, and checks them against the session identifier, server address, server port, server certificate fingerprint and current monotonic time value stored in the current KVM communication session. If the session identifier bound to the session ticket matches the current session identifier, the server address bound to the session ticket matches the current server address, the server port bound to the session ticket matches the current server port, and the server certificate fingerprint bound to the session ticket matches the currently saved server certificate fingerprint, and the session ticket has not exceeded its validity period, then the client records the session ticket as a pending session ticket and determines the TLS reconnection method as the session recovery method; if any binding information is inconsistent, the session ticket has exceeded its validity period, or the session ticket storage status is not "stored", then the client does not generate a pending session ticket and determines the TLS reconnection method as the full handshake method.

2. The method for monitoring and self-healing reconnection of KVM communication links based on TCP / TLS encryption as described in claim 1, characterized in that, The method for establishing the new TCP connection includes: The client creates a new socket based on the server address and server port; if the server address is a domain name, the client re-resolves the server address to obtain the current IP address corresponding to the server address, and generates a new server socket address based on the current IP address and the server port; if the server address is an IP address, the client directly generates a new server socket address based on the server address and the server port. Configure the connection timeout and read / write timeout for the new socket, and initiate a TCP connection request to the new server socket address through the new socket. Wait for the server to return a TCP handshake response within the preset connection time. When the client receives a TCP handshake response within the preset connection time, the client acquires the state table mutex lock, writes the new socket handle corresponding to the new socket into the socket identifier in the communication state table, keeps the connection state as "automatically recovering connection", and releases the state table mutex lock. The routing information corresponding to the new TCP connection is used to verify whether the network interface carrying the new TCP connection is the target network interface. If the network interface carrying the new TCP connection has changed, the link connectivity interface corresponding to the original target network interface is deregistered, the network interface carrying the new TCP connection is updated to the target network interface, and the link connectivity interface corresponding to the target network interface is re-registered.

3. The method for monitoring and self-healing reconnection of KVM communication links based on TCP / TLS encryption as described in claim 1, characterized in that, The heartbeat detection thread receives or sends heartbeat messages according to the heartbeat cycle and updates the heartbeat timestamp, including: The heartbeat detection thread acquires the mutex lock of the state table, reads the session identifier, connection state, TLS handshake state, link connection / disconnection signal and heartbeat thread state from the communication state table, and reads the heartbeat sending permission flag and thread exit flag. The heartbeat detection thread generates heartbeat trigger events according to the heartbeat cycle, and when each heartbeat trigger event arrives, it reads the operation status and medium connection status of the target network interface through the link connection interface to determine the link connection signal corresponding to the current heartbeat cycle. The server receives the heartbeat request message through the TLS encrypted link, parses the message header, protocol version, message type, message length, session identifier, heartbeat sequence number, sending timestamp, and application layer verification field in the heartbeat request message, and verifies the application layer verification field. The heartbeat detection thread receives and verifies the heartbeat response message returned by the server to determine the valid heartbeat response message; When the heartbeat detection thread receives the valid heartbeat response message, it reads the current monotonic time value corresponding to the valid heartbeat response message as the heartbeat timestamp to be written. After the heartbeat detection thread completes the communication status table write operation within the current heartbeat cycle and releases the status table mutex lock, the verification thread exits the flag.

4. The method for monitoring and self-healing reconnection of KVM communication links based on TCP / TLS encryption as described in claim 3, characterized in that, The method for determining the link connectivity signal includes: When the target network interface is in the running state and the medium connection state is in the medium connection state, the link connection signal is determined to be connected; if the link connection signal is connected, the heartbeat detection thread increments the heartbeat sequence number by one, reads the current monotonic time value as the sending timestamp, and writes the message header, the protocol version, the heartbeat request type, the message length, the session identifier, the incremented heartbeat sequence number and the sending timestamp into the sending buffer according to the heartbeat message format, and calculates the application layer verification field based on the above fields to obtain the heartbeat request message; When the target network interface is in a non-running state or the medium connection state is a disconnected medium, the link connection signal is determined to be disconnected; if the link connection signal is disconnected, the heartbeat timestamp in the communication status table remains unchanged.

5. The method for monitoring and self-healing reconnection of KVM communication links based on TCP / TLS encryption as described in claim 3, characterized in that, The method for determining a valid heartbeat response message includes: After sending the heartbeat request message, the heartbeat detection thread listens to the TLS encrypted link within a preset heartbeat response waiting time and writes the decrypted message output by the TLS encrypted link into the receiving buffer. The heartbeat detection thread reads the message to be verified in the receive buffer and checks the message header, protocol version, message type, message length and application layer verification field of the message to be verified in sequence. When the message type of the message to be verified is a heartbeat response type, the process continues to check whether the session identifier in the message to be verified is consistent with the session identifier of the current KVM communication session, and whether the heartbeat sequence number in the message to be verified is consistent with the heartbeat sequence number in the heartbeat request message sent in the current heartbeat cycle. If the above verification results are consistent, the message to be verified is determined to be a valid heartbeat response message; otherwise, the message to be verified is discarded.

6. A KVM communication link monitoring and breakpoint self-healing reconnection system based on TCP / TLS encryption, based on the KVM communication link monitoring and breakpoint self-healing reconnection method based on TCP / TLS encryption as described in any one of claims 1 to 5, characterized in that, include: The link establishment initialization module is used to establish a TCP connection, load the CA certificate, complete the TLS handshake, send the session ticket from the server to the client, start the heartbeat detection thread, and register the link connectivity interface to obtain the link connectivity signal. The heartbeat status update module is used by the heartbeat detection thread to receive or send heartbeat messages according to the heartbeat cycle and update the heartbeat timestamp, wherein the heartbeat timestamp and the link connection / disconnection signal are written into the communication status table; the heartbeat message includes a heartbeat request message and a heartbeat response message. An abnormal state determination module is used to mark the network cable as disconnected in the communication status table and stop sending heartbeat messages when the link connection signal is disconnected. When the link connection signal is connected and the heartbeat timestamp expires without being refreshed, the device connection is marked as disconnected in the communication status table, the TCP connection and TLS resources are released, and the session ticket is retained; The session recovery and reconnection module is used to trigger TCP reconnection when the link connection signal is restored or the duration of the device connection being disconnected is greater than or equal to a preset period. After the new TCP connection is established, the session ticket is submitted to complete the TLS session recovery without repeating the certificate chain verification. The connection confirmation and restart module is used to receive a heartbeat response message after the TLS session is restored, mark the device as normally connected in the communication status table, and restart the heartbeat detection thread.

Images