TCP/IP（八）之總結TCP/IP四層模型

閱讀目錄(Content)

• 1、TCP/IP參考模型概述
• 1.一、TCP/IP參考模型的層次結構
• 2、TCP/IP四層功能概述 
• 2.一、主機到網絡層　　
• 2.二、網絡互連層　　
• 2.三、傳輸層　　
• 2.三、應用層　
• 3、TCP/IP報文格式
• 3.一、IP報文格式
• 3.二、TCP數據段格式
• 3.三、UDP數據段格式
• 3.四、套接字

前言

　　在這裏有一個問題，有的書上說TCP/IP是四層有的卻說是五層。其實這個問題我也上網查了一下資料。

　　tcp/ip是事實標準，分4層。osi模型是國際標準，分7層。講課的時候，通常把他們綜合起來說，就說是5層。他把網絡接口層分開爲數據鏈路層和物理層了。

　　咱們探討一下爲何ISO七層模型不適用而大部分都是使用的是TCP/IP四層模型呀？

　　OSI的七層協議體系結構的概念清楚，理論也比較完整，但它既複雜又不實用，TCP/IP體系結構則不一樣，它如今已經獲得了很是普遍的應用，TCP/IP是一個四層的體系結構，

　　它包含應用層、運輸層、網際層和網絡接口層（用網際層這個名字是強調這一層是爲了解決不一樣網絡的互連問題  ），不過從實質來說，TCP/IP只有最上面的三層，由於最下面的網絡接口層基本上和通常的通訊鏈路的功能上沒有多大差異，

　　對於計算機網絡來講，這一層並無什麼特別新的具體的內容，所以在學習計算機網絡原理是每每採用折中的辦法，即綜合OSI和TCP/IP的優勢，採用一種只有五層協議的體系結構

　　　　 

回到頂部(go to top)

1、TCP/IP參考模型概述

ISO制定的OSI參考模型的過於龐大、複雜招致了許多批評。與此對照，由技術人員本身開發的TCP/IP協議棧得到了更爲普遍的應用。以下圖，是TCP/IP參考模型和OSI參考模型的對比示意圖。

　　

1.一、TCP/IP參考模型的層次結構

　　TCP/IP協議棧是美國國防部高級研究計劃局計算機網（Advanced Research Projects Agency Network，ARPANET）和其後繼因特網使用的參考模型。ARPANET是由美國國防部（U.S．Department of Defense，DoD）贊助的研究網絡。

　　最初，它只鏈接了美國境內的四所大學。隨後的幾年中，它經過租用的電話線鏈接了數百所大學和政府部門。最終ARPANET發展成爲全球規模最大的互連網絡-因特網。最初的ARPANET於1990年永久性地關閉。　　
　　TCP/IP參考模型分爲四個層次：應用層、傳輸層、網絡互連層和主機到網絡層。以下圖所示。

　　

回到頂部(go to top)

2、TCP/IP四層功能概述 

　　在TCP/IP參考模型中，去掉了OSI參考模型中的會話層和表示層（這兩層的功能被合併到應用層實現）。同時將OSI參考模型中的數據鏈路層和物理層合併爲主機到網絡層。下面，分別介紹各層的主要功能。

2.一、主機到網絡層　　

　　網絡接入層與OSI參考模型中的物理層和數據鏈路層相對應。它負責監視數據在主機和網絡之間的交換。事實上，TCP/IP自己並未定義該層的協議，而由參與互連的各網絡使用本身的物理層和數據鏈路層協議，

　　而後與TCP/IP的網絡接入層進行鏈接。地址解析協議（ARP）工做在此層，即OSI參考模型的數據鏈路層。
　　實際上TCP/IP參考模型沒有真正描述這一層的實現，只是要求可以提供給其上層-網絡互連層一個訪問接口，以便在其上傳遞IP分組。因爲這一層次未被定義，因此其具體的實現方法將隨着網絡類型的不一樣而不一樣。　

2.二、網絡互連層　　

　　網絡互連層是整個TCP/IP協議棧的核心。它的功能是把分組發往目標網絡或主機。同時，爲了儘快地發送分組，可能須要沿不一樣的路徑同時進行分組傳遞。所以，分組到達的順序和發送的順序可能不一樣，這就須要上層必須對分組進行排序。　　
　　網絡互連層定義了分組格式和協議，即IP協議（Internet Protocol）。　　
　　網絡互連層除了須要完成路由的功能外，也能夠完成將不一樣類型的網絡（異構網）互連的任務。除此以外，網絡互連層還須要完成擁塞控制的功能。

2.三、傳輸層　　

   　在TCP/IP模型中，傳輸層的功能是使源端主機和目標端主機上的對等實體能夠進行會話。在傳輸層定義了兩種服務質量不一樣的協議。即：傳輸控制協議TCP（transmission control protocol）和用戶數據報協議UDP（user datagram protocol）。　　
　　TCP協議是一個面向鏈接的、可靠的協議。它將一臺主機發出的字節流無差錯地發往互聯網上的其餘主機。在發送端，它負責把上層傳送下來的字節流分紅報文段並傳遞給下層。

　　在接收端，它負責把收到的報文進行重組後遞交給上層。TCP協議還要處理端到端的流量控制，以免緩慢接收的接收方沒有足夠的緩衝區接收發送方發送的大量數據。　　
　　UDP協議是一個不可靠的、無鏈接協議，主要適用於不須要對報文進行排序和流量控制的場合。　　

2.三、應用層　

　　　TCP/IP模型將OSI參考模型中的會話層和表示層的功能合併到應用層實現。　　
　　應用層面向不一樣的網絡應用引入了不一樣的應用層 協議。其中，有基於TCP協議的，如文件傳輸協議（File Transfer Protocol，FTP）、虛擬終端協議（TELNET）、超文本連接協議（Hyper Text Transfer Protocol，HTTP），也有基於UDP協議的。

回到頂部(go to top)

3、TCP/IP報文格式

3.一、IP報文格式

　　IP協議是TCP/IP協議族中最爲核心的協議。它提供不可靠、無鏈接的服務，也即依賴其餘層的協議進行差錯控制。

　　在局域網環境，IP協議每每被封裝在以太網幀中傳送。而全部的TCP、UDP、ICMP、IGMP數據都被封裝在IP數據報中傳送。以下圖所示：
　　　　
　　　　　　　　TCP/IP報文封裝

　　　　

　　　　　　　　　　IP頭部（報頭）格式：（RFC 791）

　　分析：　　　

　　　　1）版本（Version）字段：佔4比特。用來代表IP協議實現的版本號，當前通常爲IPv4，即0100。　　
　　　　2）報頭長度（Internet Header Length，IHL）字段：佔4比特。是頭部佔32比特的數字，包括可選項。普通IP數據報（沒有任何選項），該字段的值是5，即160比特=20字節。此字段最大值爲60字節。　　　　　　　　

　　　　3）服務類型（Type of Service ，TOS）字段：佔8比特。其中前3比特爲優先權子字段（Precedence，現已被忽略）。第8比特保留未用。第4至第7比特分別表明延遲、吞吐量、可靠性和花費。
　　　　　　當它們取值爲1時分別表明要求最小時延、最大吞吐量、最高可靠性和最小費用。這4比特的服務類型中只能置其中1比特爲1。能夠全爲0，若全爲0則表示通常服務。服務類型字段聲明瞭數據報被網絡系統傳輸時能夠被怎樣處理。
　 　　　　　例如：TELNET協議可能要求有最小的延遲，FTP協議（數據）可能要求有最大吞吐量，SNMP協議可能要求有最高可靠 性，NNTP（Network News Transfer Protocol，網絡新聞傳輸協議）可能要求最小費用，而ICMP協議可能無特殊要求（4比特全爲0）。
　　　　　　實際上，大部分主機會忽略 這個字段，但一些動態路由協議如OSPF（Open Shortest Path First Protocol）、IS-IS（Intermediate System to Intermediate System Protocol）能夠根據這些字段的值進行路由決策。

　　　　4）總長度字段：佔16比特。指明整個數據報的長度（以字節爲單位）。最大長度爲65535字節。　　
　　　　5）標誌字段：佔16比特。用來惟一地標識主機發送的每一份數據報。一般每發一份報文，它的值會加1。　　
　　　　6）標誌位字段：佔3比特。標誌一份數據報是否要求分段。　　
　　　　7）段偏移字段：佔13比特。若是一份數據報要求分段的話，此字段指明該段偏移距原始數據報開始的位置。　　
　　　　8）生存期（TTL：Time to Live）字段：佔8比特。用來設置數據報最多能夠通過的路由器數。由發送數據的源主機設置，一般爲3二、6四、128等。每通過一個路由器，其值減1，直到0時該數據報被丟棄。　　
　　　　9）協議字段：佔8比特。指明IP層所封裝的上層協議類型，如ICMP（1）、IGMP（2） 、TCP（6）、UDP（17）等。　　
　　　　10）頭部校驗和字段：佔16比特。內容是根據IP頭部計算獲得的校驗和碼。計算方法是：對頭部中每一個16比特進行二進制反碼求和。（和ICMP、IGMP、TCP、UDP不一樣，IP不對頭部後的數據進行校驗）。　　
　　　　11）源IP地址、目標IP地址字段：各佔32比特。用來標明發送IP數據報文的源主機地址和接收IP報文的目標主機地址。　　
　　　　12）可選項字段：佔32比特。用來定義一些任選項：如記錄路徑、時間戳等。這些選項不多被使用，同時並非全部主機和路由器都支持這些選項。可選項字段的長度必須是32比特的整數倍，若是不足，必須填充0以達到此長度要求。

3.二、TCP數據段格式

　　TCP是一種可靠的、面向鏈接的字節流服務。源主機在傳送數據前須要先和目標主機創建鏈接。而後，在此鏈接上，被編號的數據段按序收發。同時，要求對每一個數據段進行確認，保證了可靠性。

　　若是在指定的時間內沒有收到目標主機對所發數據段的確認，源主機將再次發送該數據段。　　
　　　　

　　　　　　　　　　　　TCP頭部結構（RFC 79三、1323）

　　分析：

　　　　1）源、目標端口號字段：佔16比特。TCP協議經過使用"端口"來標識源端和目標端的應用進程。端口號可使用0到65535之間的任何數字。在收到服務請求時，操做系統動態地爲客戶端的應用程序分配端口號。

　　　　　　在服務器端，每種服務在"衆所周知的端口"（Well-Know Port）爲用戶提供服務。
　　　　2）順序號字段：佔32比特。用來標識從TCP源端向TCP目標端發送的數據字節流，它表示在這個報文段中的第一個數據字節。　　
　　　　3）確認號字段：佔32比特。只有ACK標誌爲1時，確認號字段纔有效。它包含目標端所指望收到源端的下一個數據字節。　　
　　　　4）頭部長度字段：佔4比特。給出頭部佔32比特的數目。沒有任何選項字段的TCP頭部長度爲20字節；最多能夠有60字節的TCP頭部。　　
　　　　5）標誌位字段（U、A、P、R、S、F）：佔6比特。各比特的含義以下：　　
　　　　　　URG：緊急指針（urgent pointer）有效。　　
　　　　　　ACK：確認序號有效。　　
　　　　　　PSH：接收方應該儘快將這個報文段交給應用層。　　
　　　　　　RST：重建鏈接。　　
　　　　　　SYN：發起一個鏈接。　　
　　　　　　FIN：釋放一個鏈接。　　
　　　　6）窗口大小字段：佔16比特。此字段用來進行流量控制。單位爲字節數，這個值是本機指望一次接收的字節數。　　
　　　　7）TCP校驗和字段：佔16比特。對整個TCP報文段，即TCP頭部和TCP數據進行校驗和計算，並由目標端進行驗證。　　
　　　　8）緊急指針字段：佔16比特。它是一個偏移量，和序號字段中的值相加表示緊急數據最後一個字節的序號。　　
　　　　9）選項字段：佔32比特。可能包括"窗口擴大因子"、"時間戳"等選項。

3.三、UDP數據段格式

　　UDP是一種不可靠的、無鏈接的數據報服務。源主機在傳送數據前不須要和目標主機創建鏈接。數據被冠以源、目標端口號等UDP報頭字段後直接發往目的主機。這時，每一個數據段的可靠性依靠上層協議來保證。在傳送數據較少、較小的狀況下，UDP比TCP更加高效。　　
　　　　

　　　　　　　　UDP頭部結構（RFC 79三、1323）

　　分析：
　　　　1）源、目標端口號字段：佔16比特。做用與TCP數據段中的端口號字段相同，用來標識源端和目標端的應用進程。　　
　　　　2）長度字段：佔16比特。標明UDP頭部和UDP數據的總長度字節。　　
　　　　3）校驗和字段：佔16比特。用來對UDP頭部和UDP數據進行校驗。和TCP不一樣的是，對UDP來講，此字段是可選項，而TCP數據段中的校驗和字段是必須有的。

3.四、套接字

　　在每一個TCP、UDP數據段中都包含源端口和目標端口字段。有時，咱們把一個IP地址和一個端口號合稱爲一個套接字（Socket），而一個套 接字對（Socket pair）能夠惟一地肯定互連網絡中每一個TCP鏈接的雙方（客戶IP地址、客戶端口號、服務器IP地址、服務器端口號）。
　　
　　　　
 　　　　　　　　　　常見協議和對應的服務端口號

　　注意：不一樣的應用層協議可能基於不一樣的傳輸層協議，如FTP、TELNET、SMTP協議基於可靠的TCP協議。TFTP、SNMP、RIP基於不可靠的UDP協議。　　
　　同時，有些應用層協議佔用了兩個不一樣的端口號，如FTP的20、21端口，SNMP的16一、162端口。這些應用層協議在不一樣的端口提供不一樣的功能。如FTP的21端口用來偵聽用戶的鏈接請求，而20端口用來傳送用戶的文件數據。

　　再如，SNMP的161端口用於SNMP管理進程獲取SNMP代理的數據，而162端口用於SNMP代理主動向SNMP管理進程發送數據。　　　　還有一些協議使用了傳輸層的不一樣協議提供的服務。如DNS協議同時使用了TCP 53端口和UDP 53端口。DNS協議在UDP的53端口提供域名解析服務，在TCP的53端口提供DNS區域文件傳輸服務。