安徽工程大學 網絡期末考試必備 運輸層復習_第1頁
安徽工程大學 網絡期末考試必備 運輸層復習_第2頁
安徽工程大學 網絡期末考試必備 運輸層復習_第3頁
安徽工程大學 網絡期末考試必備 運輸層復習_第4頁
安徽工程大學 網絡期末考試必備 運輸層復習_第5頁
已閱讀5頁,還剩15頁未讀 繼續免費閱讀

下載本文檔

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

文檔簡介

第七章運輸層1運輸層運輸層實現網絡上應用進程間的邏輯通信(端到端的通信)邏輯通信:網絡上的主機運輸層之間并沒有實際的物理連接,運輸層之間的通信要通過調用下層(網絡層)功能。運輸層向應用進程屏蔽了下面通信子網的細節(如網絡拓撲、采用的協議),它使應用進程看見的就是好像在兩個運輸層實體之間有一條端到端的邏輯通信信道運輸層的兩個不同的運輸協議:面向連接的TCP和面向無連接的UDP(兩個協議最大的區別)盡管網絡層提供的服務是不可靠的,但TCP采用了順序號、累積確認、校驗、超時/重傳的可靠傳輸的機制,提供了全雙工可靠傳輸服務。2運輸層的兩個重要協議TCP和UDP可靠傳輸:無差錯、按序、無丟失、無重復不可靠傳輸:不按序、可能會丟失和重復UDP協議是不可靠的,因為應用進程通過UDP協議接收的數據可能會有差錯?(這個說法是錯誤的!)傳輸控制協議TCP(TransmissionControlProtocol)面向連接的可靠傳輸,實現較復雜。協議數據單元為TCP報文段(segment)用戶數據報協議UDP(UserDatagramProtocol)面向無連接的可靠傳輸,實現簡單。協議數據單元為用戶數據報(UDP報文)3端口(port)應用層的進程通過端口與運輸層實體進行交互,運輸層通過端口號找到具體的應用進程,因此在TCP報文段和用戶數據報首部要寫入源端口號和目的端口號。端口用16位的端口號進行標識例如:HTTP(80)、FTP(21)網絡上進程通信所用到的地址:IP地址+端口號IP地址+端口號可以抽象為插口(socket,套接字)C++中,采用下面命令創建一個插口

Csocketm_socket;m_socket.Create();

m_socket.Connect(m_ip,6666);4用戶數據報協議UDPUDP只在IP數據報服務的基礎上增加了很少的功能,即端口功能(分用、復用功能)和差錯檢測功能。UDP適合于允許丟失一些數據,但不允許太大時延的場合IP電話、流媒體通信、DNS、TFTP、RIP、

SNMP、BOOTP/DHCP、NFSUDP計算檢驗和與IP數據報計算首部檢驗和的方法類似。IP數據報的檢驗和只檢驗IP數據報首部,UDP的檢驗和將首部和數據部分一起檢驗。(了解)5傳輸控制協議TCPTCP概述應用進程不斷的將數據塊通過端口寫到TCP發送緩存中,TCP每次從緩存中取出一定數量的數據,將其組成TCP報文段TCP報文段的首部源端口、目的端口序號。指的是本報文段數據的第一個字節的編號確認號。期望收到的下一個字節的編號,即下一個報文段的序號。確認比特ACK。ACK=1時確認號才有效同步比特。連接建立時用來同步序號。SYS置為1時表示這是一個連接請求或連接接受報文。終止比特FIN。用來釋放連接。當FIN=1表示數據發送完畢,要求釋放連接。6窗口。確定對方發送窗口的上限檢驗和。檢驗整個報文段(首部和數據)7TCP如何決定發送一個報文段的時機(了解)三種基本機制發送緩存中的數據達到MSS字節,就組裝成一個報文段發送出去發送端應用進程指明要求發送報文段,即推送(push)操作設置計時器,時間到則發送報文段Nagle算法:發送端不發送很小的報文段糊涂窗口綜合癥(sillywindowsyndrome)解決的方法:接收端不要在緩存剛有了一點小的空位置就急忙把一個很小的窗口大小通知給發送端收到亂序的報文段,TCP未明確規定要如何處理可以將亂序的報文段丟棄,也可以將其暫存于接收緩存中(連續ARQ協議或稱為GBN協議、滑動窗口協議,選擇重傳ARQ協議或稱為SR協議)8流量控制流量控制的實現:接受端設置發送端發送窗口的上限,限制發送端的發送速率。發送窗口:發送端使用的一個數據結構,用來管理存儲允許發送報文段的緩存。包括下列信息允許發送的未確認區間(第一個字節與最后一個字節編號表示)若干已發送的未確認報文段(第一個字節與最后一個字節編號)若干可用的空閑區接收窗口:接收端使用的一個數據結構,用來管理存儲允許接收報文段的緩存。只有當收到的報文段的序號落入接收窗口內才接收該報文段,并發出確認。連續ARQ協議接收窗口大小為1。允許接收的區間若干個已收到但未確認的報文段若干可用的空閑區9發送方,接收方的窗口10選擇重傳上層數據到達:如果窗口中的下一個序號可用,則發送下一個報文段timeout(n):第n個計時器跳重發報文段n,計時器復位ACK(n)到達n?[sendbase,sendbase+N]:標記報文段n已經收到如n為unACKed分組中的最小值,將窗口向前移動到下一個unACKed

seq#

發送方分組n到達n?[rcvbase,rcvbase+N-1]發送ACK(n),窗口大小如果失序:緩存如果有序:遞交到上層(同時遞交緩存中的其他有序分組),將窗口推進到下一個尚未收到的分組分組n到達[rcvbase-N,rcvbase-1]雖然接收方曾經確認,但仍然需要ACK(n)其他情況:忽略分組接收方11接收端如何設置發送端的發送窗口大小以實現流量控制發送窗口接收窗口?應用進程從接收緩存中讀取的最后一個字節LastByteReadLastByteRcvd放入接收緩存中的最后一個字節接收端窗口rwnd(或叫通知窗口)=接收緩存中空閑區的大小=Buffer-[LastByteRcvd-LastByteRead]由此,將發送端的發送窗口的上限設置為7接收緩存12擁塞控制發送端有一個擁塞窗口變量cwnd,發送窗口的大小不超過cwnd。發送窗口的上限=min(擁塞窗口,接收端窗口)發送端沒有按時收到確認信息,就認為網絡出現擁塞。擁塞控制算法:(1)慢開始。cwnd=1;每收到一個新報文段的確認cwnd加1個MSS,這是一個指數增長的過程;cwnd達到慢開始門限值ssthresh時慢開始階段結束;(2)擁塞避免階段。每經過一個往返時延RTTcwnd

就增加1個MSS,這是一個線性增長的過程13擁塞控制(續)(3)無論何時,只要發現網絡出現擁塞(出現超時),慢開始門限降為當前擁塞窗口的一半,然后擁塞窗口降為1個MSS擁塞控制兩個改進算法(了解)快重傳:收到三個重復的ack(4個相等的ack)則認為有報文段丟失,網絡出現擁塞。此時立即重傳丟失的報文段快恢復:收到三個重復的ack判斷出現擁塞,此時不是將擁塞窗口降為1,而是降為ssthreash+3*MSS,收到n個重復的ack則降為ssthreash+n*MSS14TCP的重傳機制TCP每發送一個報文段,就對這個報文段設置一次計時器,超時則重傳。超時重傳時間RTO(RetransmissionTime-Out)一般設為比平均往返時延(RTT,往返時延P19)稍長一點RTO=?*RTT(?原先推薦為2)平均RTT計算中的問題RTTnew=a*RTTold+(1-a)*RTTnowKarn算法(了解):重傳的報文段,得到的RTT不計算在平均RTT之內Karn算法修正(了解):報文段每重傳一次,就將超時重傳時間增大一些15采用隨機早期丟棄RED(Random

EarlyDiscard)進行擁塞控制(了解)路由器溢出造成后來到達的分組全部丟失,影響到多個相關的TCP連接因為擁塞控制而進入慢開始狀態,網絡上的通信量突然下降很多。通信量的不穩定造成了平均通信量的下降。要盡量推遲路由器進入溢出狀態的時間,由此在路由器還沒有出現溢出之前就開始隨機的丟棄一些分組。16TCP的運輸連接管理運輸連接的三個階段連接釋放、數據傳送、連接釋放連接建立要解決的問題(理解)每一方確知對方的存在允許雙方協商一些參數(如最大報文段長度MSS、最大窗口大小、服務質量)能夠對運輸實體資源(緩存大小、連接表項目、其它管理連接的數據結構)進行分配發起TCP連接的進程叫作客戶,響應連接申請的進程叫作服務器17連接建立的三次握手主機A的TCP向主機B的TCP發出連接請求報文段,其首部同步比特SYS置1,選擇一個序號x主機B收到連接請求報文段后,如同意,則發回確認。確認報文段中SYS和ACK置1,確認號為x+1,同時選擇自己的序號y主機A收到B的確認后,給B再發一個確認,其ACK置1,確認號y+1,自己的序號為x+1。并且A通知自己上層的應用進程,連接已經建立。B收到A的確認后,也通知自己上層的應用進程,連接已經建立。

(了解)主機A發送的第一個報文段其序號仍為x+1為什么要發送第三個報文段(第三次握手)?(理解)18用三次握手建立TCP連接SYN,SEQ=x主機BSYN,ACK,SEQ=y,ACK=x1ACK,SEQ=x+1,ACK=y

溫馨提示

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

評論

0/150

提交評論