这个标题起得比较纠结,之前熟知的PPPOE是作为PPP协议的底层载体,而实际上它也是一个完整的协议,不过它的实现比较简单,由它出发,可以很容易理清楚Linux网络栈的实现方式。
Linux中用户空间的网络编程,是以socket为接口,一般创建一个sockfd = socket(family,type,protocol),之后以该sockfd为参数,进行各种系统调用来实现网络通信功能。其中family指明使用哪种协议域(如INET、UNIX等),protocol指明该协议域中具体哪种协议(如INET中的TCP、UDP等),type表明该接口的类型(如STREAM、DGRAM等),一般设protocol=0,那么就会用该family中该type类型的默认协议(如INET中的STREAM默认就是TCP协议)。
Linux中利用module机制,层次分明地实现了这套协议体系,并具有很好的扩展性,其基本模块构成如下:
先看右边,顶层的socket模块提供一个sock_register()函数,供各个协议域模块使用,在全局的net_family[]数组中增加一项;各个协议域模块也提供一个类似的register_xx_proto()函数,供各个具体的协议使用,在该协议域私有的xx_proto[]数组中增加一项。这两个数组中的存放的都是指针,指向的数据结构如下图所示:
很明显它们是用来创建不同类型的socket接口的,且是一种分层次的创建过程,可想而知,顶层socket_create()完成一些共有的操作,如分配内存等,然后调用下一层create;协议域内的create()完成一些该协议域内共有的初始化工作;最后具体协议中的create()完成协议特有的初始化。具体的下一节讲。
再来看上图右边的,也是顶层socket模块提供的4个函数,前两个一般由具体协议模块调用,由于协议栈与应用层的交互,具体的后面会讲到。后两个一般有协议域模块调用,用于底层设备与协议栈间的交互。但这也不绝对,如在PPPOE协议中,这4个函数都由具体协议模块调用,这是因为PPPOX协议域内的共有部分不多,各个协议间几乎独立。这4个函数的功能及所用到的数据结构,在后面具体用到时会详细说明。
首先来看一下最终创建好的socket插口由哪些部分组成,该结构是相当庞大的,这里只给出框架:
创建的总体过程,第一节已讲过了,下面以pppoe为例,描述一个socket插口的具体创建过程:
之前所述的关键点这里几乎都涉及到了,要注意的是这里的struct proto结构非常简单,因为PPPOE协议几乎没有传输层,所以不需要有太多的中间操作,仅需要一个obj_size来指明struct sock结构后需分配的私有结构大小,关于私有结构的内容,一般在connect操作时才能初始化。
创建好socket之后,其中的fops,proto_ops,sk_backlog_rcv等操作是如何作用,来实现网络通信的功能?这是后面要讲述的内容。
主动过程即在应用层中通过系统调用,触发socket完成某种动作,有些系统调用和标准的文件操作类似,因此可以直接用sockfd的fops来描述,如read、write、ioctl等,有些则是socket接口特有的,需重新定义系统调用接口,Linux中用SYSCALL_DEFINEn()宏来定义系统调用接口,如bind、accept等。这些系统调用一般都很简单,最终都会去调用socket内部proto_ops中的接口函数。
如下图所示,在socket层,并不是所有的文件操作都适用于socket,因此其特有的socket_file_ops中只指定了部分函数;另外还封装了几个系统调用,是我们熟悉的bind、listen、connect、accept。这些系统调用接口都是静态的,它们一般经过简单的处理,就调用具体socket中的proto_ops操作。
在协议栈中,主要是socket特有的proto_ops操作,但对于一些复杂的协议,如TCP,还需要其它一些操作来支持,这些接口都放在struct sock中的struct proto中。PPPOE协议比较简单,不需要struct proto的操作来支持,但其中的obj_size仍然重要,如前所述。
如上图所示,PPPOE协议中,并不是所有协议操作都需要,如bind、accept等,下面选几个来详细看一下socket的主动过程的工作。
Ioctl系统调用:ioctl是通过标准的文件操作来调用的,具体如下图所示:
其中顶层sock_ioctl中,对于一些特殊情况,如VLAN、BRIDGE等,它们并不是要对socket插口本身操作,而是要调用VLAN、BRIDGE模块中的创建函数,这看起来有点格格不入,但为了操作方便,且保证网络相关的操作都封装在socket中,这么做也是不得已。
在pppoe_ioctl中,根据cmd进行相应操作,其中有一个值得注意的,就是PPPIOCGCHAN选项,它使得该pppoe_socket成为一个特殊的channel,这主要是pppoe为了给ppp协议提供服务而特有的,与网络协议栈关系不大,以后会具体看。
Read系统调用:read也是标准的文件操作,但要注意,在网络栈中,read并不是接收过程,而仅是从该sock的接收队列中取出skb,提交给应用层,如下图所示。而这些skb是如何获得的,那是一个复杂的被动过程,下面再讲。
Connect系统调用:connect是socket.c中封装的一个系统特用,其代码也很简单,最终调用协议栈中的pppoe_connect接口,该接口函数是pppoe协议中一个非常重要的操作,具体如下图所示:
首先先一下通配地址的问题,这是network programming中一个基本问题,因为各个协议用到的地址结构不同,在应用层,为了方便可读性,可以用协议特有的地址结构,只要符标准的模式即可(即第一个元素为family),然后强制转换成sockaddr*类型,传递给通用的系统调用接口。在最终调用协议模块中的接口函数时,再转换回来。
再看pppoe_connect中,首先由sock结构指针得到pn指针,它们是分配在一起的(如前所述),这很容易得到,同时还得到pppoe_net结构的指针(它是该协议中全局共有的)。然后把用户传递进来的addr的数据放到socket中来,并且执行一个set_item函数,该函数主要根据addr信息,把该socket指针放到协议全局的pppoe_net结构中(这一步对接收过程很重要,后面会细讲)。最后初始化了该socket中特有的chan结构,并调用ppp_register_net_channel(),这主要为ppp服务,以后再看。
这也是一个主动过程,在协议体系中,它是一个比较重要的过程,所以单独列出来。Socket框架中,发送过程是通过标准的文件操作write完成的, socket的write操作为sock_aio_write(),最终会调用proto_ops->sendmsg()函数,即pppoe模块中的pppoe_sendmsg(),如下图所示:
首先从sock中获得相关信息,最重要的当然是dev设备,因为pppoe的设备是选定的(由useraddr提供),而有些协议如IP,则会根据协议地址,有协议栈自动选择dev。然后分配skb,并准备其中的package,这是每个协议的关键,由于pppoe协议很简单,只需要设置好一个pppoe header即可。最后直接调用dev_queue_xmit(skb),通过设备将该package发送出去。
这里想讲一下的是,pppoe到底是什么层的协议,链路层。而通过上面的描述,更准确的说法应该是,pppoe是一个完整的协议,是从应用层到设备之间的协议模块,从这个意义上来讲,它和INET域中的协议是等价的。如下图所示:
这里讲的协议是从应用层往下直到物理设备的完整过程,有些协议具有一定的相似性,(如TCP、UDP,还包括裸IP等都以IP协议为基础),则把它们归为一个协议域内。至于协议分层,则是概念上的,如PPPOE协议的主要功能体现在链路层,则一般称它为链路层协议, 而狭义上称TCP、UDP为传输层协议(而前面讲的广义上的TCP、UDP则是包括传输层、以IP为基础的网络层、链路层的完整协议)。
有点饶人,不过没关系,只要理解协议栈的功能就是从socket接口得到数据,封装成一定的包结构,最终由物理设备发送出去(接收过程反过来)。至于具体的实现,则是由具体协议的特点决定的,对于一些复杂协议,分层方式则是一种比较好的选择。
而其中有些协议会比较特殊,如之前讲的VLAN,它甚至从来都不会进入到协议栈,仅在设备驱动层,就被转化成以太网协议,协议栈中根本不需要为它准备处理接口。再如比较典型的ICMP协议,它既可以是一个完整的协议,被应用层调用(如典型的Ping程序),也可以只作为TCP的附属协议(只被TCP处理,对应用层不可见)。这里的PPPOE与此很类似,本文讲述了其作为完整协议的工作方式,另外它也可以作为PPP协议的底层基础,在下一篇中会讲述其具体的实现方法。
接收过程是一个被动过程,在屋里设备层,它往往是由中断触发,其实现的复杂度也较发送过程高很多。在协议栈中,其实现也同样与发送过程很不对称。因为发送时,本身主机拥有控制权,而接收时,是一个数据包对多个接收模块(一对多),只能从数据包中的信息中一点一点分析,并去寻找接收模块。
先给出接收流程的框架,再逐步去分析其实现。如下图所示:
先不看橙色部分,一个接收流程由物理设备的中断触发,设备驱动程序进行相应处理,得到协议栈中标准的数据结构sk_buff(简称skb),并根据一个特殊的全局数据结构packet_type,将数据交给相应的协议;协议根据自身设计特点对skb数据进行处理,并通过全局变量xx_net_id和各个协议私有的特殊数据结构xx_net,寻找到该数据包对应的应用层socket插口,并将其放在该socket插口的接收队列中;最后应用层在某个时刻会通过read系统调用读取该数据(如第3节所讲)。
设备驱动层的接收过程在之前的篇章中已经讲过了,一般是由硬件中断触发,然后或是采用中断模式、或是采用NAPI模式,总之其根本任务就是:根据设备的特点(先验知识,如以太网设备驱动事先就是知道以太网帧的基本结构的),将接收到的裸数据转换成协议栈所认识的标准结构skb(从而实现底层设备对上层的透明性),然后提交给相应的协议。很明显问题有两个,skb是什么样的,要准备什么?怎么知道提交给谁?
准备skb结构。首先来看一下sk_buff的构成,如下图所示。Skb只是一个控制结构,实际的数据放在一个data_buf中,并由skb中一些列参数索引,具体见下图右所示,这之中有些参数是在分配data_buf、copy数据时就决定的,如head、end、data、tail等;有些则要经过一定的识别才能得到,如mac_header一般在设备驱动中得到,而network_header、transport_header则要到协议栈中才知道,且各个协议的处理各不相同,如PPPOE协议根本不需要只需要指明network_header,而TCP协议则有复杂的头部信息。最终由skb->data指针和头部长可得到app_data的位置,因此应用层可以只读取应用数据即可。
Skb中另外一些参数也相当重要,如vlan_tci用于指明vlan的id,其用法在前面已讲过。dev参数则是要贯穿整个流程的,因为该庞大结构中的多个信息会在整个网络系统中用到,要注意的是该参数由设备驱动程序决定,一般就是接收的物理设备,但在Linux中,网络设备是由net_device结构指示的,一个物理设备可有多个协议设备,这在VLAN、BRIDGE中很明显,其实在PPP协议中,这也是一个关键点,后面会讲到。Sk参数指示了该数据包属于哪个应用层socket插口,它由具体协议根据特定方法得到,后面会讲到。Protocol参数是本节的重点,它由mac_header中的字节决定。
设备驱动程序只关心mac_header,即数据包最初始的部分。前面也提到了,这需要一定的先验知识,如ethernet设备驱动,它先验的指导以太网头部由DMAC、SMAC和两字节的协议构成,下面是一个RTL8012驱动的接收片段(~/dev/net/Ethernet/realtek/apt.c):
提交协议栈。主要就是根据skb->protocol参数,当然还需要另一个重要的数据结构packet_type。
设备驱动中最后提交过程有netif_skb_receive()函数完成,它会遍历系统中所有的packet_type,找到protocol和dev(这个是啥意思)都相同,就调用该ptype中的func函数,如ip_packet中的func为ip_rcv()函数,这样skb就到了协议栈中。
系统中所有全局的packet_type构成一个list,并由全局变量ptype_all索引,另外还提供ptype_base[]全局数组,将type相同的packet_type单独成链,为遍历提供方便。
这些全局的packet_type结构是从哪来的,这就要看第一节图中,左边4个函数中的一个dev_add_packet(struct packet_type*)。协议模块在加载时,调用该函数,将自己特有的packet_type结构注册进内核中,而其中的(*func)则有协议自己定义。
最后要注意的是,打开if_ether.h文件,可以看到现在已定义的协议protocol有_P_IP、_P_ARP、_P_8021Q、_P_PPP_SES、_P_PPP_DIS等,如果根据传统的分层协议来看它们,会觉得很乱,有网络层的、链路层的、甚至同一种协议还有两个,但如果用第5节的概念来看,则很容易理解。再看由什么模块注册,TCP、UDP都是以IP协议为基础,只要有INET协议域模块注册一个即可,而ARP虽然也属于INET域,但它却必须自己有一个packet_type,PPPOE协议虽然只是一个协议,但却有两个阶段,所以它有两个不同的packet_tpye。可见这种实现是很灵活的,根据具体协议的特点决定。
协议栈的处理由各协议决定,如TCP协议的处理过程是相当复杂的,而这里的pppoe的处理却非常简单,但由它却可以避开细节,更清楚地看到流程的梗概,如下图所示:
可以看到pppoe协议的处理过程几乎没有,仅是设置了skb的network_header, transport_header,然后就利用get_item()函数找到它所属的socket插口,直接把它提交给上层。如上图右所示,是典型的TCP接收流程,是相当复杂的,其中TCP与IP的接头处还需用到额外的私有数据结构。
提交函数sk_backlog_rcv,即这里的pppoe_rcv_core(sk,skb)函数,首先判断是否为ppp通道的数据,若是则提交给ppp协议。一般正常情况下,直接用sock_queue_rcv_skb(sk,skb)函数将它放在socket的接收队列中。
匹配应用层接口:协议栈在对数据包进行处理后,需要确定该包属于哪个socket插口,这个过程在内核中有一套完整的机制来完成,其框架如下图所示:
首先内核有个全局结构net_generic,其中一个最重要的元素是指针数组。然后每个协议module加载时,会调用register_pernet_device(struct pernet_operations*)(见第一节图),pernet_operations结构中最关键的两个参数,一个是size,它指示内核为该模块分配一个私有数据结构(如pppoe即为struct pppoe_net),另一个是xx_net_id,它指示由net_generic.ptr[xx_net_id]来指向该数据结构,这样每个协议模块中,就可以根据自己的xx_net_id很容易寻找到内核分配给自己的私有结构。最后协议的私有模块中一般也有一个指针数组,用以索引属于它的各个socket。
工作流程就很清楚了,具体的工作方式还要看两个函数,
就不看细节了,仅看两个函数的原型就能明白,其中pn参数就是上面所述的用全局结构net_generic和各协议私有xx_net_id获得的。Set_item()函数在connect时调用(参见第3节),它根据pppox_sock中的sessionID、remoteMAC(这两个参数由*useraddr传入,详见下一篇协议分析),根据一个hash算法得到一个hashInt值,然后用pn->hash_ptr[hashInt]指向该socket结构。那反过来,接收时由这两个参数(由数据包的协议头中获得)得到hashInt,便能很容易找到对应的socket了。
各个协议使用的方法及参数都不同,但思路都一样,就是依据协议本身特有的参数(如TCP中的连接4元组),在socket创建、或连接的时候(接收数据之前),根据一定的算法,将它的指针放在该协议私有的xx_net中,这样接收时就可以由数据报的协议参数找到它了。
上述的socket索引方法有个绕弯的地方:就是每个协议私有的xx_net结构可以直接由协议模块本身分配,索引起来也方便,不要用到全局的net_generic。而目前内核所用的方法,其实是为了另外的目的,那就是命名空间namespace。也就是虚拟多用户的一套机制,具体的也没细看,好像目前内核整个namespace还没有全部完成。
network的命名空间问题主要在于,每个协议模块的xx_net私有结构不仅是一个,而是由内核全局决定的,即每注册一个新的用户(有点像虚拟机机制),就分配一个新的xx_net结构,这样多用户间可以用参数相同的socket连接,但却指向不同的socket。
可以看到前面所述的很多内容中,都会有个net参数,就是为了这个作用,主要实现函数在namespace.c中。
主要结合pppoe协议,学习了Linux中网络栈的实现。由于pppoe协议本身很简单,代码量少,更容易抓住协议实现的梗概。Linux网络栈,继承Unix,采用socket插口作为主线,主要包括创建、协议连接、主动过程、匹配机制、被动过程等内容。
要注意的是,实际应用中,很少有直接利用pppoe协议通信的,而是把它作为ppp协议的底层基础来用,而这需要协议实现中的一些技巧来支持,下一篇中讲述。