曾几何时，恐龙在地球上漫游；人类最早开始使用岩石和基于第 4 层 DSR 的负载平衡器等工具。
当时，这些工具很有用，因为你可以用它们联系到服务器，它们也很有用，因为很容易确保应用服务器显示的是实际的客户端 IP 地址。
负载平衡器位于客户机和应用程序之间，因此从应用程序回看，谁是发送方？客户端（是的，请回答）还是负载平衡器？
这相当容易，你有几个选择。
DSR 模式 – 直接服务器返回。
- 客户端将连接到负载平衡器。
- 负载平衡器将使用客户端的源 IP 将其发送给应用程序。
- 然后，应用程序将直接向客户端发送响应。它可能会注意到 SourceIP 是外部 IP，然后将响应路由到网关，从而跳过响应上的负载平衡器。
因此，恐龙们喜欢这种方法，因为它使用的基础设施资源更少，而且应用程序可以获得真正的客户端 IP
缺点是需要在应用程序服务器和大显示屏上进行特殊的网络配置……负载平衡器不会收到或看到响应，因此任何 SSL 或内容切换都是不可能的。
另一个缺点是，LB 不知道 App 服务器的性能如何，因此很难将负载平衡到最有可能提高性能的服务器上。ADC 会使用响应最快或连接最少的服务器。(石器时代的人可以在 App 服务器上安装一个代理来报告这一情况）或者 ADC 可以使用 SNMP 来获取这一信息。
不管怎么说，这种设置多年来一直行之有效，就像马车和马车一样，事实上，在有些情况下，这种设置仍然是最佳选择，例如战车比赛或一些古老的协议。
接下来是
网关模式
- 客户端将连接到负载平衡器
- 负载平衡器会将其发送到 App 服务器，并附上客户端的源 IP
- 应用程序会直接向客户端发送响应，但不会通过负载平衡器，因为您已将应用程序服务器的默认网关更改为负载平衡器的默认网关。这意味着负载平衡器将收到响应。
这在某些方面要好得多，但来自应用程序服务器的所有外部流量（如软件更新）都要通过负载平衡器运行，因此会变得很混乱。
这种情况在负载平衡器看起来像交换机、所有设备都直接插入高速杯串网络链接时更为常见。
人类学会养殖和使用基于代理的负载平衡
大约在这个时候，网络和 CPU 速度越来越快，我们开始看到代理方法。
我们决定坦白从宽，开始使用负载平衡器作为源 IP，而不是欺骗应用服务器。我们这样做有很多原因，包括 TCP 性能、安全性以及在负载平衡器上提供额外服务的能力。
但是，这种摒弃狩猎采集的做法也带来了巨大的代价和挑战。
如何向应用程序服务器发送客户端 IP？
幸运的是，只要你使用 HTTP，”老好人 “HTTP 就能提供很好的答案。
X_Forwarded_For 标头 – 允许将客户端 IP 写入标头，然后发送。
我不会详细解释这个问题，因为它相当简单，但我只想说，这是一个任何人都可以轻松设置的标题。此外，它还可能变得复杂。例如，如果负载平衡器已经收到了 X_Forwareded_For IP，会发生什么情况？是使用该 IP 还是使用源 IP 并进行更改？这些通常都可以在像样的 LB 上配置，但它们都有安全考虑等。
总之，99% 的情况下，只要网络应用程序需要源代码，他们就会通过这种方式获取（注：99% 的统计数据都是编造的）
其他协议呢？
有几种是针对特定协议的黑客技术，但没有什么通用技术被更广泛地采用。
直到《代理协议》提出并被广泛采用。
代理协议解释
代理协议通过在转发请求中添加一个包含原始客户端连接详细信息的头来解决这个问题。
该协议已有两个版本。
- 代理协议 v1：使用简单、人类可读的文本格式。
- 代理协议 v2：使用二进制格式，效率更高，可支持 IPv6 和 Unix 套接字地址等附加功能。
不同的是，如果不对应用程序服务器进行配置，启用代理协议后，大多数应用程序服务器都会崩溃。这是因为代理协议会在数据开始时添加所需的细节。
不过，采用这种方法的人越来越多，许多供应商现在都支持这种方法。
例如，它非常适合 DNS 代理。
与 X_Forwardard_For 一样，我们还需要做出一些决定：
例如，如果出现代理协议标头，您希望负载平衡器如何处理？是删除它并设置一个新的，还是保留它？如果不希望发送代理协议标头，就应该忽略它，然后获取自己的代理协议标头，但必须考虑这些决定。
代理协议是获取客户端 IP 的一种简单方法，目前已得到广泛支持，请尽情使用。
我要回去考虑云计算的高可用性了，Ciao！
