OSI參考模型及TCP/IP參考模型
OSI模型（open system interconnection reference model）是基于國際標準化組織（ISO）的建議而發展起來的，它分為如圖3-1所示的七層。當衛星和無線網絡出現以后，現有的協議在和這些網絡互聯時出現了問題，所以需要一種新的參考體系結構，能無縫地連接多個網絡。這個體系結構就是TCP/IP參考模型。
TCP 協議
因特網在傳輸層有兩種主要的協議：一種是面向連接的協議，一種是無連接的協議。傳輸控制協議TCP是(transmission control PRotocol)專門用于在不可靠的因特網上提供可靠的、端對端的字節流通信的協議。通過在發送方和接收方分別創建一個稱為套接字的通信端口就可以獲得TCP服務。所有的TCP 連接均是全雙工的和點到點的。
發送和接收方TCP實體以數據報的形式交換數據。一個數據報包含一個固定的20字節的頭、一個可選部分以及0或多字節的數據。對數據報的大小有兩個限制條件：首先，每個數據報（包括TCP頭在內）必須適合IP的載荷能力，不能超過65535字節；其次，每個網絡都存在最大傳輸單元MTU（maximum transfer unit），要求每個數據報必須適合MTU。假如一個數據報進入了一個MTU小于該數據報長度的網絡，那么處于網絡邊界上的路由器會把該數據報分解為多個小的數據報。
TCP實體所采用的基本協議是滑動窗口協議。當發送方傳送一個數據報時，它將啟動計時器。當該數據報到達目的地后，接收方的TCP實體向回發送一個數據報，其中包含有一個確認序號，它等于希望收到的下一個數據報的順序號。假如發送方的定時器在確認信息到達之前超時，那么發送方會重發該數據報。
2.1 TCP數據報頭
圖2給出了TCP數據報頭的格式。
源端口、目的端口：16位長。標識出遠端和本地的端口號。
順序號：32位長。表明了發送的數據報的順序。
確認號：32位長。希望收到的下一個數據報的序列號。
TCP頭長：4位長。表明TCP頭中包含多少個32位字。
接下來的6位未用。
ACK：ACK位置1表明確認號是合法的。假如ACK為0，那么數據報不包含確認信息，確認字段被省略。
PSH：表示是帶有PUSH標志的數據。接收方因此請求數據報一到便可送往應用程序而不必等到緩沖區裝滿時才傳送。
RST：用于復位由于主機崩潰或其它原因而出現的錯誤的連接。還可以用于拒絕非法的數據報或拒絕連接請求。
SYN：用于建立連接。
FIN：用于釋放連接。
窗口大小：16位長。窗口大小字段表示在確認了字節之后還可以發送多少個字節。
校驗和：16位長。是為了確保高可靠性而設置的。它校驗頭部、數據和偽TCP頭部之和。
可選項：0個或多個32位字。包括最大TCP載荷，窗口比例、選擇重發數據報等選項。
2.2 連接治理
在TCP中建立連接采用三次握手的方法。為了建立連接，其中一方，如服務器，通過執行LISTEN和ACCEPT原語被動地等待一個到達的連接請求。
另一方，如客戶方，執行CONNECT原語，同時要指明它想連接到的IP地址和端口號，設置它能夠接受的TCP數據報的最大值，以及一些可選的用戶數據。CONNECT原語發送一個SYN=1，ACK=0的數據報到目的端，并等待對方響應。
該數據報到達目的端后，那里的TCP實體將察看是否有進程在偵聽目的端口字段指定的端口。假如沒有，它將發送一個RST=1的應答，拒絕建立該連接。
假如某個進程正在對該端口進行偵聽，于是便將到達的TCP數據報交給該進程，它可以接受或拒絕建立連接。假如接受，便發回一個確認數據報。一般情況下，TCP的連接建立過程如圖3所示。
為了釋放連接，每方均可發送一個FIN=1的TCP數據報，表明本方已無數據發送。當FIN數據報被確認后，那個方向的連接即告關閉。當兩個方向上的連接均關閉后，該連接就被完全釋放了。一般情況下，釋放一個連接需要4個TCP數據報：每個方向均有一個FIN數據報和一個ACK數據報。
2.3 傳輸策略
TCP中采用滑動窗口來進行傳輸控制，滑動窗口的大小意味著接收方還有多大的緩沖區可以用于接收數據。發送方可以通過滑動窗口的大小來確定應該發送多少字節的數據。當滑動窗口為0時，發送方一般不能再發送數據報，但有兩種情況除外，一種情況是可以發送緊急數據，例如，答應用戶終止在遠端機上的運行進程。另一種情況是發送方可以發送一個1字節的數據報來通知接收方重新聲明它希望接收的下一字節及發送方的滑動窗口大小。
2.4 擁塞控制
當加載到某個網絡上的載荷能力超過其處理能力時，便會出現擁塞現象。對于因特網來說有兩個潛在的問題--網絡的容量和接收方的容量，應該分別進行處理。發送方始終保持兩個窗口：接收方承認的窗口和擁塞窗口。取兩個窗口的最小值作為可以發送的字節數。
當建立連接時，發送方將擁塞窗口大小初始化為該連接所用的最大數據報的長度值，并隨后發送一個最大長度的數據報。假如該數據報在定時器超時之前得到了確認，那么發送方會在原擁塞窗口的基礎上再增加一個數據報的字節值，使其為兩倍最大數據報的大小，然后發送兩個數據報。當這些數據報中的每一個都被確認后，擁塞窗口大小就再增加一個最大數據報的長度。當擁塞窗口是N個數據報的大小時，假如發送的所有N個數據報都被及時確認，那么將擁塞窗口大小增加N個數據報對應的字節數目。擁塞窗口保持指數規律增大，直到數據傳輸超時或者達到接收方設定的窗口大小。擁塞窗口便設置為恰好不造成超時或達到接收方的窗口大小的字節數。
2.5 定時器治理
TCP使用多個定時器，如重發定時器、持續定時器、"keep alive"定時器等。最重要的是重發定時器。在發送一個數據報的同時，啟動一個數據重發定時器。假如在定時器超時前該數據報被確認，則關閉該定時器；相反，假如在確認到達之前定時器超時，則需要重發該數據報。
持續定時器用于防止出現死鎖情況。當一個連接長時間閑置時，"keep alive"定時器會超時而使一方去檢測另一方是否仍然存在。假如它未得到響應，便終止該連接。
UDP協議
因特網協議組也支持無連接的傳輸協議UDP（user data protocol）。 UDP使用底層的因特網協議來傳送報文，提供與IP一樣的不可靠的、無連接的數據報傳輸服務。它不使用確認信息對報文的到達進行確認，不對收到的數據報進行排序，也不提供反饋信息來控制機器之間傳輸的信息流量。UDP通信的可靠性方面的工作，包括報文的丟失、重復、亂序等現象，由使用UDP的應用程序來承擔。
一個UDP數據報包括一個8字節的頭和數據部分。報頭的格式如下圖4所示，它包括四個長為16字節的字段。源端口和目的端口的作用與TCP中的相同，是用來標明源端和目的端的端口號。UDP長度字段指明包括8個字節的頭和數據在內的數據報長度。UDP校驗和字段是可選項，用于紀錄 UDP頭、UDP偽頭、用戶數據三者的校驗和。
IP協議
IP協議提供了不可靠的、無連接的數據報傳輸機制。TCP/IP是為了適應物理網絡的多樣性而設計的，而這種適應性主要是通過IP層來體現的。由于物理網絡的多樣性，各種物理網絡的數據幀格式、地址格式之間的差異很大。為了將這些底層的細節屏蔽起來，使得采用不同物理網絡的網絡之間進行通訊， TCP/IP分別采用了IP數據報和IP地址作為物理數據幀與物理地址的統一描述形式。這樣IP向上層提供統一的IP數據報和統一的IP地址，使得各種物理幀及物理地址的差異性對上層協議不復存在。
4.1 IP數據報頭
一個IP數據報由一個頭部和數據部分構成。頭部包括一個20字節的固定長度部分和一個可選任意長度部分。頭部格式如圖5所示。
版本：4位長。記錄了數據報對應的協議版本號。當前的IP協議有兩個版本：IPV4 和IPV6。
IHL：4位長。代表頭部的總長度，以32位字節為一個單位。
服務類型：8位長。使主機可以告訴子網它想要什么樣的服務。如下圖所示，服務類型域又分為了5個部分。優先權字段是標志優先級的；三個標志位分別代表延遲、吞吐量、可靠性。
總長：16位。指頭部和數據的總長。最大長度是65535個字節。
標識：16位。通過它使目的主機判定新來的分段屬于哪個分組，所有屬于同一分組的分段包含同樣的標識值。
DF：代表不要分段。它命令路由器不要將數據報分段，因為目的端不能重組分段。
MF：代表還有進一步的分段，用它來標志是否所有的分組都已到達。除了最后一個分段的所有分段都設置了這一位。
分段偏移：13位。標明分段在當前數據報的什么位置。
生命期：8位。用來限制分組生命周期的計數器。它在每個節點中都遞減，而且當在一個路由器中排隊時可以倍數遞減。
協議：8位。說明將分組發送給那個傳輸進程，如TCR、VDP等。
頭校驗和：16位。僅用來校驗頭部。
源地址： 32位。產生IP數據報的源主機IP地址。
目的地址：32位。IP數據報的目的主機的IP地址。
可選項：是變長的。每個可選項用一個字節標明內容。有些可選項還跟有一字節的可選項長度字段，其后是一個或多個數據字節。現在已定義了安全性、嚴格的源路由選擇、松的源路由選擇、記錄路由和時間標記五個可選項。但不是所有的路由器都支持全部5個可選項。
安全性選項說明了信息的安全程度。
嚴格的源路由選擇選項以一系列的IP地址方式，給出了從源到目的地的完整路徑。數據報必須嚴格地從這條路徑傳送。當路由選擇表崩潰，系統治理員發送緊急分組時，或作時間測量時，此字段很有用。
松的源路由選擇選項要求分組遍及所列的路由器，但它可以在其間穿過其它的路由器。
記錄路由選項讓沿途的路由器都將其IP地址加到可選字段之后，這使系統治理者可以跟蹤路由選擇算法的錯誤。
時間標記選項像記錄路由選項一樣，除了記錄32位的IP地址外，每個路由器還要記錄一個32位的時間標記。同樣地，這一選擇可用來為路由選擇算法查錯。
4.2 IP數據報的分段與重組
IP數據報是通過封裝為物理幀來傳輸的。由于因特網是通過各種不同物理網絡技術互連起來的，在因特網的不同部分，物理幀的大小（最大傳輸單元MTU）可能各不相同。為了最大程度的利用物理網絡的能力，IP模塊以所在的物理網絡的MTU做為依據，來確定IP數據報的大小。當IP數據報在兩個不同MTU的網絡之間傳輸時，就可能出現IP數據報的分段與重組操作。
在IP頭中控制分段和重組的IP頭域有三個：標識域、標志域、分段偏移域。標識是源主機賦予IP數據報的標識符。目的主機根據標識域來判定收到的IP數據報分段屬于哪一個數據報，以進行IP數據報重組。標志域中的DF位標識該IP數據報是否答應分段。當需要對IP數據報進行分段時，假如DF位置1，網關將會拋棄該IP數據報，并向源主機發送出錯信息。標志域中的MF位標識該IP數據報分段是否是最后一個分段。分段偏移域記錄了該IP數據報分段在原IP數據報中的偏移量。偏移量是8字節的整數倍。分段偏移域被用來確定該IP數據報分段在IP數據報重組時的順序。
IP數據報在被傳輸過程中，一旦被分段，各段就作為獨立的IP數據報進行傳輸，在到達目的主機之前有可能會被再次或多次分段。但是IP數據報分段的重組都只在目的主機進行。
4.3 IP對輸入數據報的處理
IP對輸入數據報的處理分為兩種，一種是主機對數據報的處理，一種是網關對數據報的處理。
當IP數據報到達主機時，假如IP數據報的目的地址與主機地址匹配，IP接收該數據報并將它傳給高級協議軟件處理；否則拋棄該IP數據報。
網關則不同，當IP數據報到達網關IP層后，網關首先判定本機是否是數據報到達的目的主機。假如是，網關將接收到的IP數據報上傳給高級協議軟件處理。假如不是，網關將對接收到的IP數據報進行尋徑，并隨后將其轉發出去。
4.4 IP對輸出數據報的處理
IP對輸出數據報的處理也分為兩種，一種是主機對數據報的處理，一種是網關對數據報的處理。
對于網關來說，IP接收到IP數據報后，經過尋徑，找到該IP數據報的傳輸路徑。該路徑實際上是全路徑中的下一個網關的IP地址。然后，該網關將該IP數據報和尋徑到的下一個網關的地址交給網絡接口軟件。網絡接口軟件收到IP數據報和下一個網關地址后，首先調用ARP完成下一個網關IP地址到物理地址的映射，然后將IP數據報封裝成幀，最后由子網完成數據報的物理傳輸。
ICMP協議
ICMP(Internet Control Message Protocol)-因特網控制報文協議。ICMP主要用于差錯信息和控制信息的構造及某些網絡信息的獲取。ICMP與IP 同屬IP層，但ICMP報文是經IP封裝后，作為IP數據報發送出去的。不把ICMP作為一個獨立的協議層次，是因為ICMP不是上層協議的基礎，在概念上構不成一個獨立的層次。
ICMP消息包括以下類型：目的不可達、超時、參數問題、源端抑制、重定向、回聲請求、回聲應答、時間標記請求、時間標記應答。
目的不可達消息用來報告子網或路由器不能定位目的地，或設置了DF位的分組不能繞過"小分組"網絡。
超時消息用來報告報文由于計時器為零而被丟棄。
參數問題消息表明在頭部字段中發現了非法值。
源端抑制消息用來抑制發送過多分組的主機。當主機收到這個消息，就要減慢發送速度。
重定向消息在路由器發現可能出現了路由錯誤時發送。
回聲請求和回聲應答消息用來測試目的是否可達且正常運行。收到回聲請求消息，目的端應該往回發一個回聲應答消息。時間標記請求和時間標記應答與此類似，只是消息到達時間和應答發出時間應加入應答中，其好處是可以用來測試網絡性能。
更多的請看：http://www.QQread.com/windows/2003/index.html
IP在Linux上的實現
如圖6所示，Linux以分層的軟件結構實現了TCP/IP協議。BSD套接字由一般性的套接字治理軟件INET套接字層支持。INET套接字治理著基于IP的TCP或UDP協議端。在傳輸UDP數據報時，Linux不必關心數據報是否安全到達目的端。但對TCP數據報來說，Linux需要對數據報進行編號，數據報的源端和目的端需要協調工作，以便保證數據報不會丟失，或以錯誤的順序發送。IP層包含的代碼需要處理數據報的報頭信息，并且必須將傳入的數據報發送到TCP或 UDP兩者中正確的一層處理。在IP層之下是Linux的網絡設備層，其中包括以太網設備或PPP設備等。和Linux系統中的其它設備不同，網絡設備并不總代表實際的物理設備，例如，回環設備就是一個純軟件設備。ARP協議提供地址解析功能，因此它處于IP層和網絡設備層之間。
6.1 套接字緩沖區
Linux利用套接字緩沖區在協議層和網絡設備之間傳送數據。Sk_buff包含了一些指針和長度信息，從而可讓協議層以標準的函數或方法對應用程序的數據進行處理。如圖7所示，每個sk_buff均包含一個數據塊、四個數據指針以及兩個長度字段。利用四個數據指針，各協議層可操縱和治理套接字緩沖區的數據，這四個指針的用途如下。
Head：指向內存中數據區的起始地址。Sk_buff和相關數據塊在分配之后，該指針的值是固定的。
Data：指向協議數據的當前起始地址。該指針的值隨當前擁有Sk_buff的協議層的變化而變化。
Tail：指向協議數據的當前結尾地址。和data指針一樣，該指針的值也隨當前擁有Sk_buff的協議層的變化而變化。
End：指向內存中數據區的結尾。和head指針一樣，Sk_buff被分配之后，該指針的值也固定不變。
Sk_buff的兩個長度字段，len和truesize，分別描述當前協議數據報的長度和數據緩沖區的實際長度。
6.2 接收IP數據報
當網絡設備從網絡上接收到數據報時，它必須將接收到的數據轉換為sk_buff數據結構，然后將該結構添加到backlog隊列中排隊。當backlog隊列變得很大時，接收到的sk_buff數據將會被丟棄。當新的sk_buff添加到backlog隊列時，網絡底層程序將被標志為就緒狀態，從而可以讓調度程序調度底層程序進行處理。
調度程序最終會運行網絡的底層處理程序。這時，網絡底層處理程序將處理任何等待傳輸的數據報，但在這之前，底層處理程序首先會處理sk_buff結構的backlog隊列。底層處理程序必須確定將接收到的數據報傳遞到哪個協議層。
在Linux進行網絡層的初始化時，每個協議要在ptype_all鏈表或ptype_base哈希表中添加packet_type數據結構以進行注冊。Packet_type數據結構包含協議類型、指向網絡設備的指針、指向協議的接收數據處理例程的指針等。Ptype_base是一個哈希表，其哈希函數以協議標識符為參數，內核通常利用該哈希表判定應當接受傳入的網絡數據報的協議。通過檢查ptype_all鏈表和ptype_base哈希表，網絡底層處理程序會復制新的sk_buff，最終，sk_buff會傳遞到一個或多個目標協議的處理例程。
6.3 發送IP 數據報
網絡處理代碼必須建立sk_buff來包含要傳輸的數據，并且在協議層之間傳遞數據時，需要添加不同的協議頭和協議尾。
首先，IP協議需要決定要使用的網絡設備，網絡設備的選擇依靠于數據報的最佳路由。對于只利用調制解調器和PPP協議連接的計算機來說，路由的選擇比較輕易，但是對于連接到以太網的計算機來說，路由的選擇是比較復雜的。
對每個要傳輸的IP數據報，IP利用路由表解析目標IP地址的路由。對每個可從路由表中找到路由的目標IP地址，路由表返回一個rtable數據結構描述可使用的路由。這包括要使用的源地址、網絡設備的device數據結構的地址以及預先建立的硬件頭信息。該硬件頭信息和網絡設備相關，包含了源和目標的物理地址以及其它的介質信息。
6.4 數據報的分段與重組
當傳輸IP數據報時，IP從IP路由表中找到發送該IP數據報的網絡設備，網絡設備對應的device數據結構中包含由一個mtu字段，該字段描述最大的傳輸單元。假如設備的mtu小于等待發送的IP數據報的大小，就需要將該IP數據報劃分為小的片斷。每個片斷由一個sk_buff代表，其中的IP頭標記為數據報片斷，以及該片斷在IP數據報中的偏移。最后的數據報被標志為最后的IP片斷。假如分段過程中IP不能分配sk_buff，則傳輸失敗。
IP片斷的接收較片斷的發送更加復雜一些，因為IP片斷可能以任意的順序接收到，而在重組之前，必須接受到所有的片斷。每次接收到IP數據報時，IP 要檢查是否是一個分段數據報。當第一次接收到分段的消息時，IP建立一個新的ipq數據結構，并將它鏈接到由等待重組的IP片斷形成的ipqueue鏈表中。隨著其他IP片斷的接收，IP找到正確的ipq數據結構，同時建立新的ipfrag數據結構描述該片斷。每個ipq數據結構中包含有其源和目標IP地址、高層協議的標識符以及該IP幀的標識符，從而唯一描述了一個分段的IP接收幀。當所有的片斷接收到之后，它們被組合成單一的sk_buff并傳遞到上一級協議層處理。假如定時器在所有的片斷到達之前到期，ipq數據結構和ipfrag被丟棄，并假定消息已經在傳輸中丟失，這時，高層協議需要請求源主機重新發送丟失的信息。
新聞熱點
疑難解答
