【 tulaoshi.com - Linux 】
对于不了解内核的，特别是内核网络的人来说，内核的网路处理就像一个巧克力盒子。不打开就不会知道里面是什么，打开了就会觉得里面是丰富多彩的。 本文试图从一个原始数据包处理流程的角度，结合源代码（相应的函数）简单扼要地分析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， |
