1. Concepts
   1. Google Cloud TCP Proxy Load Balancing allows users to use a single IP address for all users around the world
   2. The TCP proxy load balancer automatically routes traffic to the instances that are closest to the user
   3. Global load balancing requires use of the Premium Tier of Network Service Tiers, which is the default tier, otherwise, load balancing is handled regionally
   4. TCP Proxy Load Balancing is intended for non-HTTP traffic
   5. For HTTP traffic, use HTTP Load Balancing instead
   6. For proxied SSL traffic, use SSL Proxy Load Balancing
   7. TCP Proxy Load Balancing supports both IPv4 and IPv6 addresses for client traffic
   8. Client IPv6 requests are terminated at the load balancing layer, then proxied over IPv4 to your backends
2. Overview
   1. When using TCP Proxy Load Balancing for TCP traffic, users can terminate customers’ TCP sessions at the load balancing layer, then forward the traffic to virtual machine instances using TCP or SSL
   2. TCP Proxy Load Balancing can be configured as a global load balancing service
   3. With this configuration, users can deploy instances in multiple regions, and global load balancing automatically directs traffic to the region closest to the user
   4. If a region is at capacity, the load balancer automatically directs new connections to another region with available capacity
   5. Existing user connections remain in the current region
3. Advantages
   1. Load balancer can route requests to backend locations where there is capacity
   2. In contrast, an L3/L4 load balancer must route to regional backends without paying attention to capacity
   3. Use of smarter routing allows provisioning at N+1 or N+2 instead of x*N
   4. Security patching — if vulnerabilities arise in the TCP stack, Cloud Load Balancing applies patches at the load balancer automatically to keep instances safe
   5. TCP Proxy Load Balancing supports the following ports: 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, 5222
4. Network tier behavior
   1. TCP Proxy Load Balancing is a global service when the Premium Network Service Tier is used
   2. Supports more than one backend service in a region, and backend services in more than one region, via the same global load balancer
5. Traffic allocation
   1. When a user request comes in, the load balancing service determines the approximate origin of the request from the source IP address
   2. The load balancing service knows the locations of the instances owned by the backend service, their overall capacity, and their overall current usage
   3. If the closest instances to the user have available capacity, then the request is forwarded to that closest set of instances
   4. Incoming requests to the given region are distributed evenly across all available backend services and instances in that region
   5. At very small loads, the distribution may appear to be uneven
   6. If there are no healthy instances with available capacity in a given region, the load balancer instead sends the request to the next closest region with available capacity
   7. TCP Proxy Load Balancing is a regional service when the Standard Network Service Tier is used
   8. Its backend instance groups must all be located in the region used by the load balancer's external IP address and forwarding rule
6. Forwarding rules and addresses
   1. Forwarding rules route traffic by IP address, port, and protocol to a load balancing configuration consisting of a target proxy and one or more backend services
   2. Each forwarding rule provides a single IP address that can be used in DNS records for applications
   3. No DNS-based load balancing is required
   4. Either reserve a static IP address to be used or let Cloud Load Balancing assign one
   5. Google recommends reserving a static IP address: otherwise, update DNS record with the newly-assigned ephemeral IP address whenever a forwarding rule is deleted or create a new one
7. Target proxies
   1. TCP Proxy Load Balancing terminates TCP connections from the client and creates new connections to the instances
   2. By default, the original client IP address and port information is not preserved
   3. Users can preserve this information using PROXY protocol
   4. The target proxies route incoming requests directly to backend services
8. Backend services
   1. Backend services direct incoming traffic to one or more attached backends
   2. Each backend is composed of an instance group or network endpoint group and serving capacity metadata.
   3. Backend serving capacity can be based on CPU or requests per second (RPS)
   4. Each backend service specifies the health checks to perform for the available instances
   5. To ensure minimal interruptions to users, enable connection draining on backend services
   6. Such interruptions might happen when an instance is terminated, removed manually, or removed by an autoscaler
9. Protocol to the backends
   1. When a backend service for the TCP Proxy load balancer is configured, set the protocol that the backend service uses to communicate with the backends.
   2. Choose either SSL or TCP
   3. The load balancer uses only the protocol specified, and will not attempt to negotiate a connection with the other protocol
10. Backend buckets
    1. Backend buckets direct incoming traffic to Google Cloud Storage buckets instead of instance groups
    2. Buckets are containers that hold data.
    3. Use buckets as common storage between VM instances, Google App Engine, and other cloud services
    4. Use a storage bucket to store large amount of data that doesn't need to be locally stored on a single VM instance
11. Firewall rules
    1. Firewall rules allow traffic to reach instances
    2. Configure firewall rules to allow traffic from both the load balancer and the health checker
    3. Use a single firewall rule if the rule allows traffic on the port that the global forwarding rule uses
    4. And the health checker uses the same port
    5. If the health checker uses a different port, create a separate firewall rule for that port
    6. Firewall rules block and allow traffic at the instance level, not at the edges of the network
    7. Firewall rules cannot prevent traffic from reaching the load balancer itself
    8. Google Cloud Platform uses a large range of IP addresses, which change over time
12. Termination
    1. With TCP proxy, traffic coming over a TCP connection is terminated at the load balancing layer, then proxied to the closest available instance group
13. Session affinity
    1. Session affinity sends all requests from the same client to the same virtual machine instance, if the instance is healthy and has capacity
    2. TCP Proxy Load Balancing offers client IP affinity, which forwards all requests from the same client IP address to the same instance
14. Open ports
    1. TCP proxy load balancers are reverse proxy load balancers
    2. The load balancer terminates incoming connections, and then opens new connections from the load balancer to the backends
    3. The reverse proxy functionality is provided by the Google Front Ends (GFE)
    4. The firewall rules defined by the customer block traffic from the GFEs to the backends, but do not block incoming traffic to the GFEs
    5. The TCP proxy load balancers have a number of open ports to support other Google services that run on the same architecture
    6. If a security or port scan is run against the external IP address of the load balancer, additional ports appear to be open
    7. This does not affect TCP proxy load balancers
    8. External forwarding rules, which are used in the definition of an SSL load balancer, can only reference a specific set of ports
    9. Traffic with a different TCP destination port is not forwarded to the load balancer's backend