TCP/IP參考模型
ISO制定的OSI參考模型的過于龐大、復雜招致了許多批評。與此對照，由技術人員自己開發(fā)的TCP/IP協(xié)議棧獲得了更為廣泛的應用。如圖2-1所示，是TCP/IP參考模型和OSI參考模型的對比示意圖。
圖2-1 TCP/IP參考模型
2.1 TCP/IP參考模型的層次結構
TCP/IP協(xié)議棧是美國國防部高級研究計劃局計算機網（Advanced Research Projects Agency Network，ARPANET）和其后繼因特網使用的參考模型。ARPANET是由美國國防部（U.S．Department of Defense，DoD）贊助的研究網絡。最初，它只連接了美國境內的四所大學。隨后的幾年中，它通過租用的電話線連接了數百所大學和政府部門。最終ARPANET發(fā)展成為全球規(guī)模最大的互連網絡-因特網。最初的ARPANET于1990年永久性地關閉。
TCP/IP參考模型分為四個層次：應用層、傳輸層、網絡互連層和主機到網絡層。如圖2-2所示。
圖2-2 TCP/IP參考模型的層次結構
在TCP/IP參考模型中，去掉了OSI參考模型中的會話層和表示層（這兩層的功能被合并到應用層實現）。同時將OSI參考模型中的數據鏈路層和物理層合并為主機到網絡層。下面，分別介紹各層的主要功能。
1、主機到網絡層 實際上TCP/IP參考模型沒有真正描述這一層的實現，只是要求能夠提供給其上層-網絡互連層一個訪問接口，以便在其上傳遞IP分組。由于這一層次未被定義，所以其具體的實現方法將隨著網絡類型的不同而不同。
2、網絡互連層 網絡互連層是整個TCP/IP協(xié)議棧的核心。它的功能是把分組發(fā)往目標網絡或主機。同時，為了盡快地發(fā)送分組，可能需要沿不同的路徑同時進行分組傳遞。因此，分組到達的順序和發(fā)送的順序可能不同，這就需要上層必須對分組進行排序?！ ?br> 網絡互連層定義了分組格式和協(xié)議，即IP協(xié)議（Internet Protocol）?！ ?br> 網絡互連層除了需要完成路由的功能外，也可以完成將不同類型的網絡（異構網）互連的任務。除此之外，網絡互連層還需要完成擁塞控制的功能?！ ?br>
3、傳輸層 在TCP/IP模型中，傳輸層的功能是使源端主機和目標端主機上的對等實體可以進行會話。在傳輸層定義了兩種服務質量不同的協(xié)議。即：傳輸控制協(xié)議TCP（transmission control protocol）和用戶數據報協(xié)議UDP（user datagram protocol）?！ ?br> TCP協(xié)議是一個面向連接的、可靠的協(xié)議。它將一臺主機發(fā)出的字節(jié)流無差錯地發(fā)往互聯網上的其他主機。在發(fā)送端，它負責把上層傳送下來的字節(jié)流分成報文段并傳遞給下層。在接收端，它負責把收到的報文進行重組后遞交給上層。TCP協(xié)議還要處理端到端的流量控制，以避免緩慢接收的接收方沒有足夠的緩沖區(qū)接收發(fā)送方發(fā)送的大量數據?！ ?br> UDP協(xié)議是一個不可靠的、無連接協(xié)議，主要適用于不需要對報文進行排序和流量控制的場合。
4、應用層 TCP/IP模型將OSI參考模型中的會話層和表示層的功能合并到應用層實現?！ ?br> 應用層面向不同的網絡應用引入了不同的應用層協(xié)議。其中，有基于TCP協(xié)議的，如文件傳輸協(xié)議（File Transfer Protocol，FTP）、虛擬終端協(xié)議（TELNET）、超文本鏈接協(xié)議（Hyper Text Transfer Protocol，HTTP），也有基于UDP協(xié)議的。
2.2 TCP/IP報文格式
1、IP報文格式
IP協(xié)議是TCP/IP協(xié)議族中最為核心的協(xié)議。它提供不可靠、無連接的服務，也即依賴其他層的協(xié)議進行差錯控制。在局域網環(huán)境，IP協(xié)議往往被封裝在以太網幀中傳送。而所有的TCP、UDP、ICMP、IGMP數據都被封裝在IP數據報中傳送。如圖2-3所示：
圖2-3 TCP/IP報文封裝
圖2-4是IP頭部（報頭）格式：（RFC 791）。
圖2-4 IP頭部格式
其中：
●版本（Version）字段：占4比特。用來表明IP協(xié)議實現的版本號，當前一般為IPv4，即0100?！ ?br> ●報頭長度（Internet Header Length，IHL）字段：占4比特。是頭部占32比特的數字，包括可選項。普通IP數據報（沒有任何選項），該字段的值是5，即160比特=20字節(jié)。此字段最大值為60字節(jié)?！ ?br> ●服務類型（Type of Service ，TOS）字段：占8比特。其中前3比特為優(yōu)先權子字段（Precedence，現已被忽略）。第8比特保留未用。第4至第7比特分別代表延遲、吞吐量、可靠性和花費。當它們取值為1時分別代表要求最小時延、最大吞吐量、最高可靠性和最小費用。這4比特的服務類型中只能置其中1比特為1?？梢匀珵?，若全為0則表示一般服務。服務類型字段聲明了數據報被網絡系統(tǒng)傳輸時可以被怎樣處理。例如：TELNET協(xié)議可能要求有最小的延遲，FTP協(xié)議（數據）可能要求有最大吞吐量，SNMP協(xié)議可能要求有最高可靠性，NNTP（Network News Transfer Protocol，網絡新聞傳輸協(xié)議）可能要求最小費用，而ICMP協(xié)議可能無特殊要求（4比特全為0）。實際上，大部分主機會忽略這個字段，但一些動態(tài)路由協(xié)議如OSPF（Open Shortest Path First Protocol）、IS-IS（Intermediate System to Intermediate System Protocol）可以根據這些字段的值進行路由決策。
●總長度字段：占16比特。指明整個數據報的長度（以字節(jié)為單位）。最大長度為65535字節(jié)?！ ?br> ●標志字段：占16比特。用來唯一地標識主機發(fā)送的每一份數據報。通常每發(fā)一份報文，它的值會加1?！ ?br> ●標志位字段：占3比特。標志一份數據報是否要求分段。
●段偏移字段：占13比特。如果一份數據報要求分段的話，此字段指明該段偏移距原始數據報開始的位置。
●生存期（TTL：Time to Live）字段：占8比特。用來設置數據報最多可以經過的路由器數。由發(fā)送數據的源主機設置，通常為32、64、128等。每經過一個路由器，其值減1，直到0時該數據報被丟棄。
●協(xié)議字段：占8比特。指明IP層所封裝的上層協(xié)議類型，如ICMP（1）、IGMP（2） 、TCP（6）、UDP（17）等?！ ?br> ●頭部校驗和字段：占16比特。內容是根據IP頭部計算得到的校驗和碼。計算方法是：對頭部中每個16比特進行二進制反碼求和。（和ICMP、IGMP、TCP、UDP不同，IP不對頭部后的數據進行校驗）?！ ?br> ●源IP地址、目標IP地址字段：各占32比特。用來標明發(fā)送IP數據報文的源主機地址和接收IP報文的目標主機地址?！ ?br> 可選項字段：占32比特。用來定義一些任選項：如記錄路徑、時間戳等。這些選項很少被使用，同時并不是所有主機和路由器都支持這些選項?？蛇x項字段的長度必須是32比特的整數倍，如果不足，必須填充0以達到此長度要求。
2、TCP數據段格式
TCP是一種可靠的、面向連接的字節(jié)流服務。源主機在傳送數據前需要先和目標主機建立連接。然后，在此連接上，被編號的數據段按序收發(fā)。同時，要求對每個數據段進行確認，保證了可靠性。如果在指定的時間內沒有收到目標主機對所發(fā)數據段的確認，源主機將再次發(fā)送該數據段?！ ?br> 如圖2-5所示，是TCP頭部結構（RFC 793、1323）。
圖2-5 TCP頭部結構
●源、目標端口號字段：占16比特。TCP協(xié)議通過使用"端口"來標識源端和目標端的應用進程。端口號可以使用0到65535之間的任何數字。在收到服務請求時，操作系統(tǒng)動態(tài)地為客戶端的應用程序分配端口號。在服務器端，每種服務在"眾所周知的端口"（Well-Know Port）為用戶提供服務。
●順序號字段：占32比特。用來標識從TCP源端向TCP目標端發(fā)送的數據字節(jié)流，它表示在這個報文段中的第一個數據字節(jié)?！ ?br> ●確認號字段：占32比特。只有ACK標志為1時，確認號字段才有效。它包含目標端所期望收到源端的下一個數據字節(jié)?！ ?br> ●頭部長度字段：占4比特。給出頭部占32比特的數目。沒有任何選項字段的TCP頭部長度為20字節(jié)；最多可以有60字節(jié)的TCP頭部?！ ?br> ●標志位字段（U、A、P、R、S、F）：占6比特。各比特的含義如下：
◆URG：緊急指針（urgent pointer）有效。
◆ACK：確認序號有效?！ ?br> ◆PSH：接收方應該盡快將這個報文段交給應用層?！ ?br> ◆RST：重建連接?！ ?br> ◆SYN：發(fā)起一個連接?！ ?br> ◆FIN：釋放一個連接?！ ?br> ●窗口大小字段：占16比特。此字段用來進行流量控制。單位為字節(jié)數，這個值是本機期望一次接收的字節(jié)數?！ ?br> ●TCP校驗和字段：占16比特。對整個TCP報文段，即TCP頭部和TCP數據進行校驗和計算，并由目標端進行驗證。
●緊急指針字段：占16比特。它是一個偏移量，和序號字段中的值相加表示緊急數據最后一個字節(jié)的序號。
●選項字段：占32比特?？赡馨?窗口擴大因子"、"時間戳"等選項。
3、UDP數據段格式
UDP是一種不可靠的、無連接的數據報服務。源主機在傳送數據前不需要和目標主機建立連接。數據被冠以源、目標端口號等UDP報頭字段后直接發(fā)往目的主機。這時，每個數據段的可靠性依靠上層協(xié)議來保證。在傳送數據較少、較小的情況下，UDP比TCP更加高效。
如圖2-6所示，是UDP頭部結構（RFC 793、1323）：
●源、目標端口號字段：占16比特。作用與TCP數據段中的端口號字段相同，用來標識源端和目標端的應用進程?！ ?br> ●長度字段：占16比特。標明UDP頭部和UDP數據的總長度字節(jié)?！ ?br> ●校驗和字段：占16比特。用來對UDP頭部和UDP數據進行校驗。和TCP不同的是，對UDP來說，此字段是可選項，而TCP數據段中的校驗和字段是必須有的。
2.3 套接字
在每個TCP、UDP數據段中都包含源端口和目標端口字段。有時，我們把一個IP地址和一個端口號合稱為一個套接字（Socket），而一個套接字對（Socket pair）可以唯一地確定互連網絡中每個TCP連接的雙方（客戶IP地址、客戶端口號、服務器IP地址、服務器端口號）。
如圖2-7所示，是常見的一些協(xié)議和它們對應的服務端口號。
圖2-7 常見協(xié)議和對應的端口號
需要注意的是，不同的應用層協(xié)議可能基于不同的傳輸層協(xié)議，如FTP、TELNET、SMTP協(xié)議基于可靠的TCP協(xié)議。TFTP、SNMP、RIP基于不可靠的UDP協(xié)議?！ ?br> 同時，有些應用層協(xié)議占用了兩個不同的端口號，如FTP的20、21端口，SNMP的161、162端口。這些應用層協(xié)議在不同的端口提供不同的功能。如FTP的21端口用來偵聽用戶的連接請求，而20端口用來傳送用戶的文件數據。再如，SNMP的161端口用于SNMP管理進程獲取SNMP代理的數據，而162端口用于SNMP代理主動向SNMP管理進程發(fā)送數據?！ ?br> 還有一些協(xié)議使用了傳輸層的不同協(xié)議提供的服務。如DNS協(xié)議同時使用了TCP 53端口和UDP 53端口。DNS協(xié)議在UDP的53端口提供域名解析服務，在TCP的53端口提供DNS區(qū)域文件傳輸服務。
2.4 TCP連接建立、釋放時的握手過程
1、TCP建立連接的三次握手過程
TCP會話通過三次握手來初始化。三次握手的目標是使數據段的發(fā)送和接收同步。同時也向其他主機表明其一次可接收的數據量（窗口大?。?，并建立邏輯連接。這三次握手的過程可以簡述如下：
●源主機發(fā)送一個同步標志位（SYN）置1的TCP數據段。此段中同時標明初始序號（Initial Sequence Number，ISN）。ISN是一個隨時間變化的隨機值?！ ?br> ●目標主機發(fā)回確認數據段，此段中的同步標志位（SYN）同樣被置1，且確認標志位（ACK）也置1，同時在確認序號字段表明目標主機期待收到源主機下一個數據段的序號（即表明前一個數據段已收到并且沒有錯誤）。此外，此段中還包含目標主機的段初始序號?！ ?br> ●源主機再回送一個數據段，同樣帶有遞增的發(fā)送序號和確認序號?！ ?br> 至此為止，TCP會話的三次握手完成。接下來，源主機和目標主機可以互相收發(fā)數據。整個過程可用圖2-8表示。
2、TCP釋放連接的四次握手過程
