關于TCP/IP協議已經介紹很多了，但在實際運用中有著各種不同的方法，本篇所要給大家介紹的就是TCP/IP協議棧的運用，設置一個網絡環境時會有很大的幫助。

[[64898]]

一、TCP/IP應用都必須實現IP和ICMP對于一個路由器而言，有這兩個協議就可以運作了，雖然從應用的角度來看，這樣一個路由器 意義不大。實際的路由器一般還需要運行許多使用的協議，以及一些其它的協議，主要有lwIP和uC/IP。

1、lwIP(LightweightTCP/IPStack)：支持的協議比較完整，一般需要多任務環境支持，代碼占用ROM>40KB，不適合8位機系統，沒有完整的應用文檔;

2、uC/IP(TCP/IPstackforuC/OS)：基于uC/OS的任務管理，接口較復雜，沒有說明文檔。

二、由于uIP所具有的顯著特點，自從0.6版本以來就被移植到多種處理器上，包括MSP430、AVR和Z80等，它去掉了許多全功能協議棧中不常用的功能，而保留網絡通信所必要的協議機制。

其設計重點放在IP、ICMP和TCP協議的實現上，將這三個模塊合為一個有機的整體，而將UDP和ARP協議實現作為可選模塊，uIP0.9處于網絡通信的中間層，其上層協議在這里被稱之為應用程序，而下層硬件或固件被稱之為網絡設備驅動。

顯然，uIP0.9并不是僅僅針對以太網設計的，它具有媒體無關性。

三、注意各模塊的融合，減少處理函數的個數和調用次數，提高代碼復用率，以減少ROM占用。基于單一全局數組的收發數據緩沖區，不支持內存動態分配，由應用負責處理收發的數據。

基于事件驅動的應用程序接口，各并發連接采用輪循處理，僅當網絡事件發生時，由uIP內核喚起應用程序處理。這樣，uIP用戶只須關注特定應用就可以了。傳統的TCP/IP實現一般要基于多任務處理環境，而大多數8位機系統不具備這個條件，由uIP內核設置重發事件，應用程序重新生成數據提交發送，免去了大量內部緩存的占用。

四、當設備驅動程序從網絡層收到一個數據包時要調用這個函數，設備驅動程序必須事先將數據包存放到uip_buf[]中，包長放到uip_len，然后交由uip_input()處理。當函數返回時，如果uip_len不為0，則表明有帶外數據(如SYN，ACK等)要發送。

當需要ARP支持時，還需要考慮更新ARP表或發出ARP請求和回應，另一個需要驅動程序支持的函數是uip_periodic(conn)。這個函數用于uIP內核對各連接的定時輪循，因此需要一個硬件支持的定時程序周期性地用它輪循各連接，一般用于檢查主機是否有數據要發送，如有，則構造IP包。使用示例如下。

五、為了將用戶的應用程序掛接到uIP中，必須將宏UIP_APPCALL()定義成實際的應用程序函數名，這樣每當某個uIP事件發生時，內核就會調用該應用程序進行處理。

如果要加入應用程序狀態的話，必須將宏UIP_APPSTATE_SIZE定義成應用程序狀態結構體的長度。在應用程序函數中，依靠uIP事件檢測函數來決定處理的方法，另外可以通過判斷當前連接的端口號來區分處理不同的連接。

六、單片機采用的是Atmel的AT89C55WD，它內置20KB程序Flash，512字節RAM，3個定時器/計數器，工作在22.1184MHz時具有約2MIPS的處理速度。

網卡芯片同樣采用的是低成本的RTL8019AS，是一款NE2000兼容的網卡芯片。系統外擴了32KB的SRAM，用于串口數據和網絡數據的緩沖，另外還存放了uIP的許多全局變量。

七、UIPWeb51的應用程序，路由器首先打開80端口的監聽，一旦有客戶機要求連上，uIP內部會給它分配一個連接項，接著等收到客戶機IE瀏覽器發出的“GETHTTP…”請求后，將發電機電平與狀態數據隊列中的數據填入網頁模板，生成一幅新的網頁發給客戶機。

因為這幅網頁的大小已經超過uIP的最大段長，因此在uIP內核第一次實際只發出了MSS個字節，在等到下一次輪循到該連接并且收到上次數據包的ACK時，發送剩下的網頁數據。

八、在連接處于空閑的時候，應用程序可以從串口隊列中讀出原始數據，經格式處理后再存到發電機電平與狀態數據隊列中，而在這個隊列中保存著當前1min的設備工作數據，以便下次更新網頁時使用。

在網頁中添加了更新按鈕，一旦瀏覽器用戶點擊了按鈕，瀏覽器會自動發出CGI請求，UIPWEB51收到后，立即發送包含最新數據的網頁。

如果uIP接收ACK超時，它會自動設置重發標志，應用程序中可以用uip_rexmit()來檢測這個標志，重新生成網頁并發送。一旦用戶關閉了瀏覽器，uIP也會自動檢測到這一事件，并且釋放掉這個連接項。

重點說明

每一個應用層一般都會使用到兩個傳輸層協議之一： 面向連接的TCP傳輸控制協議和無連接的包傳輸的UDP用戶數據報文協議。