logo资料库

LwIP协议详解_老衲五木+目录.pdf

第1页 / 共99页
第2页 / 共99页
第3页 / 共99页
第4页 / 共99页
第5页 / 共99页
第6页 / 共99页
第7页 / 共99页
第8页 / 共99页
资料共99页,剩余部分请下载后查看
1 移植综述
2 动态内存管理
3 数据包 pbuf
4 pbuf 释放
5 网络接口结构
6 以太网数据接收
7 ARP 表
8 ARP 表 表表 表查询
9 ARP 层流程
10 IP 层 层层 层输入
11 IP 分片重装 1
12 IP 分片重装 2
13 ICMP 处理
14 TCP 建立与断开
15 TCP 状态转换
16 TCP 控制块
17 TCP 建立流程
18 TCP 状态机
19 TCP 输入输出函数 1
20 TCP 输入输出函数 2
21 TCP 滑动窗口
22 TCP 超时与重传
23 TCP 慢启动与拥塞避免
24 TCP 快速恢复重传和 快速恢复重传和 快速恢复重传和 快速恢复重传和 Nagle 算法
25 TCP 坚持与保活定时器
26 TCP 定时器
27 TCP 终结与小结
28 API 实现及相关数据结构
29 API 消息机制
30 API 函数及编程实例
LwIP 协议栈详解 ——TCP/IP 协议的实现 E-mail:for_rest@foxmail.com 老衲五木出品
前言 最近一个项目用到 LwIP,恰好看到网上讨论的人比较多,所以有了写这篇学习笔记的 冲动,一是为了打发点发呆的时间,二是为了吹过的那些 NB。往往决定做一件事是简单的, 而坚持做完这件事却是漫长曲折的,但终究还是写完了,时间开销大概为四个月,内存开销 无法估计。。 这篇文章覆盖了 LwIP 协议大部分的内容,但是并不全面。它主要讲解了 LwIP 协议最重 要也是最常被用到的部分,包括内存管理,底层网络接口管理,ARP 层,IP 层,TCP 层,API 层等,这些部分是 LwIP 的典型应用中经常涉及到的。而 LwIP 协议的其他部分,包括 UDP, DHCP,DNS,IGMP,SNMP,PPP 等不具有使用共性的部分,这篇文档暂时未涉及。 原来文章是发在空间中的,每节每节依次更新,后来又改发为博客,再后来就干脆懒得 发了。现在终于搞定,于是将所有文章汇总。绞尽脑汁的想写一段空前绝后,人见人爱的序 言,但越写越觉得像是猫儿抓的一样。就这样,PS:由于本人文笔有限,情商又低,下里巴 人一枚,所以文中的很多语句可能让您很纠结,您可以通过邮箱与我联系。共同探讨才是进 步的关键。 最后,欢迎读者以任何方式使用与转载,但请保留作者相关信息,酱紫!码字。。。世界 上最痛苦的事情莫过于此。。。 ——老衲五木 E-mail:for_rest@foxmail.com 老衲五木出品
目录 1 移植综述------------------------------------------------------------------------------------------------------ 4 2 动态内存管理------------------------------------------------------------------------------------------------ 6 3 数据包 pbuf -------------------------------------------------------------------------------------------------- 9 4 pbuf 释放 ---------------------------------------------------------------------------------------------------13 5 网络接口结构-----------------------------------------------------------------------------------------------16 6 以太网数据接收--------------------------------------------------------------------------------------------20 7 ARP 表 -----------------------------------------------------------------------------------------------------23 8 ARP 表查询 -----------------------------------------------------------------------------------------------26 9 ARP 层流程 -----------------------------------------------------------------------------------------------28 10 IP 层输入 -------------------------------------------------------------------------------------------------31 11 IP 分片重装 1 --------------------------------------------------------------------------------------------34 12 IP 分片重装 2 --------------------------------------------------------------------------------------------37 13 ICMP 处理 -----------------------------------------------------------------------------------------------40 14 TCP 建立与断开 ----------------------------------------------------------------------------------------43 15 TCP 状态转换 -------------------------------------------------------------------------------------------46 16 TCP 控制块 ----------------------------------------------------------------------------------------------49 17 TCP 建立流程 -------------------------------------------------------------------------------------------53 18 TCP 状态机 ----------------------------------------------------------------------------------------------56 19 TCP 输入输出函数 1 -----------------------------------------------------------------------------------60 20 TCP 输入输出函数 2 -----------------------------------------------------------------------------------63 21 TCP 滑动窗口 -------------------------------------------------------------------------------------------66 22 TCP 超时与重传 ----------------------------------------------------------------------------------------69 23 TCP 慢启动与拥塞避免 -------------------------------------------------------------------------------73 24 TCP 快速恢复重传和 Nagle 算法 -------------------------------------------------------------------76 25 TCP 坚持与保活定时器 -------------------------------------------------------------------------------80 26 TCP 定时器 ----------------------------------------------------------------------------------------------84 27 TCP 终结与小结 ----------------------------------------------------------------------------------------88 28 API 实现及相关数据结构 -----------------------------------------------------------------------------91 29 API 消息机制 --------------------------------------------------------------------------------------------94 30 API 函数及编程实例 -----------------------------------------------------------------------------------97 E-mail:for_rest@foxmail.com 老衲五木出品
1 移植综述 移植综述 移植综述移植综述 如果你认为所谓的毅力是每分每秒的“艰苦忍耐”式的奋斗,那这是一种很不足的心理 状态。毅力是一种习惯,毅力是一种状态,毅力是一种生活。看了这么久的代码觉得是不是 该写点东西了,不然怎么对得起某人口中所说的科研人员这个光荣称号。初见这如山如海的 代码,着实看出了一身冷汗。现在想想其实也不是那么难,那么多革命先辈经过 N 长时间 才搞出来的东东怎么可能让你个毛小子几周之内搞懂。我见到的只是冰川的一小角,万里长 征的一小步,九头牛身上的一小毛…再用某人的话说,写吧,昏写,瞎写,胡写,乱写,写 写就懂了。 我想我很适合当一个歌颂者,青春在风中飘着。你知道,就算大雨让这座城市颠倒,我 会给你怀抱;受不了,看见你背影来到,写下我度秒如年难捱的离骚;就算整个世界被寂寞 绑票,我也不会奔跑;逃不了,最后谁也都苍老,写下我,时间和琴声交错的城堡。我正在 听的歌。扯远了… 正题,嵌入式产品连入 Internet 网,这个 MS 是个愈演愈烈的趋势。想想,你可以足不 出户对你的产品进行配置,并获取你关心的数据信息,多好。这也许也是物联网世界最基本 的雏形。当然,你的产品要有如此功能,那可不容易,至少它得有个目前很 Fashion 的 TCP/IP 协议栈。LWIP 是一套用于嵌入式系统的开放源代码 TCP/IP 协议栈。在你的嵌入式处理器 不是很 NB,内部 Flash 和 Ram 不是很强大的情况下,用它还是很合适滴。 LWIP 的设计者为像我这样的懒惰者提供了详细的移植说明文档,当然这还不够,他们 还尽可能的包揽了大部分工作,懒人们只要做很少的工作就功德圆满了。纵观整个移植过程, 使用者需要完成以下几个方面的东西: 首先是 LWIP 协议内部使用的数据类型的定义,如 u8_t,s8_t,u16_t,u32_t 等等等等。 由于所移植平台处理器的不同和使用的编译器的不同,这些数据类型必须重新定义。想想, 一个 int 型数据在 64 位处理器上其长度为 8 个字节,在 32 位处理器上为 4 个字节,而在 16 位处理器上就只有两个字节了。因此这部分需要使用者根据处理器位数和和使用的编译器的 特点来编写。所以在 ARM7 处理器上使用的 typedef unsigned int u32_t 移植语句用在 64 位处 理器的移植过程中那肯定是行不通的了。 其次是实现与信号量和邮箱操作相关的函数,比如建立、删除、等待、释放等。如果 在裸机上直接跑 LWIP,这点实现起来比较麻烦,使用者必须自己去建立一套信号量和邮箱 相关的机制。一般情况下,在使用 LWIP 的嵌入式系统中都会有操作系统的支持,而在操作 系统中信号量和邮箱往往是最基本的进程通信机制了。UC/OSII 应该算是最简单的嵌入式操 作系统了吧,它也无例外的能够提供信号量和邮箱机制,只要我们将 UC/OSII 中的相关函 数做相应的封装,就可满足 LWIP 的需求。LWIP 使用邮箱和信号量来实现上层应用与协议 栈间、下层硬件驱动与协议栈间的信息交互。LWIP 协议模拟了 TCP/IP 协议的分层思想, 表面上看 LWIP 也是有分层思想的,但从实现上看,LWIP 只在一个进程内实现了各个层次 的所有工作。具体如下:LWIP 完成相关初始化后,会阻塞在一个邮箱上,等待接收数据进 行处理。这个邮箱内的数据可能来自底层硬件驱动接收到的数据包,也可能来自应用程序。 当在该邮箱内取得数据后,LWIP 会对数据进行解析,然后再依次调用协议栈内部上层相关 处理函数处理数据。处理结束后,LWIP 继续阻塞在邮箱上等待下一批数据。当然 LWIP 还 有一大串的内存管理机制用以避免在各层间交互数据时大量的时间和内存开销,这将在后续 讲解中慢慢道来。当然,但这样的设计使得代码理解难度加大,这一点让人头大。信号量也 E-mail:for_rest@foxmail.com 老衲五木出品
可以用在应用程序与协议栈的互相通信中。比如,应用程序要发送数据了,它先把数据发到 LWIP 阻塞的邮箱上,然后它挂起在一个信号量上;LWIP 从邮箱上取得数据处理后,释放 一个信号量,告诉应用程序,你要发的数据我已经搞定了;此后,应用程序得到信号量继续 运行,而 LWIP 继续阻塞在邮箱上等待下一批处理数据。 其其次,就是与等待超时相关的函数。上面说到 LWIP 协议栈会阻塞在邮箱上等待接收 数据的到来。这种等待在外部看起来是一直进行的,但其实不然。一般在初始化 LWIP 进程 的时候,都会同时的初始化一些超时事件,即当某些事件等待超时后,它们会自动调用一些 超时处理函数做相关处理,以满足 TCP/IP 协议栈的需求。这样看来,当 LWIP 协议栈阻塞 等待邮箱之前,它会精明的计算到底应该等待多久,如果 LWIP 进程中没有初始化任何超时 事件,那好,这种情况最简单了,永远的挂起进程就可以了,这时的等待就可以看做是天长 地久的….有点暧昧了。如果 LWIP 进程中有初始化的超时事件,这时就不能一直等了,因 为这样超时事件没有任何被执行的机会。LWIP 是这样做的,等待邮箱的时间设置为第一个 超时事件的时间长度,如果时间到了,还没等到数据,那好,直接跳出邮箱等待转而执行超 时事件,当执行完成超时事件后,再按照上述的方法继续阻塞邮箱。可以看出,对一个 LWIP 进程,需要用一个链表来管理这些超时事件。这个链表的大部分工作已经被 LWIP 的设计者 完成了,使用者只需要实现的仅有一个函数:该函数能够返回当前进程个超时事件链表的首 地址。LWIP 内部协议要利用该首地址来查找完成相关超时事件。 其其其次,如果 LWIP 是建立在多线程操作系统之上的话,则要实现创建一个新线程的 函数。不支持多线程的操作系统,汗…表示还没听过。不过 UC/OSII 显然是支持多线程的, 地球人都知道。这样一个典型的 LWIP 应用系统包括这样的三个进程:首先启动的是上层应 用程序进程,然后是 LWIP 协议栈进程,最后是底层硬件数据包接收发送进程。通常 LWIP 协议栈进程是在应用程序中调用 LWIP 协议栈初始化函数来创建的。注意 LWIP 协议栈进程 一般具有最高的优先级,以便实时正确的对数据进行响应。 其其其其次,其他一些细节之处。比如临界区保护函数,用于 LWIP 协议栈处理某些临 界区时使用,一般通过进临界区关中断、出临界区开中断的方式来实现;又如结构体定义时 用到的结构体封装宏,LWIP 的实现基于这样一种机制,即上层协议已经明确知道了下层所 传上来的数据的结构特点,上层直接使用相关取地址计算得到想要的数据,而避免了数据递 交时的复制与缓冲,所以定义结构体封装宏,禁止编译器的地址自动对齐是必须的;还有诸 如调试输出、测量记录方面的宏不做讲解。 最后,也是比较重要的地方。底层网络驱动函数的实现。这取决于你嵌入式硬件系统 所使用的网络接口芯片,也就是网卡芯片,常见的有 RTL8201BL、ENC28J60 等等。不同的 接口芯片厂商都会提供丰富的驱动函数。我们只要将这些发送接收接口函数做相应的封装, 将接收到得数据包封装为 LWIP 协议栈熟悉的数据结构、将发送的数据包分解为芯片熟悉的 数据结构就基本搞定了。最起码的,发送一个数据包函数和接收一个数据包函数需要被实现。 那就这样了吧,虽然写得草草,但终于在撤退之前搞定。好的开始是成功的一半,那 这暂且先算四分之一吧。不晓得一个月、两个月或者更多时间能写完否。预知后事如何,请 见下回分解。 E-mail:for_rest@foxmail.com 老衲五木出品
2 动态内存管理 动态内存管理 动态内存管理 动态内存管理 最近电力局很不给力啊,隔三差五的停电,害得我们老是痛苦的双扣斗地主,不带这样 的啊!今天还写吗?写,必须的。 昨天把 LWIP 的移植工作框架说了一下,网上也有一大筐的关于移植细节的文档。有兴 趣的童鞋不妨去找找。这里,我很想探究 LWIP 内部协议实现的细节,以及所有盘根错节的 问题的来龙去脉。以后的讨论研究将按照 LWIP 英文说明文档《Design and Implementation of the LWIP:TCP/IP Stack》的结构组织展开。 这里讨论 LWIP 的动态内存管理机制。 总的来说,LWIP 的动态内存管理机制可以有三种:C 运行时库自带的内存分配策略、 动态内存堆(HEAP)分配策略和动态内存池(POOL)分配策略。 动态内存堆分配策略和 C 运行时库自带的内存分配策略具有很大的相似性,这是 LWIP 模拟运行时库分配策略实现的。这两种策略使用者只能从中选择一种,这通过头文件 lwippools.h 中的宏定义 MEM_LIBC_MALLOC 来实现的,当它被定义为 1 时则使用标准 C 运行时库自带的内存分配策略,而为 0 时则使用 LWIP 自身的动态内存堆分配策略。一般情 况下,我们选择使用 LWIP 自身的动态内存堆分配策略,这里不对 C 运行时库自带的内存分 配策略进行讨论。 同时,动态内存堆分配策略可以有两种实现方式,纠结….第一种就是如前所述的通过 开辟一个内存堆,然后通过模拟 C 运行时库的内存分配策略来实现。第二种就是通过动态 内存池的方式来实现,也即动态内存堆分配函数通过简单调用动态内存池(POOL)分配函数 来完成其功能(太敷衍了事了),在这种情况下,用户需要在头文件 lwippools.h 中定义宏 MEM_USE_POOLS 和 MEM_USE_CUSTOM_POOLS 为 1,同时还要开辟一些额外的缓冲池 区,如下: LWIP_MALLOC_MEMPOOL_START LWIP_MALLOC_MEMPOOL(20, 256) LWIP_MALLOC_MEMPOOL(10, 512) LWIP_MALLOC_MEMPOOL(5, 1512) LWIP_MALLOC_MEMPOOL_END 这几句摘自 LWIP 源码注释部分,表示为动态内存堆相关功能函数分配 20 个 256 字节 长度的内存块,10 个 512 字节的内存块,5 个 1512 字节的内存块。内存池管理会根据以上 的宏自动在内存中静态定义一个大片内存用于内存池。在内存分配申请的时候,自动根据所 请 求 的 大 小 , 选 择 最 适 合 他 长 度 的 池 里 面 去 申 请 , 如 果 启 用 宏 MEM_USE_POOLS_TRY_BIGGER_POOL,那么,如果上述的最适合长度的池中没有空间 可以用了,分配器将从更大长度的池中去申请,不过这样会浪费更多的内存。晕乎乎…..就 这样了,这种方式一般不会被用到。哎,就最后这句话给力。 下面讨论动态内存堆分配策略的第一种实现方式,这也是一般情况下被使用的方式。这 部分讨论主要参照网上 Oldtom’s Blog,TA 写得很好(但是也有一点小小的错误),所以一不 小心被我借用了。 动态内存堆分配策略原理就是在一个事先定义好大小的内存块中进行管理,其内存分配 的策略是采用最快合适(First Fit)方式,只要找到一个比所请求的内存大的空闲块,就从 中切割出合适的块,并把剩余的部分返回到动态内存堆中。分配的内存块有个最小大小的限 E-mail:for_rest@foxmail.com 老衲五木出品
制,要求请求的分配大小不能小于 MIN_SIZE,否则请求会被分配到 MIN_SIZE 大小的内存 空间。一般 MIN_SIZE 为 12 字节,在这 12 个字节中前几个字节会存放内存分配器管理用 的私有数据,该数据区不能被用户程序修改,否则导致致命问题。内存释放的过程是相反的 过程,但分配器会查看该节点前后相邻的内存块是否空闲,如果空闲则合并成一个大的内存 空闲块。采用这种分配策略,其优点就是内存浪费小,比较简单,适合用于小内存的管理, 其缺点就是如果频繁的动态分配和释放,可能会造成严重的内存碎片,如果在碎片情况严重 的话,可能会导致内存分配不成功。对于动态内存的使用,比较推荐的方法就是分配->释放 ->分配->释放,这种使用方法能够减少内存碎片。下面具体来看看 LWIP 是怎么来实现这些 函数的。 mem_init( ) 内存堆的初始化函数,主要是告知内存堆的起止地址,以及初始化空闲列 表,由 lwip 初始化时自己调用,该接口为内部私有接口,不对用户层开放。 mem_malloc( ) 申请分配内存。将总共需要的字节数作为参数传递给该函数,返回值是 指向最新分配的内存的指针,而如果内存没有分配好,则返回值是 NULL,分配的空间大小 会收到内存对齐的影响,可能会比申请的略大。返回的内存是“没有“初始化的。这块内存 可能包含任何随机的垃圾,你可以马上用有效数据或者至少是用零来初始化这块内存。内存 的分配和释放,不能在中断函数里面进行。内存堆是全局变量,因此内存的申请、释放操作 做了线程安全保护,如果有多个线程在同时进行内存申请和释放,那么可能会因为信号量的 等待而导致申请耗时较长。 mem_calloc( ) 是对 mem_malloc( )函数的简单包装,他有两个参数,分别为元素的数目 和每个元素的大小,这两个参数的乘积就是要分配的内存空间的大小,与 mem_malloc()不 同的是它会把动态分配的内存清零。有经验的程序员更喜欢使用 mem_ calloc (),因为这样 的话新分配内存的内容就不会有什么问题,调用 mem_ calloc ()肯定会清 0,并且可以避免 调用 memset()。 休息………… 动态内存池(POOL)分配策略可以说是一个比较笨的分配策略了,但其分配策略实现简 单,内存的分配、释放效率高,可以有效防止内存碎片的产生。不过,他的缺点是会浪费部 分内存。 为什么叫 POOL?这点很有趣,POOL 有很多种,而这点依赖于用户配置 LWIP 的方式。 例如用户在头文件 opt.h 文件中定义 LWIP_UDP 为 1,则在编译的时候与 UDP 类型内存池 就会被建立;定义 LWIP_TCP 为 1,则在编译的时候与 TCP 类型内存池就会被建立。另外, 还有很多其他类型的内存池,如专门存放网络包数据信息的 PBUF_POOL、还有上面讲解动 态内存堆分配策略时提到的 CUSTOM_POOLS 等等等等。某种类型的 POOL 其单个大小是 固定的,而分配该类 POOL 的个数是可以用户配置的,用户应该根据协议栈实际使用状况 进行配置。把协议栈中所有的 POOL 挨个放到一起,并把它们放在一片连续的内存区域, 这呈现给用户的就是一个大的缓冲池。所以,所谓的缓冲池的内部组织应该是这样的:开始 处放了 A 类型的 POOL 池 a 个,紧接着放上 B 类型的 POOL 池 b 个,再接着放上 C 类型的 POOL 池 c 个….直至最后 N 类型的 POOL 池 n 个。这一点很像 UC/OSII 中进程控制块和事 件控制块,先开辟一堆各种类型的放那,你要用直接来取就是了。注意,这里的分配必须是 以单个缓冲池为基本单位的,在这样的情况下,可能导致内存浪费的情况。这是很明显的啊, 不解释。 下面我来看看在 LWIP 实现中是怎么开辟出上面所论述的大大的缓冲池的(‘的’这个字, 今天让我们一群人笑了很久)。基本上绝大部分人看到这部分代码都会被打得晕头转向,完 全不晓得作者是在干啥,但是仔细理解后,你不得不佩服作者超凡脱俗的代码写能力,差一 点用了沉鱼落雁这个词,罪过。上代码: E-mail:for_rest@foxmail.com 老衲五木出品
static u8_t memp_memory [[[[ MEM_ALIGNMENT static u8_t memp_memory MEM_ALIGNMENT ---- 1 1 1 1 MEM_ALIGNMENT static u8_t memp_memory static u8_t memp_memory MEM_ALIGNMENT #define LWIP_MEMPOOL(name,num,size,desc) + ( (num) * (MEMP_SIZE + MEMP_ALIGN_SIZE(size) ) ) #define LWIP_MEMPOOL(name,num,size,desc) + ( (num) * (MEMP_SIZE + MEMP_ALIGN_SIZE(size) ) ) #define LWIP_MEMPOOL(name,num,size,desc) + #define LWIP_MEMPOOL(name,num,size,desc) + ( (num) * (MEMP_SIZE + MEMP_ALIGN_SIZE(size) ) ) ( (num) * (MEMP_SIZE + MEMP_ALIGN_SIZE(size) ) ) #include "lwip/memp_std.h" #include "lwip/memp_std.h" #include "lwip/memp_std.h" #include "lwip/memp_std.h" ]; 上面的代码定义了缓冲池所使用的内存缓冲区,很多人肯定会怀疑这到底是不是一个数组的 定义。定义一个数组,里面居然还有 define 和 include 关键字。解决问题的关键就在于头文 件 memp_std.h,它里面的东西可以被简化为诸多条 LWIP_MEMPOOL(name,num,size,desc)。 又由于用了 define 关键字将 LWIP_MEMPOOL(name,num,size,desc)定义为 +((num) * (MEMP_SIZE + MEMP_ALIGN_SIZE(size))),所以,memp_std.h 被编译后就为一 条一条的+(),+(),+(),+()….所以最终的数组 memp_memory 等价定义为: static u8_t memp_memory [ MEM_ALIGNMENT – 1 +() +()….]; 如果此刻你还没懂,只能说明我的表述能力有问题了。当然还有个小小的遗留问题,为什么 数组要比实际需要的大 MEM_ALIGNMENT – 1?作者考虑的是编译器的字对齐问题,到此 打住,这个问题不能深究啊,以后慢慢讲。 复制上面的数组建立的方法,协议栈还建立了一些与缓冲池管理的全局变量: memp_num:这个静态数组用于保存各种类型缓冲池的成员数目 memp_sizes:这个静态数组用于保存各种类型缓冲池的结构大小 memp_tab:这个指针数组用于指向各种类型缓冲池当前空闲节点 接下来就是理所当然的实现函数了: memp_init():内存池的初始化,主要是为每种内存池建立链表 memp_tab,其链表是逆序 的,此外,如果有统计功能使能的话,也把记录了各种内存池的数目。 memp_malloc():如果相应的 memp_tab 链表还有空闲的节点,则从中切出一个节点返回, 否则返回空。 memp_free():把释放的节点添加到相应的链表 memp_tab 头上。 从上面的三个函数可以看出,动态内存池分配过程时相当的简洁直观啊。 HC:百度说是胡扯的意思。哈哈…… E-mail:for_rest@foxmail.com 老衲五木出品
分享到:
收藏