TCP/IP協(xié)議族
TCP/IP(傳輸控制協(xié)議/網(wǎng)際協(xié)議)是用于計算機(jī)通信的一個協(xié)議族。
TCP/IP協(xié)議族包括諸如Internet協(xié)議(IP)、地址解析協(xié)議(ARP)、互聯(lián)網(wǎng)控制信息協(xié)議(ICMP)、用戶數(shù)據(jù)報協(xié)議(UDP)、傳輸控制協(xié)議(TCP)、路由信息協(xié)議(RIP)、Telnet、簡單郵件傳輸協(xié)議(SMTP)、域名系統(tǒng)(DNS)等協(xié)議。
1. 應(yīng)用層 應(yīng)用層包含一切與應(yīng)用相關(guān)的功能，我們經(jīng)常使用的HTTP、FTP，Telnet、SMTP等協(xié)議都在這一層實現(xiàn)。
2. 傳輸層 傳輸層負(fù)責(zé)提供可靠的傳輸服務(wù)。在該層中，典型的協(xié)議是TCP(Transmission Control Protocol)和UDP(User Datagram Protocol)。其中，TCP提供可靠、有序的，面向連接的通信服務(wù);而UDP則提供無連接的、不可靠用戶數(shù)據(jù)報服務(wù)。
3. 網(wǎng)際層 網(wǎng)際層負(fù)責(zé)網(wǎng)絡(luò)間的尋址和數(shù)據(jù)傳輸，在該層中，典型的協(xié)議是IP(Internet Protocol)。
4. 網(wǎng)絡(luò)接口層 最下面一層是網(wǎng)絡(luò)接口層，負(fù)責(zé)數(shù)據(jù)的實際傳輸.網(wǎng)絡(luò)接口層在發(fā)送端將上層的IP數(shù)據(jù)報封裝成幀后發(fā)送到網(wǎng)絡(luò)上;數(shù)據(jù)幀通過網(wǎng)絡(luò)到達(dá)接收端時，該結(jié)點的網(wǎng)絡(luò)接口層對數(shù)據(jù)幀拆封，并檢查幀中包含的MAC地址。如果該地址就是本機(jī)的MAC地址或者是廣播地址，則上傳到網(wǎng)絡(luò)層，否則丟棄該幀。
圖1 TCP/IP協(xié)議棧
HTTP是一個客戶端終端(用戶)和服務(wù)器端(網(wǎng)站)請求和應(yīng)答的標(biāo)準(zhǔn)(TCP)。通過使用Web瀏覽器、網(wǎng)絡(luò)爬蟲或者其它的工具，客戶端發(fā)起一個HTTP請求到服務(wù)器上指定端口(默認(rèn)端口為80)。我們稱這個客戶端為用戶代理程序(user agent)。應(yīng)答的服務(wù)器上存儲著一些資源，比如HTML文件和圖像。我們稱這個應(yīng)答服務(wù)器為源服務(wù)器(origin server)。在用戶代理和源服務(wù)器中間可能存在多個中間層，比如代理，網(wǎng)關(guān)，或者隧道(tunnel)。
盡管TCP/IP協(xié)議是互聯(lián)網(wǎng)上最流行的應(yīng)用，HTTP協(xié)議中，并沒有規(guī)定必須使用它或它支持的層。事實上，HTTP可以在任何互聯(lián)網(wǎng)協(xié)議上，或其他網(wǎng)絡(luò)上實現(xiàn)。HTTP假定其下層協(xié)議提供可靠的傳輸。因此，任何能夠提供這種保證的協(xié)議都可以被其使用。因此也就是其在TCP/IP協(xié)議族使用TCP作為其傳輸層。
通常，由HTTP客戶端發(fā)起一個請求，創(chuàng)建一個到服務(wù)器指定端口(默認(rèn)是80端口)的TCP連接。HTTP服務(wù)器則在那個端口監(jiān)聽客戶端的請求。一旦收到請求，服務(wù)器會向客戶端返回一個狀態(tài)，比如"HTTP/1.1 200 OK"，以及返回的內(nèi)容，如請求的文件、錯誤消息、或者其它信息。
圖2 組成元素
如圖，web服務(wù)器接入于公網(wǎng)，ip地址為61.155.154.42， url為www.demo.com。 資源文件包括index.html，index.js，index.css，others位于服務(wù)器的虛擬根目錄下，index.html索引文件index.js，index.cs
若用戶在瀏覽器的地址欄中輸入www.demo.com并回車鍵確認(rèn)，則將觸發(fā)以下流程：
· 瀏覽器所在客戶端主機(jī)通過DNS查詢，獲取www.demo.com所對應(yīng)的ip地址，并作為客戶端與該ip地址對應(yīng)的服務(wù)端建立http連接
· 瀏覽器向服務(wù)器發(fā)起http根請求，瀏覽器從本機(jī)取出根文件index.html并回應(yīng)瀏覽器
· 瀏覽器從根請求回應(yīng)中解析index.html文件中所引入的資源文件列表index.js，index.css等文件
· 瀏覽器再次分別向服務(wù)器發(fā)起index.js，index.css等文件請求
· 瀏覽器獲取所有文件之后，解析渲染出所有資源文件，提供ui接口給用戶
圖4 資源獲取流程
http代理服務(wù)器即是一個http協(xié)議的中繼。其所完成的任務(wù)是插入瀏覽器與服務(wù)器之間的通信，截獲瀏覽器的http請求，并模擬瀏覽器向服務(wù)器發(fā)起http請求，并把服務(wù)器的http回應(yīng)，轉(zhuǎn)回應(yīng)于瀏覽器。這個動作對應(yīng)瀏覽器來說，是透明的，
但是對于開發(fā)者來說，可以在代理服務(wù)器上做手腳，修改雙向的報文。可以通過兩種方式來實現(xiàn)http代理，其一為應(yīng)用程序代理，其二tcp代理，其特征分別為：
應(yīng)用層代理，瀏覽器與代理服務(wù)器，代理服務(wù)器與服務(wù)器兩個通信組隊之間，分別建立tcp連接，并進(jìn)行tcp數(shù)據(jù)傳輸。代理服務(wù)器與瀏覽器握手之后，截獲瀏覽器發(fā)出的GET報文，獲取HOST字段與服務(wù)器握手，并把GET報文進(jìn)行處理之后，轉(zhuǎn)發(fā)給服務(wù)器，等待服務(wù)器的回包，并轉(zhuǎn)發(fā)給瀏覽器。整個流程可以在應(yīng)用層完成。
可以看出代理服務(wù)器對客戶端上來的GET報文有修改
1、HTTP/1.1修改為HTTP/1.0, 這樣修改有兩個作用，服務(wù)器對HTTP/1.0請求的回應(yīng)報文沒有Content-Length, 或CHUNCK的標(biāo)示，而這兩個標(biāo)示與應(yīng)用程序數(shù)據(jù)的長度相關(guān)，如果采用HTTP/1.1的請求，則在修改服務(wù)器的回包之后(回包長度發(fā)生變化)，需要重新修改Content-Length或CHUNCK兩個屬性的值，而這兩個值的修改增加了開發(fā)的難度;
2、服務(wù)器對HTTP/1.0回應(yīng)不會保持長連接，即圖中服務(wù)器響應(yīng)index.html之后，tcp連接關(guān)閉，這樣對于代理軟件來說，軟件容易穩(wěn)定，降低了開發(fā)難度。
TCP層代理
? TCP報文插入
在TCP層做報文注入，涉及到了修改報文雙向sequence, ack-sequence值的問題。原因在于seq值與ack值與實際報文長度相關(guān)，如果修改了報文長度，顯然需要修改seq, ack值：
圖6 TCP之SEQ與ACK
? TCP層代理報文插入
如圖7所示，代理需要維護(hù)兩個狀態(tài)機(jī)，收到服務(wù)端帶fin報文的數(shù)據(jù)包之后，和服務(wù)端完成結(jié)束握手;同時去除fin報文的fin標(biāo)志，把改報文發(fā)給瀏覽器，同時完成和瀏覽器的報文插入以及結(jié)束握手：
圖7 TCP之SEQ與ACK
? TCP層代理狀態(tài)機(jī)
1. Eth0收到http報文的結(jié)束幀(帶fin)
2. 代理去掉fin標(biāo)志
3. 代理插入一段報文，并加上fin標(biāo)志
4.瀏覽器對原始的http結(jié)束報文回應(yīng)fin：
問題：看起來服務(wù)器到瀏覽器的fin報文，并沒有被代理扔掉，故而瀏覽器收到了兩幀fin報文。
聯(lián)系客服
