TCP/IP協議族

TCP/IP(Transmission Control Protocol/InternetProtocol，傳輸控制協議/網際協議)是用於計算機通訊的一個協議族。 TCP/IP協議族包括諸如Internet協議(IP)、地址解析協議(ARP)、網際網路控制資訊協議(ICMP)、使用者資料報協議(UDP)、傳輸控制協議(TCP)、路由資訊協議(RIP)、Telnet、簡單郵件傳輸協議(SMTP)、域名系統(DNS)等協議。

1. 應用層 應用層包含一切與應用相關的功能，我們經常使用的HTTP、FTP，Telnet、SMTP等協議都在這一層實現。

2. 傳輸層 傳輸層負責提供可靠的傳輸服務。在該層中，典型的協議是TCP(Transmission Control Protocol)和UDP(User Datagram Protocol)。其中，TCP提供可靠、有序的，面向連線的通訊服務；而UDP則提供無連線的、不可靠使用者資料報服務。

3. 網際層 網際層負責網路間的定址和資料傳輸，在該層中，典型的協議是IP(Internet Protocol)。

4. 網路介面層 最下面一層是網路介面層，負責資料的實際傳輸.網路介面層在傳送端將上層的IP資料報封裝成幀後傳送到網路上；資料幀通過網路到達接收端時，該結點的網路介面層對資料幀拆封，並檢查幀中包含的MAC地址。如果該地址就是本機的MAC地址或者是廣播地址，則上傳到網路層，否則丟棄該幀。

圖1 TCP/IP協議棧

協議概述

HTTP是一個客戶端終端（使用者）和伺服器端（網站）請求和應答的標準（TCP）。通過使用Web瀏覽器、網路爬蟲或者其它的工具，客戶端發起一個HTTP請求到伺服器上指定埠（預設

埠為80）。我們稱這個客戶端為使用者代理程式（user agent）。應答的伺服器上儲存著一些資源，比如HTML檔案和影象。我們稱這個應答伺服器為源伺服器（origin server）。在使用者代理和源伺服器中間可能存在多個中間層，比如代理，閘道器，或者隧道（tunnel）。

儘管TCP/IP協議是網際網路上最流行的應用，HTTP協議中，並沒有規定必須使用它或它支援的層。事實上，HTTP可以在任何網際網路協議上，或其他網路上實現。HTTP假定其下層協議提供可靠的傳輸。因此，任何能夠提供這種保證的協議都可以被其使用。因此也就是其在TCP/IP協議族使用TCP作為其傳輸層。

通常，由HTTP客戶端發起一個請求，建立一個到伺服器指定埠（預設是80埠）的TCP連線。HTTP伺服器則在那個埠監聽客戶端的請求。一旦收到請求，伺服器會向客戶端返回一個狀態，比如"HTTP/1.1 200 OK"，以及返回的內容，如請求的檔案、錯誤訊息、或者其它資訊。

請求資訊（Request Message）

發出的請求資訊包括以下幾個

·1. 請求行

例如GET /images/logo.gif HTTP/1.1，表示從/images目錄下請求logo.gif這個檔案。

2. 請求頭

例如Accept-Language: en

3. 空行

4. 其他訊息體

請求行和標題必須以<CR><LF>作為結尾。空行內必須只有<CR><LF>而無其他空格。在HTTP/1.1協議中，所有的請求頭，除Host外，都是可選的。

請求方法

HTTP/1.1協議中共定義了八種方法（也叫“動作”）來以不同方式操作指定的資源：

1. OPTIONS：這個方法可使伺服器傳回該資源所支援的所有HTTP請求方法。用'*'來代替資源名稱，向Web伺服器傳送OPTIONS請求，可以測試伺服器功能是否正常運作。

2. HEAD：與GET方法一樣，都是向伺服器發出指定資源的請求。只不過伺服器將不傳回資源的本文部份。它的好處在於，使用這個方法可以在不必傳輸全部內容的情況下，就可以獲取其中“關於該資源的資訊”（元資訊或稱元資料）。

3. GET：向指定的資源發出“顯示”請求。使用GET方法應該只用在讀取資料，而不應當被用於產生“副作用”的操作中，例如在Web Application中。其中一個原因是GET可能會被網路蜘蛛等隨意訪問。參見安全方法

4. POST：向指定資源提交資料，請求伺服器進行處理（例如提交表單或者上傳檔案）。資料被包含在請求本文中。這個請求可能會建立新的資源或修改現有資源，或二者皆有。

5. PUT：向指定資源位置上傳其最新內容。

6. DELETE：請求伺服器刪除Request-URI所標識的資源。

7. TRACE：回顯伺服器收到的請求，主要用於測試或診斷。

8. CONNECT：HTTP/1.1協議中預留給能夠將連線改為管道方式的代理伺服器。通常用於SSL加密伺服器的連結（經由非加密的HTTP代理伺服器）。

方法名稱是區分大小寫的。當某個請求所針對的資源不支援對應的請求方法的時候，伺服器應當返回狀態碼405（Method Not Allowed），當伺服器不認識或者不支援對應的請求方法的時候，應當返回狀態碼501（Not Implemented）。

HTTP伺服器至少應該實現GET和HEAD方法，其他方法都是可選的。當然，所有的方法支援的實現都應當符合下述的方法各自的語義定義。此外，除了上述方法，特定的HTTP伺服器還能夠擴充套件自定義的方法。例如：

 PATCH（由RFC5789指定的方法）:用於將區域性修改應用到資源。

HTTPS

目前有兩種方法來建立安全超文字協議連線：HTTPS URI方案和HTTP 1.1請求頭（由RFC2817引入）。由於瀏覽器對後者的幾乎沒有任何支援，因此HTTPS URI方案仍是建立安全超文字協議連線的主要手段。安全超文字連線協議使用https://代替http://

安全方法

對於GET和HEAD方法而言，除了進行獲取資源資訊外，這些請求不應當再有其他意義。也就是說，這些方法應當被認為是“安全的”。 客戶端可能會使用其他“非安全”方法，例如POST，PUT及DELETE，應該以特殊的方式（通常是按鈕而不是超連結）告知客戶可能的後果（例如一個按鈕控制的資金交易），或請求的操作可能是不安全的（例如某個檔案將被上傳或刪除）。

但是，不能想當然地認為伺服器在處理某個GET請求時不會產生任何副作用。事實上，很多動態資源會把這作為其特性。這裡重要的區別在於使用者並沒有請求這一副作用，因此不應由使用者為這些副作用承擔責任。

副作用

假如在不考慮諸如錯誤或者過期等問題的情況下，若干次請求的副作用與單次請求相同或者根本沒有副作用，那麼這些請求方法就能夠被視作“冪等”的。GET，HEAD，PUT和DELETE方法都有這樣的冪等屬性，同樣由於根據協議，OPTIONS，TRACE都不應有副作用，因此也理所當然也是冪等的。

假如某個由若干個請求做成的請求序列產生的結果在重複執行這個請求序列或者其中任何一個或多個請求後仍沒有發生變化，則這個請求序列便是“冪等”的。但是，可能出現若干個請求做成的請求序列是“非冪等”的，即使這個請求序列中所有執行的請求方法都是冪等的。例如，這個請求序列的結果依賴於某個會在下次執行這個序列的過程中被修改的變數。

版本

超文字傳輸協議已經演化出了很多版本，它們中的大部分都是向下相容的。在RFC2145中描述了HTTP版本號的用法。客戶端在請求的開始告訴伺服器它採用的協議版本號，而後者則在響應中採用相同或者更早的協議版本。

HTTP/0.9

已過時。只接受GET一種請求方法，沒有在通訊中指定版本號，且不支援請求頭。由於該版本不支援POST方法，因此客戶端無法向伺服器傳遞太多資訊。

HTTP/1.0

這是第一個在通訊中指定版本號的HTTP協議版本，至今仍被廣泛採用，特別是在代理伺服器中。

HTTP/1.1

當前版本。持久連線被預設採用，並能很好地配合代理伺服器工作。還支援以管道方式在同時傳送多個請求，以便降低線路負載，提高傳輸速度。

HTTP/1.1相較於HTTP/1.0協議的區別主要體現在：

·                   快取處理

·                   頻寬優化及網路連線的使用

·                   錯誤通知的管理

·                   訊息在網路中的傳送

·                   網際網路地址的維護

·                   安全性及完整性

狀態碼

所有HTTP響應的第一行都是狀態行，依次是當前HTTP版本號，3位數字組成的狀態程式碼，以及描述狀態的短語，彼此由空格分隔。

狀態程式碼的第一個數字代表當前響應的型別：

·                   1xx訊息——請求已被伺服器接收，繼續處理

·                   2xx成功——請求已成功被伺服器接收、理解、並接受

·                   3xx重定向——需要後續操作才能完成這一請求

·                   4xx請求錯誤——請求含有詞法錯誤或者無法被執行

·                   5xx伺服器錯誤——伺服器在處理某個正確請求時發生錯誤

雖然RFC2616中已經推薦了描述狀態的短語，例如"200 OK"，"404 Not Found"，但是WEB開發者仍然能夠自行決定採用何種短語，用以顯示本地化的狀態描述或者自定義資訊。

持續連線

在HTTP 0.9和1.0使用非持續連線，在非持續連線下，每個tcp只連線一個web物件，連線在每個請求-迴應對後都會關閉，一個連線可被多個請求重複利用的保持連線機制被引入。這種連線持續化顯著地減少了請求延遲，因為客戶不用在首次請求後再次進行TCP互動確認建立連線。現在在HTTP 1.1使用持續連線，不必為每個web物件建立一個新的連線，一個連線可以傳送多個物件。 HTTP1.1還進行了頻寬優化，例如1.1引入了分塊傳輸編碼來允許流化傳輸持續連線上傳送的內容，取代原先的buffer式傳輸。HTTP管道允許客戶在上一個迴應被收到前傳送多重請求從而進一步減少了延遲時間。

另一項協議的改進是byte serving（位元組服務），允許伺服器根據客戶的請求僅僅傳輸資源的一部分。

協議例子

基本HTTP協議

下面是一個HTTP客戶端與伺服器之間會話的例子，運行於www.google.com，埠80

客戶端請求：

GET / HTTP/1.1

Host:www.google.com

（末尾有一個空行。第一行指定方法、資源路徑、協議版本；第二行是在1.1版裡必帶的一個header作用指定主機）

伺服器應答：

HTTP/1.1 200 OK

Content-Length: 3059

Server: GWS/2.0

Date: Sat, 11 Jan 2003 02:44:04 GMT

Content-Type: text/html

Cache-control: private

Set-Cookie:PREF=ID=73d4aef52e57bae9:TM=1042253044:LM=1042253044:S=SMCc_HRPCQiqy

X9j; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/;domain=.google.com

Connection: keep-alive

（緊跟著一個空行，並且由HTML格式的文字組成了Google的主頁）

AJAX應用例項

AJAX即“Asynchronous JavaScript and XML”（非同步的JavaScript與XML技術），指的是一套綜合了多項技術的瀏覽器端網頁開發技術。傳統的Web應用允許使用者端填寫表單（form），當提交表單時就向Web伺服器傳送一個請求。伺服器接收並處理傳來的表單，然後送回一個新的網頁，但這個做法浪費了許多頻寬，因為在前後兩個頁面中的大部分HTML碼往往是相同的。由於每次應用的溝通都需要向伺服器傳送請求，應用的迴應時間依賴於伺服器的迴應時間。這導致了使用者介面的迴應比本機應用慢得多。與此不同，AJAX應用可以僅向伺服器傳送並取回必須的資料，並在客戶端採用JavaScript處理來自伺服器的迴應。因為在伺服器和瀏覽器之間交換的資料大量減少,伺服器迴應更快了。同時，很多的處理工作可以在發出請求的客戶端機器上完成，因此Web伺服器的負荷也減少了。AJAX不是指一種單一的技術，而是有機地利用了一系列相關的技術。雖然其名稱包含XML，但實際上資料格式可以由JSON代替，進一步減少資料量，形成所謂的AJAJ。一句話，AJAX基於HTTP協議。

程式碼清單test.html:

<script src="jquery.js"></script> <!-- Javascript --> <script type="text/javascript"> $(document).ready(function (){     $("#btn392").click(function(){             var url = "http://www.pureexample.com/backend/ajax_crossdomain.aspx";               //var url = "http://127.0.0.1:5000";            //[{    "Manufacturer": "HUMMER",    "Sold": 120,    "Month": "2012-11"}]            var success = function(data){             var html = [];             data = $.parseJSON(data); /* parse JSON */             /* loop through array */             $.each(data, function(index, d){                            html.push("Manufacturer : ", d.Manufacturer, ", ",                           "Sold : ", d.Sold, ", ",                           "Month : ", d.Month, "<br>");             });             $("#div391").html(html.join('')).css("background-color", "orange");         };         $.ajax({           type: 'GET',              url: url,           data:{todo:"jsonp"},           dataType: "jsonp",           crossDomain: true,                    cache:false,           success: success,           error:function(jqXHR, textStatus, errorThrown){             alert(errorThrown);           }         });     }); }); </script> <!-- HTML --> <a name="#jsonp-ajax"></a> <div id="example-section39">        <div>Car sale report</div>     <div id="div391"></div>     <button id="btn392" type="button">Click </button> </div>

普通情況下雙向抓包資訊：

GET /backend/ajax_crossdomain.aspx?callback=jQuery111006746286363340914_1393568973731&todo=jsonp&_=1393568973732HTTP/1.1

Host: www.pureexample.com

Connection:keep-alive

Accept: */*

User-Agent:Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) UbuntuChromium/31.0.1650.63 Chrome/31.0.1650.63 Safari/537.36

Accept-Encoding:gzip,deflate,sdch   /* 回包壓縮 */

Accept-Language:zh-CN,zh;q=0.8,en;q=0.6

Cookie:__cfduid=da94308c9f886169fb62c872c48d44e7c1393554685481

HTTP/1.1 200 OK

Server:cloudflare-nginx

Date: Fri, 28 Feb2014 06:31:01 GMT

Content-Type:text/html; charset=utf-8

Transfer-Encoding:chunked

Connection:keep-alive

Cache-Control:private

Vary:Accept-Encoding

Set-Cookie:ASP.NET_SessionId=yofjwnenn0cs5ijxx1jrdq55; path=/; HttpOnly

X-AspNet-Version:2.0.50727

X-Powered-By:ASP.NET

X-Powered-By-Plesk:PleskWin

CF-RAY:103b11cb0d290378-LAX

Content-Encoding:gzip

78     /* chunck大小為0x78位元組*/

........... /* 回包為壓縮形式 */

,M-.4444003713.0363661.44.74.465..47676.P..V..%..........."%+.%.P__.%..dp~N

P........+...2204.54T..U.......

a

...t..t...

0

通過分析雙向的資料包可以看出，若請求頭的Accept-Enconding為gzip，則服務端的回包會以壓縮資料的形式回傳。

去掉壓縮雙向抓包資訊：

GET /backend/ajax_crossdomain.aspx?callback=jQuery111007808388310950249_1393570158984&todo=jsonp&_=1393570158985HTTP/1.0

Host:www.pureexample.com

Connection:keep-alive

Accept: */*

User-Agent:Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) UbuntuChromium/31.0.1650.63 Chrome/31.0.1650.63 Safari/537.36

Via: 1.1mtnproxy                

Accept-Language:zh-CN,zh;q=0.8,en;q=0.6

Cookie:__cfduid=da94308c9f886169fb62c872c48d44e7c1393554685481;ASP.NET_SessionId=yofjwnenn0cs5ijxx1jrdq55

HTTP/1.1 200 OK

Server:cloudflare-nginx

Date: Fri, 28 Feb2014 06:50:16 GMT

Content-Type:text/html; charset=utf-8

Connection: close

Cache-Control:private

X-AspNet-Version:2.0.50727

X-Powered-By:ASP.NET

X-Powered-By-Plesk:PleskWin

CF-RAY:103b2dfbb05c0378-LAX

jQuery111007808388310950249_1393570158984('[{    "Manufacturer":"HUMMER",    "Sold":120,    "Month":"2012-11"}]')

通過分析雙向的資料包可以看出，若請求頭無Accept-Enconding資訊，則服務端的回包會以普通形式回傳。如果HTTP請求頭為HTTP/1.0則，迴應資訊無Content-Length或CHUNCK的資訊欄位。

組成要素

HTTP協議的展示，需要4個基本的要素，包括一個規範即http協議本身以及三個實體，即資原始檔、web伺服器，瀏覽器。http協議規範了客戶端與伺服器之間資料互動的格式；資原始檔包括html，js，css，等展示檔案；web伺服器用於儲存資原始檔，並響應瀏覽器的資原始檔請求；瀏覽器從web伺服器上請求資原始檔，並解析展示。

圖2 組成元素

如圖1所示，web伺服器接入於公網，ip地址為61.155.154.42， url為www.demo.com。 資原始檔包括index.html，index.js，index.css，others位於伺服器的虛擬根目錄下，index.html索引檔案index.js，index.css。

圖3 資原始檔

若使用者在瀏覽器的位址列中輸入www.demo.com並回車鍵確認，則將觸發以下流程：

·                   瀏覽器所在客戶端主機通過DNS查詢，獲取www.demo.com所對應的ip地址，並作為客戶端與該ip地址對應的服務端建立http連線

·                   瀏覽器向伺服器發起http根請求，瀏覽器從本機取出根檔案index.html並回應瀏覽器

·                   瀏覽器從根請求迴應中解析index.html檔案中所引入的資原始檔列表index.js，index.css等檔案

·                   瀏覽器再次分別向伺服器發起index.js，index.css等檔案請求

·                   瀏覽器獲取所有檔案之後，解析渲染出所有資原始檔，提供ui介面給使用者

   

         圖4 資源獲取流程

代理服務

通過以上描述，我們知道，http代理伺服器即是一個http協議的中繼。其所完成的任務是插入瀏覽器與伺服器之間的通訊，截獲瀏覽器的http請求，並模擬瀏覽器向伺服器發起http請求，並把伺服器的http迴應，轉回應於瀏覽器。這個動作對應瀏覽器來說，是透明的，但是對於開發者來說，可以在代理伺服器上做手腳，修改雙向的報文。可以通過兩種方式來實現http代理，其一為應用程式代理，其二tcp代理，其特徵分別為：

·                   應用層代理，瀏覽器與代理伺服器，代理伺服器與伺服器兩個通訊組隊之間，分別建立tcp連線，並進行tcp資料傳輸。代理伺服器與瀏覽器握手之後，截獲瀏覽器發出的GET報文，獲取HOST欄位與伺服器握手，並把GET報文進行處理之後，轉發給伺服器，等待伺服器的回包，並轉發給瀏覽器。整個流程可以在應用層完成。

圖5 應用層代理伺服器

可以看出代理伺服器對客戶端上來的GET報文有修改：1）HTTP/1.1修改為HTTP/1.0, 這樣修改有兩個作用，伺服器對HTTP/1.0請求的迴應報文沒有Content-Length, 或CHUNCK的標示，而這兩個標示與應用程式資料的長度相關，如果採用HTTP/1.1的請求，則在修改伺服器的回包之後（回包長度發生變化），需要重新修改Content-Length或CHUNCK兩個屬性的值，而這兩個值的修改增加了開發的難度；其二，伺服器對HTTP/1.0迴應不會保持長連線，即圖中伺服器響應index.html之後，tcp連線關閉，這樣對於代理軟體來說，軟體容易穩定，降低了開發難度。

·                   TCP層代理

Ø         TCP報文插入

在TCP層做報文注入，涉及到了修改報文雙向sequence, ack-sequence值的問題。原因在於seq值與ack值與實際報文長度相關，如果修改了報文長度，顯然需要修改seq, ack值：

圖6 TCP之SEQ與ACK

Ø         TCP層代理報文插入

如圖7所示，代理需要維護兩個狀態機，收到服務端帶fin報文的資料包之後，和服務端完成結束握手；同時去除fin報文的fin標誌，把改報文發給瀏覽器，同時完成和瀏覽器的報文插入以及結束握手：

圖7 TCP之SEQ與ACK

Ø        TCP層代理狀態機

1.       Eth0收到http報文的結束幀（帶fin） 

 

2.     代理去掉fin標誌

3.      代理插入一段報文，並加上fin標誌

4.      瀏覽器對原始的http結束報文迴應fin

問題：看起來伺服器到瀏覽器的fin報文，並沒有被代理扔掉，故而瀏覽器收到了兩幀fin報文。