Method for suppressing jitter based on TCP protocol network tunnel

Abstract

The present invention discloses a method for suppressing jitter in a TCP-based network tunnel. The method comprises deploying a virtual private network (VPN) protocol within a client / server architecture, installing a server and client, and using the TCP protocol to connect the client and server through a dial-up parameter negotiation process and a tunnel data transmission process to encapsulate, encrypt, and transmit data packets. By encapsulating, encrypting, and transmitting IP data packets within the TCP protocol format, the method retains TCP's three-way and four-way handshake mechanisms while eliminating the acknowledgment, retransmission mechanism, and the corresponding complex congestion control algorithms. Furthermore, the method utilizes forward error correction (FEC) codes within a custom VPN protocol to achieve high-efficiency, high-reliability, and low-latency jitter transmission of network data packets, while also offering good adaptability to Internet environments.

Description

Technical Field

[0001] The present invention relates to a method for suppressing network jitter, and in particular to a method for suppressing jitter based on a TCP protocol network tunnel. Background Art

[0002] A virtual private network, or VPN, establishes a private network across a public network for encrypted communications. It is widely used in enterprise networks. VPN gateways enable remote access by encrypting data packets and translating their destination addresses. VPNs can be categorized in various ways, primarily by protocol. VPNs can be implemented using servers, hardware, and software.

[0003] To enable branch office employees to access the intranet resources of headquarters or the data center, the VPN solution involves setting up a VPN server on the headquarters intranet. Branch office gateways connect to the VPN server via the internet, allowing them to access the headquarters intranet through the VPN server. To ensure data security, data between the VPN server and the branch office gateway is encrypted. With data encryption, data can be securely transmitted over a dedicated data link, as if it were a private network. However, VPNs actually use the public links on the internet, making them virtual private networks. Essentially, VPNs use encryption technology to create a data communication tunnel over the public internet.

[0004] Virtual Private Network (VPN) protocols and their software are typically encapsulated and transmitted using either UDP or TCP. UDP-based VPN tunnels are typically designed to meet specific needs, particularly in latency-sensitive applications such as video streaming or online gaming. However, the UDP protocol itself has limitations, including unreliability and an inability to adapt to the existing Internet environment. Unreliability refers to the fact that UDP is a connectionless protocol that doesn't guarantee data packet delivery and lacks a retransmission mechanism. If a data packet is lost during network transmission, it will not be received by the receiving end. Furthermore, an inability to adapt to the existing Internet environment refers to the fact that UDP-based VPNs, when operating on the Internet, are subject to local network communication policies and traffic control restrictions, making it impossible to establish a VPN connection or resulting in poor network transmission quality. Before rectification, VPN tunnels based on the TCP transmission control protocol had problems with high latency, increased latency in weak network environments, and low transmission efficiency. High latency refers to the fact that TCP uses technologies such as three-way handshakes, confirmation responses, and retransmission mechanisms to ensure the reliable transmission of data packets. Although this ensures data integrity, it also introduces additional network round-trip time, resulting in higher latency. TCP will retransmit lost data packets, which improves the reliability of data transmission. However, in environments with poor network conditions or high packet loss rates, frequent retransmissions will increase network load and further increase latency. Since TCP has complex congestion control algorithms, these algorithms help prevent network congestion but may also cause data transmission rates to slow down. In high-load network environments, TCP's congestion control may reduce data transmission efficiency. Summary of the Invention

[0005] In order to solve the shortcomings of the above technologies, the present invention provides a method for suppressing jitter based on a TCP protocol network tunnel.

[0006] In order to solve the above technical problems, the technical solution adopted by the present invention is: a method for suppressing jitter based on a TCP protocol network tunnel, comprising the following steps:

[0007] Step S1: Deploy the virtual private network (VPN) protocol in a client / server architecture and install the server and client.

[0008] Step S2: Using the TCP protocol, the client and the server are connected through a dial-up parameter negotiation process to encapsulate, encrypt, and transmit data packets. The dial-up parameter negotiation process to connect the client and the server includes the following steps:

[0009] Step S21: The client initiates a TCP connection to the server based on the standard TCP three-way handshake mechanism;

[0010] Step S22: The server accepts the new connection and establishes a connection with the client;

[0011] Step S23: After the connection is established, the client and the server negotiate the Client ID;

[0012] Step S24: After the client completes the verification, it sends the client RSA public key. The server records the client RSA public key and sends the server RSA public key.

[0013] Step S25: The client records the server's RSA public key and sends the symmetric encryption algorithm. The server generates and encrypts the symmetric encryption key using RSA.

[0014] Step S26: The server sends the RSA encrypted key to the client, and the client decrypts and records the symmetric encryption key;

[0015] Step S27: The client sends error correction algorithm parameters, i.e., redundant parameters. The server records the error correction algorithm parameters and sends duplicate error correction algorithm parameters to the client.

[0016] Step S28: The client verifies the error correction algorithm parameters replied by the server, sends a request after verification, and obtains an IP address message and sends it to the server;

[0017] Step S29: The client and the server negotiate tunnel network parameters; the tunnel network parameters include the client tunnel IP address, subnet mask, and the server tunnel IP address;

[0018] Step S210: The client creates a virtual network card for the local tunnel and starts the tunnel data transmission process to enable the forward error correction code (FEC) to perform data damage redundancy calculation to restore the original data and suppress jitter.

[0019] Step S211: The client initiates a TCP disconnect to the server based on the standard TCP four-way handshake, and the server ends the TCP communication.

[0020] Furthermore, in step S23, the client ID negotiation is performed between the client and the server, including the following steps:

[0021] Step S23-1: The client sends a Client ID message, the server processes the Client ID message, and initializes the data structure of the Client ID message;

[0022] Step S23-2: The server sends a duplicate Client ID message, and the client verifies the Client ID message replied by the server; that is, it checks whether the Client ID message sent by the server is the value sent by the client before.

[0023] Furthermore, in step S26, the client decrypts and records the symmetric encryption key, including the following steps:

[0024] Step S26-1: The client sends the encryption type requested by the client to the server;

[0025] Step S26-2: The server generates a random string based on the encryption type requested by the client and uses the server's RSA private key to encrypt a 32-byte key, a 12-byte initialization vector, and 16-byte additional information.

[0026] Step S26-3: The server sends the AES-GCM or SM4 encryption parameters encrypted by the server's RSA to the client;

[0027] Step S26-4: The client uses the server's RSA public key to decrypt the key Key, the initial vector IV, and the additional information AAD.

[0028] Furthermore, in step S28, the client verifies the error correction algorithm parameters replied by the server, including the following steps:

[0029] Step S28-1: The client sends redundant parameters to the server;

[0030] Step S28-2: The server records redundant parameters;

[0031] Step S28-3: The server sends a reply to the client to confirm the redundant parameters;

[0032] Step S28-4: The client checks whether the redundant parameter sent by the server is the value that has been sent before.

[0033] Furthermore, in step S29, the client and the server negotiate tunnel network parameters, including the following steps:

[0034] Step S29-1: The client sends a network parameter request instruction to the server;

[0035] Step S29-2: The server allocates a tunnel IP address, subnet mask, and server tunnel IP address to the client, and encrypts the tunnel IP address, subnet mask, and server tunnel IP address based on the server RSA private key.

[0036] Step S29-3: The server sends the encrypted tunnel network parameters to the client;

[0037] Step S29-4: The client decrypts and records the client tunnel IP address, subnet mask and server tunnel IP address.

[0038] Furthermore, the tunnel data transmission process in step S210 adopts a custom encapsulated TCP data packet and interaction process, which becomes 7xETP; the structure of 7xETP includes a TCP header, which occupies 20 bytes; a 7xETP plaintext protocol header, which occupies 8 bytes; 7xETP encrypted data, including a 7xETP ciphertext protocol header, which occupies 4 bytes and original IP packet data; the original IP packet data includes 7xETP FEC parameters, which occupy 11 bytes and FEC fragments of variable length.

[0039] Furthermore, the tunnel data transmission process, where the client and the server serve as the sender and receiver, reads, encapsulates, and transmits data, includes the following steps:

[0040] Step S210-1: The sending end reads the tunnel network card data packet and encapsulates the data packet read from the tunnel network card;

[0041] Step S210-2: Determine the FEC (Forward Error Correction) code parameters based on the network quality and determine whether the FEC parameters need to be sliced. If slicing is required, split the encrypted data into several data slices based on the length of the encrypted data, generate redundant data slices according to the forward error correction algorithm, and symmetrically encrypt the encapsulated data slices. If FEC slicing is not required, directly symmetrically encrypt the encapsulated data.

[0042] Step S210-3: The sending end encapsulates TCP data packets and sends the TCP data packets one by one through the raw socket; the receiving end receives the TCP data packets through the raw socket;

[0043] Step S210-4: After receiving the TCP data packet, the receiving end decapsulates the TCP data packet and then decrypts the encapsulated data. It determines whether it is an FEC fragment based on the decrypted protocol parameters. If the decrypted protocol parameters are FEC fragments, the original data packet group is restored according to the forward error correction algorithm, and finally decapsulated to obtain the original network card data packet. If the decrypted protocol parameters are not FEC fragments, the encapsulated data is directly decapsulated to obtain the original network card data packet and written into the tunnel network card data packet.

[0044] Furthermore, after the sender reads data from the Linux virtual network card in step S210-1, the format of the data after encapsulation includes the magic word, which is 2 bytes, or 16 bits, fixed to "7x" to identify the characteristics of this protocol; the total length, that is, the length of all data sent at one time, is 2 bytes, or 16 bits; the local tunnel IP address, that is, the LocalTunnel IP, is 4 bytes, or 32 bits. The client tunnel IP address is obtained from the server during the negotiation process, and the server tunnel IP address is specified in the configuration file; the ciphertext, which is greater than the total length but less than 8 bytes, or 64 bits, is encrypted using the encryption method negotiated between the client and the server, that is, AES / SM4, and the key, initialization vector, and additional information in the encryption parameters, to encrypt the plaintext structure;

[0045] The plaintext format before encryption includes the message type (Type), which is half a byte or 4 bits; the message header (Header), which is one half byte or 12 bits, of which one bit indicates whether the current data packet is an FEC fragment, and the remaining bits are filled with 0 to represent a reserved field; the data length (Date Length), which is two bytes or 16 bits, is the length of the data content; the data content is variable length. If FEC is not enabled, the data content is a standard IP data packet, that is, the user IP length; if FEC is enabled and redundancy calculation is performed, the Reed Solomom algorithm is enabled to fragment the original data, and redundant data fragments are calculated based on the original fragments. Each fragment is encrypted using the AES / SM4 encryption algorithm, and the fragmented data is re-encapsulated and sent to the peer end.

[0046] Furthermore, after FEC is turned on, the format of re-encapsulating the fragmented data includes the packet sequence PacketSequence of 4 bytes, i.e. 42 bits, which is used to identify the historical fragment number of the current data bit; the original fragment number Number of Original Fragment is 1 byte, i.e. 8 bits, which is the number of original fragments in the current group of fragments; the total number of fragments is 1 byte, i.e. 8 bits, which is the total number of fragments in the current group of fragments, then the number of redundant fragments = the total number of fragments - the number of original fragments; the current fragment sequence Fragment Sequence is 1 byte, i.e. 8 bits, which is the sequence of the current fragment in the current group of fragments; the fragment data Fragment Size length is 2 bytes, i.e. 16 bits, which indicates the standard length of each fragment; the original data payload length Original Payload Length is 2 bytes, i.e. 16 bits, which is equal to the original data length restored by any original fragment of the current group; the fragment content is of variable length and depends on the data length of the fragment.

[0047] Furthermore, calculating redundant data fragments includes the following steps:

[0048] Step B1: Read K IP packets from the virtual network card;

[0049] Step B2: Splice K IP packets into a whole segment of data;

[0050] Step B3: Split the entire data segment into K segments, i.e., K shards;

[0051] Step B4: Calculate N redundant fragments using the Reed Solomon algorithm; the total number of fragments of the current packet is K+N.

[0052] The present invention discloses a method for suppressing jitter in a TCP protocol network tunnel. By encapsulating, encrypting and transmitting IP data packets in the TCP protocol format, the three-way handshake and four-way handshake mechanisms of TCP are retained, and the confirmation response, retransmission mechanism and the corresponding complex congestion control algorithm are eliminated. By using the FEC forward error correction code on a customized VPN protocol, high-efficiency, high-reliability and low-latency jitter transmission of network data packets is achieved, and the method has good adaptability to the Internet environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Figure 1 The flowchart of the interaction process between the client and the server in the present invention.

[0054] Figure 2 This is a structural diagram of the TCP protocol used in the present invention.

[0055] Figure 3 Schematic diagram of the TCP three-way handshake mechanism in the present invention.

[0056] Figure 4 Schematic diagram of the TCP four-way handshake mechanism in the present invention.

[0057] Figure 5 This is a flow chart of the tunnel data transmission process in the present invention.

[0058] Figure 6 This is a diagram of the data encapsulation structure read by the sending end in the present invention.

[0059] Figure 7 This is the plaintext structure diagram before encryption in the present invention.

[0060] Figure 8 This is a structural diagram of FEC encapsulated data in the present invention.

[0061] Figure 9 This is a structural diagram of the 7xETP protocol in the present invention. DETAILED DESCRIPTION

[0062] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0063] The method for suppressing jitter based on a TCP protocol network tunnel includes the following steps:

[0064] Step S1: Deploy the virtual private network (VPN) protocol in a client / server architecture and install the server and client.

[0065] Step S2: Using the TCP protocol, the client and the server are connected through a dial-up parameter negotiation process to encapsulate, encrypt, and transmit data packets. The dial-up parameter negotiation process to connect the client and the server includes the following steps:

[0066] Step S21: The client initiates a TCP connection to the server based on the standard TCP three-way handshake mechanism;

[0067] Step S22: The server accepts the new connection and establishes a connection with the client;

[0068] Step S23: After the connection is established, the client and the server negotiate the Client ID;

[0069] Step S24: After the client completes the verification, it sends the client RSA public key. The server records the client RSA public key and sends the server RSA public key.

[0070] Step S25: The client records the server's RSA public key and sends the symmetric encryption algorithm. The server generates and encrypts the symmetric encryption key using RSA.

[0071] Step S26: The server sends the RSA encrypted key to the client, and the client decrypts and records the symmetric encryption key;

[0072] Step S27: The client sends error correction algorithm parameters, i.e., redundant parameters. The server records the error correction algorithm parameters and sends duplicate error correction algorithm parameters to the client.

[0073] Step S28: The client verifies the error correction algorithm parameters replied by the server, sends a request after verification, and obtains an IP address message and sends it to the server;

[0074] Step S29: The client and the server negotiate tunnel network parameters; the tunnel network parameters include the client tunnel IP address, subnet mask, and the server tunnel IP address;

[0075] Step S210: The client creates a virtual network card for the local tunnel and starts the tunnel data transmission process to enable the forward error correction code (FEC) to perform data damage redundancy calculation to restore the original data and suppress jitter.

[0076] Step S211: The client initiates a TCP disconnect to the server based on the standard TCP four-way handshake, and the server ends the TCP communication.

[0077] Specifically, in step S23, the client ID negotiation between the client and the server includes the following steps:

[0078] Step S23-1: The client sends a Client ID message, the server processes the Client ID message, and initializes the data structure of the Client ID message;

[0079] Step S23-2: The server sends a duplicate Client ID message, and the client verifies the Client ID message replied by the server; that is, it checks whether the Client ID message sent by the server is the value sent by the client before.

[0080] In step S26, the client decrypts and records the symmetric encryption key, including the following steps:

[0081] Step S26-1: The client sends the encryption type requested by the client to the server;

[0082] Step S26-2: The server generates a random string based on the encryption type requested by the client and uses the server's RSA private key to encrypt a 32-byte key, a 12-byte initialization vector, and 16-byte additional information.

[0083] Step S26-3: The server sends the AES-GCM or SM4 encryption parameters encrypted by the server's RSA to the client;

[0084] Step S26-4: The client uses the server's RSA public key to decrypt the key Key, the initial vector IV, and the additional information AAD.

[0085] In step S28, the client verifies the error correction algorithm parameters replied by the server, including the following steps:

[0086] Step S28-1: The client sends redundant parameters to the server;

[0087] Step S28-2: The server records redundant parameters;

[0088] Step S28-3: The server sends a reply to the client to confirm the redundant parameters;

[0089] Step S28-4: The client checks whether the redundant parameter sent by the server is the value that has been sent before.

[0090] Furthermore, in step S29, the client and the server negotiate tunnel network parameters, including the following steps:

[0091] Step S29-1: The client sends a network parameter request instruction to the server;

[0092] Step S29-2: The server allocates a tunnel IP address, subnet mask, and server tunnel IP address to the client, and encrypts the tunnel IP address, subnet mask, and server tunnel IP address based on the server RSA private key.

[0093] Step S29-3: The server sends the encrypted tunnel network parameters to the client;

[0094] Step S29-4: The client decrypts and records the client tunnel IP address, subnet mask and server tunnel IP address.

[0095] In step S210, the tunnel data transmission process uses a custom encapsulated TCP data packet and interaction process to become 7xETP; the structure of 7xETP includes a TCP header, which occupies 20 bytes; a 7xETP plaintext protocol header, which occupies 8 bytes; 7xETP encrypted data, including a 7xETP ciphertext protocol header, which occupies 4 bytes and the original IP packet data; the original IP packet data includes the 7xETP FEC parameters, which occupies 11 bytes and FEC fragments of variable length.

[0096] The tunnel data transmission process, in which the client and server act as sender and receiver, reads, encapsulates, and transmits data, includes the following steps:

[0097] Step S210-1: The sending end reads the tunnel network card data packet and encapsulates the data packet read from the tunnel network card;

[0098] Step S210-2: Determine the FEC (Forward Error Correction) code parameters based on the network quality and determine whether the FEC parameters need to be sliced. If slicing is required, split the encrypted data into several data slices based on the length of the encrypted data, generate redundant data slices according to the forward error correction algorithm, and symmetrically encrypt the encapsulated data slices. If FEC slicing is not required, directly symmetrically encrypt the encapsulated data.

[0099] Step S210-3: The sending end encapsulates TCP data packets and sends the TCP data packets one by one through the raw socket; the receiving end receives the TCP data packets through the raw socket;

[0100] Step S210-4: After receiving the TCP data packet, the receiving end decapsulates the TCP data packet and then decrypts the encapsulated data. It determines whether it is an FEC fragment based on the decrypted protocol parameters. If the decrypted protocol parameters are FEC fragments, the original data packet group is restored according to the forward error correction algorithm, and finally decapsulated to obtain the original network card data packet. If the decrypted protocol parameters are not FEC fragments, the encapsulated data is directly decapsulated to obtain the original network card data packet and written into the tunnel network card data packet.

[0101] In step S210-1, after the sender reads data from the Linux virtual network card, the format of the data after encapsulation includes the magic word, which is 2 bytes, or 16 bits, fixed to "7x" to identify the characteristics of this protocol; the total length, or the total length of all data sent at once, is 2 bytes, or 16 bits; the local tunnel IP address, or Local Tunnel IP, is 4 bytes, or 32 bits. The client tunnel IP address is obtained from the server during the negotiation process, and the server tunnel IP address is specified in the configuration file; the ciphertext, or Ciphertext, is larger than the total length but less than 8 bytes, or 64 bits. The plaintext structure is encrypted using the encryption method negotiated between the client and server, or AES / SM4, and the key, initialization vector, and additional information in the encryption parameters.

[0102] The plaintext format before encryption includes the message type (Type), which is half a byte or 4 bits; the message header (Header), which is one half byte or 12 bits, of which one bit indicates whether the current data packet is an FEC fragment, and the remaining bits are filled with 0 to represent a reserved field; the data length (Date Length), which is two bytes or 16 bits, is the length of the data content; the data content is variable length. If FEC is not enabled, the data content is a standard IP data packet, that is, the user IP length; if FEC is enabled and redundancy calculation is performed, the Reed Solomom algorithm is enabled to fragment the original data, and redundant data fragments are calculated based on the original fragments. Each fragment is encrypted using the AES / SM4 encryption algorithm, and the fragmented data is re-encapsulated and sent to the peer end.

[0103] After FEC is enabled, the format of re-encapsulating the fragmented data includes the following: Packet Sequence is 4 bytes, or 42 bits, used to identify the historical fragment number of the current data bit; Number of Original Fragment is 1 byte, or 8 bits, which is the number of original fragments in the current group of fragments; Total Number of Fragments is 1 byte, or 8 bits, which is the total number of fragments in the current group of fragments, then Number of Redundant Fragments = Total Number of Fragments - Number of Original Fragments; Current Fragment Sequence is 1 byte, or 8 bits, which is the sequence of the current fragment in the current group of fragments; Fragment Size is 2 bytes, or 16 bits, indicating the standard length of each fragment; Original Payload Length is 2 bytes, or 16 bits, which is equal to the length of the original data restored by any original fragment of the current packet; The fragment content is of variable length and depends on the data length of the fragment.

[0104] Calculating redundant data shards includes the following steps:

[0105] Step B1: Read K IP packets from the virtual network card;

[0106] Step B2: Splice K IP packets into a whole segment of data;

[0107] Step B3: Split the entire data segment into K segments, i.e., K shards;

[0108] Step B4: Calculate N redundant fragments using the Reed Solomon algorithm; the total number of fragments of the current packet is K+N.

[0109] This embodiment provides a method for suppressing jitter based on a TCP protocol network tunnel, which connects the corporate headquarters and branches, allowing employees of the branches to access the intranet resources of the headquarters or data center.

[0110] In the Client / Server architecture, the server software is installed on the CPE devices at the corporate headquarters, and the client software is installed on the CPE devices at the branch offices. No PC client or mobile phone or tablet app is provided.

[0111] The server software can monitor a TCP port through a normal socket for the VPN dial-up process and parameter negotiation, and the interaction with the client complies with the standard TCP protocol; it reads and writes data segments of a specific TCP port through a raw socket for the VPN data transmission process. This TCP port is used for special processing and cannot be monitored by calling the system listen command.

[0112] The specific deployment details include: the client operating environment is set to the CentOS or Ubuntu Linux operating system; the dependent libraries are ibuuid, pcre, libuv, OpenSSL, OpenFEC, libconfig++, and log4cpp; it is recommended to copy the program package contents to the / usr / local / abyss-client directory; where abyss-client is the executable file, config is the configuration file directory, abyss-client.conf is the main configuration file, log4cpp.conf is the log configuration file, and log is the log file directory.

[0113] The server's operating environment is set to a CentOS or Ubuntu Linux operating system. The dependent libraries are libuuid, pcre, libuv, OpenSSL, OpenFEC, libconfig++, and log4cpp. It is recommended to copy the package contents to the / usr / local / abyss-server directory. Here, abyss-server is the executable file, config is the configuration file directory, abyss-server.conf is the main configuration file, log4cpp.conf is the log configuration file, and log is the log file directory.

[0114] Using the TCP protocol, the client and server are connected through the dial-up parameter negotiation process; the dial-up parameter negotiation process allows the server to record client-related information for subsequent data forwarding; allows the client and server to exchange RSA encryption keys; allows the client and server to negotiate AES / SM4 encryption keys; allows the client and server to negotiate the necessary parameters of the FEC algorithm; and allows the server to assign an IP address to the client. The client and server are connected through the dial-up parameter negotiation process, such as Figure 1 The flowchart of the client-server interaction process in the method for suppressing jitter in a TCP protocol network tunnel is shown, which includes the following steps:

[0115] Step A1: The client initiates a TCP connection to the server based on the standard TCP three-way handshake; Figure 2The following diagram shows the TCP protocol structure used in the TCP-based network tunnel jitter suppression method. In this process, the TCP protocol structure is as follows: the message type is 1 byte (8 bits); the message length is 4 bytes (32 bits), describing the length of the message content to be read later; the message body varies depending on the message type. When the message type value is 0x01, the message type is to notify the client ID; when the message type value is 0x02, the message type is to exchange the RSA encryption public key; when the message type value is 0x03, the message type is to exchange the SM4 encryption key; when the message type value is 0x04, the message type is error correction configuration information; when the message type value is 0x05, the message type is to distribute the IP address.

[0116] Step A2: The server accepts the new connection and the client connection is established;

[0117] Step A3: After the connection is established, the client and server negotiate the Client ID.

[0118] Step A31: The client sends a Client ID message, the server processes the Client ID message, and initializes the data structure of the Client ID message;

[0119] Step A32: The server sends a duplicate Client ID message, and the client verifies the Client ID message sent by the server, that is, checks whether the Client ID message sent by the server is the value sent by the client before.

[0120] Step A4: After the client completes verification, it sends the client's RSA public key. The server records the client's RSA public key and sends the server's RSA public key.

[0121] Step A5: The client records the server's RSA public key and sends the symmetric encryption algorithm. The server generates and encrypts the symmetric encryption key using RSA.

[0122] Step A6: The server sends the RSA-encrypted key to the client, which decrypts and records the symmetric encryption key.

[0123] Step A61: The client sends the encryption type requested by the client to the server;

[0124] 0x01 is AES-GCM, 0x02 is SM4;

[0125] Step A62: The server generates a random string based on the encryption type requested by the client and uses the server's RSA private key to encrypt a 32-byte key, a 12-byte initialization vector, and 16-byte additional information.

[0126] Step A63: The server sends the encryption parameters of AES-GCM or SM4 after the server RSA encryption to the client;

[0127] Step A64: The client uses the server's RSA public key to decrypt the key Key, the initial vector IV, and the additional information AAD.

[0128] Step A7: The client sends error correction algorithm parameters, i.e., redundant parameters. The server records the error correction algorithm parameters and sends duplicate error correction algorithm parameters to the client.

[0129] Step A8: The client verifies the error correction algorithm parameters replied by the server, sends a request after verification, obtains an IP address message, and sends it to the server;

[0130] Step A81: The client sends redundant parameters to the server;

[0131] 1 byte for FEC mode to be changed. 0x00 means FEC is forcibly disabled. 0x01 means FEC parameters are automatically adjusted based on network quality. 0x02 means FEC is forcibly enabled. The number of original packets is 5 and the number of redundant packets is 1.

[0132] Step A82: The server records the redundant parameters;

[0133] Step A83: The server sends a reply to the client to confirm the redundant parameters;

[0134] Step A84: The client checks whether the redundant parameter sent by the server is the value that has been sent before.

[0135] Step A9: The client and the server negotiate tunnel network parameters; the tunnel network parameters include the client tunnel IP address, subnet mask, and the server tunnel IP address;

[0136] Step A91: The client sends a network parameter request instruction to the server;

[0137] Step A92: The server allocates a tunnel IP address, a subnet mask, and a server tunnel IP address to the client, and encrypts the tunnel IP address, the subnet mask, and the server tunnel IP address based on the server RSA private key.

[0138] Step A93: The server sends the encrypted tunnel network parameters to the client;

[0139] Step A94: The client decrypts and records the client tunnel IP address, subnet mask, and server tunnel IP address

[0140] Step A10: The client creates a virtual network card for the local tunnel and starts the tunnel data transmission process;

[0141] The client configures tunnel network parameters based on the virtual network card of the Linux tun driver.

[0142] The tunnel data transmission process uses custom encapsulated TCP packets and interactive processes, known as 7xETP; Figure 9 As shown in the structural diagram of the 7xETP protocol in the method for suppressing jitter in a TCP protocol network tunnel, the complete structure of 7xETP includes a 20-byte TCP header; an 8-byte 7xETP plaintext protocol header; 7xETP encrypted data of variable length; 7xETP encrypted data includes a 4-byte 7xETP ciphertext protocol header and original IP packet data of variable length; original IP packet data includes 11 bytes of 7xETP FEC parameters and FEC fragments of variable length.

[0143] The tunnel data transmission process is a composite protocol that spans from the transport layer to the application layer. The protocol structure of the transport layer retains the structure of the TCP protocol header unchanged; the three-way handshake mechanism of the standard TCP protocol is retained and independently implemented, so that the intermediate network devices in the network transmission process, mainly firewalls, can correctly establish sessions and ensure that data communication can proceed normally; the four-way handshake mechanism of the standard TCP protocol is retained and independently implemented, so that the intermediate network devices in the network transmission process, mainly firewalls, can correctly destroy conversations and avoid unpredictable failures of intermediate devices; the TCP confirmation response is retained, which can circumvent the detection mechanism of intermediate network devices and prevent intermediate devices from actively discarding data packets because they believe that the receiving windows at both ends are full; at the same time, no timeout detection is performed on TCP confirmation responses, and the timeout retransmission mechanism is canceled. The forward error correction code is enabled as an error correction method in the TCP data part, and the original data packet is restored through data damage redundancy calculation, replacing the retransmission mechanism; the TCP sliding window mechanism and the corresponding congestion mechanism are also canceled.

[0144] like Figure 3 As shown in the schematic diagram of the TCP three-way handshake mechanism in the method of suppressing jitter based on the TCP protocol network tunnel, the three-way handshake mechanism of the standard TCP protocol includes: in the initial state, both the client and the server are in the CLOSED state; the client is destined to open the connection, and the server is passively opening the connection.

[0145] The first handshake is when the client establishes a transmission control block (TCB) and is always ready to accept the client process's connection request. At this time, the server enters the LISTEN listening state and sets the TCP message flag SYN to 1. It randomly generates a sequence number value seq=x and saves it in the sequence number (Sequence Number) field of the TCP header, indicating the port of the server the client intends to connect to. The server establishes a passive TCB open and sends the data packet to the server. After sending, the client enters the SYN_SENT state and waits for confirmation from the server. The second handshake is when the server receives the data packet and knows from the flag SYN=1 that the client requests to establish a connection. The server sets the TCP message flags SYN and ACK to 1, ack=x+1, randomly generates a sequence number value seq=y, and sends the data packet to the client to confirm the connection request. The server enters the SYN_RCVD state.

[0146] The third handshake is when the client receives the confirmation and checks whether ack is x+1 and ACK is 1. If correct, the flag ACK is set to 1, ack=y+1, and the data packet is sent to the server. The server checks whether ack is y+1, ACK is 1, and seq=x+1. If correct, the connection is successfully established, the client and server enter the ESTABLISHED state, and the three-way handshake is completed. Then the client and server can start transmitting data.

[0147] like Figure 4 This is a diagram of the TCP four-way handshake mechanism in a method for suppressing jitter in a TCP protocol network tunnel. The standard TCP four-way handshake mechanism includes: after data transmission is completed, both parties can release the connection; initially, both the client and the server are in the ESTABLISHED state, with the client actively closing and the server passively closing;

[0148] The first wave sends a connection release message to the client and stops sending data. The release data message header has FIN=1 and its sequence number is seq=u, which is the sequence number of the last byte of the previously transmitted data plus 1. At this point, the client enters the FIN-WAIT-1 state, which means the client stops waiting.

[0149] The second wave is when the server receives the connection release message and sends a confirmation message, ACK=1, ack=u+1, and carries its own sequence number seq=v. At this time, the server enters the CLOSE-WAIT closing waiting state.

[0150] After the third wave, the client receives the confirmation request from the server, and then the client enters the FIN-WAIT-2 state, waiting for the server to send a connection release message. After the server sends the last data, it sends a connection release message to the client, and the server enters the LAST-ACK state, waiting for the client's confirmation.

[0151] The fourth wave is when the client receives the connection release message from the server and must send a confirmation, ACK=1, ack=w+1, and its own column number is seq=u+1. At this time, the client enters the TIME-WAIT state, but the TCP connection has not been terminated yet. It must wait for 2MSL, which is the long message life. When the client revokes the corresponding TCB, the client will enter the CLOSED state. After receiving the confirmation message, the server will immediately enter the CLOSED state. At this point, the TCP connection is disconnected, and the four waves are completed.

[0152] like Figure 5 The flowchart of the tunnel data transmission process in the method for suppressing jitter in a TCP protocol network tunnel is shown. The tunnel data transmission process, disguised as a TCP format, can help clients bypass UDP shielding. The client and server serve as senders and receivers, reading, encapsulating, and transmitting data, including the following steps:

[0153] Step A101: The sending end reads the tunnel network card data packet and encapsulates the data packet read from the tunnel network card; Figure 6 As shown in the diagram of the data encapsulation structure read by the sender in the method for suppressing jitter in a TCP protocol network tunnel, after the sender reads data from the Linux virtual network card, the encapsulated data structure includes: the magic word, which is 2 bytes, or 16 bits, and is fixedly set to "7x" to identify the characteristics of this protocol; the total length, which is the total length of the data sent at one time, is 2 bytes, or 16 bits; the local tunnel IP address, or Local Tunnel IP, is 4 bytes, or 32 bits. The client tunnel IP address is obtained from the server during the negotiation process, and the server tunnel IP address is specified in the configuration file; the ciphertext, which is larger than the total length but less than 8 bytes, or 64 bits, is encrypted using the encryption method negotiated between the client and the server, or AES / SM4, and the key, initialization vector, and additional information in the encryption parameters to encrypt the plaintext structure;

[0154] like Figure 7As shown in the plaintext structure diagram before encryption in the method for suppressing jitter in a TCP protocol network tunnel, the plaintext format before encryption includes the message type Type, which is half a byte, i.e., 4 bits. When the Type value is 0x06, the message type is payload content payload; when the Type value is 0x07, the message type is heartbeat HB Echo; when the Type value is 0x08, the message type is heartbeat response HB Echo Reply; the message header Header is 1 half byte, i.e., 12 bits, of which 1 bit indicates whether the current data packet is FEC fragmented, and the remaining bits are filled with 0 to represent the reserved field; the data length Date Length is 2 bytes, i.e., 16 bits, which is the length of the data content; the data content is not fixed in length. If FEC is not enabled, the data content is a standard IP packet, i.e., the user IP length; if FEC is enabled, redundancy calculation is performed, and Reed is enabled. The Solomom algorithm shards the original data and calculates redundant shards based on the original shards. It encrypts each shard using the AES / SM4 encryption algorithm, re-encapsulates the sharded data, and sends it to the peer end.

[0155] Step A102: Determine the FEC (Forward Error Correction) code parameters based on the network quality and determine whether the FEC parameters need to be sliced; if the FEC parameters need to be sliced, split the encrypted data into several data slices according to the length of the encrypted data, generate redundant data slices according to the forward error correction algorithm, and symmetrically encrypt the encapsulated data slices; if FEC slicing is not required, directly symmetrically encrypt the encapsulated data; Figure 8 As shown in the structural diagram of FEC encapsulated data in the method for suppressing jitter in a TCP protocol network tunnel, the structure of the FEC-encapsulated data includes: a packet sequence (Packet Sequence) of 4 bytes, or 32 bits, used to identify the historical fragment number of the current data bit; a number of original fragments (Number of Original Fragments) of 1 byte, or 8 bits, representing the number of original fragments in the current group; a total number of fragments (1 byte, or 8 bits), representing the total number of fragments in the current group; and a number of redundant fragments = total number of fragments - number of original fragments. The current fragment sequence (Fragment Sequence) is 1 byte, or 8 bits, representing the sequence of the current fragment in the current group. The fragment data (FragmentSize) is 2 bytes, or 16 bits, indicating the standard length of each fragment. The original data payload length (OriginalPayloadLength) is 2 bytes, or 16 bits, representing the length of the original data restored from any original fragment of the current packet. The fragment content is of variable length and depends on the data length of the fragment.

[0156] The calculation of redundant shards includes the following steps:

[0157] Step B1: Read K IP packets from the virtual network card;

[0158] Step B2: Concatenate the K IP packets into a complete data segment in the following format: length of IP packet No. 1 (2 bytes) + content of IP packet No. 1 + length of IP packet No. 2 (2 bytes) + content of IP packet No. 2 + ... + length of IP packet No. K (2 bytes) + content of IP packet No. K;

[0159] Step B3: Split the entire data segment into K segments, i.e., K shards;

[0160] Step B4: Calculate N redundant fragments using the Reed Solomon algorithm; the total number of fragments of the current packet is K+N.

[0161] By setting up a redundancy algorithm, the original data can still be decrypted when the number of consecutive packet losses is less than or equal to N during network transmission. The theoretical packet loss resistance rate is calculated to be N / (K+N)*100%. There is no need for an ARQ-like mechanism for confirmation and response, and no increase in data transmission delay.

[0162] The original data restored from any original shard of the current group includes the following steps:

[0163] Step C1: accept the fragment, and the current group will temporarily store the fragment;

[0164] Step C2: When the number of any fragments in the current group is greater than or equal to K, the original data can be solved using the Reed Solomon algorithm.

[0165] Step A103: The sending end encapsulates TCP data packets and sends the TCP data packets one by one through the raw socket; the receiving end receives the TCP data packets through the raw socket;

[0166] Step A104: After receiving the TCP data packet, the receiving end decapsulates the TCP data packet and then decrypts the encapsulated data. It determines whether it is an FEC fragment based on the decrypted protocol parameters. If the decrypted protocol parameters are FEC fragments, the original data packet group is restored according to the forward error correction algorithm, and finally the original network card data packet is decapsulated. If the decrypted protocol parameters are not FEC fragments, the encapsulated data is directly decapsulated to obtain the original network card data packet and written into the tunnel network card data packet.

[0167] Step A11: The client initiates a TCP disconnect to the server based on the standard TCP four-way handshake, and the server ends the TCP communication.

[0168] By encapsulating, encrypting and transmitting IP data packets in the TCP protocol format, the TCP three-way handshake and four-way handshake mechanisms are retained, the confirmation response, retransmission mechanism and the corresponding complex congestion control algorithm are removed, and the FEC forward error correction code is used on the customized VPN protocol to achieve high-efficiency, high-reliability and low-latency jitter transmission of network data packets, and it has good adaptability to the Internet environment.

[0169] High security means that the parameter negotiation process is encrypted using asymmetric encryption algorithms, such as RSA and SM2, and network data packets are encapsulated, encrypted, and transmitted using symmetric encryption algorithms, such as AES and SM4. This ensures compliance with international and domestic requirements for secure transmission of network data packets.

[0170] Good adaptability to the Internet environment means that given the widespread use of the TCP protocol in other applications, it is less restricted by local network communication policies and traffic control, and has good adaptability to the network environment.

[0171] Low latency and jitter refers to avoiding the extra network round trip time in packet loss environments by removing the TCP protocol's acknowledgment and retransmission mechanisms and corresponding complex congestion control algorithms. This achieves low latency and jitter comparable to that of the UDP protocol.

[0172] High reliability means that by introducing FEC (Forward Error Correction Code) at the application layer, limited redundant calculation and group transmission of a group of network data packets can be achieved in a packet loss environment, thus achieving high reliability of data packet transmission.

[0173] The above embodiments are not limitations of the present invention, and the present invention is not limited to the above examples. Any changes, modifications, additions or substitutions made by technicians in this technical field within the scope of the technical solution of the present invention also fall within the scope of protection of the present invention.

Claims

1. A method for suppressing jitter in a TCP protocol network tunnel, characterized in that: The following steps are involved: Step S1: Deploy the virtual private network (VPN) protocol in a client / server architecture and install the server and client. Step S2: Using the TCP protocol, the client and the server are connected through a dial-up parameter negotiation process to encapsulate, encrypt and transmit data packets; Dial-up parameter negotiation connects the client and server, including the following steps: Step S21: The client initiates a TCP connection to the server based on the standard TCP three-way handshake mechanism; Step S22: The server accepts the new connection and establishes a connection with the client; Step S23: After the connection is established, the client and the server negotiate the Client ID; Step S24: After the client completes the verification, it sends the client RSA public key. The server records the client RSA public key and sends the server RSA public key. Step S25: The client records the server's RSA public key and sends the symmetric encryption algorithm. The server generates and encrypts the symmetric encryption key using RSA. Step S26: The server sends the RSA encrypted key to the client, and the client decrypts and records the symmetric encryption key; Step S27: The client sends error correction algorithm parameters, i.e., redundant parameters. The server records the error correction algorithm parameters and sends duplicate error correction algorithm parameters to the client. Step S28: The client verifies the error correction algorithm parameters replied by the server, sends a request after verification, and obtains an IP address message and sends it to the server; Step S29: The client and the server negotiate tunnel network parameters; the tunnel network parameters include the client tunnel IP address, subnet mask, and the server tunnel IP address; Step S210: The client creates a virtual network card for the local tunnel and starts the tunnel data transmission process to enable the forward error correction code (FEC) to perform data damage redundancy calculation to restore the original data and suppress jitter. Step S211: The client initiates a TCP disconnect to the server based on the standard TCP four-way handshake, and the server ends the TCP communication.

2. The method for suppressing jitter in a TCP protocol network tunnel according to claim 1, wherein: In step S23, the client ID negotiation is performed between the client and the server, including the following steps: Step S23-1: The client sends a Client ID message, the server processes the Client ID message, and initializes the data structure of the Client ID message; Step S23-2: The server sends a duplicate Client ID message, and the client verifies the Client ID message replied by the server; that is, it checks whether the Client ID message sent by the server is the value sent by the client before.

3. The method for suppressing jitter in a TCP protocol network tunnel according to claim 1, wherein: In step S26, the client decrypts and records the symmetric encryption key, including the following steps: Step S26-1: The client sends the encryption type requested by the client to the server; Step S26-2: The server generates a random string based on the encryption type requested by the client and uses the server's RSA private key to encrypt a 32-byte key, a 12-byte initialization vector, and 16 bytes of additional information; Step S26-3: The server sends the AES-GCM or SM4 encryption parameters encrypted by the server's RSA to the client; Step S26-4: The client uses the server's RSA public key to decrypt the key Key, the initial vector IV, and the additional information AAD.

4. The method for suppressing jitter in a TCP protocol network tunnel according to claim 1, wherein: In step S28, the client verifies the error correction algorithm parameters replied by the server, including the following steps: Step S28-1: The client sends redundant parameters to the server; Step S28-2: The server records redundant parameters; Step S28-3: The server sends a reply to the client to confirm the redundant parameters; Step S28-4: The client checks whether the redundant parameter sent by the server is the value that has been sent before.

5. The method for suppressing jitter in a TCP protocol network tunnel according to claim 1, wherein: In step S29, the client and the server negotiate tunnel network parameters, including the following steps: Step S29-1: The client sends a network parameter request instruction to the server; Step S29-2: The server allocates a tunnel IP address, subnet mask, and server tunnel IP address to the client, and encrypts the tunnel IP address, subnet mask, and server tunnel IP address based on the server RSA private key. Step S29-3: The server sends the encrypted tunnel network parameters to the client; Step S29-4: The client decrypts and records the client tunnel IP address, subnet mask and server tunnel IP address.

6. The method for suppressing jitter in a TCP protocol network tunnel according to claim 1, wherein: The tunnel data transmission process in step S210 uses a custom encapsulated TCP data packet and an interactive process to become 7xETP; the structure of 7xETP includes a TCP header, which occupies 20 bytes; 7xETP plaintext protocol header, occupies 8 bytes; 7xETP encrypted data, including the 7xETP ciphertext protocol header, occupies 4 bytes and the original IP packet data; the original IP packet data includes the 7xETP FEC parameters, occupies 11 bytes, and the FEC fragment has a variable length.

7. The method for suppressing jitter in a TCP protocol network tunnel according to claim 6, wherein: The tunnel data transmission process, in which the client and the server serve as the sending and receiving ends respectively, reads, encapsulates and transmits data, includes the following steps: Step S210-1: The sending end reads the tunnel network card data packet and encapsulates the data packet read from the tunnel network card; Step S210-2: Determine the FEC (Forward Error Correction) code parameters based on the network quality and determine whether the FEC parameters need to be sliced. If slicing is required, split the encrypted data into several data slices based on the length of the encrypted data, generate redundant data slices according to the forward error correction algorithm, and symmetrically encrypt the encapsulated data slices. If FEC slicing is not required, directly symmetrically encrypt the encapsulated data. Step S210-3: The sending end encapsulates TCP data packets and sends the TCP data packets one by one through the raw socket; the receiving end receives the TCP data packets through the raw socket; Step S210-4: After receiving the TCP data packet, the receiving end decapsulates the TCP data packet and then decrypts the encapsulated data. It determines whether it is an FEC fragment based on the decrypted protocol parameters. If the decrypted protocol parameters are FEC fragments, the original data packet group is restored according to the forward error correction algorithm, and finally decapsulated to obtain the original network card data packet. If the decrypted protocol parameters are not FEC fragments, the encapsulated data is directly decapsulated to obtain the original network card data packet and written into the tunnel network card data packet.

8. The method for suppressing jitter in a TCP protocol network tunnel according to claim 7, wherein: In step S210-1, after the sender reads data from the Linux virtual network card, the format of the data after encapsulation includes the magic number MagicWord, which is 2 bytes, i.e., 16 bits, fixedly set to "7x" to identify the characteristics of this protocol; the total length, i.e., the total length of the data sent at one time, which is 2 bytes, i.e., 16 bits; the local tunnel IP address, i.e., the local tunnel IP address, which is 4 bytes, i.e., 32 bits; the client tunnel IP address is obtained from the server during the negotiation process; the server tunnel IP address is specified in the configuration file; the ciphertext Ciphertext is larger than the total length but less than 8 bytes, i.e., 64 bits; the plaintext structure is encrypted using the encryption method negotiated between the client and the server, i.e., AES / SM4, and the key, initialization vector, and additional information in the encryption parameters; The plaintext format before encryption includes the message type (Type), which is half a byte or 4 bits; the message header (Header), which is one half byte or 12 bits, of which one bit indicates whether the current data packet is an FEC fragment, and the remaining bits are filled with 0 to represent a reserved field; the data length (Date Length), which is two bytes or 16 bits, is the length of the data content; the data content is variable length. If FEC is not enabled, the data content is a standard IP data packet, that is, the user IP length; if FEC is enabled and redundancy calculation is performed, the Reed Solomom algorithm is enabled to fragment the original data, and redundant data fragments are calculated based on the original fragments. Each fragment is encrypted using the AES / SM4 encryption algorithm, and the fragmented data is re-encapsulated and sent to the peer end.

9. The method for suppressing jitter in a TCP protocol network tunnel according to claim 8, wherein: After the FEC is enabled, the format of re-encapsulating the fragmented data includes: the packet sequence is 4 bytes, i.e., 42 bits, which is used to identify the historical fragment number of the current data bit; the original fragment number is 1 byte, i.e., 8 bits, which is the number of original fragments in the current group of fragments; the total number of fragments is 1 byte, i.e., 8 bits, which is the total number of fragments in the current group of fragments, and the number of redundant fragments = the total number of fragments - the number of original fragments; the current fragment sequence is 1 byte, i.e., 8 bits, which is the sequence of the current fragment in the current group of fragments; the fragment size is 2 bytes, i.e., 16 bits, which indicates the standard length of each fragment; the original data payload length is 2 bytes, i.e., 16 bits, which is equal to the original data length restored by any original fragment of the current group; the fragment content is of variable length and depends on the data length of the fragment.

10. The method for suppressing jitter in a TCP protocol network tunnel according to claim 9, characterized in that: Calculating the redundant data fragments includes the following steps: Step B1: Read K IP packets from the virtual network card; Step B2: Splice K IP packets into a whole segment of data; Step B3: Split the entire data segment into K segments, i.e., K shards; Step B4: Calculate N redundant fragments using the Reed Solomon algorithm; the total number of fragments of the current packet is K+N.

Images