lwip的特点

Lwip可以移植到操作系统上，也可以在无操作系统的情况下独立运行。LwIP实现的 重点是在保持TCP/IP协议主要功能的基础上减少对RAM的占用，这使得LwIP协议栈很适合在嵌入式系统中使用。  

以下是从网络上搜集并整理的一些资料，来说明Lwip的特点，看这个协议栈能否满足我们的应用。  Lwip协议栈的特点：   

(1) 支持多网络接口下的IP转发 

(2) 支持ICMP协议  

(3) 包括实验性扩展的的UDP（用户数据报协议）  

(4) 包括阻塞控制，RTT估算和快速恢复和快速转发的TCP（传输控制协议）

(5) 提供专门的内部回调接口（Raw API）用于提高应用程序性能

(6) 可选择的Berkeley接口API（多线程情况下）  

(7) 在最新的版本中支持ppp(这很适合我们的实际应用，避免重写PPP协议) 

(8) 新版本中增加了的IP fragment的支持. 

(9) 支持DHCP协议,动态分配IP地址. 

Lwip的进程模式：  所有tcp/ip协议栈都在一个进程当中，这样tcp/ip协议栈就和操作系统内核分开了。而应用层程序既可以是单独的进程也可以驻留在tcp/ip进程中。如果应用程序是单独的进程可以通过操作系统的邮箱，消息队列等和tcp/ip进程进行通讯。如果应用层程序驻留tcp/ip进程中,那应用层程序就利用内部回调函数口(Raw API)和tcp/ip协议栈通讯.对于ucos-ii来说进程就是一个系统任务。lwip的整个tcp/ip协议栈都在同一个任务(tcpip_thread)中。应用层程序既可以是独立的任务(tftp_thread，tcpecho_thread)，也可以在tcpip_thread中，利用 内部函数口(Raw API)和tcp/ip协议栈通讯。需要说明的一点是lwip会为每个网络连接动态分配一些信号量(semaphone)和消息队列(Message Queue)，当连接断开时会删掉这些semaphone和Queue。  

Lwip提供三种API：1)RAW API  2)lwip API  3)BSD API。  

（1）RAW API把协议栈和应用程序放到一个进程里边，该接口基于函数回调技术，使用该接口的应用程序可以不用进行连续操作。不过，这会使应用程序编写难度加大且代码不易被理解。为了接收数据，应用程序会向协议栈注册一个回调函数。该回调函数与特定的连接相关联，当该关联的连接到达一个信息包，该回调函数就会被协议栈调用。这即有优点也有缺点。优点是既然应用程序和TCP/IP协议栈驻留在同一个进程中，那么发送和接收数据就不再产生进程切换。主要缺点是应用程序不能使自己陷入长期的连续运算中，这样会导致通讯性能下降，原因是TCP/IP处理与连续运算是不能并行发生的。这个缺点可以通过把应用程序分为两部分来克服，一部分处理通讯，一部分处理运算。  

（2）Lwip API把接收与处理放在一个线程里面。这样只要处理流程稍微被延迟，接收就会被阻塞，直接造成频繁丢包、响应不及时等严重问题。因此，接收与协议处理必须分开。LwIP的作者显然已经考虑到了这一点，他为我们提供了tcpip_input()函数来处理这个问题，虽然他并没有在rawapi一文中说明。讲到这里，读者应该知道tcpip_input()函数投递的消息从哪里来的答案了吧，没错，它们来自于由底层网络驱动组成的接收线程。我们在编写网络
驱动时，其接收部分以任务的形式创建。数据包到达后，去掉以太网包头得到IP包，然后直接调用tcpip_input()函数将其投递到mbox邮箱。投递结束，接收任务继续下一个数据包的接收，而被投递得IP包将由TCPIP线程继续处理。这样，即使某个IP包的处理时间过长也不会造成频繁丢包现象的发生。这就是Lwip API。  

（3）BSD API提供了基于open-read-write-close模型的UNIX标准API，它的最大特点是使应用程序移植到其它系统时比较容易，但用在嵌入式系统中效率比较低，占用资源多。这对于嵌入式应用有时是不能容忍的。   基于以上的考虑，应采用Lwip API，嵌入式应用讲求效率高和省资源。   

用嵌入式操作系统最难把握的时进程堆栈的大小，要求我们能较准确地估算，如果在任务中使用递归，必须能够预料最坏情况下的递归层数！最理想的是能够通过一种方法测试出系统占用堆栈的大小。  lwip协议栈有自己的内存区，用于协议栈相关变量对内存的使用。因此，在协议栈相关的应用程序中，我们尽量使用这一部分内存。 避免造成内存空间的浪费!并且注意：用完之后一定要释放，否则你不是一个合格的程序员！为了保护内存缓冲区的完整性，防止因多个进程同时访问破坏数据，Lwip使用ucos-ii提供的OS_ENTER_CRITICAL和OS_EXIT_CRITICAL来保护临界资源！当然也可以用信号量来实现，但其效能不如前者！  lwIP包含好几个模块，除了那些实现TCP/IP协议族（IP，ICMP，UDP，TCP）的模块外，也实现了其他一些支持的模块。这些支持的模块包括操作系统仿真层，缓冲及内存管理子系统，网络接口函数，和计算检验和的函数。  

让LwIP实现为用户空间的进程而不是驻留操作系统内核有其优缺点。主要优点是这种实现在不同操作系统间是可移植的。因为lwIP被设计为运行在小的操作系统上，这些操作系统不支持交换进出进程和虚拟内存，所以由不得不等待磁盘操作（假如部分lwIP进程被交换出到磁盘中）引起的延迟不再是个问题。在有机会服务一个请求前必须等待一定的调度这仍然是个问题，但在lwIP的设计中并没有什么去排除将来会在操作系统内核中实现。为了使lwIP可移植，操作系统特定函数调用及数据结构并没直接在代码中使用。当需要这样的函数时， 操作系统仿真层就被使用。操作系统仿真层向操作系统服务提供了统一的接口，这些服务有定时器，进程同步，消息传递机制，等等。原理上，要移植lwIP到其他操作系统时，只需实现该特定操作系统的仿真层就可以了。操作系统仿真层提供了一个功能性定时器让TCP使用。该定时器是一个时间间隔至少200ms的一次性定时，它在定时结束时将调用一个已注册的函数。 信号量是进程同步机制的唯一一个实现。即使下层的操作系统并不提供信号量实现，它也能由其他的同步原语如临界变量或锁机制实现。消息传递的实现是一个抽象为“邮箱”的简单机制。一个邮箱有两种操作：邮递和收取。邮递操作不会阻塞该进程，而邮递给一个邮箱的信息会由操作系统仿真层列入队列，直到另外的进程收取该信息。 即使下层操作系统不支持邮箱机制，它也能容易地由信号量实现。  

缓冲及内存管理： 在一个通信系统中，缓冲及内存管理系统必须能准备好分配不同大小的缓冲区，从包含有几百字节有用数据的全长TCP报文段，到只含几个字节的ICMP 应答响应。同时，为了避免拷贝，应该尽可能地让数据类型缓冲区驻留在内存中，而不是由网络子系统，如应用内存或ROM来管理。为了节省内存空间，不使用IP碎片的重组。Lwip的存储管理是这样的： 收到的pbufs是PBUF POOL类型，发送出的pbufs是PBUF ROM或PBUF RAM类型。PBUF ROM由memp分配struct pbuf,而PBUF RAM和PBUF POOL在它们占用的内存中。内存管理只是简单地支持pbuf机制。它处理连续内存的分配和释放，并能收缩先前分配的内存块。