对于不了解内核的，特别是内核网络的人来说，内核的网路处理就像一个巧克力盒子。不打开就不会知道里面是什么，打开了就会觉得里面是丰富多彩的。    本文试图从一个原始数据包处理流程的角度，结合源代码（相应的函数）简单扼要地分析FreeBSD的内核网络处理。    主机对主机的方式是比较简单的，数据包从链路层上来，一路上行，达到用户空间的应用程序，一个数据包的生命期就结束了。对于像网关或防火墙之类包转发的方式，处理起来就相对复杂了一些，这也是许多人迷惑不解之处。
    对于不了解内核的，特别是内核网络的人来说，内核的网路处理就像一个巧克力盒子。不打开就不会知道里面是什么，打开了就会觉得里面是丰富多彩的。    本文试图从一个原始数据包处理流程的角度，结合源代码（相应的函数）简单扼要地分析FreeBSD的内核网络处理。    主机对主机的方式是比较简单的，数据包从链路层上来，一路上行，达到用户空间的应用程序，一个数据包的生命期就结束了。对于像网关或防火墙之类包转发的方式，处理起来就相对复杂了一些，这也是许多人迷惑不解之处。    上面是开场白，接下来就转入正题。    老规矩，先建立场景，场景总是要假设并建立起来的。设：        hostA  --  GW  --  hostB        主机A通过GW互访hostB        谈到数据的通讯，总是双向的，如同2人谈话，如果仅仅是一个人说，那就成了演讲--广播。GW就是扮演了一个传递员的角色，将2人的话传来传去，粗俗的话，优化的GW或防火墙十有八九是不传的，免得制造矛盾。    对于主机如何产生包，本文不作详细讨论。关心此项内容的，可以参见tcp/udp处理以及内核中的socket等系统调用。本文的重点放在GW上，分析GW是如何处理转发数据包的。    hostA 想要访问hostB的ftp(21端口)：    0. 先广播询问并获得网关的MAC地址。谁是网关，速速报来!!!    1. 连接hostB的ftp端口    2. 成功后，发送数据包    ....    hostA找到网关的MAC地址后，发往非本网段的数据包的目标 MAC地址都是网关的 MAC地址但目标 IP地址不是网关的。                下面就看看GW都作了哪些工作        1. GW听到一个包             NIC               <-- 硬中断发生了，          |                    调用驱动的rxeof函数。包处理开始。对于polling          |                    方式，是cpu主动去网卡读包，这样硬中断数会少，          |                    但是如果处理不及时，数据包就丢了。对于小包，而          |                    且网卡芯片上的buf很大时，polling方式的好处就很          |                    大了。反过来，在遭受小包攻击时，系统的中断数就          |                    会异常高，这是因为需要不停地响应处理。          |        if_xxx.c            <-- rxeof          |                    m_devget 申请mbuf，从网卡的buf拷贝数据到mbuf，          |