GCP提供两种负载均衡器，分别是网络层和HTTP（s）层，前者作用于第四层，后者作用于第七层。
还有一份文件说明即使是HTTP流量也可以由网络负载均衡器进行负载平衡。这会稍微让人感到困惑，不知道在GCP中为Web应用程序选择哪个负载均衡器更好。在选择项目所需的负载均衡器之前最好先了解它们之间的区别。
基于工作流程、设置、基于区域/区域组的选项、会话亲和力和其他设置，它们之间的区别是什么？
GCP中网络负载均衡器和HTTP(s)负载均衡器之间有哪些区别？
google-cloud-platformgoogle-compute-engineload-balancinggoogle-cloud-network-load-balancergoogle-cloud-http-load-balancer
27
- Lakshman Diwaakar
2
5我不明白为什么会有负评。这个问题太宽泛了吗？网络与HTTP（s）的区别，我实在想不出更直接的问题了。此外，在stackoverflow上也没有与此相同的重复问题。 - Lakshman Diwaakar
1我看不到这里的问题。问号在哪里？ - Suma
3个回答
38
网络负载均衡器和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负载均衡器说明的链接。
- Lakshman Diwaakar
8
一般而言，以下是网络负载均衡器和HTTP负载均衡器之间的区别。
网络负载均衡器（第4层）：基于网络变量（如IP地址和目标端口）分配流量。它是第4层（TCP）及以下的负载均衡器，不考虑应用程序层面的内容类型、Cookie数据、自定义头、用户位置或应用程序行为等任何因素。它是无上下文的，只关注其指导的数据包中包含的网络层信息。
应用负载均衡器（第7层）：基于从网络层到应用层的多个变量分配请求。它是上下文感知的，并且可以轻松地根据任何单一变量或多个变量来指导请求。应用程序的负载平衡基于其独特的行为，而不仅仅是服务器（操作系统或虚拟化层）信息。提供基于规则、基于主机或基于路径的路由HTTP和HTTPS流量的功能。与NLB类似，每个目标可以在不同的端口上。
两者之间的另一个区别很重要，因为网络负载平衡不能保证应用程序的可用性。这是因为它仅基于网络和TCP层变量做出决策，并且根本不了解应用程序。通常，网络负载均衡器将基于服务器响应ICMP ping或正确完成三向TCP握手的能力来确定“可用性”。应用负载均衡器则更深入，能够根据特定页面的成功HTTP GET以及内容是否符合基于输入参数的预期来确定可用性。
参考: https://medium.com/awesome-cloud/aws-difference-between-application-load-balancer-and-network-load-balancer-cb8b6cd296a4
两者之间的另一个区别很重要，因为网络负载平衡不能保证应用程序的可用性。这是因为它仅基于网络和TCP层变量做出决策，并且根本不了解应用程序。通常，网络负载均衡器将基于服务器响应ICMP ping或正确完成三向TCP握手的能力来确定“可用性”。应用负载均衡器则更深入，能够根据特定页面的成功HTTP GET以及内容是否符合基于输入参数的预期来确定可用性。
参考: https://medium.com/awesome-cloud/aws-difference-between-application-load-balancer-and-network-load-balancer-cb8b6cd296a4
- Vali7394
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接