TCP/IP四層協(xié)議

imooc

TCP（Transmission Control Protocol 傳輸控制協(xié)議）

TCP協(xié)議是計算機網(wǎng)絡(luò)中非常復(fù)雜的一個協(xié)議。

1. 它解決了以下問題：

(1). TCP協(xié)議可靠傳輸

網(wǎng)絡(luò)環(huán)境復(fù)雜围小，保證數(shù)據(jù)準(zhǔn)確無誤到達

(2). TCP協(xié)議流量控制

感知對方壓力并控制流量（比如網(wǎng)卡性能差異瑰谜，造成接收壓力央碟，TCP可以減緩傳輸酱固，控制流量。感受接收方的壓力）

(3). TCP協(xié)議擁塞控制

感知網(wǎng)絡(luò)壓力并控制發(fā)送速度（如果網(wǎng)絡(luò)出現(xiàn)擁塞兔跌，TCP可以控制發(fā)送速度感受網(wǎng)絡(luò)的壓力）

2. TCP報文

imooc

TCP協(xié)議是面向字節(jié)流的協(xié)議，不管傳輸什么數(shù)據(jù)峡蟋，都需要轉(zhuǎn)成字節(jié)坟桅，再傳輸

3. 應(yīng)用場景

(1). 微信、QQ等APP消息發(fā)送接收

(2). 瀏覽器-服務(wù)器通信

(3). 其他可靠通信的場景

TCP的三次握手與四次揮手

(1). 三次握手

三次握手是建立連接的過程蕊蝗，當(dāng)客戶端向服務(wù)端發(fā)起連接時仅乓，會發(fā)一包連接請求數(shù)據(jù)，過去詢問一下蓬戚，能否與你建立連接方灾，這包數(shù)據(jù)稱為SYN包，如果對端同意連接碌更，則回復(fù)一包SYN+ACK包裕偿，客戶端收到后回復(fù)一包ACK包，連接建立痛单，因為這個過程中互相發(fā)送了三包數(shù)據(jù)嘿棘，所以稱之為“三次握手”

嗶哩嗶哩UP掌芝士

為什么不是三次握手而不是兩次握手？

這是為了防止因為已失效的請求報文旭绒，突然又傳到服務(wù)器引起錯誤鸟妙。三次握手本質(zhì)上是為了解決網(wǎng)絡(luò)信道不可靠的問題，為了在不可靠的信道上建立可靠的連接挥吵。

三次握手之后重父，客戶端和服務(wù)器端都進入到了傳遞數(shù)據(jù)的狀態(tài)。

(2). 傳輸確認(rèn)

一包數(shù)據(jù)有可能會被拆成多包發(fā)送忽匈，如何處理丟包問題房午？

這些數(shù)據(jù)包到達的先后順序不同，如何處理亂序問題丹允？

針對這些問題郭厌，TCP協(xié)議為每一個連接，建立了一個發(fā)送緩沖區(qū)雕蔽，從建立鏈接后的第一個字節(jié)的序列號為0折柠，后面每個字節(jié)的序列號就會增加1。發(fā)送數(shù)據(jù)時批狐，從發(fā)送緩沖區(qū)取一部分?jǐn)?shù)據(jù)組成發(fā)送報文扇售，在其TCP協(xié)議中會附帶序列號和長度。接收端在收到數(shù)據(jù)后，需要回復(fù)確認(rèn)報文承冰，確認(rèn)報文中的ACK等于接受序列號加長度嘱根，也就是下一包數(shù)據(jù)需要發(fā)送的起始序列號。這樣一問一答的發(fā)送方式巷懈，能夠使發(fā)送端確認(rèn)發(fā)送的數(shù)據(jù)该抒，已經(jīng)被對方收到，發(fā)送端也可以發(fā)送一次連續(xù)多包數(shù)據(jù)顶燕，接收端只需要回復(fù)一次ACK就可以了凑保。這樣發(fā)送端可以把待發(fā)送的數(shù)據(jù)分割成一系列的碎片，發(fā)送到對端涌攻，對端根據(jù)序列號和長度欧引，在接收后重構(gòu)出來完整的數(shù)據(jù)，假設(shè)其中丟失了某些數(shù)據(jù)包恳谎，在接收端可以要求發(fā)送端重傳芝此。

TCP連接是全雙工的，對于兩端來說均采用上述機制因痛。

嗶哩嗶哩UP掌芝士

(3). 四次揮手

假設(shè)客戶端主動發(fā)起連接關(guān)閉請求婚苹，它需要將服務(wù)端發(fā)起一包FIN包，表示要關(guān)閉連接鸵膏，自己進入中止等待1狀態(tài)膊升，這是第一次揮手。

服務(wù)端收到FIN包谭企，發(fā)送一包ACK包廓译，表示自己進入了關(guān)閉等待狀態(tài)，客戶端進入中止等待2狀態(tài)债查，這是第二次揮手非区。

服務(wù)端此時還可以發(fā)送未發(fā)送的數(shù)據(jù)，而客戶端還可以接收數(shù)據(jù)盹廷，待服務(wù)端發(fā)送完數(shù)據(jù)之后征绸，發(fā)送一包FIN包，進入最后確認(rèn)狀態(tài)速和，這是第三次揮手歹垫。

客戶端收到之后回復(fù)ACK包，進入超時等待狀態(tài)颠放，經(jīng)過超時時間后關(guān)閉連接，而服務(wù)端收到ACK包后吭敢，立即關(guān)閉連接碰凶，這是第四次揮手。

為什么客戶端需要等待超時時間？

這是為了保證對方已收到ACK包欲低，因為假設(shè)客戶端發(fā)送完最后一包ACK后就釋放了連接辕宏，一旦ACK包在網(wǎng)絡(luò)中丟失，服務(wù)端將一直停留在最后確認(rèn)狀態(tài)砾莱∪鹂穑客戶端在發(fā)送完最后一包ACK包后等待一段時間，這時服務(wù)端因為沒有收到ACK包腊瑟，會重發(fā)FIN包聚假，客戶端會響應(yīng)FIN包，重發(fā)ACK包闰非，并刷新超時時間膘格，這個機制跟三次握手一樣，也是為了保證在不可靠的網(wǎng)絡(luò)鏈路中财松，進行可靠的連接斷開瘪贱。

嗶哩嗶哩UP掌芝士

UDP協(xié)議是非連接的，發(fā)送數(shù)據(jù)就是把數(shù)據(jù)封裝一下辆毡，然后從網(wǎng)卡發(fā)送出去就可以了菜秦，數(shù)據(jù)包之間并沒有狀態(tài)上的聯(lián)系，正因為UDP這種簡單的處理方式舶掖，導(dǎo)致它的性能損耗非常少喷户，對于CPU內(nèi)存資源的占用也遠小于TCP，但是對于網(wǎng)絡(luò)傳輸過程中時產(chǎn)生的丟包访锻，UDP協(xié)議并不能保證褪尝，所以UDP在傳輸穩(wěn)定性上要弱于TCP

TCP vs UDP?

TCP傳輸數(shù)據(jù)穩(wěn)定可靠，適用于對網(wǎng)絡(luò)通訊質(zhì)量要求較高的場景期犬，需要準(zhǔn)確無誤的傳輸給對方河哑，比如傳輸網(wǎng)絡(luò)，發(fā)送郵件龟虎，瀏覽網(wǎng)頁等璃谨。

UDP的優(yōu)點是速度快，但是可能產(chǎn)生丟包鲤妥，所以適用于對實時性要求較高佳吞，但是對少量丟包沒有太大要求的場景，比如域名查詢棉安，語音通話底扳，視頻直播等。UDP還有一個非常重要的應(yīng)用場景贡耽，就是隧道網(wǎng)絡(luò)衷模，比如VPN鹊汛，以及在SDN中用到的VXLAN.

嗶哩嗶哩UP掌芝士

網(wǎng)絡(luò)套接字與通信過程

進程之間的通信：HTTP協(xié)議

imooc

計算機可以同時運行多個不同的進程，比如打開瀏覽器的同時阱冶，可以播放視頻刁憋，那么如何識別是哪一個進程進行通信呢？

(1). 使用端口(Port)來標(biāo)記不同的網(wǎng)絡(luò)進程

(2). 端口(Port)使用16比特位表示0~2^16（0~65535）

imooc

imooc

套接字（Socket）是抽象概念木蹬，表示TCP連接的一段至耻。

通過套接字可以進行數(shù)據(jù)發(fā)送或接收。

imooc

HTTP(HyperText Transfer Protocol: 超文本傳輸協(xié)議)

通過HTTP協(xié)議來獲取互聯(lián)網(wǎng)資源镊叁。包含著超鏈接尘颓，圖片，視頻等多媒體的副本意系，這個副本可以通過HTTP協(xié)議進行傳輸

imooc

互聯(lián)網(wǎng)資源那么多泥耀，怎么獲取? ? --通過地址獲取

imooc

HTTP請求方法：

imooc

比較常用的請求方法

(1). GET:? ?獲取指定的服務(wù)器資源

(2). POST:? 提交數(shù)據(jù)到服務(wù)端

(3). DELETE:? 刪除指定的服務(wù)器端資源

(4). UPDATE:? 更新指定的服務(wù)端資源

Web服務(wù)器工作流程

(1). 接受客戶端請求：服務(wù)端接受客戶端連接

(2). 接收請求報文，通過報文蛔添，服務(wù)端可以知道瀏覽器想要干什么卷员，想獲取或操作什么資源

(3). 處理請求

(4). 訪問Web資源：通過路徑去判斷需要訪問哪些資源

(5). 構(gòu)造應(yīng)答：構(gòu)成應(yīng)答報文

(6). 發(fā)送應(yīng)答：把應(yīng)答報文發(fā)送給瀏覽器

imooc

HTTP協(xié)議的請求報文詳解

請求報文的主要內(nèi)容

imooc

1. 請求行：不管有多少內(nèi)容推励，都只有一行

包含：請求方法（GET,POST等）姨夹，請求地址（唯一對應(yīng)Web服務(wù)器的資源）吴旋，HTTP版本

2. 請求頭：

通信的附加信息：比如說明當(dāng)前手機還是計算機

格式：<key>:<value>

常用的請求頭：

imooc

實例：

3. 請求內(nèi)容

發(fā)送數(shù)據(jù)

數(shù)據(jù)格式是不固定的，只要客戶端和服務(wù)端協(xié)商好就可以

注意：請求內(nèi)容不是必須的

4. 實例

imooc

HTTP協(xié)議的應(yīng)答報文詳解

imooc

1. 狀態(tài)行

狀態(tài)碼：三位數(shù)

imooc

imooc

304: 客戶端緩存的數(shù)據(jù)并沒有發(fā)生變化凶硅，不需要再次請求后臺缝裁，可以直接使用本機緩存，即304為重定向到本機緩存

2. 應(yīng)答頭

和請求頭類似

imooc

常用的應(yīng)答頭

imooc

3. 實例：

imooc