一萬字 16 張圖詳解計算機網絡協議

OSI 七層協議

1. 物理層

很久很久以前,那時候還沒有現在的外星人超級電腦,或者華爲的 P30。比較調皮的小明想要把自己機器上寫好的一些個人遊戲心得(如何玩好王者農藥)發給小紅(校花),希望博得芳心。小明個人比較勤,遊戲總結心得總結的比較詳細(大概有 100M)。但是到底怎麼才能從自己的機器上傳給小紅的機器呢,進過一番打聽,他發現遠在太平洋另一端的科學家已經發明瞭一種技術 物理層,專門用來解決小明這種單身狗問題。**該層主要定義物理設備標準,如網線的接口類型、光纖的接口類型、各種傳輸介質的傳輸速率等。**它的主要作用是傳輸比特流 (就是由 1、0 轉化爲電流強弱來進行傳輸,到達目的地後在轉化爲 1、0,也就是我們常說的數模轉換與模數轉換)。這一層的數據叫做比特。

他很興奮,通過一個月的努力終於搭建起了這個物理層。

2. 數據鏈路層:

然而上天卻好像和小明開了一個玩笑,樓下的小潤髮超市的網線、光纖最近賣光了,但是這個物理層傳輸數據只能通過網線傳輸。到底怎麼辦!!。

此時,他體內的雄性激素促使着他的大腦以光速運轉。終於他餓了,無奈得走去學校飯堂三樓喫麻辣燙。此時聽到隔壁坐着的那位王叔叔(老王)說,科學家已經發明瞭一種技術可以通過無線電來傳輸。What?這不是完美解決了自己的困擾嗎。小明連忙對隔壁老王說謝謝,老王留下了幸福的淚水!!

右通過一番努力查資料,小明發現:**這****種技術可以通過電線我能發數據流,也可以通過其它介質來傳輸。然後還要保證了傳輸過去的比特流是正確的,有糾錯功能。**定義瞭如何讓格式化數據以進行傳輸,以及如何讓控制對物理介質的訪問。這一層通常還提供錯誤檢測和糾正,以確保數據的可靠傳輸。

小明把層技術稱爲:數據鏈路層

3. 網絡層:

由於小明家離小紅家比較遠,無線電信號無法傳輸到哪裏,但是這完全難不到小明。他通過在離小紅家的路上搭建了多個節點(路由器,交換機),用於信號的傳輸。但是由於他有時候被雄性激素衝昏了頭腦,搭建的信號節點有點亂,而且很多。那他又想用最短的路徑來傳輸怎麼辦呢?在小明沮喪走回家的時候已深夜,他看見今天看到的那位王叔叔匆匆的從自己家走出來,他連忙拉住王叔叔,向他訴說自己的煩惱,希望王叔叔能給自己一些幫助。當小明說完後,王叔叔從緊張變爲和藹,和小明說:其實已經有人發明了網絡層。**即路由器,交換機那些具有尋址功能的設備所實現的功能。**這一層定義的是 IP 地址,通過 IP 地址尋址。所以產生了 IP 協議。該層能選擇最佳路徑,這就是路由要做的事。

4. 傳輸層

爲了趁熱打鐵,小明通宵查資料來學習相關信息,並且簡單搭建好網絡層,開始傳輸數據,趁着傳輸過程好好睡一覺。當他起來的時候,噩夢纔剛剛開始,因爲他傳輸的數據太大(100M)只傳輸了一部分,而且斷斷續續的,有一部分數據根本傳不出去。那怎麼辦?

“加一層傳輸層!!!”:王叔叔在樓下大聲喊着,“資料在你媽媽的牀頭櫃”,王叔叔繼續說。小明連忙找到資料,上面寫着:“

發正確的發比特流數據到另一臺計算機了,但是當我發大量數據時候,可能需要好長時間,例如一個視頻格式的,網絡會中斷好多次(事實上,即使有了物理層和數據鏈路層,網絡還是經常中斷,只是中斷的時間是毫秒級別的)。

那麼,我還須要保證傳輸大量文件時的準確性。於是,我要對發出去的數據進行封裝。就像發快遞一樣,一個個地發。

例如 TCP,是用於發大量數據的,我發了 1 萬個包出去,另一臺電腦就要告訴我是否接受到了 1 萬個包,如果缺了 3 個包,就告訴我是第 1001,234,8888 個包丟了,那我再發一次。這樣,就能保證對方把這個視頻完整接收了。

例如 UDP,是用於發送少量數據的。我發 20 個包出去,一般不會丟包,所以,我不管你收到多少個。在多人互動遊戲,也經常用 UDP 協議,因爲一般都是簡單的信息,而且有廣播的需求。如果用 TCP,效率就很低,因爲它會不停地告訴主機我收到了 20 個包,或者我收到了 18 個包,再發我兩個!如果同時有 1 萬臺計算機都這樣做,那麼用 TCP 反而會降低效率,還不如用 UDP,主機發出去就算了,丟幾個包你就卡一下,算了,下次再發包你再更新。

TCP 協議是會綁定 IP 和端口的協議,下面會介紹 IP 協議。”

通過如此這般的操作,他!小明同學終於把自己 100M 的遊戲心得發送給了小紅。

5. 會話層 (解除與建立與別的接口的聯繫)

然而,小紅根本不玩遊戲。得知這個消息後,小明楞逼了。但是他沒有放棄,而是把自己猜到小紅喜歡的信息都發給他,但是小明每發一次,難道我每次都要調用 TCP 去打包,然後調用 IP 協議去找路由,這一來一回就是一天,那怎麼辦呢?

他又翻了翻王叔叔的筆記本資料,寫着:**會話層可以幫助我們建立和管理應用程序之間的通信,封裝了調用 TCP 去打包,然後調用 IP 協議去找路由等操作,**如此一來,他只需要十幾二十分鐘就能夠成功搭建好傳輸數據的機器。

6. 表示層 (數據格式化,代碼轉換,數據加密)

有一次,小明傳了一份數據,是關於如何選購化妝品的文章,小紅對此非常感興趣,但是當小紅想用自己的 window 開該文件時發現根本無法打開,後來小紅在下課的時候和小明說自己無法打開這個文件,小明想自己用 Linux 系統明明完整地發送給了小紅啊,那就奇怪了,但是出於耍帥,小明只是輕輕地說 “我放學後再發你一份!”。

這時雖然小明不知道是出了什麼問題,但是他堅信老王叔叔的資料筆記會有答案的。

果然!上清清楚楚的寫着:“現在我能保證應用程序自動收發包和尋址了。但是我要用 Linux 給 window 發包,兩個系統語法不一致,就像安裝包一樣,exe 是不能在 linux 下用的,shell 在 window 下也是不能直接運行的。於是需要表示層(presentation),幫我們解決不同系統之間的通信語法問題。”

小明立即用了一個通宵手動搭好了表示層,傳輸了一份完美的文件給小紅。

7. 應用層 (文件傳輸,電子郵件,文件服務,虛擬終端)

官方 OSI 說明圖

TCP/IP 協議

TCP/IP 協議是由七層模型簡化成四層而來。(TPC/IP 協議其實泛指了四層模型中的全部協議,區別開 TCP 協議,IP 協議)

每一層對於上一層來講是透明的,上層只需要使用下層提供的接口,並不關心下層是如何實現的。

與 OSI 七層協議的對比:

傳輸層:

網絡層是主機與主機之間的通訊,而傳輸層則是進程之間的通訊。

爲何要有傳輸層?

應爲進程是資源分配的基本單位,計算機之間的信息傳輸也只是一臺計算機的進程傳輸到另外一臺計算機的進程中。

一臺計算機如何找到另外一臺計算機呢?

那就是通過 IP 協議來完成的(複用,多個進程都可以把信息通過傳輸層到 IP 層,再傳輸到另外一臺計算機中)。

那如何找到另外一臺計算機的進程(pid)?

那就是用端口(分用,到達另外一臺計算機後還要通過端口號找到對應進程)。

傳輸層主要有兩種協議:UDP 和 TCP

一、UDP 協議

特點:

UDP 的首部格式(UDP 頭):

二、TCP 協議

A、特點:

B、爲何 TCP 是可靠的呢?

其實 TCP 是依賴停止 等待協議和連續 ARQ 協議 + 滑動窗口協議才達到可靠的目的

a、等待協議

b、連續 ARQ 協議

以上只是簡單瞭解 TCP 協議的發送流程,如果要清楚發送細節,必須知道 TCP 報文首部

TCP 報文段的首部格式

雖然說 TCP 是面向字節流的,但是 TCP 傳輸的數據單元卻是報文段,報文段由首部和數據兩部分組成,如圖:

1. 源端口和目標端口(各佔兩字節)

**2. 序號(佔 4 字節):**TCP 連接傳輸的數據每一個字節都有一個序號,而一個報文段可能會有多個字節的數據,這個序號指的是 TCP 報文段中起始的序號,下一個報文段的序號則是該序號加上報文數據長度(三次握手和四次揮手時說的 SYN 或 ACK 會消耗一個序號就是指該序號)

3. 確認號(佔 4 字節):因爲一次數據傳輸會分成多個報文段,接收方接收完一次報文段後如果要發送確認(有可能不用確認,因爲是接收完發送窗口的報文段才確認的),則會攜帶一個確認號,表示接收方想要接收的下一個報文的序號

**4. 數據偏移(佔 4 字位):**數據部分的起始位置離報文段起始位置的距離,就是報文首部的長度,單位是 4 字節,所以 4 位能表示最大值是十進制的 15,就是 15 x 4 字節 = 60 字節,TCP 報文首部最大長度爲 60 字節

**5. 保留(佔 6 位):**未被使用,全置爲 0

**6. 緊急 URG:**當 URG=1 時緊急數據纔有效。注意,這裏 URG 並不是緊急數據,只是一個標誌,標誌着緊急數據是否有效

**7. 確認 ACK:**當 ACK=1 時確認號纔有效,當建立連接後全部傳輸的報文都要把 ACK 設置爲 1

**8. 推送 PSH:**接收方機器會有一個接收,當接收緩存慢了纔回把接收到的數據交付到接收應用進程中,而如果發送端把報文的 PSH 設爲 1,接收方接收到該報文會立即交付到應用的進程中

**9. 復位 RST:**兩個作用,1、當 RST=1 時,表示 TCP 連接中出現嚴重差錯,必須釋放連接,然後重新建立運輸連接。2、當 RST=1 時,拒絕一個非法的報文段或拒絕打開一個連接。

**10. 同步 SYN:**用於同步序號(告訴另外一方,他們之間從該序號開始傳輸報文段),當 SYN=1,ACK=0 表示這時一個連接請求報文。

**11. 終止 FIN:**用於釋放一個連接。當 FIN=1 時,表明此報文的發送方的數據已經發送完畢,並要求釋放運輸連接。

12. 窗口(佔 2 字節),是一個接收窗口,接收方允許發送方發送的數據量

**13. 檢驗和(佔 2 字節):**檢驗接收過來的報文段(報文首部和用戶數據)是否有誤

**14. 緊急指針(佔 2 字節):**當 URG=1 時纔有效,指出緊急數據未尾位置(開始位置是整個報文段中用戶數據的開頭)

**15. 選項,**長度可變,最長 40 字節

那到底 TCP 是如何實現可靠傳輸的呢?

TCP 可靠傳輸的實現

一、通過滑動窗口來發送數據

二、超時重傳時間的選擇

採用一個根據 RTT 動態計算的時間,並不是直接採用一個固定的時間

RTT:發送一個報文段到收到對應的 ACK 所花費的時間

RTO:超時重傳時間

RTTs 是一個加權平均 RTT 時間

RTTd 是 RTTs 偏差的加權平均

RTO = RTTs + 4 * RTTd

如果發生了重傳 ,這次的 RTT 會讓 RTTs 會變大,此時是不會用該 RTT 來計算 RTTs 的

三、確認 SACK

是一個 TCP 報文首部的選項。

當數據傳輸過程中,接收方可能會未按順收到部分報文段,此時序號告訴發送方從新傳輸這些報文段,SACK 選項就是用於告訴發送方需要傳輸那些報文段的

TCP 傳輸連接管理

連接的三個階段:建立連接、數據傳輸、連接釋放

在建立連接的過程中要解決三個問題:

1、使每一方都知道對方的存在

2、協商一些參數

3、能夠運輸實體資源

主動建立連接的一端叫客戶端,被動等待連接建立的一方叫服務器

連接建立(三次握手)

如圖:

每次發送一個 seq 時,都會消耗一個序號,所以會發現在確認時,ack 總等於另一端請求的 seq+1

爲何需要第三次握手?

假設沒有第三次握手(即 A 再次確認)

在很久很久以前,A 發了一個連接請求給 B,但是網絡滯留的原因,請求沒有到達 B,所以 B 也沒有確認返回給 A,所以 A 右發送了一個連接請求給 B,此時 B 收到了連接請求並返回了一個確認給 A,此時連端開始愉快的數據傳輸之旅。當傳輸結束時,分別斷開連接,各自幹各自的活兒。但是過了一段時間,之間滯留在網絡中的 A 發出的連接請求到達了 B 中,B 以爲 A 又要傳輸數據,便右回了一個確認給 A,但是 A 並不需要輸出傳輸,也沒有理會這個確認,而 B 卻在傻傻等待 A 傳輸數據,這個就會浪費 B 的資源。

但是如果有第三次 A 的確認,A 這個滯留的連接傳給 B,B 返回一個確認,但是 A 不想傳輸數據了,便沒有回一個確認給 B(第三次握手),B 沒有收到該確認也不會等待 A 傳輸數據。

連接釋放(四次揮手)

如圖:

**第一次揮手:**客戶端發送連接,FIN=1 標誌着 A 已經完成了數據的發送。

第二次揮手:B 回了一個確認,此時 A 與 B 的發送連接就斷開了。

**第三次揮手:**因爲 TCP 連接是全雙工通信的,B 還保留着一個對 A 大發送連接,如果等到 B 也不需要發送數據給 A 時,B 會發送一個連接給 A,seq 等於一個大於或等於 v 的值(因爲 A 與 B 斷開發送連接到 B 與 A 斷開發送連接期間有可能 B 向 A 發送了數據,就是消耗序號)。

**第四次揮手:**當 A 收到 B 的連接時,要回一個響應給 B,但是此時會有一個 2MSL 長的等待時間,時間一過,就真正的斷開與 B 的全部連接了。

爲什麼需要 2MSL 的等待時間?

MSL:最長報文壽命

當 A 發送確認給 A 後,如果此時出現了一些狀況(連接被丟棄等),確認無法到達 B 中,B 會重新發送一個連接給 A,但是 A 就停止了,B 就一直等待(其實有一個保活時間)。

如果有了這個等待時間,就算 A 的 ACK 確認丟失了,B 也會再從新發送一個連接給 A,A 接收到該連接後,會從新計算等待時間。A 會再確認一次

應用層

一、HTTP 協議

特點:

請求報文的結構

請求頭部:用於設置請求的的一些參數如:ContentType

請求空行:就算請求數據爲空,都要有空行,表示請求首部的結束

從瀏覽器地址欄鍵入 URL,回車後會盡力的流程:

HTTP 報文層面:GET 請求信息放在 URL 中,POST 放在報文體中

數據庫層面:GET 符合冪等性和安全性,POST 不符合

其他層面:GET 可以被緩存、儲存,而 POST 不行

Cookie 和 Session 的區別

爲什麼會有這兩種技術?

HTTP 與 HTTPS 的區別:

1、HTTPS 需要到 CA 申請證書,HTTP 不需要

2、HTTPS 密文傳輸、HTTP 明文傳輸

3、連接方式不同,HTTPS 默認使用 443 端口,HTTP 使用 80 端口

4、HTTPS = HTTP + 加密 + 認證 + 完整性保護,較 HTTP 安全

其實也不一定就安全,原因是用戶不會再訪問時候加上 http:// 或 https://, 瀏覽器就默認會加上 http://,然後通過轉發的方式轉成 https:// 這個過程 http 就有可能會被劫持了。

此時會用到一個技術 HSTS(HTTP Strict Transort Security)

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/hKNygSqARvGBKivxbOnb_g