網(wǎng)絡(luò)協(xié)議

網(wǎng)絡(luò)協(xié)議為計算機網(wǎng)絡(luò)中進行數(shù)據(jù)交換而建立的規(guī)則、標(biāo)準(zhǔn)或約定的集合。

網(wǎng)絡(luò)層架構(gòu)

針對五層架構(gòu)分析如下：

image.png

實體層：

負責(zé)物理設(shè)備連接的物理技術(shù)，規(guī)定了網(wǎng)絡(luò)數(shù)據(jù)0，1傳輸?shù)碾娦盘枴?/p>

鏈接層：

在實體層基礎(chǔ)上規(guī)定了0，1分組方式。一組0，1組成一個數(shù)據(jù)包稱為幀，包含標(biāo)頭和數(shù)據(jù)兩部分。
標(biāo)頭：數(shù)據(jù)包的說明，包含發(fā)送者、接收者、數(shù)據(jù)類型等
數(shù)據(jù)：數(shù)據(jù)傳輸?shù)膬?nèi)容

標(biāo)頭中的發(fā)送者和接收者的信息是使用MAC地址的方式進行標(biāo)識，網(wǎng)卡地址就是發(fā)送者和接收者的MAC地址。有了網(wǎng)卡地址就可以定位數(shù)據(jù)傳輸路徑。

網(wǎng)卡之間數(shù)據(jù)的傳輸方式是通過ARP協(xié)議進行的，通過廣播的方式把數(shù)據(jù)包發(fā)送給接收者。在網(wǎng)路中的數(shù)據(jù)包通過解析標(biāo)頭MAC地址與自身MAC地址比較，一致的則為需要為需要接收的數(shù)據(jù)。

網(wǎng)絡(luò)層：

為了解決多個子網(wǎng)絡(luò)之間數(shù)據(jù)傳輸?shù)膯栴}，區(qū)分不同計算機是否屬于同一個子網(wǎng)絡(luò)。規(guī)定網(wǎng)絡(luò)地址的協(xié)議，叫做IP協(xié)議。

區(qū)分不同IP是否屬于同一個子網(wǎng)絡(luò)，引入了子網(wǎng)掩碼。將兩個IP地址與子網(wǎng)掩碼分別進行AND運算（兩個數(shù)位都為1，運算結(jié)果為1，否則為0），然后比較結(jié)果是否相同，如果是的話，就表明它們在同一個子網(wǎng)絡(luò)中，否則就不是。

傳輸層：

為了區(qū)分不同應(yīng)用程序進程的數(shù)據(jù)包，引入了端口參數(shù)。一個端口就標(biāo)識一個使用網(wǎng)卡程序的序號。每個數(shù)據(jù)包都發(fā)到主機的特定端口，所以不同的程序就能取到自己所需要的數(shù)據(jù)。

傳輸層是建立了端口到端口的通信，網(wǎng)絡(luò)層是建立了主機到主機的通信。在傳輸層常用的協(xié)議有TCP UDP協(xié)議，其中UDP協(xié)議只是在原網(wǎng)絡(luò)層協(xié)議上添加了端口標(biāo)頭，它不保證數(shù)據(jù)的準(zhǔn)確接收，可靠性較差。TCP協(xié)議是能夠保證保數(shù)據(jù)不會遺失，TCP發(fā)送的數(shù)據(jù)包需要進行確認回復(fù)。

應(yīng)用層：

應(yīng)用層就是規(guī)定程序的數(shù)據(jù)格式，TCP協(xié)議可以傳輸任意格式的數(shù)據(jù)。就是對網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)部分進行格式的解析規(guī)定。

TCP/IP

UDP：

1. 不提供復(fù)雜的控制機制，利用IP協(xié)議提供面向無連接的通信服務(wù)
2. 無法提供數(shù)據(jù)包丟失重發(fā)，也不進行網(wǎng)絡(luò)阻塞后的流量控制
3. 不保證數(shù)據(jù)包的順序發(fā)送，無法提供亂序糾錯功能
4. 在視頻、消息通訊、多媒體等特定場景下使用

TCP:

1. 面向連接的可靠通信服務(wù)，消息的發(fā)送需要進行確認
2. 根據(jù) TCP 的這些機制，在 IP 這種無連接的網(wǎng)絡(luò)上也能夠?qū)崿F(xiàn)高可靠性的通信（ 主要通過檢驗和、序列號、確認應(yīng)答、重發(fā)控制、連接管理以及窗口控制等機制實現(xiàn)）。

三次握手

TCP是面向連接的通信協(xié)議，也就是在消息通信之前需要做好端到端的準(zhǔn)備工作。建立一個 TCP 連接時需要客戶端與服務(wù)端發(fā)送三個包以確認連接建立。

image.png

• 第一次握手：客戶端發(fā)送SYN確認碼，將標(biāo)識位SYN設(shè)置成1，隨機產(chǎn)生一個值seq=J。將該包發(fā)送給服務(wù)端，客戶端進入SYN_SENT狀態(tài) 等待服務(wù)端響應(yīng)
• 第二次握手：服務(wù)端收到客戶端發(fā)送的SYN確認碼，將SYN和ACK都設(shè)置為1，ack=J+1，并隨機產(chǎn)生一個值seq=K。并將該包發(fā)送給客戶端以確認建立連接，服務(wù)端進入SYN_RCVD狀態(tài)。
• 第三次握手：客戶端收到服務(wù)端的確認狀態(tài)碼，檢查ack是否為J+1，如果是擇將ACK設(shè)置為1，ack=K+1。將該數(shù)據(jù)包發(fā)送給服務(wù)端。服務(wù)端將檢測ack是否為K+1，如果正確則建立連接成功，客戶端和服務(wù)端進入ESTABLISHED狀態(tài)，可以進行數(shù)據(jù)傳輸。

四次揮手

TCP連接是全雙工的，可以由客戶端或服務(wù)端任一方執(zhí)行斷開TCP連接。原則上由一方發(fā)送完數(shù)據(jù)后，發(fā)送FIN碼確認該方向無數(shù)據(jù)傳輸。當(dāng)另外一方也發(fā)送 FIN碼 則TCP連接斷開。

image.png

• 第一次揮手：客戶端發(fā)送FIN=M ，用來關(guān)閉客戶端到服務(wù)端的數(shù)據(jù)傳輸服務(wù)?？蛻舳诉M入FIN_WAIT_1狀態(tài)，標(biāo)示客戶端沒有數(shù)據(jù)發(fā)送給服務(wù)端了
• 第二次揮手：服務(wù)端收到客戶端的FIN斷開碼時，會發(fā)送ack=M+1 確認收到斷開請求。通知客戶端已經(jīng)收到關(guān)閉確認請求，但服務(wù)端還沒發(fā)送完數(shù)據(jù)。服務(wù)端進入CLOSE_WAIT狀態(tài)，客戶端進入FIN_WAIT_2狀態(tài)，等待服務(wù)端發(fā)送FIN碼。
• 第三次揮手：服務(wù)端發(fā)送FIN=N斷開狀態(tài)碼，標(biāo)示服務(wù)端沒有數(shù)據(jù)發(fā)送給客戶端了，準(zhǔn)備好關(guān)閉連接了。服務(wù)端進入LAST_ACK狀態(tài)
• 第四次揮手：客戶端收到服務(wù)端FIN=N斷開碼后，確認服務(wù)端連接斷開請求。發(fā)送ACK=1，ack=N+1 確認碼后進入TIME_WAIT狀態(tài)，等待確認服務(wù)端連接斷開?？蛻舳说却?MSL后依然沒有收到回復(fù)，則證明服務(wù)器端已正常關(guān)閉，然后關(guān)閉客戶端連接。

HTTP

HTTP協(xié)議是建立在應(yīng)用層的超文本傳輸協(xié)議，是用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳輸協(xié)議。

HTTP 工作過程

HTTP存在兩個角色，客戶端和服務(wù)器。基于請求和響應(yīng)的一次完整的通信過程。

• 建立TCP連接：在HTTP協(xié)議工作之前先要通過TCP協(xié)議建立客戶端與服務(wù)器的連接。
• 客戶端發(fā)送請求：建立完TCP連接后，客戶端可以向服務(wù)器發(fā)送請求命令，例如：GET/sample/hello.jsp HTTP/1.1
• 客戶端發(fā)送請求頭：客戶端發(fā)送其請求命令之后，還要以頭信息的形式向服務(wù)器發(fā)送一些別的信息
• 服務(wù)端響應(yīng)：服務(wù)端會響應(yīng)客戶端的請求命令，例如HTTP/1.1 200 OK 響應(yīng)的協(xié)議號和響應(yīng)狀態(tài)碼
• 服務(wù)器返回響應(yīng)頭：服務(wù)端會返回想用客戶端報文的數(shù)據(jù)文檔
• 服務(wù)器向客戶端發(fā)送數(shù)據(jù)：以 Content-Type 響應(yīng)頭信息所描述的格式發(fā)送用戶所請求的實際數(shù)據(jù)
• 服務(wù)器關(guān)閉 TCP 連接：一般情況下，服務(wù)端發(fā)送完響應(yīng)數(shù)據(jù)后，就會關(guān)閉TCP連接。但如果在請求頭或響應(yīng)頭中設(shè)置Connection:keep-alive時，TCP 連接在發(fā)送后將仍然保持打開狀態(tài)，客戶端可以繼續(xù)通過相同的連接發(fā)送請求