CCNA1
OSI七層參考模型 - -國際標準化組織
1. 通過端口號來區(qū)分不同的服務: 0-65535 靜態(tài)端口號 1-1023 著名端口號 1024-65535 動態(tài)端口號
2. 提供可靠的傳輸: 確認 重傳 排序 流控
. TCP 傳輸控制協(xié)議 面向連接的可靠傳輸協(xié)議
. UDP 用戶數據報文協(xié)議 非面向連接的不可靠傳輸協(xié)議
3. 數據分段: 最大段長度 MSS 1480B 最大傳輸單元 MTU 1500B
LLC 邏輯鏈路控制子層 為上層服務提供FCS校驗
MAC 媒介訪問控制子層 通過MAC地址來進行物理尋址
數據的封裝與解封裝
PDU(協(xié)議數據單元)
數據報文
 四層 數據段
 三層 數據包
 二層 數據幀
 一層 比特流
TCP協(xié)議 - -確認 重傳 排序 流控
TCP報頭
 
| 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三次握手
 
過程詳解
 第一次握手:建立連接時,客戶端發(fā)送syn包(seq=100)到服務器,并進入SYN_SENT狀態(tài),等待服務器確認;SYN:同步序列編號;
 第二次握手:服務器收到syn包,必須確認客戶的SYN(ack=100+1),同時自己也發(fā)送一個SYN包(seq=300),即SYN+ACK包,此時服務器進入SYN_RECV狀態(tài);
 第三次握手:客戶端收到服務器的SYN+ACK包,向服務器發(fā)送確認包ACK(ack=300+1),此包發(fā)送完畢,客戶端和服務器進入ESTABLISHED(TCP連接成功)狀態(tài),完成三次握手。
TCP第三次握手的必要性:
 答: 防止已失效的請求報文段突然又傳送到了服務端而造成連接的誤判。假如客戶端發(fā)出連接請求A,由于網絡原因,服務端并沒有收到A,于是客戶端又發(fā)送了連接請求B,并建立了連接,完成通信,斷開連接。這時候,服務端突然又收到了A,于是看作是一次新的連接請求,進行第二次握手,由于不存在第三次握手,所以這時已經建立了TCP連接。但實際上客戶端并沒有發(fā)起連接,所以不會傳遞數據,那么這條連接就會變成一條死連接。
TCP三次握手的意義:
 答:
 (1) 同步連接雙方的序列號和確認號并交換 TCP 窗口大小信息。
 (2) TCP通過三次握手建立可靠的(確保收到)的全雙工通信。
TCP四次斷開
 
過程解釋
 假設 A 為主動斷開方,B 為被動斷開方
 第一次握手,A 向 B 發(fā)送消息,表明數據發(fā)送完成需要斷開連接
 第二次握手,B 向 A 發(fā)送消息,讓 A 先等等,等 B 把數據傳完
 第三次握手,B 向 A 發(fā)送消息,數據已傳完,可以斷開了
 第四次握手,A 向 B 發(fā)送消息,稍后會斷開連接
TCP四次斷開為什么比三次握手多一次?
 答:為保證單向通信的可行性,所以多一次握手
UDP協(xié)議
UDP報頭
 
IP協(xié)議
IP報頭
 生存時間(TTL): 0-255 默認每經過一臺路由器減1
 協(xié)議號: 標識上層協(xié)議
| TCP | 6 | 
| UDP | 17 | 
| OSPF | 89 | 
| EIGRP | 88 | 
TCP/IP協(xié)議棧
相同點:
 2者都是模型化層次化
 下層對上層提供服務支持
 每層協(xié)議彼此相互獨立
 不同點:
 OSI先有模型才有協(xié)議 TCP/IP先有協(xié)議才有模型
 TCP/IP協(xié)議棧只適用于TCP/IP網絡
 層數量不同
擴充
TCP滑動窗口
TCP協(xié)議里窗口機制有2種:
這個窗口大小就是我們一次傳輸幾個數據。對所有數據幀按順序賦予編號,發(fā)送方在發(fā)送過程中始終保持著一個發(fā)送窗口,只有落在發(fā)送窗口內的幀才允許被發(fā)送;同時接收方也維持著一個接收窗口,只有落在接收窗口內的幀才允許接收。這樣通過調整發(fā)送方窗口和接收方窗口的大小可以實現流量控制。
TCP滑動窗口技術通過動態(tài)改變窗口大小來調節(jié)兩臺主機間數據傳輸。每個TCP/IP主機支持全雙工數據傳輸,因此TCP有兩個滑動窗口:一個用于接收數據,另一個用于發(fā)送數據。TCP使用肯定確認技術,其確認號指的是下一個所期待的字節(jié)。 假定發(fā)送方設備以每一次三個數據包的方式發(fā)送數據,也就是說,窗口大小為3。發(fā)送方發(fā)送序列號為1、2、3的三個數據包,接收方設備成功接收數據包,用序列號4確認。發(fā)送方設備收到確認,繼續(xù)以窗口大小3發(fā)送數據。當接收方設備要求降低或者增大網絡流量時,可以對窗口大小進行減小或者增加,本例降低窗口大小為2,每一次發(fā)送兩個數據包。當接收方設備要求窗口大小為0,表明接收方已經接收了全部數據,或者接收方應用程序沒有時間讀取數據,要求暫停發(fā)送。發(fā)送方接收到攜帶窗口號為0的確認,停止這一方向的數據傳輸。
通過下面的圖來看一下TCP固定窗口有什么問題
 
 這里我們可以看到假設窗口的大小是1,也是就每次只能發(fā)送一個數據只有接受方對這個數據進行確認了以后才能發(fā)送第2個數據。我們可以看到發(fā)送方每發(fā)送一個數據接受方就要給發(fā)送方一個ACK對這個數據進行確認。只有接受到了這個確認數據以后發(fā)送方才能傳輸下個數據。 這樣如果說窗口過小,那么當傳輸比較大的數據的時候需要不停的對數據進行確認,這個時候就會造成很大的延遲。如果說窗口的大小定義的過大。我們假設發(fā)送方一次發(fā)送100個數據。但是接收方只能處理50個數據。這樣每次都會只對這50個數據進行確認。發(fā)送方下一次還是發(fā)送100個數據,但是接受方還是只能處理50個數據。這樣就避免了不必要的數據來擁塞我們的鏈路。所以我們就引入了滑動窗口機制,窗口的大小并不是固定的而是根據我們之間的鏈路的帶寬的大小進行動態(tài)變化。
通過一下幾張圖來看一下滑動窗口的工作
 
 首先是第一次發(fā)送數據這個時候的窗口大小是根據鏈路帶寬的大小來決定的。我們假設這個時候窗口的大小是3。這個時候接受方收到數據以后會對數據進行確認告訴發(fā)送方我下次希望手到的是數據是多少。這里我們看到接收方發(fā)送的ACK=3(這是發(fā)送方發(fā)送序列2的回答確認,下一次接收方期望接收到的是3序列信號)。這個時候發(fā)送方收到這個數據以后就知道我第一次發(fā)送的3個數據對方只收到了2個。就知道第3個數據對方沒有收到。下次在發(fā)送的時候就從第3個數據開始發(fā)。這個時候窗口大小就變成了2。
 這個時候發(fā)送方發(fā)送2個數據。
 看到接收方發(fā)送的ACK是5就表示他下一次希望收到的數據是5,發(fā)送方就知道我剛才發(fā)送的2個數據對方收了這個時候開始發(fā)送第5個數據。
 這就是滑動窗口的工作機制,當鏈路變好了或者變差了這個窗口還會發(fā)生變話,并不是第一次協(xié)商好了以后就永遠不變了。
總結
 
                            
                        - 上一篇: foobar 2000|foobar20
- 下一篇: 前端学习(1383):多人管理项目3
