1. Load balancing using multiple backend
   1. One common use case is load balancing traffic among services
   2. External IPv4 and IPv6 clients can request video, API, and image content by using the same base URL, with the paths /api, /video, and /images
   3. The load balancer evaluates incoming request according to the URL map and sends the request to the correct service
   4. On each backend service, Cloud CDN or Google Cloud Armor can be enabled
   5. When Cloud CDN is enabled, Google Cloud Armor cannot be enabled
   6. On backend buckets, Cloud CDN is supported, but not Google Cloud Armor
2. Three-tier web services
   1. External HTTP(S) Load Balancing supports traditional three-tier web services
   2. Web tier traffic enters from the internet and is load balanced by using an external HTTP(S) load balancer
   3. The application tier is scaled by using a regional internal HTTP(S) load balancer
   4. The database tier is scaled by using an internal TCP/UDP load balancer
3. HTTP Load Balancing
   1. A forwarding rule directs incoming requests to a target HTTP proxy
   2. The target HTTP proxy checks each request against a URL map to determine the appropriate backend service for the request
   3. The backend service directs each request to an appropriate backend based on serving capacity, zone, and instance health of its attached backends
   4. The health of each backend instance is verified by using an HTTP health check, an HTTPS health check, or an HTTP/2 health check
   5. If the backend service is configured to use an HTTPS or HTTP/2 health check, the request is encrypted on its way to the backend instance
   6. Sessions between the load balancer and the instance can use the HTTP, HTTPS, or HTTP/2 protocol
   7. If HTTPS or HTTP/2 is used, each backend instance must have an SSL certificate
4. HTTPS Load Balancing
   1. An HTTPS load balancer uses a target HTTPS proxy instead of a target HTTP proxy
   2. An HTTPS load balancer requires at least one signed SSL certificate installed on the target HTTPS proxy for the load balancer
   3. Self-managed or Google-managed SSL certificates can be used
   4. The client SSL session terminates at the load balancer
   5. HTTPS load balancers support the QUIC transport layer protocol
5. Client communications
   1. Clients can communicate with the load balancer using the HTTP 1.1 or HTTP/2 protocol
   2. When HTTPS is used, modern clients default to HTTP/2
   3. This is controlled on the client, not on the HTTPS load balancer
   4. Users cannot disable HTTP/2 by making a configuration change on the load balancer
   5. Users can configure some clients to use HTTP 1.1 instead of HTTP/2, for example, with curl, use the --http1.1 parameter
   6. HTTPS load balancers do not support client certificate-based authentication, also known as mutual TLS authentication
6. Open ports
   1. External HTTP(S) 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 backends, but do not block incoming traffic to the GFEs
   5. The external HTTP(S) 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 performed against the external IP address of a Google Cloud external HTTP(S) load balancer, additional ports appear to be open
   7. External forwarding rules, which are used in the definition of an external HTTP(S) load balancer, can only reference TCP ports 80, 8080, and 443
   8. Traffic with a different TCP destination port is not forwarded to the load balancer's backend
7. 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, URL map, and one or more backend services
   2. Each forwarding rule provides a single IP address that can be used in DNS records for the application
   3. No DNS-based load balancing is required
   4. The IP address can be specified or Cloud Load Balancing assign
   5. The forwarding rule for an HTTP load balancer can only reference TCP ports 80 and 8080
   6. The forwarding rule for an HTTPS load balancer can only reference TCP port 443
   7. The type of forwarding rule required by external HTTP(S) load balancers depends on the load balancer Network Service Tier
   8. The external HTTP(S) load balancers in the Premium Tier use global external forwarding rules
   9. The external HTTP(S) load balancers in the Standard Tier use regional external forwarding rules
8. Target proxies
   1. Target proxies terminate HTTP(S) connections from clients
   2. One or more forwarding rules direct traffic to the target proxy, and the target proxy consults the URL map to determine how to route traffic to backends
9. URL maps
   1. URL maps define matching patterns for URL-based routing of requests to the appropriate backend services
   2. A default service is defined to handle any requests that does not match a specified host rule or path matching rule
   3. In some situations, a user might not define any URL rules and rely only on the default service
   4. For content-based routing of traffic, the URL map allows users to divide traffic by examining the URL components to send requests to different sets of backends
10. SSL certificates
    1. HTTPS Load Balancing requires one or more SSL certificates on the target HTTPS proxy
    2. SSL certificates are used by target HTTPS proxies to authenticate communications between the load balancer and the client
    3. These can be self-managed or Google-managed SSL certificates
    4. If using HTTPS or HTTP/2 from the load balancer to the backends, SSL certificates must be installed on each VM instance
    5. For external HTTP(S) Load Balancing, Google encrypts traffic between the load balancer and backend instances
    6. SSL certificate resources are not required on individual VM instances
11. SSL policies
    1. SSL policies provide the ability to control the features of SSL that HTTPS load balancer negotiates with HTTPS clients.
    2. By default, HTTPS Load Balancing uses a set of SSL features that provides good security and wide compatibility
    3. Some applications require more control over which SSL versions and ciphers are used for their HTTPS or SSL connections
    4. Define SSL policies that control the features of SSL the load balancer negotiates and associates with the target HTTPS proxy
12. TLS termination
    1. The HTTPS 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 Google Cloud Network Load Balancing instead, and terminate TLS on backends that are located in the appropriate regions
13. Backend services
    1. Backend services provide configuration information to the load balancer
    2. An external HTTP(S) load balancer must have at least one backend service and can have multiple backend services
    3. Load balancers use the information in a backend service to direct incoming traffic to one or more attached backends
    4. The backends of a backend service can be either instance groups or network endpoint groups (NEGs) , but not a combination of both
    5. When a backend instance group or NEG is added, a balancing mode is specified, which defines a method for distributing requests and a target capacity
    6. HTTP(S) Load Balancing supports Cloud Load Balancing Autoscaler for autoscaling instance groups in a backend service
    7. Connection draining can be enabled on backend services to ensure minimal interruption when an instance is terminated, removed manually, or removed by an autoscaler
    8. HTTP(S) Load Balancing is a global service when the Premium Network Service Tier is used
    9. Users may have more than one backend service in a region, and may create backend services in more than one region, all serviced by the same global load balancer
    10. 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.
    11. At very small loads, the distribution may appear to be uneven
    12. Incoming requests to the given region are distributed evenly across all available backend services and instances in that region
    13. If the closest instances to the user have available capacity, the request is forwarded to that closest set of instances
    14. The load balancing service knows the locations of instances owned by the backend service, their overall capacity, and their overall current usage
    15. When a user request comes in, the load balancing service determines the approximate origin of the request from the source IP address
    16. HTTP(S) Load Balancing is a regional service when the Standard Network Service Tier is used
    17. Its backend instance groups or NEGs must all be located in the region used by the load balancer's external IP address and forwarding rule
14. Health checks
    1. Each backend service also specifies which health check is performed against each available instance
    2. For the health check probes to function correctly, create a firewall rule that allows traffic from 130.211.0.0/22 and 35.191.0.0/16 to reach instances
15. Protocol to the backends
    1. When a backend service is configured for external HTTP(S) load balancer, set the protocol that the backend service uses to communicate with the backends
    2. Choose HTTP, HTTPS, or HTTP/2
    3. The load balancer uses only the protocol that is specified.
    4. The load balancer does not fall back to one of the other protocols if it is unable to negotiate a connection to the backend with the specified protocol
    5. If HTTP/2 is used, TLS must be selected
    6. HTTP/2 without encryption is not supported
    7. Although not required, it is a best practice to use a health check whose protocol matches the protocol of the backend service
16. Using gRPC
    1. gRPC is an open-source framework for remote procedure calls
    2. It is based on the HTTP/2 standard
    3. Use cases for gRPC include low latency, highly scalable, distributed systems
    4. Also while developing mobile clients that communicate with a cloud server
    5. As well as designing new protocols that must be accurate, efficient, and language independent
    6. Layered design to enable extension, authentication, and logging is also a use case
    7. To use gRPC with Google Cloud applications, requests must be proxied end-to-end over HTTP/2
17. Backend buckets
    1. Backend buckets direct incoming traffic to Cloud Storage buckets
    2. A load balancer can be configured to send traffic with a path of /static to a storage bucket and all other requests to your other backends
18. Firewall rules
    1. A firewall rule that allows traffic from 130.211.0.0/22 and 35.191.0.0/16 must be configured to reach instances
    2. These are IP address ranges that the load balancer uses to connect to backend instances
    3. This rule allows traffic from both the load balancer and the health checker
    4. The rule must allow traffic on the port that the global forwarding rule has been configured to use, and t
    5. The health checker should be configured to use the same port
    6. If the health checker uses a different port, another firewall rule must be configured for that port
    7. Firewall rules block and allow traffic at the instance level, not at the edges of the network
    8. They cannot prevent traffic from reaching the load balancer itself
19. Return path
    1. Google Cloud uses special routes not defined in the VPC network for health checks
20. Load distribution algorithm
    1. External HTTP(S) Load Balancing supports two balancing modes for backends
    2. RATE for instance group backends or NEGs and UTILIZATION for instance group backends
    3. The backends of a backend service can be either instance groups or NEGs, but not a combination of both
    4. When a backend instance group or NEG is added, specify a balancing mode, which defines a method for distributing requests and a target capacity
    5. For instance group backends, use either UTILIZATION or RATE balancing mode
    6. For NEGs, you must use RATE
    7. When RATE balancing mode is used, specify a target maximum number of requests (queries) per second (RPS, QPS)
    8. This target is used to define when an instance or endpoint is at capacity
    9. The target maximum RPS/QPS can be exceeded if all backends are at or above capacity
    10. When an external HTTP(S) load balancer is in Premium Tier, requests sent to the load balancer are delivered to backend instance groups or NEGs in the region closest to the user, if a backend in that region has available capacity
    11. When an external HTTP(S) load balancer is in Standard Tier, its backend instance groups or NEGs must all be located in the region used by the load balancer's external IP address and forwarding rule
    12. After a region is selected an external HTTP(S) load balancer tries to balance requests as evenly as possible within the zones of a region, subject to session affinity
    13. When multiple NEGs or zonal instance groups are configured in the same region or one or more regional managed instance groups, the external HTTP(S) load balancer behaves this way
    14. When multiple NEGs or zonal instance groups are configured, within a zone, an external HTTP(S) load balancer tries to balance requests by using a round-robin algorithm, subject to session affinity.
21. Session affinity
    1. Session affinity provides a best-effort attempt to send requests from a particular client to the same backend for as long as the backend is healthy and has the capacity, according to the configured balancing mode
    2. Google Cloud HTTP(S) Load Balancing offers
       1. NONE. Session affinity is not set for the load balancer
       2. Client IP affinity sends requests from the same client IP address to the same backend
       3. Generated cookie affinity sets a client cookie when the first request is made, and then sends requests with that cookie to the same backend
    3. When using session affinity, RATE balancing mode is recommended over UTILIZATION.
    4. Session affinity works best with balancing mode set to requests per second (RPS)
22. WebSocket proxy support
    1. HTTP(S) Load Balancing has native support for the WebSocket protocol with HTTP or HTTPS, not HTTP/2, as the protocol to the backend
    2. Backends that use the WebSocket protocol to communicate with clients can use the external HTTP(S) load balancer as a frontend for scale and availability
    3. The load balancer does not need any additional configuration to proxy WebSocket connection
    4. The WebSocket protocol, which is defined in RFC 6455, provides a full-duplex communication channel between clients and servers
    5. The channel is initiated from an HTTP(S) request.
    6. When HTTP(S) Load Balancing recognizes a WebSocket Upgrade request from an HTTP(S) client and the request is followed by a successful Upgrade response from the backend instance
    7. The load balancer proxies bidirectional traffic for the duration of the current connection
    8. If the backend does not return a successful Upgrade response, the load balancer closes the connection
    9. The timeout for a WebSocket connection depends on the configurable response timeout of the load balancer, which is 30 seconds by default
    10. The timeout is applied to WebSocket connections regardless of whether they are in use
    11. If either a client IP is configured or cookie session affinity generated for the external HTTP(S) load balancer, all WebSocket connections from a client are sent to the same backend instance, if the instance continues to pass health checks and has capacity.
    12. The WebSocket protocol is supported with Ingress
23. QUIC protocol
    1. HTTPS Load Balancing supports the QUIC protocol in connections between the load balancer and the clients
    2. QUIC is a transport layer protocol that provides congestion control similar to TCP and the security equivalent to SSL/TLS for HTTP/2, with improved performance
    3. QUIC allows faster client connection initiation, eliminates head-of-line blocking in multiplexed streams, and supports connection migration when a client's IP address changes
    4. QUIC affects connections between clients and the load balancer, not connections between the load balancer and its backends