【正文】 程 嵌入式 TCP/IP 的總體數(shù)據(jù)流圖如圖 32 所示 : 應用程序通過 socket 應用編程接口使用 TCP/IP 協(xié)議棧提供的數(shù)據(jù)通訊功能。另外，在嵌入式產(chǎn)品中實現(xiàn) TCP/IP 協(xié)議的好處是可以統(tǒng)一平臺，使不同廠家生產(chǎn)的產(chǎn)品兼容。在電腦里編寫 TCP/IP 程序，你可以不考慮代碼大 小、代碼速度，但在嵌入式系統(tǒng)用戶發(fā)送任務 用戶接收任務 SOCKET 應用編程接口 TCP 協(xié)議模塊 UDP 協(xié)議模塊 IP 協(xié)議模塊 ICMP 協(xié)議模塊 ARP 協(xié)議模塊 網(wǎng)絡接口層 驅(qū)動程序 物理鏈路 異步串口 數(shù)據(jù)任務接收收 14 上這些都是要考慮的問題。 接收數(shù)據(jù)時，本層的網(wǎng)絡接 口層接收函數(shù) ni_recv()被下層以太網(wǎng)驅(qū)動程序和 PPP 協(xié)議中的數(shù)據(jù)接收任務調(diào)用。但是這種非線性存儲的鏈表式緩存結(jié)構(gòu) ,在進行表項匹配查找時比較費時 ,不適用于嵌入式系統(tǒng)。當進行以太網(wǎng)幀封裝時，如果不知道目的物理地址，則調(diào)用 arp_req()函數(shù)發(fā)出 ARP 請求報文； ARP 報文處理函數(shù) arp_proc()負責對輸入 arp 報文進行處理，如果收到 ARP 請求報文，且請求解析的物理地址正是自己的物理地址，則調(diào)用函數(shù) arp_reply()發(fā)出 ARP 應答報文；如果收到 ARP 應答報文，則調(diào)用函數(shù) arp_send()把等候地址解析的 IP 數(shù)據(jù)報發(fā)出。 圖 34 ARP 協(xié)議函數(shù)關系圖 IP協(xié)議實現(xiàn) 功能概述 IP 協(xié)議實現(xiàn)對無連接的 IP 數(shù)據(jù)包的尋徑、傳送。 IP 包最大可以為 65KB，可以分段傳輸，而在嵌入式系統(tǒng)里根本無法容納如此大的數(shù)據(jù)包， 因此一般不支持分段傳輸。 發(fā)送數(shù)據(jù)時，上層的 TCP 發(fā)送函數(shù) tcp_send(),UDP 發(fā)送函數(shù) udp_send()以及同層的ICMP 協(xié)議中的 icmp_send()函數(shù)把所發(fā)數(shù)據(jù)交給 ip_send()函數(shù)。該程序發(fā)送 ICMP 回顯請求報文給目的主機 ,并等待 ICMP 回顯應答。 ICMP 報文格式如下 ： 1 byte 1 byte 2 byte 2 byte 其中類型字段用來標識報文；代碼字段提供有關報文類型的進一步信息。 由于 TCP 協(xié)議要求 發(fā)送每一個數(shù)據(jù)都必須收到確認后才能肯定數(shù)據(jù)己正確發(fā)到目的地，如果在規(guī)定時間內(nèi)仍未收到確認，則要重發(fā)該數(shù)據(jù)。相對 IP 協(xié)議而言，唯一增加的功能是提供協(xié)議端口以實現(xiàn)進程間的通 信。 函數(shù) udp_init()負責 UDP 協(xié)議的初始化，包括任務的創(chuàng)建、數(shù)據(jù)結(jié)構(gòu)的初始化等工作。 ，令其主動廣播自己的地址編聯(lián)，以免其它主機對它運行 ARP。 算法設計流程如圖 44 所示。為了簡化代碼，提高效率，本設計不對輸出數(shù)據(jù)報進行分片，只實現(xiàn)了對輸入數(shù)據(jù)報片的重組。若檢查未通過，則丟棄。算法流程圖如圖 46 所示。事實上，由于嵌入式系統(tǒng)生成的數(shù)據(jù)報足夠小，能夠直接通過網(wǎng)絡傳輸，因此，嵌入式系統(tǒng)并不需要將輸出數(shù)據(jù)報進行分片。 圖 43 發(fā)送 ARP 應答報文流程圖 (4) arp_pro(接口函數(shù)，被上層調(diào)用 ) 對輸入的 ARP 報文進行分析，判斷是否為請求報文或者為應答報文。實驗表明，由于多數(shù)網(wǎng)絡通訊都需要持續(xù)發(fā)送多個報文，所以高速緩存大大提高了 ARP 的效率。 發(fā)送數(shù)據(jù)時，上層調(diào)用本層的數(shù)據(jù)發(fā)送函數(shù) udp_send()，在 udp_send 中再調(diào)用下層的ip_send()函數(shù)實現(xiàn)發(fā)送。 函數(shù)關系圖 TCP 協(xié)議主要函數(shù)關系如圖 38 所示，虛線框內(nèi)為 TCP 協(xié)議實現(xiàn)。 數(shù)據(jù)的接收由 TCP 接收函數(shù) tcp_recv()與 TCP 連接建立好以后的處理函數(shù) estab()完成。 、 ICMP 報文 IP 數(shù)據(jù)包 圖 3 6 ICMP 報文的封裝 ICMP 協(xié)議實現(xiàn)比較單一，由兩個函數(shù)組成 :icmp_proc()函數(shù)、 icmp_send()函數(shù)。 ICMP 的報文類型很多 ,不同類型的報文由類型和代碼字段共同決定。因此可以裁減掉 IP 的分片和重組功能。發(fā)送 IP 包時，將緩沖區(qū)內(nèi)的源地址與目的地址互換，設置校驗和，然后交給下層協(xié)議處理。arp_init()被網(wǎng)絡接口層的初始化函數(shù) ni_init()調(diào)用。鑒于這種情況 ,ARP協(xié)議中選擇對 ARP 應答部分進行實現(xiàn)。 ARP 協(xié)議是某些網(wǎng)絡接口 (如以太 網(wǎng)和令牌環(huán)網(wǎng) )使用的特殊協(xié)議 ,ARP 的地址解析功能是為 IP 地址和數(shù)據(jù)鏈路層使用的硬件地址提供動態(tài)地址映射。 發(fā)送普通數(shù)據(jù)時，本層的 網(wǎng)絡接口層發(fā)送函數(shù) ni_send()負責接收上層協(xié)議產(chǎn)生的數(shù)據(jù)，然后判斷發(fā)送的數(shù)據(jù)是從以太網(wǎng)接口發(fā)出還是從異步串口發(fā)出。再加上本設計方案沒有采用操作系統(tǒng)，所以不能夠直接移植 UNIX 上實現(xiàn)的 TCP/IP 協(xié)議源代碼。一個可互聯(lián)的設備本質(zhì)上就比一個不可互聯(lián)的設備更有價值。 TCP/IP 協(xié)議棧與 Socket APIs 一起以系統(tǒng)軟組件的形式提供給用戶，用戶使用 Sockets APIs 編寫應用代碼，然后與該系統(tǒng)組件的代碼庫鏈接在一起。 圖 2 7 UDP 數(shù)據(jù)報的字段格式 端口號表示發(fā)送進程和接收進程。二者都使用端口號作為送往主機的解碼地址。直到包到達最終目的地。要是它降到 0 的話，包就會被拋棄。 0 8 16 24 31 圖 2 4 ARP 的報文格式 硬件類型字段表示硬件地址的類型，它的值為 1 即表示以太網(wǎng)地址；協(xié)議類 型字段表示要映射的協(xié)議地址類型，如 0x0800 即表示 IP 地址；硬件地址長度和協(xié)議地址長度以字節(jié)為單位，對于以太網(wǎng)上的 IP 地址的 ARP 請求或應答來說，它們的值分別為 6 和 4； 操作字段指出四種操作類型，它們是 ARP 請求 (值為 1)ARP 應答 (值為 2 )、 RARP 請求 (值為3 )、 RARP 應答 (值為 4)，這個字段是必需的，因為 ARP 請求和應答的幀類型字段是相同的。對此我們先要了解 IP 和物理地址兩種編址形式 : IP 地址 :互聯(lián)網(wǎng)上的每個接口必須有一個唯一的 Inter 地址 (也稱 IP 地址 )， IP 地址長32bit。但由于網(wǎng)絡協(xié)議的復雜性與嵌入式系統(tǒng)的 MCU 相對簡單之間的矛盾，極大的制約了嵌入式系統(tǒng)實現(xiàn)網(wǎng)絡化的進程。數(shù)據(jù)在不同的層添加了不同的信息，有不同的稱呼，如 TCP 傳遞給 IP 的數(shù)據(jù)單元稱作 TCP報文段或 TCP 段 (TCP segment ), IP 傳遞給網(wǎng)絡接口層的叫 IP 數(shù)據(jù)報 (IP datagram )，通過以太網(wǎng)傳輸?shù)谋忍亓鞣Q作幀 ( Frame )。這種通信又叫端到端通信。 TCP/IP 協(xié)議并不完全符合 OSI 的七層參考模型。 網(wǎng)絡層 (Network layer):關鍵問題是確定分組從源端到目的端如何選擇路由。 關于協(xié)議分層，有兩個思想占據(jù)了該領域的主導地位。家居網(wǎng)絡是信息化城市和信息化社會的最重要標志，也是其最基本的單元。 目前，家電等嵌入式設備直接聯(lián)網(wǎng)存在的問題是 :的控制器，它們的運算速度和系統(tǒng)資源根本無法運行復雜 Inter 網(wǎng)絡協(xié)議 TCP/IP。由嵌入式應用的多樣性決定了嵌入式應用平臺也是變化多端的。為了達到靈活性的要求，嵌入式 TCP/IP 應具有開發(fā)環(huán)境獨立性和目標環(huán)境獨立性 :對底層協(xié)議無任何假設，通過網(wǎng)卡配置表動態(tài)地將其聯(lián)入系統(tǒng)中 。 嵌入式系統(tǒng)首先是一個實時系統(tǒng)，它具有實時系統(tǒng)的根本特點，即能夠確定地響應異步事件。在 Inter 上進行web 頁面的傳輸， 傳送，文件傳輸，實現(xiàn)點對點網(wǎng)絡， TCP/IP 是最優(yōu)先采用的協(xié)議。 本文首先對嵌入式 TCP/IP的特點和發(fā)展動態(tài)進行了介紹，然后從嵌入式領域的角度對TCP/IP協(xié)議進行了較全面的分析，提出了一個 TCP/IP網(wǎng)絡組件的系統(tǒng)模型。為此，本文對嵌入式設備聯(lián)網(wǎng)的TCP/IP協(xié)議進行了討論研究。 伴隨著 Inter 的成功， TCP/IP 協(xié)議族已經(jīng)成為通信的全球標準。 這種用于嵌入式系統(tǒng)聯(lián)網(wǎng)的 TCP/IP 就稱為嵌入式 TCP/IP，其主要特點是實時性、簡單性和靈活性。嵌入式應用規(guī)?？纱罂尚?，網(wǎng)絡硬件品種繁多，底層協(xié)議也多種多樣，這就要求嵌入式 TCP/IP 協(xié)議能 夠適應各種需求，提供靈活、高效的網(wǎng)絡通訊服務。 (2) 很強的可移植性。由于是面向嵌入式應用，因此這些產(chǎn)品在實時性、占用存儲空間、可移植性方面都做了各具特色的改進。而信息化城市和信息化社會是目前人們主攻的目標。但在所有的網(wǎng)絡中，每一層的目的都是向它的上一層提供一定 的服務，而把如何實現(xiàn)這一服務的細節(jié)對上一層加以屏蔽。其中還有一個特殊的子層 —— 介質(zhì)訪問子層，它主要控制對共享信道的訪問。 TCP/IP參考模型 廣泛地講， TCP/IP 軟件分成五個概 念層次，建立在第五層 (即硬件層 )上四個軟件層，圖 給出了這些概念性層次結(jié)構(gòu)以及在這些層次之間傳輸?shù)臄?shù)據(jù)形式。 傳輸層 (Transport Layer):基本任務是提供應用程序之間的通信服務。 概念性層次 通過層次間的對象 報文和數(shù)據(jù)流 傳輸協(xié)議分組 IP 數(shù)據(jù)報 特定于網(wǎng)絡的幀 圖 2 2 TCP/IP 網(wǎng)絡層次模型及各層之間傳輸數(shù)據(jù) 形式 如圖 23 所示當最初的用戶數(shù)據(jù)到來時，數(shù)據(jù)被送入?yún)f(xié)議棧中，由上到下每通過一層都要添加一些首部信息 (鏈路層還要添加尾部信息 )，直到數(shù)據(jù)被當成一串比特流送入網(wǎng)絡。 TCP 段 IP 數(shù)據(jù)報 14 20 20 4 以太網(wǎng) 以太網(wǎng)幀 圖 2 3 數(shù)據(jù)進入?yún)f(xié)議棧時的封裝過程 嵌入式 TCP/IP協(xié)議 嵌入式系統(tǒng)與 TCP/IP 網(wǎng)絡的互聯(lián)，這一技術在許多領域得以廣泛的應用。 ARP 提供的是一種把 IP 地址映射到物理地址的機制。從接收方考慮，如果網(wǎng)絡上過來的是 ARP 請求幀，則查看自己是否是請求的目標 (是否與自己的 IP地址相符 )，如果符合則發(fā)送 ARP 應答幀。 這樣當路由器收到一個包后，該包向上傳給 IP： (1)如果交通阻塞，包在路由器中停滯， TTL 至少減 1 或更多。每個路由器都要重復該過 程。 UDP 和 TCP 都屬于 IP 上層的傳輸層協(xié)議。 12 3 嵌入式 TCP/IP 總體框架設計 嵌入式 TCP/IP 網(wǎng)絡系統(tǒng)結(jié)構(gòu) 其中， TCP/IP 協(xié)議是本課題的主要任務， Socket APIs 是一組 C 語言調(diào)用接口函數(shù)，應用程序通過它使用 TCP/IP 協(xié)議棧的功能。 通過 TCP/IP 能夠使內(nèi)部網(wǎng)絡或網(wǎng)絡設備與整個 Inter 聯(lián)網(wǎng)，在全世界范圍內(nèi)進行通信與信息交流。嵌入式 TCP/IP 不追求協(xié)議的完備性，一般以“夠用即可”為原則，所以需要根據(jù)實際需求來對協(xié)議棧進行裁剪。 基本協(xié)議框架設計 網(wǎng)絡接口層實現(xiàn) 功能概述 該層是 TCP/IP 協(xié)議棧與下層物理設備的驅(qū)動程序之間的接口。 ARP 報文 IP 報文 IP 報文 接收數(shù)據(jù) 驅(qū)動程序 圖 3 3 網(wǎng)絡接口層函數(shù)關系 ARP協(xié)議實現(xiàn) 功能概述 ARP 協(xié)議實現(xiàn)對 ARP 報文的解釋、處理，同時管理 ARP 映射表。既然如此始終處于被動狀態(tài)的服務器完全不需要向任何調(diào)用 arp_proc() 接收函數(shù) ni_recv()