WO2022042370A1 - Mptcp负载均衡方法、介质及设备 - Google Patents

Mptcp负载均衡方法、介质及设备 Download PDF

Info

Publication number
WO2022042370A1
WO2022042370A1 PCT/CN2021/113001 CN2021113001W WO2022042370A1 WO 2022042370 A1 WO2022042370 A1 WO 2022042370A1 CN 2021113001 W CN2021113001 W CN 2021113001W WO 2022042370 A1 WO2022042370 A1 WO 2022042370A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
mptcp
load balancing
identifier
message
Prior art date
Application number
PCT/CN2021/113001
Other languages
English (en)
French (fr)
Inventor
吴新显
梁乾灯
康娇
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2022042370A1 publication Critical patent/WO2022042370A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/215—Flow control; Congestion control using token-bucket
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding

Definitions

  • One or more embodiments of the present application generally relate to the field of communication technologies, and specifically relate to a multipath transport control protocol (Multipath Transport Control Protocol, MPTCP) load balancing method, medium and device.
  • MPTCP Multipath Transport Control Protocol
  • Multihome the multi-address of the host (Multihome) has become more and more popular. From servers under the fat-tree network architecture in the data center to multi-connected smartphones with 5G/4G/Wifi/3G/Bluetooth/wired Ethernet/fiber networks, all are multi-homed.
  • IETF The Internet Engineering Task Force, International Internet Engineering Task Force
  • MPTCP Multipath Transport Control Protocol
  • TCP Transport Control Protocol
  • an MPTCP connection consists of multiple TCP connections.
  • the LB will dynamically create an MPTCP load balancing record based on the token (Token) of the MPTCP session (session) for recording.
  • the mapping between the token and the IP address of the server If different TCP connections of MPTCP are forwarded by different LBs, load balancing may not be achieved.
  • the token is associated with the MPTCP session and its lifetime is the same as that of MPTCP. In other words, when the MPTCP session ends, the token may also become invalid, and the corresponding MPTCP load balancing record will also become invalid.
  • the embodiments of the present application provide an MPTCP load balancing method for a load balancing device, including receiving a first request message from a user equipment (User Equipment, UE) for requesting to establish a first MPTCP connection;
  • the UE establishes the server of the first MPTCP connection and sends the first request message to the server; receives a first response message for the first request message from the server, the first response
  • the message includes the identifier of the server; receiving a second request message used by the UE to request the establishment of a second MPTCP connection, and in the case of determining that the second request message includes the identifier of the server, according to the
  • the identifier of the server searches the static forwarding rule table to determine the IP address of the server corresponding to the identifier of the server, and forwards the second request message to the server corresponding to the IP address, wherein the The static forwarding rule table is pre-configured in the load balancing device, and includes a mapping relationship between the identifier of
  • the first MPTCP connection and the second MPTCP connection belong to the same MPTCP session.
  • the identifier of the server includes a serial number of the server or a UUID (Universally Unique Identifier, UUID) or a Globally Unique Identifier (Globally Unique Identifier, GUID).
  • UUID Universally Unique Identifier
  • GUID Globally Unique Identifier
  • the identifier of the server is irrelevant to the MPTCP session.
  • the response message further includes at least one of a kind (Kind), a length (Length), and an MPTCP option subtype (Subtype).
  • embodiments of the present application provide an MPTCP load balancing method for user equipment, including sending a first request message for requesting to establish a first MPTCP connection, receiving a response from the server for the first request The first response message of the message, the first response message includes the identifier of the server, and sends a second request message requesting the establishment of a second MPTCP connection to the server, wherein, after determining that the first MPTCP connection and the When the second MPTCP connection belongs to the same MPTCP session, the second request information includes the identifier of the server.
  • the identifier of the server includes a serial number of the server or a UUID (Universally Unique Identifier, UUID) or a Globally Unique Identifier (Globally Unique Identifier, GUID).
  • UUID Universally Unique Identifier
  • GUID Globally Unique Identifier
  • the identifier of the server is irrelevant to the MPTCP session.
  • the first response message further includes at least one of a kind (Kind), a length (Length), and an MPTCP option subtype (Subtype).
  • Kind a kind
  • Length a length
  • Subtype an MPTCP option subtype
  • the second request information does not include the server's logo.
  • embodiments of the present application provide an MPTCP load balancing method for a server, including receiving a first request message for establishing a first MPTCP connection from a user equipment, sending a message for the first MPTCP connection The first response message of the first request message, where the first response message includes the identifier of the server, receives the confirmation message that the user equipment establishes the first MPTCP connection; receives the user equipment for establishing the second MPTCP connection a second request message for connection, and if it is determined that the identifier of the server is included in the second request message, establish the second MPTCP connection.
  • the first MPTCP connection and the second MPTCP connection belong to the same MPTCP session.
  • the identifier of the server includes a serial number of the server or a UUID (Universally Unique Identifier, UUID) or a Globally Unique Identifier (Globally Unique Identifier, GUID).
  • UUID Universally Unique Identifier
  • GUID Globally Unique Identifier
  • the identifier of the server is irrelevant to the MPTCP session.
  • the first response message and the second response message further include at least one of a kind (Kind), a length (Length), and an MPTCP option subtype (Subtype).
  • an embodiment of the present application provides a machine-readable medium, wherein an instruction is stored on the medium, and when the instruction is executed on the machine, the machine is caused to execute the first Aspects to the method described in the third aspect.
  • embodiments of the present application provide a device, including: a processor; and a memory, where instructions are stored in the memory, and when the instructions are executed by the processor, the user equipment is made to execute the first The methods described in one aspect to the third aspect.
  • the load balancing method according to the present application can establish MPTCP more effectively and reliably Multiple substreams of a session.
  • FIG. 1 is a schematic diagram of a scenario of a data transmission system applying a load balancing method according to an embodiment of the present application
  • FIG. 2 is a signal flow diagram of an MPTCP load balancing method according to some embodiments of the present application
  • FIG. 3 is a flowchart of an MPTCP load balancing method for a load balancing device according to some embodiments of the present application
  • FIG. 4 is a schematic diagram of an MPTCP option carrying server identification information according to an embodiment of the present application.
  • FIG. 5 is a flowchart of an MPTCP load balancing method for UE according to some embodiments of the present application
  • FIG. 6 is a flowchart of an MPTCP load balancing method for a server according to some embodiments of the present application.
  • first, second, etc. may be used herein to describe various elements or data, these elements or data should not be limited by these terms. These terms are used only to distinguish one feature from another. For example, a first feature could be termed a second feature, and, similarly, a second feature could be termed a first feature, without departing from the scope of example embodiments.
  • FIG. 1 is a schematic diagram of a scenario of a data transmission system to which a load balancing method according to an embodiment of the present application is applied.
  • the data transmission system may include a user equipment (User Equipment, UE) 100 , load balancing instances 201 and 202 , and a server resource pool 300 including a plurality of servers 301 , 302 and 303 .
  • UE User Equipment
  • the UE may be a laptop computer, desktop computer, tablet computer, cell phone, wearable device, head mounted display, server, mobile email device, portable game console, portable music player, reader device, embedded or coupled
  • a TV connected with one or more processors, or other electronic devices that can access the network, or a network device such as a CPE (Customer Premise Equipment) that supports MPTCP client or MPTCP proxy.
  • the load balancing instances 201 and 202 may be two instances of the load balancing service running on the same load balancing device, or may be instances of the load balancing service running on two different load balancing devices respectively.
  • Server resource pool 300 is a server cluster that may include multiple servers (eg, servers 301-303) managed by load balancing instances (eg, instances 201 and 202) that may provide data processing services for user equipment (eg, UE 100),
  • the plurality of servers 301 , 302 and 303 may be physical servers, virtual machines or containers, and so on.
  • FIG. 1 shows that the UE 100 establishes a connection with the server 302 , but those skilled in the art can understand that the connection with the UE 100 may be any server in the server resource pool 300 , such as 301 or 303 .
  • the UE 100 includes a controller 110, and the controller 110 may include, but is not limited to, a modem, a central processing unit (Central Processing Unit, CPU), an application processor (Application Processor, AP), a microprocessor (Micro-programmed Control Unit, MCU), artificial intelligence (Artificial Intelligence, AI) processor or programmable logic device (Field Programmable Gate Array, FPGA) and other processing circuits.
  • a modem a central processing unit
  • CPU Central Processing Unit
  • AP Application Processor
  • MCU Micro-programmed Control Unit
  • AI Artificial Intelligence
  • FPGA Field Programmable Gate Array
  • the modem is used to modulate the information (such as signal and/or data) in the baseband frequency domain to be transmitted into an analog signal that can be transmitted through the transceiver according to the 3GPP protocol, and demodulate the analog signal received by the transceiver information in the baseband frequency domain that the processor of the UE 100 can process.
  • the different processing units can be stand-alone devices or integrated in one or more processors.
  • the controller 110 may run an operating system, such as Android, iOS, Windows OS, Linux, and Harmony OS. In other possible implementations, the controller 110 may run a specific application program.
  • a memory may also be provided in the controller 110 for storing instructions and data.
  • the controller 110 may be configured to perform the load balancing method according to the following description.
  • the UE 100 also includes two transceivers 101 and 102 .
  • the transceiver is used to provide a wireless connection interface (such as a radio frequency front-end module, an antenna, etc.) for the UE 100 to communicate with any other suitable device through one or more networks.
  • a wireless connection interface such as a radio frequency front-end module, an antenna, etc.
  • the transceivers 101 and 102 may provide a network including wired local area networks, wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), bluetooth (BT) ), the 3rd-generation mobile communication technology (3G) network, the 4th generation mobile communication technology (4G) network, the 5th-generation mobile communication technology (5th-generation mobile communication technology)
  • WLAN wireless local area networks
  • BT bluetooth
  • 3G 3rd-generation mobile communication technology
  • 4G 4th generation mobile communication technology
  • 5th-generation mobile communication technology 5th-generation mobile communication technology
  • PLMN Public Land Mobile Network
  • the transceiver 101 and the transceiver 102 may communicate through different networks, and the transceivers 101 and 102 may have different IP addresses, for example, the transceiver 101 is a network interface for 4G wireless communication, The transceiver 102 is a network interface for WLAN wireless communication.
  • the UE 100 shown in FIG. 1 includes two transceivers is only for illustration, and the number of transceivers is not specifically limited, and may be three or more.
  • an MPTCP session is established between the servers 302 in the server resource pool 300 of the UE 100, and the MPTCP session implements data transmission on two subflows (Subflow, TCP connection) at the same time.
  • the load balancing instance 201 first establishes a TCP connection with the server 302 in the server resource pool 300, and then the transceiver 102 of the UE accesses the Internet through the wireless local area network.
  • Balanced instance 202 also establishes a TCP connection with server 302 .
  • the TCP connection between the transceiver 101 and the server 302 established first is the first TCP connection of the MPTCP session, which can also be generally referred to as the first subflow (Subflow) of the MPTCP session, and the transceiver 102 and the server 302 established later.
  • the TCP connection between them is the second TCP connection of the MPTCP session, which may also be referred to as an additional substream of the MPTCP session.
  • the two substreams belong to the same MPTCP session, so that the data sent by the UE can select any substream for transmission.
  • step 21 shown in FIG. 2 the establishment of the first sub-stream of the MPTCP session, that is, step 21 shown in FIG. 2 also needs to go through a three-way handshake (Three-way handshake) between the two communicating parties.
  • a three-way handshake Two-way handshake
  • all management information of MPTCP is transmitted through the TCP option field.
  • both parties in the communication need to carry a multi-path capability (MP-CAPABLE) option in the SYN, SYN/ACK message.
  • MP-CAPABLE multi-path capability
  • the UE 100 sends a request for establishing a first connection to the server through the transceiver 101 for transmitting the first substream of the MPTCP session, and the request message may be a SYN message.
  • the SYN packet carries the MP-CAPABLE option, and the MP-CAPABLE option is used to indicate that the UE 100 supports MPTCP connections.
  • the MP-CAPABLE option also includes the secret key (Key) of the UE100.
  • step 210 in FIG. 2 shows that the SYN packet is directly sent by the UE 100 to the server 302.
  • the above-mentioned SYN packet carrying the MP-CAPABLE option is sent via The load balancer corresponding to the load balancing instance forwards it.
  • the load balancer may perform a hash algorithm or other random allocation algorithm based on the five-tuple (the sender IP address, the sender port, the receiver IP address, the receiver port and the transport layer protocol) to extract the data from the server resource pool 300 from the server resource pool 300.
  • the server that establishes the above-mentioned first connection with the UE 100 is selected and the above-mentioned request to establish the first connection is forwarded to the selected server (eg, server 301).
  • the steps of other information transmission between the UE 100 and the server 302 shown in FIG. 2 are actually forwarded via the load balancer.
  • the load balancer where the load balancing instance 201 is located.
  • the server 302 After receiving the SYN message carrying the MP-CAPABLE option from the UE 100, the server 302 sends a response message.
  • the response message is a SYN/ACK message, that is, a handshake signal confirmation message.
  • the SYN/ACK message carries the MP-CAPABLE option, and the MP-CAPABLE option is used to indicate that the server 302 supports MPTCP connections.
  • the MP-CAPABLE option also includes the key (Key) of the server 302 .
  • the above-mentioned SYN/ACK message also carries the identification information of the server 302 (Server ID ) for additional substreams for establishing MPTCP sessions.
  • the identification information can be any server identification unrelated to a specific MPTCP session, such as a unique sequence number such as 1, 2, 3, etc., or a Universal Unique Identifier (UUID or Globally Unique Identifier). Unique Identifier, GUID), which is not specifically limited in the embodiments of this application.
  • the corresponding server resource pools are configured in different load balancing instances, and the same server is added (the server entry IP addresses can be different in different service balancing instances) , the configured server ID must be consistent and the same as the local server ID of the server; at the same time, in the server resource pool of the same load balancing instance, the server IDs of different servers cannot be the same.
  • the network operations manager can configure the load balancing instance through management protocols (eg Netconf, SNMP, RESTful APIs over HTTP) or a local web management or CLI command line.
  • management protocols eg Netconf, SNMP, RESTful APIs over HTTP
  • a local web management or CLI command line For example, in the LB server resource pool configuration, in addition to configuring the IP of each back-end server, it is also necessary to configure the corresponding ID of each server. The configured server ID must be consistent with the ID of the back-end server itself.
  • the load balancer where the load balancing instance is located generates a static forwarding rule table according to the configuration of the server resource pool, and selects the corresponding server according to the server ID carried in the captured service packet to process and route the packet accordingly.
  • the static forwarding rule table may be stored in the load balancing device of the load balancing instance 202, or may be stored in other servers or storages that communicate with the load balancing device, such as a cloud server.
  • the static forwarding rule table may further include a mapping relationship related to routing information on the communication link between the UE 100 and the server 302 .
  • the SYN/ACK packet carrying the identifier of the server 302 is forwarded to the transceiver 101 of the UE 100 via the load balancer where the load balancing instance 201 is located.
  • step 212 after receiving the SYN/ACK message from the server 302, the UE 100 parses the identification information of the server 302, caches the server identification, and then sends an acknowledgement message.
  • the confirmation message is an ACK message
  • the ACK message carries the MP-CAPABLE option and the server 302 identifier
  • the MP-CAPABLE option includes the above-mentioned Key of the UE 100 and the Key of the server 302 .
  • the above ACK packet is forwarded by the load balancer corresponding to the load balancing instance.
  • the load balancer detects that the ACK packet is a packet that needs to be load balanced (for example, the protocol type is TCP, and the port is port 80 corresponding to the HTTP protocol).
  • the packet is parsed and found to carry the identifier of the server 302 , and then the forwarding rule table is queried according to the identifier of the server 302 , the IP of the server 302 is queried for routing and forwarding, and the ACK packet is forwarded to the server 302 . So far, the establishment of the first sub-stream of the MPTCP session is completed through the three-way handshake process between the transceiver 101 of the UE 100 and the server 302 , and the establishment of the MPTCP session is also completed.
  • the UE 100 associates the server 302 identifier with the MPCTP session, for example, writes it into the session parameter information of the MPCTP session.
  • the data transmission of the MPTCP session can be performed between the transceiver 101 of the UE 100 and the server 302 .
  • the data transmission process is a normal TCP data transmission process.
  • the server 302 identifier will be carried.
  • the forwarding process on the load balancer where the above-mentioned load balancing instance is located is the same as the forwarding process of the above-mentioned ACK message . It is not shown in FIG. 2 and will not be described again here.
  • step 22 between the transceiver 102 of the UE 100 and the server 302, an additional sub-flow of the MPTCP session will be established.
  • the information transfer between the UE 100 and the server 302 in step 21 of establishing the additional sub-flow of the MPTCP session shown in FIG. 2 is completed by the load balancing instance 202 .
  • the traditional load balancing technology will perform a five-tuple hash algorithm or other random allocation according to the token of the MPTCP session. Algorithm forwarding. Since the transceivers 101 and 102 of the UE 100 have different IP addresses, the message transmission of the transceiver 102 will be routed to other servers different from the server 302, resulting in the result that load balancing cannot be achieved.
  • the additional subflow link establishment packets (SYN and ACK packets) of the above MPTCP session will carry the server 302 identifier, the forwarding process on the load balancer where the above load balancing instance is located and the above first subflow
  • the forwarding process of the ACK message is the same. This ensures that additional subflows are successfully established between the transceiver 102 of the UE 100 and the server 302 .
  • the process will be described in detail with reference to FIG. 2 .
  • the transceiver 101 of the UE 100 after receiving the identification information of the server 302, the transceiver 101 of the UE 100 stores the mapping relationship between the identification information of the server 302 and the current MPTCP session in the memory of the UE 100.
  • the controller 110 will look up the above-mentioned mapping table between the identification information and the MPTCP session, so as to find the identification information of the server 302 and put it in the additional sub-stream for establishing the MPTCP session. stream request. It should be noted that although only one controller 110 is used to control the transceiver 101 and the transceiver 102 in FIG. 1 and FIG.
  • the transceiver 101 and the transceiver 102 may also be controlled by different controllers.
  • the mapping relationship between the identification information of the server 302 and the current MPTCP session should be shared, for example, the UE can locally cache the corresponding relationship between the MPTCP session and the server identification information, It is used when other substreams of the MPTCP session are established and the TCP data packets are normally sent when the MPTCP session is carried out.
  • the identification information of the server 302 is used.
  • the establishment of the additional substream of the MPTCP session adopts a four-way handshake, which is very similar to the above-mentioned three-way handshake.
  • the transceiver 102 sends a request message for establishing a second connection of the MPTCP session, that is, establishing an additional substream of the MPTCP session, and the request message may also be a SYN message.
  • the SYN message carries the MP-JOIN option, and the MP-JOIN option includes the token of the server 302 , which is used to indicate that the additional substream and the first substream of the MPTCP session belong to the same MPTCP session.
  • the SYN message must also carry the identification information of the server 302 .
  • the load balancing instance 202 parses the SYN message to obtain the identification information of the server 302, and determines the forwarding object of the SYN message by retrieving the static forwarding rule table.
  • the static forwarding rule table includes the mapping relationship between the identification information of the server 302 and the IP (Internet Protocol, Internet Protocol) address of the server 302.
  • the load balancing instances 201 and 202 may be the same instance, or two instances in the same load balancing device, or two instances respectively located in different load balancing devices.
  • the above-mentioned one load balancing device can be an independent load balancing device, or it can be a group of active and standby load balancing devices. When the main load balancing device fails, the backup load balancing device is used to achieve load balancing. The configuration remains the same.
  • the above-mentioned static forwarding rule table should be shared or configured in the same way.
  • the load balancing instance 202 forwards the SYN packet to the server corresponding to the IP address.
  • the load balancing instance 202 forwards the SYN packet to the server corresponding to the IP address 192.0.0.2, that is, the server 302 .
  • the IP address of the server described here may be a public network address or a private network address, which is not limited in this application.
  • the static forwarding rule table also includes other mapping relationships related to routing information, the load balancing instance can forward based on the NAT (Network Address Translation) technology to ensure that the SYN message arrives and establishes MPTCP.
  • the load balancer For example, if the load balancer supports NAT locally, it will configure a load balancer instance, configure the public network IP (for example, public network IP1) and the type of service to be load balanced (protocol type and port, such as HTTP, corresponding to port 43).
  • the private network server of the server resource pool provides NAT processing.
  • the process for a terminal (assuming its IP is public network IP2) to access the MPTCP server whose IP address is private network IP1 via the load balancer whose IP address is public network IP1 is as follows:
  • the quintuple information carried in the corresponding TCP packet (which can be a TCP Sync packet or a TCP data packet) is as follows:
  • Source IP public network IP2
  • destination IP public network IP1
  • source port Port2 (a free port randomly assigned locally); destination port: 43; protocol type: TCP
  • the load balancer When the load balancer receives the TCP (destination port 43) message from the terminal accessing the MPTCP server, it queries whether the TCP message carries the server identifier. Hash) to select a server in the MPTCP server resource pool; if the TCP packet carries a server identifier, directly query the static forwarding rule table according to the server identifier carried by the TCP packet to obtain the IP address of the corresponding MPTCP server. It is assumed here that the MPTCP server 1 corresponding to the private network IP1 is selected.
  • the load balancer modifies the TCP header and IP header of the packet, re-encapsulates the packet and forwards it to MPTCP server 1.
  • the modified quintuple information of the TCP packet is as follows:
  • Source IP Public IP1
  • Destination IP Private IP1
  • Source Port Port2
  • Destination Port 43
  • Protocol Type TCP.
  • MPTCP server 1 After receiving the NAT-translated TCP message, MPTCP server 1 finds that it is a local message for processing, and replies to a message (such as a TCP Ack/Syn-ack message), which carries the following quintuple information:
  • Source IP Private IP1
  • Destination IP Public IP2
  • Source Port 43
  • Destination Port Port2
  • Protocol Type TCP
  • the load balancer receives the TCP packet replied by MPTCP server 1, queries the NAT mapping table according to the source IP, knows that the new source IP is the public network IP1, modifies the TCP header and IP header of the packet, re-encapsulates the packet and forwards it to the terminal.
  • the modified quintuple information of the TCP packet is as follows:
  • Source IP Public IP1
  • Destination IP Public IP2
  • Source Port 43
  • Destination Port Port2
  • Protocol Type TCP.
  • the second connection established by the transceiver 102 and the first connection established by the transceiver 101 belong to the same MPTCP session.
  • the controller 110 of the UE 100 needs to determine whether it belongs to the same MPTCP session as the first sub-stream of MPTCP established by the transceiver 101.
  • the request message for establishing the second connection in step 213 will carry the relevant field options and the identification information of the server 302; if it does not belong to the same MPTCP session, the relevant field options and the identification information of the server 302 will not be carried.
  • the balancer After receiving the request message for establishing the connection, the balancer will establish the connection according to the three-way handshake, that is, the method described in the above steps 210-212, which will not be repeated here.
  • the server 302 sends a response message to the received SYN message, and the response message may be a SYN/ACK message.
  • the SYN/ACK message may carry the MP-JOIN option including the authentication information of the server 302 .
  • step 217 for the SYN/ACK response message sent by the server, the transceiver 102 sends an acknowledgment message for establishing an additional substream of the MPTCP session, and the acknowledgment message is an ACK message.
  • the ACK message should carry the MP-JOIN option including the authentication information of the UE100.
  • step 218 for the ACK message from the transceiver 102, the server 302 also sends an acknowledgment message for establishing an additional substream of the MPTCP session, which is also an ACK message, for the ACK message sent by the transceiver in step 217 message for confirmation.
  • steps 216, 217 and 218, the SYN/ACK or ACK packets sent between the transceiver 102 and the server 302 are all forwarded through the load balancing instance 202, which is not shown in FIG. This will not be repeated here.
  • the establishment of the additional substream of the MPTCP session is realized by means of the four-way handshake.
  • data transmission can also be performed between the transceiver 102 of the UE 100 and the server 302 .
  • the data transmission process is a normal TCP data transmission process, which is not shown in FIG. 2 and will not be repeated here.
  • the load balancing method according to an embodiment of the present application described above according to FIG. 2 , multiple subflows of the MPTCP session are established based on the static forwarding rule table of the mapping relationship between the server identification information and the IP address. Since the identification information of the server has nothing to do with the MPTCP session, it remains unchanged during the life cycle of providing the service. Therefore, compared with the load balancing in the prior art, the load balancing method according to the present application can establish MPTCP more effectively and reliably Multiple substreams of a session.
  • a request message used by the UE for establishing a first connection of an MPTCP session is received.
  • the first connection of the MPTCP session described here is the first substream of the MPTCP session.
  • the request message is usually a SYN message.
  • the SYN packet carries the MP-CAPABLE option, and the MP-CAPABLE option is used to indicate that the user equipment supports MPTCP connections.
  • the MP-CAPABLE option also includes the Key of the user equipment.
  • step 302 according to the request message for establishing the first connection of the MPTCP session by the UE, the load balancer will select the server for establishing the first connection with the UE.
  • the request message of the first connection is forwarded by the load balancing instance.
  • the instance of load balancing may be forwarded based on a quintuple hash algorithm or other random allocation algorithm, which is not specifically limited in this application.
  • the server sends a response message after receiving the SYN message carrying the MP-CAPABLE option from the UE and forwarded by the load balancing.
  • the load balancer receives the response message from the server and forwards it to the UE.
  • the response message of the server mentioned here is a SYN/ACK message, that is, a handshake signal confirmation message.
  • the SYN/ACK message carries the MP-CAPABLE option, which is used to indicate that the server supports MPTCP connections.
  • the MP-CAPABLE option also contains the server's key (Key).
  • the above-mentioned SYN/ACK message also carries the identification information (Server ID) of the server for establishing an additional substream of the MPTCP session.
  • the identification information may be any identification of the server unrelated to the MPTCP session, such as Universal Unique Identifier (UUID), or may be a unique sequence number such as 1, 2, 3, etc., or a globally unique identifier ( Globally Unique Identifier, GUID).
  • UUID Universal Unique Identifier
  • GUID globally unique identifier
  • the load balancer receives the acknowledgment message from the UE and forwards it to the responding server.
  • the confirmation message is an ACK message.
  • the ACK message needs to carry the MP-CAPABLE option, and the MP-CAPABLE option includes the above-mentioned UE key and server key.
  • steps 301 to 304 correspond to steps 210 to 212 shown in FIG. 2 above.
  • the UE and the server complete the establishment of the first substream of the MPCTP session through a three-way handshake process.
  • data transmission can be performed between the UE and the server.
  • the data transmission process is a normal TCP data transmission process, which will not be repeated here.
  • the UE sends a request message for establishing a second connection of the MPTCP session, that is, establishing an additional substream of the MPTCP session, and the request message may also be a SYN message.
  • the SYN packet carries the MP-JOIN option, and the MP-JOIN option includes the server's token, which is used to indicate that the additional substream and the first substream of the MPTCP session belong to the same MPTCP session.
  • the SYN message must also carry the identification information of the server.
  • the UE can locally cache the corresponding relationship between the MPTCP session and the server identification information, so that it can be used for subsequent establishment of other sub-streams of the MPTCP session and when the TCP data packet is normally sent in the MPTCP session and carries the server identification.
  • the second connection for establishing the MPTCP session is initiated by another transceiver than the transceiver for establishing the first subflow of the MPTCP session.
  • the first sub-stream of the MPTCP session is established by the transceiver 101 of the UE 100
  • the additional sub-streams of the MPTCP session are established by the transceiver 102 of the UE 100 .
  • step 306 after the load balancer receives the SYN message described in step 305, it needs to parse the SYN message.
  • the above SYN packet also carries the identification information of the server 302.
  • step 307 is executed, and the load balancer determines the forwarding object of the SYN message by retrieving the static forwarding rule table.
  • the static forwarding rule table includes the mapping relationship between the identification information of the server and the IP (Internet Protocol, Internet Protocol) address of the server.
  • the static forwarding rule table may be stored in the load balancing device of the load balancing instance, or may be stored in other servers or storages that communicate with the load balancing device, such as a cloud server.
  • the static forwarding rule table may be manually configured or automatically configured according to a control protocol.
  • a control protocol For example, in the LB server resource pool configuration, in addition to configuring the IP of each back-end server, it is also necessary to configure the corresponding ID of each server. The configured server ID must be consistent with the ID of the back-end server itself.
  • the LB server can retrieve the static forwarding rule table of the load balancing of the private network IP of the server according to the server ID.
  • the static forwarding rule table may further include a mapping relationship related to routing information on the communication link.
  • the first connection and the second connection of the MPTCP session are forwarded by the load balancing instances 201 and 202 respectively, and the load balancing instances 201 and 202 may be the same instance or the same load
  • the two instances in the balancing device can also be located in two different load balancing devices.
  • the above-mentioned one load balancing device can be an independent load balancing device, or it can be a group of active and standby load balancing devices. When the main load balancing device fails, the backup load balancing device is used to achieve load balancing. The configuration remains the same.
  • the above-mentioned static forwarding rule table should be shared or configured in the same way.
  • step 308 according to the IP address corresponding to the server identification information found in the static forwarding rule table, the load balancing instance forwards the SYN packet to the server corresponding to the IP address.
  • the load balancing instance 202 forwards the SYN packet to the server corresponding to the IP address 192.0.0.2 , namely the server 302 .
  • the IP address of the server described here may be a public network address or a private network address, which is not limited in this application.
  • the static forwarding rule table also includes other mapping relationships related to routing information, the load balancing instance can forward based on the NAT (Network Address Translation) technology to ensure that the SYN message arrives and establishes MPTCP.
  • the server 302 sends a response message to the received SYN message, and the corresponding message may be a SYN/ACK message.
  • the SYN/ACK message may carry the MP-JOIN option including the authentication information of the server 302 .
  • the SYN/ACK message is received by the load balancer and forwarded to the UE.
  • step 310 for the SYN/ACK response message sent by the server, the transceiver 102 sends an acknowledgment message for establishing an additional substream of the MPTCP session, the acknowledgment message being an ACK message.
  • the ACK message should carry the MP-JOIN option including the authentication information of the UE100.
  • the ACK message is received by the load balancer and forwarded to the server 302 .
  • step 311 for the ACK message from the transceiver 102, the server 302 also sends an acknowledgment message for establishing an additional substream of the MPTCP session, and the acknowledgment message is also an ACK message, which is used for the ACK sent by the transceiver in step 310. message for confirmation.
  • the load balancer receives the ACK message and forwards it to the UE 100 .
  • the establishment of the additional substream of the MPTCP session is realized by means of the four-way handshake.
  • data transmission can also be performed between the transceiver 102 of the UE 100 and the server 302 .
  • the data transmission process is a normal TCP data transmission process, which will not be repeated here.
  • step 306 after the load balancer receives the SYN message described in step 305, it needs to parse the SYN message. If the load balancer does not obtain the identification information of the server by parsing the SYN message, that is, if the judgment result of step 306 is no, it means that the request message for the second connection sent from the transceiver 102 does not include the information of the server 302. The identification information also means that the second connection requested by the transceiver 102 to be established does not belong to the same MPTCP session as the first connection of the MPTCP session established by the transceiver 101 . At this point, the load balancer turns to step 312.
  • the load balancer will consider it as the establishment request of the first sub-stream belonging to another MPTCP session, and then follow steps 210-212 shown in Figure 2, or steps 301-304 shown in Figure 3
  • the processing is performed, that is, the five-tuple hash algorithm or other random allocation algorithm forwarding is performed according to the token of the session, which is not repeated here.
  • FIG. 4 is a schematic diagram of an MPTCP option carrying server identification information according to an embodiment of the present application.
  • the MPTCP options include Kind (Kind), Length (Length), and Subtype (Subtype) fields.
  • the kind field indicates that the header option is an MPTCP header option, and the value is 30. This value is assigned by IANA (The Internet Assigned Numbers Authority, Internet Assigned Numbers Authority).
  • the Length field indicates the length of this header option.
  • Subtype indicates the subtype of the MPTCP option, which is generally four bytes.
  • the RFC8684 standard of IESG Internet Engineering Steering Group, Internet Engineering Steering Group
  • 0x0 indicates MP-CAPABLE
  • the Subtype is defined as the MP-LB-ADVERT option, which indicates that the identification information of the server is carried.
  • the value of Subtype can be any one of 0x9-0xe not specified in the existing standard.
  • the identification information of the server is located in the last 8 bytes of the MPTCP option, but those skilled in the art can understand that the identification information of the server can be set to other lengths such as 4 bytes as required, if In the case of using the server UUID, the IP option needs to be expanded separately, which is not specifically limited in this embodiment of the present application.
  • the UE sends a request message for establishing the first connection of the MPTCP session to the server.
  • the UE 100 sends a request message for establishing the first connection of the MPTCP session, that is, the first substream of the MPTCP session, to the server through the transceiver 101 , and the request message may be a SYN message.
  • the SYN packet carries the MP-CAPABLE option, and the MP-CAPABLE option is used to indicate that the UE 100 supports MPTCP connections.
  • the MP-CAPABLE option also includes the secret key (Key) of the UE100.
  • the UE receives a response message from the server.
  • the server 302 sends a response message.
  • the response message is a SYN/ACK message, that is, a handshake signal confirmation message.
  • the SYN/ACK message carries the MP-CAPABLE option, and the MP-CAPABLE option is used to indicate that the server 302 supports MPTCP connections.
  • the MP-CAPABLE option also includes the key (Key) of the server 302 .
  • the above SYN/ACK message also carries the identification information of the server 302 (Server ID ) for additional substreams for establishing MPTCP sessions.
  • the identification information may be any identification of the server unrelated to the MPTCP session, such as Universal Unique Identifier (UUID), or may be a unique sequence number such as 1, 2, 3, etc., or a globally unique identifier ( Globally Unique Identifier, GUID).
  • UUID Universal Unique Identifier
  • GUID globally unique identifier
  • step 503 after receiving the SYN/ACK message from the server 302, the UE 100 sends an acknowledgement message.
  • the confirmation message is an ACK message.
  • the ACK message needs to carry the MP-CAPABLE option, and the MP-CAPABLE option includes the above-mentioned Key of the UE 100 and the Key of the server 302 . So far, the establishment of the first substream of the MPCTP session is completed through the three-way handshake process between the transceiver 101 of the UE 100 and the server 302 .
  • data transmission can be performed between the transceiver 101 of the UE 100 and the server 302 .
  • the data transmission process is a normal TCP data transmission process, which will not be repeated here.
  • step 504 the controller 110 of the UE 100 generates a request message for establishing a second connection.
  • This second connection may be the first connection established in the above steps, that is, the first substream of the MPTCP session belongs to the same MPTCP session, or may be a different session.
  • step 505 the UE 100 needs to make a judgment on the generated second connection request message, and perform different processing according to the judgment result.
  • step 505 When the determination in step 505 is yes, it means that the transceiver 102 will establish an additional substream of the same MPTCP session.
  • the controller 110 of the UE 100 will process to add the identification information of the server 302 obtained in the above step 502 to the request message for establishing the second connection of the MPTCP session, that is, the step 506 in FIG. 5 .
  • the request message may also be a SYN message.
  • the SYN message carries the MP-JOIN option, and the MP-JOIN option includes the token of the server 302 , which is used to indicate that the additional substream and the first substream of the MPTCP session belong to the same MPTCP session.
  • the SYN message must also carry the identification information of the server 302 .
  • the load balancing instance 202 parses the SYN message to obtain the identification information of the server 302, and determines the forwarding object of the SYN message by retrieving the static forwarding rule table.
  • the static forwarding rule table includes the mapping relationship between the identification information of the server 302 and the IP (Internet Protocol, Internet Protocol) address of the server 302. For details, reference may be made to the related description in FIG. 2 , which will not be repeated here.
  • the UE 100 receives the response message sent by the server 302.
  • the response message may be a SYN/ACK message.
  • the SYN/ACK message may carry the MP-JOIN option including the authentication information of the server 302 .
  • step 508 for the SYN/ACK response message sent by the server, the transceiver 102 of the UE 100 sends an acknowledgement message for establishing an additional substream of the MPTCP session, and the acknowledgement message is an ACK message.
  • the ACK message should carry the MP-JOIN option including the authentication information of the UE100.
  • step 509 for the ACK message from the transceiver 102, the server 302 also sends an acknowledgment message for establishing an additional subflow of the MPTCP session, and this acknowledgment message is received by the UE.
  • the confirmation message is also an ACK message, which is used to confirm the ACK message sent by the transceiver in step 217 .
  • the establishment of the additional substream of the MPTCP session is realized by means of the four-way handshake.
  • data transmission can also be performed between the transceiver 102 of the UE 100 and the server 302 .
  • the data transmission process is a normal TCP data transmission process, which will not be repeated here.
  • the second connection initiated by the transceiver 102 of the UE 100 may be the first connection established in the above step, that is, the first sub-flow of the MPTCP session belongs to a different session.
  • the identification information of the server 302 in the connection establishment request message it is not necessary to carry the identification information of the server 302 in the connection establishment request message. Therefore, if the judgment in step 505 is negative, step 510 is executed, that is, a request message for establishing a second connection is sent. At this time, the request message for establishing a second connection does not include the server obtained in the above step 502 identification information.
  • the load balancer After the load balancer receives the request message that does not contain the server identification information, the load balancer will determine that it is the establishment request of the first substream belonging to another MPTCP session, and then execute the five-tuple hash algorithm or other methods according to the token of the current session.
  • the random allocation algorithm forwarding specifically, reference may be made to steps 210-212 in FIG. 2 or steps 301-304 in FIG. 3 for establishing the first substream of the MPTCP session, which will not be repeated here.
  • FIG. 6 is a flowchart of an MPTCP load balancing method for a server according to an embodiment of the present application.
  • step 601 via the load balancing instance 201, the server 302 in the server resource pool 300 receives a request message for establishing the first connection of the MPTCP session by the transceiver 101 of the UE 100.
  • the request message may be a SYN message.
  • the SYN packet carries the MP-CAPABLE option, and the MP-CAPABLE option is used to indicate that the UE 100 supports MPTCP connections.
  • the MP-CAPABLE option also includes the secret key (Key) of the UE100.
  • Step 601 corresponds to the above-mentioned steps 210, 301 and 501, and details are not repeated here.
  • the server 302 responds to the request message for establishing the first connection of the MPTCP session in step 601.
  • the response message is a SYN/ACK message, that is, a handshake signal confirmation message.
  • the SYN/ACK message carries the MP-CAPABLE option, and the MP-CAPABLE option is used to indicate that the server 302 supports MPTCP connections.
  • the MP-CAPABLE option also includes the key (Key) of the server 302 .
  • the above-mentioned SYN/ACK message also carries the identification information of the server 302 (Server ID ) for additional substreams for establishing MPTCP sessions.
  • the identification information may be, for example, a Universal Unique Identifier (UUID), or a unique sequence number such as 1, 2, 3, etc., or a Globally Unique Identifier (GUID).
  • UUID Universal Unique Identifier
  • GUID Globally Unique Identifier
  • step 603 the load balancer receives the confirmation message from the UE and forwards it to the corresponding server 302 .
  • the confirmation message is an ACK message.
  • the ACK message needs to carry the MP-CAPABLE option, and the MP-CAPABLE option includes the above-mentioned UE key and server key.
  • Step 603 corresponds to the above-mentioned steps 212, 304 and 503, and details are not repeated here.
  • steps 601-603 the establishment of the first sub-stream of the MPCTP session is completed through the three-way handshake process between the UE and the server.
  • data transmission can be performed between the transceiver 101 of the UE 100 and the server 302 .
  • the data transmission process is a normal TCP data transmission process, which will not be repeated here.
  • the server receives a request message for establishing a second connection from the UE.
  • the controller 110 of the UE 100 generates a request message for establishing the second connection.
  • This second connection may be the first connection established in the above steps 601-603, that is, the first substream of the MPTCP session belongs to the same MPTCP session, or may be a different session. The difference is that if the second connection and the first connection belong to the same MPTCP session, the request message for establishing the second connection will carry the identification information of the server 302 sent in step 602; if it does not belong to the same MPTCP session, then the second connection is established The request message does not carry the identification information of the server 302 .
  • the load balancing instance will perform different processing for different request messages for establishing the second connection. If it is a request message carrying the identification information of the server 302 , it will be forwarded to the server 302 accordingly. If the identification information of the server 302 is not carried, the request message for establishing the second connection will be forwarded through the load balancing instance through a conventional method such as a five-tuple hash algorithm or other random allocation algorithm. Therefore, in step 605, the server will perform different processing on whether the request message for the second connection carries the server identifier.
  • the server 302 receives the second connection request message that is forwarded by the load balancing instance 202 and carries the identification information of the server 302, and sends a response message to the request message.
  • the response message may be a SYN/ACK message.
  • the SYN/ACK message may carry the MP-JOIN option including the authentication information of the server 302 .
  • step 607 for the SYN/ACK response message sent by the server in step 606, the transceiver 102 of the UE 100 sends an acknowledgement message for establishing an additional substream of the MPTCP session, and the acknowledgement message is an ACK message.
  • the ACK message should carry the MP-JOIN option including the authentication information of the UE100.
  • step 608 for the ACK message from the transceiver 102, the server 302 also sends an acknowledgment message for establishing an additional substream of the MPTCP session, which is received by the UE.
  • the confirmation message is also an ACK message, which is used to confirm the ACK message sent by the transceiver in step 607 .
  • the establishment of the additional substream of the MPTCP session is realized by means of the four-way handshake.
  • data transmission can also be performed between the transceiver 102 of the UE 100 and the server 302 .
  • the data transmission process is a normal TCP data transmission process, which will not be repeated here.
  • the request message for establishing the second connection sent by the transceiver 102 of the UE 100 does not include the identification information of the server 302
  • the request message for the second connection may be forwarded to the server resource pool by the load balancing instance 202 Any one of the servers in 300, such as server 301 or 303.
  • the server 301 or 303 will send a response carrying its identification information.
  • This process is similar to MPTCP and the first sub-stream of establishing an MPTCP session. For details, refer to the above-mentioned steps 211, 303 or 502, which will not be repeated here.
  • the load balancing method according to an embodiment of the present application is described above according to FIG. 2 to FIG. 6 , and multiple sub-flows of the MPTCP session are established based on the static forwarding rule table of the mapping relationship between the identification information of the server and the IP address. Since the identification information of the server has nothing to do with the MPTCP session and remains unchanged during the service life cycle, compared with the load balancing in the prior art, the load balancing method according to the present application can establish the MPTCP session more effectively and reliably of multiple substreams.
  • Program code may be applied to input instructions to perform the functions described herein and to generate output information.
  • the output information can be applied to one or more output devices in a known manner.
  • a processing system includes any system having a processor such as, for example, a digital signal processor (DSP), microcontroller, application specific integrated circuit (ASIC), or microprocessor.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • the program code may be implemented in a high-level procedural language or an object-oriented programming language to communicate with the processing system.
  • the program code may also be implemented in assembly or machine language, if desired.
  • the mechanisms described herein are not limited to the scope of any particular programming language. In either case, the language may be a compiled language or an interpreted language.
  • IP cores may be stored on tangible computer-readable storage media and provided to multiple customers or production facilities for loading into the manufacturing machines that actually manufacture the logic or processors.
  • module or “unit” may refer to, be or include: an application specific integrated circuit (ASIC), an electronic circuit, a (shared, dedicated or group) process executing one or more software or firmware programs and/or memory, combinational logic circuits, and/or other suitable components that provide the described functionality.
  • ASIC application specific integrated circuit
  • electronic circuit a (shared, dedicated or group) process executing one or more software or firmware programs and/or memory, combinational logic circuits, and/or other suitable components that provide the described functionality.
  • ASIC application specific integrated circuit
  • process executing one or more software or firmware programs and/or memory, combinational logic circuits, and/or other suitable components that provide the described functionality.
  • Embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of these implementation methods.
  • Embodiments of the present application may be implemented as a computer program or program code executing on a programmable system including multiple processors, a memory system (including volatile and non-volatile memory and/or storage elements) , multiple input devices, and multiple output devices.
  • Program code may be applied to input instructions to perform the functions described herein and to generate output information.
  • the output information can be applied to one or more output devices in a known manner.
  • a processing system includes any system having a processor such as, for example, a digital signal processor (DSP), microcontroller, application specific integrated circuit (ASIC), or microprocessor.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • the program code may be implemented in a high-level procedural language or an object-oriented programming language to communicate with the processing system.
  • the program code may also be implemented in assembly or machine language, if desired.
  • the mechanisms described in this application are not limited in scope to any particular programming language. In either case, the language may be a compiled language or an interpreted language.
  • the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof.
  • one or more aspects of at least some embodiments may be implemented by representative instructions stored on a computer-readable storage medium, the instructions representing various logic in a processor, which when read by a machine cause The machine fabricates logic for performing the techniques described in this application.
  • IP cores may be stored on tangible computer-readable storage media and provided to multiple customers or production facilities for loading into the manufacturing machines that actually manufacture the logic or processors.
  • Such computer readable storage media may include, but are not limited to, non-transitory tangible arrangements of items manufactured or formed by machines or equipment, including storage media such as hard disks Any other type of disk including floppy disks, optical disks, compact disks Disk Read Only Memory (CD-ROM), Compact Disk Rewritable (CD-RW), and Magneto-Optical Optical Disks; Semiconductor Devices such as Read Only Memory (ROM), such as Dynamic Random Access Memory (DRAM) and Static Random Access Random Access Memory (RAM) such as memory (SRAM), Erasable Programmable Read Only Memory (EPROM), Flash Memory, Electrically Erasable Programmable Read Only Memory (EEPROM); Phase Change Memory (PCM); Magnetic Cards or optical card; or any other type of medium suitable for storing electronic instructions.
  • ROM Read Only Memory
  • DRAM Dynamic Random Access Memory
  • RAM Static Random Access Random Access Memory
  • SRAM Static Random Access Random Access Memory
  • EPROM Erasable Programmable Read Only Memory
  • Flash Memory Electrically Era
  • embodiments of the present application also include non-transitory computer-readable storage media containing instructions or containing design data, such as a hardware description language (HDL), which defines the structures, circuits, devices, Processor and/or System Characteristics.
  • HDL hardware description language

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请实施例涉及一种多路径传输控制协议(Multipath Transport Control Protocol，MPTCP)负载均衡方法，包括接收用户设备用于请求建立MPTCP连接的请求消息，和在确定请求消息包括服务器的标识的情况下，根据服务器的标识查找静态转发规则表，以确定与服务器的标识相对应的服务器的IP地址，并且将请求消息转发至IP地址对应的服务器，其中，静态转发规则表预先配置在负载均衡设备中，并且包括服务器的标识与服务器的IP地址的映射关系。本申请的实施例还涉及一种机器可读介质及设备。

Description

MPTCP负载均衡方法、介质及设备
本申请要求于2020年8月28日提交中国专利局，申请号为202010884208.X，发明名称“MPTCP负载均衡方法、介质及设备”的中国专利申请优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请的一个或多个实施例通常涉及通信技术领域，具体涉及一种多路径传输控制协议(Multipath Transport Control Protocol，MPTCP)负载均衡方法、介质及设备。
背景技术
随着IPv6到来，主机的多地址(Multihome)变得越来越普及。从数据中心胖树(Fat-tree)网络架构下的服务器到具有5G/4G/Wifi/3G/蓝牙(Bluetooth)/有线以太/光纤网络的多连接的智能手机，都是多宿主机。为了充分利用设备的多连接特性，IETF(The Internet Engineering Task Force，国际互联网工程任务组)制定了多路径传输控制协议(Multipath Transport Control Protocol，MPTCP)，允许传输控制协议(Transport Control Protocol，TCP)连接使用多个路径来最大化信道资源使用，从而可以提高端到端的吞吐率，增加网络利用率。
在MPTCP场景下，一个MPTCP连接是由多个TCP连接组成的。按照传统的负载均衡(Load Balance，LB)机制，为确保同一MPTCP会话的不同TCP连接路由到同一服务器，LB会根据MPTCP会话(session)的令牌(Token)动态创建MPTCP负载均衡记录用于记录令牌与服务器的IP地址之间的映射关系。如果MPTCP的不同TCP连接由不同LB转发，可能无法实现负载均衡。此外，令牌与MPTCP会话相关，其生命周期与MPTCP的生命周期相同。换句话说，当MPTCP会话结束，那么令牌也可能失效，与之对应的MPTCP负载均衡记录也就随之失效了。
发明内容
以下从多个方面介绍本申请，以下多个方面的实施方式和有益效果可互相参考。
第一方面，本申请的实施例提供了一种MPTCP负载均衡方法，用于负载均衡设备，包括接收用户设备(User Equipment，UE)用于请求建立第一MPTCP连接的第一请求消息；选择与所述UE建立所述第一MPTCP连接的服务器并将所述第一请求消息发送到所述服务器；接收来自所述服务器的针对所述第一请求消息的第一响应消息，所述第一响应消息包括所述服务器的标识；接收所述UE用于请求建立第二MPTCP连接的第二请求消息，和在确定所述第二请求消息包括所述服务器的所述标识的情况下，根据所述服务器的标识查找静态转发规则表，以确定与所述服务器的标识相对应的所述服务器的IP地址，并且将所述第二请求消息转发至所述IP地址对应的所述服务器， 其中，所述静态转发规则表预先配置在所述负载均衡设备中，并且包括所述服务器的标识与所述服务器的IP地址的映射关系。
在上述第一方面的一种可能实现中，所述第一MPTCP连接与所述第二MPTCP连接属于同一个MPTCP会话。
在上述第一方面的一种可能实现中，所述服务器的标识包括所述服务器的编号或者UUID(Universally Unique Identifier，UUID)或者全局唯一标识符(Globally Unique Identifier，GUID)。
在上述第一方面的一种可能实现中，所述服务器的所述标识与所述MPTCP会话无关。
在上述第一方面的一种可能实现中，所述响应消息还包括种类(Kind)、长度(Length)、MPTCP选项子类型(Subtype)中的至少一个。
第二方面，本申请的实施例提供了一种MPTCP负载均衡方法，用于用户设备，包括发送用于请求建立第一MPTCP连接的第一请求消息，接收来自所述服务器针对所述第一请求消息的第一响应消息，所述第一响应消息包括所述服务器的标识，向所述服务器发送请求建立第二MPTCP连接的第二请求消息，其中，在确定所述第一MPTCP连接与所述第二MPTCP连接属于同一MPTCP会话的情况下，所述第二请求信息包括所述服务器的所述标识。
在上述第二方面的一种可能实现中，所述服务器的标识包括所述服务器的编号或者UUID(Universally Unique Identifier，UUID)或者全局唯一标识符(Globally Unique Identifier，GUID)。
在上述第二方面的一种可能实现中，所述服务器的所述标识与所述MPTCP会话无关。
在上述第二方面的一种可能实现中，所述第一响应消息还包括种类(Kind)、长度(Length)、MPTCP选项子类型(Subtype)中的至少一个。
在上述第二方面的一种可能实现中，在确定所述第一MPTCP连接与所述第二MPTCP连接不属于同一MPTCP会话的情况下，所述第二请求信息不包括所述服务器的所述标识。
第三方面，本申请的实施例提供了一种MPTCP负载均衡方法，用于服务器，包括接收来自用户设备的用于建立第一MPTCP连接的第一请求消息，发送对于所述第一MPTCP连接的第一请求消息的第一响应消息，所述第一响应消息包括所述服务器的标识，接收所述用户设备建立所述第一MPTCP连接的确认消息；接收所述用户设备用于建立第二MPTCP连接的第二请求消息，以及在确定所述第二请求消息中包括所述服务器的标识的情况下，建立所述第二MPTCP连接。
在上述第三方面的一种可能实现中，所述第一MPTCP连接与所述第二MPTCP连接属于同一MPTCP会话。
在上述第三方面的一种可能实现中，所述服务器的标识包括所述服务器的编号或者UUID(Universally Unique Identifier，UUID)或者全局唯一标识符(Globally Unique Identifier，GUID)。
在上述第三方面的一种可能实现中，所述服务器的所述标识与所述MPTCP会话无关。
在上述第三方面的一种可能实现中，所述第一响应消息和所述第二响应消息还包括种类(Kind)、长度(Length)、MPTCP选项子类型(Subtype)中的至少一个。
第四方面，本申请的实施例提供了一种机器可读介质，其特征在于，在所述介质上存储有指令，当所述指令在所述机器上运行时，使得所述机器执行第一方面到第三方面所述的方法。
第五方面，本申请的实施例提供了一种设备，包括：处理器；存储器，在所述存储器上存储有指令，当所述指令被所述处理器运行时，使得所述用户设备执行第一方面到第三方面所述的方法。
根据本申请的技术方案，基于服务器的标识信息和IP地址之间映射关系的静态转发规则表建立MPTCP会话的多个子流。由于服务器的标识信息与MPTCP会话无关，其在提供服务的生命周期内保持不变，因此相对于现有技术的负载均衡来说，根据本申请的负载均衡的方法能够更有效并可靠的建立MPTCP会话的多个子流。
附图说明
图1是应用根据本申请实施例的负载均衡方法的数据传输系统的场景示意图；
图2是根据本申请一些实施例的MPTCP负载均衡方法的信号流图；
图3是根据本申请一些实施例的用于负载均衡设备的MPTCP负载均衡方法的流程图；
图4是根据本申请一个实施例的携带服务器标识信息的MPTCP选项的示意图；
图5是根据本申请一些实施例的用于UE的MPTCP负载均衡方法的流程图；
图6是根据本申请一些实施例的用于服务器的MPTCP负载均衡方法的流程图。
具体实施方式
下面结合具体实施例和附图对本申请做进一步说明。
应当理解的是，虽然在这里可能使用了术语“第一”、“第二”等等来描述各个单元或是数据，但是这些单元或数据不应当受这些术语限制。使用这些术语仅仅是为了将一个特征与另一个特征进行区分。举例来说，在不背离示例性实施例的范围的情况下，第一特征可以被称为第二特征，并且类似地第二特征可以被称为第一特征。
应注意的是，在本说明书中，相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。
为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请的实施方式作进一步地详细描述。
图1是应用根据本申请实施例的负载均衡方法的数据传输系统的场景示意图。如图1所示，数据传输系统可以包括用户设备(User Equipment，UE)100、负载均衡实例201和202，以及包括多个服务器301、302、303的服务器资源池300。其中UE可以是 膝上型计算机、台式计算机、平板计算机、手机、可穿戴设备、头戴式显示器、服务器、移动电子邮件设备、便携式游戏机、便携式音乐播放器、阅读器设备、其中嵌入或耦接有一个或多个处理器的电视机、或能够访问网络的其他电子设备，也可以是支持MPTCP client或MPTCP proxy的CPE(Customer Premise Equipment，客户驻点设备)等网络设备。负载均衡实例201和202可以是同一台负载均衡设备中运行的负载均衡服务的两个实例，也可以是分别在不同的两台负载均衡设备中运行的负载均衡服务的实例。服务器资源池300是可以包括由负载均衡实例(例如，实例201和202)管理的可以为用户设备(例如，UE100)提供数据处理服务的多个服务器(例如，服务器301-303)的服务器集群，其中的多个服务器301、302、303可以是物理服务器、虚拟机或容器等等。图1中示出的是UE100与服务器302建立连接，但是本领域技术人员可以理解，与UE100建立连接的可以是服务器资源池300中的任一台服务器，例如301或者303。
进一步的，UE100包括控制器110，控制器110可以包括，但不限于，调制解调器、中央处理器(Central Processing Unit，CPU)、应用处理器(Application Processor，AP)、微处理器(Micro-programmed Control Unit，MCU)、人工智能(Artificial Intelligence，AI)处理器或可编程逻辑器件(Field Programmable Gate Array，FPGA)等的处理电路。其中，调制解调器用于根据3GPP的协议，将处于需要发射的基带频域的信息(例如信号和/或数据)调制成可以通过收发器传输的模拟信号，和将收发器接收到的模拟信号解调成UE100的处理器能够处理的基带频域的信息。不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。在一种可能的实施方式中，控制器110可以运行操作系统，例如，Android、iOS、Windows OS、Linux和鸿蒙操作系统等。在另一些可能的实施方式中，控制器110可以运行特定的应用程序。控制器110中还可设置存储器，用于存储指令和数据。在本申请的实施例中，控制器110可以被配置为执行根据下文所述的负载均衡方法。
UE100还包括两个收发器101和102。收发器用于为UE100提供无线连接接口(如射频前端模块，天线等)，进而通过一个或多个网络与任意其他合适的设备进行通信。本领域技术人员可以理解，收发器101和102可以是提供包括有线局域网、无线局域网(wireless local area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)、蓝牙(bluetooth，BT)、第三代移动通信技术(3rd-generation mobile communication technology，3G)网络、第四代移动通信技术(the 4th generation mobile communication technology，4G)网络、第五代移动通信技术(5th-generation mobile communication technology，5G)网络、和/或未来演进的公共陆地移动网络(Public Land Mobile Network，PLMN)的数据连接服务等无线通信的网络接口。在本申请的实施例中，收发器101和收发器102可以通过不同的网络进行通信，并且收发器101和102可以分别具有不同的IP地址，例如收发器101为进行4G无线通信的网络接口，收发器102为进行WLAN无线通信的网络接口。另外，本领域技术人员可以理解，图1所示的UE100包括两个收发器仅为举例说明，收发器的数量不具体限定，还可以是三个或更多。
如图1所示，UE100服务器资源池300中的服务器302之间建立了MPTCP会话，该MPTCP会话实现了同时在两条子流(Subflow，TCP连接)上的数据传输。假设其中 UE100的收发器101通过4G核心网接入因特网，经由负载均衡实例201首先建立与服务器资源池300中的服务器302的TCP连接，之后UE的收发器102通过无线局域网接入因特网，经由负载均衡实例202也与服务器302建立TCP连接。进一步的，先建立的收发器101与服务器302之间的TCP连接为MPTCP会话的第一TCP连接，一般也可称为MPTCP会话的首个子流(Subflow)，后建立的收发器102与服务器302之间的TCP连接为MPTCP会话的第二TCP连接，也可以称为MPTCP会话的附加子流。如上所述，这两条子流同属于一个MPTCP会话，从而UE发送的数据能够选择任一子流进行传输。
接下来，将参考图2对根据本申请一个实施例的MPTCP负载均衡方法进行说明。
与普通TCP连接一样，MPTCP会话的首个子流的建立，即图2中所示的步骤21也需要经过通信双方的三次握手(Three-way handshake)。为了兼容TCP，MPTCP的所有管理信息都通过TCP选项字段来传输。在首个子流建立的过程中，通信双方需要在SYN，SYN/ACK报文中携带多路径能力(MP-CAPABLE)选项。
如图2所示，首先在步骤210，UE100通过收发器101向服务器发送建立第一连接的请求，用于传输MPTCP会话的首个子流，该请求消息可以是SYN报文。其中SYN报文中携带有MP-CAPABLE选项，MP-CAPABLE选项用于表示UE100支持MPTCP连接。通常，MP-CAPABLE选项中还包含UE100的秘钥(Key)。
需要说明的是，图2中的步骤210示出的是SYN报文直接由UE100发送到服务器302，实际上，在包括负载均衡的场景下，上述携带有MP-CAPABLE选项的SYN报文是经由负载均衡实例对应的负载均衡器进行转发。其中，负载均衡器可以基于五元组(发送端IP地址，发送端端口，接收端IP地址，接收端端口和传输层协议)进行哈希算法或其他的随机分配算法来从服务器资源池300中选择与UE100建立上述第一连接的服务器并将上述建立第一连接的请求转发到所选的服务器(例如，服务器301)。同样，图2中所示的UE100与服务器302之间的其他信息传送的步骤实际上都是经由负载均衡器转发。这里，假设图2所示的建立MPTCP会话的首个子流的步骤21中UE100与服务器302之间的信息传送是由负载均衡实例201所在负载均衡器完成。
接下来，在步骤211，服务器302在接收到来自UE100的携带有MP-CAPABLE选项的SYN报文后，会发出响应消息。该响应消息是SYN/ACK报文，即握手信号确认消息。同样，SYN/ACK报文中携带有MP-CAPABLE选项，MP-CAPABLE选项用于表示服务器302支持MPTCP连接。通常，MP-CAPABLE选项中还包含服务器302的秘钥(Key)。
为了解决现有技术中同一MPTCP由不同LB转发的情况下可能存在无法实现负载均衡的问题，根据本申请的负载均衡方法，上述SYN/ACK报文中还携带有服务器302的标识信息(Server ID)以用于建立MPTCP会话的附加子流。该标识信息可以是与具体MPTCP会话无关的任意的服务器标识，例如1、2、3……等唯一的顺序编号，也可以是通用唯一识别码(Universally Unique Identifier，UUID或全局唯一标识符(Globally Unique Identifier，GUID)，本申请的实施例对此不作具体限定。在不同的负载均衡实例中配置对应的服务器资源池，加入同一个服务器(在不同的服务均衡实例中服务器入口IP地址可以不同)，则配置的服务器标识需要保持一致，并和服务器本地的服务器 标识要相同；同时在同一个负载均衡实例的服务器资源池中，不同服务器的服务器标识不能相同。
下面是本方案中负载均衡实例中配置的服务器资源池成员列表的一个示例：
Figure PCTCN2021113001-appb-000001
在一个实例中，网络运营管理人员可以通过管理协议(例如Netconf、SNMP、RESTful APIs over HTTP)或本地的Web网管或CLI命令行进行配置该负载均衡实例。例如在LB服务器资源池配置中除了配置每个后端服务器的IP，还要配置每个服务器对应的标识，配置的服务器标识要和后端服务器自身的标识要确保一致。该负载均衡实例所在负载均衡器根据服务器资源池的配置生成静态转发规则表，根据捕获到业务报文中携带的服务器ID选择对应的服务器进行该报文的相应处理和路由转发。
在一个实例中，静态转发规则表可以存储在负载均衡实例202的负载均衡设备中，也可以存储在与负载均衡设备进行通信的其他服务器或存储器中，例如云端服务器。
在一个实例中，静态转发规则表还可以包括UE100与服务器302之间的通信链路上与路由信息相关的映射关系。
同样，携带有服务器302标识的SYN/ACK报文经由负载均衡实例201所在负载均衡器转发至UE100的收发器101。
在步骤212，UE100在接收到来自服务器302的SYN/ACK报文后，解析到服务器302的标识信息，缓存该服务器标识，然后发出确认消息。该确认消息是ACK报文，ACK报文携带MP-CAPABLE选项和服务器302标识，并且MP-CAPABLE选项中包含上述UE100的Key和服务器302的Key。上述ACK报文是经由负载均衡实例对应的负载均衡器进行转发，负载均衡器检测到该ACK报文是需要做负载均衡的报文(例如协议类型是TCP，端口是HTTP协议对应的80端口)，解析发现报文中携带服务器302标识，然后根据服务器302标识查询转发规则表，查询到服务器302的IP进行路由转发，将ACK报文转发到服务器302。至此，UE100的收发器101与服务器302之间通过三次握手的过程完成了MPTCP会话的首个子流的建立，该MPTCP会话也建链完成。
需要说明的是，该MPTCP会话建链完成后，UE100将服务器302标识和该MPCTP会话关联，例如写入该MPCTP会话的会话参数信息中。
该MPCTP的首个子流成功建立之后，UE100的收发器101与服务器302之间可以进行该MPTCP会话的数据传输。该数据传输的过程是正常的TCP数据传输过程，所述TCP数据在UE100上发出时会携带服务器302标识，在上述负载均衡实例所在负载均衡器上的转发流程和上述ACK报文的转发流程相同。图2中并没有示出，在此也不 再赘述。
为提高端到端的吞吐率，增加网络利用率，接下来的步骤22中，在UE100的收发器102和服务器302之间，将建立MPTCP会话的附加子流。这里，假设图2所示的建立MPTCP会话的附加子流的步骤21中UE100与服务器302之间的信息传送是由负载均衡实例202完成。
如果UE100与服务器302之间建立MPTCP会话的附加子流的信息传送是由负载均衡实例202完成，传统的负载均衡技术会根据MPTCP会话的令牌，执行五元组哈希算法或其他的随机分配算法转发。由于UE100的收发器101和102具有不同的IP地址，因此会导致收发器102的消息传送被路由到不同于服务器302的其他服务器上，造成负载均衡无法实现的结果。
根据本申请的负载均衡方法，上述MPTCP会话的附加子流建链报文(SYN、ACK报文)都会携带服务器302标识，在上述负载均衡实例所在负载均衡器上的转发流程和上述首个子流的ACK报文的转发流程相同。这样就确保在UE100的收发器102和服务器302之间成功的建立附加子流。接下来将参考图2对该过程进行详细的说明。
根据本申请的一个实例，UE100的收发器101在收到服务器302的标识信息之后，会将服务器302的标识信息与当前的MPTCP会话的映射关系存放在UE100的存储器中。当UE100需要产生针对当前的MPTCP会话建立附加子流的时候，控制器110会查找上述的标识信息与MPTCP会话的映射表，从而发现服务器302的标识信息并将其放在建立MPTCP会话的附加子流的请求中。需要说明的是，虽然在图1和图2中只显示了通过一个控制器110控制收发器101和收发器102，但是收发器101和收发器102也可以由不同的控制器进行控制。本领域技术人员可以理解，对于两个不同的控制器来说，服务器302的标识信息与当前的MPTCP会话的映射关系应该是共享的，例如UE可以本地缓存MPTCP会话和服务器标识信息的对应关系，以便后续建立MPTCP会话其他子流和正常进行MPTCP会话发送TCP数据报文时生成携带服务器标识时使用。
在收发器102发起MPTCP会话的附加子流的建立过程中，会使用到服务器302的标识信息。MPTCP会话的附加子流的建立采用四次握手的方式，这与上述的三次握手方式非常类似。
首先，在步骤213，收发器102发送建立MPTCP会话的第二连接，即建立MPTCP会话的附加子流的请求消息，该请求消息同样可以是SYN报文。其中SYN报文中携带有MP-JOIN选项，MP-JOIN选项中包含服务器302的令牌，用于表示该附加子流与上述的MPTCP会话的首个子流属于同一个MPTCP会话。根据本申请的一个实施例，SYN报文中还必须携带有服务器302的标识信息。
在步骤214，负载均衡实例202接收到SYN报文之后，解析SYN报文得到服务器302的标识信息，通过检索静态转发规则表确定该SYN报文的转发对象。其中，所述的静态转发规则表包括服务器302的标识信息与服务器302的IP(Internet Protocol，网际互联协议)地址之间的映射关系。
如上所述，负载均衡实例201和202可以是同一个实例，或者是同一负载均衡设备中的两个实例，也可以分别位于不同的负载均衡设备中的两个实例。上述的一个负载 均衡设备可以是一个独立的负载均衡设备，也可以是一组主备负载均衡设备，当主负载均衡设备故障时，由备用的负载均衡设备来实现负载均衡，主备负载均衡设备间配置维持一致。本领域技术人员可以理解，对于两个不同的负载均衡实例来说，上述的静态转发规则表应该是共享的或者配置一致的。
如图2中步骤215所示，根据静态转发规则表中查找到的服务器标识信息所对应的IP地址，负载均衡实例202将SYN报文转发至该IP地址对应的服务器。
假设根据静态转发规则表查找到服务器302的标识信息对应的IP地址是192.0.0.2，则负载均衡实例202将SYN报文转发至与IP地址192.0.0.2对应的服务器，即服务器302。
需要说明的是，这里所述的服务器的IP地址可以是公网地址或者私网地址，本申请不对此做限定。并且，如果静态转发规则表中还包括上述的与路由信息相关的其他映射关系时，负载均衡实例可以基于NAT(Network Address Translation，网络地址转换)技术进行转发，以确保SYN报文到达建立了MPTCP的首个子流的相应的服务器。
举例来说，负载均衡器本地支持NAT，会配置负载均衡实例，配置公网IP(例如，公网IP1)和要负载均衡的服务类型(协议类型和端口，例如HTTP，对应端口43)，对服务器资源池的私网服务器提供NAT处理。
终端(假设其IP为公网IP2)经由IP地址为公网IP1的负载均衡器访问IP地址为私网IP1的MPTCP服务器的过程如下：
终端访问MPTCP服务器，对应的TCP报文(可以是TCP Sync报文或TCP数据报文)携带的五元组信息如下：
源IP：公网IP2；目的IP：公网IP1；源端口：Port2(本地随机分配的空闲端口)；目的端口：43；协议类型：TCP
当负载均衡器收到终端访问MPTCP服务器的TCP(目的端口为43)报文后，查询TCP报文是否携带服务器标识，如果没有携带服务器的标识，则根据现有散列方案(例如五元组哈希)选择MPTCP服务器资源池中的一个服务器；如果TCP报文有携带服务器标识，则直接根据其携带的服务器标识查询静态转发规则表获取对应的MPTCP服务器的IP地址。这里假设选择的是对应私网IP1的MPTCP服务器1。负载均衡器修改报文TCP头和IP头，重新封装后路由转发给MPTCP服务器1。修改后的TCP报文五元组信息如下：
源IP：公网IP1；目的IP：私网IP1；源端口：Port2；目的端口：43；协议类型：TCP。
MPTCP服务器1收到NAT转换后的TCP报文后，发现是本地报文进行处理，回复报文(例如TCP Ack/Syn-ack报文)，携带的五元组信息如下：
源IP：私网IP1；目的IP：公网IP2；源端口：43；目的端口：Port2；协议类型：TCP
负载均衡器收到MPTCP服务器1回复的TCP报文，根据源IP查询NAT映射表，知道新的源IP为公网IP1，修改报文TCP头和IP头，重新封装后路由转发给终端。
修改后的TCP报文五元组信息如下：
源IP：公网IP1；目的IP：公网IP2；源端口：43；目的端口：Port2；协议类型： TCP。
如上所述，收发器102建立的第二连接与收发器101建立的第一连接属于同一MPTCP会话。本领域技术人员可以理解，在收发器102建立第二连接时，UE100的控制器110需要判断其是否和收发器101建立的MPTCP的首个子流属于同一MPTCP会话，如果属于同一MPTCP会话，则在步骤213中建立第二连接的请求消息中会携带相关的字段选项以及服务器302的标识信息；如果不属于同一MPTCP会话，则不会携带相关的字段选项以及服务器302的标识信息，此时，负载均衡在接收到建立连接的请求消息后，会按照三次握手的方式建立连接，即如上述步骤210-212所述的方式，在此不再赘述。
接下来，在步骤216，服务器302对于收到的SYN报文发出响应消息，该响应消息可以是SYN/ACK报文。该SYN/ACK报文中可以携带包含服务器302的鉴权信息的MP-JOIN选项。
在步骤217，对于服务器发出的SYN/ACK响应消息，收发器102发出建立MPTCP会话的附加子流的确认消息，该确认消息是ACK报文。同样，ACK报文要携带包含UE100的鉴权信息的MP-JOIN选项。
最后，在步骤218，对于来自收发器102的ACK报文，服务器302也发出建立MPTCP会话的附加子流的确认消息，该确认消息也是ACK报文，用于对步骤217中收发器发送的ACK报文进行确认。
这里需要说明的是，在步骤216、217和218中，收发器102和服务器302之间发送的SYN/ACK或者ACK报文都是经由负载均衡实例202进行转发，图2中未示出，在此也不再赘述。
以上，通过四次握手的方式，实现了MPTCP会话的附加子流的建立。同样，MPCTP的附加子流成功建立之后，UE100的收发器102与服务器302之间也可以进行数据传输。该数据传输的过程是正常的TCP数据传输过程，图2中并没有示出，在此也不再赘述。
通过上述根据图2说明的根据本申请一个实施例的负载均衡的方法，基于服务器的标识信息和IP地址之间映射关系的静态转发规则表建立MPTCP会话的多个子流。由于服务器的标识信息与MPTCP会话无关，其在提供服务的生命周期内保持不变，因此相对于现有技术的负载均衡来说，根据本申请的负载均衡的方法能够更有效并可靠的建立MPTCP会话的多个子流。
接下来，参考图3对根据本申请一个实施例的用于负载均衡设备的MPTCP负载均衡方法的流程进行说明。
在步骤301，接收UE用于建立MPTCP会话的第一连接的请求消息。这里所述的MPTCP会话的第一连接，也就是MPTCP会话的首个子流。该请求消息通常是SYN报文。其中SYN报文中携带有MP-CAPABLE选项，MP-CAPABLE选项用于表示用户设备支持MPTCP连接。通常，MP-CAPABLE选项中还包含用户设备的Key。
在步骤302，根据UE用于建立MPTCP会话的第一连接的请求消息，负载均衡会选择与UE建立第一连接的服务器。
第一连接的请求消息由负载均衡的实例进行转发。其中，负载均衡的实例可以基 于五元组进行哈希算法或其他的随机分配算法转发，本申请不对此做具体的限定。
接下来，服务器在接收到负载均衡转发的，来自UE的携带有MP-CAPABLE选项的SYN报文后，发出响应消息。在步骤303，负载均衡会接收服务器的响应消息并转发给UE。
这里所说的服务器的响应消息是SYN/ACK报文，即握手信号确认消息。同样，SYN/ACK报文中携带有MP-CAPABLE选项，MP-CAPABLE选项用于表示服务器支持MPTCP连接。通常，MP-CAPABLE选项中还包含服务器的秘钥(Key)。UE在接收到来自服务器的SYN/ACK报文后，会发出确认消息。
根据本申请的负载均衡方法，上述SYN/ACK报文中还携带有服务器的标识信息(Server ID)以用于建立MPTCP会话的附加子流。该标识信息可以是与MPTCP会话无关的服务器的任意标识，例如通用唯一识别码(Universally Unique Identifier，UUID)，也可以是例如1、2、3……等唯一的顺序编号或者全局唯一标识符(Globally Unique Identifier，GUID)。
在步骤304，负载均衡接收来自UE的确认消息并转发给响应的服务器。该确认消息是ACK报文，通常，ACK报文需要携带MP-CAPABLE选项，并且MP-CAPABLE选项中包含上述UE的Key和服务器的Key。
这里，步骤301-304与上述图2中所示的步骤210-212对应，经由负载均衡，UE与服务器之间通过三次握手的过程完成了MPCTP会话的首个子流的建立。
需要说明的是，MPCTP会话的首个子流成功建立之后，UE与服务器之间可以进行数据传输。该数据传输的过程是正常的TCP数据传输过程，在此也不再赘述。
当UE和服务器之间成功建立了MPTCP会话的首个子流之后，UE和服务器之间会发起MPTCP会话的附加子流的建立过程。
在步骤305，UE发送建立MPTCP会话的第二连接，即建立MPTCP会话的附加子流的请求消息，该请求消息同样可以是SYN报文。其中SYN报文中携带有MP-JOIN选项，MP-JOIN选项中包含服务器的令牌，用于表示该附加子流与上述的MPTCP会话的首个子流属于同一个MPTCP会话。根据本申请的一个实施例，SYN报文中还必须携带有服务器的标识信息。如上所述，UE可以本地缓存MPTCP会话和服务器标识信息的对应关系，以便后续建立MPTCP会话其他子流和正常进行MPTCP会话发送TCP数据报文时生成携带服务器标识时使用。
与上述图2中的步骤213相对应，建立MPTCP会话的第二连接是由不同于建立MPTCP会话的首个子流的收发器的另一个收发器所发起的。在本申请的实施例中，MPTCP会话的首个子流是由UE100的收发器101发起建立，而MPTCP会话的附加子流是由UE100的收发器102发起建立的。
接下来，在步骤306，负载均衡接收到步骤305中所述的SYN报文之后，需要解析SYN报文。如上所述，为了确保同一MPTCP会话的附加子流在UE100的收发器102和服务器302之间成功的建立，上述SYN报文中还携带有服务器302的标识信息。
负载均衡通过解析SYN报文得到服务器的标识信息的情况下，即步骤306的判断结果为是的情况下，执行步骤307，负载均衡要通过检索静态转发规则表确定该SYN 报文的转发对象。其中，所述的静态转发规则表包括服务器的标识信息与服务器的IP(Internet Protocol，网际互联协议)地址之间的映射关系。
在一个实例中，静态转发规则表可以存储在负载均衡实例的负载均衡设备中，也可以存储在与负载均衡设备进行通信的其他服务器或存储器中，例如云端服务器。
在一个实例中，静态转发规则表可以由人工进行配置或者根据控制协议自动配置。例如在LB服务器资源池配置中除了配置每个后端服务器的IP，还要配置每个服务器对应的标识，配置的服务器标识要和后端服务器自身的标识要确保一致。LB服务器可以根据服务器标识检索服务器私网IP的负载均衡的静态转发规则表。
在一个实例中，静态转发规则表还可以包括通信链路上与路由信息相关的映射关系。
如上所述，在本申请的一个实施例中，MPTCP会话的第一连接和第二连接由负载均衡实例201和202分别转发，负载均衡实例201和202可以是同一个实例，或者是同一台负载均衡设备中的两个实例，也可以分别位于不同的两台负载均衡设备中。上述的一个负载均衡设备可以是一个独立的负载均衡设备，也可以是一组主备负载均衡设备，当主负载均衡设备故障时，由备用的负载均衡设备来实现负载均衡，主备负载均衡设备间配置维持一致。本领域技术人员可以理解，对于两个不同的负载均衡实例来说，上述的静态转发规则表应该是共享的或者配置一致的。
与图2中步骤215一样，在步骤308，根据静态转发规则表中查找到的服务器标识信息所对应的IP地址，负载均衡实例将SYN报文转发至该IP地址对应的服务器。
在根据本申请的实例中，假设根据静态转发规则表查找到服务器302的标识信息对应的IP地址是192.0.0.2，则负载均衡实例202将SYN报文转发至与IP地址192.0.0.2对应的服务器，即服务器302。
需要说明的是，这里所述的服务器的IP地址可以是公网地址或者私网地址，本申请不对此做限定。并且，如果静态转发规则表中还包括上述的与路由信息相关的其他映射关系时，负载均衡实例可以基于NAT(Network Address Translation，网络地址转换)技术进行转发，以确保SYN报文到达建立了MPTCP的首个子流的相应的服务器。
接下来，在步骤309，服务器302对于收到的SYN报文发出响应消息，该相应消息可以是SYN/ACK报文。该SYN/ACK报文中可以携带包含服务器302的鉴权信息的MP-JOIN选项。该SYN/ACK报文由负载均衡接收并转发至UE。
在步骤310，对于服务器发出的SYN/ACK响应消息，收发器102发出建立MPTCP会话的附加子流的确认消息，该确认消息是ACK报文。同样，ACK报文要携带包含UE100的鉴权信息的MP-JOIN选项。该ACK报文由负载均衡接收并转发至服务器302。
最后，在步骤311，对于来自收发器102的ACK报文，服务器302也发出建立MPTCP会话的附加子流的确认消息，该确认消息也是ACK报文，用于对步骤310中收发器发送的ACK报文进行确认。同样，负载均衡接收ACK报文并将其转发至UE100。
以上，通过四次握手的方式，实现了MPTCP会话的附加子流的建立。同样，MPCTP的附加子流成功建立之后，UE100的收发器102与服务器302之间也可以进行数据传输。该数据传输的过程是正常的TCP数据传输过程，在此也不再赘述。
需要说明的是，在步骤306中，负载均衡接收到步骤305中所述的SYN报文之后，需要解析SYN报文。如果负载均衡通过解析SYN报文没有得到服务器的标识信息的情况下，即步骤306的判断结果为否的情况下，表示从收发器102发出的第二连接的请求消息中并没有包括服务器302的标识信息，也就意味着收发器102请求建立的第二连接并非与收发器101建立的MPTCP会话的第一连接属于同一个MPTCP会话。此时，负载均衡转而执行步骤312。
对于没有包括服务器标识信息的连接请求，负载均衡会认为是属于另一MPTCP会话的首个子流的建立请求，进而按照图2所示的步骤210-212，或者图3所示的步骤301-304进行处理，即根据会话的令牌执行五元组哈希算法或其他的随机分配算法转发，在此不再赘述。
图4是根据本申请一个实施例的携带服务器标识信息的MPTCP选项的示意图。如图4所示，MPTCP选项包括种类(Kind)、长度(Length)、子类型(Subtype)字段。其中，Kind字段表示该头部选项为MPTCP头部选项，取值为30，这个值是由IANA(The Internet Assigned Numbers Authority，互联网数字分配机构)分配的。Length字段表示该头部选项的长度。Subtype表示该MPTCP选项的子类型，一般为四个字节，在IESG(Internet Engineering Steering Group,互联网工程指导小组)的RFC8684标准中对不同的Subtype有详细的规定，例如0x0表示MP-CAPABLE，0x1表示MP-JOIN。
在根据本申请的实例中，Subtype定义为MP-LB-ADVERT选项，表示携带有服务器的标识信息。作为新定义的选项，Subtype的取值可以是现有标准中仍未指定的0x9-0xe中任意一个。另外，如图4所示，服务器的标识信息位于MPTCP选项的最后8个字节，但是本领域技术人员可以理解，服务器的标识信息可以根据需要设定为例如4个字节等其他长度，如果是使用服务器UUID的情况还需要单独扩展IP选项，本申请的实施例不对此做具体限定。
接下来，将结合图5对根据本申请的用于用户设备的MPTCP负载均衡方法进行说明。
在步骤501，UE向服务器发送用于建立MPTCP会话的第一连接的请求消息。与图2的步骤210一样，UE100通过收发器101向服务器发送建立MPTCP会话的第一连接，即MPTCP会话的首个子流的请求消息，该请求消息可以是SYN报文。其中SYN报文中携带有MP-CAPABLE选项，MP-CAPABLE选项用于表示UE100支持MPTCP连接。通常，MP-CAPABLE选项中还包含UE100的秘钥(Key)。
接下来，在步骤502，UE接收来自服务器的响应消息。如上所述，服务器302在接收到来自UE100的携带有MP-CAPABLE选项的SYN报文后，会发出响应消息。该响应消息是SYN/ACK报文，即握手信号确认消息。同样，SYN/ACK报文中携带有MP-CAPABLE选项，MP-CAPABLE选项用于表示服务器302支持MPTCP连接。通常，MP-CAPABLE选项中还包含服务器302的秘钥(Key)。
为了解决现有技术中同一MPTCP由不同LB转发的情况下可能存在无法实现负载均衡的问题，根据本申请的负载均衡方法，上述SYN/ACK报文中还携带有服务器302的标识信息(Server ID)以用于建立MPTCP会话的附加子流。该标识信息可以是与 MPTCP会话无关的服务器的任意标识，例如通用唯一识别码(Universally Unique Identifier，UUID)，也可以是例如1、2、3……等唯一的顺序编号或者全局唯一标识符(Globally Unique Identifier，GUID)。
在步骤503，UE100在接收到来自服务器302的SYN/ACK报文后，会发出确认消息。该确认消息是ACK报文，通常，ACK报文需要携带MP-CAPABLE选项，并且MP-CAPABLE选项中包含上述UE100的Key和服务器302的Key。至此，UE100的收发器101与服务器302之间通过三次握手的过程完成了MPCTP会话的首个子流的建立。
需要说明的是，MPCTP会话的首个子流成功建立之后，UE100的收发器101与服务器302之间可以进行数据传输。该数据传输的过程是正常的TCP数据传输过程，在此也不再赘述。
接下来，在步骤504，UE100的控制器110会产生用于建立第二连接的请求消息。这个第二连接可能是与上述步骤中建立的第一连接，即MPTCP会话的首个子流属于同一个MPTCP会话，也有可能是不同的会话。
因此，在步骤505，UE100需要对产生的第二连接的请求消息做出判断，并给予判断的结果做出不同的处理。
当步骤505的判断为是的情况下，表示收发器102将要建立同一MPTCP会话的附加子流。此时，UE100的控制器110会进行处理，以便在建立MPTCP会话的第二连接的请求消息中添加上述步骤502获得的服务器302的标识信息，即图5中的步骤506。该请求消息同样可以是SYN报文。其中SYN报文中携带有MP-JOIN选项，MP-JOIN选项中包含服务器302的令牌，用于表示该附加子流与上述的MPTCP会话的首个子流属于同一个MPTCP会话。如上所述，SYN报文中还必须携带有服务器302的标识信息。
如图2中所示的过程，负载均衡实例202接收到SYN报文之后，解析SYN报文得到服务器302的标识信息，通过检索静态转发规则表确定该SYN报文的转发对象。其中，所述的静态转发规则表包括服务器302的标识信息与服务器302的IP(Internet Protocol，网际互联协议)地址之间的映射关系。具体的可参考图2中的相关描述，在此不再赘述。
接下来，在步骤507，UE100接收服务器302发出的响应消息。该响应消息可以是SYN/ACK报文。该SYN/ACK报文中可以携带包含服务器302的鉴权信息的MP-JOIN选项。
在步骤508，对于服务器发出的SYN/ACK响应消息，UE100的收发器102发出建立MPTCP会话的附加子流的确认消息，该确认消息是ACK报文。同样，ACK报文要携带包含UE100的鉴权信息的MP-JOIN选项。
最后，在步骤509，对于来自收发器102的ACK报文，服务器302也发出建立MPTCP会话的附加子流的确认消息，这个确认消息被UE所接收。该确认消息也是ACK报文，用于对步骤217中收发器发送的ACK报文进行确认。
以上，通过四次握手的方式，实现了MPTCP会话的附加子流的建立。同样，MPCTP的附加子流成功建立之后，UE100的收发器102与服务器302之间也可以进行数据传输。该数据传输的过程是正常的TCP数据传输过程，在此也不再赘述。
如上步骤504所述，UE100的收发器102发起的第二连接可能是与上述步骤中建立 的第一连接，即MPTCP会话的首个子流属于不同的会话。对于不同的MPTCP会话来说，不需要在建立连接的请求消息中携带服务器302的标识信息。因此，如果步骤505的判断为否的情况下，执行步骤510，即发送用于建立第二连接的请求消息，此时，该建立第二连接的请求消息中不包含上述步骤502中获得的服务器的标识信息。
负载均衡在接收到不包含服务器标识信息的请求消息后，负载均衡会判断是属于另一MPTCP会话的首个子流的建立请求，进而根据当前会话的令牌执行五元组哈希算法或其他的随机分配算法转发，具体的，可参考图2的步骤210-212，或者图3的步骤301-304所示的MPTCP会话的首个子流的建立过程，在此不再赘述。
图6是根据本申请一个实施例的用于服务器的MPTCP负载均衡方法的流程图。
具体的，在步骤601，经由负载均衡实例201，服务器资源池300中的服务器302接收到UE100的收发器101用于建立MPTCP会话的第一连接的请求消息。该请求消息可以是SYN报文。其中SYN报文中携带有MP-CAPABLE选项，MP-CAPABLE选项用于表示UE100支持MPTCP连接。通常，MP-CAPABLE选项中还包含UE100的秘钥(Key)。步骤601对应于上述的步骤210，301以及501，在此不再赘述。
在步骤602，针对步骤601中的建立MPTCP会话的第一连接的请求消息，服务器302做出响应。该响应消息是SYN/ACK报文，即握手信号确认消息。同样，SYN/ACK报文中携带有MP-CAPABLE选项，MP-CAPABLE选项用于表示服务器302支持MPTCP连接。通常，MP-CAPABLE选项中还包含服务器302的秘钥(Key)。
为了解决现有技术中同一MPTCP由不同LB转发的情况下可能存在无法实现负载均衡的问题，根据本申请的负载均衡方法，上述SYN/ACK报文中还携带有服务器302的标识信息(Server ID)以用于建立MPTCP会话的附加子流。该标识信息可以是例如通用唯一识别码(Universally Unique Identifier，UUID)，也可以是例如1、2、3……等唯一的顺序编号或者全局唯一标识符(Globally Unique Identifier，GUID)。步骤602对应于上述的步骤211，303以及502，在此不再赘述。
接下来，在步骤603，负载均衡接收来自UE的确认消息并转发给相应的服务器302。该确认消息是ACK报文，通常，ACK报文需要携带MP-CAPABLE选项，并且MP-CAPABLE选项中包含上述UE的Key和服务器的Key。步骤603对应于上述的步骤212，304以及503，在此不再赘述。
由此，在步骤601-603中，UE与服务器之间通过三次握手的过程完成了MPCTP会话的首个子流的建立。同样，MPCTP的首个子流成功建立之后，UE100的收发器101与服务器302之间可以进行数据传输。该数据传输的过程是正常的TCP数据传输过程，在此也不再赘述。
在步骤604，服务器会接收来自UE的用于建立第二连接的请求消息。如上所述，UE100的控制器110会产生用于建立第二连接的请求消息。这个第二连接可能是与上述步骤601-603中建立的第一连接，即MPTCP会话的首个子流属于同一个MPTCP会话，也有可能是不同的会话。区别在于，如果第二连接与第一连接属于同一MPTCP会话，则建立第二连接的请求消息中会携带步骤602中发送的服务器302的标识信息；如果不属于同一MPTCP会话，则建立第二连接的请求消息中不会携带服务器302的标识信息。
接下来，针对不同的建立第二连接的请求消息，负载均衡实例会做不同处理。如果是携带了服务器302标识信息的请求消息，则会相应的转发至服务器302。如果没有携带服务器302的标识信息，建立第二连接的请求消息会经由负载均衡实例通过常规的例如五元组哈希算法或其他随机分配算法进行转发。因此在步骤605中，服务器针对是否携带有服务器标识的第二连接的请求消息会做不同处理。
在步骤606，服务器302会接收到负载均衡实例202转发的携带有服务器302标识信息的第二连接请求消息，并针对该请求消息发出响应消息。该响应消息可以是SYN/ACK报文。该SYN/ACK报文中可以携带包含服务器302的鉴权信息的MP-JOIN选项。
在步骤607，对于步骤606中服务器发出的SYN/ACK响应消息，UE100的收发器102发出建立MPTCP会话的附加子流的确认消息，该确认消息是ACK报文。同样，ACK报文要携带包含UE100的鉴权信息的MP-JOIN选项。
最后，在步骤608，对于来自收发器102的ACK报文，服务器302也发出建立MPTCP会话的附加子流的确认消息，这个确认消息被UE所接收。该确认消息也是ACK报文，用于对步骤607中收发器发送的ACK报文进行确认。
以上，通过四次握手的方式，实现了MPTCP会话的附加子流的建立。同样，MPCTP的附加子流成功建立之后，UE100的收发器102与服务器302之间也可以进行数据传输。该数据传输的过程是正常的TCP数据传输过程，在此也不再赘述。
如果上述步骤604中，UE100的收发器102发出的用于建立第二连接的请求消息不包括服务器302的标识信息，则该第二连接的请求消息可能会被负载均衡实例202转发至服务器资源池300中的任一台服务器，例如服务器301或303。此时，针对第二连接的请求消息，服务器301或303会发出携带其标识信息的响应。这个过程类似于MPTCP与建立MPTCP会话的首个子流，具体的可参考上述的步骤211，303或者502，在此不再赘述。
通过上述根据图2-图6说明了根据本申请一个实施例的负载均衡的方法，基于服务器的标识信息和IP地址之间映射关系的静态转发规则表建立MPTCP会话的多个子流。由于服务器的标识信息与MPTCP会话无关，在提供服务的生命周期内保持不变，因此相对于现有技术的负载均衡来说，根据本申请的负载均衡的方法能够更有效并可靠的建立MPTCP会话的多个子流。
本申请的各方法实施方式均可以以软件、磁件、固件等方式实现。
可将程序代码应用于输入指令，以执行本文描述的各功能并生成输出信息。可以按已知方式将输出信息应用于一个或多个输出设备。为了本申请的目的，处理系统包括具有诸如例如数字信号处理器(DSP)、微控制器、专用集成电路(ASIC)或微处理器之类的处理器的任何系统。
程序代码可以用高级程序化语言或面向对象的编程语言来实现，以便与处理系统通信。在需要时，也可用汇编语言或机器语言来实现程序代码。事实上，本文中描述的机制不限于任何特定编程语言的范围。在任一情形下，该语言可以是编译语言或解释语言。
至少一个实施例的一个或多个方面可以由存储在计算机可读存储介质上的表示性指令来实现，指令表示处理器中的各种逻辑，指令在被机器读取时使得该机器制作用于执行本文所述的技术的逻辑。被称为“IP核”的这些表示可以被存储在有形的计算机可读存储介质上，并被提供给多个客户或生产设施以加载到实际制造该逻辑或处理器的制造机器中。
虽然本申请的描述将结合较佳实施例一起介绍，但这并不代表此申请的特征仅限于该实施方式。恰恰相反，结合实施方式作发明介绍的目的是为了覆盖基于本申请的权利要求而有可能延伸出的其它选择或改造。为了提供对本申请的深度了解，以下描述中将包含许多具体的细节。本申请也可以不使用这些细节实施。此外，为了避免混乱或模糊本申请的重点，有些具体细节将在描述中被省略。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。
此外，各种操作将以最有助于理解说明性实施例的方式被描述为多个离散操作；然而，描述的顺序不应被解释为暗示这些操作必须依赖于顺序。特别是，这些操作不需要按呈现顺序执行。
如这里所使用的，术语“模块”或“单元”可以指代、是或者包括：专用集成电路(ASIC)、电子电路、执行一个或多个软件或固件程序的(共享、专用或组)处理器和/或存储器、组合逻辑电路和/或提供所描述的功能的其他合适的组件。
在附图中，以特定布置和/或顺序示出一些结构或方法特征。然而，应该理解，可以不需要这样的特定布置和/或排序。在一些实施例中，这些特征可以以不同于说明性附图中所示的方式和/或顺序来布置。另外，在特定图中包含结构或方法特征并不意味着暗示在所有实施例中都需要这样的特征，并且在一些实施例中，可以不包括这些特征或者可以与其他特征组合。
本申请公开的机制的各实施例可以被实现在硬件、软件、固件或这些实现方法的组合中。本申请的实施例可实现为在可编程系统上执行的计算机程序或程序代码，该可编程系统包括多个处理器、存储系统(包括易失性和非易失性存储器和/或存储元件)、多个输入设备以及多个输出设备。
可将程序代码应用于输入指令，以执行本申请描述的各功能并生成输出信息。可以按已知方式将输出信息应用于一个或多个输出设备。为了本申请的目的，处理系统包括具有诸如例如数字信号处理器(DSP)、微控制器、专用集成电路(ASIC)或微处理器之类的处理器的任何系统。
程序代码可以用高级程序化语言或面向对象的编程语言来实现，以便与处理系统通信。在需要时，也可用汇编语言或机器语言来实现程序代码。事实上，本申请中描述的机制不限于任何特定编程语言的范围。在任一情形下，该语言可以是编译语言或解释语言。
在一些情况下，所公开的实施例可以以硬件、固件、软件或其任何组合来实现。在一些情况下，至少一些实施例的一个或多个方面可以由存储在计算机可读存储介质上的表示性指令来实现，指令表示处理器中的各种逻辑，指令在被机器读取时使得该机器制作用于执行本申请所述的技术的逻辑。被称为“IP核”的这些表示可以被存储在 有形的计算机可读存储介质上，并被提供给多个客户或生产设施以加载到实际制造该逻辑或处理器的制造机器中。
这样的计算机可读存储介质可以包括但不限于通过机器或设备制造或形成的物品的非瞬态的有形安排，其包括存储介质，诸如：硬盘任何其它类型的盘，包括软盘、光盘、紧致盘只读存储器(CD-ROM)、紧致盘可重写(CD-RW)以及磁光盘；半导体器件，例如只读存储器(ROM)、诸如动态随机存取存储器(DRAM)和静态随机存取存储器(SRAM)之类的随机存取存储器(RAM)、可擦除可编程只读存储器(EPROM)、闪存、电可擦除可编程只读存储器(EEPROM)；相变存储器(PCM)；磁卡或光卡；或适于存储电子指令的任何其它类型的介质。
因此，本申请的各实施例还包括非瞬态的计算机可读存储介质，该介质包含指令或包含设计数据，诸如硬件描述语言(HDL)，它定义本申请中描述的结构、电路、装置、处理器和/或系统特征。

Claims (17)

  1. 一种MPTCP负载均衡方法，用于负载均衡设备，其特征在于，包括
    接收用户设备(User Equipment，UE)用于请求建立第一MPTCP连接的第一请求消息；
    选择与所述UE建立所述第一MPTCP连接的服务器并将所述第一请求消息发送到所述服务器；
    接收来自所述服务器的针对所述第一请求消息的第一响应消息，所述第一响应消息包括所述服务器的标识；
    接收所述UE用于请求建立第二MPTCP连接的第二请求消息，和
    在确定所述第二请求消息包括所述服务器的所述标识的情况下，根据所述服务器的标识查找静态转发规则表，以确定与所述服务器的标识相对应的所述服务器的IP地址，并且将所述第二请求消息转发至所述IP地址对应的所述服务器，其中，
    所述静态转发规则表预先配置在所述负载均衡设备中，并且包括所述服务器的标识与所述服务器的IP地址的映射关系。
  2. 如权利要求1所述的方法，其特征在于，所述第一MPTCP连接与所述第二MPTCP连接属于同一个MPTCP会话。
  3. 如权利要求1或2所述的负载均衡方法，其特征在于，所述服务器的标识包括所述服务器的编号或者UUID(Universally Unique Identifier，UUID)或者全局唯一标识符(Globally Unique Identifier，GUID)。
  4. 如权利要求2或3所述的方法，其特征在于，所述服务器的所述标识与所述MPTCP会话无关。
  5. 如权利要求1-4所述的负载均衡方法，其特征在于，所述响应消息还包括种类(Kind)、长度(Length)、MPTCP选项子类型(Subtype)中的至少一个。
  6. 一种MPTCP负载均衡方法，用于用户设备，其特征在于，包括
    发送用于请求建立第一MPTCP连接的第一请求消息，
    接收来自所述服务器针对所述第一请求消息的第一响应消息，所述第一响应消息包括所述服务器的标识，
    向所述服务器发送请求建立第二MPTCP连接的第二请求消息，其中，在确定所述第一MPTCP连接与所述第二MPTCP连接属于同一MPTCP会话的情况下，所述第二请求信息包括所述服务器的所述标识。
  7. 如权利要求6所述的负载均衡方法，其特征在于，所述服务器的标识包括所述服务器的编号或者UUID(Universally Unique Identifier，UUID)或者全局唯一标识符(Globally Unique Identifier，GUID)。
  8. 如权利要求6或7所述的方法，其特征在于，所述服务器的所述标识与所述MPTCP会话无关。
  9. 如权利要求6-8所述的负载均衡方法，其特征在于，所述第一响应消息还包括种类(Kind)、长度(Length)、MPTCP选项子类型(Subtype)中的至少一个。
  10. 如权利要求6-9所述的负载均衡方法，其特征在于，在确定所述第一MPTCP连接与所述第二MPTCP连接不属于同一MPTCP会话的情况下，所述第二请求信息不包括所述服务器的所述标识。
  11. 一种MPTCP负载均衡方法，用于服务器，包括
    接收来自用户设备的用于建立第一MPTCP连接的第一请求消息，
    发送对于所述第一MPTCP连接的第一请求消息的第一响应消息，所述第一响应消息包括所述服务器的标识，
    接收所述用户设备建立所述第一MPTCP连接的确认消息；
    接收所述用户设备用于建立第二MPTCP连接的第二请求消息，以及
    在确定所述第二请求消息中包括所述服务器的标识的情况下，建立所述第二MPTCP连接。
  12. 如权利要求11所述的负载均衡方法，其特征在于，所述第一MPTCP连接与所述第二MPTCP连接属于同一MPTCP会话。
  13. 如权利要求11或12所述的负载均衡方法，其特征在于，所述服务器的标识包括所述服务器的编号或者UUID(Universally Unique Identifier，UUID)或者全局唯一标识符(Globally Unique Identifier，GUID)。
  14. 如权利要求11-13所述的方法，其特征在于，所述服务器的所述标识与所述MPTCP会话无关。
  15. 如权利要求11-15所述的负载均衡方法，其特征在于，所述第一响应消息和所述第二响应消息还包括种类(Kind)、长度(Length)、MPTCP选项子类型(Subtype)中的至少一个。
  16. 一种机器可读介质，其特征在于，在所述介质上存储有指令，当所述指令在所述机器上运行时，使得所述机器执行权利要求1至15中任意一项所述的方法。
  17. 一种设备，其特征在于，包括：
    处理器；
    存储器，在所述存储器上存储有指令，当所述指令被所述处理器运行时，使得所述用户设备执行权利要求1至15中任意一项所述的方法。
PCT/CN2021/113001 2020-08-28 2021-08-17 Mptcp负载均衡方法、介质及设备 WO2022042370A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010884208.XA CN114205301A (zh) 2020-08-28 2020-08-28 Mptcp负载均衡方法、介质及设备
CN202010884208.X 2020-08-28

Publications (1)

Publication Number Publication Date
WO2022042370A1 true WO2022042370A1 (zh) 2022-03-03

Family

ID=80354608

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/113001 WO2022042370A1 (zh) 2020-08-28 2021-08-17 Mptcp负载均衡方法、介质及设备

Country Status (2)

Country Link
CN (1) CN114205301A (zh)
WO (1) WO2022042370A1 (zh)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180041570A1 (en) * 2015-04-01 2018-02-08 Telefonaktiebolaget Lm Ericsson (Publ) System, Apparatus and Method for Load Balancing
CN108667880A (zh) * 2017-03-31 2018-10-16 华为技术有限公司 一种负载均衡系统、方法及装置
CN110460641A (zh) * 2019-07-16 2019-11-15 华为技术有限公司 数据传输方法、装置及系统

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107295086B (zh) * 2017-06-28 2020-06-09 杭州云英网络科技有限公司 集群会话防丢失方法及系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180041570A1 (en) * 2015-04-01 2018-02-08 Telefonaktiebolaget Lm Ericsson (Publ) System, Apparatus and Method for Load Balancing
CN108667880A (zh) * 2017-03-31 2018-10-16 华为技术有限公司 一种负载均衡系统、方法及装置
CN110460641A (zh) * 2019-07-16 2019-11-15 华为技术有限公司 数据传输方法、装置及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
3GPP: "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on enhancement of support for Edge Computing in 5G Core network (5GC)(Release 17)", 3GPP TR 23.748 V0.4.0, 3 August 2020 (2020-08-03), pages 1 - 189, XP051925857 *

Also Published As

Publication number Publication date
CN114205301A (zh) 2022-03-18

Similar Documents

Publication Publication Date Title
WO2020259509A1 (zh) 一种应用迁移方法及装置
JP4722157B2 (ja) ネットワークトラフィックのインテリジェントロードバランシング及びフェイルオーバー
US10270689B2 (en) Multi-nonce enabled interest packet design for named-data networking
WO2022012310A1 (zh) 一种通信方法及装置
JP6508591B2 (ja) 無線ネットワークにおけるデバイス間のトンネルダイレクトリンクセットアップ（ｔｄｌｓ）セッションを再確立するための方法および装置
JP4651692B2 (ja) ネットワークトラフィックのインテリジェントロードバランシング及びフェイルオーバー
JP4840943B2 (ja) ネットワークトラフィックのインテリジェントロードバランシング及びフェイルオーバー
US8763109B2 (en) Seamless data networking
US8549146B2 (en) Stateless forwarding of load balanced packets
US7849127B2 (en) Method and apparatus for a distributed control plane
US20120331160A1 (en) Multi-path transmission control protocol proxy service
US20110038377A1 (en) Method and apparatus for providing host node awareness for multiple NAT64 environments
JP2019526983A (ja) ブロードバンドリモートアクセスサーバの制御プレーン機能と転送プレーン機能の分離
CN113872845B (zh) 建立vxlan隧道的方法及相关设备
JP6118122B2 (ja) 通信装置及びその制御方法、プログラム
JP5994190B2 (ja) パケット転送方法およびシステム
WO2011035710A1 (zh) 面向用户的通信方法和路由注册方法及设备及通信系统
WO2017124886A1 (zh) 按需获取路由的方法及网关
WO2017107871A1 (zh) 访问控制方法和网络设备
WO2021008591A1 (zh) 数据传输方法、装置及系统
JP2015511463A (ja) 無線デバイスを検出するための方法及び装置
WO2021169291A1 (zh) 发布路由的方法、网元、系统及设备
WO2023116165A1 (zh) 网络负载均衡方法、装置、电子设备、介质和程序产品
WO2022042370A1 (zh) Mptcp负载均衡方法、介质及设备
WO2023035836A1 (zh) 一种报文处理方法及相关装置

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21860208

Country of ref document: EP

Kind code of ref document: A1