CN118784401A - Data transmission method and device - Google Patents

Abstract

The present application discloses a data transmission method and device, which are used to solve the problem that some servers currently do not support the network tunnel protocol and thus cannot use the L4 load balancing technology for data transmission. The method is applied to a front-end device, which is connected to multiple servers included in a server cluster. The method includes: receiving a first request data packet sent by a load balancer; the first request data packet is obtained by the load balancer using the network tunnel protocol to encapsulate the second request data packet, and the second request data packet comes from the client; determining the target server from multiple servers according to the destination IP address of the first request data packet, and using the network tunnel protocol to decapsulate the first request data packet to obtain the second request data packet; setting the destination MAC address in the packet header of the second request data packet to the MAC address of the target server, to obtain a third request data packet; sending the third request data packet to the target server.

Description

Data transmission method and device

Technical Field

The present application relates to the field of communication technology, and in particular to a data transmission method and device.

Background Art

The rapid development of the Internet has led to a rapid increase in the number of visits to multimedia network servers, while the central processing unit (CPU) and input/output (I/O) resources of a single server are limited and cannot meet the needs of a large number of concurrent visits. Therefore, a cluster consisting of multiple servers is currently used to jointly provide services to clients. Load balancing technology refers to a technology that distributes traffic to different servers in a cluster through a balancing algorithm when responding to high concurrent traffic from user requests to the server. Among them, the four-layer (L4) load balancing technology is a load balancing technology based on the five-tuple of data packets (source IP address, destination IP address, source port, destination port and transport layer protocol), which works at the fourth layer of OSI, the transport layer. L4 load balancing deploys a load balancer (LOad Balancer) in front of the server cluster. The load balancer receives request packets from external clients, determines which specific server in the server cluster needs to forward the received request to through a balancing algorithm, and uses a network tunneling protocol (such as IP tunneling protocol and Virtual eXtensible LOcal Area Network (VXLAN) protocol, etc.) to encapsulate the data packet and send it to the determined server. As an example, see Figure 1, a schematic diagram of the system architecture of an L4 load balancing technology.

However, some servers do not support the network tunneling protocol (such as servers using Windows systems), and therefore cannot process data packets from the load balancer, and thus cannot respond to client requests. If a network tunneling protocol processing module is added to all servers that do not support the network tunneling protocol, the cost is high. Therefore, how to use L4 load balancing technology for data transmission for servers that do not support the network tunneling protocol is an urgent problem to be solved.

Summary of the invention

The present application provides a data transmission method and device to solve the problem that some servers currently do not support the network tunnel protocol and thus cannot use L4 load balancing technology for data transmission.

In a first aspect, an embodiment of the present application provides a data transmission method, the method being applied to a front-end device, the front-end device being connected to a plurality of servers included in a server cluster, the method comprising:

receiving a first request data packet sent by the load balancer; the first request data packet is obtained by the load balancer encapsulating a second request data packet using a network tunnel protocol, and the second request data packet comes from a client;

Determine a target server from the multiple servers according to the destination IP address of the first request data packet, and use a network tunneling protocol to decapsulate the first request data packet to obtain the second request data packet;

Setting the destination MAC address in the packet header of the second request packet to the MAC address of the target server to obtain a third request packet;

Send the third request data packet to the target server.

In some embodiments, the method further comprises:

Determine the IP address of the target server corresponding to the destination IP address according to the pre-stored IP address mapping relationship;

The address resolution protocol is used to determine the MAC address of the target server corresponding to the IP address of the target server.

In some embodiments, the target server is a server for receiving the first request data packet determined by the load balancer from the server cluster using a load balancing algorithm; the destination IP address is an IP address corresponding to the target server obtained from multiple IP addresses stored in a front-end device when the load balancer determines that the target server does not support the network tunnel protocol.

In some embodiments, the load balancer stores a correspondence between multiple IP addresses of a front-end device and IP addresses of multiple servers connected to the front-end device, and the destination IP address is the IP address of the front-end device corresponding to the IP address of the target server determined by the load balancer based on the correspondence.

In some embodiments, the method further comprises:

The correspondence between the destination IP address and the MAC address of the target server is recorded.

In some embodiments, setting the destination MAC address in the header of the second request data packet to the MAC address of the target server specifically includes:

Determine whether the packet header of the second request data packet includes a destination MAC address;

If the packet header of the second request data packet includes a destination MAC address, modifying the destination MAC address in the packet header of the second request data packet to the MAC address of the target server;

If the packet header of the second request data packet does not include the destination MAC address, the MAC address of the target server is added to the packet header of the second request data packet as the destination MAC address of the second request data packet.

In some embodiments, the method further comprises:

The source MAC address in the packet header of the second request data packet is set to the MAC address of the front-end device.

In a second aspect, an embodiment of the present application provides a data transmission device, the device is a front-end device, or the device is applied to a front-end device, the device is connected to multiple servers included in a server cluster, and the device includes:

A communication unit, configured to receive a first request data packet sent by a load balancer; the first request data packet is obtained by encapsulating a second request data packet by the load balancer using a network tunnel protocol, and the second request data packet comes from a client;

a processing unit, configured to determine a target server from the plurality of servers according to a destination IP address of the first request data packet, and to decapsulate the first request data packet using a network tunneling protocol to obtain the second request data packet;

The processing unit is further configured to set the destination MAC address in the packet header of the second request packet to be the MAC address of the target server, to obtain a third request packet;

The communication unit is further used to send the third request data packet to the target server.

In some embodiments, the processing unit is further configured to:

Determine the IP address of the target server corresponding to the destination IP address according to the pre-stored IP address mapping relationship;

The address resolution protocol is used to determine the MAC address of the target server corresponding to the IP address of the target server.

In some embodiments, the target server is a server for receiving the first request data packet determined by the load balancer from the server cluster using a load balancing algorithm; the destination IP address is an IP address corresponding to the target server obtained from multiple IP addresses stored in a front-end device when the load balancer determines that the target server does not support a network tunneling protocol.

In some embodiments, the load balancer stores a correspondence between multiple IP addresses of a front-end device and IP addresses of multiple servers connected to the front-end device, and the destination IP address is the IP address of the front-end device corresponding to the IP address of the target server determined by the load balancer based on the correspondence.

In some embodiments, the processing unit is further configured to:

The correspondence between the destination IP address and the MAC address of the target server is recorded.

In some embodiments, the processing unit is specifically configured to:

Determine whether the packet header of the second request data packet includes a destination MAC address;

If the packet header of the second request data packet includes a destination MAC address, modifying the destination MAC address in the packet header of the second request data packet to the MAC address of the target server;

If the packet header of the second request data packet does not include the destination MAC address, the MAC address of the target server is added to the packet header of the second request data packet as the destination MAC address of the second request data packet.

In some embodiments, the processing unit is further configured to:

The source MAC address in the packet header of the second request data packet is set to the MAC address of the front-end device.

In a third aspect, an electronic device is provided, the electronic device comprising a controller and a memory. The memory is used to store computer-executable instructions, and the controller executes the computer-executable instructions in the memory to use hardware resources in the controller to perform the operation steps of any possible implementation method of the first aspect.

In a fourth aspect, a computer-readable storage medium is provided, wherein instructions are stored in the computer-readable storage medium, and when the computer-readable storage medium is run on the computer, the computer executes the above-mentioned methods.

This application proposes to deploy a front-end device before the server cluster, and the front-end device serves as a bridge between the server cluster and the load balancer. The front-end device can use the network tunnel protocol to process the message from the load balancer and forward it to the server, so that the server can directly use the standard Internet protocol to process the message. The solution of this application solves the problem that some existing servers cannot support the network tunnel protocol, and there is no need to deploy the load balancer and the server in the same local area network, which improves the flexibility of server deployment.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

FIG1 is a schematic diagram of a system architecture of an L4 load balancing technology;

FIG2 is a schematic diagram of a system architecture for load balancing based on direct routing;

FIG3 is a schematic diagram of a system architecture for load balancing based on address translation;

FIG4 is a schematic diagram of a system architecture for load balancing based on tunnel technology;

FIG5 is a schematic diagram of a communication system architecture provided in an embodiment of the present application;

FIG6 is a schematic diagram of a flow chart of a data transmission method provided in an embodiment of the present application;

FIG7 is a schematic diagram of the architecture of a front-end device provided in an embodiment of the present application;

FIG8 is a schematic diagram of a flow chart of another data transmission method provided in an embodiment of the present application;

FIG9 is a schematic diagram of the structure of a data transmission device provided in an embodiment of the present application;

FIG. 10 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

DETAILED DESCRIPTION

In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the technical solution of the present application, rather than all of the embodiments. Based on the embodiments recorded in the application documents, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the technical solution of the present application.

The terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented using sequences other than those illustrated or described herein.

Server cluster refers to combining multiple servers to provide external services, thereby improving the processing performance of the servers. The solution of this application is to maintain the load balance of multiple servers in the server cluster while transmitting data. There are many load balancing technologies, mainly including: Domain Name System (DNS) to achieve load balancing, seven-layer load balancing and L4 load balancing technology.

Among them, load balancing based on DNS means configuring the same domain name for the addresses of multiple servers in DNS, so that the client that queries the domain name will get one of the addresses, so that different clients can access different servers to achieve the purpose of load balancing. DNS load balancing does not require the development and maintenance of load balancing equipment, is simple to implement and has low cost, and the work of load balancing is handed over to the DNS server, saving management costs. However, DNS is not clear about the actual load of each server, so it cannot be allocated on demand, and DNS can support fewer algorithms and simple traffic distribution strategies, which easily lead to problems such as unbalanced scheduling and large granularity. In addition, the delay of synchronizing the information of server addition, modification or fault switching to the DNS server is large, resulting in user access failure. Seven-layer load balancing is load balancing based on a virtual uniform resource locator (URL) or the host's Internet Protocol (IP) address, and load balancing is achieved through application layer protocols. For example, nginx load balancing technology, in the seventh layer (application layer) of the network layer, nginx establishes a connection with the client (handshake and link establishment), and then flexibly distributes the request to different servers according to the client's request information and local configuration information. Although the seven-layer load balancing technology can achieve load balancing between servers, it needs to establish a connection with the client, which is less efficient.

Based on the above problems, L4 load balancing technology is proposed in the related technology. L4 load balancing is a load balancing technology based on network tunneling protocol. Network tunneling protocols mainly include IP tunneling protocol and VXLAN protocol. Among them, IP tunneling protocol is a technology that encapsulates an IP message in another IP message, so that the data message with the target of one IP address can be encapsulated and forwarded to another IP address. IP tunneling technology can also be called IP encapsulation technology. VXLAN introduces an outer tunnel in the format of User Datagram Protocol (UDP) as the data link layer, and the original data message content is transmitted as the tunnel payload. In other words, the outer tunnel of IP tunneling protocol is the third layer of the network - application layer, while the outer tunnel of VXLAN protocol is the second layer of the network - data link layer. Therefore, compared with IP tunneling protocol, VXLAN protocol can realize cross-regional Layer 2 interconnection. L4 load balancing mainly includes three working modes: Network Address Translation (NAT), Direct Routing (DR) and Tunneling (TUN). The three working modes are introduced below.

The architecture of the DR working mode can be seen in Figure 2. In the DR mode, the load balancer (LOad Balancer, LB) receives the data packet by modifying the destination MAC address of the data packet and configuring the server-only visible loopback (LOopback adaptor, LO) network card address on the server. Among them, the LO network card is a special network interface located in the server, which is not connected to any actual device and is used to realize communication between various processes in the same server. Multiple IP addresses can be configured on the LO network card. The specific process of the DR mode is as follows: Step 1, the client sends a request data packet to the LB. Here, the source IP address of the request data packet is defined as CIP, the destination IP address is the virtual IP (Virtual IP, VIP) of the LB, the source MAC address is CMAC, and the destination MAC address is VMAC. Step 2, the LB receives the request data packet, determines the target server to be forwarded from the server cluster according to the load balancing algorithm, and modifies the destination MAC address in the packet header to the MAC address of the target server (defined as RMAC), and modifies the source MAC address to the MAC address corresponding to the IP address of the LB and the target server in the same network segment (defined as DMAC). Step 3, the LB sends the request data packet with the modified MAC address to the target server. Step 4: The target server receives the request data packet and determines that the destination MAC address of the data packet is its own network card address and the destination IP address is the VIP configured in the LO network card, thereby parsing the request data packet to obtain data and performing corresponding business processing to obtain a response data packet. The response data packet is sent to the client using the VIP as the source IP and the CIP as the destination IP to complete the request response process.

The DR working mode is to forward the client's request data packet to the server through direct routing, and the server directly returns the response information to the client without going through the LB. It is more efficient and the modification of the data packet is small, so the information of the data packet is kept intact. However, since the LB directly sends the request data packet to the server through the data link layer, the LB and the server must be in the same LAN, so the servers in the server cluster cannot be deployed across computer rooms. In addition, the server must also be configured with a LO network card.

The system architecture of the NAT working mode can be seen in Figure 3. In the NAT mode, the client's request data packet is directly sent to the VIP of the LB. The LB uses the network address translation technology to modify the destination IP address of the request data packet to the address of the target server, thereby forwarding the request data packet to the target server for business processing. The specific process is as follows: Step 1, the client sends a request data packet to the LB. Here, the source IP address of the request data packet is defined as CIP, and the destination IP address is the VIP of the LB. Step 2, the LB receives the request data packet, parses the IP address in the header of the request data packet, modifies the destination IP address to the IP address of the target server (defined as RIP), and sends the modified request data packet to the target server. Among them, the target server is determined by the LB through the load balancing algorithm. Step 3, after the target server determines that the destination IP address of the received request data packet is its own IP address, it can parse the request data packet and generate a response data packet. Step 4, the target server sends the response data packet to the LB. Since the gateway device configured in the target server is LB, the target server will send the response data packet to the LB. Step 5, the LB forwards the response data packet to the client.

NAT mode does not have high requirements for the server, and only needs to process the standard Internet transport layer protocol. However, since all request and response messages need to pass through LB, and LB also needs to perform address translation on the messages, the load on LB is relatively large.

The system architecture of the TUN working mode can be seen in Figure 4. The TUN mode is similar to the DR mode. It is necessary to configure the server-only visible LO network card address on the server to realize the reception of data packets. Unlike the DR mode to modify the MAC address, the TUN mode re-encapsulates the original data packet and sends it to the target server. The specific process is: Step 1, the client sends a request data packet to the LB. Here, the source IP address of the request data packet is defined as CIP, and the destination IP address is the VIP of the LB. Step 2, the LB receives the request data packet, and uses the network tunnel protocol to encapsulate the request data packet, adds a tunnel header (where the source IP is DIP and the destination IP is RIP), and sends the re-encapsulated request data packet to the target server. Step 3, after the target server receives the request data packet, it first uses the network tunnel protocol to decapsulate it, and then uses the standard Internet protocol to decapsulate it again, and then generates a response data packet and returns it to the client.

The TUN mode puts less load pressure on the LB, but because the upper-layer application cannot parse the network tunnel protocol, all servers are required to have a network tunnel protocol processing module, which places high requirements on the server.

Based on the above problems, this application proposes a data transmission solution. In the TUN working mode of L4 load balancing technology, a front-end device is deployed before the server cluster. The front-end device uses the network tunneling protocol to preliminarily decapsulate the message from the LB, and sets the destination MAC address of the request data packet to the MAC address of the target server, and finally sends the processed request data packet to the target server. Therefore, the target server only needs to have a standard Internet protocol processing module to respond to the request.

In order to facilitate understanding of the solution of the present application, the communication system used in the present application is first introduced. Referring to Figure 5, a schematic diagram of the architecture of a communication system provided for an embodiment of the present application. It should be understood that the embodiment of the present application is not limited to the system shown in Figure 5. In addition, the device in Figure 5 can be hardware, or software divided from a functional point of view, or a structure after the above two are combined. As shown in Figure 5, the communication system includes a client, a load balancer, a front-end device, and a server cluster. Among them, the server cluster can include two types of servers, the first type is a server that supports a network tunneling protocol, such as a server using a LINUX system, and in Figure 5, server A and server B are used as the first type of servers; the second type is a server that does not support a network tunneling protocol, such as a server using a Window system, and in Figure 5, server C and server D are used as the second type of servers.

Exemplarily, a client is a terminal device used by a user, which may be called a mobile station (MS), a mobile terminal (MT), etc. It is a device that provides voice and/or data connectivity to a user, for example, a handheld device with a wireless connection function, a vehicle-mounted device, etc. At present, some examples of terminals are: mobile phones, tablet computers, laptop computers, PDAs, mobile Internet devices (MID), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self driving, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, etc.

The load balancer in FIG5 can be an independent server, processor or processing chip, etc., or it can be integrated in a gateway device, such as a switch. A load balancing algorithm is deployed in the load balancer to distribute requests from clients to servers in the server cluster to ensure load balancing between the servers. The front-end device shown in FIG5 can also be an independent server, processor or processing chip, etc. The front-end device serves as a bridge between the load balancer and the second type of server in the server cluster, and is used to process the request data packets from the load balancer using a network tunneling protocol, and forward the processed request data packets to the second type of server.

It should be noted that Figure 5 is only an exemplary description, and the present application does not limit the number of servers, front-end devices, and clients included in the communication system. Optionally, one front-end device can provide data packet processing services for multiple second-class servers at the same time.

The solution of the present application is described in detail below in conjunction with the system shown in FIG5 . Referring to FIG6 , a flow chart of a data transmission method provided in an embodiment of the present application is shown. Exemplarily, the process shown in FIG6 can be executed by a front-end device included in the system shown in FIG5 , and the multiple servers involved in FIG6 are second-class servers included in the system shown in FIG5 . The method flow shown in FIG6 specifically includes:

601, receiving a first request data packet from a load balancer.

Among them, the first request data packet is obtained by the load balancer using the network tunnel protocol to decapsulate the second request data packet, and the second request data packet comes from the client. That is to say, the client can generate request information, and use a standard Internet transmission protocol, such as the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol to encapsulate the request information to obtain a second request data packet, and send the second request data packet to the load balancer. After receiving the second request data packet, the load balancer can use a load balancing algorithm to determine the target server from the server cluster, and use the network tunnel protocol to encapsulate the second request data packet according to the stored IP address and MAC address of the target server to obtain a first request data packet, and send the first request data packet to the front-end device. It should be noted that in the present application, since the target server is a second-class server, the IP address of the target server stored by the load balancer is one of the multiple IP addresses of the front-end device, and the MAC address of the target server stored is one of the multiple MAC addresses of the front-end device.

602, determine a target server from multiple servers according to the destination IP address of the first request data packet, and use a network tunneling protocol to decapsulate the first request data packet to obtain a second request data packet.

Among them, the multiple servers are the second type of servers included in the system shown in FIG. 5 above.

Exemplarily, after receiving the first request data packet, the front-end device can determine whether the first request data packet is sent correctly according to whether the destination IP address in the packet header of the first request data packet is the IP address of the local machine. For example, when the front-end device determines that the destination IP address of the first request data packet is not the IP address configured by the local machine, the front-end device can discard the first request data packet; when it is determined that the destination IP address of the first request data packet is the IP address configured by the local machine, the front-end device can parse the first request data packet.

Among them, the local IP address of the front-end device can be set to multiple, and the number of IP addresses is the number of servers connected to the front-end device. For example, in the system shown in Figure 5, the front-end device is connected to two second-class servers (server C and server D), then two local IP addresses can be configured, that is, the IP addresses of server C and server D recorded in the load balancer are both the local IP addresses of the front-end device, so that as long as the destination address is the data packet of these two local IP addresses, it will be transmitted to the front-end device. Optionally, the mapping relationship between the local IP address and the actual IP address of the server can also be stored in the front-end device. For example, the set local IP address can include the actual IP address of server C corresponding to "IP address C", and can also include the actual IP address of server D corresponding to "IP address D". Correspondingly, the IP address of server C stored in the load balancer is not the actual IP address of server C, but the local IP address set in the front-end device, that is, "IP address C". Similarly, the IP address of server D stored in the load balancer is the local IP address set in the front-end device, that is, "IP address D". Therefore, when the load balancer determines that the target server is server C, it will use "IP address C" to encapsulate the second request data packet, and "IP address C" is exactly the local IP address configured in the front-end device, so that the encapsulated data packet will be received by the front-end device.

603. Set the destination MAC address in the packet header of the second request data packet to the MAC address of the target server to obtain a third request data packet.

Exemplarily, after determining the actual IP address of the target server in step 604, the front-end device can determine the MAC address of the target server corresponding to the actual IP address of the target server according to the Address Resolution Protocol (ARP), thereby setting the destination MAC address in the packet header of the second request data packet to the MAC address of the target server.

604, sending a third request data packet to the target server.

Exemplarily, after receiving the third request data packet, the target server can check whether the destination MAC address of the third request data packet is its own network card address, and check whether the destination IP address of the third request data packet is the IP address of the load balancer (i.e., VIP, where the LO network cards of each server included in the server cluster are configured with VIP). Furthermore, the target server can also determine the corresponding upper-layer application according to the port number in the third request data packet, use the determined application to perform corresponding business processing to generate a response data packet, and return the response data packet to the client to complete the request response process.

Based on the above solution, the present application proposes to deploy a front-end device before the server cluster, and the front-end device serves as a bridge between the server cluster and the load balancer. The front-end device can use the network tunnel protocol to process the message from the load balancer and forward it to the server, so that the server can directly use the standard Internet protocol to process the message. The solution of the present application solves the problem that some existing servers cannot support the network tunnel protocol, and there is no need to deploy the load balancer and the server in the same local area network, which improves the flexibility of server deployment.

In some embodiments, the front-end device stores a mapping relationship between the actual IP address of the server and the configured local IP address, and can also be configured with a mapping relationship between the actual MAC address of the server and the configured local IP address. Thus, when the front-end device executes the above step 603, it can directly obtain the MAC address corresponding to the destination IP address of the first request data packet (i.e., the local IP address configured by the front-end device) from the storage space, and use the obtained MAC address to set the destination MAC address of the second request data packet. In a possible case, if the storage space of the front-end device does not store the MAC address corresponding to the destination IP address of the first request data packet (i.e., the local IP address configured by the front-end device), the front-end device can also determine the actual IP address of the target server according to the mapping relationship between the actual IP address of the stored server and the configured local IP address, and can determine the MAC address corresponding to the actual IP address of the target server according to the Address Resolution Protocol (ARP). In this case, the front-end device can also record the mapping relationship between the destination IP address of the first request data packet (i.e., the local IP address configured by the front-end device) and the determined MAC address of the target server, for example, a MAC address mapping table can be generated and stored in the storage space, so that the corresponding MAC address can be directly queried according to the destination IP address of the data packet next time.

In one possible implementation, after the front-end device determines the MAC address of the target server, it can set it as the destination MAC address of the second request data packet. Exemplarily, the front-end device can determine whether the destination MAC address is included in the header of the second request data packet. Because the load balancer uses different network tunnel protocols when re-encapsulating the second request data packet from the client, the encapsulation results will be different. For example, if the IP tunnel protocol is used, the second layer in the header of the second request data packet will be missing, that is, the MAC address does not exist in the header of the second request data packet obtained by the front-end device. In this case, the front-end device can add the MAC address of the target server as the destination MAC address in the header of the second request data packet. If the VXLAN protocol is used for encapsulation, the header of the second request data packet obtained by the front-end device will include a MAC address. In this case, the front-end device can modify the MAC address included in the header of the second request data packet to the MAC address of the target server.

As an optional method, when setting the header of the second request data packet, the front-end device can also modify the source MAC address in the header, and can modify the source MAC address in the header to the MAC address of the front-end device itself. Specifically, the front-end device can query the MAC address corresponding to the IP address of the same network segment as the target server configured by itself, and use it as the source MAC address of the second request data packet.

Exemplarily, the solutions described in the above embodiments may be executed by a front-end device, or may be executed by a processor, a processing chip or different processing modules included in the front-end device. For example, as an example, see FIG. 7 , which is a schematic diagram of the architecture of a front-end device provided in an embodiment of the present application. As shown in FIG. 7 , the front-end device may include a receiving module, a decapsulation module, a storage module, an acquisition module, a generation module, an address setting module and a sending module.

Among them, the receiving module is used to receive the message from the load balancer, the decapsulation module is used to decapsulate the message from the load balancer using the network tunneling protocol, the address setting module is used to set the MAC address of the decapsulated message, and the sending module is used to send the message output by the address setting module to the server. The storage module is used to store the mapping relationship between the local IP address configured by the front-end device (that is, the destination IP address of the message from the load balancer) and the actual IP address of the server, the acquisition module is used to obtain the MAC address of the server according to the ARP protocol, and the generation module is used to generate the mapping relationship between the local IP address configured by the front-end device and the MAC address of the server according to the information of the storage module and the acquisition module, and the generated mapping relationship can be stored in the storage module.

It should be noted that the various processing modules shown in FIG. 7 are merely a functional division of the front-end device, and the actual structure of the front-end device is not limited thereto.

The following is a detailed introduction to the solution of the present application in conjunction with the schematic diagram of the architecture of the front-end device shown in FIG7. Referring to FIG8, a flow chart of a data transmission method provided in an embodiment of the present application specifically includes:

801. A receiving module receives a first request data packet from a load balancer.

Optionally, the receiving module may check the received first request data packet to determine that the destination IP address is one of a plurality of local IP addresses configured for the receiving module.

802. The decapsulation module uses a network tunneling protocol to decapsulate the first request data packet to obtain a second request data packet.

803, the acquisition module determines whether the storage module stores the MAC address corresponding to the destination IP address of the first request data packet.

If yes, continue to execute step 807.

If not, continue to execute step 804.

804. The acquisition module determines the IP address of the target server corresponding to the destination IP address of the first request data packet according to the IP address mapping relationship stored in the storage module.

805, the acquisition module determines the MAC address corresponding to the IP address of the target server according to the ARP protocol.

806. The generation module generates a mapping relationship between the destination IP address of the first request data packet and the MAC address of the target server, and stores the generated mapping relationship in the storage module.

807, the address setting module obtains the MAC address of the target server from the storage module.

808. The address setting module determines whether the header of the second request data packet has a MAC address.

If yes, continue to execute step 809.

If not, continue to execute step 810.

809. The address setting module modifies the destination MAC address in the packet header of the second request data packet to the MAC address of the target server.

Optionally, the address setting module may also modify the source MAC address in the packet header of the second request data packet to the MAC address of the front-end device, and continue to execute step 811.

810. The address setting module adds the MAC address of the target server as the destination MAC address in the packet header of the second request data packet.

Optionally, the address setting module may also add the MAC address of the front-end device as the source MAC address in the packet header of the second request data packet, and continue to execute step 811.

811, the sending module sends the data packet output by the address setting module to the target server.

Based on the same concept as the above method, see FIG9 , which is a data transmission device 900 provided by the present application, and the device 900 is used to perform each step in the above method, and in order to avoid repetition, it will not be described here. The device 900 includes: a communication unit 901 and a processing unit 902 .

A communication unit 901 is configured to receive a first request data packet sent by a load balancer; the first request data packet is obtained by encapsulating a second request data packet by the load balancer using a network tunneling protocol, and the second request data packet comes from a client;

The processing unit 902 is configured to determine a target server from the multiple servers according to the destination IP address of the first request data packet, and to decapsulate the first request data packet using a network tunneling protocol to obtain the second request data packet;

The processing unit 902 is further configured to set the destination MAC address in the packet header of the second request packet to be the MAC address of the target server, to obtain a third request packet;

The communication unit 901 is further configured to send the third request data packet to the target server.

In some embodiments, the target server is a server for receiving the first request data packet determined by the load balancer from the server cluster using a load balancing algorithm; the destination IP address is an IP address corresponding to the target server obtained from multiple IP addresses stored in a front-end device when the load balancer determines that the target server does not support a network tunneling protocol.

In some embodiments, the processing unit 902 is further configured to:

Determine the IP address of the target server corresponding to the destination IP address according to the pre-stored IP address mapping relationship;

The address resolution protocol is used to determine the MAC address of the target server corresponding to the IP address of the target server.

In some embodiments, the processing unit 902 is further configured to:

The correspondence between the destination IP address and the MAC address of the target server is recorded.

In some embodiments, the processing unit 902 is specifically configured to:

Determine whether the packet header of the second request data packet includes a destination MAC address;

If the packet header of the second request data packet includes a destination MAC address, modifying the destination MAC address in the packet header of the second request data packet to the MAC address of the target server;

If the packet header of the second request data packet does not include the destination MAC address, the MAC address of the target server is added to the packet header of the second request data packet as the destination MAC address of the second request data packet.

In some embodiments, the processing unit 902 is further configured to:

The source MAC address in the packet header of the second request data packet is set to the MAC address of the front-end device.

Fig. 10 shows a schematic diagram of the structure of an electronic device 1000 provided in an embodiment of the present application. The electronic device 1000 in the embodiment of the present application may further include a communication interface 1003, which is, for example, a network port, through which the electronic device may transmit data, for example, the communication interface 1003 may implement the functions of the communication unit 901 described in the above embodiment.

In an embodiment of the present application, the memory 1002 stores instructions that can be executed by at least one controller 1001. At least one controller 1001 can be used to execute the various steps in the above method by executing the instructions stored in the memory 1002. For example, the controller 1001 can implement the function of the processing unit 902 in Figure 9 above.

Among them, the controller 1001 is the control center of the electronic device, which can use various interfaces and lines to connect various parts of the entire electronic device, by running or executing instructions stored in the memory 1002 and calling data stored in the memory 1002. Optionally, the controller 1001 may include one or more processing units, and the controller 1001 may integrate an application controller and a modem controller, wherein the application controller mainly processes the operating system and application programs, etc., and the modem controller mainly processes wireless communications. It is understandable that the above-mentioned modem controller may not be integrated into the controller 1001. In some embodiments, the controller 1001 and the memory 1002 may be implemented on the same chip, and in some embodiments, they may also be implemented separately on independent chips.

The controller 1001 may be a general controller, such as a central processing unit (CPU), a digital signal controller, an application specific integrated circuit, a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, which may implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general controller may be a microcontroller or any conventional controller, etc. The steps performed by the data statistics platform disclosed in the embodiments of the present application may be performed directly by a hardware controller, or by a combination of hardware and software modules in the controller.

The memory 1002 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs, non-volatile computer executable programs and modules. The memory 1002 may include at least one type of storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory, a random access memory (English: Random Access Memory, referred to as: RAM), a static random access memory (English: Static Random Access Memory, referred to as: SRAM), a programmable read-only memory (English: Programmable Read Only Memory, referred to as: PROM), a read-only memory (English: Read Only Memory, referred to as: ROM), an electrically erasable programmable read-only memory (English: Electrically Erasable Programmable Read-Only Memory, referred to as: EEPROM), a magnetic memory, a disk, an optical disk, etc. The memory 1002 is any other medium that can be used to carry or store a desired program code in the form of an instruction or data structure and can be accessed by a computer, but is not limited thereto. The memory 1002 in the embodiment of the present application can also be a circuit or any other device that can realize a storage function, for storing program instructions and/or data.

By designing and programming the controller 1001, for example, the code corresponding to the method introduced in the above embodiment can be solidified into the chip, so that the chip can execute the steps of the above method during operation. How to design and program the controller 1001 is a technology well known to those skilled in the art and will not be repeated here.

Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

The present application is described with reference to the flowchart and/or block diagram of the method, device (system), and computer program product according to the present application. It should be understood that each flow process and/or box in the flow chart and/or block diagram, as well as the combination of the flow process and/or box in the flow chart and/or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a controller of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the controller of the computer or other programmable data processing device produce a device for implementing the function specified in one flow chart or multiple flows and/or one box or multiple boxes in the block diagram.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device that implements the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

These computer program instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications falling within the scope of the present application.

Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims (10)

1. A data transmission method, wherein the method is applied to a front-end device, the front-end device being connected to a plurality of servers included in a server cluster, the method comprising:

Receiving a first request data packet sent by a load balancer; the first request data packet is obtained by encapsulating a second request data packet by the load balancer through a network tunnel protocol, and the second request data packet is from a client;

Determining a target server from the plurality of servers according to the destination IP address of the first request data packet, and decapsulating the first request data packet by adopting a network tunnel protocol to obtain the second request data packet;

setting a destination MAC address in a packet head of the second request data packet as the MAC address of the target server to obtain a third request data packet;

And sending the third request data packet to the target server.

2. The method according to claim 1, wherein the method further comprises:

determining the IP address of the target server corresponding to the target IP address according to a pre-stored IP address mapping relation;

and determining the MAC address of the target server corresponding to the IP address of the target server by adopting an address resolution protocol.

3. The method according to claim 1 or 2, wherein the target server is a server determined by the load balancer from the cluster of servers using a load balancing algorithm for receiving the first request data packet; and the target IP address is an IP address corresponding to the target server, which is acquired from a plurality of stored IP addresses of the front-end equipment when the load balancer judges that the target server does not support a network tunnel protocol.

4. The method according to claim 1 or 2, wherein the setting the destination MAC address in the header of the second request packet as the MAC address of the destination server specifically includes:

judging whether the packet head of the second request data packet comprises a destination MAC address or not;

If the packet header of the second request data packet comprises a destination MAC address, modifying the destination MAC address in the packet header of the second request data packet into the MAC address of the target server;

If the packet header of the second request data packet does not include the destination MAC address, the MAC address of the target server is added in the packet header of the second request data packet as the destination MAC address of the second request data packet.

5. A data transmission apparatus, wherein the apparatus is a front-end device or the apparatus is applied to a front-end device, and the apparatus connects a plurality of servers included in a server cluster, the apparatus comprising:

The communication unit is used for receiving the first request data packet sent by the load balancer; the first request data packet is obtained by encapsulating a second request data packet by the load balancer through a network tunnel protocol, and the second request data packet is from a client;

The processing unit is used for determining a target server from the plurality of servers according to the destination IP address of the first request data packet, and decapsulating the first request data packet by adopting a network tunnel protocol to obtain the second request data packet;

the processing unit is further configured to set a destination MAC address in a packet header of the second request packet as a MAC address of the target server, to obtain a third request packet;

the communication unit is further configured to send the third request packet to the target server.

6. The apparatus of claim 5, wherein the processing unit is further configured to:

determining the IP address of the target server corresponding to the target IP address according to a pre-stored IP address mapping relation;

and determining the MAC address of the target server corresponding to the IP address of the target server by adopting an address resolution protocol.

7. The apparatus according to claim 5 or 6, wherein the target server is a server for receiving the first request packet determined by the load balancer from the server cluster using a load balancing algorithm; and the target IP address is an IP address corresponding to the target server, which is acquired from a plurality of stored IP addresses of the front-end equipment when the load balancer judges that the target server does not support a network tunnel protocol.

8. The device according to claim 5 or 6, characterized in that the processing unit is specifically configured to:

judging whether the packet head of the second request data packet comprises a destination MAC address or not;

If the packet header of the second request data packet comprises a destination MAC address, modifying the destination MAC address in the packet header of the second request data packet into the MAC address of the target server;

If the packet header of the second request data packet does not include the destination MAC address, the MAC address of the target server is added in the packet header of the second request data packet as the destination MAC address of the second request data packet.

9. An electronic device, characterized in that the electronic device comprises a controller and a memory,

The memory is used for storing a computer program or instructions;

the controller being adapted to execute a computer program or instructions in a memory such that the method of any of claims 1-4 is performed.

10. A computer readable storage medium storing computer executable instructions which, when invoked by a computer, cause the computer to perform the method of any one of claims 1-4.