Using BPF to increase the throughput of Go network programs by 8 times

Original link: https://colobu.com/2022/06/05/use-bpf-to-make-the-go-network-program-8x-faster/

The classic bpf (classical Berkeley Packet Filter) is a very useful technology, which can greatly improve performance in some special Go underlying network programming situations.

background

I have previously developed a Go UDP application, the client and server communicate through the UDP program and through the raw socket. The purpose of the program is quite special, here I will introduce a simple program as an example.

In fact, I am not strict when I say that I use the rawsocket method, I do not implement the socket and communicate in the following way (link layer method):

Nor does it use the following rawsocket method (IP layer method):

Instead, it directly uses the encapsulated method net.ListenPacket("ip4:udp", addr) in the Go standard library to send and receive packets at the IP layer.

By encapsulating the data structure of the custom UDP layer, I realize the sending and receiving of custom packets, and monitor the network.

Some people may say that using the standard library’s UDPConn is not enough. If it is an ordinary UDP program, there is no problem. If there are some special requirements, such as monitoring 1000 UDP ports, and tens of thousands of nodes regularly send monitoring data, we are unlikely to establish 1000*10000 UDPConn, so Here I use the rawsocket communication method.

RawSocket is a part of the standard Berkeley socket. When we use the standard library of Go to develop network programs, most of the scenarios use the encapsulated datagram type (UDPConn) or stream type (TCPConn), but if you want to do something more low-level For network programming, you need to use RawSocket, such as lower-level TCP, UDP network control, ICMP, ARP and other protocols. Different operating systems may implement different RawSockets. Here we take the Linux environment as an example.

The Linux man manual gives a detailed introduction to the relevant knowledge of RawSocket: socket(2) , packet(7) , raw(7) , this article will not repeat it, and this is not the focus of this article.

According to the Linux documentation, packets received in the Linux server = will be passed to both the kernel network module and RawSocket. So you sometimes need to pay attention when using RawSocket. For example, when you are processing TCP packets, the network program of the Linux kernel may have already processed this packet.

Raw sockets may tap all IP protocols in Linux, even protocols like ICMP or TCP which have a protocol module in the kernel. In this case, the packets are passed to both the kernel module and the raw socket(s). This should not be relied upon in portable programs, many other BSD socket implementations have limitations here.

If there are no special requirements, we directly use net.ListenPacket to implement a RawSocket program. The signature of this method is as follows:

The first parameter network can be udp , udp4 , udp6 , unixgram , or ip , ip4 , ip6 plus a colon and a protocol number or protocol name, such as ip:1 , ip:icmp , you can also handle any protocol .

demo program

server program

For the server program, we use conn, err := net.ListenPacket("ip4:udp", *addr) to listen to all UDP packets on the local address and start a goroutine to process them. There should be another judgment in the handler, which is to check whether the UDP port is the port we are dealing with, because here net.ListenPacket listens to all local UDPs, and there may be many useless UDP packets passed into the user mode program. .

Here we use gopacket to define the packets of various protocol layers to facilitate parsing (or creating) the network protocols of each layer of TCP/IP.

client program

The client program is simplified here, writes a hello , and reads the return from the server. When we are doing performance testing, we will use a loop to continuously write a seq number and check whether the server returns this seq in order to calculate the packet loss performance. In addition, a current limiter is used to limit the current to test the packet loss rate under a certain RPS.

helper method

The following is the EncodeUDPPacket method, which is used to generate a UDP packet data.

performance issues

Although the above program runs well, there will be some problems in the case of large concurrency.

Above, we started a goroutine to read the packet. This is a performance bottleneck. In the end, the server can only use one core to process the RawSocket packet.

Even creating multiple goroutines to read this PacketConn is useless, because this PacketConn is unique, it is a bottleneck, and multiple goroutines are sometimes better than one goroutine to read.

So can you call net.ListenPacket("ip4:udp", *addr) multiple times to generate multiple RawSockets for concurrent processing?

It seems to be possible, but in fact, these multiple RawSockets will read the same UDPPacket, rather than load balancing across multiple Sockets. Therefore, multiple RawSockets are not only useless, but also consumes more server resources.

The actual test can also reach a throughput of 20,000 to 30,000, and no matter how high the concurrency is, there will be packet loss.

But is there no way?

Neither. Here we can see that the main performance bottleneck is that the above program cannot achieve load balancing and use the ability of multiple cores to process concurrently. The second performance bottleneck is that the program monitors all the UDP packets of the local machine and hands it to the user-mode program for filtering and processing. There are many unnecessary packets in it.

Both of these performance issues we can handle with BPF.

BPF for packet filtering

The classic BPF appeared as early as 1994, and although everyone is talking about the extended BPF (eBPF), the classic BPF can still exert its power.

You may not have used BPF in programming, but I believe you must have had some experience with it in practice.

For example, when you use tcpdump to monitor network transmission, you often add filtering methods. For example, the following command only listens to port 8080 of the tcp protocol:

In fact, tcpdump generates a filter for tcp port 8080 , filters packets in the kernel, and only filters out the filtered packets.

In fact, you can view the compiled filtered code with the following command:

What does this mean? BPF defines a limited number of instructions that can filter packets in the VM.
The first line is the offset of the loaded package (offset 12 bytes), the second line is to check whether it is IPV6, if it is, jump to 002 , if not, jump to 008 . Let’s focus on IPV4.
The line 008 is to judge whether it is ipv4, if it is, jump to 009 . 009 loads a byte at offset 23, which is ip proto, line 010 determines whether ip proto is TCP, and if so, jumps to 011 .
Next, flags are judged to determine the address of the data.
Lines 014 and 016 read the source port and destination port in the TCP protocol. If it is equal to 8080 ( 0x1f90 ), the maximum return packet size is 262144 bytes, otherwise the packet is discarded.

Of course, the code generated by tcpdump is quite strict. When we actually write it, if it is determined to be an ipv4 package and the package has no expansion, the code written is simpler than this. But when we actually apply BPF, we might as well use the code generated by tcpdump without error.

Use -dd to display c code snippets, use -ddd to display decimal numbers. Let’s take a look at the effect of -dd , as this result we can use to convert to Go code:

In fact, x/net/bpf provides corresponding methods to make it easier to write BPF programs, serialize and deserialize. For example, to write a filter to filter out all packets whose destination port is equal to 8972, we can simply write it in the following format (considering the simple form, we only consider the form of IPV4 and ordinary IP packets):

We can write a program to convert the code generated by tcpdump into the RawInstruction instruction of bpf:

Well, all of this is ready, the background knowledge is introduced, and the performance bottleneck of the current RawSocket program is also introduced, so what if the performance bottleneck is solved.

For the first performance bottleneck, we can generate multiple goroutines, each of which is responsible for filtering a part of the packets, thus achieving load balancing. For example, filtering according to the client’s IP, or the server listening on 1000 ports, each goroutine is only responsible for a part of the ports. And can filter according to the client’s source port and so on. Always, through BPF filtering, a goroutine is only responsible for a part of the packet, realizing multi-core processing.

The second bottleneck is solved along with the first problem. Because BPF only filters our specific ports, UDP packets of other ports will not be copied from kernel mode to user mode, reducing the processing of useless packets.

To set up BPF filtering for PacketConn of the standard library, there are also various methods, such as calling syscall.SetsockoptInt to set it. But golang.org/x/net/ipv4 provides the SetBPF method, we can directly convert the standard library PacketConn to ipv4.PacketConn, and then set it.

For example, in the above server program, we can modify it to use BPF to filter in kernel mode:

This article is reprinted from: https://colobu.com/2022/06/05/use-bpf-to-make-the-go-network-program-8x-faster/
This site is for inclusion only, and the copyright belongs to the original author.