1. Overview
    1. Enables users to terminate SSL (TLS) connections at the load balancing layer, and balance the connections across backend instances using SSL (recommended) or TCP protocols
    2. SSL Proxy Load Balancing is intended for non-HTTP(S) traffic
    3. SSL Proxy Load Balancing supports both IPv4 and IPv6 addresses for client traffic
    4. Client IPv6 requests are terminated at the load balancing layer, and then proxied over IPv4 to VMs
    5. SSL Proxy Load Balancing is a load balancing service that can be deployed globally
    6. Backends can be deployed in multiple regions, and the load balancer automatically directs traffic to the closest region that has capacity
    7. If the closest region is at capacity, the load balancer automatically directs new connections to another region with available capacity
    8. Existing user connections remain in the current region
    9. Global load balancing requires the Premium Tier of Network Service Tiers, which is the default tier, otherwise, load balancing is handled regionally
    10. For the best security, use end-to-end encryption for SSL Proxy Load Balancing deployment by configuring backend service to accept traffic over SSL
    11. Ensures that the client traffic decrypted at the SSL Proxy Load Balancing layer is encrypted again before being sent to the backend instances
    12. End-to-end encryption requires certificates and keys on VMs so they can perform SSL processing
  2. Benefits
    1. Intelligent routing. The load balancer can route requests to backend locations where there is capacity
    2. In contrast, L3/L4 load balancer route to regional backends without considering capacity
    3. Better utilization of backends. SSL processing can be very CPU-intensive if the ciphers used are not CPU efficient
    4. To maximize CPU performance, use ECDSA SSL certificates and TLS 1.2, and prefer the ECDHE-ECDSA-AES128-GCM-SHA256 cipher suite for SSL between the load balancer and backend instances
    5. Certificate management. Customer-facing SSL certificates can be either certificates obtained and managed (self-managed certificates) by the customer, or certificates that Google obtains and manages for the customer (Google-managed certificates)
    6. Users only need to provision certificates on the load balancer
    7. On VMs, simplify management by using self-signed certificates
    8. Security patching. If vulnerabilities arise in the SSL or TCP stack, Google applies patches at the load balancer automatically to keep VMs safe
    9. SSL Proxy Load Balancing support for the following ports: 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, and 5222
    10. When using Google-managed SSL certificates with SSL Proxy Load Balancing, the frontend port for traffic must be 443 to enable the Google-managed SSL certificates to be provisioned and renewed
    11. SSL policies. SSL policies provides the ability to control the features of SSL that the SSL proxy load balancer negotiates with clients
    12. SSL Proxy Load Balancing can handle HTTPS, but Google does not recommend this. Use HTTP(S) Load Balancing for HTTPS traffic
    13. SSL proxy load balancers do not support client certificate-based authentication, also known as mutual TLS authentication
  3. Network tier behaviour
    1. SSL Proxy Load Balancing is a global service with Premium Tier.
    2. You can have only one backend service, and it can have backends in multiple regions
    3. With Standard Tier, TCP Proxy Load Balancing is a regional service
    4. Its backends must all be located in the region used by the load balancer's external IP address and forwarding rule
  4. Traffic allocation
    1. When a client sends a request, the load balancing service determines the approximate origin of the request from the source IP address
    2. The load balancing service determines the locations of the backends owned by the backend service, their overall capacity, and their overall current usage
    3. If the closest backend instances to the user have available capacity, the request is forwarded to that closest set of backends
    4. Incoming requests to the given region are distributed evenly across all available backend instances in that region.
    5. At very small loads, the distribution might appear to be uneven
    6. If there are no healthy backend instances with available capacity in a given region, the load balancer instead sends the request to the next closest region with available capacity
  5. TLS termination
    1. The SSL proxy load balancer terminates TLS in locations that are distributed globally, so as to minimize latency between clients and the load balancer
    2. If geographic control over where TLS is terminated is required, use Network Load Balancing instead, and terminate TLS on backends that are located in regions appropriate to the customer's needs
  6. Open ports
    1. The SSL 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 (GFEs)
    4. The firewall rules block traffic from the GFEs to the backend instances, but do not block incoming traffic to the GFEs
    5. The SSL 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 SSL proxy load balancers
    8. External forwarding rules, which are used in the definition of an SSL load balancer, can only reference TCP ports 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, and 5222
    9. Traffic with a different TCP destination port is not forwarded to the load balancer's backend
  7. HTTP(S) Load Balancing functionality
    1. Negotiates HTTP/2 and SPDY/3.1
    2. Rejects invalid HTTP requests or responses
    3. Forwards requests to different VMs based on URL host and path
    4. Integrates with Cloud CDN
    5. Spreads the request load more evenly among backend instances, providing better backend utilization
    6. HTTPS load balances each request separately, whereas SSL Proxy Load Balancing sends all bytes from the same SSL or TCP connection to the same backend instance
    7. SSL Proxy Load Balancing can be used for other protocols that use SSL, such as WebSockets and IMAP over SSL