Atitit 代理解决方案proxy solu attilax总结 1. 为什么需要代理1 1.1. Ajax跨域1 1.2. Nginx反向代理1 2. 分类2 2.1. 普通vs隧道2
Atitit 代理解決方案proxy solu attilax總結
?
1. 為什么需要代理 1
1.1. Ajax跨域 1
1.2. Nginx反向代理 1
2. 分類 2
2.1. 普通vs隧道 2
2.2. 正向反向 2
2.3. CGLIB 動態代理 AspectJ靜態代理 2
2.4. http代理 socket代理 2
3. 普通代理 2
3.1.1. 普通代理 3
4. 隧道代理 4
5. 反向代理 5
6. 代理的實現 5
6.1. nginx 5
6.2. 正向代理也可以使用apache實現 5
6.3. 瀏覽器代理 6
7. 參考 6
8. 參考資料 6
?
1.?為什么需要代理
1.1.?Ajax跨域
1.2.?Nginx反向代理
?
??server_name ?http://www.qq.com;
?
????????#charset koi8-r;
?
????????#access_log ?logs/host.access.log ?main;
?
????????location / {
????????????proxy_pass http://www.qq.com;
????????}
?
2.?分類
2.1.?普通vs隧道
2.2.?正向反向
?
2.3.?CGLIB 動態代理 AspectJ靜態代理
2.4.?http代理 socket代理
3.?普通代理
Web 代理是一種存在于網絡中間的實體，提供各式各樣的功能?，F代網絡系統中，Web 代理無處不在。我之前有關 HTTP 的博文中，多次提到了代理對 HTTP 請求及響應的影響。今天這篇文章，我打算談談 HTTP 代理本身的一些原理，以及如何用 Node.js 快速實現代理。
HTTP 代理存在兩種形式，分別簡單介紹如下：
第一種是?RFC 7230 - HTTP/1.1: Message Syntax and Routing（即修訂后的 RFC 2616，HTTP/1.1 協議的第一部分）描述的普通代理。這種代理扮演的是「中間人」角色，對于連接到它的客戶端來說，它是服務端；對于要連接的服務端來說，它是客戶端。它就負責在兩端之間來回傳送 HTTP 報文。
第二種是?Tunneling TCP based protocols through Web proxy servers（通過 Web 代理服務器用隧道方式傳輸基于 TCP 的協議）描述的隧道代理。它通過 HTTP 協議正文部分（Body）完成通訊，以 HTTP 的方式實現任意基于 TCP 的應用層協議代理。這種代理使用 HTTP 的 CONNECT 方法建立連接，但 CONNECT 最開始并不是 RFC 2616 - HTTP/1.1 的一部分，直到 2014 年發布的 HTTP/1.1 修訂版中，才增加了對 CONNECT 及隧道代理的描述，詳見?RFC 7231 - HTTP/1.1: Semantics and Content。實際上這種代理早就被廣泛實現。
本文描述的第一種代理，對應《HTTP 權威指南》一書中第六章「代理」；第二種代理，對應第八章「集成點：網關、隧道及中繼」中的 8.5 小節「隧道」。
.作者::?綽號:老哇的爪子?（?全名：：Attilax?Akbar?Al?Rapanui?阿提拉克斯?阿克巴?阿爾?拉帕努伊?）?漢字名：艾龍，??EMAIL:1466519819@qq.com
轉載請注明來源：?http://blog.csdn.net/attilax
?
3.0.1.?普通代理
第一種 Web 代理原理特別簡單：
HTTP 客戶端向代理發送請求報文，代理服務器需要正確地處理請求和連接（例如正確處理 Connection: keep-alive），同時向服務器發送請求，并將收到的響應轉發給客戶端。
當然代理也可以修改 HTTP 請求頭部，通過?X-Forwarded-IP?這樣的自定義頭部告訴服務端真正的客戶端 IP。但服務器無法驗證這個自定義頭部真的是由代理添加，還是客戶端修改了請求頭，所以從 HTTP 頭部字段獲取 IP 時，需要格外小心。
?
4.?隧道代理
?
可以看到，瀏覽器與代理進行 TCP 握手之后，發起了 CONNECT 請求，報文起始行如下：
CONNECT imququ.com:443 HTTP/1.1
對于 CONNECT 請求來說，只是用來讓代理創建 TCP 連接，所以只需要提供服務器域名及端口即可，并不需要具體的資源路徑。代理收到這樣的請求后，需要與服務端建立 TCP 連接，并響應給瀏覽器這樣一個 HTTP 報文：
HTTP/1.1 200 Connection Established
瀏覽器收到了這個響應報文，就可以認為到服務端的 TCP 連接已經打通，后續直接往這個 TCP 連接寫協議數據即可。通過 Wireshark 的 Follow TCP Steam 功能，可以清楚地看到瀏覽器和代理之間的數據傳遞：
可以看到，瀏覽器建立到服務端 TCP 連接產生的 HTTP 往返，完全是明文，這也是為什么 CONNECT 請求只需要提供域名和端口：如果發送了完整 URL、Cookie 等信息，會被中間人一覽無余，降低了 HTTPS 的安全性。HTTP 代理承載的 HTTPS 流量，應用數據要等到 TLS 握手成功之后通過 Application Data 協議傳輸，中間節點無法得知用于流量加密的 master-secret，無法解密數據。而 CONNECT 暴露的域名和端口，對于普通的 HTTPS 請求來說，中間人一樣可以拿到（IP 和端口很容易拿到，請求的域名可以通過 DNS Query 或者 TLS Client Hello 中的 Server Name Indication 拿到），所以這種方式并沒有增加不安全性
?
5.?反向代理
還有一種情況是訪問 A 網站時，實際上訪問的是代理，代理收到請求報文后，再向真正提供服務的服務器發起請求，并將響應轉發給瀏覽器。這種情況一般被稱之為反向代理，它可以用來隱藏服務器 IP 及端口。一般使用反向代理后，需要通過修改 DNS 讓域名解析到代理服務器 IP，這時瀏覽器無法察覺到真正服務器的存在，當然也就不需要修改配置了。反向代理是 Web 系統最為常見的一種部署方式，例如本博客就是使用 Nginx 的?proxy_pass?功能將瀏覽器請求轉發到背后的 Node.js 服務。
通常是由apache實現
6.?代理的實現
6.1.?nginx
6.2.?正向代理也可以使用apache實現
?
??#正向代理設置
????ProxyRequests On
????ProxyVia On
?
????<Proxy *>
????????Order deny,allow
????????Deny from all
????????Allow from 127.0.0.1
????</Proxy></VirtualHost>
現在看正向代理設置那一段
ProxyRequests On：開啟Apache正向代理
ProxyVia On：控制位于代理服務器鏈中的代理請求的流向
引用Apache2.2官方文檔中對ProxyVia的解釋如下：
?
如果設置為默認值Off?，將不會采取特殊的處理。如果一個請求或應答包含"Via:"頭，將不進行任何修改而直接通過。
如果設置為On每個請求和應答都會對應當前主機得到一個"Via:"頭。
如果設置為Full?，每個產生的"Via:"頭中都會額外加入Apache服務器的版本，以"Via:"注釋域出現。
如果設置為Block?，每個代理請求中的所有"Via:"頭行都將被刪除。且不會產生新的"Via:"頭。
6.3.?瀏覽器代理
7.?參考
7.1.?HTTP 代理原理及實現（一） ??JerryQu 的小站.htm
7.2.?Apache配置正向代理與反向代理 - Alexis_Liu - 博客園.htm
7.3.??
7.4.?參考資料
7.5.?Apache配置正向代理與反向代理 - Alexis_Liu - 博客園.htm
7.6.?[轉載]socks2http原理分析 代理技巧交流 代理中國--ProxyCN_Com 提供每日全球最新最快代理服務器 - Powered by PHPWind.htm
7.7.?atitit. 自動代理 proxy 的設計實現。
7.8.?Atitit.實現反向代理(1)----url rewrite 配置java php.wps
7.9.?用Java開發代理服務器.htm
7.10.?Java編寫代理服務器(Burp攔截Demo)一 - Web安全 - 米安網.htm
7.11.?Atitit.java http 代理 ?atiHttpProxy ?大木馬.docx
7.12.?多線程Http代理服務器 Java實現 - 獨上高樓 - ITeye技術網站.htm
7.13.?Atitit 通用服務端代理接口 ?轉接口 attilax總結.docx
7.14.?java實現http代理服務 - chenyu.hz - ITeye技術網站.htm
7.15.?Atitit.HTTP 代理原理及實現 正向代理與反向代理attilax總結.docx
7.16.?Atitit 動態調用webservice與客戶端代理方式調用.docx
7.17.?Atitit 代理CGLIB 動態代理 AspectJ靜態代理區別.docx
?
?
?
作者:: 綽號:老哇的爪子claw of Eagle 偶像破壞者Iconoclast image-smasher
捕鳥王"Bird Catcher ?kok ?虔誠者Pious 宗教信仰捍衛者 Defender Of the Faith. 卡拉卡拉紅斗篷 Caracalla red cloak 萬獸之王??縱火者
簡稱：： st Emir Attilax Akbar 圣?埃米爾 阿提拉克斯 阿克巴
全名：：st Emir Attilax Akbar bin Mahmud bin ?attila bin Solomon bin adam Al Rapanui 圣?埃米爾 阿提拉克斯 阿克巴 本 馬哈茂德 本 阿提拉 本 所羅門 本亞當 ?阿爾 拉帕努伊
常用名：艾提拉（艾龍）， ?EMAIL:1466519819@qq.com
?
?
頭銜：
?
| uke | ?Emir Uke部落首席大酋長，ati協會創始人 uke總部o2o負責人，全球網格化項目創始人， 圣阿提拉克斯國王 |
| 科技領域 | UTSC uke技術標準化委員會委員長 uke 首席cto ??軟件部門總監 技術部副總監 ?研發部門總監主管 ?產品部副經理 項目部副經理 ??uke科技研究院院長 uke軟件培訓大師 Ati組織科研研究院創始人 ? |
| 文藝領域 | ， ?，， uke機車協會主任 uke紋身協會 uke交友協會會長 ?uke捕獵協會會長 Ati文藝協會會長 ?ati文學協會 ? |
| 行政領域 | Gchsp總裁 ?gchsp常委 ?GsP創始人 |
| 媒體傳播領域 | ???uke出版社編輯總編??宣傳布道總策劃 Ati傳媒總部 ? |
| 漁獵軍事領域 | uke保安部首席大隊長 Uke 戶外運動協會理事長 ?度假村首席大村長 Ati打獵協會 |
| 法學 | 法學研究會 制度研究會 |
| 管理領域 | 工商管理學 公共管理與社會服務 ,uke制度檢查委員會副會長 |
| 教育領域 | ?uec學院校長， uecip圖像處理機器視覺專業系主任 ??uke文檔檢索專業系主任 Uke圖像處理與機器視覺學院首席院長 uke終身教育學校副校長 靚號研究院 ? |
| 經濟領域 | uke波利尼西亞區大區連鎖負責人 湯加王國區域負責人 uke克爾格倫群島區連鎖負責人，萊恩群島區連鎖負責人，uke布維島和南喬治亞和南桑威奇群島大區連鎖負責人 ?Uke軟件標準化協會理事長理事長 Uke 數據庫與存儲標準化協會副會長 直達巴士西北區負責人???直達巴士長沙與西安分部部長 潤昌通訊軟件事業部總裁 執行長 分部負責人 ?執行委員會主席 Ati經濟研究所 |
| 歷史領域 | 歷史事業部 ?ati歷史研究院 |
| 社會科學領域 | 社科學院 ?ati文化部 |
| 自然科學領域 | Uke研究院院長兼首席研究員 科學家 Ati自然科學研究院 |
| 宗教神學領域 | uke宗教與文化融合事務部部長??大師master uke制度與重大會議委員會委員長????ati宗教事務所 |
| 醫學領域 | ???Uke醫院 與醫學院方面的創始人 ? |
?
?
?
?
?
?
?
?
轉載請注明來源：attilax的專欄 ?http://blog.csdn.net/attilax
http://www.cnblogs.com/attilax/
Microblog
http://weibo.com/u/5941179815???(common attilax)
https://weibo.com/p/1005055941179815??（attilax201707,bek weibo）
http://weibo.com/u/5487832265?(tech,for blog auto gene)
知乎空間
https://www.zhihu.com/people/ati-att/activities
Qq 1466519819 ?小號112237553
?微信attilax ?小號attilax201708
微博 attilax2016 ??小號attilax201707
?
?
--Atiend ?v19
?
總結
以上是生活随笔為你收集整理的Atitit 代理解决方案proxy solu attilax总结 1. 为什么需要代理1 1.1. Ajax跨域1 1.2. Nginx反向代理1 2. 分类2 2.1. 普通vs隧道2的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 移动通信核心网技术总结（四）IMS的网络
- 下一篇： Nginx-反向代理