A peer-to-peer communication method, device and medium based on a QUIC protocol extension

Abstract

This invention discloses a peer-to-peer communication method, device, and medium based on the QUIC protocol extension, relating to the field of QUIC technology. The method includes: a first endpoint obtaining the address information of a second public network auxiliary node associated with a second endpoint; obtaining its own first public network address by sending an extended QUIC long header data packet with a STUN request flag set to the first public network auxiliary node; forwarding the first public network address to the second endpoint via the second public network auxiliary node using an extended QUIC long header data packet with a forwarding flag set to the first public network auxiliary node; simultaneously receiving the second public network address forwarded by the second endpoint via the first public network auxiliary node; and establishing an end-to-end direct connection by directly sending a hole-punching request frame based on the second public network address. This invention natively integrates network address translation (NAT) traversal and data relay functions within the QUIC protocol, eliminating the need for an additional independent auxiliary server, thus reducing system complexity and operational costs.

Description

Technical Field

[0001] This invention relates to the field of QUIC technology, and in particular to a peer-to-peer communication method, device and medium based on QUIC protocol extension. Background Technology

[0002] With the increasing demand for point-to-point communication, especially the emergence of direct collaboration scenarios between intelligent agents, transport layer protocols need to possess more flexible network penetration and autonomous interconnection capabilities. The QUIC protocol, as a next-generation UDP-based secure transport protocol, is primarily designed to serve communication modes between clients and servers, with its packet header structure and frame types revolving around reliable request-response interactions.

[0003] In existing technologies, the standard QUIC protocol does not define a detection mechanism for network address translation (NAT) traversal, nor can it carry the control information required for relay forwarding within the protocol stack. In actual deployments, when communication endpoints are located behind different NAT devices, QUIC connections must rely on external session traversal servers, relay servers, and signaling services for auxiliary connection establishment. This external functional dependency results in the protocol stack itself lacking closed-loop peer-to-peer communication capabilities, requiring the introduction of additional independent components at the deployment level for QUIC-based end-to-end direct connections. This increases system complexity and operational costs, and also makes it difficult to support fully decentralized peer-to-peer network operation. Summary of the Invention

[0004] This invention provides a peer-to-peer communication method, device, and medium based on the QUIC protocol extension. The technical problem it aims to solve is: how to provide a self-contained communication scheme that enables the QUIC protocol to natively integrate network address translation penetration and data relay functions.

[0005] In a first aspect, embodiments of the present invention provide a peer-to-peer communication method based on a QUIC protocol extension, comprising: In response to a connection request initiated by the first endpoint to the second endpoint, the first endpoint obtains the address information of the second public network auxiliary node associated with the second endpoint; The first endpoint constructs a first extended QUIC long header data packet and sends it to the first public network auxiliary node associated with the first endpoint. The unused bits in the header of the first extended QUIC long header data packet are set with a STUN request flag, and the payload carries a STUN binding request. The first public network auxiliary node extracts the source address information of the first endpoint based on the first extended QUIC long header data packet, constructs a second extended QUIC long header data packet, and returns it to the first endpoint. The unused bits in the header of the second extended QUIC long header data packet are set with a STUN response flag, and the payload carries a STUN binding response containing the source address information. The first endpoint parses the STUN binding response to obtain the first public IP address of the first endpoint after network address translation; The first endpoint constructs a third extended QUIC long header data packet and sends it to the second public network auxiliary node based on the address information of the second public network auxiliary node, so that the second public network auxiliary node forwards the candidate address information in the third extended QUIC long header data packet to the second endpoint. The header of the third extended QUIC long header data packet has a forwarding flag set in the unused bits, and the payload carries the candidate address information of the first endpoint containing the first public network address. The first endpoint receives a fourth extended QUIC long header data packet forwarded by the second endpoint through the first public network auxiliary node. The payload of the fourth extended QUIC long header data packet carries candidate address information of the second endpoint, including the second public network address of the second endpoint after network address translation. The first endpoint sends a QUIC data packet carrying a hole punching request frame directly to the second endpoint based on the second public network address, so as to establish a direct communication path with the second endpoint.

[0006] Optionally, the first endpoint obtains the address information of the second public network auxiliary node associated with the second endpoint, including: The first endpoint initiates a DNS resolution request to the Domain Name System for the domain name of the second endpoint; The first endpoint receives an extended resource record returned by the domain name system, the extended resource record containing at least one address information of a second public network auxiliary node associated with the address of the second endpoint.

[0007] Optionally, the first extended QUIC long header data packet, the second extended QUIC long header data packet, the third extended QUIC long header data packet, and the fourth extended QUIC long header data packet all adopt the header format of the QUIC version negotiation packet, and the unused bits in the header are the six unused fields in the QUIC version negotiation packet header; In the first extended QUIC long header data packet, the six-bit unused field includes a STUN flag bit set to a value indicating the STUN data packet type, and a STUN type flag bit set to a value indicating the STUN request type; In the second extended QUIC long header data packet, the six-bit unused field includes a STUN flag bit set to a value indicating the STUN data packet type, and a STUN type flag bit set to a value indicating the STUN response type; In the third extended QUIC long header data packet, the six-bit unused field contains a forwarding flag bit and is set to a value indicating the type of forwarded data packet; In the fourth extended QUIC long header data packet, the six-bit unused field contains a forwarding flag bit and is set to a value indicating the type of forwarded data packet; In the first extended QUIC long header data packet, the second extended QUIC long header data packet, the third extended QUIC long header data packet, and the fourth extended QUIC long header data packet, the six-bit unused field also includes a source endpoint network type flag bit, used to identify whether the source endpoint is a public network endpoint or an internal network endpoint; and a target endpoint network type flag bit, used to identify whether the target endpoint is a public network endpoint or an internal network endpoint.

[0008] Optionally, the first endpoint, based on the second public IP address, directly sends a QUIC data packet carrying a hole punching request frame to the second endpoint to establish a direct communication path with the second endpoint, including: The first endpoint constructs a PUNCH_HELLO frame and sends it directly to the second endpoint based on the second public network address. The PUNCH_HELLO frame contains a first sequence number corresponding to the local address of the first endpoint and a second sequence number corresponding to the second public network address. The PUNCH_HELLO frame is encapsulated in a QUIC data packet to bypass the QUIC reliable transmission control mechanism. The first endpoint receives the PUNCH_DONE frame returned directly by the second endpoint after receiving the PUNCH_HELLO frame. The PUNCH_DONE frame contains the address sequence number corresponding to the PUNCH_HELLO frame. The first endpoint confirms that the direct communication path with the second endpoint has been successfully established based on the received PUNCH_DONE frame.

[0009] Optionally, when there is at least one available network path between the first endpoint and the second endpoint, the first endpoint sends the third extended QUIC long header data packet to the second public network auxiliary node based on the address information of the second public network auxiliary node, including: the first endpoint sends the third extended QUIC long header data packet through the at least one available network path; The first endpoint directly sends a QUIC data packet carrying a hole punching request frame to the second endpoint, including: the first endpoint sending the QUIC data packet carrying the hole punching request frame through the at least one available network path; When a hole punching request is successful on any available network path, the first endpoint will prioritize establishing a direct communication path with the second endpoint through the network path where the hole punching was successful.

[0010] Optionally, when the direct communication path between the first endpoint and the second endpoint fails to be established, the method will fall back to the transmission path established via an auxiliary node. The method further includes: The first endpoint constructs a first extended QUIC short header data packet and sends it to any reachable node in the decentralized auxiliary node cluster. The reachable node forwards the first extended QUIC short header data packet to the second public network auxiliary node associated with the second endpoint based on the target address information. The second public network auxiliary node then delivers the application data to the second endpoint. The Spin Bit of the header of the first extended QUIC short header data packet is redefined as a forwarding flag bit and set to a first value. The payload carries the application data to be sent and the target address information of the second endpoint.

[0011] Optionally, the decentralized auxiliary node cluster is formed by multiple endpoints in the network that are publicly reachable through a distributed hash table, and all of the multiple endpoints run the QUIC protocol extension.

[0012] Optionally, during the connection request initiated by the first endpoint to the second endpoint and subsequent communication interactions, each instruction data sent by the first endpoint carries a digital signature generated using the private key of the first endpoint. The second endpoint authenticates the digital signature based on the domain name of the first endpoint and decides whether to respond to the instruction data according to a preset access policy based on domain name identity.

[0013] Secondly, embodiments of the present invention also provide a computer device, which includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0014] Thirdly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the above-described method.

[0015] This invention provides a peer-to-peer communication method, device, and medium based on a QUIC protocol extension. By reusing unused bits in the QUIC version negotiation header and setting STUN request, STUN response, and forwarding flags, the QUIC protocol stack itself possesses the ability to carry STUN binding requests and responses, as well as relay candidate address information through public network auxiliary nodes. The first and second endpoints complete public network address detection and bidirectional exchange of candidate addresses with the help of public network auxiliary nodes, and then directly send hole punching request frames based on the obtained public network addresses to establish an end-to-end direct connection. This scheme natively integrates network address translation traversal and data relay functions within the QUIC protocol, eliminating the need for additional deployment of independent STUN servers, signaling servers, or relay servers. It achieves self-containment of the protocol stack and a closed loop of peer-to-peer communication capabilities, reducing system complexity and maintenance costs. Attached Figure Description

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

[0017] Figure 1 A flowchart illustrating a peer-to-peer communication method based on a QUIC protocol extension provided in an embodiment of the present invention; Figure 2 A schematic block diagram of a computer device provided in an embodiment of the present invention; Figure 3 This is a schematic diagram illustrating the principle of communication between intranet endpoints and public network auxiliary nodes in an embodiment of the present invention. Figure 4 This is a schematic diagram of signaling interaction for STUN address probing by an endpoint through a public network auxiliary node in an embodiment of the present invention; Figure 5 This is a schematic diagram of signaling interaction between two intranet endpoints through their respective public network auxiliary nodes in an embodiment of the present invention. Figure 6 This is a schematic diagram of the data packet reception and processing logic of an endpoint running this extended QUIC protocol in an embodiment of the present invention; Figure 7 This is a schematic diagram illustrating the parallel network address translation traversal between two endpoints using multiple available network paths in an embodiment of the present invention; Figure 8 This is a schematic diagram illustrating data relay by a decentralized auxiliary node cluster in an embodiment of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" mean the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0020] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0021] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0022] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [the described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [the described condition or event] is detected," or "in response to detection of [the described condition or event]."

[0023] Please see Figure 1 This invention provides a peer-to-peer communication method based on QUIC protocol extensions. By extending the functionality of the unused bits in the long packet header of the standard QUIC protocol, the QUIC protocol stack itself possesses STUN request and response capabilities as well as packet relay forwarding capabilities, thereby achieving self-containment of the protocol stack and native support for peer-to-peer communication. Specifically, the method includes the following steps: S1, in response to the connection request initiated by the first endpoint to the second endpoint, the first endpoint obtains the address information of the second public network auxiliary node associated with the second endpoint.

[0024] In practice, in response to a connection request initiated by the first endpoint to the second endpoint, the first endpoint obtains the address information of the second public network auxiliary node associated with the second endpoint. The first endpoint refers to the party initiating the communication connection, such as a smart device or mobile terminal located within a home LAN, running a network communication module that supports the extended QUIC protocol. The second endpoint refers to the target device with which the first endpoint wishes to establish peer-to-peer communication.

[0025] Furthermore, connection requests can be triggered by applications on the first endpoint. For example, an agent program might need to call the application programming interface (API) on the second endpoint to obtain data or perform operations. Since neither the first nor the second endpoint typically possesses a fixed public Internet Protocol (IP) address, they cannot directly establish a Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) connection via IP addresses as in a traditional client-server model. Therefore, a public network auxiliary node is needed as a communication bridge in the initial stage. The second public network auxiliary node refers to a network node that has pre-established a keep-alive connection with the second endpoint and possesses public network reachability. Public network reachability means that the node has an IP address that can be directly accessed from the public network, or its network address translation device is of type FullCone, allowing any external host to initiate communication with the node through the mapped address and port.

[0026] Furthermore, the address information of the second public network auxiliary node includes the Internet Protocol address, port number, and optional auxiliary verification information such as node identifier or public key fingerprint, which are used to uniquely locate and verify the auxiliary node.

[0027] Furthermore, there are various ways for the first endpoint to obtain the address information, such as reading it through a pre-configured local configuration file, querying it through a distributed hash table network, or obtaining it through an extended domain name system resolution. This embodiment does not specifically limit this method.

[0028] In some preferred embodiments, the first endpoint obtaining the address information of the second public network auxiliary node associated with the second endpoint includes: the first endpoint initiating a resolution request for the domain name of the second endpoint to the domain name system; the first endpoint receiving an extended resource record returned by the domain name system, the extended resource record containing the address information of at least one second public network auxiliary node associated with the second endpoint.

[0029] In this specific implementation, this embodiment defines a new E record by extending the resource record types of the Domain Name System. This E record binds the address information of the public network auxiliary node to the domain name of the second endpoint in the form of a resource record, enabling the first endpoint to obtain this information through the standard domain name resolution process. The specific implementation method is as follows.

[0030] The Domain Name System (DNS) is a core service of the Internet, used to translate human-readable domain names into machine-routable Internet Protocol (IP) addresses. Standard DNS resource record types include A records for mapping IPv4 addresses, AAAA records for mapping IPv6 addresses, and TXT records for storing text information. However, these standard record types cannot directly carry the composite address information required by this scheme, including port numbers, protocol types, and auxiliary node identifiers. Therefore, this embodiment defines a new resource record type, denoted as the E record, where E stands for Endpoint, representing endpoint auxiliary information. Furthermore, the record data field of the E record uses a specific encoding format and can contain address information entries for one or more auxiliary nodes. Each address information entry includes the auxiliary node's IP address, port number, transport protocol type, priority weight, and optional node public key fingerprint fields.

[0031] In practice, the administrator of the second endpoint pre-configures E records on the authoritative name server of its domain name. For example, for the second endpoint with the domain name agent-b.ioa, its E record may contain the following information: the IPv4 address of auxiliary node 1 is 203.0.113.10, port 8443, protocol is UDP, and the public IP address mapped by the second endpoint to auxiliary node 1 is 106.52.222.34, port 34462; the IPv6 address of auxiliary node 2 is 2001:db8::1, port 8443, protocol is UDP, and the public IP address mapped by the second endpoint to auxiliary node 2 is 2408:8214:1234:5678::1, port 20348.

[0032] Furthermore, when the first endpoint needs to initiate a connection request to the second endpoint, the first endpoint first constructs a domain name resolution request packet. The query question portion of this packet specifies that the domain name to be resolved is the complete domain name of the second endpoint, the query type field is set to E to indicate the new allocation type number of the record, and the query class field is set to IN to indicate the Internet class. The first endpoint sends this request to the configured DNS recursive resolver through the operating system's DNS application programming interface or the built-in DNS client.

[0033] Upon receiving the request, the recursive resolver follows the standard DNS resolution process, querying downwards from the root name server until it reaches the authoritative name server responsible for the second endpoint domain. The authoritative name server retrieves the zone file corresponding to that domain, finds the pre-configured E record, encapsulates the E record's data in the DNS resolution response packet, and returns it to the first endpoint along the original path. If the second endpoint domain is configured with a DNS Security Extension (SSLE) signature, the response packet will also contain the corresponding digital signature record, allowing the first endpoint to verify the signature's validity to ensure the returned E record has not been tampered with.

[0034] Furthermore, after receiving the domain name resolution response data packet returned by the Domain Name System, the first endpoint parses the response portion and extracts the address information of one or more second public network auxiliary nodes contained in the E record. The first endpoint can cache this address information locally and select one or more auxiliary nodes for subsequent communication according to a preset selection strategy. The selection strategy can further include: probability selection based on priority weights, selecting the fastest responding node based on network latency measurement results, or using a round-robin approach to balance the load. If the first endpoint simultaneously obtains the address information of multiple second public network auxiliary nodes, when sending third extended QUIC long header data packets to the second public network auxiliary nodes in subsequent steps, copies can be sent to multiple auxiliary nodes simultaneously to improve the reliability and timeliness of message delivery.

[0035] Furthermore, it should be noted that the administrator of the second endpoint can dynamically update the content of the E-record based on the operational status of the auxiliary nodes. For example, when an auxiliary node goes offline for maintenance, the administrator removes the entry for that node from the E-record; when a new auxiliary node is added, the administrator adds the corresponding entry to the E-record. Because the Domain Name System (DNS) itself has a caching mechanism, record updates must wait for the cache lifetime to expire before they are perceived by all queryers. To balance update timeliness and query load, a shorter lifetime value can be set, such as sixty seconds or three hundred seconds. In addition, the first endpoint can also periodically refresh the DNS resolution results to ensure that the locally cached auxiliary node address information remains synchronized with the authoritative record.

[0036] This embodiment extends the resource record types of the Domain Name System (DNS) to define a dedicated E-record for carrying public network auxiliary node address information, and binds this record to the domain name of the second endpoint. The first endpoint only needs to initiate an E-record query request for the second endpoint's domain name to the DNS through the standard DNS resolution process to obtain the address information of one or more public network auxiliary nodes associated with the second endpoint. This approach fully utilizes the existing infrastructure of the DNS as a globally distributed database, eliminating the need for additional centralized signaling servers to manage and distribute auxiliary node addresses, reducing system complexity and improving scalability. Furthermore, since auxiliary node address information is stored using domain names as indexes, when auxiliary nodes change or scale down, only the E-record configuration in the DNS needs to be updated to automatically obtain the latest information from all potential communication initiators, without needing to notify each peer individually, thus achieving dynamic management and flexible switching of auxiliary node configurations. Furthermore, this scheme also organically integrates the endpoint's domain name identity with its network reachability information, providing a unified addressing layer foundation for end-to-end security authentication and access control based on domain name identity in subsequent embodiments.

[0037] S2, the first endpoint constructs a first extended QUIC long header data packet and sends it to the first public network auxiliary node associated with the first endpoint. The unused bits in the header of the first extended QUIC long header data packet are set with a STUN request flag, and the payload carries a STUN binding request.

[0038] In specific implementation, the first endpoint constructs a first extended QUIC long header data packet and sends it to the first public network auxiliary node associated with the first endpoint. The unused bits in the header of the first extended QUIC long header data packet contain a STUN request flag, and the payload carries a STUN binding request. The QUIC protocol is a next-generation transport layer protocol standardized by the Internet Engineering Task Force (IETF). Its full name is Quick UDP Internet Connections. This protocol operates in user space based on the User Datagram Protocol (UDP), integrates the encryption capabilities of transport layer security protocols, and features low latency, multiplexing, and connection migration.

[0039] Furthermore, in the QUIC protocol standard specification, the version negotiation packet is used to negotiate the protocol versions supported by both parties during the initial connection establishment. Its header contains a six-bit unused field, which the standard stipulates must be entirely zero. This embodiment extends the functionality of this unused field, giving it the semantics of carrying control signaling. The first public network auxiliary node is an auxiliary node that has a pre-established connection with the first endpoint and possesses public network reachability; its role is similar to that of a proxy for the first endpoint on the public network. The first endpoint first needs to know its own public network address information after network address translation, that is, the public Internet Protocol address and port mapping assigned to the first endpoint by the network address translation device.

[0040] To this end, the first endpoint constructs a QUIC packet using a version negotiation header format. In the six unused fields of this header, the STUN flag is set to a value indicating the STUN packet type, and the STUN type flag is set to a value indicating the STUN request type. STUN is an abbreviation for Session Traversal Utilities for NAT, a protocol that defines a set of message formats for detecting network address translation types and obtaining public network address mappings.

[0041] In the payload section, the first endpoint fills in a Binding Request message conforming to the standard STUN protocol specification. Subsequently, the first endpoint sends this data packet via a User Datagram Protocol (UDP) socket to the Internet Protocol (IP) address and port of the first public network auxiliary node.

[0042] S3, the first public network auxiliary node extracts the source address information of the first endpoint based on the first extended QUIC long header data packet, constructs a second extended QUIC long header data packet, and returns it to the first endpoint. The unused bits in the header of the second extended QUIC long header data packet are set with a STUN response flag, and the payload carries a STUN binding response containing the source address information.

[0043] In specific implementation, the first public network auxiliary node extracts the source address information of the first endpoint based on the first extended QUIC long header data packet, constructs a second extended QUIC long header data packet, and returns it to the first endpoint. The unused bits in the header of the second extended QUIC long header data packet are set with a STUN response flag, and the payload carries a STUN binding response containing the source address information.

[0044] After receiving the first extended QUIC long header data packet, the first public network auxiliary node first parses the six unused fields in the header and identifies that the data packet carries a STUN binding request based on the combination of the values ​​of the STUN flag and the STUN type flag.

[0045] Furthermore, the first public network auxiliary node extracts the source Internet Protocol address and source port number of the first endpoint from the header of the User Datagram Protocol (UDP) message received from the data packet. Since the data packet passed through the Network Address Translation (NAT) device of the network where the first endpoint resides during transmission, the source Internet Protocol address and port number have been modified by the NAT device to the public network address and port exposed by the NAT device. Therefore, the extracted address and port are the public network mapped address of the first endpoint after NAT translation.

[0046] Furthermore, the first public network auxiliary node then constructs a second extended QUIC long header packet as a response, which also adopts the header format of the version negotiation packet. In the six unused fields, the first public network auxiliary node sets the STUN flag to a value indicating the STUN packet type and sets the STUN type flag to a value indicating the STUN response type. In the payload, the first public network auxiliary node constructs a Binding Response message conforming to the standard STUN protocol specification, and fills the extracted public Internet Protocol address and port number of the first endpoint into the XOR-MAPPED-ADDRESS or MAPPED-ADDRESS attribute field of the response message.

[0047] Furthermore, the first public network auxiliary node returns the second extended QUIC long header data packet to the first endpoint via the User Datagram Protocol.

[0048] S4, the first endpoint parses the STUN binding response and obtains the first public IP address of the first endpoint after network address translation.

[0049] In practice, the first endpoint parses the STUN binding response to obtain its first public IP address after network address translation. Upon receiving the second extended QUIC long header data packet, the first endpoint parses the STUN binding response message in its payload and extracts its public Internet Protocol address and port number from the corresponding attribute fields. This address is the first public IP address, which is a unique routable identifier that allows external hosts to directly access the first endpoint in the current network environment.

[0050] Furthermore, the first endpoint saves the first public IP address to its local candidate address list as one of the alternative addresses for subsequent connectivity negotiation with the second endpoint.

[0051] Furthermore, it should be noted that the first endpoint may be connected to multiple network interfaces simultaneously, such as both a wireless LAN and a cellular data network. Each network interface may also support both IPv4 and IPv6 protocol stacks. In this case, the first endpoint can execute the aforementioned STUN probe procedure for each valid local address, thereby obtaining multiple different first public IP addresses. These addresses are all used as candidate addresses in subsequent address exchange and hole punching attempts.

[0052] S5, the first endpoint constructs a third extended QUIC long header data packet and sends it to the second public network auxiliary node based on the address information of the second public network auxiliary node, so that the second public network auxiliary node forwards the candidate address information in the third extended QUIC long header data packet to the second endpoint. The header of the third extended QUIC long header data packet has a forwarding flag set in the unused bits, and the payload carries the candidate address information of the first endpoint containing the first public network address.

[0053] In specific implementation, the first endpoint constructs a third extended QUIC long header data packet and sends it to the second public network auxiliary node based on the address information of the second public network auxiliary node, so that the second public network auxiliary node forwards the candidate address information in the third extended QUIC long header data packet to the second endpoint. The header of the third extended QUIC long header data packet has a forwarding flag set in the unused bits, and the payload carries the candidate address information of the first endpoint containing the first public network address.

[0054] Specifically, after the first endpoint obtains its own public IP address, it needs to inform the second endpoint of this address information so that both can attempt to establish a direct connection based on the other's public IP address. Since no direct communication channel has been established between the first and second endpoints at this time, especially when both are behind different network address translation devices, data packets sent directly by either side to the other cannot penetrate the other's network address translation device to reach the other end.

[0055] Therefore, the first endpoint completes the initial signaling exchange via an auxiliary node. The first endpoint constructs a third extended QUIC long header data packet, which adopts the header format of a version negotiation packet. In the six unused fields, the first endpoint sets the forwarding flag to a value indicating the type of forwarded data packet, instructing the receiver that the data packet needs to be relayed rather than processed locally. Further, in the payload, the first endpoint fills in its own candidate address information. This candidate address information includes at least the first public network address obtained in the aforementioned steps, and may also include the first endpoint's local intranet address, IPv6 address, and other available addresses.

[0056] Based on the address information of the second public network auxiliary node obtained in step S1, the first endpoint sends the third extended QUIC long header data packet to the second public network auxiliary node via the User Datagram Protocol (UDP). Further, upon receiving the data packet, the second public network auxiliary node parses the header to identify the forwarding flag and confirms that the data packet needs to be relayed.

[0057] Furthermore, the second public network auxiliary node, based on its internally maintained connection mapping table and having established a keep-alive channel with the second endpoint, forwards the data packet to the second endpoint through this channel. Correspondingly, upon receiving the forwarded data packet, the second endpoint extracts and saves the candidate address information of the first endpoint, just as it would when receiving a QUIC data packet in a normal manner.

[0058] S6, the first endpoint receives a fourth extended QUIC long header data packet forwarded by the second endpoint through the first public network auxiliary node. The payload of the fourth extended QUIC long header data packet carries candidate address information of the second endpoint, including the second public network address of the second endpoint after network address translation.

[0059] In a specific implementation, the first endpoint receives a fourth extended QUIC long header data packet forwarded by the second endpoint through the first public network auxiliary node. The payload of the fourth extended QUIC long header data packet carries candidate address information of the second endpoint, which includes the second public network address of the second endpoint after network address translation.

[0060] Specifically, corresponding to the operation of the first endpoint, after receiving the candidate address information from the first endpoint, the second endpoint also needs to inform the first endpoint of its own candidate address information. The second endpoint performs a STUN probe process similar to that of the first endpoint to obtain its own second public IP address after network address translation. Further, the second endpoint constructs a fourth extended QUIC long header data packet, in which the six unused bits of the header also contain a forwarding flag, and the payload carries the candidate address information of the second endpoint, including its second public IP address. Further, the second endpoint sends this data packet to the first public network auxiliary node, which forwards it to the first endpoint through its keep-alive connection with the first endpoint.

[0061] Furthermore, the first endpoint receives the fourth extended QUIC long header data packet, parses its payload, and extracts the candidate address information of the second endpoint from it. At this point, the first and second endpoints have completed bidirectional candidate address exchange through their respective public network auxiliary nodes, and both sides have obtained the reachable address of the other end on the public network.

[0062] S7, the first endpoint sends a QUIC data packet carrying a hole punching request frame directly to the second endpoint based on the second public network address, so as to establish a direct communication path with the second endpoint.

[0063] In practice, the first endpoint sends a QUIC data packet carrying a hole punching request frame directly to the second endpoint based on the second public network address, so as to establish a direct communication path with the second endpoint.

[0064] Specifically, the first endpoint selects a second public IP address from the received candidate address information of the second endpoint as the target address for hole punching. The first endpoint constructs one or more QUIC packets carrying hole punching request frames, sets the destination Internet Protocol address and port to the second public IP address, and sends them directly through a User Datagram Protocol socket.

[0065] A hole-punching request frame is a specially defined QUIC frame type designed to create a mapping rule on a network address translation device that allows bidirectional communication. The transmission of this frame is not constrained by the reliable transmission control and congestion control mechanisms of the QUIC protocol; instead, it is directly controlled by a dedicated network address translation traversal module at specific timings and frequencies to maximize the success rate of traversal.

[0066] Furthermore, simultaneously, the second endpoint also sends a similar hole-punching request frame to the first endpoint based on the first public IP address. When one party's hole-punching request frame successfully penetrates the network address translation device and reaches the other party, and the other party also successfully receives the frame, a temporary mapping entry is created on the network address translation device, allowing bidirectional communication between the two parties.

[0067] Furthermore, the two parties continue to exchange data packets through this mapping entry, thus establishing an end-to-end UDP direct connection channel. Thereafter, application data between the first and second endpoints can be transmitted through this direct connection channel without needing to pass through any auxiliary nodes.

[0068] The peer-to-peer communication method based on the QUIC protocol extension provided in this embodiment extends the functionality of the originally idle six-bit unused field in the standard QUIC protocol version negotiation packet, enabling the QUIC protocol stack itself to carry STUN binding requests and responses. The first endpoint can complete its own public address detection without relying on an externally deployed STUN server. Furthermore, by setting a forwarding flag in the same field, transparent relay forwarding of candidate address information via public network auxiliary nodes is achieved, allowing two endpoints located behind different network address translation devices to complete bidirectional exchange of candidate addresses without a centralized signaling server. Furthermore, this method internalizes all STUN, signaling, and relay service functions, which must be independently deployed in traditional interactive connection establishment schemes, into the QUIC protocol, realizing a closed loop of peer-to-peer communication capabilities at the protocol stack level, significantly simplifying the complexity of the system architecture and reducing deployment and maintenance costs. Furthermore, by constructing hole-punching request frames that are not constrained by the QUIC reliable transmission control mechanism and sending them directly to the peer's public network address, network address translation traversal operations can be effectively performed in various complex network environments, successfully establishing an end-to-end direct communication path and providing a solid transport layer foundation for efficient, low-latency, and decentralized collaboration among intelligent agents.

[0069] To more clearly illustrate the technical solution of the present invention, the key steps and overall architecture are described below with reference to the accompanying drawings.

[0070] Please see Figure 3 This diagram illustrates the principle of communication between internal network endpoints using public network auxiliary nodes in an embodiment of the present invention. As shown, because the internal network endpoint ep is located after the network address translation device, it cannot be directly connected to other public network endpoints. However, it can actively establish a connection with a public network endpoint (&EP) that has public network reachability; this &EP is ep's public network auxiliary node. When another endpoint needs to communicate with ep, it can relay signaling or data to ep through &EP, thus logically enabling ep to have public network reachability. Furthermore, when two internal network endpoints ep1 and ep2 need to communicate, ep1 can exchange signaling and relay data through its associated public network auxiliary node &EP1 and ep2's associated public network auxiliary node &EP2, thereby creating conditions for a possible direct connection later.

[0071] Please see Figure 4This diagram illustrates the signaling interaction of an endpoint performing STUN address probing via a public network auxiliary node in an embodiment of the present invention. As shown, the first endpoint ep sends an extended QUIC long header data packet with a STUN request flag in the header and a STUN binding request payload to its associated public network auxiliary node (EP). Upon receiving this data packet, the public network auxiliary node (EP) extracts the source Internet Protocol address and port of the first endpoint ep from the User Datagram Protocol (UDP) message, encapsulates them as a public network mapped address in a STUN binding response, and returns it to the first endpoint ep via an extended QUIC long header data packet with a STUN response flag. The first endpoint ep parses this response to obtain its own public network address information after network address translation, thus completing the public network address probing.

[0072] Please see Figure 5 This diagram illustrates the signaling interaction between two intranet endpoints in this invention, where candidate addresses are exchanged through their respective public network auxiliary nodes. As shown, the first endpoint ep1 constructs a third extended QUIC long header data packet with a forwarding flag in its header. The payload carries the candidate address information of the first endpoint ep1 and sends it to the public network auxiliary node (EP2) associated with the second endpoint ep2. After parsing the data packet, the public network auxiliary node EP2 identifies the forwarding flag and forwards it to the second endpoint ep2. Symmetrically, the second endpoint ep2 also forwards its own candidate address information to the first endpoint ep1 through the public network auxiliary node (EP1) associated with the first endpoint ep1. Through this bidirectional forwarding process, the two intranet endpoints complete the exchange of candidate addresses, providing the necessary address information for subsequent direct hole punching.

[0073] Please see Figure 6 This diagram illustrates the data packet reception and processing logic of an endpoint running this extended QUIC protocol in an embodiment of the present invention. As shown, the User Datagram Protocol (UDP) data packets received by the endpoint are first routed according to the flag bits in the QUIC header. If identified as a STUN type data packet, the endpoint performs the corresponding processing—either obtaining its own public IP address or acting as a STUN service provider for another endpoint—depending on whether it is a binding request or a binding response. If identified as a relay type data packet, the destination address is checked: if the destination address points to this endpoint, it is handled by this endpoint; if the destination address points to another endpoint, it is forwarded to the destination address according to routing information. This mechanism enables endpoints running this extended QUIC protocol to possess the potential capabilities of both STUN and relay services.

[0074] Please see Figure 7This diagram illustrates the parallel network address translation (NAT) traversal between two endpoints using multiple available network paths in an embodiment of the present invention. As shown, the first endpoint ep1 and the second endpoint ep2 may simultaneously have multiple network interfaces, such as cellular and Ethernet. Each interface may support both IPv4 and IPv6 protocol stacks, thus multiple potential available network paths exist between the two endpoints. For example, the diagram illustrates four paths: cellular IPv4, Ethernet IPv4, cellular IPv6, and Ethernet IPv6. The first endpoint ep1 and the second endpoint ep2 can independently and in parallel perform candidate address switching and hole punching request frame transmission on each available network path. Once NAT traversal is successful on any path, a direct communication path can be established, and the multi-path scheduling mechanism of the QUIC connection can prioritize the use of the direct communication path for transmission.

[0075] Please see Figure 8 This diagram illustrates data relay via a decentralized auxiliary node cluster in an embodiment of the present invention. As shown, when a direct communication path between the first endpoint ep1 and the second endpoint ep2 fails to be established, the first endpoint ep1 can encapsulate the application data to be sent into a short extended QUIC header data packet with a forwarding flag. This packet is then sent to any reachable node in the decentralized auxiliary node cluster. The reachable node forwards the data packet hop-by-hop within the cluster based on the destination address information carried in the packet, ultimately delivering it to the public network auxiliary node associated with the second endpoint ep2, which then delivers it to the second endpoint ep2. This decentralized auxiliary node cluster is self-organized by multiple endpoints in the network that have public network reachability through a distributed hash table, providing reliable data relay services without the need for a centralized relay server.

[0076] Further, in some preferred embodiments, the first extended QUIC long header data packet, the second extended QUIC long header data packet, the third extended QUIC long header data packet, and the fourth extended QUIC long header data packet all adopt the header format of the QUIC version negotiation packet, and the unused bits in the header are the six unused fields in the QUIC version negotiation packet header; in the first extended QUIC long header data packet, the six unused fields include a STUN flag bit set to a value indicating the STUN data packet type, and a STUN type flag bit set to a value indicating the STUN request type; in the second extended QUIC long header data packet, the six unused fields include a STUN flag bit set to a value indicating the STUN data packet type, and... The STUN type flag is set to a value indicating the STUN response type; in the third extended QUIC long header data packet, the six unused fields include a forwarding flag set to a value indicating the forwarding data packet type; in the fourth extended QUIC long header data packet, the six unused fields include a forwarding flag set to a value indicating the forwarding data packet type; in the first, second, third, and fourth extended QUIC long header data packets, the six unused fields also include a source endpoint network type flag, used to identify whether the source endpoint is a public network endpoint or an internal network endpoint; and a destination endpoint network type flag, used to identify whether the destination endpoint is a public network endpoint or an internal network endpoint.

[0077] In practice, this embodiment achieves compact coding of multiple types of control signaling by functionally dividing and semantically defining the six unused fields in the QUIC version negotiation packet. The specific implementation method is as follows.

[0078] The first extended QUIC long header data packet, the second extended QUIC long header data packet, the third extended QUIC long header data packet, and the fourth extended QUIC long header data packet all adopt the header format of the QUIC version negotiation packet, and the unused bits in the header are the six unused fields in the QUIC version negotiation packet header.

[0079] Specifically, in the QUIC protocol standard specification released by the Internet Engineering Task Force (IETF), the version negotiation packet is a special data packet type used to negotiate the protocol version supported by both parties during the QUIC handshake phase. The first byte of its header structure contains a header format bit fixed at 1 to indicate a long header, a fixed bit also fixed at 1, and six unused bits. Following this is a 32-bit version field; the standard specifies that a version field value of 0x00000000 indicates that the data packet is a version negotiation packet. After this are the destination connection identifier length field, destination connection identifier, source connection identifier length field, and source connection identifier. The QUIC protocol standard specifies a six-bit unused field whose value should be ignored by the receiver. This embodiment utilizes this characteristic to extend the functionality of this six-bit unused field. Since implementations conforming to the standard QUIC protocol ignore the value of this field, encoding additional control signaling within it will not affect the standard QUIC protocol stack's processing of the data packet. The extended data packet still appears as a valid version negotiation packet to intermediate network devices, exhibiting good network compatibility and traversal capabilities.

[0080] Furthermore, in the first extended QUIC long header data packet, the six-bit unused field includes a STUN flag set to a value indicating the STUN data packet type, and a STUN type flag set to a value indicating the STUN request type. In a specific bit allocation scheme, each bit of this six-bit field is assigned a different functional semantic.

[0081] For example, the fifth bit can be designated as the STUN flag. When this bit is 1, it indicates that the payload of the data packet carries a message related to the STUN protocol; when the bit is 0, it indicates that the payload is not a STUN message. The sixth bit is the STUN type flag. When the STUN flag is 1, this type flag further distinguishes between requests and responses: a value of 0 indicates a STUN request type, and a value of 1 indicates a STUN response type. When the first endpoint constructs the first extended QUIC long header data packet, it sets the fifth bit to 1 and the sixth bit to 0, while other bits can be set or kept at 0 as needed. After receiving the data packet, the first public network auxiliary node can quickly determine that the data packet is a STUN binding request by reading the combination of the fifth and sixth bits without parsing the payload.

[0082] Furthermore, in the second extended QUIC long header data packet, the six unused fields include a STUN flag bit set to a value indicating the STUN data packet type, and a STUN type flag bit set to a value indicating the STUN response type. When constructing the response data packet, the first public network auxiliary node also sets the fifth STUN flag bit to 1, but sets the sixth STUN type flag bit to 1 to indicate that the data packet carries a STUN binding response. After receiving the data packet, the first endpoint can distinguish it from the STUN request packet based on the values ​​of these two flag bits and hand it over to the corresponding STUN response processing logic.

[0083] Furthermore, in the third extended QUIC long header data packet, the six-bit unused field contains a forwarding flag bit and is set to a value indicating the type of forwarded data packet. Another bit is also specified in the six-bit field as a forwarding flag bit.

[0084] For example, the first bit can be designated as a forwarding flag. When this bit is 1, it indicates that the data packet needs to be relayed; when it is 0, it indicates that the destination address of the data packet is the final receiver. When the first endpoint constructs the third extended QUIC long header data packet, it sets the first bit of the forwarding flag to 1. After receiving the data packet, the second public network auxiliary node first checks the forwarding flag, identifying that the data packet needs to be relayed rather than processed directly by this node, thus triggering the forwarding process.

[0085] Furthermore, in the fourth extended QUIC long header data packet, the six-bit unused field includes a forwarding flag bit and is set to a value indicating the type of forwarded data packet. When the second endpoint constructs a data packet that needs to be forwarded to the first endpoint via the first public network auxiliary node, it also sets the first bit of the forwarding flag bit to 1 to instruct the first public network auxiliary node to perform a relay forwarding operation on the data packet.

[0086] Furthermore, in the first extended QUIC long header data packet, the second extended QUIC long header data packet, the third extended QUIC long header data packet, and the fourth extended QUIC long header data packet, the six-bit unused field also includes a source endpoint network type flag bit, used to identify whether the source endpoint is a public network endpoint or an internal network endpoint; and a target endpoint network type flag bit, used to identify whether the target endpoint is a public network endpoint or an internal network endpoint.

[0087] Specifically, two additional bits are allocated to the remaining bits of the six-bit field as the source endpoint network type flag and the destination endpoint network type flag, respectively.

[0088] For example, the third bit can be designated as the source endpoint network type flag. When this bit is 0, it indicates that the original source endpoint of the data packet has a public Internet Protocol (IP) address and can be directly accessed by other hosts on the public network. When this bit is 1, it indicates that the original source endpoint is located after a network address translation device (NAT) and needs to rely on its associated public network auxiliary node for reverse communication. The fourth bit is the destination endpoint network type flag. When this bit is 0, it indicates that the final destination endpoint of the data packet has a public IP address. When this bit is 1, it indicates that the final destination endpoint is located after a NAT. When constructing extended QUIC long header data packets, the first and second endpoints set the values ​​of these two flags according to their own and the peer's known network types. When processing data packets with forwarding flags set, public network auxiliary nodes can optimize their forwarding strategies by reading these two network type flags.

[0089] For example, if the target endpoint network type flag indicates that the target endpoint is a public network endpoint, the auxiliary node can directly forward the data packet to that public network address; if it indicates that the target endpoint is an internal network endpoint, the auxiliary node needs to further forward the data packet to the auxiliary node associated with the target endpoint.

[0090] It should be noted that the specific bit positions of the aforementioned flags in the six-bit field are merely illustrative and not intended to limit the scope of protection of this application. In actual implementation, as long as the communication participants follow the same convention, the flags can be assigned to any position in the six-bit field. For example, the first bit can be used as the STUN flag, the second bit as the STUN type flag, and the third bit as the forwarding flag, etc. Furthermore, unused bits in the six-bit unused field can be reserved for future expansion or used to carry other auxiliary control information.

[0091] This embodiment refines the functional division and semantic definition of a six-bit unused field in the QUIC version negotiation packet that originally had no practical use. This allows the finite-length field to simultaneously carry multiple control signaling messages, including STUN packet type flags, STUN request and response type flags, forwarding packet type flags, and network type flags for the source and destination endpoints. This design fully utilizes the existing redundancy space in the QUIC protocol header without introducing additional header overhead or changing the external form and length of the data packet, ensuring transparent transmission and broad compatibility of the extended data packet in existing network infrastructure. Furthermore, by directly distinguishing the functional type of the data packet at the protocol header level, the receiving endpoint and relay auxiliary nodes can quickly identify the data packet processing method without deeply parsing the encrypted payload content, thereby significantly improving data packet processing efficiency and forwarding throughput. Furthermore, the setting of the source and destination endpoint network type flags allows relay nodes to select the optimal forwarding path based on the network topology characteristics of both communicating parties. For example, when the destination endpoint is a public network endpoint, it can be directly forwarded without multiple relays, avoiding unnecessary network detours and bandwidth consumption, and optimizing end-to-end data transmission performance.

[0092] In some preferred embodiments, the first endpoint directly sends a QUIC data packet carrying a hole punching request frame to the second endpoint based on the second public network address to establish a direct communication path with the second endpoint. This includes: the first endpoint constructing a PUNCH_HELLO frame and sending it directly to the second endpoint based on the second public network address. The PUNCH_HELLO frame contains a first sequence number corresponding to the local address of the first endpoint and a second sequence number corresponding to the second public network address. The PUNCH_HELLO frame is encapsulated in a QUIC data packet, bypassing the QUIC reliable transmission control mechanism. The first endpoint receives a PUNCH_DONE frame directly returned by the second endpoint after receiving the PUNCH_HELLO frame. The PUNCH_DONE frame contains an address sequence number corresponding to the PUNCH_HELLO frame. Based on the received PUNCH_DONE frame, the first endpoint confirms that the direct communication path with the second endpoint has been successfully established.

[0093] In specific implementation, this embodiment further defines the steps for the first endpoint to directly send a QUIC data packet carrying a hole-punching request frame to the second endpoint based on the second public network address to establish a direct communication path. By defining two new QUIC frame types, PUNCH_HELLO frame and PUNCH_DONE frame, and decoupling the transmission control of these frames from the QUIC transmission control layer, a flexible and efficient hole-punching signaling mechanism is achieved. The specific implementation method is as follows.

[0094] First, the first endpoint constructs a PUNCH_HELLO frame and sends it directly to the second endpoint based on the second public network address. The PUNCH_HELLO frame contains a first sequence number corresponding to the local address of the first endpoint and a second sequence number corresponding to the second public network address. The PUNCH_HELLO frame is encapsulated in a QUIC data packet to bypass the QUIC reliable transmission control mechanism.

[0095] Furthermore, the PUNCH_HELLO frame is a newly defined QUIC frame type. Its frame type number can be registered by selecting an unassigned value from the frame type space reserved by the QUIC protocol. The word PUNCH comes from the English word "punch," and HELLO means greeting; together, it represents a greeting frame used for Network Address Translation (NAT) traversal. This frame is designed as an unacknowledged frame, meaning that the receiver does not need to generate an acknowledgment frame upon receiving it, and the sender will not trigger a retransmission due to the lack of acknowledgment. This design is because NAT traversal has specific requirements for the timing of packet transmission. Sometimes, multiple punch packets with the same content need to be sent consecutively within a very short period to increase the probability of traversal. If managed by the QUIC reliable transmission module, retransmission logic and congestion control might interfere with the punch timing, leading to traversal failure. Therefore, the transmission control of the PUNCH_HELLO frame is transferred to a specially implemented NAT traversal module, which autonomously determines the transmission frequency, number of packets, and retry strategy based on the detected NAT type and behavioral characteristics.

[0096] Furthermore, in terms of frame structure, the PUNCH_HELLO frame contains two variable-length integer fields, i.e., variable-length integer encoded fields. The first field is the local address sequence number, filled with the sequence number corresponding to the local address of the first endpoint. This sequence number originates from the Sequence Number field contained in the ADD_ADDRESS frame as defined in the Using QUIC to Traversal NATs draft published by the Internet Engineering Task Force (IETF). During the candidate address exchange phase, the first endpoint announces its various candidate addresses to the second endpoint through the ADD_ADDRESS frame and assigns a unique sequence number to each address. When the first endpoint needs to perform a hole punching operation on a specific local address, it fills in the sequence number corresponding to that address in the PUNCH_HELLO frame. The second field is the peer address sequence number, filled with the sequence number corresponding to the second public network address. This sequence number originates from the sequence number assigned when the second endpoint announced its candidate address through the ADD_ADDRESS frame. This pair of sequence numbers uniquely identifies the address pair targeted by this hole punching attempt. By parsing these two sequence numbers, the receiver can accurately determine which local address the sender is attempting to punch from to which of its own addresses.

[0097] Furthermore, the first endpoint encapsulates the constructed PUNCH_HELLO frame within a QUIC short header data packet. The short header is a header format used by the QUIC protocol for efficient data transmission after the connection is established, with its overhead being only a small fraction of that of the long header. The first endpoint sets the destination Internet Protocol address and port of this short header data packet to a second public IP address and sends it directly through the operating system's User Datagram Protocol (UDP) socket application programming interface. The transmission operation bypasses the QUIC protocol stack's transmission control path; instead, it is completed by the network address translation traversal module bypassing the socket transmission interface, but it uses the 1RTT key of the QUIC connection for encrypted transmission.

[0098] Furthermore, the first endpoint receives a PUNCH_DONE frame directly returned by the second endpoint after receiving the PUNCH_HELLO frame, the PUNCH_DONE frame containing an address sequence number corresponding to the PUNCH_HELLO frame.

[0099] Furthermore, the PUNCH_DONE frame is a response frame paired with the PUNCH_HELLO frame, with "DONE" indicating completion. This frame requires confirmation, following the existing reliable path of the QUIC connection to avoid the cumbersome handling of losing the last data packet during the handshake process. Its frame structure is identical to the PUNCH_HELLO frame, containing two variable-length integer fields: the local address sequence number and the peer address sequence number. When the second endpoint receives the PUNCH_HELLO frame from the first endpoint, it indicates that the hole-punching data packet sent by the first endpoint has successfully traversed the network address translation device (NAT) of the second endpoint's network and reached the second endpoint's network interface. The NAT traversal module of the second endpoint parses the frame, extracting the local and peer address sequence numbers. The second endpoint immediately constructs a PUNCH_DONE frame and copies the two received sequence numbers verbatim into the corresponding fields of the PUNCH_DONE frame. The second endpoint then bypasses the QUIC reliable transmission control mechanism and directly sends this PUNCH_DONE frame back to the first endpoint with the first public network address as the destination address. This return packet action itself also serves to create a hole from the second endpoint to the network address translation device on the first endpoint, because when the return packet passes through the network address translation device on the second endpoint, a temporary reverse mapping rule will also be created.

[0100] Further, based on the received PUNCH_DONE frame, the first endpoint confirms that the direct communication path with the second endpoint has been successfully established. After receiving the PUNCH_DONE frame, the first endpoint compares the address sequence number in it with the sequence number in the previously sent PUNCH_HELLO frame. If the sequence numbers match exactly, it confirms that the response frame matches the request frame, indicating that the hole-punching packet sent by the first endpoint has successfully reached the second endpoint, and the response packet sent by the second endpoint has also successfully reached the first endpoint, meaning that bidirectional network address translation traversal has been successful. Further, the first endpoint marks this network path as a verified active path, and subsequent application data can be transmitted through this direct path. If no PUNCH_DONE frame is received within a preset timeout period, the network address translation traversal module of the first endpoint can execute a retry strategy, such as retransmitting the PUNCH_HELLO frame at an exponential backoff interval, or determining that the candidate address pair has failed to punch the hole and trying other candidate address pairs or switching to other network paths.

[0101] Alternatively, in a more complex implementation, to address the strict port binding requirements of symmetric network address translation devices, the hole punching process can be performed as follows: the first endpoint not only sends a PUNCH_HELLO frame on the primary port declared by the second endpoint, but also simultaneously sends the same hole punching frame in parallel on multiple other guessed ports. The second endpoint also listens and sends on multiple ports. The address sequence number carried in the PUNCH_HELLO and PUNCH_DONE frames ensures that regardless of which port the hole punching frame is received from, the receiver can accurately associate it with the corresponding candidate address, avoiding mismatches caused by port inconsistencies.

[0102] This embodiment defines two novel QUIC frame types, PUNCH_HELLO and PUNCH_DONE, and decouples the transmission control of these frames from the reliable transmission control mechanism of the QUIC protocol, entrusting it to a dedicated network address translation (NAT) traversal module for direct management. This achieves a flexible hole-punching signaling mechanism specifically designed for NAT traversal needs. Furthermore, since hole-punching frames are not constrained by QUIC congestion control and automatic retransmission mechanisms, the traversal module can autonomously determine the transmission frequency, timing, concurrency, and retry strategy of hole-punching packets based on the detected NAT device type and behavioral characteristics, thereby significantly improving the success rate in difficult traversal scenarios such as symmetrical NAT. Moreover, PUNCH_HELLO and PUNCH_DONE frames uniquely identify the specific candidate address combination targeted by each hole-punching attempt by carrying address sequence number pairs. This ensures that in complex scenarios involving multiple addresses and multiple ports simultaneously punching holes, the receiving end can accurately associate the response frame with the corresponding request frame, avoiding misjudgments caused by address or port confusion. Furthermore, once both the bidirectional PUNCH_HELLO and PUNCH_DONE frames successfully reach the other end, the end-to-end direct connection is declared established, and subsequent data transmission can enjoy all the advantages of the QUIC protocol, such as low transmission latency, multiplexing, connection migration, and built-in encryption.

[0103] In some preferred embodiments, when there is at least one available network path between the first endpoint and the second endpoint, the first endpoint sends the third extended QUIC long header data packet to the second public network auxiliary node based on the address information of the second public network auxiliary node, including: the first endpoint sending the third extended QUIC long header data packet through the at least one available network path; the first endpoint directly sending a QUIC data packet carrying a hole punching request frame to the second endpoint, including: the first endpoint sending the QUIC data packet carrying the hole punching request frame through the at least one available network path; when a hole punching request is successful on any available network path, the first endpoint establishes a direct communication path with the second endpoint through the network path where the hole punching was successful; wherein, the at least two available network paths include at least two of the following: IPv4 network path, IPv6 network path, wireless LAN path, and cellular network path.

[0104] In specific implementation, this embodiment further defines the parallel processing method when there are multiple available network paths between the first endpoint and the second endpoint. By deeply integrating the multi-path transmission capability of the QUIC protocol with the network address translation hole punching process, candidate address exchange and hole punching attempts can be executed independently and in parallel on all available network paths. The specific implementation method is as follows.

[0105] Modern mobile terminals and smart devices are typically equipped with multiple network interface controllers, supporting both Wi-Fi and cellular data network access simultaneously. Each network interface usually runs both IPv4 and IPv6 protocol stacks concurrently. IPv4, or Internet Protocol version 4, has a 32-bit address space and is currently the most widely used network layer protocol on the Internet. IPv6, or Internet Protocol version 6, has a 128-bit address space and is a next-generation network layer protocol designed to address IPv4 address exhaustion. A Wi-Fi path refers to the communication path that connects to a local area network via a wireless access point and then accesses the Internet; it typically offers high bandwidth and low latency. A cellular network path refers to the communication path that connects to an operator's core network via a mobile communication base station; it typically offers better mobility and coverage.

[0106] Furthermore, in a scenario where both the first and second endpoints have the typical network configuration described above, the first endpoint may simultaneously possess four valid local Internet Protocol (IP) addresses: an IPv4 and IPv6 address for the wireless LAN, and an IPv4 and IPv6 address for the cellular network. The second endpoint may also possess four corresponding public IP addresses. By selecting any local address from the first endpoint and any public IP address from the second endpoint, a candidate network path can be constructed. Ideally, there may be a total of sixteen potential network paths available for communication between the two endpoints. Different network paths traverse different physical links, routing policies, and network address translation (NAT) devices, resulting in variations in the difficulty and success rate of NAT traversal on each path. Some paths may be easily traversed due to lenient NAT device types, while others may be impassable due to the presence of symmetric firewalls.

[0107] Furthermore, this embodiment fully leverages the QUIC protocol's native support for multipath transmission, extending candidate address switching and hole punching operations to be executed in parallel on all available network paths. QUIC's multipath transmission capability is defined by the Multipath Extension for QUIC draft released by the Internet Engineering Task Force (IETF), allowing a QUIC connection to transmit data simultaneously on multiple different network paths. Each path is identified by a unique path identifier and maintains independent congestion control and packet loss recovery states.

[0108] Furthermore, during the candidate address exchange phase, the first endpoint not only sends the third extended QUIC long header data packet through the default primary network path, but also sends the packet through all other available network paths. Specifically, the first endpoint iterates through all valid Internet Protocol addresses locally, and for each address, sends a copy of the third extended QUIC long header data packet to the second public network auxiliary node through the User Datagram Protocol socket bound to that address. Since each sending operation uses a different source address, the second public network auxiliary node will receive data packets from multiple different public network addresses of the first endpoint. The second public network auxiliary node forwards these data packets from different source addresses to the second endpoint. After receiving these forwarded data packets, the second endpoint parses and records the candidate addresses of the first endpoint on each network path. Similarly, the second endpoint also sends the fourth extended QUIC long header data packet through all its available network paths, transmitting its own public network address information on each path to the first endpoint. After completing this parallel candidate address exchange process, both parties obtain a complete multi-path candidate address mapping table.

[0109] Furthermore, during the hole-punching execution phase, the network address translation (NAT) traversal module at the first endpoint generates a hole-punching task for each feasible pair of local and peer address combinations based on the candidate address mapping table. For each hole-punching task, the first endpoint constructs a PUNCH_HELLO frame, where the local address sequence number corresponds to the first endpoint's local address on the corresponding path, and the peer address sequence number corresponds to the public IP address of the second endpoint on the corresponding path. The first endpoint directly sends this PUNCH_HELLO frame to the public IP address of the second endpoint via the corresponding path's User Datagram Protocol (UDP) socket. These hole-punching attempts are performed simultaneously and independently on the sixteen paths, without interference. The NAT traversal module maintains an independent state machine for each path, tracking information such as whether a hole-punching request on that path has been sent, received a response, or timed out.

[0110] Furthermore, when a PUNCH_DONE frame is successfully received from the second endpoint on any path, the network address translation traversal module determines that the hole punching on that path has been successful and immediately marks the path as active. The first endpoint then notifies the path manager of the QUIC protocol stack of this path, and the path manager registers the path as an active sub-stream of the QUIC connection. Afterward, application data between the first and second endpoints can be transmitted through this successfully punched network path. Other paths that have not yet succeeded can continue to attempt hole punching; if they also succeed later, they can be used as backup paths or for multi-path concurrent transmission to aggregate bandwidth and improve throughput. If a path fails to punch a hole within a preset timeout period, the path is marked as unavailable and will not be attempted again.

[0111] Furthermore, this parallel strategy of "multiple lanes simultaneously crashing into the door" increases the probability of successful hole punching from relying on the luck of a single path to the cumulative success rate after multiple paths are attempted in parallel, significantly improving the success rate of establishing end-to-end direct connections in complex heterogeneous network environments.

[0112] This embodiment organically integrates the multi-path transmission capability of the QUIC protocol with the network address translation (NAT) hole-punching process, enabling candidate address exchange and hole-punching attempts to be executed independently and in parallel on all available network paths between the first and second endpoints. Since different network paths traverse different physical links, carrier networks, and NAT devices, their penetration characteristics vary significantly. Through a multi-path parallel attempt strategy, as long as any one path successfully completes NAT traversal, an end-to-end direct communication path can be established. Furthermore, this mechanism increases the probability of successful hole punching from a low level dependent on a single path to a higher level resulting from the superposition of multiple paths. In typical mobile scenarios where endpoints simultaneously possess both Wi-Fi and cellular network access capabilities, the direct connection success rate can be increased to nearly 100%. Furthermore, the network resources utilized in this embodiment, such as IPv4, IPv6, Wi-Fi, and cellular network paths, are standard configurations commonly found on modern mobile terminals, requiring no additional hardware or specific driver installations at the endpoints, demonstrating good versatility and wide applicability.

[0113] In some preferred embodiments, when the direct communication path between the first endpoint and the second endpoint fails to be established, the method further includes: the first endpoint constructing a first extended QUIC short header data packet and sending it to any reachable node in the decentralized auxiliary node cluster, so that the reachable node forwards the first extended QUIC short header data packet to the second public network auxiliary node associated with the second endpoint according to the target address information, and the second public network auxiliary node delivers the application data to the second endpoint, wherein the SpinBit bit of the header of the first extended QUIC short header data packet is redefined as the forwarding flag bit and set to a first value, and the payload carries the application data to be sent and the target address information of the second endpoint.

[0114] In specific implementation, this embodiment further limits the fallback handling method when the direct communication path between the first endpoint and the second endpoint fails to be established. By redefining the Spin Bit of the QUIC short packet header and using it as a forwarding flag, any ordinary node with permissible network conditions can act as a relay, thereby achieving decentralization of the relay function. The specific implementation method is as follows.

[0115] In certain extremely restricted network environments, such as when both endpoints are behind enterprise firewalls implementing strict outbound traffic filtering, or when the network address translation devices on both ends are symmetrical devices that strictly bind addresses and ports, direct hole punching may still fail. In such cases, a reliable fallback mechanism is needed as a backup solution to ensure uninterrupted communication between endpoints. Traditional solutions typically use a TURN server in an interactive connection establishment framework as a relay. TURN stands for Traversal Using Relays around NAT, meaning traversing network address translation via relay. The TURN server must be pre-deployed in a public network environment and acts as a centralized node carrying all relay traffic, resulting in high costs and a single point of failure risk. This embodiment proposes a completely different solution: enabling any ordinary endpoint in the network with public network reachability to relay forwarding capabilities, and forming a decentralized auxiliary node cluster through self-organization. The first endpoint can directly utilize any node in this cluster for data relay.

[0116] Furthermore, the short header of the standard QUIC protocol is used for the data transmission phase after the connection is established, and its header structure is very compact. The first byte of the short header contains: a header format bit fixed at zero to identify the short header; a fixed bit fixed at one; a Spin Bit, which is used in the standard protocol to passively measure the round-trip time on the path and is not necessary for the basic data transmission function of the connection; two reserved bits; a key phase to indicate the update status of the encryption key; and two bits to indicate the packet length. In this embodiment, the Spin Bit is redefined and used as a forwarding flag. The name Spin Bit comes from the fact that its value flips after each round trip, like a rotation, but this scheme no longer uses this dynamic flipping feature, but instead gives it a static semantic: when the bit is at a first value, such as 1, it indicates that the short header data packet is a data packet that needs to be relayed; when the bit is at a second value, such as 0, it indicates that the data packet is a normal data packet that does not need to be forwarded.

[0117] Furthermore, when the network address translation traversal module of the first endpoint confirms that a direct connection with the second endpoint cannot be established after sufficient attempts of all candidate paths, the first endpoint switches to relay mode. The first endpoint retrieves the application data to be sent from its local sending queue and constructs a first extended QUIC short header data packet. When constructing this packet, the first endpoint sets the Spin Bit in the first byte of the short header to a first value, i.e., 1, to indicate that the packet needs to be relayed. In the payload portion of this packet, in addition to carrying the application data encrypted and protected by the QUIC protocol, a plaintext extended header is appended before the payload. This plaintext extended header contains routing information required for forwarding, including at least: the destination address information of the second endpoint, which can be the public IP address of the second endpoint or the address information of a second public network auxiliary node associated with the second endpoint; and an optional source endpoint address pair, used by the receiver for reverse routing if necessary.

[0118] Furthermore, the first endpoint sends the constructed first extended QUIC short header data packet to any reachable node in the decentralized auxiliary node cluster via the User Datagram Protocol (UDP). The decentralized auxiliary node cluster is spontaneously composed of numerous ordinary endpoints running this extended QUIC protocol and possessing public network reachability. The first endpoint can select a currently known online node with low network latency as its entry node by querying its locally maintained distributed hash table routing table. A distributed hash table is a decentralized distributed storage and lookup technology. After receiving the first extended QUIC short header data packet, the reachable node first checks the Spin Bit in the short header; finding its value to be 1, it confirms that the data packet needs to be forwarded. Further, the reachable node parses the destination address information in the plaintext extended header and determines the next-hop forwarding target based on this information. Further, if an established direct QUIC path exists between the reachable node and the second public network auxiliary node, the reachable node directly forwards the data packet to the second public network auxiliary node through this path. Furthermore, if no direct path exists, the reachable node continues to search its distributed hash table routing table for other auxiliary nodes with a network distance closer to the target address, and forwards the packet to one or more of these nodes, initiating a recursive forwarding process. After a finite number of hops, the packet finally reaches the second public network auxiliary node.

[0119] Furthermore, upon receiving the data packet, the second public network auxiliary node also identifies it as a forwarding packet using the Spin Bit. After parsing the destination address information, it confirms that the final destination is the second endpoint. Therefore, it delivers the data packet to the second endpoint through the keep-alive connection between itself and the second endpoint. Upon receiving the data packet, the second endpoint processes it according to the normal QUIC protocol decryption process, ultimately obtaining the application data sent by the first endpoint.

[0120] Through the above mechanism, even if a direct connection cannot be established at all, the first and second endpoints can still conduct end-to-end data communication through a decentralized relay network spontaneously formed by ordinary endpoints, ensuring the continuity of upper-layer application services.

[0121] This embodiment redefines the Spin Bit in the QUIC short header as a forwarding flag, enabling the QUIC protocol to natively support packet relay forwarding during the data transmission phase after connection establishment. When a direct communication path cannot be established between the first and second endpoints after exhaustive attempts at all available network paths, the first endpoint does not need to fall back to a pre-deployed dedicated TURN relay server. Instead, it can encapsulate the application data to be sent into an extended short header packet and send it to any reachable node in the decentralized auxiliary node cluster. This packet, after being forwarded through a multi-hop relay network spontaneously formed by ordinary endpoints, reliably reaches the second endpoint. Furthermore, since the forwarding flag is directly embedded in the first byte of the short header, relay nodes can quickly identify the packet type and perform forwarding operations with minimal parsing overhead, ensuring efficient relay transmission. Furthermore, this scheme fundamentally eliminates the single-point dependence of traditional peer-to-peer communication schemes on centralized relay servers. Any ordinary endpoint that meets network conditions can dynamically join the auxiliary node cluster and provide relay services, giving the entire network strong self-organization, scalability, and resilience.

[0122] In some preferred embodiments, the decentralized auxiliary node cluster is formed by multiple endpoints in the network that are publicly reachable through a distributed hash table, and all of the multiple endpoints run the QUIC protocol extension.

[0123] In practice, in a large-scale decentralized peer-to-peer network, the number and composition of auxiliary nodes are highly dynamic. Nodes may leave the network at any time due to user device shutdown, network switching, or application exit, and new nodes may join at any time. Traditional methods of node registration and discovery based on centralized servers are not suitable for this highly dynamic decentralized scenario. This embodiment introduces distributed hash table technology to achieve fully distributed self-organizing management of auxiliary nodes. Distributed hash tables are a type of decentralized distributed system protocol. Their core idea is to organize nodes in the network into a structured overlay network. Each node is responsible for maintaining a small subset of key-value pairs in the entire hash table space and achieving efficient lookup of any key through a specific routing algorithm.

[0124] Furthermore, each endpoint running this extended QUIC protocol and meeting the public network reachability requirement can be configured to operate in auxiliary node mode. Public network reachability includes: the endpoint directly possessing a public Internet Protocol (IP) address, or, although located behind a network address translation (NAT) device, its NAT type, as detected, is FullCone, meaning any external host can successfully send data packets to the endpoint through its mapped public IP address and port. When an endpoint meeting these conditions initiates auxiliary node functionality, it first generates a node identifier. This node identifier is typically obtained by cryptographically hashing the endpoint's public key, network address, or other unique identifying information. Standard algorithms such as SHA-256 can be used to generate a sufficiently long and evenly distributed binary identifier. Due to the characteristics of hash functions, the node identifiers generated by different nodes are randomly and evenly distributed in the identifier space, laying the foundation for building a structured overlay network.

[0125] Furthermore, the auxiliary nodes construct and maintain the overlay network by running a distributed hash table protocol based on XOR distance metric. The Kademlia protocol is a typical example of this. In this protocol, the XOR operation result between two node identifiers is defined as the logical distance between the nodes, which satisfies symmetry and the triangle inequality, and can be used to construct efficient routing tables. Each auxiliary node maintains a routing table consisting of multiple K-buckets. Each K-bucket corresponds to a node identifier space with a specific prefix range and stores network contact information for a certain number of other auxiliary nodes matching that range, including Internet Protocol addresses, ports, and node identifiers. Nodes continuously communicate with other nodes in the network, gradually filling and improving their own routing tables, resulting in a distribution of nodes in the identifier space where closer nodes are more numerous than farther ones. This structure ensures that any node only needs to maintain a small number of routing entries that are logarithmically related to the total number of nodes in the network to achieve efficient routing to any other node in the network; the average number of hops per lookup is only proportional to the logarithm of the network size.

[0126] Furthermore, when a new auxiliary node joins the network, it first needs to obtain contact information for at least one existing auxiliary node in the network through a bootstrapping mechanism. This bootstrapping mechanism can include: a set of long-term, stable seed node hard-coded addresses built into the application; querying pre-configured seed node domain name resolution records via the Domain Name System; or reading node information saved from the last runtime from a local persistent cache. After establishing a QUIC connection with the bootstrapping node, the new node executes a node lookup process. It sends a FIND_NODE lookup request to the bootstrapping node for its own node identifier. The bootstrapping node, based on the target identifier in the request, searches its own routing table for the nearest nodes to that identifier and returns them to the new node. Upon receiving the response, the new node continues to send lookup requests to these even closer nodes, recursively iterating until it locates a group of neighboring nodes in the network closest to its own identifier. The new node establishes connections with these neighboring nodes and adds them to its own routing table, while the neighboring nodes also add the new node's information to their respective routing tables. At this point, the new node successfully joins the overlay network.

[0127] Furthermore, when a regular endpoint needs to find available auxiliary nodes—for example, when the first endpoint needs to acquire a first public network auxiliary node to assist in STUN probing during initial startup, or when the first endpoint needs to select an entry node for a decentralized auxiliary node cluster to send relay packets—it can obtain a list of eligible auxiliary nodes by initiating a search request to any known auxiliary node in the overlay network. The search request can include filtering conditions, such as returning only nodes with relatively light loads and low response latency. Nodes in the overlay network collaborate to complete the search according to a distributed hash table protocol, ultimately returning contact information for a set of eligible auxiliary nodes. The first endpoint selects one or more auxiliary nodes from the returned list to establish connections and register associations.

[0128] Furthermore, auxiliary nodes periodically exchange heartbeat information via PING messages to check each other's liveness. If an auxiliary node fails to respond for several consecutive heartbeat cycles, the corresponding entry in the routing table will be marked as invalid and eventually removed, thus ensuring the timeliness and accuracy of routing information. To improve the availability of the relay service, an internal network endpoint located behind a network address translation device can register its association with multiple auxiliary nodes simultaneously. In this way, when one auxiliary node goes offline, other endpoints can still query the other auxiliary nodes associated with that internal network endpoint through a distributed hash table, thereby maintaining communication reachability.

[0129] Through the self-organizing mechanism based on the distributed hash table, the decentralized auxiliary node cluster can achieve all functions such as automatic node discovery, routing table maintenance, fault detection, and load balancing without any centralized registration server, directory server, or scheduling server, thus truly achieving the goal of complete decentralization.

[0130] This embodiment introduces distributed hash table technology as the underlying organizational mechanism for auxiliary nodes, enabling any endpoint with public network reachability to dynamically join or leave the auxiliary node cluster at any time without going through the registration, authentication, authorization, or scheduling process of a centralized server. Furthermore, auxiliary nodes autonomously maintain a globally queryable logical routing table through the distributed hash table protocol. Ordinary endpoints can discover and obtain available auxiliary node contact information by initiating standardized lookup requests to this overlay network. This self-organizing mechanism endows the auxiliary node cluster with extremely high scalability and robustness. The cluster size can naturally scale with the number of network participants, and the failure of individual auxiliary nodes will not affect the overall cluster's ability to provide services. The network exhibits excellent fault tolerance and self-healing characteristics. Furthermore, since auxiliary nodes are voluntarily provided by devices from ordinary participants in the network, there is no need to rent and maintain dedicated cloud server infrastructure, fundamentally reducing the overall system operating costs and completely avoiding the risk of network paralysis due to the cessation of operations by a single centralized service provider.

[0131] In some preferred embodiments, during the connection request initiated by the first endpoint to the second endpoint and subsequent communication interactions, each instruction data sent by the first endpoint carries a digital signature generated using the first endpoint's private key. The second endpoint authenticates the digital signature based on the domain name of the first endpoint and decides whether to respond to the instruction data according to a preset access policy based on domain name identity.

[0132] In its implementation, this embodiment further defines the security authentication and access control mechanisms throughout the communication process. By introducing a digital signature mechanism based on asymmetric cryptography and an access control policy based on domain name identity, the anchor of security trust is shifted from a centralized platform to cryptographic algorithms and globally unique domain name identity identifiers. The specific implementation method is as follows.

[0133] In traditional centralized platform architectures, communication security between endpoints primarily relies on the platform as a trusted third party for authentication and access control. Users trust the platform, believing it will not forge or tamper with communication content, and the platform is responsible for uniformly auditing and managing access permissions for each endpoint. However, in decentralized peer-to-peer communication architectures, the communicating parties interact directly, without a centralized node trusted by all endpoints to handle authentication and access control. This embodiment proposes an intrinsic security mechanism based on domain identity and digital signatures, eliminating the need for any external third party to ensure communication security.

[0134] First, each endpoint participating in peer-to-peer communication possesses a key pair based on asymmetric cryptography, consisting of a private key and a public key. Asymmetric cryptography, also known as public-key cryptography, is characterized by the fact that data encrypted with a public key can only be decrypted with the corresponding private key, and conversely, data signed with a private key can only be verified with the corresponding public key. The private key is secret information generated and strictly guarded by the endpoint itself, for example, it can be stored in the device's trusted execution environment or hardware security module, ensuring that the private key does not leave the secure area in plaintext. The public key can be mathematically derived from the private key and can be publicly released. Simultaneously, each endpoint is bound to a globally unique domain identity identifier in the Domain Name System (DNS), such as agent-alice.ioa. This domain identity identifier is not only the endpoint's network addressing entry point but also its unforgeable identity credential. Endpoints can publish their public key fingerprint or full public key in the domain's authoritative record through DNS security extensions, or they can apply for a Transport Layer Security (TLS) digital certificate bound to the domain, which contains public key information and is signed by a trusted certificate authority. In this way, other endpoints can verify the binding relationship between the public key and the domain name through standard public key infrastructure (PPP).

[0135] Furthermore, when the first endpoint needs to send a command message to the second endpoint, whether it's a signaling message at the initial stage of connection establishment or an application layer command after connection establishment, the first endpoint uses its own private key to digitally sign the command message. The digital signature generation process is as follows: The first endpoint first uses a consensus-based one-way hash algorithm to hash the original command message, obtaining a fixed-length data digest. The hash algorithm is one-way and collision-resistant, making it impossible to deduce the original message from the digest, and it's difficult to find two different original messages that produce the same digest. Then, the first endpoint uses its own private key to encrypt the digest, generating a binary signature. The first endpoint encapsulates the original command message, the signature, and its own domain name identifier in the payload of a QUIC data packet, securely encrypts it at the QUIC transport layer, and then sends it to the second endpoint.

[0136] Further, after receiving the data packet and completing transport layer decryption, the second endpoint extracts the original instruction data, digital signature, and the claimed sender's domain name identity identifier. The second endpoint first obtains the first endpoint's public key based on this domain name identity identifier. This can be achieved by: initiating a DNS security extension query for the domain name to obtain the public key information recorded in the DNS; or by verifying the digital certificate chain provided by the first endpoint along with the data to confirm the correspondence between the public key in the certificate and the domain name. After obtaining the first endpoint's public key, the second endpoint uses it to verify the digital signature. The verification process is as follows: the second endpoint uses its public key to decrypt the signature data, obtaining a first digest value; simultaneously, the second endpoint performs the same hash algorithm on the original instruction data, obtaining a second digest value. The second endpoint compares whether the two digest values ​​are completely identical. If they match, the signature verification passes, cryptographically guaranteeing that the instruction data was indeed sent by the first endpoint holding the private key bound to the domain name, and that the data was not tampered with by any middleman during transmission. If they do not match, the signature verification fails, and the second endpoint directly discards the data packet, refusing to perform any operation.

[0137] Furthermore, after successful signature verification, the second endpoint does not directly and unconditionally execute the instruction. Instead, it further determines whether to respond based on a pre-defined domain-based access control policy. The access control policy is a set of access control rules pre-configured by the administrator of the second endpoint. Each rule defines the access permissions that a specific domain identity or domain identity pattern has for a specific resource or operation. For example, the access control policy can be configured to: allow the endpoint with the domain identity agent-alice.ioa to call the camera activation interface in the device control application programming interface; allow all endpoints with the domain identity matching the *.trusted-domain.ioa pattern to read temperature sensor data; and deny any endpoint with a domain identity not in the permitted list access to any management interface. The access control policy can be stored in the local persistent storage of the second endpoint in the form of a structured access control list, and the second endpoint provides a secure management interface with signature verification for remote updates by the administrator.

[0138] Furthermore, if the domain identity of the first endpoint precisely matches a permitted rule in the access control policy, the second endpoint processes the instruction data according to normal business logic, performs the corresponding operation, and returns a response result. If the domain identity of the first endpoint does not match any permitted rule, or explicitly matches a denied rule, the second endpoint discards the instruction data, does not perform any substantive operation, and may selectively return an access denied error response to the first endpoint. Simultaneously, it records this access denial event in the local security audit log for post-event security analysis.

[0139] Through the complete process of signature verification and access control, the security of decentralized peer-to-peer communication is built upon two fundamental principles: the unforgeability of cryptography and the globally unique identifiers of the Domain Name System. The origin of every instruction can be accurately traced back to the domain identity of the initiator, every operation leaves a verifiable signature trace on the peer, and any data tampering will be immediately detected by the signature verification process.

[0140] This embodiment constructs an intrinsic security system that is completely independent of third-party platforms by introducing a private key-based digital signature mechanism and a domain name-based access control policy throughout the entire end-to-end communication process. Each instruction data sent by the first endpoint is accompanied by a digital signature generated using its private key. The second endpoint verifies the signature to confirm the true identity of the instruction source and the integrity of the data content, and then decides whether to authorize execution based on a locally preset domain name-based access control policy. Furthermore, this mechanism shifts the trust foundation of communication security from the third-party platform in the traditional centralized architecture to the mathematical rigor of cryptographic algorithms and the authority of the globally unique identifier of the Domain Name System, fundamentally eliminating the risks of privacy leaks and unauthorized operations caused by platforms stealing, tampering with, or forging communication data. Furthermore, the digital signature endows each interactive instruction with non-repudiation, providing a complete security audit and traceability chain for cross-domain and cross-organizational intelligent agent collaboration. This security mechanism is deeply integrated with the decentralized peer-to-peer communication protocol stack in the aforementioned embodiment, providing comprehensive underlying security guarantees for autonomous, open, trustworthy, and sovereign controllable intelligent agent collaboration in the intelligent agent internet scenario.

[0141] Please see Figure 2 , Figure 2 This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 500 can be a terminal or a server, wherein the server can be a standalone server or a server cluster composed of multiple servers.

[0142] The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a system bus 501. The memory may include a non-volatile storage medium 503 and internal memory 504.

[0143] The non-volatile storage medium 503 can store an operating system 5031 and a computer program 5032. When the computer program 5032 is executed, it causes the processor 502 to execute a peer-to-peer communication method based on a QUIC protocol extension.

[0144] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0145] The internal memory 504 provides an environment for the execution of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute a peer-to-peer communication method based on the QUIC protocol extension.

[0146] The network interface 505 is used for network communication with other devices. Those skilled in the art will understand that the above structure is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 500 to which the present application is applied. A specific computer device 500 may include more or fewer components than shown in the figures, or combine certain components, or have different component arrangements.

[0147] The processor 502 is used to run a computer program 5032 stored in a memory to implement the steps of any of the above method embodiments.

[0148] It should be understood that in the embodiments of this application, the processor 502 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0149] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program may be stored in a storage medium, which is a computer-readable storage medium. The computer program is executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0150] Therefore, the present invention also provides a storage medium. This storage medium may be a computer-readable storage medium. The storage medium stores a computer program. When executed by a processor, the computer program causes the processor to perform the steps of any of the above-described method embodiments.

[0151] The storage medium is a physical, non-transient storage medium, such as a USB flash drive, external hard drive, read-only memory (ROM), magnetic disk, or optical disk, or any other physical storage medium capable of storing program code. The computer-readable storage medium can be non-volatile or volatile.

[0152] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0153] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0154] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0155] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0156] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0157] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Since these modifications and variations fall within the scope of the claims and their equivalents, this invention also intends to include these modifications and variations.

[0158] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A peer-to-peer communication method based on a QUIC protocol extension, characterized in that, include: In response to a connection request initiated by the first endpoint to the second endpoint, the first endpoint obtains the address information of the second public network auxiliary node associated with the second endpoint; The first endpoint constructs a first extended QUIC long header data packet and sends it to the first public network auxiliary node associated with the first endpoint. The unused bits in the header of the first extended QUIC long header data packet are set with a STUN request flag, and the payload carries a STUN binding request. The first public network auxiliary node extracts the source address information of the first endpoint based on the first extended QUIC long header data packet, constructs a second extended QUIC long header data packet, and returns it to the first endpoint. The unused bits in the header of the second extended QUIC long header data packet are set with a STUN response flag, and the payload carries a STUN binding response containing the source address information. The first endpoint parses the STUN binding response to obtain the first public IP address of the first endpoint after network address translation; The first endpoint constructs a third extended QUIC long header data packet and sends it to the second public network auxiliary node based on the address information of the second public network auxiliary node, so that the second public network auxiliary node forwards the candidate address information in the third extended QUIC long header data packet to the second endpoint. The header of the third extended QUIC long header data packet has a forwarding flag set in the unused bits, and the payload carries the candidate address information of the first endpoint containing the first public network address. The first endpoint receives a fourth extended QUIC long header data packet forwarded by the second endpoint through the first public network auxiliary node. The payload of the fourth extended QUIC long header data packet carries candidate address information of the second endpoint, including the second public network address of the second endpoint after network address translation. The first endpoint sends a QUIC data packet carrying a hole punching request frame directly to the second endpoint based on the second public network address, so as to establish a direct communication path with the second endpoint.

2. The peer-to-peer communication method based on the QUIC protocol extension according to claim 1, characterized in that, The first endpoint obtains the address information of the second public network auxiliary node associated with the second endpoint, including: The first endpoint initiates a DNS resolution request to the Domain Name System for the domain name of the second endpoint; The first endpoint receives an extended resource record returned by the domain name system, the extended resource record containing address information of at least one second public network auxiliary node associated with the second endpoint.

3. The peer-to-peer communication method based on the QUIC protocol extension according to claim 1, characterized in that, The first extended QUIC long header data packet, the second extended QUIC long header data packet, the third extended QUIC long header data packet, and the fourth extended QUIC long header data packet all adopt the header format of the QUIC version negotiation packet, and the unused bits in the header are the six unused fields in the QUIC version negotiation packet header; In the first extended QUIC long header data packet, the six-bit unused field includes a STUN flag bit set to a value indicating the STUN data packet type, and a STUN type flag bit set to a value indicating the STUN request type; In the second extended QUIC long header data packet, the six-bit unused field includes a STUN flag bit set to a value indicating the STUN data packet type, and a STUN type flag bit set to a value indicating the STUN response type; In the third extended QUIC long header data packet, the six-bit unused field contains a forwarding flag bit and is set to a value indicating the type of forwarded data packet; In the fourth extended QUIC long header data packet, the six-bit unused field contains a forwarding flag bit and is set to a value indicating the type of forwarded data packet; In the first extended QUIC long header data packet, the second extended QUIC long header data packet, the third extended QUIC long header data packet, and the fourth extended QUIC long header data packet, the six-bit unused field also includes a source endpoint network type flag bit, which is used to identify whether the source endpoint is a public network endpoint or an internal network endpoint; And the target endpoint network type flag, used to identify whether the target endpoint is a public network endpoint or an internal network endpoint.

4. The peer-to-peer communication method based on the QUIC protocol extension according to claim 1, characterized in that, The first endpoint, based on the second public IP address, directly sends a QUIC data packet carrying a hole punching request frame to the second endpoint to establish a direct communication path with the second endpoint, including: The first endpoint constructs a PUNCH_HELLO frame and sends it directly to the second endpoint based on the second public network address. The PUNCH_HELLO frame contains a first sequence number corresponding to the local address of the first endpoint and a second sequence number corresponding to the second public network address. The PUNCH_HELLO frame is encapsulated in a QUIC data packet to bypass the QUIC reliable transmission control mechanism. The first endpoint receives the PUNCH_DONE frame returned directly by the second endpoint after receiving the PUNCH_HELLO frame. The PUNCH_DONE frame contains the address sequence number corresponding to the PUNCH_HELLO frame. The first endpoint confirms that the direct communication path with the second endpoint has been successfully established based on the received PUNCH_DONE frame.

5. The peer-to-peer communication method based on the QUIC protocol extension according to claim 1, characterized in that, When there is at least one available network path between the first endpoint and the second endpoint, the first endpoint sends the third extended QUIC long header data packet to the second public network auxiliary node based on the address information of the second public network auxiliary node, including: the first endpoint sends the third extended QUIC long header data packet through the at least one available network path; The first endpoint directly sends a QUIC data packet carrying a hole punching request frame to the second endpoint, including: the first endpoint sending the QUIC data packet carrying the hole punching request frame through the at least one available network path; When a hole punching request is successful on any available network path, the first endpoint establishes a direct communication path with the second endpoint through the successfully punched network path.

6. The peer-to-peer communication method based on the QUIC protocol extension according to claim 1, characterized in that, When the direct communication path between the first endpoint and the second endpoint fails to be established, the method further includes: The first endpoint constructs a first extended QUIC short header data packet and sends it to any reachable node in the decentralized auxiliary node cluster. The reachable node forwards the first extended QUIC short header data packet to the second public network auxiliary node associated with the second endpoint based on the target address information. The second public network auxiliary node then delivers the application data to the second endpoint. The Spin Bit of the header of the first extended QUIC short header data packet is redefined as a forwarding flag bit and set to a first value. The payload carries the application data to be sent and the target address information of the second endpoint.

7. The peer-to-peer communication method based on the QUIC protocol extension according to claim 6, characterized in that, The decentralized auxiliary node cluster is formed by multiple endpoints in the network that are publicly reachable through a distributed hash table, and all of these endpoints run the QUIC protocol extension.

8. The peer-to-peer communication method based on the QUIC protocol extension according to any one of claims 1 to 7, characterized in that, During the connection request initiated by the first endpoint to the second endpoint and subsequent communication interactions, each instruction data sent by the first endpoint carries a digital signature generated using the first endpoint's private key. The second endpoint authenticates the digital signature based on the domain name of the first endpoint and decides whether to respond to the instruction data according to a preset access policy based on domain name identity.

9. A computer device, characterized in that, The computer device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, can implement the method as described in any one of claims 1-8.

Images