Thanks for the video but I think you could have explained the differences of L4 vs L7 Load Balancing a bit more: Differences Between Layer 4 and Layer 7 Load Balancing Layer 4 load balancing operates at the intermediate transport layer, which deals with delivery of messages with no regard to the content of the messages. Transmission Control Protocol (TCP) is the Layer 4 protocol for Hypertext Transfer Protocol (HTTP) traffic on the Internet. Layer 4 load balancers simply forward network packets to and from the upstream server without inspecting the content of the packets. They can make limited routing decisions by inspecting the first few packets in the TCP stream. Layer 7 load balancing operates at the high‑level application layer, which deals with the actual content of each message. HTTP is the predominant Layer 7 protocol for website traffic on the Internet. Layer 7 load balancers route network traffic in a much more sophisticated way than Layer 4 load balancers, particularly applicable to TCP‑based traffic such as HTTP. A Layer 7 load balancer terminates the network traffic and reads the message within. It can make a load‑balancing decision based on the content of the message (the URL or cookie, for example). It then makes a new TCP connection to the selected upstream server (or reuses an existing one, by means of HTTP keepalives) and writes the request to the server.
I'm really glad that I found your videos through UA-cam recommendation. This is by far the best recommendation for me, your videos are very useful for me as a software engineer. Thank you and keep up the great work!
This one video clears so many concepts! As software engineers, we work with so much high level stuff, knowing what is happening behind the scenes is really important. Your channel is great!
Love your energy man, really enjoyed binge watching for the last days. On the topic of proxying, I recently deployed a MITM proxy using nginx (openresty for lua oidc connector) in front of a openshift 3.11 cluster, reason being limiting entry to the platform and deployed workloads only to users authenticated at the proxy level, while retaining access to programmatic clients (jenkins pipelines). Not proud about the result since it is so hacky, but it gets the job done
the coolest thing for me is that Layer 4 proxy is breaking the first TLS message and then passes the "Client Hello" to server1 as if the proxy was the client. and then server1 responds with the "Server Hello" and Layer 4 proxy just passes it back to the actual client. but that means that all the servers behind the proxy have to share the same certificate? so that means you can have only the same app behind the proxy? not like in Layer 7 when one subdomain may be handled by app1 in server1 and second subdomain in app2 in server2 :thinking:
What a fantastic observation 👍 absolutely correct. However you can still serve different certificates based on the SNI TLS extension which is in the client hello 👍
How does the layer 7 reverse proxy know which client to respond to, when it receives the response from server? I believe in layer 4, it is done by maintaining a NAT, and it is the same TCP connection.
in layer 4 ,we have one connection between the client and the load balancer and the server ? how is that happening , what about the acks > and what happen if the packet is lost between one node and the other ?
While the packets are being sent, the client and server keep track of which packets have successfully reached etc, this is what the TCP state is. Http has nothing to do with how things get transported and so is stateless
Thanks a lot for this info. However, I've one silly doubt, how does a reverse proxy differs from a proxy? Not the theory way, so basically in proxy, somebody else acts like the "client" for me, I sent request to him, and he hits the actual SERVER, and gets the response back right? But isn't that s exactly what reverse proxy is doing for me? I hit a reverse proxy, as if it was a server, but then it hit the actualy SERVER for me, got the reeponse and returned in to me. This is exactly what my PROXY did for me. Got it, I think the fundamental remains the same, it's just about the capabilities that we've allowed for reverse proxy and proxy.
Proxy servers can't look at the data but it can check the Layer 2 details like MAC address and Layer 4 details like ports and IP address if it wishes to right?
Hey Hussein, thank u for this video. 1.) What is the point behind L4 proxy reading TLS packets. it doesn't need to read because it is sending them to server like it was sending simple HTTP request packets right.? 2.) In L4 reverse proxy, there will be two TCP connection (client- proxy, proxy-server) but one TLS Handshake(client-server) in case of HTTPS.
Hey Ashurosh, your second question answers the first one. Layer 4 proxy reads TLS packet in order to terminate TLS so it decrypts the traffic and either send the traffic to the backend unencrypted or reencrypt it to the backend The alternative is TLS Passthrough which forwards everything to the backend
@@hnasr But this is not what you have explained in the video right? Video talks about proxy not having a key to decrypt the packets sent by either client or server. Video explains a case of TLS passthrough then?
as per your first question, layer 4 is sticky connection so it needs to read few packets so it could forward traffic to same upstream server based on source ip.
For L4 proxy, how does it get to know which server it has to send its request to if it does not read the data? When L4 proxy forms its own pkts it needs destination IP right. how will it know that IP?
one query - there is a single TCP connection between the client and the server in layer 4 proxy unlike 7, where there are two different TCP connections, the proxy starts the new connection to the server. This is regarding the whatsapp connections video, you mentioned only one IP can make 65k connections to the server, so for layer 7 proxy as the server sees a connection from the proxy it will always limit the no. of connections to 65k, right. Then how does, whatsapp handle this. They claim till 300k. Do they use layer 4 proxying? I have this query on my mind. I asked someone else, they explained like, the LB just handles the connection to the server. So everytime, the client wants to start a websocket, the LB delegates and transfers the first request to the dedicated server, and where the connection is established from the actual server to the client. 😕 Please reply
The connection pairing is source ip - source port - destination ip - destination port Only If destination ip and destination port is fixed and the source ip is fixed then you only have 65k source port to play with In whatsapp case, the client is your phone and destination is whatsapp server (assume just one server) the destination ip and the destination port is fixed so source port and source ip is variable (any client can connect with their ip so it will be different) This means that the theoretical limit options are 4 billion IP addresses (assuming ipv4) times 65k source ports which is .. alot of connections. whatsapp was able to handle 3 million connections on one server on one port on one ip address after which their machine just melts.
Thanks for the reply. There was another query, regarding the connection forming between the layer7 proxy to the WhatsApp server. The server sees only one source IP(the proxy), as it terminates the prev connection and starts a new connection to the server. What happens in this case. There would be a cap of only 65k connections
Will the above L4 proxying work if the requests get routed between S1 and S2 when we use TLS 1.3? No right? I understand it will work with TLS 1.2 if both S1 and S2 serves the same certificate during the symmetric key formation.
@@hnasr okay, let's say during our initial HTTPS call, we created a symmetric key with S1 via TLS 1.3. Our next call goes to S2 encrypted with the key we formed with S1. Now, S2 can't decrypt it right? Am I missing something?
@@palaniappanrm6277 Two options I know of: TLS termination = the load balancer takes care of TLS and forwards requests unencrypted inside your network. Risky. TLS bridging = same but the load balancer does TLS internally with your servers. Decrypting and encrypting. Slower but safe. Also sticky sessions can be achieved in the case of pass through.
I thought about a different perspective now. Does LB must be a TLS termination always? Because if doesn't and we created a symmetric key with one of the servers (S1) then if LB routes us to another server during next request, S2 can't decrypt what we send right?
Palaniappan RM good question! So answer is no LB can also be TLS Passthrough where it just passes the TLS to the backend server and if that happens you are right the LB must always forward to the same backend. The certificate in this case is passed by the backend server.
@@hnasr cool but the complication on LB to forward to same backend server is very difficult right? It should remember the requesting server in some way. Does it do that sticky session thing here?
@@hnasr Saw your Nginx video now. So, Nginx L4 LB might do NAT to forward the request from same client to the same server or it can use something else too.
Thanks for the video but I think you could have explained the differences of L4 vs L7 Load Balancing a bit more:
Differences Between Layer 4 and Layer 7 Load Balancing
Layer 4 load balancing operates at the intermediate transport layer, which deals with delivery of messages with no regard to the content of the messages. Transmission Control Protocol (TCP) is the Layer 4 protocol for Hypertext Transfer Protocol (HTTP) traffic on the Internet. Layer 4 load balancers simply forward network packets to and from the upstream server without inspecting the content of the packets. They can make limited routing decisions by inspecting the first few packets in the TCP stream.
Layer 7 load balancing operates at the high‑level application layer, which deals with the actual content of each message. HTTP is the predominant Layer 7 protocol for website traffic on the Internet. Layer 7 load balancers route network traffic in a much more sophisticated way than Layer 4 load balancers, particularly applicable to TCP‑based traffic such as HTTP. A Layer 7 load balancer terminates the network traffic and reads the message within. It can make a load‑balancing decision based on the content of the message (the URL or cookie, for example). It then makes a new TCP connection to the selected upstream server (or reuses an existing one, by means of HTTP keepalives) and writes the request to the server.
Great input !
I'm following and watching your videos every time and i don't know why but you're following precisely my school's program 😂 you're magic!!!
Haha I am glad my videos line up with your school schedule. All the best 😊
I'm really glad that I found your videos through UA-cam recommendation. This is by far the best recommendation for me, your videos are very useful for me as a software engineer. Thank you and keep up the great work!
This one video clears so many concepts! As software engineers, we work with so much high level stuff, knowing what is happening behind the scenes is really important. Your channel is great!
Love your energy man, really enjoyed binge watching for the last days.
On the topic of proxying, I recently deployed a MITM proxy using nginx (openresty for lua oidc connector) in front of a openshift 3.11 cluster, reason being limiting entry to the platform and deployed workloads only to users authenticated at the proxy level, while retaining access to programmatic clients (jenkins pipelines). Not proud about the result since it is so hacky, but it gets the job done
@NasyWicked Is there a write-up on this? I am curious how to set up such a infrastructure.
Much appreciate. Great work! You deserve more tumbs up! Maybe a video on Reverse Proxy vs APIGateway ?
the coolest thing for me is that Layer 4 proxy is breaking the first TLS message and then passes the "Client Hello" to server1 as if the proxy was the client. and then server1 responds with the "Server Hello" and Layer 4 proxy just passes it back to the actual client. but that means that all the servers behind the proxy have to share the same certificate? so that means you can have only the same app behind the proxy? not like in Layer 7 when one subdomain may be handled by app1 in server1 and second subdomain in app2 in server2 :thinking:
What a fantastic observation 👍 absolutely correct. However you can still serve different certificates based on the SNI TLS extension which is in the client hello 👍
Thank You, I tries to watch all your videos
Nafas Muhammad thank you !! I really appreciate it, you support the channel by watching
where were you all these years 😂 I am thinking to buy your video series plan like netflix
Thanks fr this topic also. Wonderdul as always Hussain.
I had also Made a Video ant Reserve proxies but this one is way better
FUTE thanks FUTE! Please keep making videos, some people will prefer your style over mine. If you enjoy making tech videos keep at it 😊🙏
How does the layer 7 reverse proxy know which client to respond to, when it receives the response from server? I believe in layer 4, it is done by maintaining a NAT, and it is the same TCP connection.
in layer 4 ,we have one connection between the client and the load balancer and the server ? how is that happening , what about the acks > and what happen if the packet is lost between one node and the other ?
How is HTTP a stateless protocol while TCP is a stateful protocol. Can you please explain @Hussein Nasser ?
While the packets are being sent, the client and server keep track of which packets have successfully reached etc, this is what the TCP state is. Http has nothing to do with how things get transported and so is stateless
Thanks a lot for this info. However, I've one silly doubt, how does a reverse proxy differs from a proxy? Not the theory way, so basically in proxy, somebody else acts like the "client" for me, I sent request to him, and he hits the actual SERVER, and gets the response back right?
But isn't that s exactly what reverse proxy is doing for me? I hit a reverse proxy, as if it was a server, but then it hit the actualy SERVER for me, got the reeponse and returned in to me. This is exactly what my PROXY did for me.
Got it, I think the fundamental remains the same, it's just about the capabilities that we've allowed for reverse proxy and proxy.
Proxy servers can't look at the data but it can check the Layer 2 details like MAC address and Layer 4 details like ports and IP address if it wishes to right?
Palaniappan RM correct! Except when its. Layer 7 TLS termination proxy. Where it is acts like a man in the middle
@@hnasr yes. L7 proxy can decrypt and see whole stuffs. Thank you.
very good Hussein
Sarah Brown thanks Sarah 😊
Hey Hussein, thank u for this video.
1.) What is the point behind L4 proxy reading TLS packets. it doesn't need to read because it is sending them to server like it was sending simple HTTP request packets right.?
2.) In L4 reverse proxy, there will be two TCP connection (client- proxy, proxy-server) but one TLS Handshake(client-server) in case of HTTPS.
Hey Ashurosh, your second question answers the first one. Layer 4 proxy reads TLS packet in order to terminate TLS so it decrypts the traffic and either send the traffic to the backend unencrypted or reencrypt it to the backend
The alternative is TLS Passthrough which forwards everything to the backend
@@hnasr ok, got it. thanks for the quick reply. you are amazing man.
@@hnasr But this is not what you have explained in the video right? Video talks about proxy not having a key to decrypt the packets sent by either client or server. Video explains a case of TLS passthrough then?
as per your first question, layer 4 is sticky connection so it needs to read few packets so it could forward traffic to same upstream server based on source ip.
If its a tech stuff, check out Hussein's content. period!
i love the "boop boop"s
For L4 proxy, how does it get to know which server it has to send its request to if it does not read the data? When L4 proxy forms its own pkts it needs destination IP right. how will it know that IP?
first few packets has those info like source ,dest ip etc which is differnet than content encryption
one query - there is a single TCP connection between the client and the server in layer 4 proxy unlike 7, where there are two different TCP connections, the proxy starts the new connection to the server. This is regarding the whatsapp connections video, you mentioned only one IP can make 65k connections to the server, so for layer 7 proxy as the server sees a connection from the proxy it will always limit the no. of connections to 65k, right. Then how does, whatsapp handle this. They claim till 300k. Do they use layer 4 proxying? I have this query on my mind. I asked someone else, they explained like, the LB just handles the connection to the server. So everytime, the client wants to start a websocket, the LB delegates and transfers the first request to the dedicated server, and where the connection is established from the actual server to the client. 😕 Please reply
The connection pairing is source ip - source port - destination ip - destination port
Only If destination ip and destination port is fixed and the source ip is fixed then you only have 65k source port to play with
In whatsapp case, the client is your phone and destination is whatsapp server (assume just one server) the destination ip and the destination port is fixed so source port and source ip is variable (any client can connect with their ip so it will be different)
This means that the theoretical limit options are 4 billion IP addresses (assuming ipv4) times 65k source ports which is .. alot of connections. whatsapp was able to handle 3 million connections on one server on one port on one ip address after which their machine just melts.
Thanks for the reply. There was another query, regarding the connection forming between the layer7 proxy to the WhatsApp server. The server sees only one source IP(the proxy), as it terminates the prev connection and starts a new connection to the server. What happens in this case. There would be a cap of only 65k connections
And I thought that L4 proxying was the lightest approach.
Will the above L4 proxying work if the requests get routed between S1 and S2 when we use TLS 1.3? No right? I understand it will work with TLS 1.2 if both S1 and S2 serves the same certificate during the symmetric key formation.
Palaniappan RM it should work with either. If we are doing TLS Passthrough 👍 the S1 / S2 will serve the same certificate
@@hnasr okay, let's say during our initial HTTPS call, we created a symmetric key with S1 via TLS 1.3. Our next call goes to S2 encrypted with the key we formed with S1. Now, S2 can't decrypt it right? Am I missing something?
@@palaniappanrm6277
Two options I know of:
TLS termination = the load balancer takes care of TLS and forwards requests unencrypted inside your network. Risky.
TLS bridging = same but the load balancer does TLS internally with your servers. Decrypting and encrypting. Slower but safe.
Also sticky sessions can be achieved in the case of pass through.
I thought about a different perspective now. Does LB must be a TLS termination always? Because if doesn't and we created a symmetric key with one of the servers (S1) then if LB routes us to another server during next request, S2 can't decrypt what we send right?
Palaniappan RM good question! So answer is no LB can also be TLS Passthrough where it just passes the TLS to the backend server and if that happens you are right the LB must always forward to the same backend. The certificate in this case is passed by the backend server.
@@hnasr cool but the complication on LB to forward to same backend server is very difficult right? It should remember the requesting server in some way. Does it do that sticky session thing here?
Not really. A sticky session its more like a layer 4 load balancing
@@hnasr yeah. Layer 7 LB will do TLS termination. Layer 4 won't do and also does sticky session. Right?
@@hnasr Saw your Nginx video now. So, Nginx L4 LB might do NAT to forward the request from same client to the same server or it can use something else too.
Getting high .. don’t know why