HTTP服务器之嵌入式负载平衡路由器实战(2)

三．系统架构与实作

　　图四是我们的系统环境，所有http的要求都会被DNS导向到Web Switch上，Web Switch扮演分配流量(Load Dispatcher)的角色，将所有的要求都平衡到LAN端的四台Web Node，Web Node计算完的结果再经由Web Switch传送回WAN端。所以我们要在接收封包时执行以下的动作：

　　A. 拦截送到Web Switch的http要求。

　　B. 根据演算法算出执行此要求的Web Node。

　　C. 将http要求转送到该Web Node。

　　D. 根据后端的回应来更新后端Web Node的资讯。

系统主体模组部份

　　图五介绍vLinux原本接收封包的流程，由驱动程式到TCP层。 因为http是在TCP之上的协定，所以我们必须看到TCP的表头里的port号码才可以判断这个封包是否属于某一个http的要求。但是我们又不想在TCP层解决这个问题，因为TCP是一个很复杂的协定，要在一两个月内看懂TCP的程式码是一件非常困难的事情。相对于TCP来说，IP就是一个单纯的协定，所以我们决定将所有转送的工作在IP层完成，也就是说我们要在IP层偷看TCP的资讯。从图五我们可以很清楚地知道当核心在ip_local_deliver()里，因为要准备将封包往TCP传，所以我们得到的就是一个带有IP表头的TCP封包(如图六)，所以在IP层亦可以偷看到TCP层的资讯。

　　知道了TCP的port号码后，我们便可以很轻易的将封包拦截下来，完成A步骤。接下来就是要如何将这个封包传给演算法决定的Web Node呢？图七就是经过我们修改后的封包流程图。我们在ip_local_deliver()中加入一个封包过滤器(packet filter)来过滤出http要求的封包，再经由封包转送器(packet forwarder)将这些封包转送到后端的Web Node。封包转送器做的事情依序来讲就是改写封包档头、重新计算checksum、查询路由表更新路径及分割封包。

图七 修改后的接收封包流程图

流量控制模组部份

　　在这个部份最主要的就是我们提出的负载平衡演算法。图八是我们的演算法架构，虚线表示的是存取动作；实线是封包的路径。因为MCU处理速度不快，我们将演算法全部都实作在vLinux的kernel level，可以增加整个演算法的效能。并且因为是由PowerNet-AP自动纪录转送的对应表格，所以不管是对后端的伺服器、前端的客户或是DNS都不需作修改。负载平衡演算法(Load Balance Algorithm)维护了两个表格：

　　转送资讯表(Forward Info Table)：纪录前端的客户和后端伺服器的对应，以维护TCP的连线。

　　负载资讯表(Load Info Table)：纪录后端伺服器的负载资讯，例如目前的连线数目和封包的回应时间，作为决定转送对象的参考。

　　当http要求的封包进入Web Switch时，都需要查询转送资讯表来确定下一步这个封包的目的地，所以操作转送资讯表的动作必须要非常有效率，才能负担大量的网路交通。负载资讯表根据演算法的不同可以存放不同的资料，更新的时机也是由演算法决定。接下来我们会分别讨论这两个表格的实作。