OSI七層參考模型 - -國(guó)際標(biāo)準(zhǔn)化組織

應(yīng)用層: 通過(guò)人機(jī)交互來(lái)實(shí)現(xiàn)各種各樣的服務(wù)

表示層: 編碼、解碼 加密解密

會(huì)話(huà)層: 發(fā)現(xiàn) 建立 維持 終止會(huì)話(huà)

傳輸層：
1. 通過(guò)端口號(hào)來(lái)區(qū)分不同的服務(wù): 0-65535 靜態(tài)端口號(hào) 1-1023 著名端口號(hào) 1024-65535 動(dòng)態(tài)端口號(hào)
2. 提供可靠的傳輸: 確認(rèn) 重傳 排序 流控
. TCP 傳輸控制協(xié)議 面向連接的可靠傳輸協(xié)議
. UDP 用戶(hù)數(shù)據(jù)報(bào)文協(xié)議 非面向連接的不可靠傳輸協(xié)議
3. 數(shù)據(jù)分段: 最大段長(zhǎng)度 MSS 1480B 最大傳輸單元 MTU 1500B

網(wǎng)絡(luò)層: 通過(guò)ip來(lái)進(jìn)行邏輯尋址 路由器所在層

數(shù)據(jù)鏈路層:
LLC 邏輯鏈路控制子層 為上層服務(wù)提供FCS校驗(yàn)
MAC 媒介訪問(wèn)控制子層 通過(guò)MAC地址來(lái)進(jìn)行物理尋址

物理層: 定義電氣電壓，接口規(guī)范 光學(xué)特性

數(shù)據(jù)的封裝與解封裝

PDU(協(xié)議數(shù)據(jù)單元)

數(shù)據(jù)報(bào)文
四層 數(shù)據(jù)段
三層 數(shù)據(jù)包
二層 數(shù)據(jù)幀
一層 比特流

TCP協(xié)議 - -確認(rèn) 重傳 排序 流控

TCP報(bào)頭

FTP(數(shù)據(jù)傳送端口)TCP20

FTP(傳送控制端口)	TCP	21
telnet	TCP	23(明文)
SSH(安全外殼)	TCP	22(密文)
HTTP	TCP	80或者8080
HTTPS	TCP	443
SMTP(發(fā)郵件)	TCP	25
POP3(收郵件)	TCP	110
TFTP	UDP	69
DNS	TCP/UDP	53
VNC	TCP	5900

TCP三次握手

過(guò)程詳解
第一次握手:建立連接時(shí),客戶(hù)端發(fā)送syn包(seq=100)到服務(wù)器,并進(jìn)入SYN_SENT狀態(tài),等待服務(wù)器確認(rèn);SYN:同步序列編號(hào);
第二次握手:服務(wù)器收到syn包,必須確認(rèn)客戶(hù)的SYN(ack=100+1),同時(shí)自己也發(fā)送一個(gè)SYN包(seq=300),即SYN+ACK包,此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài);
第三次握手:客戶(hù)端收到服務(wù)器的SYN+ACK包,向服務(wù)器發(fā)送確認(rèn)包ACK(ack=300+1),此包發(fā)送完畢,客戶(hù)端和服務(wù)器進(jìn)入ESTABLISHED(TCP連接成功)狀態(tài),完成三次握手。

TCP第三次握手的必要性:
答: 防止已失效的請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端而造成連接的誤判。假如客戶(hù)端發(fā)出連接請(qǐng)求A，由于網(wǎng)絡(luò)原因，服務(wù)端并沒(méi)有收到A，于是客戶(hù)端又發(fā)送了連接請(qǐng)求B，并建立了連接，完成通信，斷開(kāi)連接。這時(shí)候，服務(wù)端突然又收到了A，于是看作是一次新的連接請(qǐng)求，進(jìn)行第二次握手，由于不存在第三次握手，所以這時(shí)已經(jīng)建立了TCP連接。但實(shí)際上客戶(hù)端并沒(méi)有發(fā)起連接，所以不會(huì)傳遞數(shù)據(jù)，那么這條連接就會(huì)變成一條死連接。

TCP三次握手的意義:
答:
(1) 同步連接雙方的序列號(hào)和確認(rèn)號(hào)并交換 TCP 窗口大小信息。
(2) TCP通過(guò)三次握手建立可靠的（確保收到）的全雙工通信。

TCP四次斷開(kāi)

過(guò)程解釋
假設(shè) A 為主動(dòng)斷開(kāi)方，B 為被動(dòng)斷開(kāi)方
第一次握手，A 向 B 發(fā)送消息，表明數(shù)據(jù)發(fā)送完成需要斷開(kāi)連接
第二次握手，B 向 A 發(fā)送消息，讓 A 先等等，等 B 把數(shù)據(jù)傳完
第三次握手，B 向 A 發(fā)送消息，數(shù)據(jù)已傳完，可以斷開(kāi)了
第四次握手，A 向 B 發(fā)送消息，稍后會(huì)斷開(kāi)連接

TCP四次斷開(kāi)為什么比三次握手多一次？
答:為保證單向通信的可行性，所以多一次握手

UDP協(xié)議

UDP報(bào)頭

IP協(xié)議

IP報(bào)頭

生存時(shí)間(TTL): 0-255 默認(rèn)每經(jīng)過(guò)一臺(tái)路由器減1
協(xié)議號(hào): 標(biāo)識(shí)上層協(xié)議

上層協(xié)議協(xié)議號(hào)

TCP	6
UDP	17
OSPF	89
EIGRP	88

TCP/IP協(xié)議棧

相同點(diǎn)：
2者都是模型化層次化
下層對(duì)上層提供服務(wù)支持
每層協(xié)議彼此相互獨(dú)立
不同點(diǎn)：
OSI先有模型才有協(xié)議 TCP/IP先有協(xié)議才有模型
TCP/IP協(xié)議棧只適用于TCP/IP網(wǎng)絡(luò)
層數(shù)量不同

---

擴(kuò)充

TCP滑動(dòng)窗口

TCP協(xié)議里窗口機(jī)制有2種：

固定的窗口

滑動(dòng)的窗口

這個(gè)窗口大小就是我們一次傳輸幾個(gè)數(shù)據(jù)。對(duì)所有數(shù)據(jù)幀按順序賦予編號(hào)，發(fā)送方在發(fā)送過(guò)程中始終保持著一個(gè)發(fā)送窗口，只有落在發(fā)送窗口內(nèi)的幀才允許被發(fā)送；同時(shí)接收方也維持著一個(gè)接收窗口，只有落在接收窗口內(nèi)的幀才允許接收。這樣通過(guò)調(diào)整發(fā)送方窗口和接收方窗口的大小可以實(shí)現(xiàn)流量控制。

TCP滑動(dòng)窗口技術(shù)通過(guò)動(dòng)態(tài)改變窗口大小來(lái)調(diào)節(jié)兩臺(tái)主機(jī)間數(shù)據(jù)傳輸。每個(gè)TCP/IP主機(jī)支持全雙工數(shù)據(jù)傳輸，因此TCP有兩個(gè)滑動(dòng)窗口：一個(gè)用于接收數(shù)據(jù)，另一個(gè)用于發(fā)送數(shù)據(jù)。TCP使用肯定確認(rèn)技術(shù)，其確認(rèn)號(hào)指的是下一個(gè)所期待的字節(jié)。 假定發(fā)送方設(shè)備以每一次三個(gè)數(shù)據(jù)包的方式發(fā)送數(shù)據(jù)，也就是說(shuō)，窗口大小為3。發(fā)送方發(fā)送序列號(hào)為1、2、3的三個(gè)數(shù)據(jù)包，接收方設(shè)備成功接收數(shù)據(jù)包，用序列號(hào)4確認(rèn)。發(fā)送方設(shè)備收到確認(rèn)，繼續(xù)以窗口大小3發(fā)送數(shù)據(jù)。當(dāng)接收方設(shè)備要求降低或者增大網(wǎng)絡(luò)流量時(shí)，可以對(duì)窗口大小進(jìn)行減小或者增加，本例降低窗口大小為2，每一次發(fā)送兩個(gè)數(shù)據(jù)包。當(dāng)接收方設(shè)備要求窗口大小為0，表明接收方已經(jīng)接收了全部數(shù)據(jù)，或者接收方應(yīng)用程序沒(méi)有時(shí)間讀取數(shù)據(jù)，要求暫停發(fā)送。發(fā)送方接收到攜帶窗口號(hào)為0的確認(rèn)，停止這一方向的數(shù)據(jù)傳輸。

通過(guò)下面的圖來(lái)看一下TCP固定窗口有什么問(wèn)題

這里我們可以看到假設(shè)窗口的大小是1，也是就每次只能發(fā)送一個(gè)數(shù)據(jù)只有接受方對(duì)這個(gè)數(shù)據(jù)進(jìn)行確認(rèn)了以后才能發(fā)送第2個(gè)數(shù)據(jù)。我們可以看到發(fā)送方每發(fā)送一個(gè)數(shù)據(jù)接受方就要給發(fā)送方一個(gè)ACK對(duì)這個(gè)數(shù)據(jù)進(jìn)行確認(rèn)。只有接受到了這個(gè)確認(rèn)數(shù)據(jù)以后發(fā)送方才能傳輸下個(gè)數(shù)據(jù)。 這樣如果說(shuō)窗口過(guò)小，那么當(dāng)傳輸比較大的數(shù)據(jù)的時(shí)候需要不停的對(duì)數(shù)據(jù)進(jìn)行確認(rèn)，這個(gè)時(shí)候就會(huì)造成很大的延遲。如果說(shuō)窗口的大小定義的過(guò)大。我們假設(shè)發(fā)送方一次發(fā)送100個(gè)數(shù)據(jù)。但是接收方只能處理50個(gè)數(shù)據(jù)。這樣每次都會(huì)只對(duì)這50個(gè)數(shù)據(jù)進(jìn)行確認(rèn)。發(fā)送方下一次還是發(fā)送100個(gè)數(shù)據(jù)，但是接受方還是只能處理50個(gè)數(shù)據(jù)。這樣就避免了不必要的數(shù)據(jù)來(lái)?yè)砣覀兊逆溌贰Ｋ晕覀兙鸵肓嘶瑒?dòng)窗口機(jī)制，窗口的大小并不是固定的而是根據(jù)我們之間的鏈路的帶寬的大小進(jìn)行動(dòng)態(tài)變化。

通過(guò)一下幾張圖來(lái)看一下滑動(dòng)窗口的工作

首先是第一次發(fā)送數(shù)據(jù)這個(gè)時(shí)候的窗口大小是根據(jù)鏈路帶寬的大小來(lái)決定的。我們假設(shè)這個(gè)時(shí)候窗口的大小是3。這個(gè)時(shí)候接受方收到數(shù)據(jù)以后會(huì)對(duì)數(shù)據(jù)進(jìn)行確認(rèn)告訴發(fā)送方我下次希望手到的是數(shù)據(jù)是多少。這里我們看到接收方發(fā)送的ACK=3(這是發(fā)送方發(fā)送序列2的回答確認(rèn)，下一次接收方期望接收到的是3序列信號(hào))。這個(gè)時(shí)候發(fā)送方收到這個(gè)數(shù)據(jù)以后就知道我第一次發(fā)送的3個(gè)數(shù)據(jù)對(duì)方只收到了2個(gè)。就知道第3個(gè)數(shù)據(jù)對(duì)方?jīng)]有收到。下次在發(fā)送的時(shí)候就從第3個(gè)數(shù)據(jù)開(kāi)始發(fā)。這個(gè)時(shí)候窗口大小就變成了2。

這個(gè)時(shí)候發(fā)送方發(fā)送2個(gè)數(shù)據(jù)。

看到接收方發(fā)送的ACK是5就表示他下一次希望收到的數(shù)據(jù)是5，發(fā)送方就知道我剛才發(fā)送的2個(gè)數(shù)據(jù)對(duì)方收了這個(gè)時(shí)候開(kāi)始發(fā)送第5個(gè)數(shù)據(jù)。
這就是滑動(dòng)窗口的工作機(jī)制，當(dāng)鏈路變好了或者變差了這個(gè)窗口還會(huì)發(fā)生變?cè)?#xff0c;并不是第一次協(xié)商好了以后就永遠(yuǎn)不變了。

總結(jié)

以上是生活随笔為你收集整理的CCNA1的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。