代理服務器是HTTP協議中一個重要的組件，發揮着重要的作用。 關於HTTP代理的文章有很多，本文不再贅述，如果不清楚的可以看一下 HTTP代理的基礎知識。
本文主要介紹代理的事例，分析一個真實的案例來幫助理解HTTP代理的原理。
HTTP代理的原理
下面分析一個 http://iflow.uczzd.cn/iflow/api/v1/client_event?app=uc-iflow...經過代理服務器的HTTP請求。 iflow.uczzd.cn的公網IP是140.205.136.82（各地測試到的IP有可能不同），我的局域網IP是192.168.100.115，代理服務器的IP是192.168.16.35。
再簡單說一下HTTP請求的流程： 192.168.100.115向140.205.136.82發送HTTP請求,其中192.168.16.35是代理服務器。
一、 監控請求
通過網絡監控獲取到的HTTP請求如下：
可以看到在網絡監控中，有兩個HTTP請求，一個是向代理服務器發送的HTTP，另一個是代理服務器想目標服務器發送的HTTP請求。這兩個請求的請求體是一樣的，如下圖：
客戶端向代理服務器發送的HTTP報文：
代理服務器想目標服務器發送的HTTP報文：
二、 推測處理流程
可以看到，兩張圖片的HTTP報文是相同的（也有可能Header不同），我們可以推測出客戶端和代理服務器的處理流程，如下：
客戶端的處理流程：
代理服務器的處理流程：
三、 驗證推測的處理流程
在推測出客戶端和代理服務器的處理邏輯后，我們需要驗證我們的推測是否正確。
我們可以構造一個TCP請求，客戶端連接到代理服務器，發送HTTP報文，報文的內容是客戶端直接發送到服務器的內容。
例如：直接訪問 http://www.cnblogs.com/tgwang/的HTTP報文是：
GET http://www.cnblogs.com/tgwang/ HTTP/1.1
Host: www.cnblogs.com
Connection: close
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36
Referer: http://www.cnblogs.com/
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8
Cookie: ***
If-Modified-Since: Sat, 30 Jan 2016 02:48:23 GMT
我們構造一個TCP請求，連接代理服務器，報文的內容也是發送上面的報文，看代理服務器能否正常請求博客園的數據，如果可以正常請求，說明我們對於客戶端和代理服務器推測是正確的，如果沒有請求博客園數據，而是返回代理服務器的相關信息，表示推測錯誤。
下面我使用python向代理服務器127.0.0.1:8888發送一個TCP請求，為了在代理服務器中能找到此請求，我在Header中增加了一個Token，使用UUID標識（見紅框）。
運行程序，發送TCP請求，報文如下：
查看代理服務器的信息，可知，HTTP請求正常發送到博客園，並且正常響應，如下圖：
到此推測驗證完成，符合預期結果。
書本上的理論看多了，就以為自己看懂了，然而我們真的懂了嗎？沒動手實踐過能算是懂了嗎