網(wǎng)絡(luò)七層模型_第1頁
網(wǎng)絡(luò)七層模型_第2頁
網(wǎng)絡(luò)七層模型_第3頁
網(wǎng)絡(luò)七層模型_第4頁
網(wǎng)絡(luò)七層模型_第5頁
已閱讀5頁,還剩1頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡介

TCP/IP四層模型TCP/IP參考模型

ISO制定的OSI參考模型的過于龐大、復(fù)雜招致了許多批評。與此對照,由技術(shù)人員自己開發(fā)的TCP/IP協(xié)議棧獲得了更為廣泛的應(yīng)用。如圖2-1所示,是TCP/IP參考模型和OSI參考模型的對比示意圖。

圖2-1TCP/IP參考模型

2.1TCP/IP參考模型的層次結(jié)構(gòu)

TCP/IP協(xié)議棧是美國國防部高級研究計(jì)劃局計(jì)算機(jī)網(wǎng)(AdvancedResearchProjectsAgencyNetwork,ARPANET)和其后繼因特網(wǎng)使用的參考模型。ARPANET是由美國國防部(U.S.DepartmentofDefense,DoD)贊助的研究網(wǎng)絡(luò)。最初,它只連接了美國境內(nèi)的四所大學(xué)。隨后的幾年中,它通過租用的電話線連接了數(shù)百所大學(xué)和政府部門。最終ARPANET發(fā)展成為全球規(guī)模最大的互連網(wǎng)絡(luò)-因特網(wǎng)。最初的ARPANET于1990年永久性地關(guān)閉。

TCP/IP參考模型分為四個(gè)層次:應(yīng)用層、傳輸層、網(wǎng)絡(luò)互連層和主機(jī)到網(wǎng)絡(luò)層。如圖2-2所示。

圖2-2TCP/IP參考模型的層次結(jié)構(gòu)

在TCP/IP參考模型中,去掉了OSI參考模型中的會(huì)話層和表示層(這兩層的功能被合并到應(yīng)用層實(shí)現(xiàn))。同時(shí)將OSI參考模型中的數(shù)據(jù)鏈路層和物理層合并為主機(jī)到網(wǎng)絡(luò)層。下面,分別介紹各層的主要功能。

1、主機(jī)到網(wǎng)絡(luò)層

實(shí)際上TCP/IP參考模型沒有真正描述這一層的實(shí)現(xiàn),只是要求能夠提供給其上層-網(wǎng)絡(luò)互連層一個(gè)訪問接口,以便在其上傳遞IP分組。由于這一層次未被定義,所以其具體的實(shí)現(xiàn)方法將隨著網(wǎng)絡(luò)類型的不同而不同。

2、網(wǎng)絡(luò)互連層

網(wǎng)絡(luò)互連層是整個(gè)TCP/IP協(xié)議棧的核心。它的功能是把分組發(fā)往目標(biāo)網(wǎng)絡(luò)或主機(jī)。同時(shí),為了盡快地發(fā)送分組,可能需要沿不同的路徑同時(shí)進(jìn)行分組傳遞。因此,分組到達(dá)的順序和發(fā)送的順序可能不同,這就需要上層必須對分組進(jìn)行排序。

網(wǎng)絡(luò)互連層定義了分組格式和協(xié)議,即IP協(xié)議(InternetProtocol)。

網(wǎng)絡(luò)互連層除了需要完成路由的功能外,也可以完成將不同類型的網(wǎng)絡(luò)(異構(gòu)網(wǎng))互連的任務(wù)。除此之外,網(wǎng)絡(luò)互連層還需要完成擁塞控制的功能。

3、傳輸層

在TCP/IP模型中,傳輸層的功能是使源端主機(jī)和目標(biāo)端主機(jī)上的對等實(shí)體可以進(jìn)行會(huì)話。在傳輸層定義了兩種服務(wù)質(zhì)量不同的協(xié)議。即:傳輸控制協(xié)議TCP(transmissioncontrolprotocol)和用戶數(shù)據(jù)報(bào)協(xié)議UDP(userdatagramprotocol)。

TCP協(xié)議是一個(gè)面向連接的、可靠的協(xié)議。它將一臺主機(jī)發(fā)出的字節(jié)流無差錯(cuò)地發(fā)往互聯(lián)網(wǎng)上的其他主機(jī)。在發(fā)送端,它負(fù)責(zé)把上層傳送下來的字節(jié)流分成報(bào)文段并傳遞給下層。在接收端,它負(fù)責(zé)把收到的報(bào)文進(jìn)行重組后遞交給上層。TCP協(xié)議還要處理端到端的流量控制,以避免緩慢接收的接收方?jīng)]有足夠的緩沖區(qū)接收發(fā)送方發(fā)送的大量數(shù)據(jù)。

UDP協(xié)議是一個(gè)不可靠的、無連接協(xié)議,主要適用于不需要對報(bào)文進(jìn)行排序和流量控制的場合。

4、應(yīng)用層

TCP/IP模型將OSI參考模型中的會(huì)話層和表示層的功能合并到應(yīng)用層實(shí)現(xiàn)。

應(yīng)用層面向不同的網(wǎng)絡(luò)應(yīng)用引入了不同的應(yīng)用層協(xié)議。其中,有基于TCP協(xié)議的,如文件傳輸協(xié)議(FileTransferProtocol,F(xiàn)TP)、虛擬終端協(xié)議(TELNET)、超文本鏈接協(xié)議(HyperTextTransferProtocol,HTTP),也有基于UDP協(xié)議的。

2.2TCP/IP報(bào)文格式

1、IP報(bào)文格式

IP協(xié)議是TCP/IP協(xié)議族中最為核心的協(xié)議。它提供不可靠、無連接的服務(wù),也即依賴其他層的協(xié)議進(jìn)行差錯(cuò)控制。在局域網(wǎng)環(huán)境,IP協(xié)議往往被封裝在以太網(wǎng)幀中傳送。而所有的TCP、UDP、ICMP、IGMP數(shù)據(jù)都被封裝在IP數(shù)據(jù)報(bào)中傳送。如圖2-3所示:

圖2-3TCP/IP報(bào)文封裝

圖2-4是IP頭部(報(bào)頭)格式:(RFC791)。

圖2-4IP頭部格式

其中:

●版本(Version)字段:占4比特。用來表明IP協(xié)議實(shí)現(xiàn)的版本號,當(dāng)前一般為IPv4,即0100。

●報(bào)頭長度(InternetHeaderLength,IHL)字段:占4比特。是頭部占32比特的數(shù)字,包括可選項(xiàng)。普通IP數(shù)據(jù)報(bào)(沒有任何選項(xiàng)),該字段的值是5,即160比特=20字節(jié)。此字段最大值為60字節(jié)。

●服務(wù)類型(TypeofService,TOS)字段:占8比特。其中前3比特為優(yōu)先權(quán)子字段(Precedence,現(xiàn)已被忽略)。第8比特保留未用。第4至第7比特分別代表延遲、吞吐量、可靠性和花費(fèi)。當(dāng)它們?nèi)≈禐?時(shí)分別代表要求最小時(shí)延、最大吞吐量、最高可靠性和最小費(fèi)用。這4比特的服務(wù)類型中只能置其中1比特為1??梢匀珵?,若全為0則表示一般服務(wù)。服務(wù)類型字段聲明了數(shù)據(jù)報(bào)被網(wǎng)絡(luò)系統(tǒng)傳輸時(shí)可以被怎樣處理。例如:TELNET協(xié)議可能要求有最小的延遲,F(xiàn)TP協(xié)議(數(shù)據(jù))可能要求有最大吞吐量,SNMP協(xié)議可能要求有最高可靠性,NNTP(NetworkNewsTransferProtocol,網(wǎng)絡(luò)新聞傳輸協(xié)議)可能要求最小費(fèi)用,而ICMP協(xié)議可能無特殊要求(4比特全為0)。實(shí)際上,大部分主機(jī)會(huì)忽略這個(gè)字段,但一些動(dòng)態(tài)路由協(xié)議如OSPF(OpenShortestPathFirstProtocol)、IS-IS(IntermediateSystemtoIntermediateSystemProtocol)可以根據(jù)這些字段的值進(jìn)行路由決策。

●總長度字段:占16比特。指明整個(gè)數(shù)據(jù)報(bào)的長度(以字節(jié)為單位)。最大長度為65535字節(jié)。

●標(biāo)志字段:占16比特。用來唯一地標(biāo)識主機(jī)發(fā)送的每一份數(shù)據(jù)報(bào)。通常每發(fā)一份報(bào)文,它的值會(huì)加1。

●標(biāo)志位字段:占3比特。標(biāo)志一份數(shù)據(jù)報(bào)是否要求分段。

●段偏移字段:占13比特。如果一份數(shù)據(jù)報(bào)要求分段的話,此字段指明該段偏移距原始數(shù)據(jù)報(bào)開始的位置。

●生存期(TTL:TimetoLive)字段:占8比特。用來設(shè)置數(shù)據(jù)報(bào)最多可以經(jīng)過的路由器數(shù)。由發(fā)送數(shù)據(jù)的源主機(jī)設(shè)置,通常為32、64、128等。每經(jīng)過一個(gè)路由器,其值減1,直到0時(shí)該數(shù)據(jù)報(bào)被丟棄。

●協(xié)議字段:占8比特。指明IP層所封裝的上層協(xié)議類型,如ICMP(1)、IGMP(2)、TCP(6)、UDP(17)等。

●頭部校驗(yàn)和字段:占16比特。內(nèi)容是根據(jù)IP頭部計(jì)算得到的校驗(yàn)和碼。計(jì)算方法是:對頭部中每個(gè)16比特進(jìn)行二進(jìn)制反碼求和。(和ICMP、IGMP、TCP、UDP不同,IP不對頭部后的數(shù)據(jù)進(jìn)行校驗(yàn))。

●源IP地址、目標(biāo)IP地址字段:各占32比特。用來標(biāo)明發(fā)送IP數(shù)據(jù)報(bào)文的源主機(jī)地址和接收IP報(bào)文的目標(biāo)主機(jī)地址。

可選項(xiàng)字段:占32比特。用來定義一些任選項(xiàng):如記錄路徑、時(shí)間戳等。這些選項(xiàng)很少被使用,同時(shí)并不是所有主機(jī)和路由器都支持這些選項(xiàng)。可選項(xiàng)字段的長度必須是32比特的整數(shù)倍,如果不足,必須填充0以達(dá)到此長度要求。

2、TCP數(shù)據(jù)段格式

TCP是一種可靠的、面向連接的字節(jié)流服務(wù)。源主機(jī)在傳送數(shù)據(jù)前需要先和目標(biāo)主機(jī)建立連接。然后,在此連接上,被編號的數(shù)據(jù)段按序收發(fā)。同時(shí),要求對每個(gè)數(shù)據(jù)段進(jìn)行確認(rèn),保證了可靠性。如果在指定的時(shí)間內(nèi)沒有收到目標(biāo)主機(jī)對所發(fā)數(shù)據(jù)段的確認(rèn),源主機(jī)將再次發(fā)送該數(shù)據(jù)段。

如圖2-5所示,是TCP頭部結(jié)構(gòu)(RFC793、1323)。

圖2-5TCP頭部結(jié)構(gòu)

●源、目標(biāo)端口號字段:占16比特。TCP協(xié)議通過使用"端口"來標(biāo)識源端和目標(biāo)端的應(yīng)用進(jìn)程。端口號可以使用0到65535之間的任何數(shù)字。在收到服務(wù)請求時(shí),操作系統(tǒng)動(dòng)態(tài)地為客戶端的應(yīng)用程序分配端口號。在服務(wù)器端,每種服務(wù)在"眾所周知的端口"(Well-KnowPort)為用戶提供服務(wù)。

●順序號字段:占32比特。用來標(biāo)識從TCP源端向TCP目標(biāo)端發(fā)送的數(shù)據(jù)字節(jié)流,它表示在這個(gè)報(bào)文段中的第一個(gè)數(shù)據(jù)字節(jié)。

●確認(rèn)號字段:占32比特。只有ACK標(biāo)志為1時(shí),確認(rèn)號字段才有效。它包含目標(biāo)端所期望收到源端的下一個(gè)數(shù)據(jù)字節(jié)。

●頭部長度字段:占4比特。給出頭部占32比特的數(shù)目。沒有任何選項(xiàng)字段的TCP頭部長度為20字節(jié);最多可以有60字節(jié)的TCP頭部。

●標(biāo)志位字段(U、A、P、R、S、F):占6比特。各比特的含義如下:

◆URG:緊急指針(urgentpointer)有效。

◆ACK:確認(rèn)序號有效。

◆PSH:接收方應(yīng)該盡快將這個(gè)報(bào)文段交給應(yīng)用層。

◆RST:重建連接。

◆SYN:發(fā)起一個(gè)連接。

◆FIN:釋放一個(gè)連接。

●窗口大小字段:占16比特。此字段用來進(jìn)行流量控制。單位為字節(jié)數(shù),這個(gè)值是本機(jī)期望一次接收的字節(jié)數(shù)。

●TCP校驗(yàn)和字段:占16比特。對整個(gè)TCP報(bào)文段,即TCP頭部和TCP數(shù)據(jù)進(jìn)行校驗(yàn)和計(jì)算,并由目標(biāo)端進(jìn)行驗(yàn)證。

●緊急指針字段:占16比特。它是一個(gè)偏移量,和序號字段中的值相加表示緊急數(shù)據(jù)最后一個(gè)字節(jié)的序號。

●選項(xiàng)字段:占32比特。可能包括"窗口擴(kuò)大因子"、"時(shí)間戳"等選項(xiàng)。

3、UDP數(shù)據(jù)段格式

UDP是一種不可靠的、無連接的數(shù)據(jù)報(bào)服務(wù)。源主機(jī)在傳送數(shù)據(jù)前不需要和目標(biāo)主機(jī)建立連接。數(shù)據(jù)被冠以源、目標(biāo)端口號等UDP報(bào)頭字段后直接發(fā)往目的主機(jī)。這時(shí),每個(gè)數(shù)據(jù)段的可靠性依靠上層協(xié)議來保證。在傳送數(shù)據(jù)較少、較小的情況下,UDP比TCP更加高效。

如圖2-6所示,是UDP頭部結(jié)構(gòu)(RFC793、1323):

●源、目標(biāo)端口號字段:占16比特。作用與TCP數(shù)據(jù)段中的端口號字段相同,用來標(biāo)識源端和目標(biāo)端的應(yīng)用進(jìn)程。

●長度字段:占16比特。標(biāo)明UDP頭部和UDP數(shù)據(jù)的總長度字節(jié)。

●校驗(yàn)和字段:占16比特。用來對UDP頭部和UDP數(shù)據(jù)進(jìn)行校驗(yàn)。和TCP不同的是,對UDP來說,此字段是可選項(xiàng),而TCP數(shù)據(jù)段中的校驗(yàn)和字段是必須有的。

2.3套接字

在每個(gè)TCP、UDP數(shù)據(jù)段中都包含源端口和目標(biāo)端口字段。有時(shí),我們把一個(gè)IP地址和一個(gè)端口號合稱為一個(gè)套接字(Socket),而一個(gè)套接字對(Socketpair)可以唯一地確定互連網(wǎng)絡(luò)中每個(gè)TCP連接的雙方(客戶IP地址、客戶端口號、服務(wù)器IP地址、服務(wù)器端口號)。

如圖2-7所示,是常見的一些協(xié)議和它們對應(yīng)的服務(wù)端口號。

圖2-7常見協(xié)議和對應(yīng)的端口號

需要注意的是,不同的應(yīng)用層協(xié)議可能基于不同的傳輸層協(xié)議,如FTP、TELNET、SMTP協(xié)議基于可靠的TCP協(xié)議。TFTP、SNMP、RIP基于不可靠的UDP協(xié)議。

同時(shí),有些應(yīng)用層協(xié)議占用了兩個(gè)不同的端口號,如FTP的20、21端口,SNMP的161、162端口。這些應(yīng)用層協(xié)議在不同的端口提供不同的功能。如FTP的21端口用來偵聽用戶的連接請求,而20端口用來傳送用戶的文件數(shù)據(jù)。再如,SNMP的161端口用于SNMP管理進(jìn)程獲取SNMP代理的數(shù)據(jù),而162端口用于SNMP代理主動(dòng)向SNMP管理進(jìn)程發(fā)送數(shù)據(jù)。

還有一些協(xié)議使用了傳輸層的不同協(xié)議提供的服務(wù)。如DNS協(xié)議同時(shí)使用了TCP53端口和UDP53端口。DNS協(xié)議在UDP的53端口提供域名解析服務(wù),在TCP的53端口提供DNS區(qū)域文件傳輸服務(wù)。

2.4TCP連接建立、釋放時(shí)的握手過程

1、TCP建立連接的三次握手過程

TCP會(huì)話通過三次握手來初始化。三次握手的目標(biāo)是使數(shù)據(jù)段的發(fā)送和接收同步。同時(shí)也向其他主機(jī)表明其一次可接收的數(shù)據(jù)量(窗口大?。⒔⑦壿嬤B接。這三次握手的過程可以簡述如下:

●源主機(jī)發(fā)送一個(gè)同步標(biāo)志位(SYN)置1的TCP數(shù)據(jù)段。此段中同時(shí)標(biāo)明初始序號(InitialSeque

溫馨提示

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

最新文檔

評論

0/150

提交評論