1. http協(xié)議請求頭
[method] [uri] [version]\r\n
Host: www.example.com\r\n
Connection: keep-alive\r\n
...
\r\n
1.1 第一行的字段為請求的：方法，資源地址，協(xié)議版本
http協(xié)議常用的請求方法[method]為
- GET：用于向服務(wù)器請求數(shù)據(jù)；
- POST: 用于向服務(wù)器提交數(shù)據(jù)；
- CONNECT: 用于隧道代理;
- HEAD: 用于向服務(wù)器請求報頭;
資源地址[uri]：一般為URL中去掉域名后剩下的那部分，即瀏覽器地址欄網(wǎng)址中域名之后的內(nèi)容。
http協(xié)議版本[version]: 目前主流版本有HTTP/1.0和HTTP/1.1。
http請求頭中的的換行用的是\r\n, 而非Linux中的換行符\n。以下為一個真實請求頭的示例
GET /index.html HTTP/1.1
Host: www.example.com
Connection: keep-alive
1.2 Host字段為請求的主機域名
早期沒有虛擬主機的概念，一臺服務(wù)器有一個主機名。因此規(guī)定在請求頭的第一行，資源地址只需給出相對地址，不必給出主機名（域名）。但現(xiàn)在一臺服務(wù)器可能提供多個主機服務(wù)，比如一條服務(wù)器同時運行了example.com和example.cn兩個web站點。只給出相對地址，服務(wù)器在收到連接請求后，無法得知該請求是希望與自己哪個web服務(wù)建立連接。因此增加了Host字段[1]。
1.3 Connection字段為連接選項
用于對連接進行說明：說明是保持連接還是關(guān)閉連接等。
早期的http協(xié)議不支持此字段，因此為http提供代理的http代理服務(wù)器自然也不支持此字段。如今互聯(lián)網(wǎng)上比較古老的代理服務(wù)器依然存在。為了兼容早期的http代理服務(wù)器，在客戶端和代理之間又增加了Proxy-Connection字段。關(guān)于此字段此處簡要介紹。
http代理的實現(xiàn)原理是，代理服務(wù)器作為通信中介；客戶端把代理當作他想訪問的服務(wù)器，向代理發(fā)送連接輕求。之后代理收到連接請求，向客戶端真正想訪問的服務(wù)器轉(zhuǎn)發(fā)此連接請求。
使用http代理的客戶端，會主動修改其http請求頭，比如瀏覽器在設(shè)置http代理后，會將請求頭做出如下修改：
GET http://www.example.com/index.html HTTP/1.1
Host: www.example.com
Proxy-Connection: keep-alive
修改內(nèi)容主要是請求頭第一行的URI, 由相對地址變?yōu)榻^對地址。原因同Host字段的產(chǎn)生類似，為了讓代理能夠區(qū)分此連接是希望與哪個主機建立連接。但是這里存在一個疑問：既然有了host字段，為什么還要完整地址？我個人給出兩個可能的理由：
Host字段出現(xiàn)的更晚，起初是通過完整URI解決虛擬主機的問題，后來提出的Host字段更方便，但為了兼容早期的代理服務(wù)器，現(xiàn)在二者同時使用。
Host字段是為了讓服務(wù)器知道，收到的請求是連接自己的哪個主機。而完整URI是讓代理知道客戶端向服務(wù)器的哪個主機發(fā)起連接，二者作用不同。
修改的第二部分是Connection字段，該字段修改為Proxy-Connection。
Proxy-Connection: 用于兼容不支持Connection字段的舊版代理服務(wù)器，因為代理服務(wù)器默認會將所有未知字段原樣轉(zhuǎn)發(fā)，而老舊的代理工具不支持Connection選項。當客戶端發(fā)送Connection: Keep-Alive希望保持連接請求，但是代理無法識別此字段，轉(zhuǎn)發(fā)一次數(shù)據(jù)依然會立即斷開連接。雖然服務(wù)端收到請求且接受保持連接，但代理卻關(guān)閉了連接，會導(dǎo)致連接中斷。因此代理協(xié)議要求將Connection修改為Proxy-Connection，只有識別Proxy-Connection的代理服務(wù)器才能將Proxy-Connection轉(zhuǎn)為Connection發(fā)給服務(wù)端，讓服務(wù)端保持連接。
2. 隧道代理請求頭
2.1 CONNECT方法
隧道代理不同于http代理：http代理是代理服務(wù)器作為中介，獲取到客戶端的數(shù)據(jù)轉(zhuǎn)發(fā)給服務(wù)器端，獲取到服務(wù)端的數(shù)據(jù)轉(zhuǎn)發(fā)給客戶端。其通信過程是客戶端與代理建立http連接，代理和服務(wù)端建立http連接。顯然無法用于https通信：因為https是加密協(xié)議，代理即使使用https協(xié)議代替客戶端與服務(wù)端通信獲取到連接應(yīng)答數(shù)據(jù)，也無法使用https加密發(fā)送給客戶端，因為代理沒有服務(wù)器的證書。此時退而求其次的方式是，代理到客戶端這段轉(zhuǎn)為http通信，可能會降低安全性。當然可以在應(yīng)用層進行加密，依然能保證安全性。但這樣并不是完美的https代理。為了解決此問題，http或者說https增加了CONNECT方法，該方法是請求代理向服務(wù)器建立一條隧道通信。該隧道是在TCP層建立，客戶端與代理建立一條TCP連接，代理再與服務(wù)器建立一條TCP連接。之后客戶端和服務(wù)端在這條TCP連接之上建立一條https連接。
CONNECT www.example.com:443 HTTP/1.1
Host: www.example.com
建立連接的請求頭方法為CONNECT， 地址只需要主機地址，不能再添加具體的資源路徑，因為該請求只是用來建立一條連接，連接建立完成才真正請求數(shù)據(jù)用來通信。
這里說明一下隧道和http直觀上的區(qū)別：隧道所使用的TCP屬于ISO七層網(wǎng)絡(luò)模型的第4層，而http和https協(xié)議處于第7層，所以TCP作為https的底層協(xié)議，https并不會察覺代理的存在。舉個例子：隧道相當于A向C輸送石油，建立了一條A到B的公路，然后建立了一條B到C的公路，之后在這段公路上建立一條A經(jīng)由B到C的油管。而http代理是建立了一條A到B的公路，然后建立了一條A到B的油管；之后建立了一條B到C的公路，再建立了一條B到C的油管。隧道方式AC是油管直連，http方式在B處要有個儲油罐。
3. 移動通信數(shù)據(jù)代理
3. 1 簡述
移動通信提供了wap和net兩種網(wǎng)絡(luò)接入方式，net即直連，和電腦通過網(wǎng)線連接網(wǎng)絡(luò)沒有什么區(qū)別。而wap則是通過代理連接，類比電腦通過路由器聯(lián)網(wǎng)，多臺電腦可以共用一個路由器，多部手機也可共用一個代理，這樣只需要一個ip地址即可讓多個用戶實現(xiàn)通信。對運營商而言wap是節(jié)省資源的一種方式。所以早期的手機默認都是wap方式，但是這樣當一個代理提供接入的用戶過多時，可能導(dǎo)致網(wǎng)速下降。這即是網(wǎng)上盛傳修改接入點能提高網(wǎng)速的原因。但我個人感覺其實影響不大，因為運營商的代理吞吐能力肯定夠高，不會和直連有太大差距。
移動聯(lián)通的wap接入點代理為10.0.0.127
電信的wap接入點代理為10.0.0.200
接入點代理地址相當于路由器ip：192.168.0.1
3.2 移動接入點cmwap分析[2]
cmwap代理, 在http協(xié)議之上增加了擴展字段X-Online-Host；
移動的網(wǎng)關(guān)代理和http協(xié)議相似，而又同于http代理或隧道代理。
http協(xié)議在不使用代理時才使用相對url，與Host字段拼接為絕對地址。
標準的http代理協(xié)議是在GET 后添加絕對URL，而非相對URL(http協(xié)議在不使用代理時才使用相對url，與Host字段拼接為絕對地址)；
而移動的wap代理GET字段仍是相對URL，但是增加了X-Online-Host字段，通過與X-Online-Host字段拼接為絕對地址。
但是如果GET字段獲取到絕對地址，則不再和X-Online-Host字段拼接。
這就產(chǎn)生了下面這個問題：
假設(shè)我連接的URL為：http://wap.baidu.com/logo.gif?img=http://wap.uc.cn/uc.png
使用移動網(wǎng)關(guān)代理X-Online-Host字段聯(lián)網(wǎng)：
Conection to 10.0.0.172:80
GET /logo.gif?img=http://wap.uc.cn/uc.png HTTP/1.1
Host: wap.baidu.com
X-Online-Host: wap.baidu.com
早期的移動網(wǎng)絡(luò)，這樣的請求到達移動網(wǎng)關(guān)之后，可能會被誤發(fā)至http://wap.baidu.com/uc.png。但是實際上我們想要請求的是http://wap.baidu.com/logo.gif （?之后表示提交內(nèi)容）。
因為，移動網(wǎng)關(guān)實際上就是一個HTTP的代理服務(wù)器，它對于X-Online-Host協(xié)議處理如下：
截取請求頭中的URL字段：
- 如果URL字段沒有域名的話，則將該字段作為相對URI，同X-Online-Host字段進行補全，作為目的地址；
- 如果URL字段有域名的話，則將該字段作為絕對URI，將host替換為X-Online-Host的值。
現(xiàn)在處理方法應(yīng)該已經(jīng)完善，不會再出現(xiàn)此問題。
這里可以看到存在3個位置可以出現(xiàn)域名：
請求頭第一行方法字段；
Host字段；
X-Online-Host字段；
符和移動網(wǎng)關(guān)代理協(xié)議的標準請求，應(yīng)該是方法字段使用無域名的相對地址，Host和X-Online-Host字段使用相同的域名。但是事情往往沒有想象的那么美好：如果我修改請求方法用絕對地址，同時Host和X-Online-Host字段使用兩個不同的域名，將三個域名設(shè)為都不相同。網(wǎng)關(guān)收到此數(shù)據(jù)包會發(fā)生什么，直接丟掉異或是三個地址具有某種優(yōu)先級，選擇優(yōu)先級高的作為目的地址轉(zhuǎn)發(fā)？這個就看各自地區(qū)的運營商如果制定規(guī)則了。
但更有趣的事情不在這里而是下面這個問題，流量費用是由網(wǎng)關(guān)統(tǒng)計的，當網(wǎng)關(guān)轉(zhuǎn)發(fā)目的地址都難以確定時，費用又是如何計算呢？之所以發(fā)出這個疑問，是因為有些訪問特定主機的流量運營商是不收費的，比如訪問運營商官網(wǎng)，又或者現(xiàn)在互聯(lián)網(wǎng)套餐興起，各種定向免流數(shù)據(jù)。也就是說計費也需要知道用戶請求的Host地址。那么計費又是根據(jù)哪個字段，所用的規(guī)則和轉(zhuǎn)發(fā)規(guī)則是相同的么？我想此處是可以給個否定回答的。轉(zhuǎn)發(fā)規(guī)則和計費規(guī)則是不同的!!!
由此我們就可以順理成章的提出一個坊間流傳多年詞匯：免流。相傳2012年就有人運用此漏洞修改UC瀏覽器達到免流的目的。時隔多年，三大運營商或注意到或沒注意到，此問題也在一點點修復(fù)。但是以此作為基礎(chǔ)，免流的手段可以說層出不窮，雖然也在一個個失效。但似乎如同道高一尺魔高一丈般，免流的技術(shù)卻從未中斷。尤其各大互聯(lián)網(wǎng)套餐的出現(xiàn)，讓這淡出視野的東西又浮現(xiàn)出來。當然在這個家家有寬帶處處有wifi的今天，還玩免流的是真不多了。玩也不是圖省那點流量，就是想裝裝13。
附：聯(lián)通大王卡動態(tài)免流腳本，需要手機獲取root權(quán)限，使用RE文件管理器，復(fù)制到系統(tǒng)/system/xbin目錄執(zhí)行即可
https://lanzous.com/iat0glg
