Web 代理是一種存在于網(wǎng)絡中間的實體，提供各式各樣的功能?，F(xiàn)代網(wǎng)絡系統(tǒng)中，Web 代理無處不在。我之前有關(guān) HTTP 的博文中，多次提到了代理對 HTTP 請求及響應的影響。今天這篇文章，我打算談談 HTTP 代理本身的一些原理，以及如何用 Node.js 快速實現(xiàn)代理。

HTTP 代理存在兩種形式，分別簡單介紹如下：

***種是 RFC 7230 - HTTP/1.1: Message Syntax and Routing(即修訂后的 RFC 2616，HTTP/1.1 協(xié)議的***部分)描述的普通代理。這種代理扮演的是「中間人」角色，對于連接到它的客戶端來說，它是服務端;對于要連接的服務端來說，它是客戶端。它就負責在兩端之間來回傳送 HTTP 報文。

第二種是 Tunneling TCP based protocols through Web proxy servers(通過 Web 代理服務器用隧道方式傳輸基于 TCP 的協(xié)議)描述的隧道代理。它通過 HTTP 協(xié)議正文部分(Body)完成通訊，以 HTTP 的方式實現(xiàn)任意基于 TCP 的應用層協(xié)議代理。這種代理使用 HTTP 的 CONNECT 方法建立連接，但 CONNECT 最開始并不是 RFC 2616 - HTTP/1.1 的一部分，直到 2014 年發(fā)布的 HTTP/1.1 修訂版中，才增加了對 CONNECT 及隧道代理的描述，詳見 RFC 7231 - HTTP/1.1: Semantics and Content。實際上這種代理早就被廣泛實現(xiàn)。

本文描述的***種代理，對應《HTTP 權(quán)威指南》一書中第六章「代理」;第二種代理，對應第八章「集成點：網(wǎng)關(guān)、隧道及中繼」中的 8.5 小節(jié)「隧道」。

普通代理

***種 Web 代理原理特別簡單：

HTTP 客戶端向代理發(fā)送請求報文，代理服務器需要正確地處理請求和連接(例如正確處理 Connection: keep-alive)，同時向服務器發(fā)送請求，并將收到的響應轉(zhuǎn)發(fā)給客戶端。

下面這張圖片來自于《HTTP 權(quán)威指南》，直觀地展示了上述行為：

 [[157909]]

假如我通過代理訪問 A 網(wǎng)站，對于 A 來說，它會把代理當做客戶端，完全察覺不到真正客戶端的存在，這實現(xiàn)了隱藏客戶端 IP 的目的。當然代理也可以修改 HTTP 請求頭部，通過 X-Forwarded-IP 這樣的自定義頭部告訴服務端真正的客戶端 IP。但服務器無法驗證這個自定義頭部真的是由代理添加，還是客戶端修改了請求頭，所以從 HTTP 頭部字段獲取 IP 時，需要格外小心。

給瀏覽器顯式的指定代理，需要手動修改瀏覽器或操作系統(tǒng)相關(guān)設置，或者指定 PAC(Proxy Auto-Configuration，自動配置代理)文件自動設置，還有些瀏覽器支持 WPAD(Web Proxy Autodiscovery Protocol，Web 代理自動發(fā)現(xiàn)協(xié)議)。顯式指定瀏覽器代理這種方式一般稱之為正向代理，瀏覽器啟用正向代理后，會對 HTTP 請求報文做一些修改，來規(guī)避老舊代理服務器的一些問題。

還有一種情況是訪問 A 網(wǎng)站時，實際上訪問的是代理，代理收到請求報文后，再向真正提供服務的服務器發(fā)起請求，并將響應轉(zhuǎn)發(fā)給瀏覽器。這種情況一般被稱之為反向代理，它可以用來隱藏服務器 IP 及端口。一般使用反向代理后，需要通過修改 DNS 讓域名解析到代理服務器 IP，這時瀏覽器無法察覺到真正服務器的存在，當然也就不需要修改配置了。反向代理是 Web 系統(tǒng)最為常見的一種部署方式，例如本博客就是使用 Nginx 的proxy_pass 功能將瀏覽器請求轉(zhuǎn)發(fā)到背后的 Node.js 服務。

了解完***種代理的基本原理后，我們用 Node.js 實現(xiàn)一下它。只包含核心邏輯的代碼如下：

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 和其他必要參數(shù)，新建到服務端的請求，并把代理收到的請求轉(zhuǎn)發(fā)給新建的請求，***再把服務端響應返回給瀏覽器。修改瀏覽器的 HTTP 代理為 127.0.0.1:8888 后再訪問 HTTP 網(wǎng)站，代理可以正常工作。

但是，使用我們這個代理服務后，HTTPS 網(wǎng)站完全無法訪問，這是為什么呢?答案很簡單，這個代理提供的是 HTTP 服務，根本沒辦法承載 HTTPS 服務。那么是否把這個代理改為 HTTPS 就可以了呢?顯然也不可以，因為這種代理的本質(zhì)是中間人，而 HTTPS 網(wǎng)站的證書認證機制是中間人劫持的克星。普通的 HTTPS 服務中，服務端不驗證客戶端的證書，中間人可以作為客戶端與服務端成功完成 TLS 握手;但是中間人沒有證書私鑰，無論如何也無法偽造成服務端跟客戶端建立 TLS 連接。當然如果你擁有證書私鑰，代理證書對應的 HTTPS 網(wǎng)站當然就沒問題了。

HTTP 抓包神器 Fiddler 的工作原理也是在本地開啟 HTTP 代理服務，通過讓瀏覽器流量走這個代理，從而實現(xiàn)顯示和修改 HTTP 包的功能。如果要讓 Fiddler 解密 HTTPS 包的內(nèi)容，需要先將它自帶的根證書導入到系統(tǒng)受信任的根證書列表中。一旦完成這一步，瀏覽器就會信任 Fiddler 后續(xù)的「偽造證書」，從而在瀏覽器和 Fiddler、Fiddler 和服務端之間都能成功建立 TLS 連接。而對于 Fiddler 這個節(jié)點來說，兩端的 TLS 流量都是可以解密的。

如果我們不導入根證書，F(xiàn)iddler 的 HTTP 代理還能代理 HTTPS 流量么?實踐證明，不導入根證書，F(xiàn)iddler 只是無法解密 HTTPS 流量，HTTPS 網(wǎng)站還是可以正常訪問。這是如何做到的，這些 HTTPS 流量是否安全呢?這些問題將在下一節(jié)揭曉。

隧道代理

第二種 Web 代理的原理也很簡單：

HTTP 客戶端通過 CONNECT 方法請求隧道代理創(chuàng)建一條到達任意目的服務器和端口的 TCP 連接，并對客戶端和服務器之間的后繼數(shù)據(jù)進行盲轉(zhuǎn)發(fā)。

下面這張圖片同樣來自于《HTTP 權(quán)威指南》，直觀地展示了上述行為：

 [[157910]]

假如我通過代理訪問 A 網(wǎng)站，瀏覽器首先通過 CONNECT 請求，讓代理創(chuàng)建一條到 A 網(wǎng)站的 TCP 連接;一旦 TCP 連接建好，代理無腦轉(zhuǎn)發(fā)后續(xù)流量即可。所以這種代理，理論上適用于任意基于 TCP 的應用層協(xié)議，HTTPS 網(wǎng)站使用的 TLS 協(xié)議當然也可以。這也是這種代理為什么被稱為隧道的原因。對于 HTTPS 來說，客戶端透過代理直接跟服務端進行 TLS 握手協(xié)商密鑰，所以依然是安全的，下圖中的抓包信息顯示了這種場景：

 [[157911]]

可以看到，瀏覽器與代理進行 TCP 握手之后，發(fā)起了 CONNECT 請求，報文起始行如下：

CONNECT imququ.com:443 HTTP/1.1 

對于 CONNECT 請求來說，只是用來讓代理創(chuàng)建 TCP 連接，所以只需要提供服務器域名及端口即可，并不需要具體的資源路徑。代理收到這樣的請求后，需要與服務端建立 TCP 連接，并響應給瀏覽器這樣一個 HTTP 報文：

HTTP/1.1 200 Connection Established 

瀏覽器收到了這個響應報文，就可以認為到服務端的 TCP 連接已經(jīng)打通，后續(xù)直接往這個 TCP 連接寫協(xié)議數(shù)據(jù)即可。通過 Wireshark 的 Follow TCP Steam 功能，可以清楚地看到瀏覽器和代理之間的數(shù)據(jù)傳遞：

 [[157912]]

可以看到，瀏覽器建立到服務端 TCP 連接產(chǎn)生的 HTTP 往返，完全是明文，這也是為什么 CONNECT 請求只需要提供域名和端口：如果發(fā)送了完整 URL、Cookie 等信息，會被中間人一覽無余，降低了 HTTPS 的安全性。HTTP 代理承載的 HTTPS 流量，應用數(shù)據(jù)要等到 TLS 握手成功之后通過 Application Data 協(xié)議傳輸，中間節(jié)點無法得知用于流量加密的 master-secret，無法解密數(shù)據(jù)。而 CONNECT 暴露的域名和端口，對于普通的 HTTPS 請求來說，中間人一樣可以拿到(IP 和端口很容易拿到，請求的域名可以通過 DNS Query 或者 TLS Client Hello 中的 Server Name Indication 拿到)，所以這種方式并沒有增加不安全性。

#p#

了解完原理后，再用 Node.js 實現(xiàn)一個支持 CONNECT 的代理也很簡單。核心代碼如下：

JSvar 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 請求報文中解析出域名和端口，創(chuàng)建到服務端的 TCP 連接，并和 CONNECT 請求中的 TCP 連接串起來，***再響應一個 Connection Established 響應。修改瀏覽器的 HTTP 代理為 127.0.0.1:8888 后再訪問 HTTPS 網(wǎng)站，代理可以正常工作。

***，將兩種代理的實現(xiàn)代碼合二為一，就可以得到全功能的 Proxy 程序了，全部代碼在 50 行以內(nèi)(當然異常什么的基本沒考慮，這是我博客代碼的一貫風格)：

JSvar 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 網(wǎng)站走隧道代理，這是因為建立隧道需要耗費一次往返，能不用就盡量不用。但這并不代表 HTTP 請求不能走隧道代理，我們用 Node.js 寫段程序驗證下(先運行前面的代理服務)：

JSvar 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(); 

這段代碼運行完，結(jié)果如下：

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 的認證機制可以跟代理配合使用，使得必須輸入正確的用戶名和密碼才能使用代理，這部分內(nèi)容比較簡單，這里略過。在本文第二部分，我打算談談如何把今天實現(xiàn)的代理改造為 HTTPS 代理，也就是如何讓瀏覽器與代理之間的流量走 HTTPS 安全機制。