【轉載】http proxy原理

最近使用Charles抓https包時，發現get和post方式的請求都能抓到，可是method爲connect的就是抓不到。並且提示以下：

You may need to configure your browser or application to trust the Charles Root Certificate. See SSL Proxying in the Help menu.

因而搜索connect方式與其餘方式區別，才發現問題。如下內容系轉載。

 

***如下內容系轉載***

---

 

connect方法
http 1.1定義了8種方法，connect爲其中之一，HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。一般用於SSL加密服務器的連接（經由非加密的HTTP代理服務器）。
並不是全部的http隧道支持connect方法，Http隧道分爲兩種：
1  不使用CONNECT的隧道
不使用CONNECT的隧道，實現了數據包的重組和轉發。在Proxy收到來自客戶端的Http請求以後，會從新建立Request請求，併發送到目標服務器，。當目標服務器返回Response給Proxy以後，Proxy會對Response進行解析，而後從新組裝Response，發送給客戶端。因此，在不使用CONNECT方式創建的隧道，Proxy有機會對客戶端與目標服務器之間的通訊數據進行窺探，並且有機會對數據進行串改。

2  使用CONNECT的隧道
而對於使用CONNECT的隧道則不一樣。當客戶端向Proxy發起Http CONNECT Method的時候，就是告訴Proxy，先在Proxy和目標服務器之間先創建起鏈接，在這個鏈接創建起來以後，目標服務器會返回一個回覆給Proxy，Proxy將這個回覆轉發給客戶端，這個Response是Proxy跟目標服務器鏈接創建的狀態回覆，而不是請求數據的Response。在此以後，客戶端跟目標服務器的全部通訊都將使用以前創建起來的創建。這種狀況下的Http隧道，Proxy僅僅實現轉發，而不會關心轉發的數據。這也是爲何在使用Proxy的時候，Https請求必須首先使用Http CONNECT創建隧道。由於Https的數據都是通過加密的，Proxy是沒法對Https的數據進行解密的，因此只能使用CONNECT，僅僅對通訊數據進行轉發。
注意，proxy代理的是客戶端發起的TCP鏈接，如下是wiki的解釋                            
the client, using the "CONNECT" HTTP method, asks an HTTP Proxy server to forward the TCP connection to the desired destination. The server then proceeds to make the connection on behalf of the client. Once the connection has been established by the server, the Proxy server continues to proxy the TCP stream to and from the client. Note that only the initial connection request is HTTP - after that, the server simply proxies the established TCP connection.This mechanism is how a client behind an HTTP proxy can access websites using SSL (i.e. HTTPS).
http://en.wikipedia.org/wiki/HTTP_tunnel 


與proxy相關字段
X-Forwarded-For（XFF）是用來識別經過HTTP代理或負載均衡方式鏈接到Web服務器的客戶端最原始的IP地址的HTTP請求頭字段;  Squid 緩存代理服務器的開發人員最先引入了這一HTTP頭字段，若是沒有XFF或者另一種類似的技術，全部經過代理服務器的鏈接只會顯示代理服務器的IP地址(而非鏈接發起的原始IP地址)，這樣的代理服務器實際上充當了匿名服務提供者的角色，若是鏈接的原始IP地址不可得，惡意訪問的檢測與預防的難度將大大增長。
X-Forwarded-Host和X-Forwarded-Proto分別記錄客戶端最原始的主機和協議。
Proxy-Authorization：鏈接到proxy的身份驗證信息
Proxy-connection：它不是標準協議的一部分,標準協議中已經存在一種機制能夠完成此協議頭的功能,這就是Connection頭域,與Proxy-Connection頭相比，Connection協議頭幾乎提供了相同的功能，除了錯誤部分。並且，Connection協議頭可用於任意鏈接之間，包括HTTP服務器，代理，客戶端，而不是像Proxy-Connection同樣，只能用於代理服務器和客戶端之間。

http 1.1其他7種方法
OPTIONS：這個方法可以使服務器傳回該資源所支持的全部HTTP請求方法。用'*'來代替資源名稱，向Web服務器發送OPTIONS請求，能夠測試服務器功能是否正常運做。
HEAD：與GET方法同樣，都是向服務器發出指定資源的請求。只不過服務器將不傳回資源的本文部份。它的好處在於，使用這個方法能夠在沒必要傳輸所有內容的狀況下，
就能夠獲取其中「關於該資源的信息」（元信息或稱元數據）。
GET：向指定的資源發出「顯示」請求。使用GET方法應該只用在讀取數據，而不該當被用於產生「反作用」的操做中，例如在Web Application中，其中一個緣由是GET可能會被
網絡蜘蛛等隨意訪問。
POST：向指定資源提交數據，請求服務器進行處理（例如提交表單或者上傳文件）。數據被包含在請求本文中。這個請求可能會建立新的資源或修改現有資源，或兩者皆有。
PUT：向指定資源位置上傳其最新內容。
DELETE：請求服務器刪除Request-URI所標識的資源。
TRACE：回顯服務器收到的請求，主要用於測試或診斷。
http://zh.wikipedia.org/zh-cn/%E8%B6%85%E6%96%87%E6%9C%AC%E4%BC%A0%E8%BE%93%E5%8D%8F%E8%AE%AE

 

原文地址： http://blog.itpub.net/15480802/viewspace-1340982/