A method, apparatus and device for establishing a communication connection

Abstract

This application provides a communication connection establishment method, apparatus, and device, applied in the field of communication technology. The method includes: a network device receiving a connection establishment request from a terminal device; performing a pre-embedded verification operation cyclically based on multiple network routing hop counts arranged in ascending order until a second penetration handshake message is received within a preset time period; in one pre-embedded verification operation, the network device sets the TTL value corresponding to the first penetration handshake message to the network routing hop count of the current cycle and sends the first penetration handshake message to the terminal device, and sends a pre-embedded verification request to the server; the server receives the pre-embedded verification request and sends a second penetration handshake message to the network device; the network device sends a connection establishment success response to the terminal device through the server. By verifying the accuracy of the pre-embedded points sequentially according to the TTL values ​​in ascending order, the success rate of establishing a penetration connection between the two devices is improved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method, apparatus and device for establishing a communication connection. Background Technology

[0002] P2P (Peer-to-Peer) traversal technology is primarily used to resolve end-to-end direct communication barriers caused by NAT (Network Address Translation) devices, enabling devices located in different internal network environments to establish connections directly without relying on relay servers. However, because the Conntrack (Connection Tracking) mechanism enforced by NAT devices requires the uniqueness of the 5-tuple, this characteristic can cause abnormal jumps in NAT port mappings when the timing of probe packets from both ends is interleaved due to network latency, leading to traversal failure.

[0003] The aforementioned problem is usually solved by port pre-embedding technology. Port pre-embedding technology actively detects and identifies the number of hops in the local network routing through the device. Based on the accurately measured hop count, it configures the TTL (Time To Live) of the traversal handshake message to ensure that the message is dropped after reaching the NAT at the other end, but generates the corresponding link's five-tuple information on the local NAT. This effectively avoids the risk of traversal failure caused by the uncontrollable timing of the two-end message interaction.

[0004] The core of port pre-embedding technology lies in accurately identifying the local network routing hop count. However, in actual network environments, the multi-WAN load balancing strategy and ECMP (Equal-Cost Multi-Path) routing mechanism of routing devices can cause changes in the transmission path of data packets. This multi-path transmission characteristic can cause deviations in the detected local routing hop count, resulting in inaccurate TTL configuration, which affects the implementation effect of port pre-embedding technology and causes the two-end devices to fail to establish a penetration connection. Summary of the Invention

[0005] This invention provides a communication connection establishment method, apparatus, and device to solve the problem that dual-end devices cannot successfully establish a penetration connection in multipath transmission scenarios in related technologies.

[0006] In a first aspect, embodiments of this application provide a communication connection establishment method, applied to a network device, the method comprising:

[0007] Receive connection establishment requests from terminal devices forwarded by the server;

[0008] Sort the network routing hop counts for each of the multiple transmission paths between the network device and the server in ascending order of numerical value;

[0009] The pre-embedded verification operation is executed cyclically according to the sorting result until the second penetration handshake message is received within the preset time. In one pre-embedded verification operation, the time-to-live (TTL) value corresponding to the first penetration handshake message is set to the network routing hop count of the current cycle. Then, the first penetration handshake message is sent to the terminal device, and a pre-embedded verification request is sent to the server. The pre-embedded verification request is used to instruct the server to send the second penetration handshake message to the network device.

[0010] The server sends a successful connection establishment response to the terminal device.

[0011] Secondly, embodiments of this application provide a communication connection establishment apparatus, applied to a network device, the apparatus comprising:

[0012] The receiving module is used to receive connection establishment requests from terminal devices forwarded by the server.

[0013] The sorting module is used to sort the network routing hop counts corresponding to multiple transmission paths between network devices and servers in ascending order of numerical value.

[0014] The first pre-embedded verification module is used to perform pre-embedded verification operations cyclically according to the sorting results until the second penetration handshake message is received within a preset time period. In one pre-embedded verification operation, after setting the Time-to-Live (TTL) value corresponding to the first penetration handshake message to the network routing hop count of the current cycle, the first penetration handshake message is sent to the terminal device, and a pre-embedded verification request is sent to the server. The pre-embedded verification request is used to instruct the server to send the second penetration handshake message to the network device.

[0015] The first sending module is used to send a connection establishment success response to the terminal device via the server.

[0016] Thirdly, embodiments of this application provide a network device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any step of the communication connection establishment method in the first aspect described above.

[0017] Fourthly, embodiments of this application provide a communication connection establishment method applied to a server, the method comprising:

[0018] Receive connection establishment requests sent by terminal devices and forward them to network devices;

[0019] The system receives a pre-embedded verification request sent by the network device during the pre-embedded verification operation and generates a second penetration handshake message. The pre-embedded verification operation is performed cyclically by the network device based on multiple network route hop counts arranged in ascending order. The multiple network route hop counts correspond to multiple transmission paths between the network device and the server. In each pre-embedded verification operation, the pre-embedded verification request is sent by the network device after setting the TTL value corresponding to the first penetration handshake message to the network route hop count of the current cycle and sending it to the terminal device.

[0020] Send a second penetration handshake message to the network device. The second penetration handshake message is used to: instruct the network device to terminate the pre-embedded verification operation when it receives the second penetration handshake message within a preset time period, and send a connection establishment success response.

[0021] Receive a connection establishment success response and forward it to the terminal device.

[0022] Fifthly, embodiments of this application provide a method for establishing a communication connection, applied to a server, the apparatus comprising:

[0023] The first forwarding module is used to receive connection establishment requests sent by terminal devices and forward the connection establishment requests to network devices;

[0024] The second pre-embedded verification module is used to receive the pre-embedded verification request sent by the network device when performing the pre-embedded verification operation, and generate the second penetration handshake message; the pre-embedded verification operation is performed by the network device in a loop based on multiple network route hop counts arranged in ascending order; the multiple network route hop counts correspond to multiple transmission paths between the network device and the server respectively; in each pre-embedded verification operation, the pre-embedded verification request is: the network device sets the TTL value corresponding to the first penetration handshake message to the network route hop count of the current loop and sends it to the terminal device;

[0025] The second sending module is used to send a second penetration handshake message to the network device. The second penetration handshake message is used to: instruct the network device to terminate the pre-embedded verification operation when it receives the second penetration handshake message within a preset time period, and send a connection establishment success response.

[0026] The second forwarding module is used to receive the connection establishment success response and forward it to the terminal device.

[0027] In a sixth aspect, embodiments of this application provide a server, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any step of the communication connection establishment method in the fourth aspect described above.

[0028] In a seventh aspect, embodiments of this application provide a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, implement any step of the above-described communication connection establishment method.

[0029] Eighthly, embodiments of this application provide a computer program product, including a computer program stored in a computer-readable storage medium; when a processor of a memory access device reads the computer program from the computer-readable storage medium, the processor executes the computer program, causing the memory access device to perform any step in the above-described communication connection establishment method.

[0030] Based on the communication connection establishment method provided in this application, this application has the following beneficial effects:

[0031] By detecting the network hop counts corresponding to multiple transmission paths between network devices and servers in a multi-path transmission environment, and working in conjunction with the server's platform-embedded verification service, the accuracy of each pre-embedded point is verified sequentially in ascending order of network hop count. This effectively avoids the failure of establishing a traversal connection between the two ends due to deviations in the detected hop counts, ensuring that the traversal handshake message is discarded after reaching the peer's egress NAT, but generates the corresponding link's five-tuple information on the local egress NAT, thereby improving the success rate of establishing a traversal connection between the two ends. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 This application provides a schematic diagram of the structure of a communication connection establishment system according to an embodiment of the present application.

[0034] Figure 2 A flowchart illustrating a communication connection establishment method provided in an embodiment of this application;

[0035] Figure 3 A schematic diagram illustrating the timing of STUN service interactions provided in an embodiment of this application;

[0036] Figure 4 A schematic diagram illustrating the overall service timing of a communication connection establishment method provided in an embodiment of this application;

[0037] Figure 5 A flowchart illustrating another communication connection establishment method provided in an embodiment of this application;

[0038] Figure 6 A schematic diagram illustrating the overall business process of a communication connection establishment method provided in this application embodiment;

[0039] Figure 7 A schematic diagram of a communication connection establishment device provided in an embodiment of this application;

[0040] Figure 8 A schematic diagram illustrating another communication connection establishment method provided in an embodiment of this application;

[0041] Figure 9 This is a schematic diagram of a device structure provided in an embodiment of this application. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will now be described in further detail with reference to the accompanying drawings.

[0043] The application scenarios described in this application are for the purpose of more clearly illustrating the technical solutions of this application, and do not constitute a limitation on the technical solutions provided in this application. Those skilled in the art will understand that with the emergence of new application scenarios, the technical solutions provided in this application are also applicable to similar technical problems. In the description of this application, unless otherwise stated, "multiple" means two or more.

[0044] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of this application.

[0045] To address the problem of NAT traversal failure caused by TTL value measurement deviation in multipath transmission environments in related technologies, this application provides a communication connection establishment method. This method uses TTL flow acquisition, TTL packet sorting, and platform pre-embedded verification mechanisms to ensure that the traversal handshake message sent by the network device is discarded after reaching the exit NAT of the terminal device, but the corresponding link's five-tuple information is generated on the local exit NAT, ensuring that the port pre-embedded technology can be correctly implemented, thereby improving the success rate of establishing traversal connections between the two devices.

[0046] Figure 1 This is a schematic diagram of a communication connection establishment system provided in an embodiment of this application. The method described in this embodiment can be applied to, for example... Figure 1 The system shown includes a platform server, terminal devices (i.e., the clients shown in the figure), network devices (i.e., the device ends shown in the figure), and NAT devices (i.e., NAT devices 1-4 shown in the figure).

[0047] Specifically, the aforementioned platform server includes STUN service, application service, signaling relay service, and pre-embedded verification service, which are responsible for signaling relay and data forwarding between the client and the device. Figure 1 The platform server shown forwards the request signaling sent by the client to the egress NAT device (i.e., NAT device 3) on the device side, and forwards the response signaling sent by the device side to the egress NAT device (i.e., NAT device 2) on the client side; it is also used to obtain the public network address (IP address) and port of the egress NAT device corresponding to the client and the device side respectively; at the same time, the platform server is also used to parse the TTL field value in the obtained STUN request message and send it back to the requester through STUN response.

[0048] The aforementioned NAT devices are used for data transmission translation and management between private networks and public networks (hereinafter referred to as public networks), including IP address translation, protocol port translation, and management of network address translation tables; such as Figure 1 The diagram illustrates how request signaling sent by the client over a private network is converted to a public network and sent to the platform server, and how response signaling sent by the platform server is converted to a private network and sent to the client.

[0049] The aforementioned client is used to obtain the public IP address and port of the egress NAT device from the STUN service in the platform server in real time, and to identify the NAT type on its side; and to exchange the NAT type, public IP address and port between the client and the device based on the signaling relay service of the platform server.

[0050] The aforementioned device is used to obtain the public IP address and port of the egress NAT device from the STUN service in the platform server in real time, and identify the NAT type on its own side; it exchanges the NAT type, public IP address and port of the client and device based on the signaling relay service of the platform server; and it probes the network routing hop count, i.e. the TTL value distribution characteristics, in a multi-path transmission environment through the STUN service in the platform server, and groups and sorts the probe results, and works in conjunction with the platform pre-embedded verification service in the platform server to verify the accuracy of each pre-embedded point in order of TTL value from smallest to largest, to ensure that the penetration handshake message is dropped after reaching the client's egress NAT device, but the corresponding link's five-tuple information is generated on the local egress NAT device.

[0051] It should be noted that the above Figure 1 The structure shown is only one possible example; in a specific implementation, the structure of the system can take other forms.

[0052] For ease of understanding, before describing in detail the communication connection establishment method provided in the embodiments of this application, the NAT traversal process under different NAT type combinations during the P2P connection establishment process is described in an ideal situation where uncontrollable timing is not considered:

[0053] 1. In a scenario where both the client and device correspond to cone NAT, i.e., a double cone NAT scenario, the client and device each create a single network socket and send a pass-through handshake message to the peer's public IP and port to complete the establishment of a P2P connection.

[0054] 2. In scenarios where one end of the client and device uses symmetric NAT and the other uses cone NAT, when the symmetric end sends a traversal handshake packet to the cone end, the target IP address changes. According to the principle of symmetry, the outgoing NAT device will reassign a new NAT port, causing the cone end to be rejected by the NAT device when sending packets to the old NAT port. Therefore, a birthday attack algorithm is needed for this NAT scenario. Its essence is to achieve the traversal process through the principle of random collision. The specific operation method is as follows:

[0055] The symmetrical end creates multiple network sockets and sends traverse handshake messages to the public IP address and port of the conical end. When these handshake messages leave the local NAT device, they are mapped to different public ports. The conical end randomly sends traverse handshake messages to different external ports of the other party to determine whether a target port matches the public port mapped by the symmetrical end. If they match, a connection can be successfully established.

[0056] The probability of this operation successfully penetrating is:

[0057] Where 64511 is the difference between the port limit of 65535 and the system default usage of 1024; M is the number of guesses for the public network port on the cone side (M penetration handshake messages); N is the number of ports mapped on the symmetrical end (N penetration handshake messages); in specific implementation, the values ​​of M and N can be set based on the required penetration success probability. For example, when M=2400 and N=200, the penetration success probability P is 99.94%.

[0058] 3. In scenarios where both the client and device correspond to symmetric NAT, i.e., double symmetric NAT, the success rate of random collisions is extremely low because the NAT ports of both sides are unpredictable and dynamically changing. Therefore, in this scenario, communication between the client and device is achieved through platform relay forwarding, and P2P connection establishment is no longer required.

[0059] Figure 2 A flowchart illustrating a communication connection establishment method for a network device provided in this application embodiment; as shown Figure 2 As shown, this application provides a communication connection establishment method, applied to a network device (i.e., the device side), including:

[0060] Step 201: Receive the connection establishment request from the terminal device forwarded by the server;

[0061] In some embodiments, before the network device receives the connection establishment request forwarded by the server (i.e., the platform server), i.e., before the P2P connection establishment process between the terminal device (i.e., the client) and the terminal device, it is necessary to determine the NAT network type corresponding to the terminal device, the NAT network type corresponding to the network device, and the network routing hop count corresponding to the multiple transmission paths between the network device and the server. It should be noted that the operation of determining the network routing hop count can be performed periodically or at regular intervals to ensure the accuracy of the network routing hop count.

[0062] Specifically, in a multipath transmission scenario, multiple STUN (Session Traversal Utilities for NAT) services are deployed on the platform server, each bound to a different port number. The process by which the terminal device determines its local NAT network type is as follows: the terminal device periodically sends STUN requests to each of the multiple STUN services on the platform server; each STUN service returns a STUN response upon receiving the request; the terminal device parses each STUN response and obtains its public IP address and port after passing through the egress NAT; if the public port numbers corresponding to the STUN responses returned by the multiple STUN services are consistent, the local egress NAT device is considered to be cone-shaped; if the public port numbers are inconsistent, the local NAT device is considered to be symmetrical.

[0063] As an optional implementation, the network routing hop count in this scenario is determined based on the following method:

[0064] The network device sends STUN requests to multiple STUN services in the server respectively; the TTL value corresponding to the STUN request is the initial value; the STUN request is used to: instruct the corresponding STUN service to obtain the target TTL value from the received STUN request, generate a STUN response based on the obtained target TTL value and send it to the network device;

[0065] The network device receives STUN responses from each STUN service, obtains the target value from each STUN response, and determines the network routing hop count corresponding to the STUN service based on the initial value and the target value.

[0066] It should be noted that by sending STUN requests to multiple STUN services on the platform server, network devices can simultaneously determine the local NAT network type and the network routing hop count for each of the multiple transmission paths.

[0067] Specifically, such as Figure 3 As shown, the network device periodically sends STUN requests to multiple STUN services (STUN service 1, STUN service 2 to STUN service n) on the platform server. During this process, the network device first creates a network socket and obtains its IP_TTL option content as the initial TTL value, that is, sets the TTL value corresponding to the STUN request to the initial value, and then sends STUN requests to the multiple STUN services on the platform server. It should be noted that in Linux systems, this initial value is typically 64, and in Windows systems, it is typically 128.

[0068] After receiving a STUN request and obtaining the TTL control content from the underlying auxiliary data, the STUN service in the platform server reads the actual TTL value (i.e., the target value) from the TTL control content and fills it into the STUN response. It then sends this STUN response to the network device. Since the TTL value corresponding to the STUN request changes with each hop it passes through (decreasing by 1 with each hop), the target value in the STUN request received by the STUN service can represent the network hop count of its corresponding transmission path. Therefore, the STUN service carries this target value in the returned STUN response, allowing the network device to determine the network hop count of the current transmission path based on this target value.

[0069] After receiving STUN responses from multiple STUN services, the network device parses each STUN response to obtain the public IP address and port of the STUN response after passing through the local egress NAT device, as well as the actual TTL value (i.e., the target value) of the request message when the STUN service receives the STUN request; and determines the local NAT network type based on the NAT port set returned by the server, and calculates the local network routing hop count based on the target TTL value returned by the server.

[0070] Specifically, when determining the local NAT network type, if the public network port numbers corresponding to the STUN responses returned by multiple STUN services are consistent, the local egress NAT device can be identified as cone-shaped. If the public network port numbers are inconsistent, the local NAT device is considered to be symmetrical.

[0071] When calculating the local network hop count, the network device parses the target TTL value from the STUN response and compares it with the cached initial value. Specifically, it subtracts the target value from the initial value to obtain the network hop count between the network device and the egress NAT device. In multipath transmission scenarios, the target values ​​carried in the STUN responses returned by multiple STUN services may differ, resulting in multiple calculated network hop counts. Therefore, the network device groups and sorts the obtained network hop counts, grouping each hop count as a single group and arranging them in ascending order.

[0072] The above method obtains the TTL target value of the request message when the platform server receives the STUN request from the STUN response, and calculates the network route hop count between the network device and the local egress NAT device based on the cached initial value. This avoids the problem that the gateway device cannot obtain the route hop count between the local communication device and the target NAT gateway through network segment detection technology due to the firewall policy configured on the gateway device.

[0073] It should be noted that in related technologies, most operators provide optical modem internet access services using cone NAT, while fiber-to-the-home, 4G (4th Generation Mobile Communication Technology) / 5G (5th Generation Mobile Communication Technology) networks, and public WIFI (wireless communication technology) typically use symmetrical NAT due to security factors. The difficulty of penetration varies depending on the combination of different NAT types, and can be divided into the following categories from most difficult to easiest: symmetrical (terminal device) and symmetrical (network device), symmetrical (terminal device) and cone (network device), or cone (terminal device) and symmetrical (network device), or cone (terminal device) and cone (network device). That is, when one or both sides of the terminal device and network device are cone NAT networks, port guessing is easier to hit and the penetration success rate is higher.

[0074] In some embodiments, when the terminal device sends a connection establishment request to the network device through the server, the connection establishment request carries the NAT network type, address information (i.e., public IP address) and port information (i.e., port number) of the terminal device.

[0075] As an optional implementation method, such as Figure 4 As shown, the network device receives a connection establishment request (i.e., ...) sent by the terminal device. Figure 4 After the P2P connection request shown, the server determines the NAT types of both ends and executes different port pre-embedding strategies. Specifically, it matches the subsequent port pre-embedding strategy based on the NAT network type of the terminal device and its own NAT network type. If neither the terminal device nor the network device has a cone-shaped NAT network type (i.e., in a dual-symmetric MAT traversal scenario), the success rate of random collisions is extremely low because both NAT ports are unpredictable and dynamically changing. Therefore, the server sends a connection establishment failure response to the terminal device. Figure 4 The P2P connection failure response shown indicates that the terminal device communicates with the network device through the platform server relay link, i.e., it uses the platform relay link.

[0076] If the NAT network types corresponding to the terminal device and the network device contain cone-shaped patterns, i.e., non-double symmetric MAT traversal scenarios, including: symmetric (terminal device) and symmetric (network device), symmetric (terminal device) and cone-shaped (network device), or cone-shaped (terminal device) and symmetric (network device), then traversal handshake messages are sent based on different pre-embedded strategies, i.e., the steps described in subsequent steps 202-204 are executed.

[0077] Step 202: Sort the network routing hop counts corresponding to the multiple transmission paths between the network device and the server in ascending order of numerical value;

[0078] In some embodiments, in a non-symmetric NAT traversal scenario, the network device first creates a single network socket and sends a STUN request to the STUN service in the platform server to obtain the public IP address and port. Then, based on the network device's periodic probe of the cached TTL packet data under multiple paths (i.e., the number of hops in multiple network routes), the accuracy of each pre-buried point is verified in ascending order.

[0079] Because when verifying the accuracy of each pre-buried point, if a larger TTL value is used first, the penetration handshake message may not be discarded after reaching the other end's NAT, resulting in timing interleaving problems and affecting the penetration success rate. Therefore, in this embodiment, the accuracy of each pre-buried point is verified in order of increasing TTL value.

[0080] It should be noted that the steps described in step 202 above can also be performed before step 201 above.

[0081] Step 203: Perform the pre-embedded verification operation in a loop according to the sorting results until the second penetration handshake message is received within the preset time period;

[0082] In one pre-embedded verification operation, after setting the Time-to-Live (TTL) value corresponding to the first penetration handshake message to the network routing hop count of the current cycle, the first penetration handshake message is sent to the terminal device, and a pre-embedded verification request is sent to the server. The pre-embedded verification request is used to instruct the server to send a second penetration handshake message to the network device.

[0083] like Figure 4 As shown, after the network device sends a pre-embedded verification request to the platform server, the platform server matches the corresponding NAT traversal algorithm and process according to the dual-end NAT type, and sends a simulated traversal handshake message (i.e., the second traversal handshake message mentioned above) to the network device through the raw socket based on different NAT traversal algorithms and processes. The process of matching the corresponding NAT traversal algorithm based on the dual-end NAT type can be found in the description of the NAT traversal process under different NAT type combinations during the P2P connection establishment process above. If the network device receives the platform simulated traversal handshake message (i.e., the second traversal handshake message mentioned above) within a preset time, it is determined that the pre-embedded verification is successful, and the platform server sends a connection establishment success response to the terminal device, i.e., the P2P connection establishment success response.

[0084] In some embodiments, the preset duration can be set based on requirements.

[0085] As an optional implementation, if the NAT network type corresponding to the terminal device is cone, and the NAT network type corresponding to the network device is also cone, then after setting the Time-to-Live (TTL) value of the first traverse handshake message to the network routing hop count of the current cycle, the first traverse handshake message is sent to the terminal device, including:

[0086] Set the TTL value of a network socket in the network device to the network route hop count for the current loop.

[0087] Based on the address information and port information, the target address and target port of a first penetration handshake message are determined, and a first penetration handshake message is sent to the terminal device through a network socket.

[0088] In practice, for the double-cone NAT traversal scenario, the network device sets the IP_TTL option of a single network socket IP layer to the number of network route hops in the current loop, and sends the first traversal handshake message to the client's public IP and port of the terminal device.

[0089] As an optional implementation, if the NAT network type corresponding to the terminal device is cone-shaped and the NAT network type corresponding to the network device is symmetrical, then after setting the Time-to-Live (TTL) value of the first traversal handshake message to the network routing hop count of the current loop, the first traversal handshake message is sent to the terminal device, including:

[0090] Set the TTL values ​​of N network sockets in the network device to the network routing hop count for the current loop; where N is an integer greater than 1.

[0091] Based on the address information and port information, the target address and target port of a first penetration handshake message are determined, and a first penetration handshake message is sent to the terminal device through N network sockets.

[0092] In specific implementation, for cone-shaped (client-side) and symmetrical (device-side) NAT traversal scenarios, the network device can reuse a previously created network socket and create N-1 network sockets. The IP_TTL option of the IP layer of the above N network sockets is set to the network routing hop count of the current cycle, and the first traversal handshake message is sent to the client's public IP and port of the terminal device through the N network sockets.

[0093] As an optional implementation, if the NAT network type corresponding to the terminal device is symmetric and the NAT network type corresponding to the network device is cone, then after setting the Time-to-Live (TTL) value of the first traversal handshake message to the network routing hop count of the current cycle, the first traversal handshake message is sent to the terminal device, including:

[0094] Set the TTL value of a network socket in the network device to the network route hop count for the current loop.

[0095] Based on the address information, determine the target addresses of M first penetration handshake messages, and randomly generate M target ports for the first penetration handshake messages; where M is an integer greater than 1;

[0096] M first pass-through handshake messages are sent to the terminal device through a network socket.

[0097] In specific implementation, for symmetrical (client-side) and cone-shaped (device-side) NAT traversal scenarios, the network device sets the IP_TTL option of the IP layer of the currently created single network socket to the network route hop count for the current loop, and sends traversal handshake messages to the client's M public IP addresses and ports on the terminal device. The client's public IP address remains unchanged, and the client's public port is selected from M random values ​​between 1024 and 65535, where 65535 is the upper limit of the port and 1024 is the port occupied by the system by default.

[0098] In some embodiments, when performing the pre-embedded verification operation in a loop according to the sorting result, if the network device does not receive the second penetration handshake message within a preset time after sending the pre-embedded verification request in the current loop, that is, the verification message reception timeout, it is indicated that the current port pre-embedded point is incorrect, and the next pre-embedded verification process needs to be executed. That is, based on the next network route hop number arranged in sequence, the first penetration handshake message is constructed and sent to the terminal device, and the pre-embedded verification request is sent again to the pre-embedded verification service of the platform server.

[0099] Step 204: The server sends a connection establishment success response to the terminal device.

[0100] Specifically, if the network device receives the platform's simulated penetration handshake message (i.e., the aforementioned second penetration handshake message) within a preset time period, it can be determined that the port pre-embedded point is correct and the pre-embedded verification is successful. At this time, the network device constructs a connection establishment success response and fills in the local NAT network type, public IP address, and port. It then sends a connection establishment success response to the terminal device through the platform server, i.e., a P2P connection establishment success response. Figure 4As shown; at this time, since the network device has generated the five-tuple information of multiple links at its egress NAT device, the client of the terminal device only needs to parse and obtain the NAT network type, public IP and port of the network device, and send the NAT traversal handshake message to the specified public IP and port of the network device according to the NAT traversal algorithm and process matched by the dual-end NAT type, execute the NAT traversal ICE (Interactive Connectivity Establishment) process, and establish a P2P connection, that is, to go through the end-to-end communication link.

[0101] As an optional implementation, if the pre-embedded verification operation is executed cyclically according to the sorting result, and the second penetration handshake message is not received within a preset time after the last pre-embedded verification operation, the server sends a connection establishment failure response to the terminal device.

[0102] Specifically, if the second penetration handshake message is not received within the preset time period after the last pre-embedded verification operation is performed according to the sorting result, i.e. Figure 4 When the network device receives the platform simulation penetration message and the TTL packet data (i.e., the number of hops in multiple network routes) times out and all verifications are completed, it is determined that the port pre-embedding verification has failed and that there are errors in the port pre-embedding points. The network device sends a connection establishment failure response, i.e., a P2P connection establishment failure response, to the terminal device through the platform signaling relay service in the server, informing the terminal device of the connection establishment failure processing result. The client of the terminal device then communicates with the network device through the platform relay forwarding link.

[0103] The above method detects the network hop counts corresponding to multiple transmission paths between network devices and servers in a multi-path transmission environment, and works in conjunction with the pre-embedded verification service on the server platform to verify the accuracy of each pre-embedded point in ascending order of network hop count. This effectively avoids the failure of establishing a traversal connection between the two ends due to deviations in the detected hop counts, and ensures that the traversal handshake message is discarded after reaching the NAT at the other end, but generates the corresponding link's five-tuple information on the local NAT, thereby improving the success rate of establishing a traversal connection between the two ends.

[0104] Figure 5 A flowchart illustrating a communication connection establishment method for a server provided in this application embodiment; as shown. Figure 5 As shown in the embodiments of this application, a method for establishing a communication connection is also provided, applied to a server, including:

[0105] Step 501: Receive the connection establishment request sent by the terminal device and forward the connection establishment request to the network device;

[0106] Step 502: Receive the pre-embedded verification request sent by the network device during the pre-embedded verification operation, and generate a second penetration handshake message; the pre-embedded verification operation is performed by the network device in a loop based on multiple network route hop counts arranged in ascending order; the multiple network route hop counts correspond to multiple transmission paths between the network device and the server respectively; in each pre-embedded verification operation, the pre-embedded verification request is: the network device sets the TTL value corresponding to the first penetration handshake message to the network route hop count of the current loop and sends it to the terminal device;

[0107] Step 503: Send a second penetration handshake message to the network device. The second penetration handshake message is used to: instruct the network device to terminate the pre-embedded verification operation when it receives the second penetration handshake message within a preset time period, and send a connection establishment success response.

[0108] Step 504: Receive the connection establishment success response and forward the connection establishment success response to the terminal device.

[0109] As an optional implementation, the server described above includes multiple STUN services; the network routing hop count is determined based on the following method:

[0110] The network device receives STUN requests from multiple STUN services. A STUN request is a request sent by the network device to multiple STUN services after setting the TTL value corresponding to the STUN request to the initial value.

[0111] For each STUN service, the target value of the current TTL is obtained from the received STUN request. Based on the obtained target value of the TTL, a STUN response is generated and sent to the network device. The STUN response is used to instruct the network device to determine the number of network route hops corresponding to the STUN service based on the target value and the initial value in the STUN response.

[0112] For details on the establishment of the communication connection on the server side, please refer to the descriptions corresponding to steps 201-204 above, which will not be repeated here.

[0113] Figure 6 This is a schematic diagram of the overall business process of a communication connection establishment method provided in an embodiment of this application, as shown below. Figure 6 As shown, the communication connection establishment process specifically includes:

[0114] Step 601: The client sends a P2P connection request;

[0115] The aforementioned client sends a P2P connection request to the device through the server's platform signaling relay service. The P2P connection request carries the local NAT type, public IP address, and port.

[0116] Step 602: The device receives the P2P connection request;

[0117] Step 603: The device determines whether the dual-end NAT network type is dual symmetric NAT; if yes, proceed to step 611; otherwise, proceed to step 604.

[0118] The pre-embedded verification operation described in steps 604-60 is executed cyclically in ascending order of network routing hop count;

[0119] Step 604: The device matches the port pre-embedded policy based on the dual-end NAT type and sends the first traverse handshake message to the client based on the matched port pre-embedded policy.

[0120] Specifically, when sending the first traversal handshake message, the TTL value of the first traversal handshake message is set to the network routing hop count for the current loop.

[0121] Step 605: The device sends a pre-embedded verification request to the server's pre-embedded verification service.

[0122] Step 606: The server matches the NAT traversal algorithm and process based on the dual-end NAT type.

[0123] Step 607: Based on the matching NAT traversal algorithm and process, the server sends a second traversal handshake message to the device through the raw socket;

[0124] Specifically, for a dual-cone NAT traversal scenario, the server needs to send a single second traversal handshake message through the raw socket. The source IP and port of the message are the public IP and port on the client side, and the destination IP and port of the message are the public IP and port on the device side. For cone (client) and symmetric (device) NAT traversal scenarios, the server needs to send M second traversal handshake messages through the raw socket. The source IP and port of the messages are the public IP and port on the client side, and the destination IP and port of the messages are the public IP and M random values ​​between 1024 and 65535 on the device side. For symmetric (client) and cone (device) NAT traversal scenarios, the server needs to send N simulated traversal handshake messages through the raw socket. The source IP and port of the messages are the public IP and N random values ​​between 1024 and 65535 on the client side, and the destination IP and port of the messages are the public IP and port on the device side.

[0125] Step 608: Check whether the device has received the second penetration handshake message within the preset time period; if yes, proceed to step 609; if no, return to step 604 or proceed to step 611.

[0126] Specifically, if the current operation is the last pre-embedded verification operation performed in a loop according to the sorting result, then step 611 is executed; otherwise, step 604 is executed.

[0127] Step 609: The device sends a P2P connection establishment success response to the client;

[0128] Step 610: Execute the NAT traversal ICE process to establish an end-to-end communication link;

[0129] Step 611: The device sends a P2P connection failure response to the client;

[0130] Step 612: Use the platform relay forwarding link.

[0131] Based on the same disclosed concept, this application also provides a communication connection establishment device. Since this device is the same as the device in the method of this application, and the principle of the device in solving the problem is similar to that of the method, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0132] Figure 7 Please refer to the schematic diagram of a communication connection establishment device provided in the embodiments of this application. Figure 7 This application provides a communication connection establishment apparatus, applied to a network device, the apparatus comprising:

[0133] The receiving module 701 is used to receive connection establishment requests from terminal devices forwarded by the server;

[0134] The sorting module 702 is used to sort the network routing hop counts corresponding to multiple transmission paths between network devices and servers in ascending order of numerical value;

[0135] The first pre-embedded verification module 703 is used to perform pre-embedded verification operations cyclically according to the sorting results until the second penetration handshake message is received within a preset time period. In one pre-embedded verification operation, after setting the Time-to-Live (TTL) value corresponding to the first penetration handshake message to the network routing hop count of the current cycle, the first penetration handshake message is sent to the terminal device, and a pre-embedded verification request is sent to the server. The pre-embedded verification request is used to instruct the server to send the second penetration handshake message to the network device.

[0136] The first sending module 704 is used to send a connection establishment success response to the terminal device through the server.

[0137] As an optional implementation, the network routing hop count described above is determined based on the following method:

[0138] The application STUN service sends STUN requests to multiple network address translation sessions in the server. The TTL value corresponding to the STUN request is the initial value. The STUN request is used to: instruct the corresponding STUN service to obtain the target TTL value from the received STUN request, generate a STUN response based on the obtained target TTL value and send it to the network device; receive the STUN responses sent by each STUN service, obtain the target value from each STUN response, and determine the network routing hop count corresponding to the STUN service based on the initial value and the target value.

[0139] As an optional implementation, the connection establishment request carries the Network Address Translation (NAT) network type corresponding to the terminal device; before the sorting module 702 sorts the network routing hop counts corresponding to multiple transmission paths between the network device and the server in ascending order, it is further used for:

[0140] Determine if a cone-shaped NAT exists in the NAT network type corresponding to both the terminal device and the network device; if no cone-shaped NAT exists in the NAT network type corresponding to either the terminal device or the network device, then send a connection establishment failure response to the terminal device through the server.

[0141] As an optional implementation, the connection establishment request also carries the address information and port information corresponding to the terminal device; if the NAT network type corresponding to the terminal device is cone, and the NAT network type corresponding to the network device is cone, then the aforementioned first pre-embedded verification module 703 is specifically used for:

[0142] Set the TTL value of a network socket in the network device to the network routing hop count for the current loop; determine the target address and target port of a first traverse handshake message based on address information and port information, and send a first traverse handshake message to the terminal device through a network socket.

[0143] As an optional implementation, the connection establishment request also carries the address information and port information corresponding to the terminal device; if the NAT network type corresponding to the terminal device is cone and the NAT network type corresponding to the network device is symmetric, then the aforementioned first pre-embedded verification module 703 is specifically used for:

[0144] Set the TTL values ​​of N network sockets in the network device to the network routing hop count for the current loop; where N is an integer greater than 1; determine the target address and target port of a first penetration handshake message based on address information and port information, and send a first penetration handshake message to the terminal device through N network sockets.

[0145] As an optional implementation, the connection establishment request also carries the address information corresponding to the terminal device; if the NAT network type corresponding to the terminal device is symmetric and the NAT network type corresponding to the network device is cone, then the aforementioned first pre-embedded verification module 703 is specifically used for:

[0146] Set the TTL value of a network socket in the network device to the network routing hop count for the current loop; determine the target addresses of M first penetration handshake messages based on the address information, and randomly generate the target ports of M first penetration handshake messages; where M is an integer greater than 1; send M first penetration handshake messages to the terminal device through a network socket.

[0147] As an optional implementation, the first sending module 704 is further configured to: if, when performing the pre-embedded verification operation in a loop according to the sorting result, the second penetration handshake message is not received within a preset time after the last pre-embedded verification operation, then the server sends a connection establishment failure response to the terminal device.

[0148] Figure 8 Please refer to the schematic diagram of another communication connection establishment device provided in the embodiments of this application. Figure 8 This application provides a communication connection establishment apparatus for use on a server. The apparatus includes:

[0149] The first forwarding module 801 is used to receive the connection establishment request sent by the terminal device and forward the connection establishment request to the network device;

[0150] The second pre-embedded verification module 802 is used to receive the pre-embedded verification request sent by the network device when performing the pre-embedded verification operation, and generate a second penetration handshake message; the pre-embedded verification operation is performed by the network device in a loop based on multiple network route hop counts arranged in ascending order; the multiple network route hop counts correspond to multiple transmission paths between the network device and the server respectively; in each pre-embedded verification operation, the pre-embedded verification request is: the network device sets the TTL value corresponding to the first penetration handshake message to the network route hop count of the current loop and sends it to the terminal device;

[0151] The second sending module 803 is used to send a second penetration handshake message to the network device. The second penetration handshake message is used to: instruct the network device to terminate the pre-embedded verification operation when it receives the second penetration handshake message within a preset time period, and send a connection establishment success response.

[0152] The second forwarding module 804 is used to receive the connection establishment success response and forward the connection establishment success response to the terminal device.

[0153] As an optional implementation, the server described above includes multiple STUN services; the network routing hop count is determined based on the following method:

[0154] The network device receives STUN requests from multiple STUN services. Each STUN request is sent by the network device to multiple STUN services after setting the TTL value corresponding to the STUN request to an initial value. Each STUN service retrieves the target TTL value from the received STUN request, generates a STUN response based on the retrieved target TTL value, and sends it to the network device. The STUN response is used to instruct the network device to determine the network routing hop count corresponding to the STUN service based on the target value and the initial value in the STUN response.

[0155] Based on the same disclosed concept, this application also provides an electronic device, which can be the aforementioned network device or server. Since this device is the same device in the method of this application, and the principle of solving the problem by this device is similar to that of this method, the implementation of this device can refer to the implementation of the method, and the repeated parts will not be described again.

[0156] Those skilled in the art will understand that various aspects of this application can be implemented as a system, method, or program product. Therefore, various aspects of this application can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, collectively referred to herein as a "circuit," "module," or "system."

[0157] In some possible implementations, the device according to this application may include at least one processor and at least one memory. The memory stores program code that, when executed by the processor, causes the processor to perform the steps in the communication connection establishment method according to the various exemplary embodiments of this application described above.

[0158] The following reference Figure 9 To describe the device 900 according to this embodiment of the present application. Figure 9 The device 900 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0159] like Figure 9As shown, device 900 is presented in the form of a general-purpose device. The components of device 900 may include, but are not limited to: at least one processor 901, at least one memory 902, and a bus 903 connecting different system components (including memory 902 and processor 901). The memory stores program code, which, when executed by the processor, causes the processor to execute the communication connection establishment method described above.

[0160] Bus 903 represents one or more of several bus architectures, including a memory bus or memory controller, peripheral bus, processor, or local bus using any of the various bus architectures. Memory 902 may include readable media in the form of volatile memory, such as random access memory (RAM) 9021 and / or cache memory 9022, and may further include read-only memory (ROM) 9023. Memory 902 may also include a program / utility 9025 having a set (at least one) of program modules 9024, including but not limited to: an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment.

[0161] Device 900 can also communicate with one or more external devices 904 (e.g., keyboard, pointing device, etc.), and with one or more devices that enable a user to interact with device 900, and / or with any device that enables device 900 to communicate with one or more other devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 905. Furthermore, device 900 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 906. As shown, network adapter 906 communicates with other modules used with device 900 via bus 903. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with device 900, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0162] In some possible implementations, various aspects of the communication connection establishment method provided in this application can also be implemented in the form of a program product, which includes program code. When the program product is run on a computer device, the program code is used to cause the computer device to perform the steps in the communication connection establishment method according to the various exemplary embodiments of this application described above.

[0163] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0164] The monitoring program product of the embodiments of this application can be a portable compact disc read-only memory (CD-ROM) and include program code, and can run on a device. However, the program product of this application is not limited to this. In this document, the readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0165] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying readable program code. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0166] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0167] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user device, partially on the user device, as a standalone software package, partially on the user device and partially on a remote device, or entirely on a remote device or server. In cases involving remote devices, the remote device can be connected to the user device via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external device (e.g., via the Internet using an Internet service provider).

[0168] It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

[0169] Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0170] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0171] This application is described with reference to flowchart illustrations and block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block and / or block in the flowchart illustrations and block diagrams, as well as combinations of blocks and processes in the flowchart illustrations and block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the process. Figure 1 One or more processes and boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0172] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and boxes Figure 1 The function specified in one or more boxes.

[0173] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and boxes Figure 1 The steps of the function specified in one or more boxes.

[0174] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0175] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for establishing a communication connection, applied to a network device, characterized in that, The method includes: Receive connection establishment requests from terminal devices forwarded by the server; Sort the network routing hop counts corresponding to the multiple transmission paths between the network device and the server in ascending order of numerical value; The pre-embedded verification operation is executed cyclically according to the sorting result until the second penetration handshake message is received within a preset time period. In one pre-embedded verification operation, the time-to-live (TTL) value corresponding to the first penetration handshake message is set to the network routing hop count of the current cycle, the first penetration handshake message is sent to the terminal device, and a pre-embedded verification request is sent to the server. The pre-embedded verification request is used to instruct the server to send the second penetration handshake message to the network device. The server sends a connection establishment success response to the terminal device. Specifically, when the server generates the second penetration handshake message, the source IP and source port of the second penetration handshake message are set to the public IP and public port of the client side corresponding to the terminal device, and sent to the network device through the raw socket.

2. The method according to claim 1, characterized in that, The network routing hop count is determined based on the following method: STUN requests are sent to multiple network address translation session traversal application STUN services in the server; the TTL value corresponding to the STUN request is an initial value; The STUN request is used to: instruct the corresponding STUN service to obtain the target TTL value from the received STUN request, generate a STUN response based on the obtained target TTL value, and send it to the network device; Receive STUN responses sent by each STUN service, obtain the target value from each STUN response, and determine the network routing hop count corresponding to the STUN service based on the initial value and the target value.

3. The method according to claim 1 or 2, characterized in that, The connection establishment request carries the Network Address Translation (NAT) network type corresponding to the terminal device; before sorting the network routing hop counts corresponding to the multiple transmission paths between the network device and the server in ascending order of numerical value, the method further includes: It was determined that a cone-shaped NAT network exists in the NAT network types corresponding to the terminal device and the network device, respectively. If the NAT network type corresponding to the terminal device and the network device does not include a cone shape, the method further includes: The server sends a connection establishment failure response to the terminal device.

4. The method according to claim 3, characterized in that, The connection establishment request also carries the address information and port information corresponding to the terminal device; if the NAT network type corresponding to the terminal device is cone, and the NAT network type corresponding to the network device is cone, then after setting the Time-to-Live (TTL) value corresponding to the first traverse handshake message to the network routing hop count of the current cycle, the first traverse handshake message is sent to the terminal device, including: Set the TTL value of a network socket in the network device to the network routing hop count for the current loop. Based on the address information and port information, the target address and target port of a first penetration handshake message are determined, and the first penetration handshake message is sent to the terminal device through the network socket.

5. The method according to claim 3, characterized in that, The connection establishment request also carries the address information and port information corresponding to the terminal device; if the NAT network type corresponding to the terminal device is cone and the NAT network type corresponding to the network device is symmetric, then after setting the Time-to-Live (TTL) value of the first traversal handshake message to the network routing hop count of the current cycle, the first traversal handshake message is sent to the terminal device, including: Set the TTL values ​​of N network sockets in the network device to the network routing hop count for the current loop; where N is an integer greater than 1. Based on the address information and port information, the target address and target port of a first penetration handshake message are determined, and the first penetration handshake message is sent to the terminal device through the N network sockets.

6. The method according to claim 3, characterized in that, The connection establishment request also carries the address information corresponding to the terminal device; if the NAT network type corresponding to the terminal device is symmetric and the NAT network type corresponding to the network device is cone, then after setting the Time-to-Live (TTL) value of the first traversal handshake message to the network routing hop count of the current cycle, sending the first traversal handshake message to the terminal device includes: Set the TTL value of a network socket in the network device to the network routing hop count for the current loop. Based on the address information, the target addresses of M first penetration handshake messages are determined, and the target ports of the M first penetration handshake messages are randomly generated; where M is an integer greater than 1. The M first pass-through handshake messages are sent to the terminal device through the network socket.

7. The method according to claim 1, characterized in that, The method further includes: If the pre-embedded verification operation is executed cyclically according to the sorting result, and the second penetration handshake message is not received within the preset time after the last pre-embedded verification operation, then the server sends a connection establishment failure response to the terminal device.

8. A method for establishing a communication connection, applied to a server, characterized in that, The method includes: Receive a connection establishment request sent by a terminal device and forward the connection establishment request to a network device; The system receives a pre-embedded verification request sent by the network device during the pre-embedded verification operation, and generates a second penetration handshake message. When generating the second penetration handshake message through the server, the source IP and source port of the second penetration handshake message are set to the public IP and public port of the client side corresponding to the terminal device. The pre-embedded verification operation is performed cyclically by the network device based on multiple network route hop counts arranged in ascending order. The multiple network route hop counts correspond to multiple transmission paths between the network device and the server. In each pre-embedded verification operation, the pre-embedded verification request is sent by the network device after setting the TTL value corresponding to the first penetration handshake message to the current cycle's network route hop count and sending it to the terminal device. The second penetration handshake message is sent to the network device via the original socket. The second penetration handshake message is used to: instruct the network device to terminate the pre-embedded verification operation when it receives the second penetration handshake message within a preset time period, and send a connection establishment success response. Receive the connection establishment success response and forward the connection establishment success response to the terminal device.

9. The method according to claim 8, characterized in that, The server includes multiple STUN services; the network routing hop count is determined based on the following method: The network device receives STUN requests from the network service through the multiple STUN services respectively; the STUN request is sent by the network device to the multiple STUN services after setting the TTL value corresponding to the STUN request to the initial value. For each STUN service, the target value of the current TTL is obtained from the received STUN request, and a STUN response is generated based on the obtained target value of the TTL and sent to the network device. The STUN response is used to instruct the network device to determine the number of network routing hops corresponding to the STUN service based on the target value and the initial value in the STUN response.

10. A communication connection establishment device, applied to network equipment, characterized in that, The device includes: The receiving module is used to receive connection establishment requests from terminal devices forwarded by the server. The sorting module is used to sort the network routing hop counts corresponding to multiple transmission paths between the network device and the server in ascending order of numerical value. The first pre-embedded verification module is used to perform pre-embedded verification operations cyclically according to the sorting results until a second penetration handshake message is received within a preset time period. In one pre-embedded verification operation, after setting the Time-to-Live (TTL) value corresponding to the first penetration handshake message to the network routing hop count of the current cycle, the first penetration handshake message is sent to the terminal device, and a pre-embedded verification request is sent to the server. The pre-embedded verification request is used to instruct the server to send the second penetration handshake message to the network device. When the server generates the second penetration handshake message, the source IP and source port of the second penetration handshake message are set to the public IP and public port of the client side corresponding to the terminal device, and it is sent to the network device via a raw socket. The first sending module is used to send a connection establishment success response to the terminal device through the server.

11. A communication connection establishment device, applied to a server, characterized in that, The device includes: The first forwarding module is used to receive a connection establishment request sent by the terminal device and forward the connection establishment request to the network device; The second pre-embedded verification module is used to receive the pre-embedded verification request sent by the network device when performing the pre-embedded verification operation, and generate a second penetration handshake message. When the server generates the second penetration handshake message, the source IP and source port of the second penetration handshake message are set to the public IP and public port of the client side corresponding to the terminal device. The pre-embedded verification operation is performed cyclically by the network device based on multiple network route hop counts arranged in ascending order. The multiple network route hop counts correspond to multiple transmission paths between the network device and the server. In each pre-embedded verification operation, the pre-embedded verification request is sent by the network device after setting the TTL value corresponding to the first penetration handshake message to the current loop's network route hop count and sending it to the terminal device. The second sending module is used to send the second penetration handshake message to the network device through the raw socket. The second penetration handshake message is used to: instruct the network device to terminate the pre-embedded verification operation when it receives the second penetration handshake message within a preset time period, and send a connection establishment success response. The second forwarding module is used to receive the connection establishment success response and forward the connection establishment success response to the terminal device.

12. A network device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 7.

13. A server, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of claim 8 or 9.

14. A computer storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 9.

Images