Google cloud platform GCP中的网络和HTTP(s)负载平衡器有什么区别
GCP提供了两个负载平衡器,即网络和HTTP(s),前者在第4层上工作,后者在第7层上工作 还有一个文档说明,即使是HTTP流量也可以通过网络负载平衡器进行负载平衡。这稍微混淆了在GCP中为web应用选择哪个负载平衡器。在为项目选择一个之前,最好先了解差异Google cloud platform GCP中的网络和HTTP(s)负载平衡器有什么区别,google-cloud-platform,google-compute-engine,load-balancing,google-cloud-network-load-balancer,google-cloud-http-load-balancer,Google Cloud Platform,Google Compute Engine,Load Balancing,Google Cloud Network Load Balancer,Google Cloud Http Load Balancer,GCP提供了两个负载平衡器,即网络和HTTP(s),前者在第4层上工作,后者在第7层上工作 还有一个文档说明,即使是HTTP流量也可以通过网络负载平衡器进行负载平衡。这稍微混淆了在GCP中为web应用选择哪个负载平衡器。在为项目选择一个之前,最好先了解差异 基于工作流,设置,基于区域/区域,会话关联选项,以及其他设置,它们之间有什么区别?网络负载平衡器与HTTP(s)负载平衡器 +---------------------+------------------------------------
基于工作流,设置,基于区域/区域,会话关联选项,以及其他设置,它们之间有什么区别?网络负载平衡器与HTTP(s)负载平衡器
+---------------------+------------------------------------------+------------------------------------------------------+
| Category | Network Load Balancing (NLB) | HTTP(S) Load Balancing (HLB) |
+---------------------+------------------------------------------+------------------------------------------------------+
| 1. Region / | NLB supports only within a region. | HLB supports both within cross-region |
| Cross-Region | Does not support cross-region | load balancing. |
| | load balancing | |
+---------------------+------------------------------------------+------------------------------------------------------+
| 2. Load balancing | NLB is based on IP address, port | HLB is based only on HTTP and HTTPS |
| based on | and protocol type. Any TCP/UDP | protocols. |
| | traffic, even SMTP can be | |
| | load balanced. | |
+---------------------+------------------------------------------+------------------------------------------------------+
| 3. Packet | Packet inspection is possible and | HLB cannot inspect packets. |
| inspection | load balance based on packets | |
+---------------------+------------------------------------------+------------------------------------------------------+
| 4. Instance | No need of creating instance group. | Managed / UnManaged Instance group |
| Group | Target pools need to be created. | is necessary for creating HTTP / HTTPS |
| | Instance can be just tagged to the pool. | load balancer. |
| | Ideal for unmanaged instance group | |
| | where instances are non homogeneous. | |
+---------------------+------------------------------------------+------------------------------------------------------+
| 5. Workflow | Forwarding rules is the starting point. | This is quite complex in HTTP(s) load balancer. |
| | It directs the request to the | Global forwarding rulesroutes direct the request |
| | target pools from which compute | to target HTTP proxy, which in turn checks the |
| | engines will pick the request. | URL map to determine appropriate backend |
| | | services. These services in turn direct the request |
| | Forwarding rules -> target pool | to the instance group. |
| | -> instances | |
| | | |
| | | Global forwarding rules -> Target HTTP proxy -> |
| | | URL map -> Backend Sevices -> instance group |
+---------------------+------------------------------------------+------------------------------------------------------+
| 6. Types of | Basic network load balancer which | 1. Cross-region load balancer uses only one |
| load balancer | directs the request based on IP address, | global IP address and routes the request |
| | port and the protocol within the region. | to the nearest region. |
| | | |
| | | 2. Content-based load balancer is based |
| | | on the URL path. Different path rules need |
| | | different backend services. for eg: /video |
| | | and /static require two separate backend services. |
+---------------------+------------------------------------------+------------------------------------------------------+
| 7. Session affinity | Session affinity can be set, but only | 1. Client IP Affinity: This directs the same |
| | during the creation of target pool. | client ip to same backend instance by |
| | Once it is set, the value | computing hash of the IP. |
| | cannot be changed. | 2. Generated Cookie Affinity: Load balancer stores |
| | | cookie in clients and directs the same client to |
| | | same instance with the help of retrieved cookie. |
+---------------------+------------------------------------------+------------------------------------------------------+
| 8. Health check | Health check is optional, but network | Health can be verified by either using HTTP |
| | load balancing relies on HTTP Health | heath check or HTTPS health check. |
| | checks for determining instance health. | |
+---------------------+------------------------------------------+------------------------------------------------------+
上表基于我的观点。如果有任何不正确的地方或我遗漏了什么,请随时发表评论,我会将其添加到表格中
这里是关于在<强> GCP中设置<强> HTTP负载均衡器< /强>的说明,此外,我想指出在选择GCP中正确的负载均衡器(LB)时要考虑:
1) 全球与区域的对比2) 外部对内部
3) 交通类型
请同时查找有关这方面的更多信息。下面是网络负载平衡器和Http负载平衡器的区别 网络负载平衡器(第4层): 这是基于网络变量(如IP地址和目标端口)的流量分布。它是第4层(TCP)及以下,设计时不考虑应用层的任何内容,如内容类型、cookie数据、自定义头、用户位置或应用程序行为。它是无上下文的,只关心它所指向的数据包中包含的网络层信息 应用程序负载平衡器(第7层) 这是基于多个变量的请求分布,从网络层到应用层。它是上下文感知的,可以基于任何单个变量和变量的组合来引导请求。应用程序的负载平衡基于其特殊行为,而不仅仅是服务器(操作系统或虚拟化层)信息。提供了基于规则、基于主机或基于路径路由HTTP和HTTPS流量的能力。与NLB一样,每个目标可以位于不同的端口上 两者之间的另一个区别很重要,因为网络负载平衡不能保证应用程序的可用性。这是因为它的决策完全基于网络和TCP层变量,完全不了解应用程序。通常,网络负载平衡器将根据服务器响应ICMP ping或正确完成三向TCP握手的能力来确定“可用性”。应用程序负载平衡器更深入,不仅能够基于对特定页面的成功HTTP GET,而且能够基于输入参数验证内容是否符合预期,从而确定可用性
Ref:我不明白那些反对票。这个问题是否过于宽泛?网络Vs HTTP(s)。我想不出比这更直截了当的问题了。此外,stackoverflow中的同一个问题没有重复。我在这里看不到这个问题。问号在哪里?