小紅帽技術論壇 在這裡你可以看到你訂閱的主題,悄悄話,編輯個人資料及環境設定 免費註冊! 行事曆 搜尋其他會員 常見問題
搜尋 小紅帽流量分析 小紅帽專用irc 聊天室 Web 版!建議安裝使用 hmirc 軟體! 回首頁 登出
小紅帽技術論壇 : Powered by vBulletin version 2.2.9 小紅帽技術論壇 > 電腦類 > IT認證考試板 > 《教學》CISCO CCNA 640-802 第二章 網絡互聯 主機到主機層協議
  上一篇主題   下一篇主題
作者
主題、內容    發表新的文章     回覆文章

benshaoxw
違規停權

註冊日期: Mar 2009
來自:
發表文章數: 29

《教學》CISCO CCNA 640-802 第二章 網絡互聯 主機到主機層協議

主機到主機層的目的:就是將上一層的應用程式從複雜的網絡傳輸中屏閉出來。
而這次運行之中需要經過兩個協議 TCP 和UDP 下麵我來一個一個介紹一下
TCP:Transmission Control Protocol 傳輸控制協議
  首先,TCP建立連接之後,通信雙方都同時可以進行數據的傳輸,其次,他是全雙工的;在保證可靠性上,采用超時重傳和捎帶確認機制。
  在流量控制上,采用滑動窗口協議,協議中規定,對於窗口內未經確認的分組需要重傳。
  在擁塞控制上,采用慢啟動算法。
  註解:該協議主要用於在主機間建立壹個虛擬連接,以實現高可靠性的數據包交換。IP協議可以進行IP數據包的分割和組裝,但是通過IP協議並不能清楚地了解到數據包是否順利地發送給目標計算機。而使用TCP協議就不同了,在該協議傳輸模式中在將數據包成功發送給目標計算機後,TCP會要求發送壹個確認;如果在某個時限內沒有收到確認,那麽TCP將重新發送數據包。另外,在傳輸的過程中,如果接收到無序、丟失以及被破壞的數據包,TCP還可以負責恢復。
  傳輸控制協議(Transmission Control Protocol,TCP)是壹種面向連接的、可靠的、基於字節流的運輸層通信協議,通常由IETF的RFC 793說明。在簡化的計算機網絡OSI模型中,它完成運輸層所指定的功能。
UDP(User Datagram Protocol) 用戶數據報協議
  用戶數據報協議(UDP)是 OSI 參考模型中壹種無連接的傳輸層協議,提供面向事務的簡單不可靠信息傳送服務。是壹個簡單的面向數據報的傳輸層協議,IETF RFC 768是UDP的正式規範。 UDP 協議基本上是 IP 協議與上層協議的接口。 UDP 協議適用端口分別運行在同壹臺設備上的多個應用程序。
  由於大多數網絡應用程序都在同壹臺機器上運行,計算機上必須能夠確保目的地機器上的軟件程序能從源地址機器處獲得數據包,以及源計算機能收到正確的回復。這是通過使用 UDP 的“端口號”完成的。例如,如果壹個工作站希望在工作站 128.1.123.1 上使用域名服務系統,它就會給數據包壹個目的地址 128.1.123.1 ,並在 UDP 頭插入目標端口號 53 。源端口號標識了請求域名服務的本地機的應用程序,同時需要將所有由目的站生成的響應包都指定到源主機的這個端口上。 UDP 端口的詳細介紹可以參照相關文章。
  與 TCP 不同, UDP 並不提供對 IP 協議的可靠機制、流控制以及錯誤恢復功能等。由於 UDP 比較簡單, UDP 頭包含很少的字節,比 TCP 負載消耗少。
  UDP 適用於不需要 TCP 可靠機制的情形,比如,當高層協議或應用程序提供錯誤和流控制功能的時候。 UDP 是傳輸層協議,服務於很多知名應用層協議,包括網絡文件系統(NFS)、簡單網絡管理協議(SNMP)、域名系統(DNS)以及簡單文件傳輸系統(TFTP)、動態主機配置協議(DHCP)、路由信息協議(RIP)和某些影音串流服務等等。
  協議結構
  Source Port — 16位。源端口是可選字段。當使用時,它表示發送程序的端口,同時它還被認為是沒有其它信息的情況下需要被尋址的答復端口。如果不使用,設置值為0。
  Destination Port — 16位。目標端口在特殊因特網目標地址的情況下具有意義。
  Length — 16位。該用戶數據報的八位長度,包括協議頭和數據。長度最小值為8。
  Checksum — 16位。IP 協議頭、UDP 協議頭和數據位,最後用0填補的信息假協議頭總和。如果必要的話,可以由兩個八位復合而成。
  Data — 包含上層數據信息。
  UDP協議有如下的特點:
  1、UDP傳送數據前並不與對方建立連接,即UDP是無連接的,在傳輸數據前,發送方和接收方相互交換信息使雙方同步。
  2、UDP不對收到的數據進行排序,在UDP報文的首部中並沒有關於數據順序的信息(如TCP所采用的序號),而且報文不壹定按順序到達的,所以接收端無從排起。
  3、UDP對接收到的數據報不發送確認信號,發送端不知道數據是否被正確接收,也不會重發數據。
  4、UDP傳送數據較TCP快速,系統開銷也少。
  5、由於缺乏擁塞控制(congestion control),需要基於網絡的機制來減小因失控和高速UDP流量負荷而導致的擁塞崩潰效應。換句話說,因為UDP發送者不能夠檢測擁塞,所以像使用包隊列和丟棄技術的路由器這樣的網絡基本設備往往就成為降低UDP過大通信量的有效工具。數據報擁塞控制協議(DCCP)設計成通過在諸如流媒體類型的高速率UDP流中增加主機擁塞控制來減小這個潛在的問題。

我將了這麼多,還有人問我? 你是做什麼的,什麼************怎麼樣,我想我這麼詳細地為大家免費講課好像不怎麼樣,其實我的目的就是在于讓大家了解************.
如果還不清楚我們的公司的話你可以看一下
http://www.************.net/about.asp

文章編號:0 | 向板主反映這篇文章 | 顯示 IP

benshaoxw 已離線! Old Post 04-11-2009 09:24
點選這裡查看 benshaoxw 的個人檔案 點選這裡寄送 Email 給 benshaoxw 按這裡傳送悄悄話給 benshaoxw 按這裡搜尋 benshaoxw 所發表的文章 按這裡將 benshaoxw 加入你的好友名單 回應這篇文章含引言 按這裡編輯或刪除文章

目前使用的時域為(台北時間),現在時間是 13:18 。    發表新的文章     回覆文章
上一篇主題   下一篇主題
友善列印 | 把這一篇寄給好朋友! | 訂閱這個主題

跳至:
評分主題:
 

討論區權限說明:
不可以 發表新文章
不可以 回覆文章
不可以 上傳附加檔案
不可以 修改你發表的文章
HTML code 目前狀態是 關閉
vB code 目前狀態是 開啟
表情符號 目前狀態是 開啟
[IMG] code 目前狀態是 開啟



< 聯絡我們 - 小紅帽全球資訊網 >

中文化:第一版 by Eric 第二版 by Jolin 於 小紅帽全球資訊網
(版權所有,翻拷必究)
小紅帽技術論壇創立於 2000/09/15 ,使用 vBulletin 合法註冊版權