ARP是Address Resolution Protocol的縮寫。中文譯做“地址解析協議”，本質是完成網絡地址到物理地址的映射。從概念上講就是找到一個映射方法f，使得“物理地址 = f(網絡地址)”。物理地址有兩種基本類型：以太網類型和proNET令牌環網類型，網絡地址特指IP地址，對映射方法的要求就是高效。具體到以太網，它使用的是動態綁定轉換的方法。為什么不直接使用同一種地址，而要這么麻煩呢？因為TCP/IP網絡就是為將不同種類計算機互聯而發明的，它的體系結構是分層的，層和層之間相互獨立，改變物理層的實現不會影響到網絡層。
32位IP地址到以太網48位物理地址的映射，采用動態綁定轉換的方法會遇到許多細節問題，例如：減少廣播，ARP包丟失，物理地址變更(更換網卡)、移動(移動設備到另一子網)、消失(關機)等。一般是設置ARP高速緩存，通過學習、老化、更新、溢出算法處理ARP映射表來解決這些問題。其中，學習指ARP收到任何指向本節點IP地址的ARP/IP包，從中提取出地址對，而ARP緩存中無對應項時，由ARP接收部分添加；老化指為每項設置壽命域，以便代謝掉陳舊的地址映射項；更新指ARP提取到新的地址對時，用其更新緩存里已有的對應項；溢出算法指當緩存滿時，采取何種方法替換舊有的地址對兒。
我找到了幾個TCP/IP源代碼，對比他們的實現，深感差別巨大，靈活多變。有的代碼未實現ARP緩存，只用幾個全局變量記錄源目的IP地址和源目的MAC地址，每次通信前直接操作全局變量，這在使用51單片機，進行點對點通信時不失為一個有效的方案；而有的代碼龐大復雜，細節處理精益求精。比如實現了ARP高速緩存、支持多址節點、支持網管查看/動態改變ARP相關參數、重發處理、支持IPv6等。我的看法是：ARP的本質是地址轉換，只要抓住這個靈魂，設計的大方向就把握住了。具體實現過程各具特色，因人而異，沒有統一要求，有些功能可以不實現，有些優點不能兼得，而唯一不變的只有思想。
我參考了幾種已有的IP協議棧并結合51單片機的特點，實現了自己的基于uCOS51的TCP/IP協議棧方案。它只是一種具體的實現范例，不同的人有不同的設計方法。我保證自己的方案可以正常使用并具有較好的完備性。

------------------------------
|狀態|壽命ttl|IP地址 |MAC地址| 學習
------------------------------
| 0 | FF |X:X:X:X| XXXX | --- 老化
------------------------------
| 0 | FF |X:X:X:X| XXXX | 更新
------------------------------
圖1 ARP緩存表 表滿處理

如圖1所示，ARP緩存表由狀態、壽命、IP地址、MAC地址4個字段組成。狀態字段指示地址對是否有效(0-空閑 1-占用)；壽命字段用于老化操作，初始存入最大值，以后由OS時間函數調用，每秒減1，直至為0清除；IP地址和MAC地址字段保存網絡地址和物理地址的映射。此處，沒有設計發送數據鏈表首指針和重發記數字段，我把重發操作交給上層軟件統一處理，這是本程序的特色。圍繞ARP緩存表，完成了4種操作：學習、老化、更新、表滿處理，詳見偽代碼清單。使用OS的Shell命令ls可以查看ARP表的內容，但不支持修改，這個功能對測試很有用。(顯示內容舉例如圖2所示)

%ls

ARP table:
status TTL IP address MAC address
=================================================
01 78 172.18.92.86 0050BABD4C7E

%
圖2 ARP緩存表顯示內容舉例


表滿處理
|
v ARP請求
--------- ----------- ---------->
| | 學習/更新 | | - - - - -
老化--->| ARP表 |------------| ARP處理 |
| | | | - - - - - >
--------- ----------- ----------
^ ARP應答
|學習/更新
---------
| |
| IP_in |
| |
---------
圖3 ARP處理過程

0 8 16 24 31
---------------------------------------------------------------------
| 硬件類型 | 協議類型 |
---------------------------------------------------------------------
|硬件地址長度(HLEN)|協議長度(PLEN)| 操作 |
---------------------------------------------------------------------
| 發送方首部(八位組0-3) |
---------------------------------------------------------------------
| 發送方首部(八位組4-5) | 發送方IP地址(八位組0-1) |
---------------------------------------------------------------------
| 發送方IP地址(八位組2-3) | 目標首部(八位組0-1) |
---------------------------------------------------------------------
| 目標首部(八位組2-5) |
---------------------------------------------------------------------
| 目標IP地址(八位組0-3) |
---------------------------------------------------------------------
圖4 ARP包結構

如圖3，整個ARP處理過程，我主要用5個函數實現。ARP初始化(ARP_init)、ARP請求(ARP_request)、ARP應答(ARP_answer)、ARP回應處理(ARP_process)、IP包接收預處理(IP_in)。在實現網卡驅動程序后，所有ARP處理操作就是填寫ARP包(ARP包結構見圖4)，詳見偽代碼清單。
ARP_init完成ARP表初始化，概括說就是ARP表state字段清0。
ARP_request完成ARP請求操作。ARP協議要求程序根據子網掩碼判斷IP地址是否屬于同一子網，如果在同一子網內，ARP請求目的MAC地址，否則請求默認網關MAC地址。
ARP_answer比較簡單，只要交換ARP請求包地址內容，填寫自己的MAC地址和很少的改動后發送即可。
ARP_process完成ARP回應回來的信息處理。主要進行ARP表的學習和更新。
IP_in完成IP包接收預處理，用于提取地址映射信息，以便主動學習和及時更新。我的程序不會主動學習不是發給自己IP地址的MAC地址信息，因為ARP表在51中的容量有限，只有頻繁用到的地址對才應該存放在里面，否則一旦出現“顛簸”，ARP表就失效了。
有的ARP實現方案采用數據驅動方式，參數可配置，使用統一的程序，通過加載不同的配置數據，執行不同的操作。這樣做使程序版本統一，不同的應用只要加載不同的配置數據即可，不用更換程序，有利于后期維護。但是考慮到51資源緊張和安全性，我的方案只能顯示ARP表不允許修改其內容，用戶可發揮想象力在此處增加新功能。另外，ARP程序應該記住上一次發過的請求，以避免重發，但同樣考慮到資源緊張，也免了。其實無所謂，重發就重發了。表滿處理采用有損性能的加速算法，快速有效。另外，本程序不能直接用于嵌入式網關產品。
uCOS51操作系統本身提供了良好的內存管理功能，我利用它設置了大中小三種緩沖區存放不同類型的數據包。內存使用前申請，使用后釋放，有效利用了資源。
系統特點是：1.搶占式優先級；2.消息驅動；3.串行服務器模式。
系統優點是：1.等待時不耗費CPU資源；2.有超時保護，不會死鎖；3.思路清晰易懂。
系統基于中斷驅動，使用Int0做網卡中斷輸入口。ISR寄存器只用到4位：OVW 收溢出錯/TXE 發被中斷錯/PTX 發送成功/PRX 接收成功。TCP/IP協議棧做成任務，脫離內核。整體框架如圖5、6、7所示。主程序框架見偽代碼清單(RxSem和TxSem初始化為0)