不久前，我的队友Yariv在博客中介绍了OpenDNS智能代理，该代理使我们能够超越DNS层并阻止恶意HTTP通信。此后，我们的团队一直专注于其他项目，例如拥有并整合了我们基础架构中最古老的部分之一，即着陆器，从而释放了70多个服务器，以及一些我们将要讨论的令人兴奋的新功能 关于什么时候开始
今天，我想更详细地介绍智能代理及其支持的技术，即Nginx。
按照惯例，代理是在操作系统的网络设置中或在特定程序（例如HTTP代理的Chrome或Firefox）中明确配置的。
此外，协议还可以确保代理服务器始终可以在请求时确定客户端的预期目的地。但是，正如Yariv在他的帖子中所解释的那样，我们采用了一种非常规的方法，而不是代理所有内容（无论是否是显性的），而是通过DNS层选择性地将对可疑域的请求重新路由到我们的代理。这种选择性对于减少延迟，负载和影响非常有用，但同时也带来了一些有趣的工程挑战-主要围绕识别用户并确定原始目的地。
例如，当用户尝试浏览到“ some-website.net”时，如果该域被归类为可疑，则OpenDNS解析器将返回最近的Intelligent Proxy服务器的IP地址。客户，例如Firefox或Chrome对此一无所知，并假设接收到的IP地址属于实际托管“ some-website.net”的服务器。对于纯HTTP，很容易确定原始目标是什么，因为HTTP / 1.1要求在每个HTTP请求中设置Host标头，现代浏览器将正确包含此标头。例如，共享主机提供商在为单个IP后面的多个网站提供服务时依赖于此标头。同样，可以利用TLS协议的服务器名称指示（SNI）扩展来代理HTTPS通信。对于其他端口和协议，此过程更为复杂（甚至不可能）。
另一个重要的概念是“正向”代理与“反向”代理的思想。前向代理服务于一组客户端，充当单个访问点并代表客户端查询原始服务器。如前所述，这是在操作系统或Firefox之类的浏览器中配置代理时使用的类型。
反向代理的作用相反，它充当多个服务器组件（例如CGI脚本，文件服务器或数据库）的单点访问。这些代理也通常用作负载平衡器和SSL终结点。
基于此，在服务已路由到它的客户端请求时，我们的智能代理是前向代理。但是它在内部也有一些反向代理，特别是当我们添加新功能和新的数据检查层时。一开始我也提到过，我们选择的技术是Nginx，熟悉Nginx的读者会知道它的设计纯粹是一种反向代理。
在下一篇文章中，我将讨论我们因此而采取的更多非常规方法，以及我们必须解决的挑战。
