Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.

Difference between ALB and NLB in connection reusing aspect

hi team, I want to ask difference between ALB and NLB in the connection reusing aspect.

I have two solutions to expose my service(which is a http service):

1. ALB->nginx(ingress)->services

2.NLB->nginx(ingress)->serivices

question: will any user connection from my user will create a new connection to nginx instance?

for solution 1, ALB can reuse the existing connection(idle connection),   so the connection between ALB and nginx will not increase significant when a lot of user send request.

for solution 2, NLB can not reuse the existing connection,   so the connection between NLB and nginx will increase significant when a lot of user send request.

Is this correct ? thanks, what if I use Proxy Network Load Balancer , will Proxy Network Load Balancer  help reuse connection?

thanks 

for 

Solved Solved
0 2 338
1 ACCEPTED SOLUTION

Hi @gavinX,

Welcome to Google Cloud Community!

Application Load Balancers do support connection reuse, they keep a connection pool and, when a subsequent request arrives from the same client IP address and port, they try to reuse an existing connection to the backend(nginx). When a client makes a request to the ALB, It avoids the need to establish a new connection each time a client sends a request. This helps in reducing the overhead of establishing new connections.

For Network Load Balancers, which serves at a lower level (Layer 4), the main function is traffic distribution according to IP and port. Unlike an ALB, they do not automatically maintain the client-level connection state. It forwards each individual TCP connection between the client and the backend service. This means that for each incoming request, a new TCP connection may be established between NLB and nginx.

You'd use a passthrough Network Load Balancer in the following circumstances:

  • You need to forward original client packets to the backends un-proxied—for example, if you need the client source IP address to be preserved.
  • You need to load balance TCP, UDP, ESP, GRE, ICMP, and ICMPv6 traffic, or you need to load balance a TCP port that isn't supported by other load balancers.
  • It is acceptable to have SSL traffic decrypted by your backends instead of by the load balancer. The passthrough Network Load Balancer cannot perform this task. When the backends decrypt SSL traffic, there is a greater CPU burden on the VMs.
  • You are able to manage the backend VM's SSL certificates yourself. Google-managed SSL certificates are only available for proxy load balancers.
  • You have an existing setup that uses a passthrough load balancer, and you want to migrate it without changes.

Proxy Network Load Balancer can help with connection reuse (similar to ALB but it still operates at the TCP layer rather than HTTP/HTTPS) by maintaining and reusing connections between the load balancer and nginx. This could be a useful alternative if you need a balance between Layer 4 performance and connection reuse capabilities.

Other relevant references:

How to Set Up NGINX Load Balancing: A Step-by-Step Guide

NGINX Docs

I hope the information above is helpful.

 

View solution in original post

2 REPLIES 2

Hi @gavinX,

Welcome to Google Cloud Community!

Application Load Balancers do support connection reuse, they keep a connection pool and, when a subsequent request arrives from the same client IP address and port, they try to reuse an existing connection to the backend(nginx). When a client makes a request to the ALB, It avoids the need to establish a new connection each time a client sends a request. This helps in reducing the overhead of establishing new connections.

For Network Load Balancers, which serves at a lower level (Layer 4), the main function is traffic distribution according to IP and port. Unlike an ALB, they do not automatically maintain the client-level connection state. It forwards each individual TCP connection between the client and the backend service. This means that for each incoming request, a new TCP connection may be established between NLB and nginx.

You'd use a passthrough Network Load Balancer in the following circumstances:

  • You need to forward original client packets to the backends un-proxied—for example, if you need the client source IP address to be preserved.
  • You need to load balance TCP, UDP, ESP, GRE, ICMP, and ICMPv6 traffic, or you need to load balance a TCP port that isn't supported by other load balancers.
  • It is acceptable to have SSL traffic decrypted by your backends instead of by the load balancer. The passthrough Network Load Balancer cannot perform this task. When the backends decrypt SSL traffic, there is a greater CPU burden on the VMs.
  • You are able to manage the backend VM's SSL certificates yourself. Google-managed SSL certificates are only available for proxy load balancers.
  • You have an existing setup that uses a passthrough load balancer, and you want to migrate it without changes.

Proxy Network Load Balancer can help with connection reuse (similar to ALB but it still operates at the TCP layer rather than HTTP/HTTPS) by maintaining and reusing connections between the load balancer and nginx. This could be a useful alternative if you need a balance between Layer 4 performance and connection reuse capabilities.

Other relevant references:

How to Set Up NGINX Load Balancing: A Step-by-Step Guide

NGINX Docs

I hope the information above is helpful.

 

thanks @diannemcm  👍👍👍

May I ask, does reusing connections  enable default for Proxy Network Load Balancer . Or how can I enable connections reuse. thanks.