OSI七層網絡結構圖和TCP/IP的四層網絡結構圖

1、請你分別畫畫OSI的七層網絡結構圖，和TCP/IP的五層結構圖？

OSI的七層結構圖是制定的標準，可是在現實中並無被普遍採用；TCP/IP的5層是爲了方便學習而假設出來的；現實中普遍使用的是TCP/IP的四層網絡結構圖。

以TCP/IP五層結構圖來說解：應用層主要是dns、http、ftp、smtp等應用層協議；運輸層主要是tcp、udp協議；網絡層主要是ip協議；數據鏈路層是MAC幀；物理層是010101的比特流。

一、應用層協議

咱們經常使用的http、dns、ftp等應用層協議。

1.它們都有本身的報文格式（請求報文和響應報文），報文有本身的語法、含義。

2.應用層協議都有本身的端口，如http爲80，ftp爲21，ssh爲22，smtp爲25，dns爲53，https爲443。

3.應用層協議的報文傳輸依賴下面的運輸層協議tcp或udp來進行傳輸。

1.一、http協議

這時候咱們來理解各類協議就很容易了。如http協議：下面使用http://www.kongfz.com的請求和響應報文來舉例。

GET http://www.kongfz.com/ HTTP/1.1
Host: www.kongfz.com
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36
DNT: 1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,ja;q=0.8,zh-CN;q=0.7,zh;q=0.6
Cookie: acw_tc=7b39758315366525831781305e07127bc2496e172c5bae202bda3e35c76e72; kfz_uuid=0147d2f0-1626-4a30-9109-89bc69daa209; shoppingCartSessionId=3ce70b7ecc16ff4b0f5cbe4a35371d73; reciever_area=1006000000; PHPSESSID=m0m8apquke28uscf2usiam9ouc1uveko; kfz_trace=0147d2f0-1626-4a30-9109-89bc69daa209|0|20d476e6329fb229|-; kfz-tid=0502f82d47b9978735efd2b427a4babb; Hm_lvt_bca7840de7b518b3c5e6c6d73ca2662c=1538441986,1538464530,1538634990,1538703246; Hm_lpvt_bca7840de7b518b3c5e6c6d73ca2662c=1538703246; Hm_lvt_33be6c04e0febc7531a1315c9594b136=1538441986,1538464530,1538634990,1538703246; Hm_lpvt_33be6c04e0febc7531a1315c9594b136=1538703246
If-None-Match: W/"5bb6bf4e-46d7d"
If-Modified-Since: Fri, 05 Oct 2018 01:33:02 GMT

請求報文的格式：

第一行爲狀態行，代表請求的方法，請求的網址，使用的http協議版本。

中間就是請求發送的各類頭部信息，都是k-v對。

最後就是請求的內容，這裏沒有，若是咱們提交表單或上傳什麼數據的話，就會有請求內容這一塊。

HTTP/1.1 304 Not Modified
Date: Fri, 05 Oct 2018 01:34:12 GMT
Connection: keep-alive
Server: openresty
Last-Modified: Fri, 05 Oct 2018 01:33:02 GMT
ETag: "5bb6bf4e-46d7d"

響應的html文檔省略...

響應報文的格式：

第一行是狀態行，代表http的協議版本，狀態碼及說明。

中間也是響應的頭部信息。

最後就是響應的內容，這裏是返回一個html頁面，內容就不顯示了。

1.二、dhcp協議

當咱們鏈接WLAN時（家裏的WIFI或者是學校的WLAN），咱們查看網絡屬性能夠看到都是自動獲取ip地址。經過ipconfig能夠查看到本身被分配的ip。這就是動態主機配置協議。DHCP服務分配給客戶端的ip地址是臨時的，這很適合常常移動位置的計算機。

下層協議

http使用tcp協議，dns使用udp協議，ftp使用tcp協議，smtp使用tcp協議，dhcp使用udp協議。

二、運輸層協議

2.一、UDP，用戶數據報協議

• 無鏈接，盡最大努力的交付，沒有擁塞控制
• 可能丟包，面向數據報

由於UDP沒有擁塞控制，因此網絡出現的擁塞也不會下降它的發送速率，使得其適用於實時性高的應用，如：網絡電話、視頻、遊戲等。

接收方對UDP報文進行校驗和的驗證，若是不正確則丟棄。

2.二、TCP，傳輸控制協議

• 有鏈接，可靠的交付，有擁塞控制，面向字節流

1.中止等待協議。保證不丟包。

2.以字節爲單位的滑動窗口

擁塞避免控制： 擁塞窗口是指字節滑動窗口，即TCP發送的報文（以字節爲單位）。

1.設置慢開始門限爲16；慢開始，指數增大，每一次是以前的2倍：1-2-4-8-16，到達門限值後，改成擁塞避免。

2.擁塞避免，使用加法增大，16-17-18---24，出現了超時狀況。這時候認爲網絡擁塞。調整慢開始門限值爲當前擁塞窗口的一半：12，並從新使用慢開始。

3.從新慢開始，1-2-4-8-12，到達門限值，改成擁塞避免。

4.擁塞避免，12-13-14-15-16，這時候連續收到3個ACK。說明個別報文在網絡中丟失了，網絡並無出現擁塞。執行快恢復，而不是慢開始。把門限值調整爲當前擁塞窗口的一半：8。並把擁塞窗口調整爲8。

5.而後使用擁塞避免，8-9-10…直到碰到超時或連續的ACK狀況。

一個概念是，網絡中的擁塞狀況是沒法肯定的，咱們只能在實際中去探測當前擁塞窗口的一個門限值是多少。若是咱們認爲如今出現網絡擁堵，就調整對應的門限值從新開始，這樣下一次到達門限值時應該不會出現擁堵了。若是網絡擁塞嚴重，就再調整門限值。使用一次次的門限降級，來避免加劇網絡擁塞的狀況從而消除網絡擁塞。

固然，在降級後，還會一次次地加法增大，由於實際狀況老是在不斷變化的。一次次的門限升級可使得網絡的傳輸效率最大化。

三、網絡層協議

IP協議

1.尋址與路由

• IP數據報經過路由選擇協議來選擇合適的轉發路徑，把該IP數據報轉發到目的主機。
• 利用ARP協議，將IP地址和物理MAC地址相匹配，這樣才能把IP數據報發送到物理主機上。

2.分段與重組1.IP數據報經過不一樣類型的通訊網絡發送，IP數據報的大小會受到這些網絡所規定的最大傳輸單元的限制。2.將IP數據報拆分紅一個個可以適合下層技術傳輸的小數據報，被分段後的IP數據報能夠獨立地在網絡中進行轉發，在到達目的主機後被重組，恢復成原來的IP數據報。