TCP/UDP Load Balancer (Layer 4) in GCP - Step-by-Step Execution

Process Flow - TCP/UDP Load Balancer (Layer 4)

Client sends TCP/UDP request

↓

Load Balancer receives request

↓

Check backend service health

↓

Select healthy backend instance

↓

Forward request to backend instance

↓

Backend instance processes request

↓

Response sent back through Load Balancer

↓

Client receives response

The load balancer receives TCP/UDP requests from clients, checks backend health, forwards requests to healthy backends, and returns responses to clients.

Execution Sample

GCP

resource "google_compute_forwarding_rule" "tcp_udp_lb" {
  name       = "tcp-udp-lb-rule"
  load_balancing_scheme = "EXTERNAL"
  port_range = "80-81"
  target     = google_compute_target_pool.tp.id
  ip_protocol = "TCP"
}

resource "google_compute_target_pool" "tp" {
  name = "target-pool"
  instances = [google_compute_instance.instance1.id]
}

Defines a TCP load balancer forwarding rule that listens on ports 80-81 and forwards traffic to a target pool of backend instances.

Process Table

Step	Action	Input	Load Balancer Decision	Backend Response
1	Client sends TCP request	Client IP: 10.0.0.1, Port: 80	Receive request on port 80	No response yet
2	Load Balancer checks backend health	Target pool instances health status	Instance1 is healthy	No response yet
3	Load Balancer selects backend	Healthy instances: Instance1	Select Instance1	No response yet
4	Forward request to backend	Request forwarded to Instance1	Forwarded	Processing request
5	Backend processes request	Request received by Instance1	N/A	Response generated
6	Response sent back	Response from Instance1	Forward response to client	Client receives response
7	End of request cycle	No new requests	Idle, waiting for next request	No response

💡 Request cycle ends after response is sent back to client.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 6	Final
Client Request	None	Received	Received	Forwarded	Forwarded	None
Backend Health	Unknown	Healthy	Healthy	Healthy	Healthy	Healthy
Selected Backend	None	None	Instance1	Instance1	Instance1	None
Response	None	None	None	Processing	Sent	None

Key Moments - 3 Insights

Why does the load balancer check backend health before forwarding?

To avoid sending requests to unhealthy instances, ensuring reliable service. See execution_table step 2 where health is checked before selection.

What happens if no backend instances are healthy?

The load balancer cannot forward requests, so clients may get errors or timeouts. This is implied by the health check step in execution_table step 2.

Does the load balancer modify the TCP/UDP payload?

No, it only forwards packets at Layer 4 without changing payload content, as shown by forwarding actions in steps 3 and 4.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the load balancer select the backend instance?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Check the 'Load Balancer Decision' column in execution_table row for step 3.

According to variable_tracker, what is the state of 'Response' after step 4?

A None

B Processing

C Sent

D Forwarded

💡 Hint

Look at the 'Response' row and the column 'After Step 4' in variable_tracker.

If the backend health was unhealthy at step 2, what would change in the execution_table?

A Load balancer would select a different backend at step 3

B Request would be forwarded anyway at step 4

C Load balancer would not forward the request at step 4

D Client would receive response immediately at step 6

💡 Hint

Refer to key_moments about backend health and execution_table step 2 and 4.

Concept Snapshot

TCP/UDP Load Balancer (Layer 4) forwards client requests based on IP and port.
It checks backend instance health before forwarding.
Does not modify packet content, only routes traffic.
Commonly used for TCP/UDP protocols on specified ports.
In GCP, uses forwarding rules and target pools.
Ensures high availability by selecting healthy backends.

Full Transcript

A TCP/UDP Load Balancer works at Layer 4 of the network. It receives client requests on specific ports and forwards them to backend instances. Before forwarding, it checks if backend instances are healthy to avoid sending traffic to unhealthy servers. The load balancer does not change the content of the packets; it simply routes them. After the backend processes the request, the response is sent back through the load balancer to the client. This process ensures reliable and efficient distribution of network traffic. In Google Cloud Platform, this is configured using forwarding rules that listen on ports and target pools that group backend instances.

Practice

1. What is the primary function of a TCP/UDP Load Balancer in GCP?

easy

A. Store and cache static website content for faster delivery

B. Analyze HTTP headers to route requests based on URL paths

C. Encrypt data packets before sending them to clients

D. Distribute incoming TCP or UDP traffic evenly across backend servers

Solution

1. Step 1: Understand Layer 4 Load Balancing

   TCP/UDP Load Balancers operate at Layer 4, handling raw TCP or UDP traffic without inspecting application data.

2. Step 2: Identify the main role

   The main role is to distribute incoming network traffic evenly across multiple backend servers to balance load and improve availability.

3. Final Answer:

   Distribute incoming TCP or UDP traffic evenly across backend servers -> Option D

4. Quick Check:

   Layer 4 Load Balancer = Traffic distribution [OK]

Hint: Layer 4 means TCP/UDP traffic distribution only [OK]

Common Mistakes:

• Confusing Layer 4 with Layer 7 load balancing
• Thinking it inspects HTTP headers
• Assuming it caches content

2. Which GCP component is essential to define where TCP/UDP Load Balancer sends traffic?

easy

A. Cloud Storage Bucket

B. Forwarding Rule

C. Cloud Pub/Sub Topic

D. Cloud SQL Instance

Solution

1. Step 1: Identify GCP components for Load Balancing

   Forwarding rules in GCP specify the IP address, port, and protocol that the load balancer listens on.

2. Step 2: Understand traffic routing

   Forwarding rules direct incoming TCP/UDP traffic to the backend service or instance group.

3. Final Answer:

   Forwarding Rule -> Option B

4. Quick Check:

   Forwarding Rule = Traffic entry point [OK]

Hint: Forwarding Rule directs traffic to backends [OK]

Common Mistakes:

• Choosing unrelated services like Cloud Storage
• Confusing Pub/Sub with load balancing
• Selecting Cloud SQL which is a database

3. Given a TCP Load Balancer with 3 backend instances, if 300 connections arrive evenly, how many connections does each instance handle?

medium

A. 100 connections

B. 300 connections

C. 150 connections

D. 50 connections

Solution

1. Step 1: Understand even distribution

   The load balancer distributes connections evenly across all backend instances.

2. Step 2: Calculate connections per instance

   300 connections divided by 3 instances equals 100 connections per instance.

3. Final Answer:

   100 connections -> Option A

4. Quick Check:

   300 ÷ 3 = 100 [OK]

Hint: Divide total connections by backend count [OK]

Common Mistakes:

• Multiplying instead of dividing
• Ignoring even distribution assumption
• Choosing total connections as answer

4. You configured a TCP Load Balancer but backend instances are not receiving traffic. What is a common misconfiguration to check?

medium

A. Backend instances lack proper health checks

B. Forwarding rule uses HTTP protocol instead of TCP

C. Backend instances are in different cloud provider

D. Load balancer IP is not public

Solution

1. Step 1: Check health checks configuration

   Load balancer only sends traffic to healthy backends. Missing or failing health checks cause no traffic routing.

2. Step 2: Verify backend health status

   Ensure health checks are properly configured and passing for backend instances.

3. Final Answer:

   Backend instances lack proper health checks -> Option A

4. Quick Check:

   Health checks enable traffic routing [OK]

Hint: Always verify backend health checks first [OK]

Common Mistakes:

• Assuming protocol mismatch blocks traffic
• Ignoring health check failures
• Thinking IP must be public for internal load balancer

5. You want to design a highly available TCP Load Balancer in GCP that handles millions of connections. Which combination ensures scalability and fault tolerance?

hard

A. Use a global HTTP(S) Load Balancer with TCP backend services

B. Deploy multiple zonal TCP Load Balancers without health checks to reduce latency

C. Use a single regional TCP Load Balancer with multiple backend instance groups and health checks

D. Configure a single backend instance with autoscaling but no load balancer

Solution

1. Step 1: Understand GCP TCP Load Balancer types

   Regional TCP Load Balancers distribute traffic across multiple backend instance groups within a region, supporting health checks and autoscaling.

2. Step 2: Evaluate scalability and fault tolerance

   Multiple backend groups with health checks ensure traffic only goes to healthy instances, enabling fault tolerance and scaling to millions of connections.

3. Final Answer:

   Use a single regional TCP Load Balancer with multiple backend instance groups and health checks -> Option C

4. Quick Check:

   Regional LB + backends + health checks = scalable & fault tolerant [OK]

Hint: Regional LB + health checks = scalable, fault tolerant [OK]

Common Mistakes:

• Ignoring health checks reduces reliability
• Using HTTP(S) LB for TCP traffic is incorrect
• Single backend instance limits scalability