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，
          |                    一个数据包出现。剥离 ether_header 后，调用
          |                    ether_input(ifp, eh, m)
          |                     
       if_ethersubr.c      <-- ether_input:
                                 a. 一定要获取 ether_header，拿不到就释放 mbuf
                                    丢掉这个包。
                                    后续的处理中，该数据包随时面临着被丢弃的危险
                                 b. bpf想要看看这个包，那就给他看看，反正他不会
                                    更改这个包，tcpdump可以通过bpf看到这个包
                                 c. netgraph也要处理吗，呜，处理就处理，不怕。
                                    netgraph是FreeBSD独特的网络处理?椋

责任编辑 webmaster

相关链接

网络商城多用户商城模版购物网...

Linux之抢占式内核

Linux内核汉字显示技术

如何利用Google的WebService搜...

关注七项Linux内核发展方向

空间数据网络渐进传输算法研究

网络编程之C10K问题

Linux网络编程:加密通讯协议S...