普通http代理
傳統的http代理在RFC 7230 - HTTP/1.1: Message Syntax and Routing中定義，其流程如下
-
瀏覽器請求不直接發給目標主機，而是發給代理服務器
-
代理服務器從請求頭中解析並連接目標主機，並轉發請求和響應。
整個過程如下圖所示，
這個代理本質上是一箇中間人角色：對於連接到它的客戶端來說，它是服務端；對於要連接的服務端來說，它是客戶端。它就負責在兩端之間來回傳送 HTTP 報文。
隧道代理
普通http代理存在着一個問題是：代理服務器是一箇中間人角色，它獲取了傳輸內容，並且有修改內容的能力。因此和反中間人的tls協議衝突，因此是不能用此代理訪問https站點的的。因此，一個新的代理模式Tunneling TCP based protocols through Web proxy servers（通過 Web 代理服務器用隧道方式傳輸基於 TCP 的協議）應運而生。
隧道代理的流程本身也比較簡單
-
客戶端連接代理服務器，通過connect協議發送目標主機
-
代理服務器連接到目標主機後，完成connect握手。並對客戶端和服務器之間的後繼數據進行盲轉發
整個流程如下圖：
隧道代理模式下，代理服務器除了目標主機外，無需瞭解任何內容，也無法瞭解任何內容。只是作爲一個透明的管道。
小結
其實綜合這兩種模式，他們的邏輯行爲其實是一樣的
-
根據某種約定獲取目標地址：（普通代理是從http頭，隧道代理是connect命令）
-
完成和目標主機的連接，以及客戶端的握手。（普通代理轉發http頭，隧道代理回覆200報文）
-
作爲隧道轉發兩端流量
進行此抽象後，我們可以發現他其實和sock5代理的邏輯是一樣的，因此可以很方便的實現他們之間的轉換，甚至可以在一個端口上同時支持這三種代理協議（他們的解析方式不衝突）。