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 天前，文中所描述的資訊可能已發生改變，請謹慎使用。