Packet transmission method and apparatus, electronic device, related medium, and program product

Abstract

The present disclosure provides a packet transmission method and apparatus, an electronic device, a related medium, and a program product. The packet transmission method comprises: generating a data packet, a first field in the data packet having a first original port number; on the basis of a congestion window value corresponding to a current routing period of a sending device, determining that a first original path from the sending device to a receiving device is congested; selecting, from a first candidate port number set, a first virtual port number corresponding to the current routing period, updating the first field with the first virtual port number, and placing the first original port number in a second field of the data packet, the first virtual port number being used to perform routing computation to obtain a first alternative path from the sending device to the receiving device; and sending the data packet, such that the receiving device, after receiving the data packet, extracts the first original port number from the second field, and updates the first field with the first original port number to perform transport layer protocol processing.

Description

Message transmission methods, devices, electronic equipment, related media and software products

[0001] Cross-references to related applications

[0002] This application claims priority to Chinese Patent Application No. 202411921728.8, filed on December 23, 2024, entitled "Message Transmission Method, Apparatus, Electronic Device, Related Media and Program Product", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to the field of computers, and in particular to a message transmission method, apparatus, electronic device, related media, and program product.

[0004] Background of the Invention

[0005] Modern communication networks, such as IPv4 networks, are often designed with convergent bandwidth to reduce costs and minimize average traffic intensity. This means the total uplink bandwidth is less than the total downlink bandwidth, with a ratio often reaching 1:3 or even 1:6. In such networks, multiple data streams frequently traversing the same physical link can cause network congestion.

[0006] To address this, related technologies provide congestion control schemes, which maintain stable network operation by detecting the degree of network congestion and adjusting the transmission rate of the sending end accordingly. Summary of the Invention

[0007] This disclosure provides a message transmission method, apparatus, electronic device, related medium, and program product that can solve congestion problems by switching routes, and the switching process does not affect the transport layer protocol processing, thereby effectively improving message transmission efficiency.

[0008] According to one aspect of this disclosure, a message transmission method is provided, applied to a sending device; the message transmission method includes:

[0009] Generate a data packet; wherein, the first field in the data packet has a first original port number;

[0010] Based on the congestion window value corresponding to the current routing period of the transmitting device, it is determined that the first original path from the transmitting device to the receiving device is congested.

[0011] Select the first virtual port number corresponding to the current routing period from the first candidate port number set, update the first field with the first virtual port number, and place the first original port number in the second field of the data packet; the first virtual port number is used to perform routing calculations to obtain a first alternative path from the sending device to the receiving device.

[0012] The data packet is sent so that after the receiving device receives the data packet, it can extract the first original port number from the second field and update the first field with the first original port number for transport layer protocol processing.

[0013] According to one aspect of this disclosure, a message transmission method is provided, applied to a receiving device; the message transmission method includes:

[0014] A data packet is received from a sending device; wherein the data packet has a first field and a second field, the first field having a first virtual port number and the second field having a first original port number; the first virtual port number is selected by the sending device from a first set of candidate port numbers when the first original path from the sending device to the receiving device is congested based on the congestion window value corresponding to the current routing period of the sending device; the first virtual port number is used to perform routing calculations to obtain a first alternative path from the sending device to the receiving device;

[0015] The first original port number is extracted from the second field, and the first field is updated with the first original port number for transport layer protocol processing.

[0016] According to one aspect of this disclosure, a message transmission apparatus is provided, applied to a transmitting device; the message transmission apparatus includes:

[0017] A data packet generation module is used to generate data packets; wherein, the first field in the data packet has a first original port number;

[0018] The first congestion determination module is used to determine, based on the congestion window value corresponding to the current routing period of the transmitting device, that the first original path from the transmitting device to the receiving device is congested.

[0019] The data packet encapsulation module is used to select a first virtual port number corresponding to the current routing period from the first candidate port number set, update the first field with the first virtual port number, and place the first original port number in the second field of the data packet; the first virtual port number is used to perform routing calculations to obtain a first alternative path from the sending device to the receiving device.

[0020] The data packet sending module is used to send the data packet so that after the receiving device receives the data packet, it can extract the first original port number from the second field and update the first field with the first original port number for transport layer protocol processing.

[0021] According to one aspect of this disclosure, a message transmission apparatus is provided for use in a receiving device; the message transmission apparatus includes:

[0022] A data packet receiving module is used to receive data packets from a sending device; wherein, the data packet has a first field and a second field, the first field having a first virtual port number, and the second field having a first original port number; the first virtual port number is selected by the sending device from a first candidate port number set when the sending device determines that the first original path from the sending device to the receiving device is congested based on the congestion window value corresponding to the current routing period of the sending device; the first virtual port number is used to perform routing calculations to obtain a first alternative path from the sending device to the receiving device;

[0023] The data packet decapsulation module is used to extract the first original port number from the second field and update the first field with the first original port number for transport layer protocol processing.

[0024] According to one aspect of this disclosure, an electronic device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the message transmission method as described above.

[0025] According to one aspect of this disclosure, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program that, when executed by a processor, implements the message transmission method as described above.

[0026] According to one aspect of this disclosure, a computer program product is provided, the computer program product including a computer program that is read and executed by a processor of an electronic device, causing the electronic device to perform the message transmission method as described above.

[0027] Brief description of the attached figures

[0028] The accompanying drawings are provided to further understand the technical solutions of this disclosure and constitute a part of the specification. They are used together with the embodiments of this disclosure to explain the technical solutions of this disclosure and do not constitute a limitation on the technical solutions of this disclosure.

[0029] Figure 1A is a first architecture diagram of a system for applying the message transmission method provided in an embodiment of this disclosure;

[0030] Figure 1B is a second architecture diagram of the system for which the message transmission method provided in the embodiments of this disclosure is applied;

[0031] Figure 1C is a third architecture diagram of the system to which the message transmission method provided in the embodiments of this disclosure is applied;

[0032] Figure 2 is a schematic diagram of the message transmission method provided in this embodiment applied to a data center network scenario;

[0033] Figure 3 is a schematic diagram of the message transmission method provided in this embodiment of the present disclosure applied to a Redis data service scenario;

[0034] Figure 4 is a schematic diagram of the message transmission method provided in this embodiment applied to a cloud disk storage scenario;

[0035] Figure 5 is a general flowchart of the message transmission method provided in the embodiments of this disclosure;

[0036] Figure 6 is a schematic diagram of the TCP / IP protocol stack model provided in the embodiments of this disclosure;

[0037] Figure 7 is a schematic diagram of the exponential growth algorithm provided in an embodiment of this disclosure;

[0038] Figure 8 is another schematic diagram of the exponential growth algorithm provided in the embodiments of this disclosure;

[0039] Figure 9 is a schematic diagram of the congestion avoidance algorithm provided in an embodiment of this disclosure;

[0040] Figure 10 is a schematic diagram of the timeout retransmission algorithm provided in the embodiments of this disclosure;

[0041] Figure 11 is a schematic diagram of a retransmission algorithm based on duplicate acknowledgments provided in an embodiment of this disclosure;

[0042] Figure 12 is a schematic diagram of virtual tunnel encapsulation in step 530 of Figure 5;

[0043] Figure 13 is a schematic diagram of path switching provided in an embodiment of this disclosure;

[0044] Figure 14 is a schematic diagram of routing operations provided in an embodiment of this disclosure;

[0045] Figure 15 is a schematic diagram of virtual tunnel decapsulation in step 550 of Figure 5;

[0046] Figure 16 is a specific flowchart of step 520 in Figure 5;

[0047] Figure 17 is a detailed flowchart of steps 530 and 550 in Figure 5;

[0048] Figure 18 is a schematic diagram of virtual tunnel encapsulation performed in steps 1710 to 1730 of Figure 17;

[0049] Figure 19 is a schematic diagram of the virtual tunnel decapsulation process in step 1740 of Figure 17;

[0050] Figure 20 is another specific flowchart about steps 530 and 550 in Figure 5;

[0051] Figure 21 is a schematic diagram of virtual tunnel encapsulation in step 2010 of Figure 20;

[0052] Figure 22 is a schematic diagram of the virtual tunnel decapsulation process in step 2020 of Figure 20;

[0053] Figure 23 is another specific flowchart about steps 530 and 550 in Figure 5;

[0054] Figure 24 is a schematic diagram of virtual tunnel encapsulation in step 2310 of Figure 23;

[0055] Figure 25 is a schematic diagram of the virtual tunnel decapsulation process in step 2320 of Figure 23;

[0056] Figure 26 is another specific flowchart about steps 530 and 550 in Figure 5;

[0057] Figure 27 is a specific flowchart of step 530 in Figure 5;

[0058] Figure 28 is another specific flowchart regarding step 530 in Figure 5;

[0059] Figure 29 is another specific flowchart regarding step 530 in Figure 5;

[0060] Figure 30 is another specific flowchart regarding step 530 in Figure 5;

[0061] Figure 31 is another specific flowchart about steps 530 and 550 in Figure 5;

[0062] Figure 32 is a schematic diagram of virtual tunnel encapsulation in step 3110 of Figure 31;

[0063] Figure 33 is a schematic diagram of the virtual tunnel decapsulation in step 3120 of Figure 31;

[0064] Figure 34 is another specific flowchart about steps 530 and 550 in Figure 5;

[0065] Figure 35 is a schematic diagram of virtual tunnel encapsulation in step 3410 of Figure 34;

[0066] Figure 36 is a schematic diagram of the virtual tunnel decapsulation in step 3420 of Figure 34;

[0067] Figure 37 is a schematic diagram of the virtual tunnel encapsulation-decapsulation process for implementing acknowledgment messages based on Figure 5;

[0068] Figure 38 is a schematic diagram of virtual tunnel encapsulation in step 3730 of Figure 37;

[0069] Figure 39 is a schematic diagram of the virtual tunnel decapsulation process in step 3750 of Figure 37;

[0070] Figure 40 is a flowchart illustrating the data packet verification process based on Figure 5;

[0071] Figure 41 is a schematic diagram of virtual tunnel encapsulation in step 4010 of Figure 40;

[0072] Figure 42 is a schematic diagram of the virtual tunnel decapsulation process in step 4030 of Figure 40;

[0073] Figure 43 is a flowchart illustrating a two-layer verification process for data packets based on Figure 40.

[0074] Figure 44 is a schematic diagram of virtual tunnel encapsulation in step 4310 of Figure 43;

[0075] Figure 45 is a schematic diagram of virtual tunnel decapsulation in step 4330 of Figure 43;

[0076] Figure 46 is another flowchart illustrating the implementation of two-layer verification of data packets based on Figure 40;

[0077] Figure 47 is a schematic diagram of the virtual tunnel decapsulation in step 4620 of Figure 46;

[0078] Figure 48 is a schematic diagram of an IPv4 network using the TCP protocol provided in an embodiment of this disclosure;

[0079] Figure 49 is another schematic diagram of an IPv4 network using the TCP protocol provided in an embodiment of this disclosure;

[0080] Figure 50 is a schematic diagram of a custom module in a server provided in an embodiment of this disclosure;

[0081] Figure 51 is a schematic diagram of the connection components and custom sublayers in the server provided in an embodiment of this disclosure;

[0082] Figure 52 is a schematic diagram of the TCP connection for message transmission provided in an embodiment of this disclosure;

[0083] Figure 53 is a schematic diagram of the TCP packet header provided in an embodiment of this disclosure;

[0084] Figure 54 is a schematic diagram of virtual tunnel encapsulation according to path control logic provided in an embodiment of this disclosure;

[0085] Figure 55 is a schematic diagram of virtual tunnel decapsulation according to path control logic provided in an embodiment of this disclosure;

[0086] Figure 56 is a schematic diagram of virtual tunnel encapsulation based on custom fields provided in an embodiment of this disclosure;

[0087] Figure 57 is a schematic diagram of virtual tunnel decapsulation based on custom fields provided in an embodiment of this disclosure;

[0088] Figure 58 is a schematic diagram comparing the experimental results of the embodiments of this disclosure with related technologies;

[0089] Figure 59 is a block diagram of a message transmission device applied to a sending device according to an embodiment of the present disclosure;

[0090] Figure 60 is a block diagram of a message transmission device applied to a receiving device according to an embodiment of the present disclosure;

[0091] Figure 61 is a terminal structure diagram of the implementation of the message transmission method provided in the embodiments of this disclosure;

[0092] Figure 62 is a server structure diagram of the implementation of the message transmission method provided in the embodiments of this disclosure.

[0093] Methods of implementing the present invention

[0094] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this disclosure.

[0095] Before providing a further detailed description of the embodiments of this disclosure, the terms and concepts used in these embodiments are explained, and they are subject to the following interpretations:

[0096] 1) Message transmission network: This generally refers to a network architecture that includes sending devices, receiving devices, and multiple forwarding devices. For example, a message transmission network can be a data center network. A data center network is an infrastructure used to provide network, storage, and computing resources to support enterprises or data center tenants in performing a wide range of workloads. The core components of a data center network include multiple servers and multiple switches, where servers are used as sending or receiving devices, and switches are used as forwarding devices.

[0097] 2) Congestion Control: By detecting congestion along the communication path and dynamically adjusting the sending rate of the transmitting end (sending device), excessive data injection into the communication path can prevent overload of forwarding devices. In the congestion control algorithm, a congestion window (cwnd) is maintained for each communication connection. The congestion window determines the maximum amount of data the transmitting end can send within a round-trip time (RTT). The size (value) of the congestion window is dynamically adjusted based on the current congestion level of the communication path. If the communication path becomes more congested, the congestion window value decreases; if the communication path becomes smoother, the congestion window value increases.

[0098] 3) Equal Cost Multi Path (ECMP): This is a technique that selects multiple equivalent communication paths in a message transmission network and distributes traffic across these paths to achieve load balancing and network redundancy.

[0099] 4) Communication connection: refers to the communication connection between the sending device and the receiving device.

[0100] 5) Communication path: refers to the combination of a series of forwarding devices and links that the transmitting device and the receiving device must pass through to transmit messages.

[0101] 6) Transport Layer Protocols: These are communication protocols located at the transport layer in a computer network architecture. Their main function is to provide end-to-end communication services between processes (or applications, services) on different devices. Transport layer protocols have port addressing capabilities, meaning they use port numbers to identify different processes. The port number is a crucial concept in the transport layer; it can be seen as a identifier used by a device to distinguish different processes. For example, when accessing a webpage through a browser on a computer, the browser process uses a specific port number to communicate with the corresponding web process on the server. This allows data to be accurately transmitted between specific processes on different devices.

[0102] The inventors of this application discovered that:

[0103] In message transmission networks, equal-cost multipath routing hash algorithms are widely used for routing, which selects one communication path from multiple equivalent communication paths for message transmission. However, in practical message transmission networks, to reduce costs and minimize average traffic intensity, they are often designed with bandwidth convergence, meaning the total uplink bandwidth is less than the total downlink bandwidth, often in a ratio of 1:3 or even 1:6. In such networks, some degree of hash polarization inevitably occurs, where multiple data streams transmit through the same communication path, leading to congestion on that path.

[0104] In related technologies, the 5-tuple (including source port number, destination port number, etc.) in the messages transmitted between the sending and receiving devices is usually fixed. This is mainly because the 5-tuple is used for connection identification in the transport layer protocol. Changing some information in the 5-tuple will affect the connection identification of the transport layer protocol, leading to communication interruption. Simultaneously, forwarding devices in the message transmission network typically select routes based on the 5-tuple in the message, which means that the sending device can only send messages to the receiving device along a fixed communication path. When congestion occurs on the communication path from the sending device to the receiving device, related technologies can only use congestion control schemes to control the sending rate of the sending device, resulting in low message transmission efficiency and throughput significantly lower than ideal.

[0105] The congestion control schemes provided by related technologies have to tolerate congestion, which in turn affects message transmission efficiency. Modern message transmission networks are very sensitive to message throughput and latency. A decrease in throughput will directly reduce the input output per second (IOPS) of the application layer, and the increase in latency caused by congestion may significantly increase service latency. Both throughput degradation and latency degradation may violate service commitment terms.

[0106] In response to this, embodiments of this disclosure provide a message transmission method, apparatus, electronic device, related medium, and program product that can solve congestion problems by switching routes, and the switching process does not affect the transport layer protocol processing, thereby effectively improving message transmission efficiency.

[0107] System architecture and scenario description of the embodiments disclosed herein

[0108] Figure 1A is a first system architecture diagram of the message transmission method provided in the embodiments of this disclosure, which includes a terminal 130, a forwarding device 120, a server 110, etc.

[0109] Terminal 130 can take various forms, including desktop computers, laptops, personal digital assistants (PDAs), mobile phones, in-vehicle terminals, and dedicated terminals. Furthermore, it can be a single device or a collection of multiple devices. For example, multiple desktop computers connected via a local area network, sharing a single monitor, can work collaboratively to form a single terminal 130. Terminal 130 can communicate with relay device 120 via wired or wireless means to exchange data.

[0110] Server 110 refers to a computer system capable of providing certain services to terminal 130. Compared to ordinary terminal 130, server 110 has higher requirements in terms of stability, security, and performance. Server 110 can be a single high-performance computer in a network platform, a cluster of multiple high-performance computers, a portion of a single high-performance computer (e.g., a virtual machine), or a combination of portions of multiple high-performance computers (e.g., virtual machines). Server 110 can also communicate with forwarding device 120 via wired or wireless means to exchange data.

[0111] Forwarding device 120 is used to realize message transmission between different network nodes (network nodes refer to terminal 130 or server 110) in the message transmission network. Forwarding device 120 typically has multiple physical ports, through which multiple network nodes can be connected. Forwarding device 120 can be a switch or router, or other device capable of receiving and forwarding messages. Messages sent from terminal 130 to server 110 must reach the corresponding server 110 through forwarding device 120; messages sent from server 110 to terminal 130 must also reach the corresponding terminal 130 through forwarding device 120. In Figure 1A, terminal 130 can act as a sending device and server 110 can act as a receiving device; or, server 110 can act as a sending device and terminal 130 can act as a receiving device, without limitation.

[0112] Figure 1B is a second system architecture diagram of the message transmission method provided in the embodiments of this disclosure. It includes a forwarding device 120 and a server 110, etc., wherein some servers 110 are used as sending devices and other servers 110 are used as receiving devices.

[0113] Figure 1C is a third system architecture diagram of the message transmission method provided in the embodiments of this disclosure. It includes a terminal 130 and a server 110, wherein some terminals 130 are used as sending devices and other terminals 130 are used as receiving devices.

[0114] The embodiments disclosed herein can be applied in various scenarios, such as the data center network scenario shown in Figure 2, the Redis data service scenario shown in Figure 3, and the cloud disk storage scenario shown in Figure 4.

[0115] (I) Data center network scenario.

[0116] Data center networks typically use a Clos / Fat-tree architecture (Layer 3 or Layer 2 switches), as shown in Figure 2. A data center network has three layers of switches: access layer (Leaf), aggregation layer (Spine), and core layer (Core). It also includes a host layer, where servers act as sending or receiving devices, and Layer 3 switches act as forwarding devices. An access layer switch and all its downstream servers are collectively called a rack. For example, access layer switches L0 and L1, along with downstream servers H0 and H1, are collectively called rack 0. An access layer switch, along with all its upstream aggregation layer switches and downstream servers, are collectively called a network module (Pod). For example, access layer switches L0, L1, L2, and L3, along with upstream aggregation layer switches S0, S1, S2, and S3, and downstream servers H0, H1, H2, and H3, are collectively called network module 0. It is worth noting that in data center networks, in order to increase the communication bandwidth and connection reliability between servers, servers can be connected to different access layer switches through multiple links. For example, in Figure 2, server H0 is connected to access layer switch L0 through one physical port and to access layer switch L1 through another physical port. The physical port of the server is the network interface card (NIC) port.

[0117] Taking the example in Figure 2 where servers H0 and H4 are connected and the original path from server H0 to server H4 is H0-L0-S0-C0-S4-L4-H4, server H0 acts as the sending device and server H4 as the receiving device. The symbol "-" in the original path indicates a physical link; for example, "H0-L0" means that server H0 and access layer switch L0 are connected via a physical link. In the case of the original path H0-L0-S0-C0-S4-L4-H4, the data packets sent by server H0 will sequentially pass through access layer switch L0, aggregation layer switch S0, core layer switch C0, aggregation layer switch S4, and access layer switch L4 before finally reaching server H4.

[0118] In the solutions provided by related technologies, server H0, as the sending device, detects the congestion status of the original path H0-L0-S0-C0-S4-L4-H4 through a congestion control algorithm and adjusts the sending rate of server H0 according to the congestion status, without switching routes. This causes the communication connection between server H0 and H4 to suffer from low throughput due to congestion, even if there are other communication paths that are idle in the data center network.

[0119] By using the message transmission method provided in this embodiment, server H0 does not directly send the data packet after generating it. Instead, it first determines whether the original path H0-L0-S0-C0-S4-L4-H4 is congested based on the congestion window value corresponding to the current routing period of server H0. If it is determined that the original path H0-L0-S0-C0-S4-L4-H4 is congested, the first virtual port number corresponding to the current routing period of server H0 is selected from the first candidate port number set, and the first field of the data packet is updated with the first virtual port number. The original first port number in the first field of the data packet is placed in the second field of the data packet. In this way, virtual tunnel encapsulation of the data packet is realized. That is, the value of the first field of the data packet changes from the first original port number to the first virtual port number. The first virtual port number is used to perform routing calculations to obtain the replacement path from server H0 to server H4. Here, the replacement path is H0-L1-S1-C2-S5-L5-H4 as an example. Then, server H0 sends a data packet, which travels along the replacement path H0-L1-S1-C2-S5-L5-H4 to server H4. Upon receiving the data packet, server H4 extracts the first original port number from the second field of the data packet and updates the first field of the data packet with this first original port number. This achieves virtual tunnel decapsulation of the data packet, restoring the original data packet generated by server H0. Thus, the virtual tunnel encapsulation-decapsulation process is transparent to the transport layer protocol and does not disrupt the connection identification between server H0 and server H4.

[0120] In this embodiment of the disclosure, the field recording the port number in the data packet is set so that it can be replaced during the routing process and can be restored during the reception process. This achieves the effect of trying new path selection to solve the congestion problem without affecting the transport layer protocol processing, thereby improving the packet transmission efficiency and making it well applicable to data center networks with bandwidth convergence.

[0121] (ii) Redis data service scenario.

[0122] Figure 3 illustrates a terminal 340, an overlay network 330, a proxy server 320, and a basic network 310 (message transmission network). The basic network 310 is an underlay network, meaning it's a network established directly at the physical layer; for example, it could be a data center network. The overlay network 330 is an overlay network, created using virtualization technology. The proxy server 320 facilitates communication between the basic network 310 and the overlay network 330. The overlay network 330, proxy server 320, and basic network 310 work together to provide Redis data services to the terminal 340. The overlay network 330 can be considered the front-end of the Redis database, offering advantages in flexibility, security, and virtualization technology, thus meeting the external access and connection requirements of the Redis data service. The basic network 310 can be considered the back-end of the Redis database, focusing on high performance and stability to ensure the Redis data service can efficiently process data and provide services externally.

[0123] If the solutions provided by related technologies are applied in the basic network 310, problems such as terminal 340 request timeout and data loss will occur, which will seriously affect the availability and performance of Redis data services. For application scenarios that require high reliability and low latency (such as real-time data analysis and online transaction processing), the decline in service quality may lead to serious business losses. In addition, the basic network 310 and the overlay network 330 cannot exert their full performance, which can easily lead to a waste of computing resources.

[0124] If the message transmission method provided in this embodiment is applied to the basic network 310, the congestion problem faced by the basic network 310 can be solved quickly and effectively, giving full play to the performance of the basic network 310 itself, without limiting the performance of the overlay network 330; it can achieve efficient data processing, ensure high availability and timely feedback of Redis data services, and avoid serious business losses.

[0125] (III) Cloud disk storage scenario.

[0126] Figure 4 illustrates terminal 420 and basic network 410 (message transmission network). Basic network 410 is an underground network, meaning it's a network established directly at the physical layer; for example, it could be a data center network. Basic network 410 provides cloud disk storage services to terminal 420. This cloud disk storage service supports adding, deleting, modifying, and querying data. For instance, in response to a data storage request initiated by terminal 420, basic network 410 stores the data carried in the data storage request. Similarly, in response to a data read request initiated by terminal 420, basic network 410 queries the data required by the data read request from the data stored in basic network 410 and sends the retrieved data to terminal 420.

[0127] If the solution provided by the relevant technology is applied in the basic network 410, the requests initiated by the terminal 420 may not be processed in a timely manner or may even fail to be processed, which will seriously affect the service quality and availability of cloud disk storage services.

[0128] If the message transmission method provided in this embodiment is applied in the basic network 410, the basic network 410 can quickly respond to the request initiated by the terminal 420, achieve more effective data balancing, and improve the service quality and availability of cloud disk storage services; at the same time, it also helps to improve the flexibility and scalability of cloud disk storage services, and provides strong support for functions such as online expansion and contraction.

[0129] It is worth noting that the examples above only illustrate some application scenarios of this disclosure. The business scenarios to which this disclosure can be applied may include, but are not limited to, the specific embodiments described above.

[0130] General Description of Embodiments in this Disclosure

[0131] According to one embodiment of this disclosure, a message transmission method is provided. This method is applied to a message transmission network, which generally refers to a network architecture including a sending device, a receiving device, and multiple forwarding devices. For example, the message transmission network can be a data center network as shown in Figure 2. The sending device is an electronic device used to send data packets to the receiving device and receive acknowledgment packets from the receiving device; specifically, the sending device can be a terminal or a server. The receiving device is an electronic device used to receive data packets from the sending device and send acknowledgment packets back to the sending device; specifically, the receiving device can be a terminal or a server. The forwarding device is an electronic device capable of receiving and forwarding messages; for example, the forwarding device can be a switch or a router.

[0132] The message transmission method provided in this disclosure will now be described with reference to FIG5. For ease of explanation, the forwarding device is omitted in FIG5, but in reality, message transmission between the sending device and the receiving device needs to be achieved through the forwarding device.

[0133] As shown in Figure 5, a message transmission method according to an embodiment of the present disclosure includes:

[0134] Step 510: The sending device generates a data packet; wherein the first field in the data packet has the first original port number;

[0135] Step 520: The transmitting device determines that the first original path from the transmitting device to the receiving device is congested based on the congestion window value corresponding to the current routing cycle of the transmitting device;

[0136] Step 530: The sending device selects the first virtual port number corresponding to the current routing period from the first candidate port number set, updates the first field with the first virtual port number, and places the first original port number in the second field of the data packet; the first virtual port number is used to perform routing calculations to obtain the first alternative path from the sending device to the receiving device;

[0137] Step 540: The sending device sends a data packet;

[0138] Step 550: The receiving device extracts the first original port number from the second field and updates the first field with the first original port number for transport layer protocol processing.

[0139] Steps 510-550 are described in detail below.

[0140] In step 510, the sending device generates a data packet; wherein the first field in the data packet has a first original port number.

[0141] Once the sending device has established a communication connection with the receiving device, the sending device generates a data packet. The payload field of the data packet contains the service data that needs to be transmitted. The service data refers to the data that the sending device expects the receiving device to process. For example, it can be data that the sending device expects the receiving device to store, or data that the sending device expects the receiving device to calculate. There are no restrictions on this.

[0142] This disclosure does not limit the transport layer protocol used to establish the communication connection. For example, it can be a connection-oriented transport layer protocol, such as Transmission Control Protocol (TCP), Stream Control Transmission Protocol (SCTP), or Wireless Transaction Protocol (WTP). To facilitate understanding of the role of the transport layer, this disclosure provides a schematic diagram of the TCP / IP protocol stack model as shown in Figure 6. The TCP / IP protocol stack model is the basic communication architecture of the Internet. It divides network communication functions into different layers, each responsible for a specific task. Data transmission in the network is achieved through cooperation between the layers. Of course, other models besides the TCP / IP protocol stack model can also be used, such as the Open Systems Interconnection (OSI) model. Here, only the TCP / IP protocol stack model is used as an example for explanation. As shown in Figure 6, the TCP / IP protocol stack model includes the application layer, transport layer, network layer, and network interface layer. The application layer is the top layer, interacting directly with processes and defining how processes send data over the network. The transport layer defines port numbers to identify processes within a device and provides end-to-end data transmission services. The network layer defines Internet Protocol (IP) addresses to identify the network location of a device for routing and forwarding. The network interface layer defines data frames and transmits them across the physical network. The network interface layer can be further subdivided into the data link layer and the physical layer.

[0143] Next, taking the TCP / IP protocol stack model shown in Figure 6 as an example, we will explain the data transmission process between the sending device and the receiving device. For the transmitting device 610, the application layer transmits the service data to be transmitted to the transport layer; the transport layer encapsulates the service data into transport layer messages, which include a transport layer header (such as a TCP header) and a payload. The transport layer header adds information such as the port number, and the payload field is used to store the service data. Then, the transport layer message is transmitted to the network layer; the network layer encapsulates the transport layer message into a network layer message, which includes a network layer header (IP header), a transport layer header, and a payload. The network layer header adds information such as the IP address. Then, the network layer message is transmitted to the network interface layer; the network interface layer encapsulates the network layer message into a data frame (i.e., a data packet), which includes an Ethernet header (Eth header), a network layer header, a transport layer header, and a payload. The Ethernet header adds information such as the Media Access Control (MAC) address. Then, the network interface layer sends the data frame to the receiving device 620 via a physical link (such as a network cable). For the receiving device 620, after receiving the data frame, the service data can be obtained by unpacking the data frame in reverse order.

[0144] Based on the above examples, it can be seen that data packets have a port number field. Taking the TCP / IP protocol stack model as an example, the port number field is located in the transport layer header. For ease of distinction, the port number field in the data packet is named the first field, and the port number contained in the port number field of the data packet is named the first original port number. It is worth noting that the first original port number is the port number agreed upon when the sending device and the receiving device establish a communication connection, used to identify the communication connection between the sending device and the receiving device.

[0145] In step 520, the transmitting device determines that the first original path from the transmitting device to the receiving device is congested based on the congestion window value corresponding to the current routing period of the transmitting device.

[0146] Here, the process by which a sending device selects a communication path for a data packet is called a routing cycle (i.e., different routing cycles are for different data packets). The sending device can calculate the current congestion window value (real-time congestion window value) using a congestion control algorithm, and use it as the congestion window value corresponding to the current routing cycle. This disclosure does not limit the congestion control algorithm used. Next, four congestion control algorithms will be illustrated with examples.

[0147] (a) Exponential growth algorithm.

[0148] After the sending and receiving devices establish a communication connection, the exponential growth algorithm can be used. The strategy of the exponential growth algorithm is to increment the congestion window size by 1 each time the sending device receives an acknowledgment message. Therefore, during this stage, the congestion window size will grow exponentially, thereby quickly detecting network conditions.

[0149] As shown in Figures 7 and 8, when the transmitting and receiving devices first establish a communication connection, the congestion window value is initialized. For example, the congestion window value is initialized to 1, indicating that the transmitting device can send one maximum segment size (MSS) of data at a time, i.e., one data packet. Then, the transmitting device sends one data packet and receives a corresponding acknowledgment packet, and the congestion window value changes from 1 to 2, indicating that the transmitting device can send two MSS of data at a time. Then, the transmitting device sends two data packets and receives two corresponding acknowledgment packets, and the congestion window value changes from 2 to 4, indicating that the transmitting device can send four MSS of data at a time. Finally, the transmitting device sends four data packets and receives four corresponding acknowledgment packets, and the congestion window value changes from 4 to 8, indicating that the transmitting device can send eight MSS of data at a time.

[0150] The exponential growth algorithm also includes an exponential growth threshold. When the congestion window size is less than the exponential growth threshold, the exponential growth algorithm is used; when the congestion window size is greater than or equal to the exponential growth threshold, the congestion avoidance algorithm is used. Here, we take an exponential growth threshold of 8 as an example.

[0151] (ii) Congestion avoidance algorithm.

[0152] When the congestion window size is greater than or equal to the exponential growth threshold, the congestion avoidance algorithm is used. As shown in Figure 9, the strategy of the congestion avoidance algorithm is to increase the congestion window size each time the sending device receives an acknowledgment message, but the increase becomes 1 / congestion window size. Therefore, during the congestion avoidance phase, the congestion window size still increases, but the rate of increase changes from exponential to linear. This linear growth method can more stably increase the congestion window size of the sending device, avoiding network congestion caused by the congestion window size increasing too quickly, and achieving a balance between utilizing network bandwidth and preventing congestion.

[0153] (III) Congestion Occurrence Algorithm.

[0154] Congestion-causing algorithms are divided into timeout retransmission algorithms and retransmission algorithms based on duplicate acknowledgments.

[0155] 1) Timeout retransmission algorithm.

[0156] If, after a data packet is sent by the transmitting device, no acknowledgment packet is received within the retransmission timeout (RTO), a timeout retransmission algorithm is used. As shown in Figure 10, the strategy of the timeout retransmission algorithm is to reduce the exponentially growing threshold, initialize the congestion window value, and use an exponential growth algorithm. For example, the exponentially growing threshold can be updated to 1 / 2 or 1 / 3 of the congestion window value. Figure 10 illustrates updating the exponentially growing threshold from 8 to 6 (12 / 2). The timeout retransmission algorithm can quickly reduce the pressure on the network from the transmitting device, giving the network sufficient time to recover.

[0157] 2) Retransmission algorithm based on duplicate acknowledgments.

[0158] When the transmitting device receives duplicate acknowledgment messages, and the number of duplicate acknowledgment messages reaches a threshold, a duplicate acknowledgment-based retransmission algorithm is used. As shown in Figure 11, the strategy of the duplicate acknowledgment-based retransmission algorithm is to reduce the congestion window value, update the exponential growth threshold based on the congestion window value, and then use a duplicate acknowledgment-based recovery algorithm. Reducing the congestion window value can mean decreasing it to 1 / 2, 1 / 3, etc. Figure 11 uses the example of updating the congestion window value from 12 to 6 and the exponential growth threshold from 8 to 6.

[0159] (iv) Recovery algorithm based on duplicate confirmation.

[0160] As shown in Figure 11, the strategy of the duplicate acknowledgment-based recovery algorithm is as follows: The congestion window value is increased based on a threshold number. For example, if the threshold is 3, the congestion window value is increased by 3 (meaning 3 MSS are added). Figure 11 illustrates this by updating the congestion window value from 6 to 9. The sending device retransmits lost data packets. When the sending device receives a duplicate acknowledgment packet, the congestion window value is increased by 1. When the sending device receives a new acknowledgment packet (i.e., a non-duplicate acknowledgment packet), the congestion window value is updated according to the initial value of the exponential growth threshold, and the congestion avoidance phase is re-entered. Through the duplicate acknowledgment-based retransmission and recovery algorithms, the congestion window value does not experience a precipitous drop like in the timeout retransmission algorithm, but rather remains at a relatively high value and continues to grow linearly. This moderate adjustment allows for maintaining a high transmission rate even when the network experiences a certain degree of congestion, while avoiding excessive network load and enabling faster recovery to the congestion avoidance phase, thus continuing to effectively utilize network bandwidth.

[0161] Based on the above examples of congestion control algorithms, it can be seen that the congestion window value reflects the congestion status of the communication path; that is, the smaller the congestion window value, the more congested the communication path; and the larger the congestion window value, the less congested the communication path. Therefore, based on the congestion window value corresponding to the current routing period of the transmitting device, it can be determined whether the first original path from the transmitting device to the receiving device is congested. For example, when the congestion window value corresponding to the current routing period of the transmitting device is less than the congestion window value threshold, it is determined that the first original path from the transmitting device to the receiving device is congested; when the congestion window value corresponding to the current routing period of the transmitting device is greater than or equal to the congestion window value threshold, it is determined that the first original path from the transmitting device to the receiving device is not congested. The congestion window value threshold can be set according to the throughput requirements of the communication connection; for example, the higher the throughput requirements of the communication connection, the larger the congestion window value threshold can be set.

[0162] The first original path refers to the communication path used by the sending device in the previous routing cycle of the current routing cycle. If the previous routing cycle did not use virtual tunnel encapsulation, the first original path is obtained by routing calculation based on the first original port number; if the previous routing cycle used virtual tunnel encapsulation, the first original path is obtained by routing calculation based on the virtual port number corresponding to the previous routing cycle. It is worth noting that virtual tunnel encapsulation refers to the port number encapsulation method in step 530. Next, we will illustrate this with two scenarios using Figure 2.

[0163] (a) Scenarios in which virtual tunnel encapsulation was not used in the previous routing cycle.

[0164] For example, if virtual tunnel encapsulation is not used in routing period 1, the sending device will directly send out the generated data packet 1 for data packet 1 generated in routing period 1. At this time, the port number field of data packet 1 has the first original port number. The first original port number is used to perform routing calculations to obtain the first original path from the sending device to the receiving device. For example, the first original path is H0-L0-S0-C0-S4-L4-H4.

[0165] In routing period 2 following routing period 1, the transmitting device obtains the congestion window value corresponding to routing period 2 through the congestion control algorithm, and determines whether the first original path H0-L0-S0-C0-S4-L4-H4 from the transmitting device to the receiving device is congested based on the congestion window value corresponding to routing period 2.

[0166] (ii) Scenarios where virtual tunnel encapsulation was used in the previous routing cycle.

[0167] For example, if virtual tunnel encapsulation is used in routing period 1, the sending device processes data packet 1 generated in routing period 1 according to steps 520 to 540. At this time, the port number field of data packet 1 has the virtual port number corresponding to routing period 1. The virtual port number corresponding to routing period 1 is used to perform routing calculations to obtain the first original path from the sending device to the receiving device. For example, the first original path is H0-L0-S0-C1-S4-L4-H4.

[0168] In routing period 2 following routing period 1, the transmitting device obtains the congestion window value corresponding to routing period 2 through the congestion control algorithm, and determines whether the first original path H0-L0-S0-C1-S4-L4-H4 from the transmitting device to the receiving device is congested based on the congestion window value corresponding to routing period 2.

[0169] In step 530, the sending device selects the first virtual port number corresponding to the current routing period from the first candidate port number set, updates the first field with the first virtual port number, and places the first original port number in the second field of the data packet; the first virtual port number is used to perform routing calculations to obtain the first alternative path from the sending device to the receiving device.

[0170] When it is determined that the first original path from the sending device to the receiving device is not congested, it proves that the first original path is still available, and therefore the data packet can continue to be transmitted along the first original path. Specifically, this can be divided into two cases: when it is determined that the first original path from the sending device to the receiving device is not congested and virtual tunnel encapsulation was not used in the previous routing cycle, the sending device keeps the first field in the data packet unchanged, that is, it does not update the first field. In this way, when the sending device sends subsequent data packets, it will perform routing calculations based on the first original port number, so that the data packet reaches the receiving device along the first original path. The above method only uses virtual tunnel encapsulation when necessary, which can save the additional overhead of virtual tunnel encapsulation and decapsulation; when it is determined that the first original path from the sending device to the receiving device is not congested, Furthermore, when virtual tunnel encapsulation was used in the previous routing cycle, the virtual port number corresponding to the previous routing cycle was used as the first virtual port number corresponding to the current routing cycle. The first field was updated with the first virtual port number, and the first original port number was placed in the second field of the data packet. In this way, when the sending device sends a data packet, it will perform routing calculations based on the virtual port number corresponding to the previous routing cycle, so that the data packet reaches the receiving device along the first original path. The above method continuously uses virtual tunnel encapsulation, which can avoid various problems that may occur during the process of switching from never using virtual tunnel encapsulation to using virtual tunnel encapsulation, and ensure the consistency of packet processing.

[0171] When congestion is detected on the first original path from the sending device to the receiving device, it indicates that the first original path is unavailable. To resolve the congestion issue, as shown in Figure 12, the sending device selects (e.g., randomly selects or uses other selection methods) the first virtual port number corresponding to the current routing period from the first candidate port number set, updates the first field with the first virtual port number, and places the first original port number in the second field of the data packet. The first virtual port number is used for routing calculations to obtain the first alternative path from the sending device to the receiving device. The above process is equivalent to encapsulating the data packet with a virtual tunnel based on the first virtual port number. The data packet encapsulated with the virtual tunnel will be transmitted in the virtual tunnel (i.e., the first alternative path) corresponding to the first virtual port number. Figure 13 shows the path switching process. The first original path from the sending device to the receiving device is H0-L0-S0-C0-S4-L4-H4. After encapsulating with a virtual tunnel based on the first virtual port number, the first alternative path from the sending device to the receiving device is H0-L1-S1-C2-S5-L5-H4.

[0172] The first candidate port number set may include one or more candidate port numbers other than the first original port number. For example, a range of port numbers for the transmitting device (including all available port numbers) can be determined, and all or some of the port numbers in the range other than the first original port number can be included in the first candidate port number set. In this way, invalid switching caused by the selection of the first virtual port number being the same as the first original port number can be avoided.

[0173] Step 530 can be executed at the transport layer, that is, during the process of the sending device generating a data packet.

[0174] The second field can be a field that does not participate in routing calculations or affect connection identification. Taking the TCP protocol as an example, the second field can be the Option field in the TCP header.

[0175] Routing calculations can be performed solely based on port numbers, or they can be combined with other elements. For example, routing calculations can be performed on 5-tuples (source IP address, destination IP address, transport layer protocol type, source port number, destination port number), 4-tuples (source IP address, destination IP address, source port number, destination port number), or 7-tuples (source IP address, destination IP address, transport layer protocol type, source port number, destination port number, service type, interface index). There are no restrictions on this.

[0176] Next, taking the routing operation based on the 5-tuple and using a routing hash algorithm as an example, the routing operation process will be explained. This disclosure provides a schematic diagram of the routing operation shown in Figure 14, which will be explained step-by-step:

[0177] 1) Based on the destination IP address in the data packet, the sending device determines multiple equivalent communication paths in the packet transmission network that can reach the destination IP address. Based on the physical ports (referring to the physical ports in the sending device) that these communication paths need to pass through, a candidate physical port list is constructed, such as [8, 9, 10, 11], where 8 represents the sequence number (identifier) ​​of the physical port.

[0178] 2) The sending device performs a hash calculation on the five-tuple in the data packet to obtain the hash value;

[0179] 3) The sending device performs a modulo operation between the hash value and the length of the candidate physical port list to obtain the target index number of the candidate physical port list. Then, it determines the physical port corresponding to the target index number in the candidate physical port list as the physical port for sending data packets.

[0180] For example, if the hash value obtained by hashing the quintuple in the data packet is 13, and the length of the candidate physical port list [8, 9, 10, 11] is 4, then the target index number obtained by performing the modulo operation is 1. Thus, the second-ranked physical port 9 in the candidate physical port list [8, 9, 10, 11] is determined to be used to send the data packet. The index number of the candidate physical port list is calculated starting from 0.

[0181] In the example above, each physical port in the candidate physical port list is connected to a forwarding device. Therefore, when the sending device determines the physical port used to send the data packet, it is equivalent to determining which forwarding device the data packet will hop to for the first hop in the packet transmission network.

[0182] It's worth noting that routing algorithms also apply to both forwarding and receiving devices in packet transmission networks. Furthermore, port numbers and physical ports differ in meaning. Port numbers are a transport layer concept used to distinguish different processes within a device; while physical ports are interfaces within a device used to connect to physical media (such as network cables or fiber optic cables), enabling the device to connect to external physical links.

[0183] Figure 14 also illustrates a hash seed, which is a random number or string used to initialize a hash function (used to perform hash calculations). In embodiments of this disclosure, different hash seeds can be configured for different electronic devices in the message transmission network, and / or different hash functions can be configured for different electronic devices in the message transmission network, thereby introducing differentiation and minimizing hash polarization.

[0184] In step 540, the transmitting device sends a data packet.

[0185] After encapsulating the data packet with a virtual tunnel according to the first virtual port number, the sending device sends the data packet. In this way, the data packet will reach the receiving device along the first alternative path. Taking the first alternative path as H0-L1-S1-C2-S5-L5-H4 as an example, the data packet sent by server H0 will pass through access layer switch L1, aggregation layer switch S1, core layer switch C2, aggregation layer switch S5, and access layer switch L5 in sequence, and finally reach server H4.

[0186] In step 550, the receiving device extracts the first raw port number from the second field and updates the first field with the first raw port number for transport layer protocol processing.

[0187] After receiving a data packet, as shown in Figure 15, the receiving device extracts the first original port number from the second field and updates the first field with the first original port number. This achieves virtual tunnel decapsulation of the data packet, enabling transport layer protocol processing based on the data packet. Since the first field in the data packet contains the first original port number, the receiving device can identify that the data packet is generated based on the communication connection between the sending and receiving devices during transport layer protocol processing, without compromising the identification of the communication connection. The transport layer protocol processing is determined by the communication model (such as the TCP / IP protocol stack model) used by the packet transmission network, and may include processes such as congestion control, unpacking the data packet, and passing it to the application layer.

[0188] It is worth noting that before step 550, the receiving device has already performed network interface layer protocol processing and network layer protocol processing on the data packet.

[0189] In steps 510 to 550 above, the field recording the port number in the data packet is set so that it can be replaced during routing and restored during reception, thus not affecting the transport layer protocol processing. Specifically, after determining that the first original path from the sending device to the receiving device is congested, a first virtual port number is selected from the first candidate port number set to try a new path, and the field recording the port number, i.e., the first field, is updated with the first virtual port number. The first virtual port number is used to select a new path, but the first original port number is needed in subsequent transport layer protocol processing. Therefore, in this embodiment, the first original port number is placed in the second field so that after the receiving device receives the data packet, it can restore the first original port number according to the second field, thereby achieving the effect of trying a new path to solve the congestion problem without affecting the transport layer protocol processing, thus improving the packet transmission efficiency.

[0190] The above is a general description of steps 510 to 550. Below, we will focus on a more detailed description of steps 520 and 530.

[0191] Detailed description of step 520

[0192] In step 520, the transmitting device determines that the first original path from the transmitting device to the receiving device is congested based on the congestion window value corresponding to the current routing period of the transmitting device.

[0193] For example, when the congestion window value corresponding to the current routing period of the transmitting device is less than the congestion window value threshold, it is determined that the first original path from the transmitting device to the receiving device is congested; when the congestion window value corresponding to the current routing period of the transmitting device is greater than or equal to the congestion window value threshold, it is determined that the first original path from the transmitting device to the receiving device is not congested.

[0194] Referring to Figure 16, step 520 shown in Figure 5 may include:

[0195] Step 1610: The transmitting device performs a fusion process on the congestion window value corresponding to the current routing period and the congestion window value corresponding to the historical routing periods to obtain a fused congestion window value.

[0196] Step 1620: When the fusion congestion window value is less than the congestion window value threshold, the transmitting device determines that the first original path from the transmitting device to the receiving device is congested.

[0197] Steps 1610 to 1620 are described in detail below.

[0198] In step 1610, the transmitting device performs a fusion process on the congestion window value corresponding to the current routing period and the congestion window value corresponding to the historical routing periods to obtain a fused congestion window value.

[0199] Considering that the transmitting device continuously uses congestion control algorithms to determine the congestion window value, meaning the congestion window value is constantly changing, the congestion window value corresponding to the current routing period may contain fluctuation noise and may not accurately reflect the current congestion status of the first original path. Therefore, the transmitting device fuses the congestion window value corresponding to the current routing period and the congestion window values ​​corresponding to historical routing periods to obtain a fused congestion window value. Here, the historical routing period refers to the N routing periods preceding the current routing period, and the value of N can be set according to the actual application scenario. The fusion processing method is not limited; for example, it can be averaging, taking the minimum value, etc. The prerequisite for fusion processing is that the congestion window value corresponding to the current routing period and the congestion window values ​​corresponding to historical routing periods both correspond to the same communication path.

[0200] Specifically, the transmitting device performs a fusion process on the congestion window value corresponding to the current routing period and the congestion window value corresponding to the historical routing period to obtain a fused congestion window value. This includes: the transmitting device performs a moving average process on the congestion window value corresponding to the current routing period and the congestion window value corresponding to the historical routing period to obtain a fused congestion window value.

[0201] Here, the fusion processing can be a moving average processing. The formula is as follows: Moving average value corresponding to the current routing period = (1-c) * Moving average value corresponding to the previous routing period + c * Congestion window value corresponding to the current routing period, where 1-c > c, and the moving average value corresponding to the current routing period is the fused congestion window value.

[0202] For example, the congestion window value for route selection period 1 is 20, for route selection period 2 it is 18, for route selection period 3 it is 20, and for route selection period 4 it is 10, with c = 0.1. Then, the moving average value for route selection period 2 can be calculated as 0.9*20 + 0.1*18 = 19.8 (rounded down to the nearest integer, 20), for route selection period 3 it is 0.9*20 + 0.1*20 = 20, and for route selection period 4 it is 0.9*20 + 0.1*10 = 19. This reduces the fluctuation noise caused by the congestion window value for route selection period 4. Since route selection period 1 does not have a previous route selection period, the congestion window value for route selection period 1 is directly used as the moving average value for route selection period 1.

[0203] Since the congestion window values ​​corresponding to historical routing cycles are usually numerous and highly reliable, referencing the congestion window values ​​corresponding to historical routing cycles more in the above-mentioned moving average processing (i.e., setting 1-c>c) can effectively filter out the fluctuation noise that may be caused by the congestion window values ​​corresponding to the current routing cycle, which helps to improve the accuracy of congestion detection.

[0204] In step 1620, when the fusion congestion window value is less than the congestion window value threshold, the transmitting device determines that the first original path from the transmitting device to the receiving device is congested.

[0205] When the fused congestion window value is less than the congestion window value threshold, the transmitting device determines that the first original path from the transmitting device to the receiving device is congested; when the fused congestion window value is greater than or equal to the congestion window value threshold, the transmitting device determines that the first original path from the transmitting device to the receiving device is not congested. The congestion window value threshold can be set according to the throughput requirements of the communication connection.

[0206] In steps 1610 to 1620 above, considering that the transmitting device continuously uses the congestion control algorithm to determine the congestion window value, that is, the congestion window value is constantly changing dynamically, the congestion window value corresponding to the current routing cycle of the transmitting device may have fluctuation noise, which may not accurately reflect the current congestion situation of the first original path. Therefore, the congestion window value corresponding to the historical routing cycle is combined to calculate the fused congestion window value, so that the fused congestion window value can more accurately reflect the current congestion situation of the first original path, thereby helping to improve the accuracy of congestion judgment and the necessity of route switching after judging congestion, and avoiding unnecessary resource overhead.

[0207] Detailed description of step 530

[0208] In step 530, the sending device selects the first virtual port number corresponding to the current routing period from the first candidate port number set, updates the first field with the first virtual port number, and places the first original port number in the second field of the data packet; the first virtual port number is used to perform routing calculations to obtain the first alternative path from the sending device to the receiving device.

[0209] Here, the sending device selects the first virtual port number corresponding to the current routing period from the first candidate port number set, and performs virtual tunnel encapsulation on the data packet according to the first virtual port number. In this way, the communication path from the sending device to the receiving device can be updated from the first original path to the first alternative path, that is, the routing is achieved through virtual tunnel encapsulation.

[0210] Referring to Figure 17, step 530 shown in Figure 5 includes:

[0211] Step 1710: The transmitting device selects the first virtual source port number corresponding to the current routing period from the first candidate source port number set, and updates the seventh field with the first virtual source port number;

[0212] Step 1720: The transmitting device selects the first virtual destination port number corresponding to the current routing period from the first candidate destination port number set, and updates the eighth field with the first virtual destination port number;

[0213] Step 1730: The sending device places the first original source port number and the first original destination port number in the second field of the data packet;

[0214] Referring to Figure 17, step 550 shown in Figure 5 can be updated to step 1740:

[0215] Step 1740: When the receiving device identifies that the first virtual destination port number in the eighth field belongs to the first candidate destination port number set, it extracts the first original source port number and the first original destination port number from the second field, updates the seventh field with the first original source port number, and updates the eighth field with the first original destination port number to perform transport layer protocol processing.

[0216] Steps 1710 to 1740 are described in detail below.

[0217] In step 1710, the transmitting device selects the first virtual source port number corresponding to the current routing period from the first candidate source port number set, and updates the seventh field with the first virtual source port number.

[0218] Here, the first original port number includes the first original source port number and the first original destination port number. For the data packet generated by the sending device, the first field in the data packet can be subdivided into the seventh field (i.e., the source port number field) and the eighth field (i.e., the destination port number field). The seventh field has the first original source port number, and the eighth field has the first original destination port number.

[0219] Based on this, the transmitting device can select the first virtual source port number corresponding to the current routing period from the first candidate source port number set, and update the seventh field with the first virtual source port number, as shown in Figure 18. The first candidate source port number set includes multiple candidate source port numbers other than the first original source port number.

[0220] In step 1720, the transmitting device selects the first virtual destination port number corresponding to the current routing period from the first candidate destination port number set, and updates the eighth field with the first virtual destination port number.

[0221] The first candidate destination port number set includes one or more candidate destination port numbers other than the first original destination port number. Unlike the first candidate source port number set, these candidate destination port numbers are used to trigger the receiving device to update the seventh and eighth fields, i.e., to trigger the receiving device to perform virtual tunnel decapsulation. The first candidate destination port number set can be preset. Based on this, the sending device selects the first virtual destination port number corresponding to the current routing period from the first candidate destination port number set and updates the eighth field with the first virtual destination port number, as shown in Figure 18. Thus, the first virtual destination port number in the eighth field indicates that the data packet has been encapsulated by a virtual tunnel.

[0222] In step 1730, the sending device places the first original source port number and the first original destination port number in the second field of the data packet.

[0223] The sending device places the first original source port number and the first original destination port number in the second field of the data packet for subsequent recovery. The second field may include a ninth field and a tenth field; the sending device places the first original source port number in the ninth field and the first original destination port number in the tenth field for easier differentiation.

[0224] The virtual tunnel encapsulation of the data packet is completed through steps 1710 to 1730. During the transmission of the data packet, the first virtual source port number and the first virtual destination port number are used for routing calculation to obtain the first alternative path from the sending device to the receiving device.

[0225] In step 1740, when the receiving device identifies that the first virtual destination port number in the eighth field belongs to the first candidate destination port number set, it extracts the first original source port number and the first original destination port number from the second field, updates the seventh field with the first original source port number, and updates the eighth field with the first original destination port number to perform transport layer protocol processing.

[0226] After receiving a data packet, the receiving device recognizes that the data packet has undergone virtual tunnel encapsulation because the first virtual destination port number in the eighth field belongs to the first candidate destination port number set. Therefore, the receiving device performs the following processing: extracts the first original source port number and the first original destination port number from the second field (for example, extracting the first original source port number from the ninth field and the first original destination port number from the tenth field), updates the seventh field with the first original source port number, and updates the eighth field with the first original destination port number for transport layer protocol processing, as shown in Figure 19. Alternatively, the receiving device finds that the port number in the eighth field of the data packet does not belong to the first candidate destination port number set. Therefore, the receiving device recognizes that the data packet has not undergone virtual tunnel encapsulation and directly performs transport layer protocol processing on the data packet.

[0227] It is worth noting that the reason why the eighth field is used to identify whether a data packet has undergone virtual tunnel encapsulation in this embodiment is that the eighth field is the destination port number field. In the current communication model, the receiving device usually extracts the destination port number from the destination port number field of the data packet and hands the data packet over to the process corresponding to the destination port number for processing. Therefore, by assigning different meanings to different destination port numbers, the receiving device can perform different operations, namely, perform virtual tunnel decapsulation or not perform virtual tunnel decapsulation. In addition, when the sending device and the receiving device establish a communication connection, the agreed first original destination port number should avoid the first candidate destination port number set, thereby preventing the receiving device from mistakenly believing that a data packet that has not undergone virtual tunnel encapsulation has undergone virtual tunnel encapsulation.

[0228] Of course, in other embodiments, the seventh field can also be used to identify whether the data packet has been encapsulated through a virtual tunnel.

[0229] The above method triggers the receiving device to perform virtual tunnel decapsulation by selecting candidate destination port numbers from the first set of candidate destination port numbers. This ensures the accuracy and necessity of virtual tunnel decapsulation and is suitable for scenarios where some data packets in a packet transmission network use virtual tunnel encapsulation, while others do not. Two application scenarios are illustrated below.

[0230] (I) Gray-scale deployment scenario.

[0231] For example, if this embodiment of the present disclosure is deployed in a message transmission network using a gray-scale deployment method, the message transmission network will simultaneously contain data packets encapsulated using virtual tunnels and data packets not encapsulated using virtual tunnels. The port number in the eighth field of the data packet encapsulated using virtual tunnels belongs to the first candidate destination port number set, while the port number in the eighth field of the data packet not encapsulated using virtual tunnels does not belong to the first candidate destination port number set. Based on this, after receiving a data packet, the receiving device in the message transmission network can determine whether the data packet has undergone virtual tunnel encapsulation based on the eighth field of the data packet, and then determine whether to perform virtual tunnel decapsulation on the data packet. Through the above-described gray-scale deployment scenario, various uncontrollable problems caused by a large number of data packets encapsulated using virtual tunnels in the message transmission network can be avoided, effectively reducing risks and facilitating the rapid advancement of the deployment process.

[0232] (ii) Differentiate configuration scenarios.

[0233] For example, in a message transmission network, multiple communication connections are established. Some of these connections (taking communication connection 1 as an example) do not allow routing. Therefore, the sending device involved in communication connection 1 does not perform virtual tunnel encapsulation on the data packets. The receiving device involved in communication connection 1, upon receiving the data packets, recognizes that the data packets are not encapsulated using virtual tunnels and thus directly processes the data packets using the transport layer protocol. However, some communication connections (taking communication connection 2 as an example) do not strictly require message transmission along a fixed communication path, i.e., routing is allowed. Therefore, the sending device involved in communication connection 2 performs virtual tunnel encapsulation on the data packets before sending them. The receiving device involved in communication connection 2, upon receiving the data packets, recognizes that the data packets have been encapsulated using virtual tunnels and thus decapsulates the data packets using virtual tunnels before processing them using the transport layer protocol. As described above, this embodiment of the present disclosure can achieve differentiated configurations, thereby meeting the communication needs of different communication connections.

[0234] In steps 1710 to 1740 above, the seventh and eighth fields in the data packet are used for path control. The eighth field is also used to identify whether the data packet has been encapsulated through a virtual tunnel. In this way, after receiving the data packet, the receiving device can determine whether the data packet has been encapsulated through a virtual tunnel based on the eighth field in the data packet, and then determine whether to perform virtual tunnel decapsulation on the data packet. This can ensure the necessity and accuracy of virtual tunnel decapsulation, and is suitable for scenarios in the packet transmission network where some data packets are encapsulated through virtual tunnels, while other data packets are not.

[0235] Referring to Figure 20, step 530 shown in Figure 5 can also be updated to step 2010:

[0236] Step 2010: The sending device selects the first virtual source port number corresponding to the current routing period from the first candidate source port number set, updates the seventh field with the first virtual source port number, and places the first original source port number in the second field of the data packet;

[0237] Referring to Figure 20, step 550 shown in Figure 5 can be updated to step 2020:

[0238] Step 2020: The receiving device extracts the first original source port number from the second field and updates the seventh field with the first original source port number for transport layer protocol processing.

[0239] Steps 2010 to 2020 are described in detail below.

[0240] In step 2010, the sending device selects the first virtual source port number corresponding to the current routing period from the first candidate source port number set, updates the seventh field with the first virtual source port number, and places the first original source port number in the second field of the data packet.

[0241] Here, all data packets in the default message transmission network need to be encapsulated in a virtual tunnel. In this case, the sending device selects the first virtual source port number corresponding to the current routing period from the first candidate source port number set, updates the seventh field with the first virtual source port number, and places the first original source port number in the second field of the data packet, thereby completing the virtual tunnel encapsulation of the data packet, as shown in Figure 21.

[0242] It is worth noting that the eighth field (destination port number field) in the data packet can retain its original first destination port number during the virtual tunnel encapsulation process. During data packet transmission, the first virtual source port number and the first original destination port number are used for routing calculations to obtain the first alternative path from the sending device to the receiving device.

[0243] In step 2020, the receiving device extracts the first original source port number from the second field and updates the seventh field with the first original source port number for transport layer protocol processing.

[0244] After receiving a data packet, the receiving device performs virtual tunnel decapsulation on the data packet by default. That is, it extracts the first original source port number from the second field and updates the seventh field with the first original source port number for transport layer protocol processing, as shown in Figure 22.

[0245] In steps 2010 to 2020 above, the seventh field in the data packet is used for path control. After receiving the data packet, the receiving device performs virtual tunnel decapsulation based on the seventh field in the data packet. This is applicable to scenarios where all data packets in the packet transmission network use virtual tunnel encapsulation.

[0246] Referring to Figure 23, step 530 shown in Figure 5 can also be updated to step 2310:

[0247] Step 2310: The sending device selects the first virtual destination port number corresponding to the current routing period from the first candidate destination port number set, updates the eighth field with the first virtual destination port number, and places the first original destination port number in the second field of the data packet;

[0248] Referring to Figure 23, step 550 shown in Figure 5 can be updated to step 2320:

[0249] Step 2320: The receiving device extracts the first original destination port number from the second field and updates the eighth field with the first original destination port number for transport layer protocol processing.

[0250] Steps 2310 to 2320 are described in detail below.

[0251] In step 2310, the sending device selects the first virtual destination port number corresponding to the current routing period from the first candidate destination port number set, updates the eighth field with the first virtual destination port number, and places the first original destination port number in the second field of the data packet.

[0252] Here, all data packets in the default message transmission network need to be encapsulated in a virtual tunnel. In this case, the sending device selects the first virtual destination port number corresponding to the current routing period from the first candidate destination port number set, updates the eighth field with the first virtual destination port number, and places the first original destination port number in the second field of the data packet, thereby completing the virtual tunnel encapsulation of the data packet, as shown in Figure 24.

[0253] It is worth noting that the seventh field (source port number field) in the data packet can retain its original first source port number during the virtual tunnel encapsulation process. During data packet transmission, the first virtual destination port number and the first original source port number are used for routing calculations to obtain the first alternative path from the sending device to the receiving device.

[0254] It is worth noting that, unlike the first candidate destination port number set in step 1720, the candidate destination port numbers in the first candidate destination port number set involved in step 2310 are not used to trigger the receiving device to perform virtual tunnel decapsulation. The receiving device will perform virtual tunnel decapsulation by default.

[0255] In step 2320, the receiving device extracts the first original destination port number from the second field and updates the eighth field with the first original destination port number for transport layer protocol processing.

[0256] After receiving a data packet, the receiving device performs virtual tunnel decapsulation on the data packet by default. That is, it extracts the first original destination port number from the second field and updates the eighth field with the first original destination port number for transport layer protocol processing, as shown in Figure 25.

[0257] In steps 2310 to 2320 above, the eighth field in the data packet is used for path control. After receiving the data packet, the receiving device performs virtual tunnel decapsulation based on the eighth field in the data packet. This is applicable to scenarios where all data packets in the packet transmission network use virtual tunnel encapsulation.

[0258] Referring to Figure 26, step 530 shown in Figure 5 may include:

[0259] Step 2610: The transmitting device selects the first virtual source port number corresponding to the current routing period from the first candidate source port number set, and updates the seventh field with the first virtual source port number;

[0260] Step 2620: The transmitting device selects the first virtual destination port number corresponding to the current routing period from the first candidate destination port number set, and updates the eighth field with the first virtual destination port number;

[0261] Step 2630: The sending device places the first original source port number and the first original destination port number in the second field of the data packet;

[0262] Referring to Figure 26, step 550 shown in Figure 5 can be updated to step 2640:

[0263] Step 2640: The receiving device extracts the first original source port number and the first original destination port number from the second field, updates the seventh field with the first original source port number, and updates the eighth field with the first original destination port number for transport layer protocol processing.

[0264] Steps 2610 to 2640 are described in detail below.

[0265] In step 2610, the transmitting device selects the first virtual source port number corresponding to the current routing period from the first candidate source port number set, and updates the seventh field with the first virtual source port number.

[0266] Here, all data packets in the default message transmission network need to be encapsulated in a virtual tunnel. In this case, the sending device selects the first virtual source port number corresponding to the current routing period from the first candidate source port number set and updates the seventh field with the first virtual source port number.

[0267] In step 2620, the transmitting device selects the first virtual destination port number corresponding to the current routing period from the first candidate destination port number set, and updates the eighth field with the first virtual destination port number.

[0268] Unlike the first candidate destination port number set in step 1720, the candidate destination port numbers in the first candidate destination port number set involved in step 2620 are not used to trigger the receiving device to perform virtual tunnel decapsulation. The receiving device will perform virtual tunnel decapsulation by default.

[0269] In step 2630, the sending device places the first original source port number and the first original destination port number in the second field of the data packet.

[0270] The sending device places the first original source port number and the first original destination port number in the second field of the data packet to complete the virtual tunnel encapsulation of the data packet. During the transmission of the data packet, the first virtual source port number and the first virtual destination port number are used to perform routing calculations to obtain the first alternative path from the sending device to the receiving device.

[0271] In step 2640, the receiving device extracts the first original source port number and the first original destination port number from the second field, updates the seventh field with the first original source port number, and updates the eighth field with the first original destination port number for transport layer protocol processing.

[0272] After receiving a data packet, the receiving device performs virtual tunnel decapsulation on the data packet by default. That is, it extracts the first original source port number and the first original destination port number from the second field, updates the seventh field with the first original source port number, and updates the eighth field with the first original destination port number for transport layer protocol processing.

[0273] In steps 2610 to 2640 above, the seventh and eighth fields in the data packet are used for path control. After receiving the data packet, the receiving device performs virtual tunnel decapsulation based on the seventh and eighth fields in the data packet. This is applicable to scenarios where all data packets in the packet transmission network use virtual tunnel encapsulation.

[0274] Referring to Figure 27, step 530 shown in Figure 5 may include:

[0275] Step 2710: The transmitting device performs routing calculations based on multiple candidate port numbers in the first candidate port number set to obtain the correspondence between the multiple candidate port numbers and multiple physical ports of the transmitting device.

[0276] Step 2720: The transmitting device determines the port load level of multiple physical ports;

[0277] Step 2730: The transmitting device determines the physical port with the lowest port load as the target physical port, and determines the candidate port number corresponding to the target physical port as the filtered port number;

[0278] Step 2740: The transmitting device selects the first virtual port number corresponding to the current routing cycle from the filtered port numbers;

[0279] Step 2750: The sending device updates the first field with the first virtual port number and places the first original port number in the second field of the data packet.

[0280] Steps 2710 to 2750 are described in detail below.

[0281] In step 2710, the transmitting device performs routing calculations on multiple candidate port numbers in the first candidate port number set to determine the correspondence between the multiple candidate port numbers and multiple physical ports of the transmitting device.

[0282] When the first candidate port number set includes multiple candidate port numbers, the transmitting device may randomly select one candidate port number as the first virtual port number. However, the first alternative path obtained in this way may not be more idle than the first original path. Therefore, embodiments of this disclosure provide other selection strategies for the first candidate port number set.

[0283] First, the transmitting device performs routing calculations based on multiple candidate port numbers in the first candidate port number set to determine the correspondence between the multiple candidate port numbers and the multiple physical ports of the transmitting device. Here, performing routing calculations based on candidate port numbers can refer to relying solely on candidate port numbers for routing calculations, or it can refer to combining routing calculations with other elements, such as performing routing calculations on a quintuple containing candidate port numbers.

[0284] Referring to Figure 2, server H0 and server H4 establish a communication connection. Server H0 acts as the sending device, and server H4 acts as the receiving device. Physical port 1 of server H0 is connected to access layer switch L0, and physical port 2 of server H0 is connected to access layer switch L1. The first candidate port number set includes two candidate port numbers, namely port number 1 and port number 5. In this case, after performing routing calculation based on port number 1, it is found that if port number 1 is used as the first virtual port number, the data packet will be sent from physical port 1 of the sending device. Therefore, it is determined that there is a correspondence between port number 1 and physical port 1 of the sending device. After performing routing calculation based on port number 5, it is found that if port number 5 is used as the first virtual port number, the data packet will be sent from physical port 2 of the sending device. Therefore, it is determined that there is a correspondence between port number 5 and physical port 2 of the sending device.

[0285] In step 2720, the transmitting device determines the port load level of multiple physical ports.

[0286] Here, the transmitting device determines the port load of multiple physical ports. The port load can refer to the bandwidth utilization of a physical port. For example, for a physical port with a maximum throughput of 1Gbps, if its throughput at a certain moment is 800Mbps, the port load at that moment is calculated to be 80%. The transmitting device can detect the port load of multiple physical ports using tools built into the operating system, such as the command-line tool netstat; it can also use other tools, such as Simple Network Management Protocol (SNMP).

[0287] In step 2730, the transmitting device determines the physical port with the lowest port load as the target physical port, and determines the candidate port number corresponding to the target physical port as the filtered port number.

[0288] The lower the port load of a physical port, the more idle the physical port is. Therefore, after determining the port load of multiple physical ports, the transmitting device determines the physical port with the lowest port load as the target physical port, and determines the candidate port number corresponding to the target physical port as the filtered port number.

[0289] For ease of explanation, examples are provided as shown in Table 1:

[0290] Table 1. Correspondence between Physical Port, Candidate Port Number, and Port Load Level

[0291] Based on the example shown in Table 1, among the physical ports 1 to 4 of the transmitting device, physical port 3 has the lowest port load. Therefore, physical port 3 is determined as the target physical port, and the port numbers 9 to 12 corresponding to physical port 3 are all determined as the filtered port numbers.

[0292] In step 2740, the transmitting device selects the first virtual port number corresponding to the current routing cycle from the filtered port numbers.

[0293] If there is only one filtered port number, the transmitting device will directly determine the filtered port number as the first virtual port number corresponding to the current routing period; if there are multiple filtered port numbers, the transmitting device will select (e.g., randomly select) the first virtual port number corresponding to the current routing period from the filtered port numbers.

[0294] Based on the example shown in Table 1, the filtered port numbers include port numbers 9 to 12, from which one can be randomly selected, for example, port number 9 can be selected as the first virtual port number.

[0295] In step 2750, the sending device updates the first field with the first virtual port number and places the first original port number in the second field of the data packet.

[0296] After selecting the first virtual port number, the sending device updates the first field with the first virtual port number and places the first original port number in the second field of the data packet, thereby achieving virtual tunnel encapsulation. After virtual tunnel encapsulation, the data packet will be sent through the target physical port of the sending device. That is, the first hop in the first replacement path will start from the target physical port of the sending device. Since the target physical port is the least busy physical port among the multiple physical ports of the sending device, it can increase the probability that the first replacement path is less busy than the first original path, thus minimizing invalid routing.

[0297] In steps 2710 to 2750 above, the port load of the physical port of the sending device is used as the basis for selecting the first virtual port number. Specifically, the physical port with the lowest port load is determined as the target physical port, the candidate port number corresponding to the target physical port is determined as the filtered port number, and the first virtual port number corresponding to the current routing cycle is selected from the filtered port number. In this way, it is ensured that the data packet will be sent through the target physical port of the sending device after being encapsulated by the virtual tunnel. Since the target physical port is the least idle physical port among the multiple physical ports of the sending device, it can increase the probability that the first replacement path is less idle than the first original path, and try to avoid the situation that the routing needs to be changed again after the routing is changed, which can effectively save computing resources.

[0298] Referring to Figure 28, step 530 shown in Figure 5 may include:

[0299] Step 2810: The transmitting device performs routing calculations based on multiple candidate port numbers in the first candidate port number set to obtain multiple candidate replacement paths from the transmitting device to the receiving device;

[0300] Step 2820: The transmitting device determines the path overlap between the first original path and multiple candidate replacement paths;

[0301] Step 2830: The transmitting device determines the candidate port number corresponding to the candidate replacement path with the minimum path overlap as the first virtual port number corresponding to the current routing cycle.

[0302] Step 2840: The sending device updates the first field with the first virtual port number and places the first original port number in the second field of the data packet.

[0303] Steps 2810 to 2840 are described in detail below.

[0304] In step 2810, the transmitting device performs routing calculations based on multiple candidate port numbers in the first candidate port number set to obtain multiple candidate replacement paths from the transmitting device to the receiving device.

[0305] Here, the sending device performs routing calculations based on multiple candidate port numbers in the first candidate port number set to obtain multiple candidate replacement paths from the sending device to the receiving device, where each candidate replacement path corresponds to a candidate port number. It is worth noting that step 2810 requires the sending device to know the distribution of multiple forwarding devices in the message transmission network (e.g., which forwarding devices the sending device is connected to, and which forwarding devices are included in different layers of the message transmission network) and the physical port information. Only then can the sending device obtain the complete communication path from the sending device to the receiving device through routing calculations.

[0306] In step 2820, the transmitting device determines the path overlap between the first original path and the plurality of candidate replacement paths.

[0307] For example, routing operations are usually implemented based on the equal-cost multipath algorithm. For the first original path and a candidate replacement path, the total number of hops of the two communication paths is usually the same. Therefore, the number of overlapping paths in the two communication paths can be divided by the total number of hops to obtain the path overlap between the two communication paths. Here, overlapping path refers to the communication path between any two devices that communicate directly (i.e., without forwarding through other devices), rather than the complete communication path from the sending device to the receiving device.

[0308] For ease of explanation, examples are provided in Table 2, in conjunction with Figure 2:

[0309] Table 2 Path Overlap Table

[0310] Taking port number 1 in Table 2 as an example, the candidate replacement path obtained through routing calculation is H0-L0-S0-C1-S4-L4-H4. The overlapping paths between it and the first original path H0-L0-S0-C0-S4-L4-H4 include 4 hops: H0-L0, L0-S0, S4-L4, and L4-H4. The total number of hops is 6. Therefore, the path overlap rate is 4 / 6 = 67%. The calculation process for the overlap rate of the other paths shown can be deduced by analogy.

[0311] In step 2830, the transmitting device determines the candidate port number corresponding to the candidate replacement path with the minimum path overlap as the first virtual port number corresponding to the current routing cycle.

[0312] Taking Table 2 as an example, among the four candidate replacement paths, the candidate replacement path with the minimum path overlap is determined to be H0-L1-S1-C2-S5-L5-H4, and the port number 4 corresponding to this candidate replacement path is determined as the first virtual port number corresponding to the current routing cycle.

[0313] If there are multiple candidate port numbers corresponding to the candidate replacement path with the minimum path overlap, then one of them can be randomly selected as the first virtual port number corresponding to the current routing cycle.

[0314] In step 2840, the sending device updates the first field with the first virtual port number and places the first original port number in the second field of the data packet.

[0315] After the data packet is encapsulated in a virtual tunnel according to the first virtual port number selected in step 2830, the data packet will arrive at the receiving device along the first alternative path. Here, the first alternative path refers to the candidate alternative path with the minimum path overlap with the first original path. In this way, the root causes of congestion of the first original path can be avoided as much as possible, and the probability that the first alternative path is more idle than the first original path can be increased.

[0316] In steps 2810 to 2840 above, considering that the first original path is already congested, the sending device selects the first virtual port number with the principle of avoiding the first original path as much as possible. Specifically, the sending device performs routing calculations based on multiple candidate port numbers in the first candidate port number set to obtain multiple candidate replacement paths from the sending device to the receiving device. Then, the candidate port number corresponding to the candidate replacement path that is most different from the first original path is determined as the first virtual port number, and the data packet is encapsulated with a virtual tunnel based on the first virtual port number. This minimizes the overlap between the first replacement path and the first original path, increases the probability that the first replacement path is less congested than the first original path, and avoids the situation where a route change is required again after a route change, which can effectively save computing resources.

[0317] Referring to Figure 29, step 530 shown in Figure 5 may include:

[0318] Step 2910: The transmitting device determines the overlapping paths of multiple congested paths from the transmitting device to the receiving device;

[0319] Step 2920: The transmitting device performs routing calculations based on multiple candidate port numbers in the first candidate port number set to obtain multiple candidate replacement paths from the transmitting device to the receiving device;

[0320] Step 2930: The transmitting device will exclude the candidate port number corresponding to the candidate replacement path of the overlapping path and determine it as the first virtual port number corresponding to the current routing cycle.

[0321] Step 2940: The sending device updates the first field with the first virtual port number and places the first original port number in the second field of the data packet.

[0322] Steps 2910 to 2940 are described in detail below.

[0323] In step 2910, the transmitting device determines the overlapping paths of multiple congested paths from the transmitting device to the receiving device.

[0324] A congested path refers to a communication path that a sending device has used to transmit data packets to a receiving device and where congestion has occurred. For example, the first original path can be considered a congested path. When there are multiple congested paths, the sending device identifies overlapping paths among these paths. These overlapping paths are highly likely to be the root cause of the congestion. Taking N congested paths as an example, the overlapping path needs to appear at least M times among the N congested paths, where M is an integer greater than 1 and not exceeding N, and the value can be set according to the actual situation. Taking the case of M=N as an example, referring to Figure 2, if the congested paths include the following four paths: H0-L0-S0-C0-S4-L4-H4, H0-L0-S0-C1-S4-L4-H4, H0-L0-S1-C2-S5-L4-H4, and H0-L0-S1-C2-S5-L5-H4, then the overlapping path can be determined to be H0-L0. It is highly likely that the congestion of these paths is caused by the overload of the physical port connecting server H0 to access layer switch L0.

[0325] In step 2920, the transmitting device performs routing calculations based on multiple candidate port numbers in the first candidate port number set to obtain multiple candidate replacement paths from the transmitting device to the receiving device.

[0326] Step 2920 can be referred to the relevant description of step 2810.

[0327] In step 2930, the transmitting device will exclude the candidate port number corresponding to the candidate replacement path of the overlapping path and determine it as the first virtual port number corresponding to the current routing cycle.

[0328] For ease of explanation, examples are provided as shown in Table 3:

[0329] Table 3 Candidate Replacement Paths

[0330] As shown in Table 3, the candidate replacement paths corresponding to port numbers 1 to 3 all include the overlapping path H0-L0, meaning that the overlapping path H0-L0 has not been excluded. However, the candidate replacement path corresponding to port number 4 is H0-L1-S1-C2-S5-L5-H4, which excludes the overlapping path H0-L0. Therefore, port number 4 is determined as the first virtual port number corresponding to the current routing cycle. It is worth noting that excluding overlapping paths means not including overlapping paths.

[0331] If there are multiple candidate port numbers corresponding to the candidate replacement path that excludes overlapping paths, then one of them can be randomly selected as the first virtual port number corresponding to the current routing cycle.

[0332] In step 2940, the sending device updates the first field with the first virtual port number and places the first original port number in the second field of the data packet.

[0333] After the data packet is encapsulated in a virtual tunnel according to the first virtual port number selected in step 2930, the data packet will arrive at the receiving device along the first alternative path. The first alternative path here has excluded overlapping paths, so it can avoid the root causes that may cause congestion and increase the probability that the first alternative path is less busy than the first original path.

[0334] In steps 2910 to 2940 above, when multiple congested paths exist historically, overlapping paths among these paths are identified. These overlapping paths are highly likely to be the root cause of congestion. Therefore, the sending device performs routing calculations based on multiple candidate port numbers in the first candidate port number set to obtain multiple candidate alternative paths from the sending device to the receiving device. The candidate port number corresponding to the candidate alternative path that excludes overlapping paths is determined as the first virtual port number corresponding to the current routing period. The data packet is then encapsulated with a virtual tunnel based on the first virtual port number. This ensures that the first alternative path excludes overlapping paths, avoids potential congestion sources, increases the probability that the first alternative path is less congested than the first original path, and minimizes the need for rerouting after a previous route change, effectively saving computational resources.

[0335] Referring to Figure 30, step 530 shown in Figure 5 can be updated to step 3010:

[0336] In step 3010, when the path switching condition is met, the sending device selects the first virtual port number corresponding to the current routing period from the first candidate port number set, updates the first field with the first virtual port number, and places the first original port number in the second field of the data packet; wherein, the path switching condition includes at least one of the following: the sending window value corresponding to the current routing period of the sending device is zero and the duration reaches a first duration threshold; the interval between the last selection of the first candidate port number set reaches a second duration threshold.

[0337] Here, corresponding path switching conditions can be set for the virtual tunnel encapsulation operation. When the path switching conditions are met, the sending device performs virtual tunnel encapsulation on the data packet, that is, selects the first virtual port number corresponding to the current routing period from the first candidate port number set, updates the first field with the first virtual port number, and places the first original port number in the second field of the data packet, thereby switching the first original path to the first alternative path; when the path switching conditions are not met, the sending device does not perform virtual tunnel encapsulation on the data packet, but directly sends the data packet.

[0338] Path switching conditions include at least one of the following:

[0339] 1) The sending window value corresponding to the current routing cycle of the transmitting device is zero, and the duration reaches the first duration threshold. Path switching may cause out-of-order packets to appear on the receiving device. To reduce the occurrence of out-of-order packets, path switching can be performed after the communication connection between the transmitting and receiving devices has been idle for a period of time. That is, the sending window value corresponding to the current routing cycle of the transmitting device is zero, and the duration reaches the first duration threshold. Here, the sending window value refers to the amount of data that the transmitting device is allowed to send without receiving an acknowledgment message from the receiving device. A sending window value of zero means that the transmitting device is temporarily not sending data, that is, the communication connection is in an idle state. The first duration threshold can be set according to the actual situation, for example, 1ms.

[0340] 2) The interval since the last selection of the first candidate port number set reaches the second time threshold. After path switching, the congestion control algorithm needs time to converge (i.e., the congestion window value adjusts from the beginning to a stable state). Therefore, path switching can only be performed when the interval since the last path switching (i.e., the interval since the last selection of the first candidate port number set) reaches the second time threshold. The second time threshold can be set as the convergence time of the congestion control algorithm, for example, 10ms. It is understandable that if the interval since the last path switching does not reach the second time threshold, the congestion control algorithm may not have converged, and the congestion window value corresponding to the current routing cycle of the transmitting device may not be accurate. This could cause the original, uncongested path to be mistakenly considered congested, leading to unnecessary waste of computational resources and making it difficult to guarantee that the first replacement path is less congested than the original path. By setting the above path switching conditions, the necessity of path switching can be increased, thus truly resolving the congestion problem caused by the original path.

[0341] In step 3010 above, two path switching conditions are set. The first condition is that the data packet is encapsulated in a virtual tunnel only when the sending window value corresponding to the current routing cycle of the sending device is zero and the duration reaches the first duration threshold. This can reduce the occurrence of out-of-order packets on the receiving device side and improve the orderliness and accuracy of packet transmission. The second condition is that the data packet is encapsulated in a virtual tunnel only when the interval between the last selection of the first candidate port number set reaches the second duration threshold. This can ensure that the congestion of the first original path is real, increase the necessity of path switching, and avoid unnecessary waste of resources.

[0342] Referring to Figure 31, step 530 shown in Figure 5 can be updated to step 3110:

[0343] Step 3110: The sending device selects the first virtual port number corresponding to the current routing period from the first candidate port number set, updates the first field with the first virtual port number, and updates the second field of the data packet with the first original port number;

[0344] Referring to Figure 31, step 550 shown in Figure 5 can be updated to step 3120:

[0345] Step 3120: The receiving device extracts the first original port number from the second field, updates the first field with the first original port number, and updates the second field with the original value of the second field for transport layer protocol processing.

[0346] Steps 3110 to 3120 are described in detail below.

[0347] In step 3110, the sending device selects the first virtual port number corresponding to the current routing period from the first candidate port number set, updates the first field with the first virtual port number, and updates the second field of the data packet with the first original port number.

[0348] The second field can be a field defined by the traditional message format, that is, a field that the data packet has when it is generated. For ease of distinction, the value of the second field when the data packet is generated is called the original value. In this case, the sending device updates the second field of the data packet with the first original port number, as shown in Figure 32.

[0349] In step 3120, the receiving device extracts the first original port number from the second field, updates the first field with the first original port number, and updates the second field with the original value of the second field for transport layer protocol processing.

[0350] During the virtual tunnel decapsulation process of the data packet, the receiving device updates the first field with the first original port number and also updates the second field with the original value of the second field to initialize the second field, as shown in Figure 33. Of course, step 3120 requires the receiving device to know the original value of the second field, for example, if the original value of the second field is a conventional default value. If the receiving device does not know the original value of the second field, it can clear the second field to zero.

[0351] In steps 3110 to 3120 above, when the second field is a field specified by the traditional message format, the sending device updates the second field with the first original port number, and the receiving device updates the second field with the original value of the second field, thereby realizing the restoration of the second field. This ensures that the data packet obtained by the receiving device after decapsulation through the virtual tunnel is consistent with the data packet generated by the sending device, achieving the effect of not affecting the transport layer protocol processing.

[0352] Referring to Figure 34, step 530 shown in Figure 5 can be updated to step 3410:

[0353] Step 3410: The sending device selects the first virtual port number corresponding to the current routing period from the first candidate port number set, updates the first field with the first virtual port number, creates a second field based on the first original port number, and adds the second field to the data packet;

[0354] Referring to Figure 34, step 550 shown in Figure 5 can be updated to step 3420:

[0355] Step 3420: The receiving device extracts the first original port number from the second field, updates the first field with the first original port number, and deletes the second field in the data packet for transport layer protocol processing.

[0356] Steps 3410 to 3420 are described in detail below.

[0357] In step 3410, the sending device selects the first virtual port number corresponding to the current routing period from the first candidate port number set, updates the first field with the first virtual port number, creates a second field based on the first original port number, and adds the second field to the data packet.

[0358] Here, the second field is not a field specified in the traditional message format; that is, the data packet does not have a second field when it is generated. During the virtual tunnel encapsulation process of the data packet, the sending device creates the second field based on the first original port number and adds it to the data packet, as shown in Figure 35.

[0359] In step 3420, the receiving device extracts the first original port number from the second field, updates the first field with the first original port number, and deletes the second field in the data packet for transport layer protocol processing.

[0360] During the virtual tunnel decapsulation process of the data packet, the receiving device not only updates the first field with the first original port number, but also deletes the second field in the data packet, as shown in Figure 36.

[0361] In steps 3410 to 3420 above, during the virtual tunnel encapsulation process, the sending device creates a second field based on the first original port number and adds the second field to the data packet; during the virtual tunnel decapsulation process, the receiving device deletes the second field from the data packet, thereby ensuring that the data packet obtained by the receiving device after decapsulation through the virtual tunnel is consistent with the data packet generated by the sending device, achieving the effect of not affecting the transport layer protocol processing.

[0362] Virtual tunnel encapsulation-decapsulation scheme for acknowledgment messages

[0363] Referring to Figure 37, after step 550 shown in Figure 5, the following may also be included:

[0364] Step 3710: The receiving device generates an acknowledgment message for the data packet; wherein, the third field in the acknowledgment message contains the second original port number;

[0365] Step 3720: The receiving device determines that the second original path from the receiving device to the transmitting device is congested based on the congestion window value corresponding to the current routing cycle of the receiving device;

[0366] Step 3730: The receiving device selects the second virtual port number corresponding to the current routing period from the second candidate port number set, updates the third field with the second virtual port number, and places the second original port number in the fourth field of the acknowledgment message. The second virtual port number is used to perform routing calculations to obtain the second alternative path from the receiving device to the sending device.

[0367] Step 3740: The receiving device sends an acknowledgment message;

[0368] Step 3750: The sending device extracts the second original port number from the fourth field and updates the third field with the second original port number for transport layer protocol processing.

[0369] Steps 3710 to 3750 are described in detail below.

[0370] In step 3710, the receiving device generates an acknowledgment message for the data packet; wherein the third field in the acknowledgment message has a second original port number.

[0371] After the receiving device performs virtual tunnel decapsulation on the data packet, it can generate an acknowledgment message (ACK message) for the data packet. The third field (i.e., the port number field) in the acknowledgment message contains the second original port number.

[0372] In step 3720, the receiving device determines that the second original path from the receiving device to the transmitting device is congested based on the congestion window value corresponding to the current routing period of the receiving device.

[0373] For the receiving device receiving data packets, the congestion control algorithm also determines the congestion window value corresponding to the current routing cycle of the receiving device. Based on the congestion window value corresponding to the current routing cycle of the receiving device, it can be determined whether the second original path from the receiving device to the sending device is congested. It is worth noting that the sending device and the receiving device are relative concepts. The receiving device can also be regarded as a sending device when sending data, so the congestion control algorithm can be applied.

[0374] The second original path refers to the communication path used by the receiving device in the previous routing cycle of the current routing cycle. If the previous routing cycle did not use virtual tunnel encapsulation, the second original path is obtained by routing calculation based on the second original port number; if the previous routing cycle used virtual tunnel encapsulation, the second original path is obtained by routing calculation based on the virtual port number corresponding to the previous routing cycle. For ease of explanation, the following explanation assumes that the receiving device uses virtual tunnel encapsulation by default.

[0375] In step 3730, the receiving device selects the second virtual port number corresponding to the current routing period from the second candidate port number set, updates the third field with the second virtual port number, and places the second original port number in the fourth field of the acknowledgment message. The second virtual port number is used to perform routing calculations to obtain the second alternative path from the receiving device to the sending device.

[0376] When it is determined that the second original path from the receiving device to the sending device is not congested, it proves that the second original path is still available. Therefore, the acknowledgment message can continue to be transmitted along the second original path. For example, the receiving device uses the virtual port number corresponding to the previous routing cycle as the second virtual port number corresponding to the current routing cycle, updates the third field with the second virtual port number, and places the second original port number in the fourth field of the acknowledgment message. In this way, when the receiving device sends the acknowledgment message, it will perform routing calculations based on the virtual port number corresponding to the previous routing cycle, so that the acknowledgment message reaches the sending device along the second original path.

[0377] When congestion is detected on the second original path from the receiving device to the sending device, it indicates that the second original path is unavailable. To resolve the congestion issue, as shown in Figure 38, the receiving device selects (e.g., randomly selects or uses other selection methods) the second virtual port number corresponding to the current routing period from the second candidate port number set, updates the third field with the second virtual port number, and places the second original port number in the fourth field of the acknowledgment message. The second virtual port number is used for routing calculations to obtain the second alternative path from the receiving device to the sending device. The above process is equivalent to encapsulating the acknowledgment message with a virtual tunnel based on the second virtual port number. The acknowledgment message encapsulated with the virtual tunnel will be transmitted in the virtual tunnel (i.e., the second alternative path) corresponding to the second virtual port number. The second candidate port number set includes one or more candidate port numbers other than the second original port number.

[0378] Step 3730 can be executed at the transport layer, that is, during the process of the receiving device generating an acknowledgment message.

[0379] In step 3740, the receiving device sends an acknowledgment message.

[0380] After the receiving device performs virtual tunnel encapsulation on the acknowledgment message according to the second virtual port number, it sends the acknowledgment message. In this way, the acknowledgment message will reach the sending device along the second alternative path.

[0381] In step 3750, the transmitting device extracts the second original port number from the fourth field and updates the third field with the second original port number for transport layer protocol processing.

[0382] After receiving the acknowledgment message, as shown in Figure 39, the sending device extracts the second original port number from the fourth field and updates the third field with the second original port number. This achieves virtual tunnel decapsulation of the acknowledgment message so that it can be processed by the transport layer protocol according to the acknowledgment message. For example, the congestion window value corresponding to the next routing cycle of the sending device can be calculated by the congestion control algorithm.

[0383] It is worth noting that the process of generating and sending acknowledgment messages is similar to that of generating and sending data messages. Therefore, the above embodiments regarding data messages can also be applied to acknowledgment messages. For example, the receiving device can determine whether congestion has occurred on the second original path from the receiving device to the sending device by calculating the fused congestion window value; for another example, the third field may include at least one of the source port number field and the destination port number field; for yet another example, the fourth field may be a field specified in the traditional message format, or it may be a field created by the receiving device and added to the acknowledgment message.

[0384] In steps 3710 to 3750 above, the field recording the port number in the acknowledgment message is set so that it can be replaced during the routing process and restored during the reception process, thus not affecting the transport layer protocol processing. Specifically, after determining that the second original path from the receiving device to the sending device is congested, a second virtual port number is selected from the second candidate port number set to try a new path, and the field recording the port number, i.e., the third field, is updated with the second virtual port number. The second virtual port number is used to select a new path, but the second original port number is needed in the subsequent transport layer protocol processing. Therefore, in this embodiment of the disclosure, the second original port number is placed in the fourth field so that after the sending device receives the acknowledgment message, it can restore the second original port number according to the fourth field, thereby achieving the effect of trying a new path to solve the congestion problem without affecting the transport layer protocol processing, thus improving the message transmission efficiency.

[0385] Data packet verification scheme

[0386] Following step 530 shown in Figures 40 and 5, the following may also be included:

[0387] Step 4010: The sending device updates the fifth field with the second checksum of the first virtual port number;

[0388] Referring to Figures 40 and 5, prior to step 550, the method further includes:

[0389] Step 4020: The receiving device uses the second check value in the fifth field to verify the first virtual port number in the first field;

[0390] Referring to Figure 40, step 550 shown in Figure 5 can be updated to step 4030:

[0391] Step 4030: When the verification of the first virtual port number in the first field is successful, the receiving device extracts the first original port number from the second field and updates the first field with the first original port number for transport layer protocol processing.

[0392] Steps 4010 to 4030 are described in detail below.

[0393] In step 4010, the transmitting device updates the fifth field with the second checksum of the first virtual port number.

[0394] Here, the data packet also has a fifth field, which is used to verify the first field (the verification object may not be limited to the first field). The fifth field has a first checksum of the first original port number. The first checksum of the first original port number can be calculated based solely on the first original port number, or it can be calculated by combining the first original port number with other elements. This depends on which fields the verification object of the fifth field includes. For example, the checksum in the TCP protocol needs to be calculated based on the TCP header and other parts (such as the payload).

[0395] After the transmitting device updates the first field with the first virtual port number, since the value of the first field has changed, a second checksum of the first virtual port number is calculated, and the fifth field is updated with the second checksum of the first virtual port number, as shown in Figure 41. It is worth noting that the calculation methods for various checksums (such as the first checksum and the second checksum) involved in the embodiments of this disclosure are the same; the updating of the fifth field by the transmitting device is also part of the virtual tunnel encapsulation.

[0396] In step 4020, the receiving device uses the second check value of the fifth field to verify the first virtual port number of the first field.

[0397] After receiving a data packet encapsulated through a virtual tunnel, the receiving device first verifies the first virtual port number in the first field using the second checksum in the fifth field. For example, the receiving device recalculates the checksum based on the first virtual port number in the first field and determines whether the recalculated checksum is the same as the second checksum in the fifth field. If they are the same, the verification of the first virtual port number in the first field is successful; if they are different, the verification of the first virtual port number in the first field fails. Of course, the verification object here may not only be the first field; for example, in the TCP protocol, the TCP header and other parts (such as the payload) are verified as a whole.

[0398] In step 4030, when the verification of the first virtual port number in the first field is successful, the receiving device extracts the first original port number from the second field and updates the first field with the first original port number for transport layer protocol processing.

[0399] When the verification of the first virtual port number in the first field fails, it indicates that the data packet may have been lost or tampered with. Therefore, the receiving device can choose not to continue processing the data packet, for example, it can discard the data packet directly. When the verification of the first virtual port number in the first field succeeds, it indicates that the data packet is complete and accurate. Therefore, the receiving device performs virtual tunnel decapsulation on the data packet, that is, extracts the first original port number from the second field and updates the first field with the first original port number for transport layer protocol processing. As for the fifth field, it can be considered that the verification work of the fifth field has been completed and is no longer needed. Therefore, the second checksum of the fifth field can be kept unchanged, as shown in Figure 42, or the fifth field can be cleared to zero.

[0400] In steps 4010 to 4030 above, during the virtual tunnel encapsulation of the data packet, the sending device updates the fifth field with the second check value of the first virtual port number; after receiving the data packet, the receiving device first checks the first virtual port number in the first field with the second check value in the fifth field, and only performs virtual tunnel decapsulation on the data packet when the first virtual port number in the first field is successfully checked. This can effectively verify the integrity and accuracy of the data packet received by the receiving device, while ensuring the necessity of virtual tunnel decapsulation and avoiding unnecessary waste of resources.

[0401] The data packet verification scheme is applicable not only to receiving devices but also to forwarding devices between sending and receiving devices. This allows data packets to be discarded promptly when verification fails, improving the effectiveness of packet transmission and avoiding wasted resources.

[0402] The verification scheme for acknowledgment messages can refer to the verification scheme for data messages, and will not be elaborated here.

[0403] The message transmission method further includes, after updating the first field with the first original port number, updating the fifth field with the first checksum of the first original port number; verifying the first original port number of the first field with the first checksum of the fifth field; and performing transport layer protocol processing, including: performing transport layer protocol processing when the verification of the first original port number of the first field is successful.

[0404] Here, the receiving device can also verify the data packets decapsulated through the virtual tunnel. For example, after extracting the first original port number from the second field and updating the first field with the first original port number, the receiving device, considering that the value of the first field has been updated from the first virtual port number to the first original port number, updates the fifth field with the first checksum of the first original port number and verifies the first original port number in the first field with the first checksum of the fifth field. When the verification of the first original port number in the first field fails, it proves that the data packet may have lost or been tampered with. Therefore, the receiving device can choose not to continue processing the data packet, for example, it can directly discard the data packet. When the verification of the first original port number in the first field succeeds, it proves that the data packet is complete and accurate. Therefore, the receiving device performs transport layer protocol processing on the data packet. In this way, in addition to verifying the data packets encapsulated through the virtual tunnel, the receiving device also verifies the data packets decapsulated through the virtual tunnel. Through this two-layer verification mechanism, the success rate and security of the receiving device's transport layer protocol processing can be improved.

[0405] Referring to Figure 43, after step 530 shown in Figure 40, the following may also be included:

[0406] Step 4310: The sending device places the first checksum in the sixth field of the data packet;

[0407] Referring to Figure 43, step 4030 shown in Figure 40 includes:

[0408] Step 4320: When the verification of the first virtual port number in the first field is successful, the receiving device extracts the first original port number from the second field and updates the first field with the first original port number;

[0409] Step 4330: The receiving device extracts the first check value from the sixth field and updates the fifth field with the first check value;

[0410] Step 4340: The receiving device uses the first check value in the fifth field to verify the first original port number in the first field;

[0411] Step 4350: When the verification of the first original port number in the first field is successful, the receiving device performs transport layer protocol processing.

[0412] Steps 4310 to 4350 are described in detail below.

[0413] In step 4310, the sending device places the first check value in the sixth field of the data packet.

[0414] While updating the fifth field with the second checksum using the first virtual port number, the sending device simultaneously places the original first checksum from the fifth field into the sixth field of the data packet, as shown in Figure 44. It is worth noting that placing the first checksum into the sixth field of the data packet can be considered part of the virtual tunnel encapsulation.

[0415] The sixth field and the second field can be the same field or different fields. When the sixth field and the second field are different fields, the processing method for the second field involved in the above embodiments (refer to step 3120 or step 3420) also applies to the sixth field.

[0416] In step 4320, when the verification of the first virtual port number in the first field is successful, the receiving device extracts the first original port number from the second field and updates the first field with the first original port number.

[0417] In step 4330, the receiving device extracts the first check value from the sixth field and updates the fifth field with the first check value.

[0418] During the process of virtual tunnel decapsulation of data packets by the receiving device, in addition to extracting the first original port number from the second field and updating the first field with the first original port number, the first check value is also extracted from the sixth field and the fifth field is updated with the first check value, as shown in Figure 45.

[0419] In step 4340, the receiving device verifies the first original port number in the first field using the first check value in the fifth field.

[0420] In step 4350, when the verification of the first original port number in the first field is successful, the receiving device performs transport layer protocol processing.

[0421] In steps 4310 to 4350 above, the sending device places the first check value in the sixth field of the data packet. In this way, after the receiving device updates the first field with the first original port number, it can extract the first check value from the sixth field and update the fifth field with the first check value. Thus, by transmitting the first check value through the sixth field, effective verification of the data packet decapsulated through the virtual tunnel can be achieved, ensuring that the data packet decapsulated through the virtual tunnel is accurate and error-free, thereby improving the success rate and security of the receiving device in processing the transport layer protocol.

[0422] Referring to Figure 46, step 4030 shown in Figure 40 may include:

[0423] Step 4610: When the verification of the first virtual port number in the first field is successful, the receiving device extracts the first original port number from the second field and updates the first field with the first original port number;

[0424] Step 4620: The receiving device calculates a first check value based on the first original port number in the first field, and updates the fifth field with the first check value;

[0425] Step 4630: The receiving device uses the first check value in the fifth field to verify the first original port number in the first field;

[0426] Step 4640: When the verification of the first original port number in the first field is successful, the receiving device performs transport layer protocol processing.

[0427] Steps 4610 to 4640 are described in detail below.

[0428] In step 4610, when the verification of the first virtual port number in the first field is successful, the receiving device extracts the first original port number from the second field and updates the first field with the first original port number.

[0429] In step 4620, the receiving device calculates a first check value based on the first original port number of the first field, and updates the fifth field with the first check value.

[0430] During the process of virtual tunnel decapsulation of data packets by the receiving device, in addition to extracting the first original port number from the second field and updating the first field with the first original port number, the first check value is calculated based on the first original port number in the first field and the fifth field is updated with the first check value, as shown in Figure 47.

[0431] In step 4630, the receiving device verifies the first original port number in the first field using the first check value in the fifth field.

[0432] Here, the receiving device uses the first check value of the fifth field to verify the first original port number of the first field. Since the first check value of the fifth field is calculated based on the first original port number in step 4620, a successful verification result is usually obtained in step 4630.

[0433] In step 4640, when the verification of the first original port number in the first field is successful, the receiving device performs transport layer protocol processing.

[0434] In steps 4610 to 4640 above, the receiving device calculates the first check value based on the first original port number in the first field, and updates the fifth field with the first check value. In this way, it is ensured that the data packet decapsulated through the virtual tunnel is consistent with the data packet initially generated by the sending device, which can improve the success rate of the receiving device in processing the transport layer protocol.

[0435] Example of the specific usage process of the message transmission method in this disclosure embodiment

[0436] The following explanation uses an IPv4 network with TCP as the transport layer protocol as an example.

[0437] As an example, this disclosure provides a schematic diagram of an IPv4 network as shown in Figure 48. In Figure 48, solid lines between different devices represent physical links, the width of the solid lines represents the congestion level of the physical links, and dashed lines with arrows together constitute the communication path. In Figure 48, server H0 and server H3 in the IPv4 network establish a TCP connection (communication connection), and the communication path used by the TCP connection to transmit packets is H0-L0-S0-L2-H3. In the native TCP scheme, regardless of whether the communication path becomes congested (e.g., the physical link L0-S0 in Figure 48 has a high degree of congestion) or a network failure causes a timeout retransmission, the route will not be changed. This is mainly because the information used for routing calculations is a 5-tuple, and the information used for TCP connection identification is also a 5-tuple. If a certain item in the 5-tuple is changed to change the route, it will affect TCP connection identification and cause the TCP connection to be interrupted.

[0438] To reduce costs and address the low average traffic intensity, IPv4 networks are often designed with convergent bandwidth, which means they are more prone to congestion. However, in actual business operations, the average traffic on IPv4 networks is usually quite low. Most of the time, only a small number of physical links are congested, while other physical links are relatively idle. This means that routing during congestion can yield significant benefits. Therefore, in this embodiment, when congestion is detected in the communication path of a TCP connection, the TCP connection is switched to a less congested communication path, thereby effectively resolving the congestion problem, better utilizing the resources of the IPv4 network, and effectively improving packet transmission efficiency. As shown in Figure 49, this embodiment detects congestion in the communication path H0-L0-S0-L2-H3 of the TCP connection. Therefore, the communication path of the TCP connection is switched from H0-L0-S0-L2-H3 to H0-L1-S1-L3-H3.

[0439] Referring to Figures 50 and 51, this embodiment can be implemented as a custom module (similar to a kernel module in a Linux system) in the data transmission stack of a server. This custom module includes a connection component and a custom sublayer. The connection component is located within the TCP layer and its functionality is extended by modifying the source code of standard TCP (native TCP). This extension primarily involves attribute and logical extensions. Attribute extension refers to adding path-related state attributes (path attributes), including virtual source and destination port numbers, to implement lightweight virtual tunnel encapsulation, i.e., controlling the path's direction. Logical extension refers to adding throughput detection (congestion detection), path control, and path switching logic. The custom sublayer is located between the TCP and IP layers and is responsible for modifying packets in the receiving direction, thus achieving transparency to standard TCP processing. It is worth noting that this embodiment does not perform reliable transmission of upper-layer traffic, but rather performs lightweight virtual tunnel encapsulation and data flow throughput detection on packets, thereby improving data flow throughput and service availability.

[0440] Referring to Figure 52, which is a schematic flowchart of message transmission via TCP connection provided in an embodiment of this disclosure, a detailed description will be given in conjunction with Figure 52.

[0441] Step 1) When a TCP connection sends data, it first determines whether to allow the transmission based on the congestion control algorithm, as shown in ① of Figure 52.

[0442] Step 2) If the congestion control algorithm allows sending, then the standard TCP sending process (including sliding window processing, sequence number allocation, etc.) is entered, as shown in ② of Figure 52.

[0443] Step 3) After the standard TCP sending process is completed, the path control logic of this embodiment will be entered, as shown in ③ of Figure 52.

[0444] Step 4) In the path control logic, the packet header is modified to control the communication path of the packet. This embodiment inserts a custom sublayer between the transport layer and the IP layer. After the packet header is modified by the path control logic, it is delivered to the custom sublayer, which then passes the packet to the IP layer, as shown in ④ of Figure 52.

[0445] Step 5) After receiving the message from the IP layer, in this embodiment of the disclosure, the custom sublayer first performs the receiving process, that is, modifies the packet header to restore the message to the format before path control, so that the receiving process of the custom sublayer is transparent to TCP, as shown in ⑤ of Figure 52.

[0446] Step 6) After the custom sublayer has completed the receiving process, the message has been restored to the format before path control. At this time, the message is delivered to the standard TCP receiving process, as shown in ⑥ of Figure 52.

[0447] Step 7) In the standard TCP receive processing flow, the congestion control status (such as the congestion window value) will be updated, and the message will be delivered to the upper layer (i.e., the business application) for processing, as shown in ⑦ of Figure 52.

[0448] Step 8) The throughput detection logic of this embodiment continuously detects the congestion window value of the TCP connection, as shown in ⑧ of Figure 52.

[0449] Step 9) If the throughput detection logic detects that the congestion window value is less than the congestion window value threshold, it will notify the path switching logic to switch the communication path, as shown in ⑨ in Figure 52.

[0450] Step 10) The path switching logic will change the virtual source port number in the path attribute and take effect in the path control logic, as shown in ⑩ in Figure 52.

[0451] The following section will elaborate on the details of the workflow shown in Figure 52.

[0452] 1) Throughput detection logic.

[0453] This disclosure embodiment detects the congestion window value of TCP connections, enabling accurate determination of whether congestion has occurred in the communication path and avoiding missed or false alarms. For example, a moving average can be used to assess the degree of congestion. The formula for calculating the moving average is as follows: w a = (1-c)*w a +c*cwnd

[0454] Where c represents the moving average coefficient, a number greater than 0 and less than 1, which can be configured according to actual conditions, such as 0.1; cwnd represents the current congestion window value (i.e., the congestion window value corresponding to the current routing cycle); w on the right side of the equation a This represents the historical moving average (i.e., the moving average corresponding to the previous routing cycle); w on the left side of the equation a This represents the current moving average (i.e., the moving average corresponding to the current routing cycle).

[0455] Based on this, in this embodiment of the disclosure, the server updates cwnd using a congestion control algorithm each time it receives an acknowledgment message, and then updates w using the above formula. a .

[0456] When w a <w t When it is determined that the communication path is congested and a route switch is required, w is used.t =b*w m w t represents the congestion window threshold; b represents the configurable threshold coefficient, which is a number greater than 0 and not exceeding 1, for example, it can be configured to 0.4; w m This represents the maximum congestion window value, which could be, for example, the Bandwidth-Delay Product (BDP).

[0457] This embodiment of the disclosure does not require detection of congestion signals (such as packet loss count, explicit congestion notification, or packet delay), nor does it need to consider the specific congestion control algorithm used. It only needs to detect the congestion window value, as the congestion window value directly controls the throughput of TCP connections. However, the congestion window value is constantly changing dynamically. Therefore, a time-based moving average is performed in the above process to filter out small fluctuations and noise, ensuring that the obtained w... a The accuracy and effectiveness.

[0458] 2) Path control logic.

[0459] To implement path control, this embodiment of the disclosure requires modification of the source port number field and the destination port number field in the packet header. When the transport layer protocol uses TCP, the packet header is the TCP header, the format of which is shown in Figure 53. The implementation details of the path control logic will be described in detail below.

[0460] ① Initialize path attributes.

[0461] The path attributes mainly include the virtual source port number and the virtual destination port number, used to modify the TCP packet header. In this embodiment, a fixed destination port number (e.g., 4790) is used as the virtual destination port number. Destination port number 4790 is used to trigger the custom sublayer's receiving and processing flow; that is, the custom sublayer will only receive and process packets with a destination port number of 4790. If some TCP traffic in the network does not need to be received and processed by the custom sublayer, then when creating a TCP connection and allocating a destination port number, it is necessary to avoid destination port number 4790, thereby preventing this TCP traffic from being incorrectly received and processed by the custom sublayer. Conversely, if all TCP traffic in the network needs to be received and processed by the custom sublayer, the virtual destination port number can be configured arbitrarily without using a fixed destination port number; in this case, the custom sublayer will receive and process all packets.

[0462] The virtual source port number can be configured as a random source port number, or it can use the same source port number as the TCP connection. It's worth noting that the virtual source port number may be changed to a new source port number due to path switching.

[0463] ② Sending process (referring to the sending process in the path control logic).

[0464] As shown in Figure 54, when sending a message, the path control logic puts the original source port number, the original destination port number, and the first checksum (corresponding to the checksum value mentioned above) from the TCP header into the Option field. Then, it updates the source port number field with the virtual source port number from the path attribute, updates the destination port number field with the virtual destination port number from the path attribute, and calculates the second checksum. The purpose of updating the source port number field and the destination port number field with the virtual source port number from the path attribute is to control the communication path of the message. The purpose of putting the original source port number, the original destination port number, and the first checksum from the TCP header into the Option field is to ensure that they can be recovered during reception processing, thus making the processing of this embodiment transparent to TCP.

[0465] Additionally, saving the first checksum to the Options field avoids recalculating the checksum during receive processing. It's worth noting that when updating the source port number field with the virtual source port number in the path attribute, and when updating the destination port number field with the virtual destination port number in the path attribute, a second checksum needs to be calculated. This is because the checksum is calculated based on the TCP header and TCP data. Since the content and length of the TCP header have been updated, the second checksum needs to be recalculated to prevent subsequent packet checksum failures from causing packets to be discarded.

[0466] ③ Reception processing (here referring to reception processing in path control logic, i.e., reception processing of custom sub-layers).

[0467] After the packet exits the IP layer, it is distributed based on the destination port number. If the value of the destination port number field in the packet is 4790, the packet is distributed to the custom sublayer for reception processing. As shown in Figure 55, in the reception processing flow of the custom sublayer, the source port number field is updated with the original source port number in the Option field, the destination port number field is updated with the original destination port number in the Option field, the checksum field is updated with the first checksum in the Option field, and then the Option field is cleared to zero. In this way, the originally generated packet can be recovered, making the reception processing flow transparent to standard TCP.

[0468] In the above-mentioned path control logic's sending and receiving processes, virtual tunnel encapsulation and decapsulation are implemented through the Options field in the TCP header. Alternatively, virtual tunnel encapsulation and decapsulation can be implemented through custom fields in the custom header, as shown in Figures 56 and 57. In the virtual tunnel decapsulation process in Figure 57, the custom header needs to be deleted.

[0469] In the above-mentioned path control logic sending process, the first checksum needs to be saved to the Options field. Alternatively, the first checksum can be recalculated in the path control logic receiving process when updating the source port number field with the original source port number in the Option field and when updating the destination port number field with the original destination port number in the Option field.

[0470] 3) Path switching logic.

[0471] When the throughput detection logic detects congestion on the communication path, it triggers path switching logic. This logic reconfigures a virtual source port number randomly in the path attributes. Subsequent packets will then use this new virtual source port number to modify the TCP header, thus achieving path switching. Two points need clarification here:

[0472] ① Switching timing: Switching from the original path to the new path may cause out-of-order packets to appear on the receiving device of the TCP connection. In order to reduce out-of-order packets, the path switching can be set to be performed only after the TCP connection has been idle for a period of time (such as 1ms). TCP connection idle means that the sending window value is zero (empty).

[0473] ② Switching Interval: After switching paths once, a certain interval (e.g., 10ms) is required before the next path switch can proceed. This is because after switching paths, the TCP connection's traffic undergoes congestion control again on the new path, and the convergence of the congestion control algorithm (i.e., from initial adjustment to stability) requires a certain amount of time.

[0474] The embodiments disclosed herein have at least the following technical effects:

[0475] 1) Significantly reduces the impact of network congestion on TCP service traffic in IPv4 networks, improves TCP connection throughput, and thus increases service IOPS. Embodiments of this disclosure allow TCP connections that detect congestion to switch to a less congested or even completely uncongested communication path within 100ms (possibly less), increasing TCP connection throughput by more than 50%. For example, as shown in Figure 58, if a communication path becomes congested, the native TCP solution can only tolerate the congestion, and the throughput will drop to 30Gbps for a long time. However, embodiments of this disclosure can switch to an idle communication path within 100ms after congestion, restoring the throughput to 100Gbps.

[0476] 2) The embodiments disclosed herein can significantly reduce network congestion points and distribute network traffic more evenly across all communication paths, thereby increasing the overall network throughput by more than 20%.

[0477] 3) It can achieve adaptive routing of TCP service traffic in congested scenarios in IPv4 networks without upgrading the network (e.g., no need to upgrade to IPv6) or changing the switch configuration (e.g., no need to configure the switch to support overlay networks), which is low-cost and highly applicable.

[0478] Description of apparatus and devices according to embodiments of this disclosure

[0479] It is understood that although the steps in the above flowcharts are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated in this embodiment, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the above flowcharts may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0480] It should be noted that in all specific embodiments of this disclosure, when processing of messages is required, permission or consent from the relevant parties is obtained first, and the processing of messages complies with the relevant laws, regulations, and standards of the relevant countries and regions. Furthermore, when this disclosure requires message processing, separate permission or consent from the relevant parties is obtained through pop-up windows or redirection to a confirmation page, and the message is processed only after obtaining the separate permission or consent from the relevant parties.

[0481] Referring to Figure 59, which is a schematic diagram of the structure of a message transmission device 5900 provided in an embodiment of the present disclosure, the message transmission device 5900 includes:

[0482] The data packet generation module 5910 is used to generate data packets; wherein, the first field in the data packet has a first original port number;

[0483] The first congestion determination module 5920 is used to determine that the first original path from the transmitting device to the receiving device is congested based on the congestion window value corresponding to the current routing period of the transmitting device.

[0484] The data packet encapsulation module 5930 is used to select the first virtual port number corresponding to the current routing period from the first candidate port number set, update the first field with the first virtual port number, and place the first original port number in the second field of the data packet; the first virtual port number is used to perform routing calculations to obtain the first alternative path from the sending device to the receiving device.

[0485] The data packet sending module 5940 is used to send data packets so that after the receiving device receives the data packet, it can extract the first original port number from the second field and update the first field with the first original port number for transport layer protocol processing.

[0486] The message transmission device 5900 may further include an acknowledgment message receiving module (not shown) for receiving an acknowledgment message for the data message from the receiving device; wherein the acknowledgment message has a third field and a fourth field, the third field having a second virtual port number selected by the receiving device from the second candidate port number set, and the fourth field having a second original port number, the second virtual port number being used to perform routing calculations to obtain a second alternative path from the receiving device to the sending device;

[0487] The message transmission apparatus 5900 also includes an acknowledgment message decapsulation module (not shown) for extracting the second original port number from the fourth field and updating the third field with the second original port number for transport layer protocol processing.

[0488] The data packet may also have a fifth field, which has a first check value of the first original port number; the data packet encapsulation module 5930 is also used to update the fifth field with the second check value of the first virtual port number, so that after the receiving device receives the data packet, it can use the second check value of the fifth field to verify the first virtual port number of the first field, and when the verification of the first virtual port number of the first field is successful, it can extract the first original port number from the second field and update the first field with the first original port number.

[0489] The data packet encapsulation module 5930 can also be used to place the first check value in the sixth field of the data packet, so that after the receiving device updates the first field with the first original port number, it can extract the first check value from the sixth field, update the fifth field with the first check value, verify the first original port number in the first field with the first check value in the fifth field, and perform transport layer protocol processing when the verification of the first original port number in the first field is successful.

[0490] The first original port number may include a first original source port number and a first original destination port number; the first field includes a seventh field containing the first original source port number and an eighth field containing the first original destination port number; the data packet encapsulation module 5930 is also used for:

[0491] Select the first virtual source port number corresponding to the current routing cycle from the first candidate source port number set, and update the seventh field with the first virtual source port number;

[0492] Select the first virtual destination port number corresponding to the current routing period from the first candidate destination port number set, and update the eighth field with the first virtual destination port number; wherein, the candidate destination port number in the first candidate destination port number set is used to trigger the receiving device to update the seventh and eighth fields.

[0493] The first original port number may include at least one of the first original source port number and the first original destination port number, and the first field may include at least one of the seventh field having the first original source port number and the eighth field having the first original destination port number.

[0494] The data packet encapsulation module 5930 is also used for:

[0495] Perform at least one of the following processes:

[0496] Select the first virtual source port number corresponding to the current routing cycle from the first candidate source port number set, and update the seventh field with the first virtual source port number;

[0497] Select the port number of the first virtual destination corresponding to the current routing cycle from the first candidate destination port number set, and update the eighth field with the port number of the first virtual destination.

[0498] The data packet encapsulation module 5930 can also be used for:

[0499] Routing calculations are performed based on multiple candidate port numbers in the first candidate port number set to obtain the correspondence between multiple candidate port numbers and multiple physical ports of the sending device;

[0500] Determine the port load level of multiple physical ports;

[0501] The physical port with the lowest port load is identified as the target physical port, and the candidate port number corresponding to the target physical port is identified as the filtered port number.

[0502] Select the first virtual port number corresponding to the current routing cycle from the filtered port numbers.

[0503] The data packet encapsulation module 5930 can also be used for:

[0504] Based on multiple candidate port numbers in the first candidate port number set, a routing calculation is performed to obtain multiple candidate replacement paths from the sending device to the receiving device;

[0505] Determine the path overlap between the first original path and multiple candidate replacement paths;

[0506] The candidate port number corresponding to the candidate replacement path with the minimum path overlap is determined as the first virtual port number corresponding to the current routing cycle.

[0507] The data packet encapsulation module 5930 can also be used for:

[0508] Identify overlapping paths among multiple congested paths from the transmitting device to the receiving device;

[0509] Based on multiple candidate port numbers in the first candidate port number set, a routing calculation is performed to obtain multiple candidate replacement paths from the sending device to the receiving device;

[0510] The candidate port number corresponding to the candidate replacement path that excludes overlapping paths is determined as the first virtual port number corresponding to the current routing cycle.

[0511] The first congestion determination module 5920 can also be used for:

[0512] The congestion window value corresponding to the current routing cycle and the congestion window values ​​corresponding to historical routing cycles are merged to obtain the merged congestion window value.

[0513] When the fusion congestion window value is less than the congestion window value threshold, it is determined that the first original path from the transmitting device to the receiving device is congested.

[0514] The data packet encapsulation module 5930 can also be used for:

[0515] When the path switching conditions are met, select the first virtual port number corresponding to the current routing cycle from the first candidate port number set;

[0516] The path switching conditions include at least one of the following: the sending window value corresponding to the current routing cycle of the sending device is zero and the duration reaches a first duration threshold; the interval between the last selection of the first candidate port number set reaches a second duration threshold.

[0517] The data packet encapsulation module 5930 can also be used for:

[0518] Perform any of the following processes:

[0519] The second field of the data packet is updated with the first original port number so that the receiving device can update the second field with the original value of the second field after extracting the first original port number from the second field.

[0520] A second field is created based on the first original port number and added to the data packet so that the receiving device can delete the second field from the data packet after extracting the first original port number from the second field.

[0521] Referring to Figure 60, which is a schematic diagram of the structure of a message transmission device 6000 provided in an embodiment of the present disclosure, the message transmission device 6000 includes:

[0522] The data packet receiving module 6010 is used to receive data packets from the sending device. The data packet has a first field and a second field. The first field has a first virtual port number, and the second field has a first original port number. The first virtual port number is selected by the sending device from a first set of candidate port numbers when the first original path from the sending device to the receiving device is congested, based on the congestion window value corresponding to the current routing cycle of the sending device. The first virtual port number is used to perform routing calculations to obtain a first alternative path from the sending device to the receiving device.

[0523] The data packet decapsulation module 6020 is used to extract the first original port number from the second field and update the first field with the first original port number for transport layer protocol processing.

[0524] The message transmission device 6000 also includes an acknowledgment message generation module (not shown) for generating an acknowledgment message for the data message; wherein the third field in the acknowledgment message has a second original port number;

[0525] The message transmission device 6000 also includes a second congestion determination module (not shown), used to determine that the second original path from the receiving device to the transmitting device is congested based on the congestion window value corresponding to the current routing period of the receiving device;

[0526] The message transmission device 6000 also includes an acknowledgment message encapsulation module (not shown), which is used to select the second virtual port number corresponding to the current routing period from the second candidate port number set, update the third field with the second virtual port number, and place the second original port number in the fourth field of the acknowledgment message. The second virtual port number is used to perform routing calculations to obtain the second alternative path from the receiving device to the sending device.

[0527] The message transmission device 6000 also includes an acknowledgment message sending module (not shown) for sending an acknowledgment message so that after receiving the acknowledgment message, the sending device can extract the second original port number from the fourth field and update the third field with the second original port number for transport layer protocol processing.

[0528] The data packet also has a fifth field, which contains a second checksum of the first virtual port number; the data packet decapsulation module 6020 is also used for:

[0529] Use the second check value in the fifth field to verify the first virtual port number in the first field;

[0530] When the first virtual port number in the first field is successfully verified, the first original port number is extracted from the second field and the first field is updated with the first original port number.

[0531] The data packet decapsulation module 6020 is also used for:

[0532] Update the fifth field with the first checksum of the first original port number;

[0533] Use the first check value in the fifth field to verify the first original port number in the first field;

[0534] When the first original port number in the first field is successfully verified, transport layer protocol processing is performed.

[0535] The data packet decapsulation module 6020 is also used for:

[0536] Perform any of the following processes:

[0537] Extract the first checksum from the sixth field of the data packet;

[0538] Calculate the first checksum based on the first original port number in the first field.

[0539] Referring to Figure 61, which is a partial structural block diagram of a terminal 130 implementing the message transmission method of this embodiment, the terminal includes: a radio frequency (RF) circuit 6110, a memory 6115, an input unit 6130, a display unit 6140, a sensor 6150, an audio circuit 6160, a wireless fidelity (WiFi) module 6170, a processor 6180, and a power supply 6190, etc. Those skilled in the art will understand that the terminal structure shown in Figure 61 does not constitute a limitation on a mobile phone or computer, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0540] The RF circuit 6110 can be used to receive and transmit signals during information transmission or calls. In particular, it receives downlink information from the base station and processes it with the processor 6180; in addition, it transmits uplink data to the base station.

[0541] The memory 6115 can be used to store software programs and modules. The processor 6180 executes various terminal functions and data processing by running the software programs and modules stored in the memory 6115.

[0542] The input unit 6130 can be used to receive input numeric or character information, and to generate key signal inputs related to the terminal's settings and function control. Specifically, the input unit 6130 may include a touch panel 6131 and other input devices 6132.

[0543] The display unit 6140 can be used to display input or provided information, as well as various menus of the terminal. The display unit 6140 may include a display panel 6141.

[0544] Audio circuit 6160, speaker 6161, and microphone 6162 provide an audio interface.

[0545] In this embodiment, the processor 6180 included in the terminal can execute the message transmission method of the previous embodiment.

[0546] The terminals disclosed in this embodiment include, but are not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, and aircraft. The embodiments of this invention can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, and assisted driving.

[0547] Referring to Figure 62, which is a partial structural block diagram of a server 110 implementing the message transmission method of this disclosure, the server 110 can vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 6222 (e.g., one or more processors) and a memory 6232, and one or more storage media 6230 (e.g., one or more mass storage devices) storing application programs 6242 or data 6244. The memory 6232 and storage media 6230 can be temporary or persistent storage. The program stored in the storage media 6230 may include one or more modules (not shown in the figure), each module including a series of instruction operations on the server 6200. Furthermore, the CPU 6222 may be configured to communicate with the storage media 6230 and execute the series of instruction operations in the storage media 6230 on the server 6200.

[0548] Server 6200 may also include one or more power supplies 6226, one or more wired or wireless network interfaces 6250, one or more input / output interfaces 6258, and / or one or more operating systems 6241, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0549] The processor in server 6200 can be used to execute the message transmission method of the present disclosure embodiments.

[0550] This disclosure also provides a computer-readable storage medium for storing a computer program for executing the message transmission methods of the foregoing embodiments.

[0551] This disclosure also provides a computer program product, which includes a computer program. The processor of an electronic device reads and executes the computer program, causing the electronic device to perform the message transmission method described above.

[0552] In related technologies, due to limitations of transport layer protocols, the five-tuple (including source port number, destination port number, etc.) in the messages transmitted between the sending and receiving devices is usually fixed. Forwarding devices in the message transmission network typically select routes based on the five-tuple in the message. This means that the sending device can only send messages to the receiving device along a fixed communication path, and therefore, even if the communication path becomes congested, it has to endure the congestion. In this embodiment, the field recording the port number in the data packet is set to be replaceable during the routing process and recoverable during the receiving process, thus not affecting the transport layer protocol processing. Specifically, after determining that the first original path from the sending device to the receiving device is congested, a first virtual port number is selected from the first candidate port number set to try a new path, and the field recording the port number, i.e., the first field, is updated with the first virtual port number. The first virtual port number is used to select a new path, but the first original port number is needed in the subsequent transport layer protocol processing. Therefore, in this embodiment of the present disclosure, the first original port number is placed in the second field so that after the receiving device receives the data packet, it can recover the first original port number according to the second field, thereby achieving the effect of trying the selection of a new path to solve the congestion problem without affecting the transport layer protocol processing, thus improving the packet transmission efficiency.

[0553] Other features and advantages of this disclosure will be apparent in part from the description, or may be learned by practicing the disclosure. The objectives and other advantages of this disclosure may be realized and obtained by means of the structures particularly pointed out in the description, claims, and drawings.

[0554] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in this disclosure and the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this disclosure described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “including,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0555] It should be understood that in this disclosure, "at least one item" means one or more, and "more than one" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0556] It should be understood that in the description of the embodiments disclosed herein, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0557] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0558] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0559] Furthermore, the functional units in the various embodiments of this disclosure 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0560] 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 computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, 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 (computer programs) to cause an electronic device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing computer programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0561] It should also be understood that the various implementation methods provided in this disclosure can be combined arbitrarily to achieve different technical effects.

[0562] In this disclosure, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0563] The above is a detailed description of the embodiments of this disclosure. However, this disclosure is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this disclosure. All such equivalent modifications or substitutions are included within the scope defined by the claims of this disclosure.

Claims

1. A message transmission method, characterized in that, Applied to a sending device; the message transmission method includes: Generate a data packet; wherein, the first field in the data packet has a first original port number; Based on the congestion window value corresponding to the current routing period of the transmitting device, it is determined that the first original path from the transmitting device to the receiving device is congested. Select the first virtual port number corresponding to the current routing period from the first candidate port number set, update the first field with the first virtual port number, and place the first original port number in the second field of the data packet; the first virtual port number is used to perform routing calculations to obtain a first alternative path from the sending device to the receiving device. The data packet is sent so that after the receiving device receives the data packet, it can extract the first original port number from the second field and update the first field with the first original port number for transport layer protocol processing.

2. The message transmission method according to claim 1, characterized in that, After sending the data packet, the packet transmission method further includes: The receiving device receives an acknowledgment message for the data packet; wherein the acknowledgment message has a third field and a fourth field, the third field has a second virtual port number selected by the receiving device from a second candidate port number set, and the fourth field has a second original port number, the second virtual port number being used to perform routing calculations to obtain a second alternative path from the receiving device to the sending device; The second original port number is extracted from the fourth field, and the third field is updated with the second original port number for transport layer protocol processing.

3. The message transmission method according to claim 1 or 2, characterized in that, The data packet also has a fifth field, which has a first check value for the first original port number; After updating the first field with the first virtual port number, the message transmission method further includes: The fifth field is updated with the second checksum of the first virtual port number, so that after the receiving device receives the data packet, it uses the second checksum of the fifth field to verify the first virtual port number in the first field, and when the verification of the first virtual port number in the first field is successful, it extracts the first original port number from the second field and updates the first field with the first original port number.

4. The message transmission method according to claim 3, characterized in that, After updating the first field with the first virtual port number, the message transmission method further includes: The first check value is placed in the sixth field of the data packet so that after the receiving device updates the first field with the first original port number, it can extract the first check value from the sixth field, update the fifth field with the first check value, verify the first original port number in the first field with the first check value in the fifth field, and perform transport layer protocol processing when the verification of the first original port number in the first field is successful.

5. The message transmission method according to any one of claims 1 to 4, characterized in that, The first original port number includes at least one of a first original source port number and a first original destination port number, and the first field includes at least one of a seventh field having the first original source port number and an eighth field having the first original destination port number. The step of selecting the first virtual port number corresponding to the current routing period from the first candidate port number set and updating the first field with the first virtual port number includes: Perform at least one of the following processes: Select the first virtual source port number corresponding to the current routing period from the first candidate source port number set, and update the seventh field with the first virtual source port number; Select the port number of the first virtual destination corresponding to the current routing cycle from the first candidate destination port number set, and update the eighth field with the first virtual destination port number.

6. The message transmission method according to any one of claims 1 to 5, characterized in that, The step of selecting the first virtual port number corresponding to the current routing period from the first candidate port number set includes: A routing operation is performed based on multiple candidate port numbers in the first candidate port number set to obtain the correspondence between the multiple candidate port numbers and multiple physical ports of the transmitting device; Determine the port load level of the multiple physical ports; The physical port with the lowest port load is identified as the target physical port, and the candidate port number corresponding to the target physical port is identified as the filtered port number. Select the first virtual port number corresponding to the current routing cycle from the filtered port numbers.

7. The message transmission method according to any one of claims 1 to 6, characterized in that, The step of determining that the first original path from the transmitting device to the receiving device is congested based on the congestion window value corresponding to the current routing period of the transmitting device includes: The congestion window value corresponding to the current routing cycle and the congestion window value corresponding to the historical routing cycles are fused to obtain a fused congestion window value. When the fusion congestion window value is less than the congestion window value threshold, it is determined that the first original path from the transmitting device to the receiving device is congested.

8. The message transmission method according to any one of claims 1 to 7, characterized in that, The step of selecting the first virtual port number corresponding to the current routing period from the first candidate port number set includes: When the path switching condition is met, the first virtual port number corresponding to the current routing period is selected from the first candidate port number set. The path switching conditions include at least one of the following: the sending window value corresponding to the current routing cycle of the sending device is zero and the duration reaches a first duration threshold; the interval between the last selection of the first candidate port number set reaches a second duration threshold.

9. The message transmission method according to any one of claims 1 to 8, characterized in that, The step of placing the first original port number in the second field of the data packet includes: Perform any of the following processes: The second field of the data packet is updated with the first original port number so that the receiving device updates the second field with the original value of the second field after extracting the first original port number from the second field. A second field is created based on the first original port number, and the second field is added to the data packet so that the receiving device deletes the second field from the data packet after extracting the first original port number from the second field.

10. A message transmission method, characterized in that, Applied to receiving devices; the message transmission method includes: A data packet is received from a sending device; wherein the data packet has a first field and a second field, the first field having a first virtual port number and the second field having a first original port number; the first virtual port number is selected by the sending device from a first set of candidate port numbers when the first original path from the sending device to the receiving device is congested based on the congestion window value corresponding to the current routing period of the sending device; the first virtual port number is used to perform routing calculations to obtain a first alternative path from the sending device to the receiving device; The first original port number is extracted from the second field, and the first field is updated with the first original port number for transport layer protocol processing.

11. The message transmission method according to claim 10, characterized in that, After extracting the first original port number from the second field and updating the first field with the first original port number for transport layer protocol processing, the message transmission method further includes: Generate an acknowledgment message for the data packet; wherein the third field in the acknowledgment message has a second original port number; Based on the congestion window value corresponding to the current routing period of the receiving device, it is determined that the second original path from the receiving device to the transmitting device is congested. Select the second virtual port number corresponding to the current routing period from the second candidate port number set, update the third field with the second virtual port number, place the second original port number in the fourth field of the acknowledgment message, and use the second virtual port number to perform routing calculations to obtain the second alternative path from the receiving device to the sending device; The acknowledgment message is sent so that after receiving the acknowledgment message, the sending device can extract the second original port number from the fourth field and update the third field with the second original port number for transport layer protocol processing.

12. The message transmission method according to claim 10 or 11, characterized in that, The data packet also has a fifth field, which has a second check value for the first virtual port number; After receiving a data packet from the sending device, the packet transmission method further includes: The first virtual port number in the first field is verified using the second verification value of the fifth field; The step of extracting the first original port number from the second field and updating the first field with the first original port number includes: When the verification of the first virtual port number in the first field is successful, the first original port number is extracted from the second field and the first field is updated with the first original port number.

13. The message transmission method according to claim 12, characterized in that, After updating the first field with the first original port number, the message transmission method further includes: Update the fifth field with the first checksum of the first original port number; The first original port number in the first field is verified using the first verification value in the fifth field. The process of performing transport layer protocol processing includes: When the verification of the first original port number in the first field is successful, transport layer protocol processing is performed.

14. The message transmission method according to claim 13, characterized in that, Before updating the fifth field with the first checksum of the first original port number, the message transmission method further includes: Perform any of the following processes: Extract the first checksum from the sixth field of the data packet; The first checksum is calculated based on the first original port number contained in the first field.

15. A message transmission device, characterized in that, Applied to a sending device; the message transmission device includes: A data packet generation module is used to generate data packets; wherein, the first field in the data packet has a first original port number; The first congestion determination module is used to determine, based on the congestion window value corresponding to the current routing period of the transmitting device, that the first original path from the transmitting device to the receiving device is congested. The data packet encapsulation module is used to select a first virtual port number corresponding to the current routing period from the first candidate port number set, update the first field with the first virtual port number, and place the first original port number in the second field of the data packet; the first virtual port number is used to perform routing calculations to obtain a first alternative path from the sending device to the receiving device. The data packet sending module is used to send the data packet so that after the receiving device receives the data packet, it can extract the first original port number from the second field and update the first field with the first original port number for transport layer protocol processing.

16. A message transmission device, characterized in that, Applied to receiving devices; the message transmission device includes: A data packet receiving module is used to receive data packets from a sending device; wherein, the data packet has a first field and a second field, the first field having a first virtual port number, and the second field having a first original port number; the first virtual port number is selected by the sending device from a first candidate port number set when the sending device determines that the first original path from the sending device to the receiving device is congested based on the congestion window value corresponding to the current routing period of the sending device; the first virtual port number is used to perform routing calculations to obtain a first alternative path from the sending device to the receiving device; The data packet decapsulation module is used to extract the first original port number from the second field and update the first field with the first original port number for transport layer protocol processing.

17. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the message transmission method according to any one of claims 1 to 15.

18. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the message transmission method according to any one of claims 1 to 15.

19. A computer program product, the computer program product comprising a computer program, characterized in that, The computer program is read and executed by the processor of the electronic device, causing the electronic device to perform the message transmission method according to any one of claims 1 to 15.

Images