http proxy原理
本文內容主要來自http://www.fenesky.com/blog/2014/07/25/how-http-tunnel-works.html,在其基礎上稍加整理。
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).
與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:回顯伺服器收到的請求,主要用於測試或診斷。
%E8%B6%85%E6%96%87%E6%9C%AC%E4%BC%A0%E8%BE%93%E5%8D%8F%E8%AE%AE
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).
與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:回顯伺服器收到的請求,主要用於測試或診斷。
%E8%B6%85%E6%96%87%E6%9C%AC%E4%BC%A0%E8%BE%93%E5%8D%8F%E8%AE%AE
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/15480802/viewspace-1340982/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- HTTP原理HTTP
- nginx proxy cache的實現原理Nginx
- Http 請求頭中的 Proxy-ConnectionHTTP
- HTTP下載原理HTTP
- node跨域轉發 express+http-proxy-middleware跨域ExpressHTTP
- kube-proxy IPVS 模式的工作原理模式
- mysql_proxy工作原理和配置引數MySql
- nginx-upstream-keepalive;accept_mutex-proxy_http_version-1.1-proxy_set_header-connectionNginxMutexHTTPHeader
- 使用 http-proxy 代理 SAP UI5 應用發起的 HTTP 請求HTTPUI
- 一篇讀懂http-proxy-middleware(轉載)HTTP
- 使用 http-proxy 對網路請求進行代理HTTP
- 【Vue3響應式原理#02】Proxy and ReflectVue
- 【Go】Golang實現gRPC的Proxy的原理GolangRPC
- HTTP-Reverse-Proxy反向代理Nginx硬體指紋校驗HTTPNginx
- 系統環境變數中 HTTP_PROXY 的誤區變數HTTP
- 使用 http-proxy 代理 HTTP 請求時遇到的 the requested url is invalid 錯誤訊息HTTP
- HTTP檔案上傳原理HTTP
- HTTP狀態保持的原理HTTP
- HTTP網路請求原理HTTP
- vue.config.js 中跨域 proxy 的原理VueJS跨域
- 【原始碼系列#01】vue3響應式原理(Proxy)原始碼Vue
- http 框架的路由實現原理HTTP框架路由
- HTTP快取機制及原理HTTP快取
- HTTP協議基本原理HTTP協議
- http快取機制及其原理HTTP快取
- 深入分析HTTP代理的原理HTTP
- HTTP 代理原理及實現(2)HTTP
- Vue3.0 響應式資料原理:ES6 ProxyVue
- 說說webpack proxy工作原理?為什麼能解決跨域?Web跨域
- http斷點續傳原理:http頭 Range、Content-RangeHTTP斷點
- Proxy
- 瀏覽器HTTP快取原理分析瀏覽器HTTP快取
- 使用 http-proxy 實現 SAP UI5 請求的代理重定向HTTPUI
- 從零手寫實現 nginx-33-http_proxy 代理驗證測試NginxHTTP
- java動態代理基本原理及proxy原始碼分析一Java原始碼
- 在K8S中,kube-proxy iptables原理是什麼?K8S
- docker – nginx – proxy_pass + proxy_redirectDockerNginx
- nginx proxy_pass 和 proxy_redirectNginx