第3章 傳輸層協(xié)議及進程通信_第1頁
第3章 傳輸層協(xié)議及進程通信_第2頁
第3章 傳輸層協(xié)議及進程通信_第3頁
第3章 傳輸層協(xié)議及進程通信_第4頁
第3章 傳輸層協(xié)議及進程通信_第5頁
已閱讀5頁,還剩38頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

1、 第第3章章 傳輸層協(xié)議與傳輸層協(xié)議與進程通信進程通信v 設置傳輸層的原因設置傳輸層的原因v 傳輸層的主要功能傳輸層的主要功能v TCP協(xié)議的主要特點協(xié)議的主要特點v UDP協(xié)議的主要特點協(xié)議的主要特點v 實現(xiàn)實現(xiàn)傳輸層進程通信的設計傳輸層進程通信的設計方法方法3.1 傳輸層的基本概念傳輸層的基本概念3.1.1 傳輸層的基本功能傳輸層的基本功能根本目的:根本目的:在網(wǎng)絡層提供的數(shù)據(jù)通信服務基礎上,實現(xiàn)主機進程間可靠服務,v “端到端”服務(主機-主機 端-端)v 兩大功能:兩大功能:加強、彌補網(wǎng)絡層提供的網(wǎng)絡服務進一步提供進程通信機制3.1.1 傳輸層的基本功能傳輸層的基本功能3.1.2 傳輸

2、層與應用層、網(wǎng)絡層之間的關系傳輸層與應用層、網(wǎng)絡層之間的關系3.1.3應用進程、傳輸層接口與套接字應用進程、傳輸層接口與套接字 傳輸層協(xié)議在本地主機操作系統(tǒng)控制下,為應用程序提供確定的服務 網(wǎng)絡層解決IP地址,傳輸層解決進程標識 套接字:建立網(wǎng)絡應用程序的可編程接口(應用編程接口API)3.1.4 網(wǎng)絡環(huán)境中的應用進程標識網(wǎng)絡環(huán)境中的應用進程標識1 應用進程標識的基本方法應用進程標識的基本方法 傳輸層進程尋址:通過TCP/UDP端口號實現(xiàn)3.1.4 網(wǎng)絡環(huán)境中的應用進程標識網(wǎng)絡環(huán)境中的應用進程標識2端口號的分配方法端口號的分配方法表5-1 UDP常用的熟知端口號表5-2 TCP常用的熟知端口號

3、端口號服務進程說 明端口號服務進程說 明53Domain域名服務20FTP文件傳輸(數(shù)據(jù)連接)67/68DHCP動態(tài)主機配置協(xié)議21FTP文件傳輸(控制連接)69TFTP簡單文件傳輸協(xié)議23TELNET網(wǎng)絡虛擬終端協(xié)議111RPC遠程過程調(diào)用25SMTP簡單郵件傳輸協(xié)議123NTP網(wǎng)絡時間協(xié)議80HTTP超文本傳輸協(xié)議161/162SNMP簡單網(wǎng)絡管理協(xié)議119NNTP網(wǎng)絡新聞傳輸協(xié)議520RIP路由信息協(xié)議179BGP邊界路由協(xié)議3.1.4 網(wǎng)絡環(huán)境中的應用進程標識網(wǎng)絡環(huán)境中的應用進程標識3 網(wǎng)絡環(huán)境中的進程識別網(wǎng)絡環(huán)境中的進程識別進程標識五元組:進程標識五元組:協(xié)議、本地地址、本地端口、遠

4、程地址、遠程端口號3.1.5 傳輸層的多路復用與多路分解傳輸層的多路復用與多路分解運行TCP/IP協(xié)議主機可能同時運行不同應用層協(xié)議和應用程序3.2 傳輸層協(xié)議特點與比較傳輸層協(xié)議特點與比較3.2.1 TCP/UDP協(xié)議協(xié)議比較比較的關系的關系表5-3 TCP與UDP協(xié)議比較特征特征/描述描述TCPUDP一般描述允許應用程序可靠地發(fā)送數(shù)據(jù),功能齊全簡單、高速,只負責將應用層與網(wǎng)絡層銜接起來面向連接與無連接面向連接,在TPDU傳輸之前需要建立TCP連接無連接,在TPDU傳輸之前不需要建立UDP連接與應用層的數(shù)據(jù)接口基于字節(jié)流,應用層不需要規(guī)定特點的數(shù)據(jù)格式基于報文,應用層需要將數(shù)據(jù)分成包來傳送可

5、靠性與確認可靠報文傳輸,對所有的數(shù)據(jù)均要確認不可靠,不需要對傳輸?shù)臄?shù)據(jù)確認,盡力而為地交付重傳自動重傳丟失的數(shù)據(jù)不負責檢查是否丟失數(shù)據(jù)和重傳開銷低,但高于UDP很低傳輸速率高,但低于UDP很高適用的數(shù)據(jù)量從少量到幾個GB的數(shù)據(jù)從少量到幾百個字節(jié)的數(shù)據(jù)適用的應用類型對數(shù)據(jù)傳輸可靠性要求較高的應用,例如文件與報文傳輸發(fā)送數(shù)量比較少,對數(shù)據(jù)傳輸可靠性要求低的應用,例如IP電話、視頻會議、多播與廣播3.2.2 TCP/UDP協(xié)議與應用層協(xié)議協(xié)議與應用層協(xié)議的關系的關系3.3 用戶數(shù)據(jù)報協(xié)議用戶數(shù)據(jù)報協(xié)議UDP 3.3.1 UDP協(xié)議的主要特點協(xié)議的主要特點 無連接、不可靠的傳輸協(xié)議(開銷低、盡力而為)

6、。 面向報文的傳輸層協(xié)議(保留原報文)3.3.2 UDP數(shù)據(jù)報格式數(shù)據(jù)報格式3.3.3 UDP校驗和計算校驗和計算校驗和計算:校驗和計算:偽報頭+UDP數(shù)據(jù)報v 偽報頭偽報頭驗證UDP數(shù)據(jù)報是否正確傳送到目的進程v 偽報頭偽報頭結(jié)構結(jié)構3.3.3 UDP校驗和計算校驗和計算校驗和計算方法校驗和計算方法3.3.4 UDP協(xié)議適用的范圍協(xié)議適用的范圍v 對性能的要求高于對數(shù)據(jù)完整性的要求對性能的要求高于對數(shù)據(jù)完整性的要求視頻播放實時交付的要求高于對數(shù)據(jù)交付可靠性要求(可丟失個別數(shù)據(jù)包)v 需要需要“簡短快捷簡短快捷”的數(shù)據(jù)交換的數(shù)據(jù)交換簡單的請求與應答報文交互v 需要多播和廣播的應用需要多播和廣播

7、的應用源主機以恒定速率發(fā)送報文,擁塞發(fā)生時允許丟棄部分報文3.4 TCP : Transmission Control Protocol,傳輸控制協(xié)議傳輸控制協(xié)議目標:目標:提供可靠的流傳輸服務問題:問題: 不可靠的無連接分組交付的問題(IP/網(wǎng)絡層提供的服務)包錯誤、丟失、無序、重復、延遲缺乏擁塞控制TCP的解讀:的解讀:靜態(tài)結(jié)構:靜態(tài)結(jié)構:報文結(jié)構動態(tài)行為:動態(tài)行為:連接的建立與釋放機制;確認重傳機制;流量控制機制;擁塞控制機制性能優(yōu)化:性能優(yōu)化:自適應重傳算法(Karn)、擁塞避免的路由器隨機早期丟棄算法(RED)、避免糊涂窗口綜合征的Nagle和Clark算法等3.4.1 TCP協(xié)議的

8、主要特點協(xié)議的主要特點v支持面向連接的傳輸服務(虛電路連接,打電話)v支持字節(jié)流傳輸(管道,按序)v支持全雙工服務(雙向,捎帶確認,火星通訊)v支持建立多個并發(fā)的TCP連接(服務器同時響應多個連接)v支持可靠傳輸服務(確認機制,擁塞控制)3.4.1 TCP協(xié)議的主要特點協(xié)議的主要特點3.4.2 TCP報文格式報文格式3.4.2 TCP報文格式報文格式標志標志說說 明明SYN當SYNl,而ACK0時,表明這是一個建立連接請求報文,若對方同意建立該連接,則應在發(fā)回的報文中將SYN和ACK標志位同時置1。實質(zhì)上,就是用SYN來代表Connection Request和Connection Accep

9、ted,用ACK位來區(qū)分這兩種情況。ACK確認號字段的值有效。只有當ACKl時,確認序號字段才有意義。當ACK0時,確認序號沒有意義。FIN終止連接。當FIN1時,表明數(shù)據(jù)已經(jīng)發(fā)送完畢,并請求釋放連接。RST連接必須復位。當RSTl時,表明出現(xiàn)嚴重差錯,必須釋放連接,然后重新建立連接。URG此報文是緊急數(shù)據(jù),應盡快傳送出去。此標志位要與緊急指針字段配合使用,由緊急指針指出在本報文段中的緊急數(shù)據(jù)的最后一個字節(jié)的編號。PSH將數(shù)據(jù)推向前。當PSHl時,請求接收方TCP軟件將該報文立即推送給應用程序。3.4.3 TCP連接建立連接建立、釋放釋放1)(經(jīng)歷3次握手)2)報文傳輸(雙向傳輸)3)連接釋放

10、(經(jīng)歷4次握手)連接建立/釋放過程3.4.3 TCP連接建立連接建立、釋放釋放保持定時器保持定時器、時間等待定時器時間等待定時器TCP的的4個定時器:個定時器:重傳定時器、堅持定時器、保持定時器、時間等待定時器v 保持定時器保持定時器(激活定時器激活定時器)用來防止TCP連接長時間處于空閑狀態(tài)v 時間等待定時器時間等待定時器連接終止期間使用,TCP關閉連接,并不馬上真正關閉,在時間等待期間,連接處于一種過渡狀態(tài)3.4.4 TCP滑動窗口與確認重傳機制滑動窗口與確認重傳機制TCP設計思想設計思想v 應用進程將數(shù)據(jù)以字節(jié)流發(fā)送,無需考慮發(fā)送數(shù)據(jù)字節(jié)長度,由TCP負責將字節(jié)流分段打包v 依靠TCP連

11、接傳送字節(jié)流,按序的,無差錯、不丟失、不重復v 提供差錯控制功能,保證正確接收字節(jié)流(通過差錯檢測、確認、重傳實現(xiàn))滑動窗口概念滑動窗口概念字節(jié)為單位控制字節(jié)流的發(fā)送、接收、確認、重傳過程3.4.4 TCP滑動窗口與確認重傳機制滑動窗口與確認重傳機制理解理解滑動窗口滑動窗口,注意幾個問題,注意幾個問題v 2個緩存、2個窗口(控制字節(jié)流傳輸過程)發(fā)送方緩存:用于存儲準備發(fā)送的數(shù)據(jù)發(fā)送窗口:窗口值不為0,可以發(fā)送報文段接收方緩存:將正確接收的字節(jié)流寫入緩存,等待接收讀取接收窗口:窗口值=接收緩存可以接收的字節(jié)流v 字節(jié)流分段,按段(序號)傳輸,捎帶確認(確認號)v 通過滑動窗口跟蹤、記錄發(fā)送狀態(tài),

12、實現(xiàn)差錯控制3.4.4 TCP滑動窗口與確認重傳機制滑動窗口與確認重傳機制3.4.4 TCP滑動窗口與確認重傳機制滑動窗口與確認重傳機制3.4.4 TCP滑動窗口與確認重傳機制滑動窗口與確認重傳機制 選擇重發(fā)策略選擇重發(fā)策略v 回退方式假設丟失了第2個報文段,不管之后的報文段是否已正確接收,從第2個報文段的第1個字節(jié)序號151開始,重發(fā)所有的4個報文段。顯然,效率低下。v 擇重發(fā)方式接收方收到不連續(xù)的字節(jié)時,如果這些字節(jié)的序號都在接收窗口之內(nèi),則首先接收緩存這些字節(jié),并將丟失的字節(jié)流序號通知發(fā)送方,發(fā)送方只需重發(fā)丟失的報文段,而不需要重發(fā)已經(jīng)接收的報文段。3.4.4 TCP滑動窗口與確認重傳機

13、制滑動窗口與確認重傳機制 選擇重發(fā)策略選擇重發(fā)策略3.4.4 TCP滑動窗口與確認重傳機制滑動窗口與確認重傳機制重傳定時器重傳定時器 處理報文確認與等待重傳的時間。發(fā)送一個報文,將其副本放入重傳隊列3.4.5 TCP窗口與窗口與 流量控制、擁塞控制流量控制、擁塞控制1TCP窗口與流量控制窗口與流量控制 由發(fā)送方控制發(fā)送速率,使之不超過接收速率,防止接收方來不及接收字節(jié)流,而出現(xiàn)報文丟失現(xiàn)象。流量控制過程流量控制過程v 接收方從緩存中讀取速度大于等于字節(jié)到達速度,接收方在每個確認中發(fā)出一個非零窗口通告。v 如果發(fā)送方發(fā)送速度比接收方讀取速度快,將造成緩沖區(qū)被全部占用,之后到達的字節(jié)因緩沖區(qū)溢出而

14、丟棄。此時,接收方必須發(fā)出一個“零窗口”的通告。告知當發(fā)送方停止發(fā)送(直到接收“非零窗口”通告為止)。v 接收方需要接收能力給出一個合適的接收窗口,并將它寫入TCP報頭中,通知發(fā)送方。3.4.5 TCP窗口與窗口與 流量控制、擁塞控制流量控制、擁塞控制1TCP窗口與流量控制窗口與流量控制堅持定時器堅持定時器接收方發(fā)出了“零窗口”通告之后,發(fā)送方停止發(fā)送,直到接收方再發(fā)出“非零窗口”通告為止。問題:問題:如果“非零窗口”通告丟失,發(fā)送方將無休止地等待接收方通知,才能繼續(xù)發(fā)送報文段,造成死鎖。解決:解決:設置“堅持定時器”發(fā)送方收到“零窗口”通告為零的確認時,啟動“堅持定時器”。堅持定時器時間到時

15、,發(fā)送方發(fā)生探測報文(提示接收方,確認已丟失,必須重傳)。3.4.5 TCP窗口與窗口與 流量控制、擁塞控制流量控制、擁塞控制傳輸效率問題傳輸效率問題必須解決好“什么時候”發(fā)送,要發(fā)送“多長”報文段受應用進程產(chǎn)生數(shù)據(jù)速度、接收方要求發(fā)送速度的影響(很復雜問題) 提高傳輸效率提高傳輸效率Nagle算法算法v 當數(shù)據(jù)以每次1B的方式進入發(fā)送方時,第1次發(fā)送方只發(fā)送1B,其他的字節(jié)存入緩沖區(qū)。v 當?shù)?個報文段被確認,再把緩沖區(qū)中數(shù)據(jù)放入第2個報文段中發(fā)送,這樣一邊發(fā)送/等待確認,一邊緩存待發(fā)送數(shù)據(jù)(可有效提高傳輸效率)。v 當緩存的數(shù)據(jù)字節(jié)數(shù)達到發(fā)送窗口的1/2(接近MSS),立即將它們作為一個報

16、文段發(fā)送。3.4.5 TCP窗口與窗口與 流量控制、擁塞控制流量控制、擁塞控制傳輸效率問題傳輸效率問題糊涂窗口綜合癥現(xiàn)象:造成傳輸效率極低 Clark算法算法解決解決思想思想v 禁止接收方發(fā)送1B的窗口更新報文,讓接收方等待一段時間,使接收緩存有足夠的空間接收一個較長的報文段。v 如果通知窗口長度達到空閑空間,再發(fā)送窗口更新報文。v 接收方等待一段時間對發(fā)送方有好處(積累一定長度的數(shù)據(jù)字節(jié),發(fā)送長報文也有利于提高傳輸效率。3.4.5 TCP窗口與窗口與 流量控制、擁塞控制流量控制、擁塞控制2TCP窗口與擁塞控制窗口與擁塞控制對網(wǎng)絡資源的需求 網(wǎng)絡可用資源3.4.5 TCP窗口與窗口與 流量控制

17、、擁塞控制流量控制、擁塞控制2TCP窗口與擁塞控制窗口與擁塞控制v 實現(xiàn)擁塞控制最基本手段:TCP滑動窗口技術。v 發(fā)送數(shù)據(jù),既要考慮接收能力,又要避免網(wǎng)絡發(fā)生擁塞v 發(fā)送窗口計算發(fā)送窗口 = Min(通知窗口,擁塞窗口 )v 通知窗口通知窗口rwnd:接收方允許接收的能力,來自接收方流量控制(將“通知窗口”值放在TCP報頭中,傳送給發(fā)送端)。v 擁塞窗口擁塞窗口cwnd:發(fā)送方根據(jù)網(wǎng)絡擁塞情況得出的窗口值,來自發(fā)送方的流量控制。v 未發(fā)生擁塞情況下,接收方“通知窗口”和“擁塞窗口”是一致的3.4.5 TCP窗口與窗口與 流量控制、擁塞控制流量控制、擁塞控制2TCP窗口與擁塞控制窗口與擁塞控制v 擁塞窗口cwnd:發(fā)送方根據(jù)網(wǎng)絡擁塞情況動態(tài)調(diào)整。網(wǎng)絡沒有出現(xiàn)擁塞,逐漸增大擁塞窗口;出現(xiàn)擁塞時,擁塞窗口立即減少。v 擁塞控制方法:慢開始、擁塞避免、快重傳、快恢復慢開始慢開始方法思想方法思想v 開始發(fā)送數(shù)據(jù)時,用試探方法,由小到大逐步增大cwnd值v 以二進制指數(shù)方式慢速增長(2n)3.4.5 TCP窗口與窗口與 流量控制、擁塞控制流量控制、擁塞控制慢開始閾值慢開始閾值SST:為避免擁塞窗口增長過快引起網(wǎng)絡擁塞 當cwndSST時,停止使用慢開始算法,使用擁塞避免算法。 當cwnd=SST時,既可以使用慢開始算法,也可使用擁塞避免算法。v 慢開始階段,若出現(xiàn)超時,發(fā)

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論