【正文】 IP 數(shù)據(jù)包 ARP 報文 經(jīng)過路由地址 解析的數(shù)據(jù) 由中斷處理程序激活 以太網(wǎng)幀 PPP 幀 圖 3 2 TCP/IP 的總體數(shù)據(jù)流圖 嵌入式 TCP/IP 協(xié)議實現(xiàn) 數(shù)據(jù)鏈路層選擇用以太網(wǎng)協(xié)議，那么在上層網(wǎng)絡(luò)協(xié)議棧的選擇上為什么要用 TCP/IP而不是其它協(xié)議棧 (比如 IPX/SPX)呢 ?這是因為 TCP/IP 是 Inter 網(wǎng)絡(luò)環(huán)境中“既成事實”的開放系統(tǒng)平臺，要想使一個內(nèi)部網(wǎng)絡(luò)或網(wǎng)絡(luò)設(shè)備對外部世界來講是可視的，則必須用TCP/IP 進行通信。 通過 TCP/IP 能夠使內(nèi)部網(wǎng)絡(luò)或網(wǎng)絡(luò)設(shè)備與整個 Inter 聯(lián)網(wǎng)，在全世界范圍內(nèi)進行通信與信息交流。一個可互聯(lián)的設(shè)備本質(zhì)上就比一個不可互聯(lián)的設(shè)備更有價值。假如你在某一區(qū)域安裝了很多監(jiān)控產(chǎn)品，但數(shù)據(jù)中心卻不在該區(qū)域，而是設(shè)在其它地方，這時就需要通過 TCP/IP 協(xié)議來傳輸控制信息、狀態(tài)信息以及數(shù)據(jù)信息。另外，在嵌入式產(chǎn)品中實現(xiàn) TCP/IP 協(xié)議的好處是可以統(tǒng)一平臺，使不同廠家生產(chǎn)的產(chǎn)品兼容。比如一個大型的智能社區(qū)可能由多家設(shè)備供應(yīng)商來進行建設(shè)，其中一些廠商做平臺、做軟件，另外一些廠商做硬件。 TCP/IP 最先是在 UNIX 系統(tǒng)里實現(xiàn)的，后來的 LINUX, DOS, WINDOWS 也實現(xiàn)了TCP/IP，隨后 TCP/IP 協(xié)議也被移植到其它嵌入式的處理器上，例如 8 位的 MCS51 單片機、AVR 單片機， 16 位的 ARM, C166 以及 32 位的 MIPS,ARM 等芯片上。 TCP/IP 協(xié)議的最底層 IP 層，很多定義都是 16 位或 32 位的，例如源 IP 地址 (32 位 )、目的 IP 地址 (32 位 )、校驗值 (16 位 )，特別是校驗值，是以 16 位為單位進行計算的，這樣使得能夠處理 16 位、 32位運算的 CPU,比如 8028 8038 ARM、 MIPS、 DSP，就有很大的速度上的優(yōu)勢。 由于智能儀器的資源有限，所以在儀器中嵌入的 TCP/IP 協(xié)議棧和我們平常用的計算機中的 TCP/IP 協(xié)議棧有很大的不同。嵌入式 TCP/IP 不追求協(xié)議的完備性，一般以“夠用即可”為原則，所以需要根據(jù)實際需求來對協(xié)議棧進行裁剪。再加上本設(shè)計方案沒有采用操作系統(tǒng)，所以不能夠直接移植 UNIX 上實現(xiàn)的 TCP/IP 協(xié)議源代碼。 由于嵌入式系統(tǒng)與電腦的差別很大，所以嵌入式 TCP/IP 與常規(guī) TCP/IP 的實現(xiàn)有很大的不同。在電腦里編寫 TCP/IP 程序，你可以不考慮代碼大 小、代碼速度，但在嵌入式系統(tǒng)用戶發(fā)送任務(wù) 用戶接收任務(wù) SOCKET 應(yīng)用編程接口 TCP 協(xié)議模塊 UDP 協(xié)議模塊 IP 協(xié)議模塊 ICMP 協(xié)議模塊 ARP 協(xié)議模塊 網(wǎng)絡(luò)接口層 驅(qū)動程序 物理鏈路 異步串口 數(shù)據(jù)任務(wù)接收收 14 上這些都是要考慮的問題。 TCP/IP 包含從應(yīng)用層、傳輸層、網(wǎng)絡(luò)層到物理層的一系列協(xié)議，且每層可采用的協(xié)議又有好幾種。嵌入式系統(tǒng)應(yīng)用針對性非常強，只需要實現(xiàn)與需求相關(guān)的部分協(xié)議。例如文件共享 SMB 協(xié)議， UNIX,WINDOWS 操作系統(tǒng)都支持，但在嵌入式系統(tǒng)中卻沒有必要。 所以只需實現(xiàn)最精簡的 TCP/IP 協(xié)議。 基本協(xié)議框架設(shè)計 網(wǎng)絡(luò)接口層實現(xiàn) 功能概述 該層是 TCP/IP 協(xié)議棧與下層物理設(shè)備的驅(qū)動程序之間的接口。 發(fā)送普通數(shù)據(jù)時，本層的 網(wǎng)絡(luò)接口層發(fā)送函數(shù) ni_send()負責(zé)接收上層協(xié)議產(chǎn)生的數(shù)據(jù)，然后判斷發(fā)送的數(shù)據(jù)是從以太網(wǎng)接口發(fā)出還是從異步串口發(fā)出。如果是從以太網(wǎng)接口發(fā)出，則 ni_send()以待發(fā) IP數(shù)據(jù)報的目的 IP 地址為索引查找 ARP 地址映射表，如果查到對應(yīng)的目的物理地址，則以此封裝成以太網(wǎng)幀，在調(diào)用下層的 ne_transmit()數(shù)實現(xiàn)發(fā)送；如果沒有相應(yīng)的目的物理地址，則調(diào)用 ARP 協(xié)議實現(xiàn)中的 arp_req()函數(shù)發(fā) ARP 請求；如果是從串口發(fā)出，則直接調(diào)用下層 PPP 協(xié)議中的 ppp_send()函數(shù)發(fā)送。 接收數(shù)據(jù)時，本層的網(wǎng)絡(luò)接 口層接收函數(shù) ni_recv()被下層以太網(wǎng)驅(qū)動程序和 PPP 協(xié)議中的數(shù)據(jù)接收任務(wù)調(diào)用。 ni_recv()首先判斷接收數(shù)據(jù)類型，如果是 IP 數(shù)據(jù)報，則調(diào)用上層IP 協(xié)議中的 ip_recv()函數(shù)；如果是 ARP 數(shù)據(jù)報，則調(diào)用 ARP 報文處理函數(shù) arp_proc()。 初始化函數(shù) ni_init()負責(zé)實現(xiàn)網(wǎng)絡(luò)接口層、 ARP 協(xié)議以及下層的物理設(shè)備驅(qū)動程序的初始化，包括任務(wù)的創(chuàng)建、數(shù)據(jù)結(jié)構(gòu)的初始化。該函數(shù)被上層的 IP 協(xié)議初始化函數(shù) ni_init()調(diào)用。 函數(shù)關(guān)系圖 網(wǎng)絡(luò)接口層的函數(shù)關(guān)系如圖 所示，其中虛 線框內(nèi)為網(wǎng)絡(luò)接口層實現(xiàn)。 ARP 報文 IP 報文 IP 報文 接收數(shù)據(jù) 驅(qū)動程序 圖 3 3 網(wǎng)絡(luò)接口層函數(shù)關(guān)系 ARP協(xié)議實現(xiàn) 功能概述 ARP 協(xié)議實現(xiàn)對 ARP 報文的解釋、處理，同時管理 ARP 映射表。 ARP 協(xié)議是某些網(wǎng)絡(luò)接口 (如以太 網(wǎng)和令牌環(huán)網(wǎng) )使用的特殊協(xié)議 ,ARP 的地址解析功能是為 IP 地址和數(shù)據(jù)鏈路層使用的硬件地址提供動態(tài)地址映射。通用計算機系統(tǒng)中 ,ARP高速緩存一般設(shè)計成雙向數(shù)據(jù)鏈的形式 ,這樣整個緩存可以方便地動態(tài)增減。但是這種非線性存儲的鏈表式緩存結(jié)構(gòu) ,在進行表項匹配查找時比較費時 ,不適用于嵌入式系統(tǒng)。因此ARP 的地址緩存采用了線性數(shù)組形式的結(jié)構(gòu)。它在內(nèi)存中是連續(xù)線性存儲的 ,查找速度快。嵌入式應(yīng)用中節(jié)點不是很多 ,即 ARP 緩存容量不需要很大 ,因此將 ARP 高速緩存設(shè)計成固定大小。被動的嵌入式服務(wù)器主要是接收來自客戶的服務(wù)請求 ,為客 戶提供服務(wù) ,即嵌入式服務(wù)器不會主動向某一主機發(fā)數(shù)據(jù)幀。既然如此始終處于被動狀態(tài)的服務(wù)器完全不需要向任何調(diào)用 arp_proc() 接收函數(shù) ni_recv() 發(fā)送函數(shù) ni_send() 15 主機發(fā)送 ARP 請求 ,設(shè)備只要能處理 ARP 請求并返回 ARP 應(yīng)答即可。鑒于這種情況 ,ARP協(xié)議中選擇對 ARP 應(yīng)答部分進行實現(xiàn)。 ARP 報文分為 ARP 請求報文和 ARP 應(yīng)答報文。當(dāng)進行以太網(wǎng)幀封裝時，如果不知道目的物理地址，則調(diào)用 arp_req()函數(shù)發(fā)出 ARP 請求報文； ARP 報文處理函數(shù) arp_proc()負責(zé)對輸入 arp 報文進行處理，如果收到 ARP 請求報文，且請求解析的物理地址正是自己的物理地址，則調(diào)用函數(shù) arp_reply()發(fā)出 ARP 應(yīng)答報文；如果收到 ARP 應(yīng)答報文，則調(diào)用函數(shù) arp_send()把等候地址解析的 IP 數(shù)據(jù)報發(fā)出。 管理 ARP 映射表的工作主要包括 :ARP 表的查找， ARP 表項的添加、刪除以及 ARP表項的更新。其中，有一個定時器任務(wù) timer_task()負責(zé)對 ARP 表項的更新工作。 ARP 映射表的每個表項有一個生存時間域 (time to live, ttl)以表明該項是否己過時， ttl 域在表項建立時根據(jù)刷新頻率置初值，定時器任務(wù)每隔一段時間就把各表項的 ttl 域減一，如果該域為負值，則把 該表項刪除。每當(dāng)收到一個 ARP 報文后，首先以該報文中的有用信息更新 ARP映射表中的表項。 函數(shù) arp_init()負責(zé) ARP 協(xié)議的初始化，包括任務(wù)的創(chuàng)建、數(shù)據(jù)結(jié)構(gòu)的初始化等工作。arp_init()被網(wǎng)絡(luò)接口層的初始化函數(shù) ni_init()調(diào)用。 函數(shù)關(guān)系圖 ARP 協(xié)議的函數(shù)關(guān)系如圖 3 4 所示，其中虛線框內(nèi)為 ARP 協(xié)議實現(xiàn)。 圖 34 ARP 協(xié)議函數(shù)關(guān)系圖 IP協(xié)議實現(xiàn) 功能概述 IP 協(xié)議實現(xiàn)對無連接的 IP 數(shù)據(jù)包的尋徑、傳送。其中，數(shù)據(jù)報的尋徑采用靜態(tài)路由表 的方式實現(xiàn)。 IP 協(xié)議是 TCP/IP 的基礎(chǔ)，為不同網(wǎng)絡(luò)的主機之間發(fā)送數(shù)據(jù)報的操作序列提供無連接服務(wù)。通過在數(shù)據(jù)報前添加 IP 協(xié)議頭，使每個數(shù)據(jù)報具有尋址能力。嵌入式系統(tǒng)只把 IP作為傳輸工具，進行簡化以完成主要的操作。得到 IP 包后，檢驗 IP 頭部的版本、目的地址、校驗和正確否，解析出協(xié)議類型字段，由此交給相應(yīng)的高層協(xié)議處理。發(fā)送 IP 包時，將緩沖區(qū)內(nèi)的源地址與目的地址互換，設(shè)置校驗和，然后交給下層協(xié)議處理。不符合要求，則將此包丟棄。 IP 包最大可以為 65KB，可以分段傳輸，而在嵌入式系統(tǒng)里根本無法容納如此大的數(shù)據(jù)包， 因此一般不支持分段傳輸。所以限制 MCU 發(fā)送和接收數(shù)據(jù)包的方式以避免分段傳輸，從而減少程序復(fù)雜度。 一般情況下 ,數(shù)據(jù)包要經(jīng)過不同的物理網(wǎng)絡(luò) ,則 IP 層必須支持數(shù)據(jù)包的分片和重裝。但IP 的分片和重組所需的開銷比較大 ,而現(xiàn)有的網(wǎng)絡(luò)一般都支持以太網(wǎng) ,并且在此次應(yīng)用的 16 8/16 位嵌入式系統(tǒng)中 ,傳輸?shù)臄?shù)據(jù)都是一些數(shù)據(jù)量比較小的狀態(tài)信息或者控制信息。因此數(shù)據(jù)報都不會超過協(xié)議所限制的 1500 字節(jié)。如果極少數(shù)數(shù)據(jù)實在比較大 ,可以在程序中進行處理 ,分批次進行傳輸。因此可以裁減掉 IP 的分片和重組功能。而 IP 數(shù)據(jù)包的 路由功能則交給默認網(wǎng)關(guān)執(zhí)行 。 發(fā)送數(shù)據(jù)時，上層的 TCP 發(fā)送函數(shù) tcp_send(),UDP 發(fā)送函數(shù) udp_send()以及同層的ICMP 協(xié)議中的 icmp_send()函數(shù)把所發(fā)數(shù)據(jù)交給 ip_send()函數(shù)。在 ip_send()函數(shù)中，調(diào)用ip_route()函數(shù)，查找靜態(tài)路由表，如果找到相應(yīng)的路由，則調(diào)用網(wǎng)絡(luò)接口層發(fā)送函數(shù)ni_send()實現(xiàn)發(fā)送；如果沒有找到相應(yīng)的路由，則調(diào)用 ICMP 協(xié)議實現(xiàn)中的函數(shù) icmp_send()發(fā)送 icmp 出錯報文。 接收數(shù)據(jù)時，函數(shù) ip_recv()被下層的網(wǎng)絡(luò)接口層接收函 數(shù) ni_recv()調(diào)用以接收 IP 數(shù)據(jù)報。在 ip_recv()中，檢查數(shù)據(jù)報的目的 IP 地址，如果不是自己的 IP 地址，則調(diào)用 ip_route()，為其路由；如果為自己的 IP 地址，則再檢查該數(shù)據(jù)報的類型，如果是 TCP 報文，則調(diào)用上層的 TCP 數(shù)據(jù)接收函數(shù) tcp recv()；如果是 UDP 報文，則調(diào)用上層的 UDP 數(shù)據(jù)接收函數(shù) udp_recv()；如果是 ICMP 報文，則調(diào)用 ICMP 協(xié)議實現(xiàn)中的接收處理函數(shù) icmp_proc()。 初始化函數(shù) ip_init()負責(zé) IP 協(xié)議以及 ICMP 協(xié)議的初始化，完成如靜態(tài)路由表的安裝等工作，該函數(shù)在應(yīng)用初始化時被函數(shù) _init()調(diào)用。 ICMP協(xié)議實現(xiàn) 功能概述 ICMP 協(xié)議是 IP 網(wǎng)絡(luò)內(nèi)為控制、測試、管理功能而設(shè)計的協(xié)議。 ICMP 的報文類型很多 ,不同類型的報文由類型和代碼字段共同決定。為了了解設(shè)備是否可達 , Simplified TCP/IP 協(xié)議棧中主要實現(xiàn)了回顯請求和應(yīng)答報文的功能。該程序發(fā)送 ICMP 回顯請求報文給目的主機 ,并等待 ICMP 回顯應(yīng)答。對于處于被動狀態(tài)設(shè)備而言 ,不需要主動發(fā)送回顯請求 ,只要能夠識別來自其他客戶的回顯請求并發(fā)送回顯應(yīng) 答就可以了。為了能夠使用戶了解設(shè)備是否可達 ,應(yīng)當(dāng)能夠?qū)?Ping 的回顯請求給予應(yīng)答。 ICMP 協(xié)議位于 IP 層，負責(zé)接收、解釋、發(fā)送 ICMP 報文。 ICMP 報文主要有兩種功能 :報告出錯信息、傳送控制信息。盡管與 IP 協(xié)議處于同一層次，但 ICMP 報文卻是封裝在 IP 數(shù)據(jù)包的數(shù)據(jù)段部分進行傳送的，具體如圖 3 6 所示。 、 ICMP 報文 IP 數(shù)據(jù)包 圖 3 6 ICMP 報文的封裝 ICMP 協(xié)議實現(xiàn)比較單一，由兩個函數(shù)組成 :icmp_proc()函數(shù)、 icmp_send()函數(shù)。其中，icmp_proc()函數(shù)負責(zé)解釋、處理收到的 ICMP 報文； icmp_send()函數(shù)負責(zé)構(gòu)成 ICMP 報文并發(fā)送該報文。 ICMP 報文格式如下 ： 1 byte 1 byte 2 byte 2 byte 其中類型字段用來標(biāo)識報文；代碼字段提供有關(guān)報文類型的進一步信息。 函數(shù)關(guān)系圖 ICMP 協(xié)議的函數(shù)關(guān)系圖如圖 37 所示，虛線框內(nèi)為 ICMP 協(xié)議實現(xiàn)。 ICMP 報頭 ICMP 數(shù)據(jù) IP 數(shù)據(jù)段 IP 數(shù)據(jù)報頭 類 型 代 碼 檢 驗 和