CN117240474A - Data relay method, device, equipment and medium - Google Patents

Abstract

The application relates to a data relay method, a device, equipment and a medium, which are applied to a central coordination server, wherein the central coordination server is applied to data relay under a network address translation NAT scene, and the method comprises the following steps: establishing connection with a first client; responding to a handshake request message sent by a first client, and judging whether data in the handshake request message is tampered according to a hash code in the handshake request message; if not, determining available relay servers from the plurality of relay servers, and sending a handshake response message to the first client, wherein the handshake response message comprises an available relay server list; if yes, closing the connection with the first client. The application has the effect of improving the data relay safety in the NAT scene.

Description

Data relay method, device, equipment and medium

Technical Field

The present application relates to the field of communications technologies, and in particular, to a data relay method, apparatus, device, and medium.

Background

Network address translation (Network Address Translation, NAT) may translate private IP addresses to public IP addresses, enabling communication between an internal network and the public internet, however NAT has some limitations that make it difficult to access hosts in an intranet environment directly from the public internet.

The chinese patent document CN111800341a discloses a method for communicating with a cross-router terminal, and if a NAT router in an internal local area network does not support UPnP protocol and NATpmp protocol, the NAT router communicates with other communication nodes in an external public network under the ICE protocol frame through STUN protocol and TURN protocol, thereby implementing NAT penetration.

Chinese patent document CN104506666a discloses a method and a system for proxy traversing symmetric NAT by using TURN protocol, where proxy client and proxy server use TURN protocol to open the path traversing symmetric NAT, proxy client uses Socks5 protocol to converge TCP connection data packet, proxy client uses TURN protocol to forward data packet converged by Socks5 protocol to proxy server, proxy server processes data packet sent by proxy client, proxy server uses Socks5 protocol to diverge processed data packet to each TCP connection target, and proxy for TCP connection traversal is completed.

As can be seen from the foregoing, the data relay in the NAT scene can be realized by relaying the data flow by using the relay server through the NAT (Traversal Using Relay around NAT, TURN) protocol by the relay method. However, TURN protocols do not provide built-in encryption and security mechanisms, which can easily lead to security issues such as unauthorized access, data leakage, man-in-the-middle attacks, etc.

Disclosure of Invention

In order to improve the safety of data relay in NAT scene, the application provides a data relay method.

In a first aspect, the present application provides a data relay method, which adopts the following technical scheme:

a data relay method applied to a central coordination server, the central coordination server being applied to data relay in a network address translation NAT scene, the method comprising:

establishing connection with a first client;

responding to a handshake request message sent by the first client, and judging whether data in the handshake request message is tampered or not according to a hash code in the handshake request message;

if not, determining available relay servers from a plurality of relay servers, and sending a handshake response message to the first client; the handshake response message includes a list of available relay servers;

if yes, closing the connection with the first client.

By adopting the technical scheme, the central coordination server sends the handshake response message to the first client if judging that the data in the handshake request message is not tampered according to the hash code in the handshake request message sent by the first client, and closes the connection with the first client if judging that the data in the handshake request message is tampered, and can prevent the data leakage of the central coordination server by the way of hash code verification, thereby ensuring the safety of the data relay in the NAT scene.

Optionally, the central coordination server stores a whitelist including a plurality of IP addresses; the method further comprises the steps of:

and determining the IP address of the first client as the IP address in the white list.

By adopting the technical scheme, the central coordination server checks whether the IP address of the first client is the IP address in the white list, ensures the safety of the first client, only allows authorized clients to access resources, reduces the possibility of potential attacker invasion, and further improves the safety of data relay in the NAT scene.

Optionally, the method further comprises:

determining that the difference between the timestamp in the handshake request message and the local time is smaller than a preset time threshold; the local time is the current time of the central coordination server.

By adopting the technical scheme, the central coordination server determines that the time difference between the time stamp and the local time is smaller than the preset time threshold, so that an attacker can be prevented from transmitting a data packet received by the central coordination server to deceive the central coordination server, namely replay attack is prevented.

Optionally, after determining available relay servers from the plurality of relay servers, sending a handshake response message to the first client, the method further comprises:

Monitoring the state of the relay server in real time, and updating the list;

and synchronizing the updated list to the first client at preset time intervals.

By adopting the technical scheme, the central coordination server can monitor the states of all relay servers in real time, and update the available relay server list to the first client at regular time, so that the first client can know the available relay servers in time, and even if a certain relay server is not available, the first client can select other available relay servers to continue working, and communication interruption is avoided.

In a second aspect, the present application provides a data relay method, which adopts the following technical scheme:

a data relay method applied to a first client, the first client being applied to data relay in a network address translation NAT scenario, the method comprising:

establishing connection with a central coordination server;

sending a handshake request message to the central coordination server, so that the central coordination server responds to the handshake request message, and when judging that data in the handshake request message is not tampered according to a hash code in the handshake request message, determining available relay servers from a plurality of relay servers, and sending a handshake response message to the first client, or when judging that the data in the handshake request message is tampered according to the hash code in the handshake request message, closing the connection with the first client;

Receiving the handshake response message to obtain the available relay server list;

and selecting a target server according to the list, and carrying out data communication with a second client through the target server.

By adopting the technical scheme, when the central coordination server judges that the data in the handshake request message is not tampered, the central coordination server determines available relay servers from the plurality of relay servers, sends a handshake response message comprising an available relay server list to the first client, and the first client selects a target server according to the list and performs data communication with the second client through the target server. Under the condition that the target server fails, the first client can still select other available relay servers to perform data communication with the second client according to the list, and communication interruption is avoided. The distributed design of the central coordination server and the relay server group solves the problem that the common relay scheme is unavailable when single-point faults occur.

Optionally, before sending the handshake request message to the central coordination server, the method further includes:

generating a session identification for uniquely identifying the handshake request message;

Generating the hash code according to the session identifier and the timestamp; the time stamp is the generation time of the session identifier;

writing the session identification, the timestamp and the hash code into the handshake request message.

By adopting the technical scheme, the first client generates the hash code according to the unique session identifier and the time stamp, and writes the session identifier, the time stamp and the hash code into the handshake request message, so that the center coordinates to perform hash code verification, thereby effectively preventing data tampering and further improving the security of data relay in the NAT scene.

In a third aspect, the present application provides a data relay apparatus, which adopts the following technical scheme:

a data relay device provided in a central coordination server that is applied to data relay in a network address translation NAT scene, the device comprising:

a connection module for: establishing connection with a first client;

a verification module for: responding to a handshake request message sent by the first client, and judging whether data in the handshake request message is tampered or not according to a hash code in the handshake request message;

a sending module, configured to: when judging that the data in the handshake request message is not tampered, determining available relay servers from a plurality of relay servers, and sending a handshake response message to the first client; the handshake response message includes a list of available relay servers;

A closing module for: and closing the connection with the first client when judging that the data in the handshake request message is tampered.

In a fourth aspect, the present application provides a data relay apparatus, which adopts the following technical scheme:

a data relay device provided in a first client, the first client being applied to data relay in a network address translation NAT scenario, the device comprising:

a connection module for: establishing connection with a central coordination server;

a sending module, configured to: sending a handshake request message to the central coordination server, so that the central coordination server responds to the handshake request message sent by the first client, determines available relay servers from a plurality of relay servers when judging that data in the handshake request message is not tampered according to hash codes in the handshake request message, and sends a handshake response message to the first client, or closes connection with the first client when judging that the data in the handshake request message is tampered according to the hash codes in the handshake request message;

a receiving module for: receiving the handshake response message to obtain the available relay server list;

A processing module for: and selecting a target server according to the list, and carrying out data communication with a second client through the target server.

In a fifth aspect, the present application provides a computer device, which adopts the following technical scheme:

a computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the method of the first or second aspect when the program is executed.

In a sixth aspect, the present application provides a computer readable storage medium, which adopts the following technical scheme:

a computer readable storage medium storing a computer program capable of being loaded by a processor and executing the method according to any one of the first or second aspects.

Drawings

Fig. 1 is a block diagram of a distributed system according to an embodiment of the present application.

Fig. 2 is a schematic diagram of interaction between devices in a distributed system according to an embodiment of the present application.

Fig. 3 is a flowchart of a data relay method according to an embodiment of the present application.

Fig. 4 is a schematic diagram of a message body format of a handshake request message according to an embodiment of the present application.

Fig. 5 is a second flowchart of a data relay method according to an embodiment of the present application.

Fig. 6 is a flowchart of a verification performed by a central coordination server according to an embodiment of the present application.

Fig. 7 is a schematic format diagram of a protocol according to an embodiment of the present application.

Fig. 8 is a first block diagram of a data relay device according to an embodiment of the present application.

Fig. 9 is a second block diagram of a data relay device according to an embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be further described in detail with reference to the accompanying drawings 1 to 9 and examples. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application.

In the present internet age, with the popularization of networks and the continuous development of technologies, many organizations and individuals face a common challenge: NAT, NAT can make it difficult to access hosts in an intranet environment directly from the public internet. In order to solve this problem, many intranet penetration technologies have been developed, and data relay technologies have high stability and applicability and are widely used.

The existing standard relay protocol TURN has the following weak links: first, the TURN protocol itself does not provide built-in encryption and security mechanisms. Although the transmission of data may be protected by using an encrypted transport layer protocol over the TURN protocol, additional security measures are required to prevent unauthorized access, data leakage, or man-in-the-middle attacks, and thus ensuring the security, authentication, and access control of the relay server is a critical issue. Second, TURN protocols rely on relay servers to relay data streams, meaning that the reliability and stability of the system is directly dependent on the availability and performance of the relay servers. If the relay server fails, is overloaded or is inaccessible, a communication connection cannot be established, resulting in an outage or unavailability of the service. While TURN protocol design limits the lateral expansion capability of the server, resulting in reduced overall reliability of the relay service.

In view of this, the embodiment of the application discloses a data relay method, which is applied to a distributed system, wherein the distributed system is applied to data relay under NAT scene. Referring to fig. 1, a block diagram of a distributed system provided by an embodiment of the present application, or an application scenario diagram of a data relay method provided by an embodiment of the present application may be understood, and the distributed system is described below.

The distributed system comprises a central coordination server, a plurality of clients and a plurality of relay servers. The plurality of clients are in different networks, such as an intranet and the public internet. The plurality of relay servers are distributed at different geographic locations or data centers. In the NAT scenario, the central coordination server is communicatively connected to each relay server, and the central coordination server may verify whether the data sent by the client is tampered with, and send a list of available relay servers to the client. Clients in different networks may select available relay servers for data communication.

The client may be a mobile handset, a multimedia computer, a multimedia tablet, an internet node, a communicator, a desktop computer, a notebook computer, a tablet computer, a Personal Communication System (PCS) device, a positioning device or any combination thereof, including the accessories and peripherals of these devices or any combination thereof. The central coordination server and the relay server form a distributed server cluster, and can be an independent physical server, or can be a cloud server for providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs, basic cloud computing services such as big data and artificial intelligent platforms, but not limited to the cloud servers.

It should be noted that fig. 1 is an example in which a plurality of relay servers includes a relay server a, a relay server B, a relay server C, and a relay server D, but the number of relay servers is not limited in practice. Fig. 1 is an example in which a plurality of clients including a first client and a second client are taken as an example, but the number of clients is not limited in practice. The first client and the second client are respectively located in different networks, for example, the first client is a client in the public internet, the second client is a client in the internal network, or the first client is a client in the internal network, and the second client is a client in the public internet.

With the above description of the distributed system, please refer to fig. 2, which is a schematic diagram of interaction between devices in the distributed system according to an embodiment of the present application, the following description is made with reference to fig. 1 and fig. 2.

S201, the first client initiates connection to the central coordination server.

Specifically, the first client may initiate a normal transport layer security (Transport Layer Security, TLS)/transport control protocol (Transmission Control Protocol, TCP) connection to the central coordination server.

S202, the first client sends a handshake request message to the central coordination server.

Specifically, the handshake request Message includes a Message header (Message Head) and a DATA (DATA) portion, and after determining the content of the Message header and the DATA portion, the first client generates a handshake request Message and sends the handshake request Message to the central coordination server.

S203, the central coordination server executes verification.

Specifically, after the central coordination server receives the handshake request message, a check may be performed in various manners, for example, checking whether data in the handshake request message is tampered, checking an IP address of the first client, checking time information, and the like. If all the modes of verification pass, S204 is executed, and if any one of the modes of verification does not pass, the connection with the first client is closed, and the flow is ended. The process how the central coordination server performs the verification will be described below.

S204, the central coordination server sends a handshake response message to the first client.

Specifically, the central coordination server determines available relay servers from the plurality of relay servers, and sends a handshake response message to the first client, wherein the handshake response message comprises a list of available relay servers, and the list comprises an IP address, a physical address and a response speed of the relay servers.

S205, periodically updating the list.

Specifically, after sending the handshake response message to the first client, the central coordination server may also monitor the state of the relay server in real time, update the list, and synchronize the updated list to the first client every preset time period.

S206, the first client determines a target server.

Specifically, after receiving the handshake response message, the first client analyzes and obtains an available relay server list, and determines a target server according to the list. The method for determining the target server by the first client side includes a plurality of determination modes, and the following description is provided.

In the first mode, the first client determines the target server according to the physical address.

Specifically, the first client may use the relay server closest to the first client as the target server according to its own physical address and the physical address of each available relay server in the list.

And secondly, the first client determines the target server according to the response speed.

Specifically, the first client may use the relay server with the highest response speed as the target server according to the response speed of each available relay server in the list.

And thirdly, the first client determines the target server according to the physical address and the response speed.

Specifically, when there are a plurality of relay servers closest to each other, the first client uses the relay server having the highest response speed as the target server. Alternatively, when there are a plurality of relay servers having the highest response speed, the first client uses the relay server closest to the first client as the target server.

S207, the first client initiates connection to the target server.

Specifically, the first client may initiate a TLS/TCP connection to the target server.

S208, the first client sends the first data to the target server.

The first client transmits first data, which is intended to be transmitted to the second client, to the target server.

S209, the target server sends the first data to the second client.

And after receiving the first data sent by the first client, the target server forwards the first data to the second client.

S210, the second client sends second data to the target server.

After the second client receives the first data, based on the first data, second data are acquired, and the second data are sent to the target server. The second data is response data of the first data, for example, the first data is a data packet for requesting to access the page X, and the second data is a data packet of a specific resource of the page X.

S211, the target server sends second data to the first client.

And after receiving the second data sent by the second client, the target server forwards the second data to the first client.

The application also discloses a data relay method, which is applied to a first client of the distributed system, wherein the first client is applied to data relay in a NAT scene. Referring to fig. 3, a flowchart of a data relay method according to an embodiment of the present application is shown, and the data relay method executed by the first client is described below with reference to fig. 3.

S301, establishing connection with a central coordination server.

Specifically, the first client initiates a normal TLS/TCP connection to the central coordination server.

S302, sending a handshake request message to the central coordination server.

Specifically, how the first client generates the handshake request message is described in various ways below.

In the first mode, the first client generates a session identifier for uniquely identifying the handshake request message, generates a hash code according to the session identifier, and writes the session identifier and the hash code into the handshake request message.

Specifically, the first client may generate a unique session identifier, perform hash operation on the session identifier by using a hash algorithm and a key agreed by both parties, generate a hash code, and finally write the session identifier and the hash code into a data portion of the handshake request message.

In the second mode, the first client generates a session identifier for uniquely identifying the handshake request message, generates a hash code according to the session identifier and the timestamp, and writes the session identifier, the timestamp and the hash code into the handshake request message.

Specifically, the first client generates a unique session identifier, hashes the session identifier and a timestamp by using a hash algorithm and a key agreed by both parties, generates a hash code, the timestamp is the generation time of the session identifier, and finally writes the session identifier, the timestamp and the hash code into a data part of the handshake request message.

Among these, there are many hash algorithms, such as SHA256. The key is negotiated for both parties, defaults to exclusive or result of the source address of the message, e.g. the IP address of the first client, and the destination address of the message, e.g. the IP address of the second client.

The algorithm pseudocode is as follows:

Hash = sha256

SecretKey = Message.Src xor Message.Dst

Result = HMAC(Hash ,SecretKey ,Timestamp + UUID)

as can be seen from the algorithm pseudo code, the Hash (Hash) algorithm adopted by the first client is SHA256, the source address (message. Src) and the destination address (message. Dst) of the message are xored (xor) to obtain the key (SecretKey), and the session identifier (UUID) and the Timestamp (Timestamp) are hashed using SHA256 algorithm and the key (SecretKey) to obtain the Hash code (HMAC).

After determining the DATA (DATA) part of the handshake request Message, the first client adds a Message header (Message Head), generates the handshake request Message, and sends the handshake request Message to the central coordination server.

Referring to fig. 4, a schematic diagram of a message body format of a handshake request message according to an embodiment of the present application is shown. It can be seen that the handshake request Message includes a 72 byte Message header (Message Head) and 76 bytes of DATA (DATA), the DATA (DATA) portion including an 8 byte Timestamp (Timestamp), a 36 byte session identification (UUID), and a 32 byte hash code (HMAC).

S303, receiving the handshake response message to obtain an available relay server list.

Specifically, after the first client receives the handshake response message, the first client parses the handshake response message to obtain an available relay server list, where the content of the list refers to the content discussed above, and details are not repeated herein.

S304, determining a target server according to the list, and carrying out data communication with the second client through the target server.

Specifically, the process of how the first client determines the target server is referred to the content discussed above, and will not be described herein.

As described above, how the first client performs the data relay method provided by the embodiment of the present application. Referring to fig. 5, a second flowchart of a data relay method according to an embodiment of the present application is provided, where the method is applied to a central coordination server of a distributed system, and the central coordination server is applied to data relay in a NAT scene. The data relay method performed by the central coordination server is described below with reference to fig. 5.

S501, connection is established with a first client.

Specifically, after the first client initiates a normal TLS/TCP connection to the central coordination server, the central coordination server establishes a connection with the first client.

S502, responding to a handshake request message sent by a first client, and judging whether data in the handshake request message is tampered according to a hash code in the handshake request message.

Specifically, after receiving the handshake request message sent by the first client, the central coordination server performs hash operation on data in the handshake request message by using a hash algorithm and a key agreed by both parties to obtain a check value. If the check value is different from the hash code in the handshake request message, judging that the data in the handshake request message is tampered. If the check value is the same as the hash code in the handshake request message, judging that the data in the handshake request message is not tampered.

The method of obtaining the check value by the central coordination server is also various, and the method is described below.

For the first mode discussed above, the first client writes the session identifier and the hash code into the handshake request message, and then the central coordination server hashes the session identifier in the handshake request message by using the hash algorithm and the key agreed by both parties to obtain the check value.

For the second mode discussed above, the first client writes the session identifier, the timestamp and the hash code into the handshake request message, and the central coordination server uses the hash algorithm and the key agreed by both parties to perform hash operation on the session identifier and the timestamp in the handshake request message to obtain the check value.

If not, S503, determining available relay servers from the plurality of relay servers, and sending handshake response information to the first client.

Specifically, when the central coordination server judges that the data in the handshake request message is not tampered, an available relay server is determined from a plurality of relay servers, and a handshake response message is sent to the first client. The handshake response message includes a list of available relay servers, and the content of the list is referred to in the foregoing discussion, which is not repeated herein.

It should be noted that the handshake request message and the handshake response message have the same structure, except that the content of the DATA (DATA) part is different. The following is an example illustration.

Handshake request message (DATA packet DATA portion) sent by the first client:

Unit64(1690783251) 8c9d1a0c-df02-414c-8ad6-66352a48cc70 8c9d1a0cdf02414c8ad666352a48cc70

where Unit64 (1690783251) is a timestamp, 8c9d1a0c-df02-414c-8ad6-66352a48cc70 is a session identification, and 8c9d1a0cdf02414c8ad666352a48cc70 is a hash code.

Handshake response message (DATA packet DATA portion) sent by the central coordination server:

{

“code”:“0”，

“status”:“ok”，

“List”:[

{

“Addr”:“243.12.9.9:3480”，

“Location”:“shanghai”，

“Ping”:“23ms”，

},

{

“Addr”:“133.121.10.9:3481”，

“Location”:“guangzhou”，

“Ping”:“45ms”，

},

{

“Addr”:“122.1.222.93：7777”，

“Location”:“chengdu”，

“Ping”:“44ms”，

}

]

}

where "status" means that the verification was successful. The list returned by the central coordination server comprises 3 available relay servers, namely a relay server with an IP address of 243.12.9.9:3480, a physical address of Shanghai and a response speed of 23ms, a relay server with an IP address of 133.121.10.9:3481, a physical address of Guangzhou and a response speed of 45ms, and an IP address of 122.1.222.93:7777", physical address is" adult ", and response speed is" 44ms ".

S504, if yes, closing the connection with the first client.

Specifically, if the central coordination server determines that the data in the handshake request message is tampered, the connection with the first client is closed, and the handshake request message is discarded.

In one possible embodiment, the central coordination server stores a whitelist including a plurality of IP addresses, i.e., an access control list (Access Control List, ACL), and the central coordination server can determine the IP address of the first client as the IP address in the whitelist to ensure that legitimate clients access the resource. If the central coordination server determines that the IP address of the first client is not the IP address in the white list, S504 is directly performed, i.e. the connection with the first client is closed.

In the embodiment of the application, the ACL white list design is used, so that the safety is further enhanced, and the following advantages are achieved:

1. forced access control: the whitelist ACL allows only certain legitimate entities (users, IP addresses, etc.) to access the resource, everything else being denied, such mandatory access control ensuring that unauthorized entities cannot access the restricted resource.

2. And (3) reducing the attack surface: by only allowing access by pre-authorized entities, the whitelist ACL can greatly reduce the attack surface of the system and reduce the possibility of a potential attacker invading the system.

3. Preventing unknown threats: whitelist ACLs provide a degree of protection against unknown threats. It not only limits known malicious entities, but also prevents unknown malicious behavior, because entities that are not on the white list cannot access the resource.

4. And (3) accurate control: the whitelist ACL allows fine-grained control that helps ensure that resources are only accessible to authorized users or services, thereby avoiding data leakage or corruption.

5. Easy audit and monitoring: the configuration of the whitelist ACL is relatively fixed, which makes auditing and monitoring easier. An administrator may keep track of which entities have accessed resources to better understand network traffic and security events.

In one possible embodiment, the central coordination server may determine that the difference between the timestamp in the handshake request message and the local time is less than a preset time threshold. The local time is the current time of the central coordination server, and the preset time threshold is 30 seconds, for example. If the difference between the timestamp in the handshake request message and the local time is greater than or equal to the preset time threshold, S504 is directly executed, i.e. the connection with the first client is closed.

It should be noted that the order of checking the data tampered with, checking the IP address of the client, checking the time stamp by the central coordination server is exchangeable. Referring to fig. 6, a flowchart of a verification performed by a central coordination server according to an embodiment of the present application is shown. The process of performing a check on the central coordination server is described in detail below in connection with fig. 6.

First, verification is started, and S601 is executed.

S601, checking whether the IP address of the client is the IP address in the white list.

If the central coordination server determines that the IP address of the client is the IP address in the white list, S602 is executed, and if the central coordination server determines that the IP address of the client is not the IP address in the white list, S604 is directly executed.

S602, checking whether the time stamp of the data packet is within 30S.

If the central coordination server determines that the difference between the time stamp in the handshake request message and the local time is less than 30S, S603 is performed, and if the central coordination server determines that the difference between the time stamp in the handshake request message and the local time is greater than or equal to 30S, S604 is performed.

S603, checking whether the HMAC value is correct.

If the verification value calculated by the central coordination server is different from the hash code, S604 is executed, and if the verification value calculated by the central coordination server is the same as the hash code, the verification is passed, and the verification is ended. The process of calculating the check value is referred to in the foregoing discussion, and will not be described herein.

S604, closing the connection.

The central coordination server closes the connection with the first client and discards the handshake request message. .

It should be noted that the order of S601, S602, S603 in fig. 6 is interchangeable.

In one possible embodiment, after determining available relay servers from the plurality of relay servers and sending the handshake response message to the first client, the central coordination server may further monitor the status of the relay servers in real time, update the list, and synchronize the updated list to the first client every preset time period. In an extreme case, even if the central coordination server fails, the first client can complete data relay work for a period of time through the relay servers in the list according to the list acquired for the first time, so as to strive for time for the failure recovery of the central coordination server.

It should be noted that the central coordination server processes the handshake request message only when the connection is opened, and if the first client continues to send the handshake request message to the central coordination server, the central coordination server will not report errors or respond at all by default.

In one possible embodiment, the central coordination server may save and synchronize information of the first client, such as the physical address, IP address, etc., of the first client with all relay servers. Even if a relay server is down due to network or other reasons and becomes in an unavailable state, other relay servers in the cluster can take over the unavailable relay server to finish data relay work. For example, if the client does not receive the data transferred by the relay server a within the preset time, it is determined that the relay server a is not available, and then the relay server B is selected from the list to replace the work of the relay server a.

In one possible embodiment, the DATA exchange is performed between the client and the server using the protocol format (SEND & DATA) provided by the present application. The data exchange method of the protocol uses a data packet format different from the standard relay protocol (TURN) based on TLS/TCP and using TCP as a carrier. Fig. 7 is a schematic diagram of a protocol format according to an embodiment of the present application.

It can be seen that the packet structure of the protocol consists of a number of fields including a fixed identification, version, length, type, checksum, peer key, length, source address, destination address and data fields. Each field carries specific information and plays a critical role in the parsing and processing of the protocol. The meaning of each field is described in turn below.

(1) Fixed head (4 bits): here hexadecimal 0x0b.

(2) Version number (4 bits): for supporting the upgrading and evolution of protocols.

(3) Length (2 bytes): the length of the data fields in the data packet is expressed by using a big-end byte order so as to ensure consistency on different platforms.

(4) Type (1 byte): the method is used for identifying the type of the data packet and facilitating proper processing and analysis at a receiving end. The following are specific type definitions:

RequestType Code Desc

keep the connection between customer end and server in keep the blank data packet of keep alive 0

Ping 1 Ping server or other Peer

Pong 2 Pong is response to Ping

Send 3 requests the server to forward data

Data 4 server push Data

Health 5 query server state

Status 6 Health response

Log 7 pushes logs to be collected to a central server

Handshake 8 Handshake packet type

(5) Checksum (4 bytes): for verifying the integrity of the data packets to ensure that the data is not tampered with or damaged during transmission. The receiving end can verify the integrity of the data by calculating the checksum of the data field and including it in the data packet. The specific algorithm comprises the following steps:

s1, data segmentation: the data is partitioned into blocks of 16 bits (2 bytes) (if the data length is not an integer multiple of 16 bits, the last block is filled with 0).

S2, summation: the 16 bit values of all blocks are added to get an accumulated sum.

S3, inverting: the accumulated sum is bit-wise inverted (i.e., 0 becomes 1 and 1 becomes 0).

S4, inserting a checksum: the inverted 16 bytes are taken to the first 4 bytes and put into the checksum (SUM) field of the header.

(6) Source address and destination address (32 bytes each): for identifying the source of the data packet and informing the relay server of the destination that should be forwarded.

(7) DATA (DATA) (variable length): and the data is specifically forwarded. Such as the data portion in a handshake request message or the data portion of a handshake response message.

In summary, the present application proposes a new protocol for some drawbacks and limitations of TURN protocol, which not only effectively solves the problems of delay, bandwidth consumption, relay server dependency, deployment complexity, etc. of TURN protocol, but also enhances security and scalability. In terms of security, the application adopts a more reliable encryption and authentication mechanism to ensure confidentiality and integrity of data. By using advanced encryption algorithms, data leakage can be resisted, and enhanced authentication and access control mechanisms are introduced, allowing only authorized users and devices to access network resources.

Meanwhile, the application introduces a distributed relay server architecture, and the expandability and the stability of the system are enhanced. By distributing the relay servers in different geographic positions or data centers and adopting a dynamic server discovery and scheduling mechanism, load balancing and fault recovery are realized at the same time, and continuous communication service can be provided under the condition of server faults or network interruption.

The embodiment of the application also discloses a data relay device which is arranged in the central coordination server, and the central coordination server is applied to data relay under the network address translation NAT scene.

Referring to fig. 8, a data relay apparatus includes:

connection module 801 for: establishing connection with a first client;

a verification module 802 for: responding to a handshake request message sent by a first client, and judging whether data in the handshake request message is tampered according to a hash code in the handshake request message;

a sending module 803, configured to: when judging that the data in the handshake request message is not tampered, determining available relay servers from a plurality of relay servers, and sending a handshake response message to the first client, wherein the handshake response message comprises an available relay server list;

a closing module 804 for: and closing the connection with the first client when judging that the data in the handshake request message is tampered.

With continued reference to fig. 8, as another embodiment of a data relay device, a central coordination server stores a whitelist including a plurality of IP addresses; the verification module 802 is further configured to: and determining the IP address of the first client as the IP address in the white list.

With continued reference to fig. 8, as another embodiment of a data relay device, the verification module 802 is further configured to: determining that the difference between the timestamp in the handshake request message and the local time is smaller than a preset time threshold; the local time is the current time of the central coordination server.

With continued reference to fig. 8, as another embodiment of a data relay device, the device further includes a monitoring module 805;

the monitoring module 805 is configured to: after determining available relay servers from a plurality of relay servers and sending a handshake response message to a first client, monitoring the state of the relay servers in real time, and updating the list;

the sending module 803 is further configured to: and synchronizing the updated list to the first client at preset time intervals.

The embodiment of the application also discloses a data relay device which is arranged in the first client, and the first client is applied to data relay under the network address translation NAT scene.

Referring to fig. 9, a data relay apparatus includes:

a connection module 901 for: establishing connection with a central coordination server;

a sending module 902, configured to: sending a handshake request message to a central coordination server, so that the central coordination server responds to the handshake request message sent by a first client, judges that data in the handshake request message is not tampered according to a hash code in the handshake request message, determines available relay servers from a plurality of relay servers, sends a handshake response message to the first client, or judges that the data in the handshake request message is tampered according to the hash code in the handshake request message, and closes the connection with the first client;

A receiving module 903, configured to receive the handshake response message, and obtain an available relay server list;

and the processing module 904 is used for selecting a target server according to the list and carrying out data communication with the second client through the target server.

With continued reference to fig. 9, as another embodiment of a data relay device, the device further includes a generating module 905 and a writing module 906;

the generating module 905 is configured to: generating a session identification for uniquely identifying the handshake request message before sending the handshake request message to the central coordination server; generating a hash code according to the session identifier and the timestamp; the time stamp is the generation time of the session identifier;

the write module 906 is configured to: the session identification, timestamp and hash code are written into the handshake request message.

The data relay device of the embodiment of the application can realize any one of the methods of the data relay method, and the specific working process of each module in the data relay device can refer to the corresponding process in the embodiment of the method.

In several embodiments provided by the present application, it should be understood that the methods and systems provided may be implemented in other ways. For example, the system embodiments described above are merely illustrative; for example, a division of a module is merely a logical function division, and there may be another division manner in actual implementation, for example, multiple modules may be combined or may be integrated into another system, or some features may be omitted or not performed.

The embodiment of the application also discloses computer equipment.

Computer apparatus comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, the processor implementing a data relay method as described above when executing the computer program.

The embodiment of the application also discloses a computer readable storage medium.

A computer-readable storage medium storing a computer program that can be loaded by a processor and that performs any one of the data relay methods described above.

Wherein a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device; program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

In the foregoing embodiments, the descriptions of the embodiments are focused on, and for those portions of one embodiment that are not described in detail, reference may be made to the related descriptions of other embodiments.

The foregoing description of the preferred embodiments of the application is not intended to limit the scope of the application in any way, including the abstract and drawings, in which case any feature disclosed in this specification (including abstract and drawings) may be replaced by alternative features serving the same, equivalent purpose, unless expressly stated otherwise. That is, each feature is one example only of a generic series of equivalent or similar features, unless expressly stated otherwise.

Claims (10)

1. The data relay method is applied to a central coordination server, and is characterized in that the central coordination server is applied to data relay in a network address translation NAT scene, and the method comprises the following steps:

establishing connection with a first client;

responding to a handshake request message sent by the first client, and judging whether data in the handshake request message is tampered or not according to a hash code in the handshake request message;

if not, determining available relay servers from a plurality of relay servers, and sending a handshake response message to the first client; the handshake response message includes a list of available relay servers;

if yes, closing the connection with the first client.

2. The data relay method according to claim 1, wherein the center coordination server stores a whitelist including a plurality of IP addresses; the method further comprises the steps of:

and determining the IP address of the first client as the IP address in the white list.

3. The method of claim 1, further comprising:

determining that the difference between the timestamp in the handshake request message and the local time is smaller than a preset time threshold; the local time is the current time of the central coordination server.

4. A data relay method according to any of claims 1-3, wherein after determining available relay servers from a plurality of relay servers, sending a handshake response message to the first client, the method further comprises:

monitoring the state of the relay server in real time, and updating the list;

and synchronizing the updated list to the first client at preset time intervals.

5. A data relay method applied to a first client, wherein the first client is applied to data relay in a network address translation NAT scene, the method comprising:

establishing connection with a central coordination server;

sending a handshake request message to the central coordination server, so that the central coordination server responds to the handshake request message, and when judging that data in the handshake request message is not tampered according to a hash code in the handshake request message, determining available relay servers from a plurality of relay servers, and sending a handshake response message to the first client, or when judging that the data in the handshake request message is tampered according to the hash code in the handshake request message, closing the connection with the first client;

Receiving the handshake response message to obtain the available relay server list;

and determining a target server according to the list, and carrying out data communication with a second client through the target server.

6. The method of claim 5, wherein prior to sending a handshake request message to the central coordination server, the method further comprises:

generating a session identification for uniquely identifying the handshake request message;

generating the hash code according to the session identifier and the timestamp; the time stamp is the generation time of the session identifier;

writing the session identification, the timestamp and the hash code into the handshake request message.

7. A data relay device provided in a central coordination server, wherein the central coordination server is applied to data relay in a network address translation NAT scene, the device comprising:

a connection module for: establishing connection with a first client;

a verification module for: responding to a handshake request message sent by the first client, and judging whether data in the handshake request message is tampered or not according to a hash code in the handshake request message;

A sending module, configured to: when judging that the data in the handshake request message is not tampered, determining available relay servers from a plurality of relay servers, and sending a handshake response message to the first client; the handshake response message includes a list of available relay servers;

and the closing module is used for closing the connection with the first client when judging that the data in the handshake request message is tampered.

8. A data relay device disposed in a first client, wherein the first client is applied to data relay in a network address translation NAT scenario, the device comprising:

a connection module for: establishing connection with a central coordination server;

a sending module, configured to: sending a handshake request message to the central coordination server, so that the central coordination server responds to the handshake request message sent by the first client, judges that data in the handshake request message is not tampered according to a hash code in the handshake request message, determines available relay servers from a plurality of relay servers, sends a handshake response message to the first client, or judges that the data in the handshake request message is tampered according to the hash code in the handshake request message, and closes the connection with the first client;

A receiving module for: receiving the handshake response message to obtain the available relay server list;

and the processing module is used for selecting a target server according to the list and carrying out data communication with the second client through the target server.

9. A computer device, characterized by: comprising a memory and a server, said memory having stored thereon a computer program for loading and executing the method according to any of claims 1-4 or 5-6 by the server.

10. A computer readable storage medium, characterized in that a computer program is stored which can be loaded by a server and which performs the method according to any of claims 1-4 or 5-6.