不久前，我的隊友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的讀者會知道它的設計純粹是一種反向代理。
在下一篇文章中，我將討論我們因此而採取的更多非常規方法，以及我們必須解決的挑戰。
原文：https://umbrella.cisco.com/blog/2015/09/18/lets-talk-about-proxies/
本文：http://jiagoushi.pro/lets-talk-about-proxies
討論：請加入知識星球或者微信圈子【首席架構師圈】
閱讀更多 首席架構師 的文章
