一LWIP內存管理

LWIP的內存管理使用了2種方式：內存池memp和內存堆mem，如圖1所示。

內存池的特點是預先開辟多組固定大小的內存塊組織成鏈表，實現簡單，分配和回收速度快，不會產生內存碎片，但是大小固定，并且需要預估算準確。

內存堆的本質是對一個事先定義好的內存塊進行合理有效的組織和管理，主要用于任意大小的內存分配，實現較復雜，分配需要查找，回收需要合并，容易產生內存碎片，需要合理估算內存堆的總大小。

圖1內存池與內存堆

1. 數據包管理

數據包管理結構pbuf共有四種類型，它們的特點和使用場合如表1所示。

表1 pbuf類型與特點

每一種pbuf分配內存的方式都不一樣，如圖2所示。

圖2四種數據包管理結構

只有選擇合適的pbuf類型才能發揮LWIP的最大性能，一個數據包可能是多種pbuf的組合，用鏈表連接起來，如圖3所示。

圖3 pbuf鏈表

2. 設置內存大小

為LWIP開辟一個專用的內存堆是應該的，這樣一來LWIP的mem_alloc()和mem_free()都將基于該堆內存進行分配和回收，不影響其他系統內存的使用。如圖1左所示，lwipopt.h文件中宏MEM_SIZE定義了堆區的大小，對于一個負荷較重的系統堆區需要分配較大。

圖4堆和PBUF_ROM內存區

LWIP使用PBUF_ROM類型的內存池來發送“只讀”數據（處于ROM中或者其他進程中不可修改），宏MEMP_NUM_PBUF定義了該緩沖池的個數，如圖2右所示。

在ISR（中斷服務程序中）經常需要快速分配一部分內存進行數據存儲，這是通過PBUF_POOL類型的緩沖區實現的。為此需要定義兩個宏：PBUF_POOL_SIZE定義緩沖池的個數，PBUF_POOL_BUFSIZE定義單個緩沖區的大小，如圖5所示。

圖5PBUF_POOL內存區

3宏編譯開關

若定義MEM_LIBC_MALLOC=1，直接使用C庫中的malloc、free來分配動態內存；否則使用LWIP自帶的mem_malloc、mem_free等函數。

若定義MEMP_MEM_MALLOC=1，則memp.c中的全部內容不會被編譯，用內存堆來實現內存池分配，使用這種方式得考慮是否能忍受內存堆分配帶來的時間延遲。

若定義MEM_USE_POOLS=1，則mem.c中的全部內容不會被編譯，用內存池來實現內存堆的分配，使用這種方式得考慮是否能忍受因為POOL內存固定大小而帶來的內存浪費。此外用戶需要定義宏MEM_USE_CUSTOM_POOLS=1，還需要額外實現一個頭文件lwippools.h，并在其中開辟一些用于內存堆分配函數的內存池POOL，開辟空間的格式如下：

LWIP_MALLOC_MEMPOOL_START

LWIP_MALLOC_MEMPOOL(20, 256)

LWIP_MALLOC_MEMPOOL(10, 512)

LWIP_MALLOC_MEMPOOL_END

二LWIP啟動時序

圖6展示了LWIP啟動時序，大部分函數都是LWIP自帶的，主要的移植代碼是eth_init()實現初始化以太網接口，啟動程序會創建2個線程：tcpip_thread負責LWIP的絕大部分工作（主要是協議棧的解析和系統運行），ethernetif_thread負責從網口接收數據包再交付給tcpip_thread線程進行處理。

圖6LWIP啟動函數

三LWIP運行邏輯

1接收數據包

圖7接收數據包

當以太網口接收到一個數據包后，EMAC_IRQ中斷服務程序通過信號量通知ethernetif線程，ethernetif線程調用low_level_input()接收該數據包并通過郵箱交付給tcpip_thread線程，tcpip_thread根據該數據包的類型進行相應處理。它是建立在消息傳遞的基礎上的，如圖8所示。

圖8數據包消息的產生和處理

2 SequentialAPI函數調用

API設計的核心在于讓用戶進程負責盡可能多的工作，例如數據的計算、拷貝等；而協議棧進程只負責簡單的通信工作，這是很合理的，因為系統可能存在多個應用程序，它們都使用協議棧進程提供的通信服務，保證內核進程的高效性和實時性是提高系統性能的重要保障。進程之間通信使用IPC技術，包括郵箱、信號量和共享內存，如圖9所示。

圖9協議棧API實現

以函數netconn_bind()為例看API是如何實現的，首先用戶程序中調用函數netconn_bind()綁定一個連接，則這個函數實現時，是通過向內核進程發送一個TCPIP_MSG_API類型的消息，告訴內核進程執行do_bind函數：在消息發送后，函數阻塞在信號量上，等待內核處理該消息；內核在處理消息時，會根據消息內容調用do_bind，而do_bind會根據連接的類型調用內核函數udp_bind、tcp_bind或raw_bind；當do_bind執行完后，它會釋放信號量，這使被阻塞的netconn_bind得以繼續執行，整個過程如圖10所示。

圖10API函數實現

四TCP/IP核心知識點

1. 滑動窗口

圖11滑動窗口

接收窗口相關的字段中，rcv_nxt是自己期望收到的下一個字節編號，rcv_wnd表示接收窗口的大小，rcv_ann_wnd表示將向對方通告的窗口大小值，這個值在報文發送時會被填在首部中的窗口大小字段，rcv_ann_right_edge記錄了上一次窗口通告時窗口右邊界取值。上面這四個字段都會隨著數據的發送和接收動態地改變，如圖12所示。

圖12接收窗口

發送窗口中，lastack記錄了被接收方確認的最高序列號，snd_nxt表示自己將要發送的下一個數據的起始編號，snd_wnd記錄了當前的發送窗口大小，它常被設置為接收方通告的接收窗口值，snd_lbb記錄了下一個被應用程序緩存的數據的起始編號，如圖10所示。

上面這四個字段的值也是動態變化的，每當收到接收方的一個有效ACK后，lastack的值就做相應的增加，指向下一個待確認數據的編號，當發送一個報文后，snd_nxt的值就做相應的增加，指向下一個待發送數據，snd_nxt和lastack之間的差值不能超過snd_wnd的大小。

由于實際數據發送時是按照報文段的形式組織的，因此可能存在這樣的情況：即使發送窗口允許，但并不是窗口內的所有數據都能發送以填滿窗口，如圖13中編號為11～13的數據，可能因為它們太小不能組織成一個有效的報文段，因此不會被發送。發送方會等到新的確認到來，從而使發送窗口向右滑動，使得更多的數據被包含在窗口中，這樣再啟動下一個報文段的發送。

圖13發送窗口

2. 三次握手

圖14連接建立過程

3. 斷開連接

圖15連接斷開過程

4.TCP狀態轉換

圖16 TCP狀態轉換圖

5. 同時打開

圖17雙方同時打開

6. 同時關閉

圖18雙方同時關閉

五正確使用LWIP

一般說來LWIP協議棧是比較穩定的，尤其像V1.3.2經歷過業界廣泛使用和工程應用，完全可以應用于嵌入式產品。那為什么還是有很多人反映LWIP不穩定呢？主要是以下幾個方面的原因：

1. 網絡硬件驅動確保EMAC口接收與發送穩定可靠

2. 移植LWIP基于OS的移植代碼正確穩定

3. 配置LWIP根據設備RAM尺寸進行合理配置

1) 值(PBUF_POOL_SIZE * PBUF_POOL_BUFSIZE)必須大于TCP_SND_BUF和TCP_WND，否則容易引起錯誤；

2) 當內存有限時TCP發送不能太快（具體值依賴于分配內存的大小），否則引起tcp_enqueue()邏輯錯誤；

4. 調用LWIP的API函數正確使用API函數，特別防止內存泄露。

5. 資源不足打開報警提醒，當資源不夠時提醒設計者

六LWIP常見問題

1. 網卡驅動程序

首先，必須將協議棧完全初始化才能打開網絡接收功能，接收中斷必須將數據封裝在PBUF中，然后交會給協議棧內核處理。其次，LWIP的全局變量（arp_table,netif_list,udp_pcbs等）確保賦初值0，否則容易一運行就崩潰。

2. 內存泄露

第一個原則（責任制）：誰分配內存，誰就負責回收。

第二個原則（對稱性）：分配內存者與回收內存者一一對應構成閉環。

另外，需要特別注意一些系統函數的調用，它們也會帶來內存泄露，如：

例1

newconn = netconn_accept(conn);

do_something_for(newconn);

netconn_close(newconn);

netconn_delete(newconn);/*一定要釋放newconn否則將導致內存泄露*/

例2

inbuf = netconn_recv(conn);

do_something_for(inbuf);

netbuf_delete(inbuf);/*一定要釋放inbuf否則將導致內存泄露*/

3.PC機無法與LWIP建立TCP連接

問題：PC機能夠與LWIP設備PING操作成功，但是無法建立TCP連接。

原因：通過代碼跟蹤，發現LWIP發出了SYN+ACK數據包，但是PC機無法接收該握手數據包，該數據包為60字節，小于以太網的最小長度（64字節），而LWIP設備的EMAC沒有設置短小數據包填充功能，導致PC機無法接收該短數據包。

解決：使能EMAC的短小數據包填充功能。