HTTP 代理原理及實現(一)
文章目錄
提醒:本文最後更新於 1097 天前,文中所描述的資訊可能已發生改變,請謹慎使用。
Web 代理是一種存在於網路中間的實體,提供各式各樣的功能。現代網路系統中,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 小節「隧道」。
普通代理
第一種 Web 代理原理特別簡單:
HTTP 客戶端向代理髮送請求報文,代理伺服器需要正確地處理請求和連線(例如正確處理 Connection: keep-alive),同時向伺服器傳送請求,並將收到的響應轉發給客戶端。
下面這張圖片來自於《HTTP 權威指南》,直觀地展示了上述行為:
假如我通過代理訪問 A 網站,對於 A 來說,它會把代理當做客戶端,完全察覺不到真正客戶端的存在,這實現了隱藏客戶端 IP 的目的。當然代理也可以修改 HTTP 請求頭部,通過 X-Forwarded-IP
給瀏覽器顯式的指定代理,需要手動修改瀏覽器或作業系統相關設定,或者指定 PAC(Proxy Auto-Configuration,自動配置代理)檔案自動設定,還有些瀏覽器支援 WPAD(Web Proxy Autodiscovery Protocol,Web 代理自動發現協議)。顯式指定瀏覽器代理這種方式一般稱之為正向代理,瀏覽器啟用正向代理後,會對 HTTP 請求報文做一些修改,來規避老舊代理伺服器的一些問題,這部分內容可以參考我之前的《Http 請求頭中的 Proxy-Connection》這篇文章。
還有一種情況是訪問 A 網站時,實際上訪問的是代理,代理收到請求報文後,再向真正提供服務的伺服器發起請求,並將響應轉發給瀏覽器。這種情況一般被稱之為反向代理,它可以用來隱藏伺服器 IP 及埠。一般使用反向代理後,需要通過修改 DNS 讓域名解析到代理伺服器 IP,這時瀏覽器無法察覺到真正伺服器的存在,當然也就不需要修改配置了。反向代理是 Web 系統最為常見的一種部署方式,例如本部落格就是使用 Nginx 的 proxy_pass
功能將瀏覽器請求轉發到背後的 Node.js 服務。
瞭解完第一種代理的基本原理後,我們用 Node.js 實現一下它。只包含核心邏輯的程式碼如下:
var http = require('http');
var net = require('net');
var url = require('url');
function request(cReq, cRes) {
var u = url.parse(cReq.url);
var options = {
hostname : u.hostname,
port : u.port || 80,
path : u.path,
method : cReq.method,
headers : cReq.headers
};
var pReq = http.request(options, function(pRes) {
cRes.writeHead(pRes.statusCode, pRes.headers);
pRes.pipe(cRes);
}).on('error', function(e) {
cRes.end();
});
cReq.pipe(pReq);
}
http.createServer().on('request', request).listen(8888, '0.0.0.0');
以上程式碼執行後,會在本地 8888
埠開啟 HTTP 代理服務,這個服務從請求報文中解析出請求 URL 和其他必要引數,新建到服務端的請求,並把代理收到的請求轉發給新建的請求,最後再把服務端響應返回給瀏覽器。修改瀏覽器的 HTTP 代理為 127.0.0.1:8888
後再訪問 HTTP 網站,代理可以正常工作。
但是,使用我們這個代理服務後,HTTPS 網站完全無法訪問,這是為什麼呢?答案很簡單,這個代理提供的是 HTTP 服務,根本沒辦法承載 HTTPS 服務。那麼是否把這個代理改為 HTTPS 就可以了呢?顯然也不可以,因為這種代理的本質是中間人,而 HTTPS 網站的證書認證機制是中間人劫持的剋星。普通的 HTTPS 服務中,服務端不驗證客戶端的證書,中間人可以作為客戶端與服務端成功完成 TLS 握手;但是中間人沒有證書私鑰,無論如何也無法偽造成服務端跟客戶端建立 TLS 連線。當然如果你擁有證書私鑰,代理證書對應的 HTTPS 網站當然就沒問題了。
HTTP 抓包神器 Fiddler 的工作原理也是在本地開啟 HTTP 代理服務,通過讓瀏覽器流量走這個代理,從而實現顯示和修改 HTTP 包的功能。如果要讓 Fiddler 解密 HTTPS 包的內容,需要先將它自帶的根證書匯入到系統受信任的根證書列表中。一旦完成這一步,瀏覽器就會信任 Fiddler 後續的「偽造證書」,從而在瀏覽器和 Fiddler、Fiddler 和服務端之間都能成功建立 TLS 連線。而對於 Fiddler 這個節點來說,兩端的 TLS 流量都是可以解密的。
如果我們不匯入根證書,Fiddler 的 HTTP 代理還能代理 HTTPS 流量麼?實踐證明,不匯入根證書,Fiddler 只是無法解密 HTTPS 流量,HTTPS 網站還是可以正常訪問。這是如何做到的,這些 HTTPS 流量是否安全呢?這些問題將在下一節揭曉。
隧道代理
第二種 Web 代理的原理也很簡單:
HTTP 客戶端通過 CONNECT 方法請求隧道代理建立一條到達任意目的伺服器和埠的 TCP 連線,並對客戶端和伺服器之間的後繼資料進行盲轉發。
下面這張圖片同樣來自於《HTTP 權威指南》,直觀地展示了上述行為:
假如我通過代理訪問 A 網站,瀏覽器首先通過 CONNECT 請求,讓代理建立一條到 A 網站的 TCP 連線;一旦 TCP 連線建好,代理無腦轉發後續流量即可。所以這種代理,理論上適用於任意基於 TCP 的應用層協議,HTTPS 網站使用的 TLS 協議當然也可以。這也是這種代理為什麼被稱為隧道的原因。對於 HTTPS 來說,客戶端透過代理直接跟服務端進行 TLS 握手協商金鑰,所以依然是安全的,下圖中的抓包資訊顯示了這種場景:
可以看到,瀏覽器與代理進行 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 拿到),所以這種方式並沒有增加不安全性。
瞭解完原理後,再用 Node.js 實現一個支援 CONNECT 的代理也很簡單。核心程式碼如下:
var http = require('http');
var net = require('net');
var url = require('url');
function connect(cReq, cSock) {
var u = url.parse('http://' + cReq.url);
var pSock = net.connect(u.port, u.hostname, function() {
cSock.write('HTTP/1.1 200 Connection Established\r\n\r\n');
pSock.pipe(cSock);
}).on('error', function(e) {
cSock.end();
});
cSock.pipe(pSock);
}
http.createServer().on('connect', connect).listen(8888, '0.0.0.0');
以上程式碼執行後,會在本地 8888
埠開啟 HTTP 代理服務,這個服務從 CONNECT 請求報文中解析出域名和埠,建立到服務端的 TCP 連線,並和 CONNECT 請求中的 TCP 連線串起來,最後再響應一個 Connection Established 響應。修改瀏覽器的 HTTP 代理為 127.0.0.1:8888
後再訪問 HTTPS 網站,代理可以正常工作。
最後,將兩種代理的實現程式碼合二為一,就可以得到全功能的 Proxy 程式了,全部程式碼在 50 行以內(當然異常什麼的基本沒考慮,這是我部落格程式碼的一貫風格):
var http = require('http');
var net = require('net');
var url = require('url');
function request(cReq, cRes) {
var u = url.parse(cReq.url);
var options = {
hostname : u.hostname,
port : u.port || 80,
path : u.path,
method : cReq.method,
headers : cReq.headers
};
var pReq = http.request(options, function(pRes) {
cRes.writeHead(pRes.statusCode, pRes.headers);
pRes.pipe(cRes);
}).on('error', function(e) {
cRes.end();
});
cReq.pipe(pReq);
}
function connect(cReq, cSock) {
var u = url.parse('http://' + cReq.url);
var pSock = net.connect(u.port, u.hostname, function() {
cSock.write('HTTP/1.1 200 Connection Established\r\n\r\n');
pSock.pipe(cSock);
}).on('error', function(e) {
cSock.end();
});
cSock.pipe(pSock);
}
http.createServer()
.on('request', request)
.on('connect', connect)
.listen(8888, '0.0.0.0');
需要注意的是,大部分瀏覽器顯式配置了代理之後,只會讓 HTTPS 網站走隧道代理,這是因為建立隧道需要耗費一次往返,能不用就儘量不用。但這並不代表 HTTP 請求不能走隧道代理,我們用 Node.js 寫段程式驗證下(先執行前面的代理服務):
var http = require('http');
var options = {
hostname : '127.0.0.1',
port : 8888,
path : 'imququ.com:80',
method : 'CONNECT'
};
var req = http.request(options);
req.on('connect', function(res, socket) {
socket.write('GET / HTTP/1.1\r\n' +
'Host: imququ.com\r\n' +
'Connection: Close\r\n' +
'\r\n');
socket.on('data', function(chunk) {
console.log(chunk.toString());
});
socket.on('end', function() {
console.log('socket end.');
});
});
req.end();
這段程式碼執行完,結果如下:
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Thu, 19 Nov 2015 15:57:47 GMT
Content-Type: text/html
Content-Length: 178
Connection: close
Location: https://imququ.com/
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
socket end.
可以看到,通過 CONNECT 讓代理開啟到目標伺服器的 TCP 連線,用來承載 HTTP 流量也是完全沒問題的。
最後,HTTP 的認證機制可以跟代理配合使用,使得必須輸入正確的使用者名稱和密碼才能使用代理,這部分內容比較簡單,這裡略過。在本文第二部分,我打算談談如何把今天實現的代理改造為 HTTPS 代理,也就是如何讓瀏覽器與代理之間的流量走 HTTPS 安全機制。注:已經寫完了,點這裡檢視。
--EOF--
發表於 2015-11-20 00:45:24 ,並被新增「 Node 、 Proxy 、 HTTP 」標籤 。檢視本文 Markdown 版本 »
提醒:本文最後更新於 1097 天前,文中所描述的資訊可能已發生改變,請謹慎使用。