OSI與TCP IP模型二(圖)

2019-11-04 20:44:32

字體：大中小

供稿：網(wǎng)友

　　2.2　TCP/ip報文格式
　　
　　1、IP報文格式
　　
　　IP協(xié)議是TCP/IP協(xié)議族中最為核心的協(xié)議。它提供不可靠、無連接的服務(wù)，也即依靠其他層的協(xié)議進行差錯控制。在局域網(wǎng)環(huán)境，IP協(xié)議往往被封裝在以太網(wǎng)幀（見本章1.3節(jié)）中傳送。而所有的TCP、UDP、ICMP、IGMP數(shù)據(jù)都被封裝在IP數(shù)據(jù)報中傳送。如圖2-3所示：
　　　 OSI與TCP IP模型二(圖)（圖一）

　　圖2-3　 TCP/IP報文封裝
　　
　　圖2-4是IP頭部（報頭）格式：（RFC 791）。
　　　 OSI與TCP IP模型二(圖)（圖二）

　　圖2-4　 IP頭部格式
　　
　　其中：
　　
　　●版本（Version）字段：占4比特。用來表明IP協(xié)議實現(xiàn)的版本號，當(dāng)前一般為IPv4，即0100。
　　
　　●報頭長度（Internet Header Length，IHL）字段：占4比特。是頭部占32比特的數(shù)字，包括可選項。普通IP數(shù)據(jù)報（沒有任何選項），該字段的值是5，即160比特=20字節(jié)。此字段最大值為60字節(jié)。
　　
　　●服務(wù)類型（Type of Service ，TOS）字段：占8比特。其中前3比特為優(yōu)先權(quán)子字段（PRecedence，現(xiàn)已被忽略）。第8比特保留未用。第4至第7比特分別代表延遲、吞吐量、可靠性和花費。當(dāng)它們?nèi)≈禐?時分別代表要求最小時延、最大吞吐量、最高可靠性和最小費用。這4比特的服務(wù)類型中只能置其中1比特為1。可以全為0，若全為0則表示一般服務(wù)。服務(wù)類型字段聲明了數(shù)據(jù)報被網(wǎng)絡(luò)系統(tǒng)傳輸時可以被怎樣處理。例如：TELNET協(xié)議可能要求有最小的延遲，F(xiàn)TP協(xié)議（數(shù)據(jù)）可能要求有最大吞吐量，SNMP協(xié)議可能要求有最高可靠性，NNTP（Network News Transfer Protocol，網(wǎng)絡(luò)新聞傳輸協(xié)議）可能要求最小費用，而ICMP協(xié)議可能無非凡要求（4比特全為0）。實際上，大部分主機會忽略這個字段，但一些動態(tài)路由協(xié)議如OSPF（Open Shortest Path First Protocol）、IS-IS（Intermediate System to Intermediate System Protocol）可以根據(jù)這些字段的值進行路由決策。
　　
　　●總長度字段：占16比特。指明整個數(shù)據(jù)報的長度（以字節(jié)為單位）。最大長度為65535字節(jié)。
　　
　　●標(biāo)志字段：占16比特。用來唯一地標(biāo)識主機發(fā)送的每一份數(shù)據(jù)報。通常每發(fā)一份報文，它的值會加1。
　　
　　●標(biāo)志位字段：占3比特。標(biāo)志一份數(shù)據(jù)報是否要求分段。
　　
　　●段偏移字段：占13比特。假如一份數(shù)據(jù)報要求分段的話，此字段指明該段偏移距原始數(shù)據(jù)報開始的位置。
　　
　　●生存期（TTL：Time to Live）字段：占8比特。用來設(shè)置數(shù)據(jù)報最多可以經(jīng)過的路由器數(shù)。由發(fā)送數(shù)據(jù)的源主機設(shè)置，通常為32、64、128等。每經(jīng)過一個路由器，其值減1，直到0時該數(shù)據(jù)報被丟棄。
　　
　　●協(xié)議字段：占8比特。指明IP層所封裝的上層協(xié)議類型，如ICMP（1）、IGMP（2）、TCP（6）、UDP（17）等。
　　
　　●頭部校驗和字段：占16比特。內(nèi)容是根據(jù)IP頭部計算得到的校驗和碼。計算方法是：對頭部中每個16比特進行二進制反碼求和。（和ICMP、IGMP、TCP、UDP不同，IP不對頭部后的數(shù)據(jù)進行校驗）。
　　
　　●源IP地址、目標(biāo)IP地址字段：各占32比特。用來標(biāo)明發(fā)送IP數(shù)據(jù)報文的源主機地址和接收IP報文的目標(biāo)主機地址。
　　
　　可選項字段：占32比特。用來定義一些任選項：如記錄路徑、時間戳等。這些選項很少被使用，同時并不是所有主機和路由器都支持這些選項。可選項字段的長度必須是32比特的整數(shù)倍，假如不足，必須填充0以達(dá)到此長度要求。
　　
　　2、TCP數(shù)據(jù)段格式
　　
　　TCP是一種可靠的、面向連接的字節(jié)流服務(wù)。源主機在傳送數(shù)據(jù)前需要先和目標(biāo)主機建立連接。然后，在此連接上，被編號的數(shù)據(jù)段按序收發(fā)。同時，要求對每個數(shù)據(jù)段進行確認(rèn)，保證了可靠性。假如在指定的時間內(nèi)沒有收到目標(biāo)主機對所發(fā)數(shù)據(jù)段的確認(rèn)，源主機將再次發(fā)送該數(shù)據(jù)段。
　　
　　如圖2-5所示，是TCP頭部結(jié)構(gòu)（RFC 793、1323）。
　　　 OSI與TCP IP模型二(圖)（圖三）

　　圖2-5　 TCP頭部結(jié)構(gòu)
　　
　　●源、目標(biāo)端口號字段：占16比特。TCP協(xié)議通過使用"端口"來標(biāo)識源端和目標(biāo)端的應(yīng)用進程。端口號可以使用0到65535之間的任何數(shù)字。在收到服務(wù)請求時，操作系統(tǒng)動態(tài)地為客戶端的應(yīng)用程序分配端口號。在服務(wù)器端，每種服務(wù)在"眾所周知的端口"（Well-Know Port）為用戶提供服務(wù)。
　　
　　●順序號字段：占32比特。用來標(biāo)識從TCP源端向TCP目標(biāo)端發(fā)送的數(shù)據(jù)字節(jié)流，它表示在這個報文段中的第一個數(shù)據(jù)字節(jié)。
　　
　　●確認(rèn)號字段：占32比特。只有ACK標(biāo)志為1時，確認(rèn)號字段才有效。它包含目標(biāo)端所期望收到源端的下一個數(shù)據(jù)字節(jié)。
　　
　　●頭部長度字段：占4比特。給出頭部占32比特的數(shù)目。沒有任何選項字段的TCP頭部長度為20字節(jié)；最多可以有60字節(jié)的TCP頭部。
　　
　　●標(biāo)志位字段（U、A、P、R、S、F）：占6比特。各比特的含義如下：
　　
　　◆URG：緊急指針（urgent pointer）有效。
　　
　　◆ACK：確認(rèn)序號有效。
　　
　　◆PSH：接收方應(yīng)該盡快將這個報文段交給應(yīng)用層。
　　
　　◆RST：重建連接。
　　
　　◆SYN：發(fā)起一個連接。
　　
　　◆FIN：釋放一個連接。
　　
　　●窗口大小字段：占16比特。此字段用來進行流量控制。單位為字節(jié)數(shù)，這個值是本機期望一次接收的字節(jié)數(shù)。
　　
　　●TCP校驗和字段：占16比特。對整個TCP報文段，即TCP頭部和TCP數(shù)據(jù)進行校驗和計算，并由目標(biāo)端進行驗證。
　　
　　●緊急指針字段：占16比特。它是一個偏移量，和序號字段中的值相加表示緊急數(shù)據(jù)最后一個字節(jié)的序號。
　　
　　●選項字段：占32比特。可能包括"窗口擴大因子"、"時間戳"等選項。
　　
　　3、UDP數(shù)據(jù)段格式
　　
　　UDP是一種不可靠的、無連接的數(shù)據(jù)報服務(wù)。源主機在傳送數(shù)據(jù)前不需要和目標(biāo)主機建立連接。數(shù)據(jù)被冠以源、目標(biāo)端口號等UDP報頭字段后直接發(fā)往目的主機。這時，每個數(shù)據(jù)段的可靠性依靠上層協(xié)議來保證。在傳送數(shù)據(jù)較少、較小的情況下，UDP比TCP更加高效。
　　
　　如圖2-6所示，是UDP頭部結(jié)構(gòu)（RFC 793、1323）：
　　　 OSI與TCP IP模型二(圖)（圖四）

　　圖2-6　 UDP數(shù)據(jù)段格式
　　
　　●源、目標(biāo)端口號字段：占16比特。作用與TCP數(shù)據(jù)段中的端口號字段相同，用來標(biāo)識源端和目標(biāo)端的應(yīng)用進程。
　　
　　●長度字段：占16比特。標(biāo)明UDP頭部和UDP數(shù)據(jù)的總長度字節(jié)。
　　
　　●校驗和字段：占16比特。用來對UDP頭部和UDP數(shù)據(jù)進行校驗。和TCP不同的是，對UDP來說，此字段是可選項，而TCP數(shù)據(jù)段中的校驗和字段是必須有的。
　　
　　2.3　套接字
　　
　　在每個TCP、UDP數(shù)據(jù)段中都包含源端口和目標(biāo)端口字段。有時，我們把一個IP地址和一個端口號合稱為一個套接字（Socket），而一個套接字對（Socket pair）可以唯一地確定互連網(wǎng)絡(luò)中每個TCP連接的雙方（客戶IP地址、客戶端口號、服務(wù)器IP地址、服務(wù)器端口號）。
　　
　　如圖2-7所示，是常見的一些協(xié)議和它們對應(yīng)的服務(wù)端口號。
　　　 OSI與TCP IP模型二(圖)（圖五）

　　圖2-7　常見協(xié)議和對應(yīng)的端口號
　　
　　需要注重的是，不同的應(yīng)用層協(xié)議可能基于不同的傳輸層協(xié)議，如FTP、TELNET、SMTP協(xié)議基于可靠的TCP協(xié)議。TFTP、SNMP、RIP基于不可靠的UDP協(xié)議。
　　
　　同時，有些應(yīng)用層協(xié)議占用了兩個不同的端口號，如FTP的20、21端口，SNMP的161、162端口。這些應(yīng)用層協(xié)議在不同的端口提供不同的功能。如FTP的21端口用來偵聽用戶的連接請求，而20端口用來傳送用戶的文件數(shù)據(jù)。再如，SNMP的161端口用于SNMP治理進程獲取SNMP代理的數(shù)據(jù)，而162端口用于SNMP代理主動向SNMP治理進程發(fā)送數(shù)據(jù)。
　　
　　還有一些協(xié)議使用了傳輸層的不同協(xié)議提供的服務(wù)。如DNS協(xié)議同時使用了TCP 53端口和UDP 53端口。DNS協(xié)議在UDP的53端口提供域名解析服務(wù)，在TCP的53端口提供DNS區(qū)域文件傳輸服務(wù)。
　　
　　2.4　TCP連接建立、釋放時的握手過程
　　
　　1、TCP建立連接的三次握手過程
　　
　　TCP會話通過三次握手來初始化。三次握手的目標(biāo)是使數(shù)據(jù)段的發(fā)送和接收同步。同時也向其他主機表明其一次可接收的數(shù)據(jù)量（窗口大小），并建立邏輯連接。這三次握手的過程可以簡述如下：
　　
　　●源主機發(fā)送一個同步標(biāo)志位（SYN）置1的TCP數(shù)據(jù)段。此段中同時標(biāo)明初始序號（Initial Sequence Number，ISN）。ISN是一個隨時間變化的隨機值。
　　
　　●目標(biāo)主機發(fā)回確認(rèn)數(shù)據(jù)段，此段中的同步標(biāo)志位（SYN）同樣被置1，且確認(rèn)標(biāo)志位（ACK）也置1，同時在確認(rèn)序號字段表明目標(biāo)主機期待收到源主機下一個數(shù)據(jù)段的序號（即表明前一個數(shù)據(jù)段已收到并且沒有錯誤）。此外，此段中還包含目標(biāo)主機的段初始序號。
　　
　　●源主機再回送一個數(shù)據(jù)段，同樣帶有遞增的發(fā)送序號和確認(rèn)序號。
　　
　　至此為止，TCP會話的三次握手完成。接下來，源主機和目標(biāo)主機可以互相收發(fā)數(shù)據(jù)。整個過程可用圖2-8表示。
　　　 OSI與TCP IP模型二(圖)（圖六）