全面了解TCP/IP到HTTP

02-24

一、OSI參考模型

OSI（Open System Interconnect），即開放式系統互聯。一般都叫OSI參考模型，是ISO（國際標準化組織）組織在1985年研究的網路互聯模型。該體系結構標準定義了網路互連的七層框架（物理層、數據鏈路層、網路層、傳輸層、會話層、表示層和應用層），即ISO開放系統互連參考模型。在這一框架下進一步詳細規定了每一層的功能，以實現開放系統環境中的互連性、互操作性和應用的可移植性。

二、TCP/IP四層協議系統

TCP/IP是一組不同層次上的多個協議的組合,通常被認為是一個四層協議系統。

- 鏈路層，有時也稱作數據鏈路層或網路介面層，通常包括操作系統中的設備驅動程序和計算機中對應的網路介面卡。它們一起處理與電纜（或其他任何傳輸媒介）的物理介面細節。

- 網路層，有時也稱作互聯網層，處理分組在網路中的活動，例如分組的選路。在TCP/IP協議族中，網路層協議包括IP網際協議，ICMP互聯網控制報文協議，以及IGMP組管理協議。

- 傳輸層，主要為兩台主機上的應用程序提供端到端的通信。在TCP/IP協議族中，有兩個互不相同的傳輸協議：TCP（傳輸控制協議）和UDP（用戶數據報協議）。TCP為兩台主機提供高可靠性的數據通信。它所做的工作包括把應用程序交給它的數據分

成合適的小塊交給下面的網路層，確認接收到的分組，設置發送最後確認分組的超時時鐘等。由於傳輸層提供了高可靠性的端到端的通信，因此應用層可以忽略所有這些細節。而另一方面，UDP則為應用層提供一種非常簡單的服務。它只是把稱作數據報的分組從一台主機發送到另一台主機，但並不保證該數據報能到達另一端。任何必需的可靠性必須由應用層來提供。這兩種運輸層協議分別在不同的應用程序中有不同的用途。

- 應用層負責處理特定的應用程序細節。幾乎各種不同的TCP/IP實現都會提供這些通用的應用程序：Telnet遠程登錄、FTP文件傳輸協議、SMTP簡單郵件傳送協議、SNMP簡單網路管理協議。

我們需要知道TCP在不可靠的IP層上提供了一個可靠的運輸層，這樣就不會在後面介紹IP協議的時候出現模糊，TCP採用了超時重傳、發送和接收端到端的確認分組等機制。

鏈路層

鏈路層協議是Internet協議族中的最底層協議。在TCP/IP協議中，鏈路層主要有三個作用：（1）發送和接收IP數據報（2）發送APR請求和接收APR應答（3）發送RAPR請求和接收RAPR應答。在這裡我們還需要知道乙太網和802封裝，乙太網是指數字設備公司在1 9 8 2年聯合公布的一個標準也是當今 T C P / I P採用的主要的區域網技術，802標準指的是IEEE（電子電氣工程師協會）802委員會公布的一個稍有不同的標準集，802.3標準定義了幀和乙太網的幀都有最小長度要求。

串列線路IP（SLIP）

這是一種在串列線路上對IP數據報進行封裝的一種形式，這個協議定義了固定的數據幀格式，規定IP數據報以一個稱作END(0XC0)的特殊字元結束，為了防止線路雜訊也被當成數據報內容，所以一般在數據報開始的時候也傳入一個END字元；如果IP報文中的某個字元為END那麼需要連續傳輸兩個字元0xdb和0xdc來取代它，0xdb這個字元被稱作SLIP的ESC字元。SLIP是一種簡單的封裝，它有一些缺陷：每一端必須知道對方的IP地址；一條串列線路如果使用了SLIP協議那麼它將不能同時使用其他協議；而且SLIP沒用在數據幀加上檢驗，所以說報文因受到影響而發生錯誤只能通過上層協議來發現。在目前SLIP是一種廣泛使用的協議。由於串列線路的速率較低，並且SLIP在性能上也有一些缺陷，後期提出了一個CSLIP（壓縮SLIP）新協議參考RFC 1144。

點對點協議PPP

點對點協議修改了SLIP中的缺陷，PPP既支持數據為 8位和無奇偶檢驗的非同步模式

（如大多數計算機上都普遍存在的串列介面），還支持面向比特的同步鏈接；它允許通信雙方進行協商，以確定不同的選項；允許雙方商定是否對報文首部進行壓縮。PPP協議要比SLIP協議有更多的優點，但是目前SLIP的用戶仍然要多於PPP用戶。

環回介面

環回介面用來允許運行在同一台主機上的客戶程序和伺服器程序通過TCP/IP進行通信，A類網路號127就是為環回介面預留的。根據慣例，大多數系統把IP地址127.0.0.1分配給這個介面，並命名為localhost。一個傳給環回介面的IP數據報不能在任何網路上出現。傳給環回地址（一般是127.0.0.1）的任何數據均作為IP輸入

最大傳輸單元MTU

我們知道乙太網對數據幀的長度都有一個限制，鏈路層的這個特性被稱為MTU，不同類型的網路都有一個上限，如果IP層有一個數據報要傳，而且數據的長度比鏈路層的MTU還大，那麼IP層就需要進行分片，把數據報分成若干片，這樣每一片都小於MTU。當在同一個網路上的兩台主機互相進行通信時，該網路的MTU是非常重要的。但是如果兩台主機之間的通信要通過多個網路，那麼每個網路的鏈路層就可能有不同的MTU。重要的不是兩台主機所在網路的MTU的值，重要的是兩台通信主機路徑中的最小MTU。它被稱作路徑MTU，它取決於所選擇的路由。

IP網際協議

IP是網路層上的主要協議，同時被TCP和UDP使用。TCP和UDP的每組數據都通過端系統和每個中間路由器中的IP層在互聯網中進行傳輸。IP協議是TCP/IP協議族中最核心的協議。它是一個不可靠的、無連接的協議，TCP、UDP、ICMP以及ICGP都以IP數據報格式傳輸。不可靠的意思是IP僅僅提供最好的傳輸服務，不能保證數據報能成功到達目的地。無連接的意思是並不維護任何關於後續數據報的狀態信息，每個數據報的處理都是相互獨立的，可以不按發送順序接收。這裡我主要解釋下IP首部各個欄位，這也是一個前端需要了解的。

IP首部

普通的IP首部長為20個位元組（不含選項欄位）

首部最高位在左邊，記為0bit；最低位在右邊，記為31bit。4個位元組的32bit值的傳輸：首先是 0～7 bit，其次8～15bit，然後16～23bit，最後是24~31bit。這種傳輸次序稱作網路位元組序，TCP/IP首部中所有的二進位整數在網路中傳輸時都要求以這種次序，以其他形式存儲二進位整數的機器，必須在傳輸數據之前把首部轉換成網路位元組序。目前的協議版本號是4，這也就是我們常說的IPv4。IP數據報的長度稱為總長度欄位，利用首部長度欄位和總長度欄位，就可以知道IP數據報中數據內容的起始位置和長度，一般主機主機要求不能接收超過576位元組的數據報，這個限制不會影響到TCP，因為它會把用戶數據分片，總長度欄位是IP首部中必要的內容。標識欄位唯一地標識主機發送的每一份數據報。通常每發送一份報文它的值就會加1。TTL生存時間欄位設置了數據報可以經過的最多路由器數，初始值由源主機設定，每經過一個處理的路由器它就會減1，該欄位為0時數據報就被丟棄。每一份IP數據報都包含源IP地址和目標IP地址。最後一個欄位是任選項，是數據報中的一個可選信息而且長度可變，包括時間戳、寬鬆的源站選路等等。

子網定址和子網掩碼

目前所有的主機都支持子網編址，不是把IP地址看成由單純的一個網路號和一個主機號組成，而是把主機號再分成一個子網號和一個主機號。除了IP地址以外，主機還需要知道有多少比特用於子網號及多少比特用於主機號。這是在引導過程中通過子網掩碼來確定的，這個掩碼是一個32bit的值，其中值為1的比特留給網路號和子網號，為0的比特留給主機號，給定IP地址和子網掩碼以後，主機就可以確定IP數據報的目標地址，根據子網掩碼可知道子網號與主機號之間的分界線。

ICMP控制報文協議

ICMP經常被認為是IP層的一個組成部分。它傳遞差錯報文以及其他需要注意的信息。

ICMP報文通常被IP層或更高層協議（TCP或UDP）使用。所有報文的前4個位元組都是一樣的，但是剩下的其他位元組則互不相同，ICMP報文格式(見圖ICMP報文3-1)。不的類型由報文中的類型欄位和代碼欄位來共同決定。ICMP報文需要區分時候查詢報文還是差錯報文，而且有時差錯報文需要做特殊處理。

IGMP組管理協議

IGMP組管理協議主要用於用於支持主機和路由器進行多播。IGMP也被當作IP層的一部分，IGMP報文通過IP數據報進行傳輸，有固定的報文長度，沒有可選數據(圖IGMP報文欄位)。多播路由器使IGMP報文來記錄與該路由器相連網路中組成員的變化情況。

UDP用戶數據報協議

UDP是一個簡單的面向數據報的傳輸層協議，進程的每個輸出操作都正好產生一個 UDP數據報，並組裝成一份待發送的IP數據報。UDP不提供可靠性，它把應用程序傳給 IP層的數據發送出去，但是並不保證它們能到達目的地。

UDP首部

埠號表示發送進程和接收進程，UDP長度欄位指的是UDP首部和UDP數據的位元組長度，UDP檢驗和(可選的)覆蓋UDP首部和UDP數據，如圖所示：

UDP數據報最大長度

去除20位元組的IP首部和8個位元組的UDP首部，UDP數據報中用戶數據的最長長度為

65507位元組。但是，大多數實現所提供的長度比這個最大值小。

TCP傳輸控制協議

TCP提供一種面向連接的、可靠的位元組流服務。面向連接意味著兩個應用在彼此交換數據之前必須先建立一個TCP連接。TCP為應用層提供全雙工服務。

TCP通過下列方式來提供可靠性：應用數據被分割成TCP認為最適合發送的數據塊；當TCP發出一個段後，它啟動一個定時器，等待目的端確認收到這個報文段；當TCP收到發自TCP連接另一端的數據，它將發送一個確認，這個確認會有一點延遲；TCP將保持它首部和數據的檢驗和；TCP將對收到的數據進行重新排序，將收到的數據以正確的順序交給應用層；TCP還能提供流量控制。

TCP首部

TCP數據被封裝在一個IP數據報中(如圖TCP1-1所示)

TCP首部(如圖TCP1-2所示)，如果不計任選欄位通常是20個位元組。每個TCP段都包含源端和目的端的埠號，用於尋找發端和收端應用進程。這兩個值加上IP首部中的源端IP地址和目的端IP地址唯一確定一個TCP連接。32位序號用來標識從TCP發送端向TCP接收端發送的數據位元組流，它表示在這個報文段中的的第一個數據位元組。在TCP首部中有6個標誌比特：URG(緊急指針有效) ACK(確認序號有效) PSH(接收方應該儘快將這個報文段交給應用層) RST(重建連接) SYN(同步序號用來發起一個連接) FIN(發端完成發送任務)。

檢驗和覆蓋了整個的TCP報文段：TCP首部和TCP數據。這是一個強制性的欄位，一定是由發送端計算和存儲，並由接收端進行驗證。只有當URG標誌置1時緊急指針才有效。

最常見的可選欄位是最長報文大小，每個連接方通常都在通信的第一個報文段中指明這個選項。TCP報文段中的數據部分是可選的，一個連接建立和一個連接終止時，雙方交換的報文段僅有TCP首部。

TCP的三次握手與四次揮手

當建立一個TCP連接的時候，通過三個報文段來完成連接的建立，這個過程稱為三次握手。(見圖TCP2-1)

(1)請求端（通常稱為客戶端）發送一個SYN段指明客戶打算連接的伺服器的埠，以及初始序號。

(2)伺服器發回包含伺服器的初始序號的SYN報文段作為應答。同時，將確認序號設置為客戶的ISN加1以對客戶的SYN報文段進行確認。一個SYN將佔用一個序號。

(3)客戶必須將確認序號設置為伺服器的ISN加1以對伺服器的SYN報文段進行確認

由於TCP的半關閉，終止一個連接要經過4次握手也就是我們常說的四次揮手。當一方完成它的數據發送任務後就能發送一個FIN來終止這個方向連接。當一端收到一個 FIN，它必須通知應用層另一端幾經終止了那個方向的數據傳送。發送FIN通常是應用層進行關閉的結果。當客戶端關閉連接時將會發送一個FIN，用來關閉從客戶到伺服器的數據傳送當伺服器收到這個FIN，它發回一個ACK，確認序號為收到的序號加 1,同時TCP伺服器還嚮應用程序傳送一個文件結束符,接著這個伺服器程序就關閉它的連接，導致它的TCP端發送一個FIN，客戶必須發回一個確認，並將確認序號設置為收到序號加1(見圖TCP2-2)

TCP的超時與重傳

TCP提供可靠的運輸層。它使用的方法之一就是確認從另一端收到的數據。但數據和確認都有可能會丟失。TCP通過在發送時設置一個定時器來解決這種問題。如果當定時器溢出時還沒有收到確認，它就重傳該數據。

對每個連接，TCP管理4個不同的定時器：(1)重傳定時器使用於當希望收到另一端的確認。(2)persist定時器使窗口大小信息保持不斷流動，即使另一端關閉了其接收窗口。(3)keeplive定時器可檢測到一個空閑連接的另一端何時崩潰或重啟。(4)2MSL定時器測量一個連接處於TIME_WAIT狀態的時間。

三、互聯網的地址及域名

互聯網上的每個介面必須有一個唯一的Internet地址（也稱作IP地址）。IP地址長32 bit。Internet地址並不採用平面形式的地址空間，如1、2、3等。IP地址具有一定的結構，五類不同的互聯網地址格式如下圖所示。

儘管通過IP地址可以識別主機上的網路介面，進而訪問主機，但是人們最喜歡使用的還是主機名。在TCP/IP領域中，域名系統（DNS）是一個分布的資料庫，由它來提供IP地址和主機名之間的映射信息。

四、HTTP超文本傳輸協議

HTTP(超文本傳輸協議)是利用TCP在兩台電腦(通常是Web伺服器和客戶端)之間傳輸信息的協議，是一種無狀態的協議，使用URI(統一資源標識符)定位互聯網上的資源。在兩台計算機之間使用HTTP協議通信時，在一條通信線路上必定有一端是客戶端，另一端則是伺服器端。HTTP協議規定，請求從客戶端發出，最後伺服器端響應該請求並返回。換句話說，肯定是先從客戶端開始建立通信的，伺服器端在沒有接收到請求之前不會發送響應。

HTTP/1.1中的方法

GET方法：獲取資源

來請求訪問已被 URI 識別的資源。指定的資源經伺服器端解析後返迴響應內容。也就是說，如果請求的資源是文本，那就保持原樣返回；如果是像CGI（Common Gateway Interface，通用網關介面）那樣的程序，則返回經過執行後的輸出結果。

POST方法：傳輸實體主體

用來傳輸實體的主體，雖然用GET方法也可以傳輸實體的主體，但一般不用GET方法進行傳輸，而是用POST方法。雖說POST的功能與GET很相似，但POST的主要目的並不是獲取響應的主體內容。

PUT方法：傳輸文件

用來傳輸文件。就像FTP協議的文件上傳一樣，要求在請求報文的主體中包含文件內容，然後保存到請求URI指定的位置。存在安全性問題，因此一般的Web網站不使用該方法。

HEAD方法：獲得報文首部

HEAD方法和GET方法一樣，只是不返回報文主體部分。用於確認URI的有效性及資源更新的日期時間等。

DELETE方法：刪除文件

用來刪除文件，是與PUT相反的方法。DELETE方法按請求URI刪除指定的資源。同樣存在安全性問題，因此一般的Web網站不使用該方法。

OPTIONS方法：詢問支持的方法

用來查詢針對請求 URI 指定的資源支持。

TRACE方法:追蹤路徑

讓Web伺服器端將之前的請求通信環回給客戶端。

CONNECT方法：要求用隧道協議連接代理

要求在與代理伺服器通信時建立隧道，實現用隧道協議進行TCP通信。主要使用SSL（Secure Sockets Layer，安全套接層）和TLS（Transport Layer Security，傳輸層安全）協議把通信內容加密後經網路隧道傳輸。

Cookie

HTTP是無狀態協議，它不對之前發生過的請求和響應的狀態，保留無狀態協議這個特徵的同時又要解決類似的矛盾問題，於是引入了Cookie技術。Cookie技術通過在請求和響應報文中寫入Cookie信息來控制客戶端的狀態。它會根據從伺服器端發送的響應報文內的一個叫做Set-Cookie的首部欄位信息，通知客戶端保存Cookie。當下次客戶端再往該伺服器發送請求時，客戶端會自動在請求報文中加入Cookie值後發送出去。伺服器端發現客戶端發送過來的Cookie後，會去檢查究竟是從哪一個客戶端發來的連接請求，然後對比伺服器上的記錄，最後得到之前的狀態信息。

HTTP狀態碼

狀態碼的職責是當客戶端向伺服器端發送請求時，描述返回的請求結果。藉助狀態碼，用戶可以知道伺服器端是正常處理了請求，還是出現了錯誤。

狀態碼 | 類別 | 原因

---|---|---

1XX | Informational（信息性狀態碼） | 接收的請求正在處理

2XX | Success（成功狀態碼） | 請求正常處理完畢

3XX | Redirection（重定向狀態碼）| 需要進行附加操作以完成請求

4XX | Client Error（客戶端錯誤狀態碼） | 伺服器無法處理請求

5XX | Server Error（伺服器錯誤狀態碼） | 伺服器處理請求出錯

HTTP首部欄位

HTTP首部欄位是構成HTTP報文的要素之一。在客戶端與伺服器之間以HTTP協議進行通信的過程中，無論是請求還是響應都會使用首部欄位，它給瀏覽器和伺服器提供報文主體大小、所使用的語言、認證信息等內容。

HTTP首部欄位是由首部欄位名和欄位值構成的，中間用冒號「:」分隔。HTTP首部欄位根據實際用途被分為以下 4 種類型:

1. 通用首部欄位（General Header Fields）

請求報文和響應報文兩方都會使用的首部。

請求首部欄位（Request Header Fields）

從客戶端向伺服器端發送請求報文時使用的首部。補充了請求的附加內容、客戶端信息、響應內容相關優先順序等信息。

響應首部欄位（Response Header Fields）

從伺服器端向客戶端返迴響應報文時使用的首部。補充了響應的附加內容，也會要求客戶端附加額外的內容信息。

實體首部欄位（Entity Header Fields）

針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的信息。

HTTP通用首部欄位

HTTP請求首部欄位

HTTP響應首部欄位

HTTP實體首部欄位

HTTP報文結構

用於HTTP協議交互的信息被稱為HTTP報文。請求端（客戶端）的HTTP報文叫做請求報文，響應端（伺服器端）的叫做響應報文。HTTP報文本身是由多行數據構成的字元串文本，大致可分為報文首部和報文主體兩塊。

本文大致介紹了TCP/IP與HTTP，給前端開發人員了解，如有興趣可參考專業書籍進行深入探索，有興趣的還可以看看TCP伺服器設計以及T/TCP還有HTTPS，同時歡迎各位指正、交流！