负载均衡几乎与全球互联网同时出现。传入的数据包、连接和请求从网络层到TCP到HTTP，通常在资源之间分布，以确保应用性能和可用性。
这些差异可能看起来微不足道，但实际上它们非常重要，因为这些将直接影响企业可以实现的部署模式类型。毕竟，如果企业对于HTTP没有可见性，就不能采用更多依赖于URI或内容类型的高级模式。
所有的负载均衡都需要决定转发分组/请求的位置，这就是网络、连接和应用程序负载均衡之间的区别变得重要的地方。每个人都根据可能导致或阻碍企业实施特定类型的部署模式的特征做出决策。
适当的网络负载均衡依赖于网络层信息。而源端和目标端IP以及TCP端口(在某些情况下)构成决策的基础。
当网络负载均衡服务收到请求时，它通常会散列源端IP和目标端IP(以及TCP端口)，然后选择目标资源。这个请求然后被发送到资源。
网络负载均衡具有作为所有负载均衡算法中最快决策者的优势，但它具有不能平衡流量的缺点。这意味着网络负载均衡(NLB)更关心路由流量，而不是跨资源平衡流量。它会进行尝试，但有些情况下会因为“超级代理”问题而失败。
当大量流量来自同一范围的网络地址时，就会出现超级代理问题。这会导致所有流量发送到相同的资源，因为散列变量之间没有足够的分化来分配多个资源。精明的开发人员会认识到这是一个冲突，这是基于哈希算法的常见问题。由于性能受到目标资源负载的影响，其冲突问题更加恶化。随着负载的增加(在任何系统上)，其性能会下降。
所以，如果企业打算使用这种消费，可能会经历糟糕的分布，并因此表现不佳。这是因为大多数企业流量都来自同一个范围的IP地址。然而，对于消费者来说，这不应该是一个问题。
企业也无法根据应用程序(或API)版本引导流量，也无法使用它来分割跨多个服务的API流量，因为它无法考虑基于HTTP的变量(如URI或Cookie)。
简单旧式负载均衡(POLB)是负载均衡的原始形式，其中企业所熟悉的实际负载均衡算法发挥作用。轮询调度(Round Robin)、最少连接(Least Connections)、最快回应(Fastest Response)都是至今仍在使用的大规模算法。
POLB是基于协议的，支持UDP(用于流式传输)和TCP(面向连接)。它的决定基于所选择的算法，仅此而已。
简单旧式负载均衡(POLB)接收请求，并根据算法从资源池(有时称为服务器场或集群)中选择资源。然后，它转发请求，然后退出。
这种负载均衡的好处是速度相对较快，并有多种算法选项可供选择。如果性能至关重要，请选择最快回应(Fastest Response)。如果企业只想快速轻松地进行扩展，请选择轮询调度(Round Robin)。
简单旧式负载均衡(POLB)的缺点是，如果决策基于HTTP标头中的某些内容(如cookie或URI)，则只能实现部署模式。根据负载均衡服务，企业可以使用诸如时间或计数器之类的变量来实现A/B测试等模式，以确定选择哪个资源。它不一定像使用HTTP负载均衡一样简易，但仍然可以获得相同的结果。
简单旧式负载均衡(POLB)可能是透明的，也可能是不透明的，具体取决于配置。使用网络负载均衡(NLB)，企业可以确信其应用程序接收的客户端(用户和设备)的IP地址是客户端的实际IP地址。使用POLB的一些配置，企业的应用程序收到的IP地址实际上是提供负载均衡服务的代理的IP地址。这意味着其应用程序需要更多的工作来挖掘真实的客户端IP地址。所以如果企业需要这些信息，应该知道它可能需要在HTTP标题中挖掘才能找到它。
HTTP负载均衡需要HTTP请求，并且在大多数实践中实际上做出两个不同的决定：***个基于HTTP变量，第二个基于算法。
为了准确，HTTP负载均衡实际上是路由和转发的组合。也就是说，它首先路由请求，然后根据资源的算法选择转发请求。这就是像Canary和Blue/Green Deployments这样的部署模式以及更强大的A/B测试。
这种类型的负载均衡问题在于它增加了等式的延迟。对HTTP请求越深入，延迟越多。一些负载均衡器具有“快速”模式，只允许基于HTTP标头进行负载均衡，以纠正此问题，但请注意，如果试图根据某个POST变量做出决定，该变量隐藏在HTTP负载的深处，这需要更多时间做决定。
另一个问题与简单旧式负载均衡(POLB)分享，即透明度。企业可能会也有可能不会收到每个请求的客户端的实际IP地址，因此请务必检查其应用中是否需要该信息。
选择企业的负载均衡，以便在规模和速度方面与其应用架构和特定目标相匹配。选择错误的负载均衡和算法可能会对企业实现这些目标的能力产生重大影响。
