[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-04。"],[],[],null,["# Cloud Load Balancing resource model\n\nA load balancer is a system composed of multiple interacting components. There\nisn't a single API resource that represents a load balancer. Instead, multiple\ncomponents work together to distribute incoming traffic across multiple backends.\n\nThe following diagram shows the core components of an Application Load Balancer,\na proxy Network Load Balancer, and a passthrough Network Load Balancer. \n\n### Application load balancer\n\n[](/static/load-balancing/images/overview/components_application_load_balancer.svg) Components of an Application Load Balancer (click to enlarge).\n\n### Proxy network load balancer\n\n[](/static/load-balancing/images/overview/components_proxy_network_load_balancers.svg) Components of a proxy Network Load Balancer (click to enlarge).\n\n### Passthrough network load balancer\n\n[](/static/load-balancing/images/overview/components_passthrough_network_load_balancers.svg) Components of a passthrough Network Load Balancer (click to enlarge).\n\nThis section provides a high-level overview of the key components of a load\nbalancer, starting from the point where traffic reaches the load balancer to\nthe stage where it is routed to the backend resource. For a deeper understanding\nof each load balancer component, refer to the page linked in each section.\n\nForwarding rule\n---------------\n\nA forwarding rule specifies an IP address, an IP protocol, and one or more ports\non which the load balancer accepts traffic. The forwarding rule and its attached\nIP address represent the frontend of a Google Cloud load balancer.\n\nFor more information, see [Forwarding rules overview](/load-balancing/docs/forwarding-rule-concepts).\n\nTarget proxy\n------------\n\nTarget proxies terminate incoming connections from clients and create new\nconnections from the load balancer to the backends.\n\n- The first connection originates from the client and is terminated at the\n target proxy of the load balancer.\n\n- The second connection starts at the target proxy and ends at the backend\n instance, which handles the client request.\n\nThe first connection is terminated either in a Google Front End (GFE) or in a\nspecially designated subnet known as the proxy-only subnet, which is reserved\nexclusively for Envoy proxies. To know whether a load balancer is GFE-based or\nEnvoy-based, see [Underlying technologies of Google Cloud load\nbalancers](/load-balancing/docs/load-balancing-overview#tech-gclb).\n\nTarget proxies are used only by proxy-based load balancers such as\nApplication Load Balancers and proxy Network Load Balancers. For these types of load\nbalancers, responses from the backend instances are sent back to the target\nproxy rather than directly to the client.\n\nFor more information, see [Target proxies](/load-balancing/docs/target-proxies).\n\nProxy-only subnet\n-----------------\n\nA proxy-only subnet provides a pool of IP addresses that are reserved\nexclusively for Envoy proxies used by Google Cloud load balancers. The proxies\nterminate incoming connections and then create new connections to the backend.\n\nFor more information, see [Proxy-only subnets for Envoy-based load balancers](/load-balancing/docs/https#proxy-only-subnet)\n\nSSL certificates\n----------------\n\nAlso known as Transport Layer Security (TLS) certificates, SSL certificates\nfacilitate secure communication between clients and load balancers. Proxy-based\nload balancers whose forwarding rules reference a target HTTPS proxy or a target\nSSL proxy require a private key and SSL certificate as part of the load\nbalancer's target proxy configuration.\n\nFor more information, see [SSL certificates](/load-balancing/docs/ssl-certificates).\n\nURL map\n-------\n\nUpon terminating the connection, the target HTTP(S) proxy uses the URL map to\ndecide where to route the new request (the second connection as stated in the\n[Target proxy](#target-proxy) section). The URL map routes the request to either\nthe backend service or the backend bucket. URL maps are only used by\nApplication Load Balancers. As Application Load Balancers operate at Layer 7 of the\nOSI model, they can make routing decisions based on HTTP attributes, such as\ndomain name, request path, and query parameters.\n\nFor more information, see [URL maps](/load-balancing/docs/url-map-concepts).\n\nBackend service\n---------------\n\nA backend service defines how your load balancer distributes traffic. The\nbackend service configuration contains a set of values, such as the protocol\nused to connect to backends, various distribution and session settings, health\nchecks, and timeouts.\n\nThese settings provide fine-grained control over how your load balancer behaves\nand let you direct traffic to the correct backends, which can be either VM\ninstance groups or [network endpoint groups (NEGs)](/load-balancing/docs/negs).\n\nFor more information, see [Backend services overview](/load-balancing/docs/backend-service#balancing-mode).\n\nBackend bucket\n--------------\n\nIf your workload serves *static content* using the HTTP(S) protocol, you can use\na [Cloud Storage bucket](/storage/docs/buckets) to store static\ncontent, and then use a [backend\nbucket](/load-balancing/docs/https/ext-load-balancer-backend-buckets) to route\nrequests to it.\n\nHealth checks\n-------------\n\nWhen you configure a load balancer's backend service, you need to specify one or\nmore health checks for its backends. A health check, as the name suggests,\ndetermines whether the backend instances of the load balancer are healthy. This\ndetermination is based on the ability of the backend to respond to incoming\ntraffic. The traffic that a backend needs to respond to depends on the type of\nthe load balancer. You can create health checks using both [Layer 7 and Layer 4\nprotocols](/load-balancing/docs/health-check-concepts#categories_protocols_ports)\nto monitor load balanced instances.\n\nFirewall rules\n--------------\n\nFor health checks to work, you must create ingress `allow` firewall rules that allow health check probes to reach your backends.\n\nLoad balancers based on Google Front Ends require an ingress allow firewall rule\nthat permits traffic from the [CIDRs of Google Front End](/load-balancing/docs/health-check-concepts#ip-ranges) to connect to your\nbackends. Load balancers based on the open source Envoy proxy require an ingress\n`allow` firewall rule that permits traffic from the *proxy-only subnet* to reach\nthe backend instances.\n\nFor more information, see [Firewall rules](/load-balancing/docs/firewall-rules).\n\nBackends\n--------\n\nBackends are the final destination of load-balanced traffic.\n\nDifferent load balancers support different types of backends. When you add a\nbackend to the backend service, you specify a *balancing mode*. This mode\nevaluates the backend's capacity to handle new requests and determines how\ntraffic is distributed among the backends.\n\nFor more information, see [Backends](/load-balancing/docs/backend-service#backends).\n\nWhat's next\n-----------\n\n- To help you determine which Google Cloud load balancer best meets your needs, see [Choose a load balancer](/load-balancing/docs/choosing-load-balancer).\n- To see a comparative overview of the load-balancing features offered by Cloud Load Balancing, see [Load balancer feature\n comparison](/load-balancing/docs/features)."]]
