http代理如何抓取數據？  Web代理是存在于網絡中間并提供各種功能的實體。 在現代網絡系統中，Web 代理無處不在。 在我之前關于 HTTP 的博文中，我多次提到代理對 HTTP 請求和響應的影響。 在今天的文章中，我打算談談HTTP代理本身的一些原理以及如何用Node.js快速實現代理。  

 

HTTP代理有兩種形式，簡單介紹如下： 

第一種是RFC 7230-HTTP/1.1： 消息語法和路由（即修訂后的 RFC 2616，HTTP/1.1 協議的第一部分）描述了普通代理。 這種代理扮演著“中間人”的角色。 對于連接到它的客戶端來說，它是服務器； 對于要連接的服務器，它是客戶端。 它負責在兩端之間來回發送 HTTP 消息。  

 

第二個是通過 Web 代理服務器通過基于 TCP 的隧道協議描述的隧道代理。 它通過HTTP協議體完成通信，以HTTP的方式實現任何基于TCP的應用層協議代理。 此代理使用 HTTP CONNECT 方法建立連接，但 CONNECT 最初不是 RFC 2616-HTTP/1.1 的一部分。 直到 2014 年發布的 HTTP/1.1 修訂版才添加了 CONNECT 和隧道代理的描述。 請參閱 RFC 7231-HTTP/1.1：語義和內容。 事實上，這種機構早已廣泛實施。  

 

第一種Web代理原理很簡單：

HTTP客戶端向代理發送請求消息，代理服務器需要正確處理請求和連接（例如正確處理Connection:keep-alive），同時向服務器發送請求，將接收到的響應轉發給客戶端。  

 

下圖來自《HTTP權威指南》，直觀演示了上述行為： 

 

訪問A的網站，對于A來說，它把代理當成一個客戶端，完全不知道真實客戶端的存在。 這樣就達到了隱藏客戶端IP的目的。 當然，代理也可以修改HTTP請求頭，通過自定義的頭，比如X-Forwarded-IP，告訴服務器真實的客戶端IP。 但是，服務器無法驗證這個自定義頭是否真的是代理添加的，還是客戶端修改了請求頭，因此從HTTP頭字段中獲取IP時需要格外小心。 這部分內容可以參考我之前的文章《X-Forwarded-For in HTTP Request Header》。  

 

為瀏覽器顯式指定代理，需要手動修改瀏覽器或操作系統相關設置，或者指定PAC的自動設置（Proxy Auto-Configuration，自動配置 proxy) 文件，并且某些瀏覽器支持 WPAD（Web 代理自動發現協議）。 顯式指定瀏覽器代理的方法一般稱為正向代理。 瀏覽器啟用轉發代理后，會對HTTP請求報文做一些修改，避免舊代理服務器的一些問題。 這部分內容可以參考。 我之前的文章“Http 請求頭中的代理連接”。  

 

另一種情況是，當你訪問A網站時，你實際上訪問了代理。 代理收到請求消息后，向實際提供服務的服務器發起請求，并響應轉發給瀏覽器。 這種情況一般稱為反向代理，可以用來隱藏服務器IP和端口。 一般使用反向代理后，需要修改DNS，將域名解析為代理服務器IP。 此時瀏覽器無法檢測到真實服務器的存在。無需修改配置。 反向代理是 Web 系統最常見的部署方式。 比如本篇博客使用Nginx的proxy_pass函數將瀏覽器請求轉發給它背后的Node.js服務。  

 

隧道代理 

 

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

 

HTTP客戶端通過CONNECT方法請求隧道代理建立到任意目的服務器和端口的TCP連接，在客戶端和服務器之間盲目轉發后續數據。  

 

下圖同樣來自《HTTP權威指南》，直觀地展示了上述行為： 

 

如果我通過代理訪問A網站，瀏覽器首先通過CONNECT請求請求代理建立到A網站的TCP連接； 一旦TCP連接建立，代理就可以不假思索地轉發后續流量。 所以這種代理理論上適用于任何基于TCP的應用層協議。 當然也可以使用HTTPS網站使用的TLS協議。 這就是為什么這種代理被稱為隧道的原因。  （部分轉載）