CN112291815A

CN112291815A - MPTCP connection establishment method and device

Info

Publication number: CN112291815A
Application number: CN202011233802.9A
Authority: CN
Inventors: 王小伟; 梧恒铭
Original assignee: Netease Hangzhou Network Co Ltd
Current assignee: Netease Hangzhou Network Co Ltd
Priority date: 2020-11-06
Filing date: 2020-11-06
Publication date: 2021-01-29
Anticipated expiration: 2040-11-06
Also published as: CN112291815B

Abstract

The embodiment of the invention provides an MPTCP connection establishment method and a device, which are applied to a plurality of load balancing nodes, and the method comprises the following steps: receiving a data message for a first MPTCP connection by adopting a first load balancing node, wherein the data message comprises a first connection identifier; determining a first back-end service node from the plurality of back-end service nodes, establishing a first MPTCP connection between the first load balancing node and the first back-end service node, generating a Token corresponding to the first MPTCP connection, and storing the Token in the global flow table; receiving a data message for a second MPTCP connection by adopting a second load balancing node, wherein the data message comprises a second connection identifier and the Token; and determining a first back-end service node matched with the Token from the global flow table, and establishing a second MPTCP connection between the second load balancing node and the first back-end service node. Therefore, the sub-connection of the MPTCP can be ensured to be a back end RS which is the same as the main connection after passing through the load balancing cluster.

Description

MPTCP connection establishment method and device

Technical Field

The present invention relates to the field of communications technologies, and in particular, to an MPTCP connection establishment method and an MPTCP connection establishment apparatus.

Background

In the TCP (Transmission Control Protocol) Protocol, each connection uses only one path for Transmission. However, in a new mobile internet environment, different Wireless access technologies are converged, and a terminal has multiple Network interfaces, for example, WiFi (Wireless Fidelity) and Cellular Network interfaces. At this time, a plurality of available paths exist between two terminals communicating with each other, and if only one path is used simultaneously according to the standard TCP protocol, other path resources are wasted. On the other hand, more and more application programs on the current terminal need internet access, and if the application programs can be accessed simultaneously through multiple paths of different interfaces, higher-level user experience can be ensured, and the influence of the wireless network due to the characteristics of link change, high error rate and the like is reduced.

Currently, the MPTCP (Multi-Path Transmission Control Protocol) technology can provide end-to-end Multi-link communication for a user equipment, and distributes service data to multiple links in a resource sharing manner to improve a network bandwidth. However, in a scenario of load balancing of MPTCP, Subflow sub-connections of the same MPTCP are allocated to different back-end RSs (Real Service), so that a kernel on the RS cannot aggregate traffic, and data viewed by an application layer is easily disturbed.

Disclosure of Invention

In view of the above problems, embodiments of the present invention are proposed to provide an MPTCP connection establishment method and a corresponding MPTCP connection establishment apparatus that overcome or at least partially solve the above problems.

In a first aspect, an embodiment of the present invention discloses an MPTCP connection establishment method, which is applied to a plurality of load balancing nodes, where the load balancing nodes are in communication connection with a plurality of backend service nodes, and the load balancing nodes configure a global flow table, where the method includes:

receiving a data message for a first MPTCP connection by adopting a first load balancing node, wherein the data message comprises a first connection identifier, and the first connection identifier is an MP _ CAPABLE field;

determining a first back-end service node from the plurality of back-end service nodes, establishing a first MPTCP connection between the first load balancing node and the first back-end service node, generating a Token corresponding to the first MPTCP connection, and storing the Token in the global flow table;

receiving a data message for a second MPTCP connection by using a second load balancing node, wherein the data message comprises a second connection identifier and the Token, and the second connection identifier is an MP _ JOIN field;

and determining a first back-end service node matched with the Token from the global flow table, and establishing a second MPTCP connection between the second load balancing node and the first back-end service node.

Optionally, the establishing a first MPTCP connection between the first load balancing node and the first backend service node includes:

forwarding the data packet for the first MPTCP connection to the first back-end service node;

receiving a response message which is returned by the first back-end service node after the data message is processed and contains a key value;

and establishing a first MPTCP connection between the load balancing node and the first back-end service node according to the key value.

Optionally, the generating and saving Token corresponding to the first MPTCP connection to the global flow table includes:

calculating to obtain a Token corresponding to the first MPTCP connection according to the key value;

storing the first back-end service node and the Token in the global flow table.

Optionally, the load balancing node has a plurality of network card queues, and after the step of receiving the data packet for the first MPTCP connection, the method further includes:

determining a target queue from the plurality of network card queues;

writing the data message into the target queue;

the storing the first backend service node and the Token in the global flow table includes:

multicasting a first back-end service node and the Token to a plurality of queues with the same sequence number corresponding to the target queue in the plurality of load balancing nodes;

and respectively storing the first back-end service node and the Token into a global flow table corresponding to the load balancing node where the queues are located.

Optionally, backend service nodes corresponding to the same Token in the global flow table are the same.

Optionally, the determining a first backend service node from the plurality of backend service nodes includes:

and determining a first back-end service node from the plurality of back-end service nodes according to a load balancing algorithm.

Optionally, the first load balancing node is the same as the second load balancing node, or the first load balancing node is different from the second load balancing node.

In a second aspect, an embodiment of the present invention further discloses an MPTCP connection establishment apparatus, which is applied to a plurality of load balancing nodes, where the plurality of load balancing nodes are in communication connection with a plurality of backend service nodes, and the plurality of load balancing nodes configure a global flow table, where the apparatus includes:

a first receiving module, configured to receive, by using a first load balancing node, a data packet for a first MPTCP connection, where the data packet includes a first connection identifier, and the first connection identifier is an MP _ able field;

the first connection module is used for determining a first back-end service node from the plurality of back-end service nodes, establishing a first MPTCP connection between the first load balancing node and the first back-end service node, generating a Token corresponding to the first MPTCP connection and storing the Token in the global flow table;

a second receiving module, configured to receive, by using a second load balancing node, a data packet for a second MPTCP connection, where the data packet includes a second connection identifier and the Token, and the second connection identifier is an MP _ JOIN field;

and the second connection module is used for determining a first back-end service node matched with the Token from the global flow table and establishing a second MPTCP connection between the second load balancing node and the first back-end service node.

In a third aspect, an embodiment of the present invention further discloses an electronic device, including:

the device comprises a processor, a storage medium and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, when an electronic device runs, the processor is communicated with the storage medium through the bus, and the processor executes the machine-readable instructions to execute the method according to any one of the embodiment of the invention.

In a fourth aspect, the present invention further discloses a storage medium, on which a computer program is stored, where the computer program is executed by a processor to perform the method according to any one of the embodiments of the present invention.

The embodiment of the invention has the following advantages:

in the embodiment of the present invention, by maintaining the Token in the global flow table of the LB node, the global flow table can enable the same Token to point to the same back-end RS, so that it can be ensured that the sub-connection of the MPTCP can be connected to the same back-end RS as the main connection after passing through the load balancing cluster, and thus the protocol stack of the RS can normally process the handshake of the sub-connection and the subsequent data transmission process.

Drawings

FIG. 1A is a schematic diagram of a TCP single channel connection;

FIG. 1B is a schematic diagram of an MPTCP dual channel connection;

FIG. 2 is a schematic diagram of a handshake flow of MPTCP;

FIG. 3 is a schematic diagram of a connection four-way handshake flow for a underflow setup;

FIG. 4 is a schematic diagram of a scenario in which MPTCP goes through a load balancing cluster;

FIG. 5 is a schematic diagram of an address reservation scheme;

FIG. 6 is a schematic diagram of a handshake flow after adding LB;

FIG. 7 is a schematic diagram of a handshake flow for underflow after adding LB;

FIG. 8 is a flowchart illustrating the steps of an embodiment of an MPTCP connection establishment method of the present invention;

FIG. 9 is a schematic diagram of a scenario in which MPTCP passes through a load balancing node cluster according to the present invention;

fig. 10 is a block diagram of an MPTCP connection setup apparatus according to an embodiment of the present invention;

FIG. 11 is a block diagram of an electronic device of the present invention;

fig. 12 is a block diagram of a storage medium of the present invention.

Detailed Description

In order to make the aforementioned objects, features and advantages of the present invention comprehensible, embodiments accompanied with figures are described in further detail below.

MPTCP is a TCP-based multi-path communication protocol. Multipath refers to both parties of communication connected to "the same" TCP, and communicates via a plurality of ports/ips without using one port or ip each.

As shown in fig. 1A, the TCP single-channel connection diagram shown in fig. 1B, as shown in fig. 1A and fig. 1B, the MPTCP may use multiple physical ports/IPs for TCP communication, which is to say that multiple connections are necessarily presented to a user in the TCP protocol, but the MPTCP protocol aggregates the connections in the kernel and still presents them to the user in the form of one TCP connection, so that the user-mode program does not have any cost for using MPTCP, and does not need to modify any underlying program, and only needs to configure policy routing at the operating system layer.

The benefits of multiple physical links are evident: the throughput is increased, the delay influence caused by a single link is reduced, and the resource utilization rate is improved. The advantages of throughput and resource utilization are well understood, in terms of delay, if the quality of a link under a TCP protocol is in a problem, the TCP connection delay under the link is increased, in an MPTCP scenario, because a plurality of physical links exist and are usually independent from each other, if the quality of a single link is in a problem, the MPTCP protocol can select to transmit more data through other links with good quality, so that the overall influence is reduced.

MPTCP principle: because the user state is completely insensitive to the MPTCP, three-way handshaking is performed according to the TCP protocol to establish connection, and in the handshaking stage, the MPTCP adds an Option weight to the TCP header, and a specific handshaking flow is as shown in fig. 2 below:

in fig. 2, the Master connection in MPTCP is established through three-way handshake, and the a/B hosts exchange respective random number Key values through MPTCP Option during the three-way handshake, and this Key is used in the subsequent establishment of Subflow sub-connection.

After the Master connection is established, if some host discovers other available ports, a Subflow connection establishment process is initiated, as shown in fig. 3, the Subflow connection establishment process is a four-way handshake, and the reason of the one-time handshake is that MPTCP uses SHA-1 algorithm encryption Key, and uses encrypted Token to authenticate, so as to prevent other illegal connections from trying to join the Master connection of the MPTCP. After the Subflow is established, the kernel is associated with the Master connection, subsequent data are aggregated and sent to an upper application layer, and the application layer is completely unaware in the Subflow establishing process and is independently completed by the kernel.

At present, the use of MPTCP is not extensive, and the protocol is still in the perfecting stage. The MPTCP is supported by each system as follows:

the latest version of the Linux MPTCP source code is v0.95 released in 2019 in 06 months, and is incorporated into Mainline of Linux Kernel in 2020 in 01 months.

The IOS7 started to support MPTCP, requiring a simple modification of the application, Apple's SiRi using MPTCP.

Android devices have difficulty accounting for MPTCP support, and the official mentioning Samsung' S Galaxy S6 and S6 Edge provides firmware for MPTCP support.

Windows temporarily does not support MPTCP.

A commonly used scene of the project using the MPTCP at present is a mobile device, the mobile device generally has two channels of WIFI and 4G/5G, the WIFI signal quality may change greatly along with the movement of the device, even the WIFI signal quality is directly disconnected, and the MPTCP can be used for ensuring that more flows are transmitted through 4G when the WIFI channel quality is poor, so that the connection quality of a user is ensured.

As shown in fig. 4, which is a schematic diagram of a scenario in which MPTCP goes through a load balancing cluster, for example, a user needs to connect to a backend RS through 4G and WIFI at the same time. The problem of the MPTCP in the load balancing scenario is that Subflow sub-connections of the same MPTCP are allocated to different back-end RSs, so that the cores on the back-end RSs cannot aggregate traffic, and data seen by an application layer is confused. The different Flow flows of MPTCP may be dispersed mainly at the following three nodes:

1) the switch ECMP is equivalently routed to different LB (load balance) nodes of the four-layer/seven-layer cluster;

2) network card RSS (received Side Scaling, network card drive) on the LB node is sent to different queues;

3) and the LB node selects a rear end RS according to a Hash Hash algorithm.

Since the three nodes select the next hop according to the quintuple, i.e., source IP (Internet Protocol), destination IP, Protocol, source port and destination port, but the flows established by MPTCP through different ports are definitely different in the quintuple, the data will be hashed to different back-end RSs, however, any node selects the back-end RS to be inconsistent, which may directly cause data errors of the MPTCP flow.

The MPTCP protocol is formulated without considering a load balancing scene, but the IP Networking Lab for formulating the protocol gives several design thoughts under the load balancing scene, and some designs are realized by referring to the design ideas.

MPTCP officials provide two ideas, the second of which has two proposals:

the first method comprises the following steps: per-server Address Address reservation.

The scheme is that each RS server is configured with a public network IP, but the IP does not directly access the user through DNS, and only the RS actively informs the Client through MPTCP. The feasible reason of the scheme is that Subflow is directly connected to the RS, and is not configured to the load balancing cluster, so that the problem that the Subflow is distributed to different RSs by the load balancing cluster does not exist. Fig. 5 shows a schematic diagram of an address reservation scheme.

And the second method comprises the following steps: the Embedding Extra Information in Packets adds Extra Information to the message.

The scheme is to add extra information in the message, and comprises the following two proposals:

proposed is that port is used as a unique identifier. The method comprises the following steps:

-client and vip: the vport establishes an init connection;

RS, when advertising a Subflow address, specifies a port, which is both a service port and a unique identity for each RS, and is different from vport;

-RS and vip: b, port establishes Subflow, when the load balance processes vip: vport connection, the original scheduling strategy (any algorithm such as consistent hash) is used, and when vip2 is processed: at port2, the RS is allocated according to port 2.

The proposal solves the problem that the Hash algorithm of the LB selects the RS, but does not solve the problems that the switch arrives at the LB and the RSS of the LB is self-solved. That is, if there is only one LB under the switch, not one LB cluster, and the LB has no sub-queue and core processing on the traffic, this proposal is feasible, and in fact, it is a usage scenario for load balancing.

Proposal II uses Token of RS as a unique identifier, and the specific method is as follows:

the handshake flow after adding LB is shown in fig. 6, the step of generating a Key of RS is moved to LB, LB generates a Key after receiving the Syn packet of MPTCP, and selects an RS according to the quintuple to encapsulate the IP of RS (i.e. alternate server IP in fig. 6) to the IP Option. After the RS receives the Key, the Token is calculated by using the Key generated by the LB, if the Token of the RS end conflicts, a plurality of keys are randomly generated by using an explosion method, and one Key is selected, wherein the corresponding upper 14 bits of the Token are consistent with the upper 14 bits of the Token of the LB. The RS shifts TSval by 14 bits to the left and fills the upper 14 bits of Token into the lower 14 bits of TSval when ACK acknowledgement is returned.

The key here is that the LB participates in the calculation of RS Token in the MPTCP protocol, and the LB cannot acquire the RS Token originally. Handshake procedure of Subflow after adding LB is shown in FIG. 7, and LB can know which RS to send Subflow according to RS Token in Subflow.

The two schemes offered by MPTCP authorities suffer from different drawbacks.

The first scheme, using the disadvantages of address reservation: RS needs an additional public network IP; 2. the MPTCP protocol stack of the Client needs to be modified to ensure that ADDR1 of the RS does not establish a connection with other IP of the Client. Because address reservation can only ensure that a plurality of IPs of the RS end can establish a plurality of connections by walking through the MPTCP channel, the Client end does not allow the same port to establish a plurality of connections.

In the second scheme, the disadvantages of different proposals in the extra information are added in the message:

aiming at the disadvantages that the proposal (i) uses a port as a unique identifier: 1. the problem of multiple IP of the Client is also not supported; 2. a user firewall is required to open a port; 3. only the hash problem from LB to backend RS can be solved.

Aiming at proposal II, the Token of RS is used as the only mark: 1. the Timestamp Option is multiplexed, and for a message without Timestamp, such as a Fin, a P2P protocol needs to be used alone to redirect traffic, and the influence of the PAWS needs to be considered. 2. Only the hash problem from LB to backend RS can be solved.

The address reservation scheme does not work since it is not possible to change the protocol; the schemes of port unique identification and RS-side Token unique identification have a common fatal problem, that is, the problem of hashing from LB to RS at the back end can only be solved, and the problem of hashing from a switch to LB and RSs of an LB node can not be guaranteed in our scene, so that the schemes are not feasible.

Therefore, in the embodiment of the present invention, the back-end RS of the main connection and the back-end RS corresponding to the back-end RS are stored in the load balancing node in a manner of maintaining the global flow table, so that the sub-connection can directly determine the back-end RS to be connected from the global flow table according to Token in the packet, and establish connection with the back-end RS, thereby ensuring that the sub-connection of the MPTCP can be connected to one back-end RS that is the same as the main connection after passing through the load balancing cluster, and the protocol stack of the RS can normally process the handshake of the sub-connection and the subsequent data transmission process.

Referring to fig. 8, a flowchart illustrating steps of an embodiment of an MPTCP connection establishment method according to the present invention is shown, and is applied to a plurality of load balancing nodes, where the plurality of load balancing nodes are in communication connection with a plurality of backend service nodes, and the plurality of load balancing nodes configure a global flow table, where the method specifically includes the following steps:

step 801, receiving a data message for a first MPTCP connection by using a first load balancing node, where the data message includes a first connection identifier, and the first connection identifier is an MP _ able field;

the MPTCP connection may include both a Master main connection and a Subflow sub-connection, and in the embodiment of the present invention, the first MPTCP connection may be the Master main connection. The data message for the first MPTCP connection may be SYN (synchronization Sequence Numbers), which is a handshake signal to establish the first MPTCP connection. In the first MPTCP connection, a data packet carries a first connection identifier, where the first connection identifier is used to indicate a type of a current connection, and specifically, the first connection identifier may be: MP _ able field to indicate that MPTCP connection is supported, when a Master connection is made.

Step 802, determining a first back-end service node from the plurality of back-end service nodes, establishing a first MPTCP connection between the first load balancing node and the first back-end service node, generating a Token corresponding to the first MPTCP connection, and storing the Token in the global flow table;

when the first MPTCP connection is established, the first load balancing node may directly determine a first back-end service node RS (real service) from all back-end service nodes, where the first back-end RS is used to establish a main connection with the first load balancing node.

Specifically, a load balancing algorithm may be used to determine the first backend RS from the multiple backend RSs. For example, the load balancing algorithm may be a hash algorithm, and the first backend RS is determined from the plurality of backend RSs by hashing randomly. In addition, the first back-end RS may be determined from the multiple back-end RSs by using other load balancing algorithms, for example, a polling method, a weighted random method, a minimum connection number method, and the like, which is not limited in this embodiment of the present invention.

After determining the first back-end service node, a first MPTCP connection of the first load balancing node with the first back-end service node may be established, i.e. a main connection is established. After establishing the first MPTCP connection, the first load balancing node may generate a Token corresponding to the first MPTCP connection and save the Token to the global flow table. In a specific implementation, each load balancing node has a corresponding global flow table, and when Token is saved, Token may be saved in the global flow tables corresponding to all load balancing nodes, so that each load balancing node may establish a sub-connection with the first backend service node by using the Token.

Step 803, receiving, by a second load balancing node, a data packet for a second MPTCP connection, where the data packet includes a second connection identifier and the Token, and the second connection identifier is an MP _ JOIN field.

In an embodiment of the present invention, the second MPTCP connection may be a Subflow sub-connection. In the second MPTCP connection, the data message contains a second connection identifier indicating the type of the current connection. Specifically, the second connection identifier may be an MP _ JOIN field, which is used to indicate that an MPTCP connection is supported, and a Subflow sub-connection is performed at this time.

When the second MPTCP connection is performed, the data packet may further include Token, where the Token is used to encrypt the data packet of the current MPTCP connection, so as to prevent other illegal connections from joining the MPTCP connection.

Step 804, determining a first back-end service node matched with the token from the global flow table, and establishing a second MPTCP connection between the second load balancing node and the first back-end service node.

Because the Token of the first MPTCP connection is maintained in the global flow table of the load balancing node, when the second MPTCP connection is performed, the Token in the data packet can be extracted, then the second backend service node matched with the Token is searched in the global flow table, and the second MPTCP connection between the second load balancing node and the first backend service node is established according to the Token.

It should be noted that the first back-end service node for establishing the first MPTCP connection is the same as the first back-end service node for establishing the second MPTCP connection, that is, the main connection is the same as the back-end service node of the sub-connection, so that the same back-end service node used for the same MPTCP connection can be ensured through the global flow table, and the quality of data transmission of the MPTCP connection is ensured.

In the embodiment of the present invention, by sinking the ECMP (Equal-cost-coded multi-routing) inconsistency problem transmitted from the switch node to the LB (load balance) node to the LB node for processing, different streams transmitted from the client may still be distributed to different LB nodes of the LB cluster. The reason for this is: the LB cluster does not have complete control authority over the switch nodes, and the switch nodes may be connected down more than the LB cluster, so that the distribution policy of the switch nodes is not easy to change. By maintaining the Token corresponding to the first MPTCP connection in the global flow table of the LB node, the global flow table enables the same Token to point to the same back-end RS, so that it can be ensured that the sub-connection of the MPTCP can be connected to the same back-end RS as the main connection after passing through the load balancing cluster, and the protocol stack of the back-end RS can normally handle the handshake of the sub-connection and the subsequent data transmission process.

In a preferred embodiment of the present invention, the step 802 may comprise the following sub-steps:

forwarding the data packet for the first MPTCP connection to the first back-end service node; receiving a response message which is returned by the first back-end service node after the data message is processed and contains a key value; calculating according to the key value to obtain a first token; and establishing the connection between the load balancing node and the first back-end service node according to the first token.

Specifically, the first load balancing node may forward the data packet for the first MPTCP connection to the first backend RS, after receiving the data packet for the first MPTCP connection, the first backend RS may process the data packet for the first MPTCP connection to generate a Key value Key, where the Key is used for verification when a Subflow sub-connection is subsequently added to the MPTCP connection, and the first backend RS may generate a response packet including the Key and transmit the response packet to the first load balancing node, where the response packet may be SYN + ACK, and the response packet may include the Key. A first field, MP _ able, may also be included in the reply message to indicate that the MPTCP protocol is supported.

After receiving the response message containing the Key, the first load balancing node may extract the Key in the response message, and establish a connection between the first load balancing node and the first backend service node according to the Key.

In a preferred embodiment of the present invention, the generating and saving Token corresponding to the first MPTCP connection to the global flow table may include:

calculating to obtain a Token corresponding to the first MPTCP connection according to the key value; storing the first back-end service node and the Token in the global flow table.

In this embodiment of the present invention, after the first load balancing node establishes the first MPTCP connection with the first back-end service node, the Token corresponding to the first MPTCP connection may be further obtained by calculation according to a key value, and the first back-end RS and the Token are stored in the global flow table. Specifically, an SHA-1 algorithm may be adopted to perform encryption calculation on the key value to obtain Token, and when data is stored, the first rear end RS and the Token may be stored in a key value pair manner to ensure a corresponding relationship between the first rear end RS and the Token, so that the matched first rear end RS may be found according to the Token when performing sub-connection, and it is ensured that the main connection is the same as the sub-connection rear end RS.

In a preferred embodiment of the present invention, the load balancing node has a plurality of network card queues, and after the step of receiving the data packet for the first MPTCP connection, the method may further include the following steps:

determining a target queue from the plurality of network card queues; and writing the data message into the target queue.

Load balancing on an LB node cluster is based on DPDK (Data Plane Development Kit) self-research, the DPDK is connected with a network card drive, when a user mode is started, a DPDK user mode interface is called to initialize a network card, a Memory is allocated to a network card queue, the network card queue is configured to a Ring Buffer circular Buffer area of the network card through the DPDK, and the network card queue is directly mapped to the user mode, so that the network card directly transmits a Data message to the user mode through DMA (Direct Memory Access) after receiving the Data message. The user mode processes each network card queue by using a single core and independently maintains a flow table, so that the multi-core advantage is fully played, and inter-core locking is avoided. The queues with the same sequence number in all LB nodes in the LB node cluster may form a multicast group, and data may be transmitted between the multicast groups in a multicast manner, that is, data of the flow table may be synchronized between the queues with the same sequence number in a multicast manner. For example, the queue flow table 0 of LB node a is a multicast group with the queue 0 of other LB nodes, and the queue 1 of LB node a is a multicast group with the queue 1 of other nodes.

In a specific implementation, to support MPTCP connection, data synchronization across queues is implemented, because different flows may be allocated to different queues, and therefore a separate global flow table is used for the flow table of MPTCP connection.

In this embodiment of the present invention, after receiving the data packet for the first MPTCP connection, the first load balancing node may determine the target queue from the network card queues. Specifically, the LB node may determine a target queue from the network card queues in a random manner, and write the data packet of the first MPTCP connection into the target queue.

In a preferred embodiment of the present invention, the storing the first back-end service node and the Token into the global flow table may include the following sub-steps:

multicasting a first back-end service node and Token to a plurality of queues with the same sequence number corresponding to the target queue in the plurality of load balancing nodes; and respectively storing the first back-end service node and the Token into a global flow table corresponding to the load balancing node where the queues are located.

Specifically, the first load balancing node may multicast the first backend RS and Token to a plurality of queues having the same sequence number as the target queue in the plurality of load balancing nodes in a multicast manner. For example, assuming that there are 10 load balancing nodes in the LB node cluster, the sequence numbers of the network card queues in the 10 load balancing nodes are all 0, 1.. 8, 9, and the sequence number of the target queue is 1, the first backend RS and Token may be multicast to multiple queues with sequence number 1 in the 10 load balancing nodes, so that the 10 load balancing nodes may all receive multicast data.

Further, the first back-end RS and the Token may be stored in the global flow table corresponding to the LB node where the plurality of queues are located, so that the first back-end RS and the Token are synchronized in the plurality of load balancing nodes.

As shown in fig. 9, after the data packet passes through a plurality of LB nodes, all LB nodes establish MPTCP connection with the backend RS 2. As an example, assume that an LB node in an LB node cluster includes a and B, where a Q1 queue of the a node receives a data packet, it is determined that a backend RS2 establishes a primary connection, and a Token corresponding to the primary connection is obtained by calculation according to a key value. The Token calculated by the node a is written into the global flow table corresponding to the node a, and multicast is performed through the multicast group in which the Q1 queue is located. At this time, the Q1 queue of the node B receives the flow information transmitted by the multicast of the node a, where the flow information includes the backend RS2 and Token, and then stores the flow information in the global flow table of the node B.

In a preferred embodiment of the present invention, the first load balancing node is the same as the second load balancing node, or the first load balancing node is different from the second load balancing node.

Specifically, when the Subflow sub-connection is performed, there are two cases as follows:

in the first case, the data packet for the second MPTCP connection is distributed to the LB node a by the switch node, after the node a detects that the second connection identifier is MP _ JOIN, the node a enters a Subflow processing flow of the MPTCP connection, at this time, the data packet carries Token information of the backend RS2, the node a searches its own global flow table, finds the flow information with the Token, determines the backend RS2 corresponding to the Token from the flow information, and directly forwards the data packet to the backend RS2, so as to establish a Subflow connection between the node a and the backend RS2, and no longer selects the backend RS through a load balancing algorithm.

In the second case, the data packet for the second MPTCP connection is allocated to another LB node B by the switch node, and after the connection identifier is detected to be MP _ JOIN, the global flow table of the switch node itself is queried, and since the flow information multicast by the node a is passed and stored in the global flow table corresponding to the node B, the flow information synchronized by the node a through multicast also exists in the node B, so that the back-end RS2 corresponding to the Token can be directly determined from the flow information, and the data packet is directly forwarded to the back-end RS2, so as to establish the connection between the node B and the back-end RS2, and no RS is selected through a load balancing algorithm.

In addition, the queue corresponding to the first MPTCP connection and the queue corresponding to the second MPTCP connection may be the same, or the queue corresponding to the first MPTCP connection and the queue corresponding to the second MPTCP connection may be different. Because the back-end service node and Token are maintained in the global flow table of the load balancing node, each queue in the load balancing node can acquire flow information from the global flow table when processing data, and therefore, the queues connected with the MPTCP each time can be different or the same.

In a preferred embodiment of the present invention, the backend service nodes corresponding to the same Token in the global flow table are the same.

In the embodiment of the present invention, the Token has uniqueness, and the back-end service nodes corresponding to the same Token in the global flow table are the same, so as to ensure that the sub-connection of the MPTCP can be connected to one back-end service node that is the same as the main connection after passing through the load balancing cluster, and thus, the protocol stack of the back-end service node can normally process the handshake of the sub-connection and the subsequent data transmission process.

In a preferred embodiment of the present invention, the determining the first back-end service node from the plurality of back-end service nodes includes:

When the first MPTCP connection is performed, the first load balancing node may determine the first backend service node from the multiple backend service nodes according to a load balancing algorithm, for example, the load balancing algorithm may be a hash algorithm, and determine the first backend RS from the multiple backend RSs in a hash random manner. In addition, the first back-end RS may be determined from the multiple back-end RSs by using other load balancing algorithms, for example, a polling method, a weighted random method, a minimum connection number method, and the like, which is not limited in this embodiment of the present invention.

It should be noted that, for simplicity of description, the method embodiments are described as a series of acts or combination of acts, but those skilled in the art will recognize that the present invention is not limited by the illustrated order of acts, as some steps may occur in other orders or concurrently in accordance with the embodiments of the present invention. Further, those skilled in the art will appreciate that the embodiments described in the specification are presently preferred and that no particular act is required to implement the invention.

Referring to fig. 10, a block diagram of an embodiment of an MPTCP connection establishment apparatus according to the present invention is shown, and is applied to a plurality of load balancing nodes, where the load balancing nodes are in communication connection with a plurality of backend service nodes, and the load balancing nodes configure a global flow table, where the apparatus specifically includes the following modules:

a first receiving module 1001, configured to receive, by using a first load balancing node, a data packet for a first MPTCP connection, where the data packet includes a first connection identifier, and the first connection identifier is an MP _ able field;

a first connection module 1002, configured to determine a first backend service node from the multiple backend service nodes, establish a first MPTCP connection between the first load balancing node and the first backend service node, generate a Token corresponding to the first MPTCP connection, and store the Token in the global flow table;

a second receiving module 1003, configured to receive, by using a second load balancing node, a data packet for a second MPTCP connection, where the data packet includes a second connection identifier and the Token, where the second connection identifier is an MP _ JOIN field;

a second connection module 1004, configured to determine, from the global flow table, a first backend service node matching the Token, and establish a second MPTCP connection between the second load balancing node and the first backend service node.

In a preferred embodiment of the present invention, the first connection module 1002 includes:

a packet forwarding sub-module, configured to forward the data packet for the first MPTCP connection to the first back-end service node;

the message receiving submodule is used for receiving a response message which is returned by the first back-end service node after the data message is processed and contains a key value;

and the first connection establishing submodule is used for establishing a first MPTCP connection between the load balancing node and the first back-end service node according to the key value.

the Token calculation sub-module is used for calculating a Token corresponding to the first MPTCP connection according to the key value;

and the Token storage submodule is used for storing the first back-end service node and the Token into the global flow table.

In a preferred embodiment of the present invention, the load balancing node has a plurality of network card queues, and the apparatus further includes:

the target queue determining submodule is used for determining a target queue from the network card queues;

a data message writing sub-module, configured to write the data message into the target queue;

the Token storage submodule comprises:

a Token multicast unit, configured to multicast a first backend service node and the Token to multiple queues, where the multiple queues have the same sequence number and correspond to the target queue, in the multiple load balancing nodes;

and the Token storage unit is used for respectively storing the first back-end service node and the Token into a global flow table corresponding to the load balancing node where the queues are located.

and the service node determining submodule is used for determining a first back-end service node from the plurality of back-end service nodes according to a load balancing algorithm.

For the device embodiment, since it is basically similar to the method embodiment, the description is simple, and for the relevant points, refer to the partial description of the method embodiment.

As shown in fig. 11, an embodiment of the present invention further provides an electronic device, including:

the device comprises a processor 1101, a storage medium 1102 and a bus 1103, wherein the storage medium 1102 stores machine-readable instructions executable by the processor 1101, when an electronic device runs, the processor 1101 communicates with the storage medium 1102 through the bus 1103, and the processor 1101 executes the machine-readable instructions to perform any one of the methods according to the embodiments of the present invention. The specific implementation manner and technical effects are similar to those of the method embodiment, and are not described herein again.

As shown in fig. 12, an embodiment of the present invention further provides a storage medium, where the storage medium stores a computer program 1201, and when the computer program 1201 is executed by a processor, the computer program performs the method according to any one of the embodiments of the present invention. The specific implementation manner and technical effects are similar to those of the method embodiment, and are not described herein again.

The embodiments in the present specification are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments are referred to each other.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, apparatus, or computer program product. Accordingly, embodiments of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

Embodiments of the present invention are described with reference to flowchart illustrations and/or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing terminal to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing terminal to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing terminal to cause a series of operational steps to be performed on the computer or other programmable terminal to produce a computer implemented process such that the instructions which execute on the computer or other programmable terminal provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

While preferred embodiments of the present invention have been described, additional variations and modifications of these embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all such alterations and modifications as fall within the scope of the embodiments of the invention.

Finally, it should also be noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or terminal that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or terminal. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or terminal that comprises the element.

The MPTCP connection establishment method and the MPTCP connection establishment apparatus provided by the present invention are described in detail above, and a specific example is applied in the text to explain the principle and the implementation of the present invention, and the description of the above embodiment is only used to help understanding the method and the core idea of the present invention; meanwhile, for a person skilled in the art, according to the idea of the present invention, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present invention.

Claims

1. An MPTCP connection establishment method applied to a plurality of load balancing nodes, wherein the plurality of load balancing nodes are in communication connection with a plurality of backend service nodes, and the plurality of load balancing nodes configure a global flow table, the method comprising:

2. The method of claim 1, wherein the establishing the first MPTCP connection of the first load balancing node with the first back-end service node comprises:

3. The method according to claim 2, wherein the generating and saving Token corresponding to the first MPTCP connection to the global flow table comprises:

storing the first back-end service node and the Token in the global flow table.

4. The method according to claim 3, wherein the load balancing node has a plurality of network card queues, and further comprising, after the step of receiving the data packet for the first MPTCP connection:

determining a target queue from the plurality of network card queues;

writing the data message into the target queue;

5. The method according to claim 1, wherein backend service nodes corresponding to the same Token in the global flow table are the same.

6. The method of claim 1, wherein determining the first back-end service node from the plurality of back-end service nodes comprises:

7. The method of claim 1, wherein the first load balancing node is the same as the second load balancing node, or wherein the first load balancing node is different from the second load balancing node.

8. An MPTCP connection setup apparatus applied to a plurality of load balancing nodes, the plurality of load balancing nodes being in communication connection with a plurality of backend service nodes, the plurality of load balancing nodes configuring a global flow table, the apparatus comprising:

9. An electronic device, comprising:

a processor, a storage medium and a bus, the storage medium storing machine-readable instructions executable by the processor, the processor and the storage medium communicating over the bus when the electronic device is operating, the processor executing the machine-readable instructions to perform the method of any one of claims 1-7.

10. A storage medium, having stored thereon a computer program which, when executed by a processor, performs the method according to any one of claims 1-7.