Yes, you could have an XDP program that checks if the packet is TCP, then updates the port before directly in the packet before it reaches the kernel stack
I understand that this a basic implementation, but for a large HTTP request, do we not need to forward all the packets to the same backend ? With this implementation, it will randomly distribute packets among the backends. So we need some stickiness to map a particular HTTP request to a particular backend server.
This is very cool.. I had often wondered how difficult it would be to do this in code. I am presuming that writing the same code using GoLang would be similar and easier?
The golang compiler doesn't currently support building BPF objects - at the moment the choices are C and (pretty recently) Rust. (I'd imagine that it would be a challenge to get Go's runtime past the eBPF verifier, too.)
I believe this is caused by the simple load balancing algorithm that is being used (remember it's only a demo). The algorithm decides which backend to send a packet to based on the time the packet is being processed. So imagine when the client makes it's request, it starts by sending a SYN which is forwarded by the load balancer to, say, backend A. Backend A will send a SYN-ACK which the load balancer will forward to the client. The client will then respond with an ACK. Now depending on the time the load balancer processes this packet it may send it to backend A or backend B, if it decided to send it to backend B then the TCP connection won't have been established and retransmissions will occur. The same when the client sends the HTTP request, it may go to backend A or backend B.
@@QueLastima it just depends on what you are into. There are several people still coding at this level building on top of current load balancers or working on building “better” ones that implement various integrations that their company may need or would like.
This was made in... 2021. ...And you need to code a load balancer in C? Something is terribly wrong here. Aren't there already mature tools for this? Ugh.
@@GlassFamFishing It is an interesting exercise, but I'd be really wary of putting my own load balancer in a production environment I cared about without a lot of QA testing.
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
Excellent video, packing wealth of information in 17mins.
I’ve watched this a few times now. It was great and was a huge help for me getting started with my XDP/BPF adventures.
Glad you like it!
IT WAS ACTUALLY AMAZING, KEEP ON THE GOOD WORK
FROM A STUDENT FROM VIET
absolutely fantastic
Simply amazing. Trying this out
Amazing! Is it possible to redirect TCP paackets from a port X to another port Y in the same machine using eBPF?
Yes, you could have an XDP program that checks if the packet is TCP, then updates the port before directly in the packet before it reaches the kernel stack
Very interesting and helpful. thank you.
We are glad you like it :)
I understand that this a basic implementation, but for a large HTTP request, do we not need to forward all the packets to the same backend ?
With this implementation, it will randomly distribute packets among the backends. So we need some stickiness to map a particular HTTP request to a particular backend server.
This is very cool.. I had often wondered how difficult it would be to do this in code.
I am presuming that writing the same code using GoLang would be similar and easier?
The golang compiler doesn't currently support building BPF objects - at the moment the choices are C and (pretty recently) Rust. (I'd imagine that it would be a challenge to get Go's runtime past the eBPF verifier, too.)
@@lizrice_ but you should be able to attach the complied BFP XDP program from the Go user space to the netlink socket?
Diplomatic
15:15 It seems that the long waiting for reply is caused by packet being unintentionally dropped. Does anyone know the root cause of this? Thanks!
I believe this is caused by the simple load balancing algorithm that is being used (remember it's only a demo). The algorithm decides which backend to send a packet to based on the time the packet is being processed. So imagine when the client makes it's request, it starts by sending a SYN which is forwarded by the load balancer to, say, backend A. Backend A will send a SYN-ACK which the load balancer will forward to the client. The client will then respond with an ACK. Now depending on the time the load balancer processes this packet it may send it to backend A or backend B, if it decided to send it to backend B then the TCP connection won't have been established and retransmissions will occur. The same when the client sends the HTTP request, it may go to backend A or backend B.
@@aarondesouza75 Do people really need to code at this level anymore? It's interesting, but I wouldn't want to start writing a load balancer.
@@QueLastima it just depends on what you are into. There are several people still coding at this level building on top of current load balancers or working on building “better” ones that implement various integrations that their company may need or would like.
@@QueLastima if you look at libbpf, people are updating that all the time. And that was built to try and make bcc more portable.
Can I use iph_csum to recalculate the ICMP/TCP/UDP's checksum?
Which ide is this?
visual studio code
Can you please share the code or repo?
It's here: github.com/lizrice/lb-from-scratch
This was made in... 2021. ...And you need to code a load balancer in C?
Something is terribly wrong here.
Aren't there already mature tools for this? Ugh.
This is a demonstration to illustrate eBPF / XDP - it's not intended to be a production-ready tool!
I like c. I don’t see anything wrong with using it to write a load balancer. Especially since you are looking for speed.
@@LizRice Noted. Sorry - it is an interesting exercise.
@@GlassFamFishing It is an interesting exercise, but I'd be really wary of putting my own load balancer in a production environment I cared about without a lot of QA testing.
Load ballancers are not the only use for EBFs... It's just an example to show what you can do with EBF running in the kernel