一、OSI參考模型

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

OSI模型1.png

二、TCP/IP四層協(xié)議系統(tǒng)

TCP/IP是一組不同層次上的多個協(xié)議的組合,通常被認為是一個四層協(xié)議系統(tǒng)。

• 鏈路層，有時也稱作數(shù)據鏈路層或網絡接口層，通常包括操作系統(tǒng)中的設備驅動程序和計算機中對應的網絡接口卡。它們一起處理與電纜（或其他任何傳輸媒介）的物理接口細節(jié)。
• 網絡層，有時也稱作互聯(lián)網層，處理分組在網絡中的活動，例如分組的選路。在TCP/IP協(xié)議族中，網絡層協(xié)議包括IP網際協(xié)議，ICMP互聯(lián)網控制報文協(xié)議，以及IGMP組管理協(xié)議。
• 傳輸層，主要為兩臺主機上的應用程序提供端到端的通信。在TCP/IP協(xié)議族中，有兩個互不相同的傳輸協(xié)議：TCP（傳輸控制協(xié)議）和UDP（用戶數(shù)據報協(xié)議）。TCP為兩臺主機提供高可靠性的數(shù)據通信。它所做的工作包括把應用程序交給它的數(shù)據分
  成合適的小塊交給下面的網絡層，確認接收到的分組，設置發(fā)送最后確認分組的超時時鐘等。由于傳輸層提供了高可靠性的端到端的通信，因此應用層可以忽略所有這些細節(jié)。而另一方面，UDP則為應用層提供一種非常簡單的服務。它只是把稱作數(shù)據報的分組從一臺主機發(fā)送到另一臺主機，但并不保證該數(shù)據報能到達另一端。任何必需的可靠性必須由應用層來提供。這兩種運輸層協(xié)議分別在不同的應用程序中有不同的用途。
• 應用層負責處理特定的應用程序細節(jié)。幾乎各種不同的TCP/IP實現(xiàn)都會提供這些通用的應用程序：Telnet遠程登錄、FTP文件傳輸協(xié)議、SMTP簡單郵件傳送協(xié)議、SNMP簡單網絡管理協(xié)議。

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

TCPIP四層.png

鏈路層

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

1. 串行線路IP（SLIP）

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

2. 點對點協(xié)議PPP

點對點協(xié)議修改了SLIP中的缺陷，PPP既支持數(shù)據為 8位和無奇偶檢驗的異步模式
（如大多數(shù)計算機上都普遍存在的串行接口），還支持面向比特的同步鏈接；它允許通信雙方進行協(xié)商，以確定不同的選項；允許雙方商定是否對報文首部進行壓縮。PPP協(xié)議要比SLIP協(xié)議有更多的優(yōu)點，但是目前SLIP的用戶仍然要多于PPP用戶。

3. 環(huán)回接口

環(huán)回接口用來允許運行在同一臺主機上的客戶程序和服務器程序通過TCP/IP進行通信，A類網絡號127就是為環(huán)回接口預留的。根據慣例，大多數(shù)系統(tǒng)把IP地址127.0.0.1分配給這個接口，并命名為localhost。一個傳給環(huán)回接口的IP數(shù)據報不能在任何網絡上出現(xiàn)。傳給環(huán)回地址（一般是127.0.0.1）的任何數(shù)據均作為IP輸入

4. 最大傳輸單元MTU

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

IP網際協(xié)議

IP是網絡層上的主要協(xié)議，同時被TCP和UDP使用。TCP和UDP的每組數(shù)據都通過端系統(tǒng)和每個中間路由器中的IP層在互聯(lián)網中進行傳輸。IP協(xié)議是TCP/IP協(xié)議族中最核心的協(xié)議。它是一個不可靠的、無連接的協(xié)議，TCP、UDP、ICMP以及ICGP都以IP數(shù)據報格式傳輸。不可靠的意思是IP僅僅提供最好的傳輸服務，不能保證數(shù)據報能成功到達目的地。無連接的意思是并不維護任何關于后續(xù)數(shù)據報的狀態(tài)信息，每個數(shù)據報的處理都是相互獨立的，可以不按發(fā)送順序接收。這里我主要解釋下IP首部各個字段，這也是一個前端需要了解的。

1. IP首部

普通的IP首部長為20個字節(jié)（不含選項字段）

IP協(xié)議1-1.png

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

2. 子網尋址和子網掩碼

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

ICMP控制報文協(xié)議

ICMP經常被認為是IP層的一個組成部分。它傳遞差錯報文以及其他需要注意的信息。
ICMP報文通常被IP層或更高層協(xié)議（TCP或UDP）使用。所有報文的前4個字節(jié)都是一樣的，但是剩下的其他字節(jié)則互不相同，ICMP報文格式(見圖ICMP報文3-1)。不的類型由報文中的類型字段和代碼字段來共同決定。ICMP報文需要區(qū)分時候查詢報文還是差錯報文，而且有時差錯報文需要做特殊處理。

ICMP報文3-1.png

IGMP組管理協(xié)議

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

IGMP報文字段.png

UDP用戶數(shù)據報協(xié)議

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

1. UDP首部

端口號表示發(fā)送進程和接收進程，UDP長度字段指的是UDP首部和UDP數(shù)據的字節(jié)長度，UDP檢驗和(可選的)覆蓋UDP首部和UDP數(shù)據，如圖所示：

UDP首部1-1.png

2. UDP數(shù)據報最大長度

去除20字節(jié)的IP首部和8個字節(jié)的UDP首部，UDP數(shù)據報中用戶數(shù)據的最長長度為
65507字節(jié)。但是，大多數(shù)實現(xiàn)所提供的長度比這個最大值小。

TCP傳輸控制協(xié)議

TCP提供一種面向連接的、可靠的字節(jié)流服務。面向連接意味著兩個應用在彼此交換數(shù)據之前必須先建立一個TCP連接。TCP為應用層提供全雙工服務。

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

1. TCP首部

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

TCP1-1.png

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

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

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

TCP1-2.png

2. TCP的三次握手與四次揮手

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

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

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

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

TCP2-1.png

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

TCP2-2.png

3. TCP的超時與重傳

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

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

三、互聯(lián)網的地址及域名

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

5類互聯(lián)網地址.png

盡管通過IP地址可以識別主機上的網絡接口，進而訪問主機，但是人們最喜歡使用的還是主機名。在TCP/IP領域中，域名系統(tǒng)（DNS）是一個分布的數(shù)據庫，由它來提供IP地址和主機名之間的映射信息。

四、HTTP超文本傳輸協(xié)議

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

HTTP/1.1中的方法

1. GET方法：獲取資源

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

2. POST方法：傳輸實體主體

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

3. PUT方法：傳輸文件

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

4. HEAD方法：獲得報文首部

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

5. DELETE方法：刪除文件

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

6. OPTIONS方法：詢問支持的方法

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

7. TRACE方法:追蹤路徑

讓Web服務器端將之前的請求通信環(huán)回給客戶端。

8. CONNECT方法：要求用隧道協(xié)議連接代理

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

Cookie

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

HTTP狀態(tài)碼

狀態(tài)碼的職責是當客戶端向服務器端發(fā)送請求時，描述返回的請求結果。借助狀態(tài)碼，用戶可以知道服務器端是正常處理了請求，還是出現(xiàn)了錯誤。

HTTP首部字段

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

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

1. 通用首部字段（General Header Fields）

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

2. 請求首部字段（Request Header Fields）

從客戶端向服務器端發(fā)送請求報文時使用的首部。補充了請求的附加內容、客戶端信息、響應內容相關優(yōu)先級等信息。

3. 響應首部字段（Response Header Fields）

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

4. 實體首部字段（Entity Header Fields）

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

HTTP通用首部字段

HTTP通用首部字段.png

HTTP請求首部字段

HTTP請求首部字段.png

HTTP響應首部字段

HTTP響應首部字段.png

HTTP實體首部字段

HTTP實體首部字段.png

HTTP報文結構

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

HTTP報文結構.png

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