构建基于软流水结构的Web服务器的方法

1、一种构建基于软流水结构的Web服务器的方法，其特征在于：将Web服务器中完 成HTTP请求处理的完整流程依序分解为四个流水栈，每个流水栈内所包含的线程组只完 成HTTP请求处理的特定环节并将控制数据依次传递给与之相连的后序流水栈，前后序的 流水栈之间通过受控内存区传递自洽的控制数据信息，通过数据缓存区对用户所访问的 对象数据进行存储，并利用Socket区来管理用于数据接收和发送的Socket；所述四个流 水栈中的线程组依序为连接线程组、接收线程组、数据处理线程组和发送线程组，且流 水栈完成HTTP请求处理的流程为：
(1)、连接线程组中的任意一个连接线程接受客户的一个新Socket连接请求，并将该 新Socket插入到Socket区中空闲的Socket项中，并且将该项的m_uKeepAlive设置为 KEEP_ALIVE_UNKNOWN状态，同时将m_nTimeoutTicks设置为当前时间，随后在接收线程 组中唤醒一个空闲的接收线程；
(2)、当接收线程被唤醒后，将检测所有的Socket项，首先判断该Socket项的 m_uKeepAlive，如果为KEEP_ALIVE_UNKNOWN或是KEEP_ALIVE_OK的话，则试图接收该 Socket中客户端所发送过来的HTTP请求，并判断该请求的完整性；如果完整的话，则从 受控内存区自由链中抽取头部的一页，分配新受控内存区页，创建一个HTTP请求结构， 并将所接收到的HTTP请求串写入该结构的m_szReqStringGotten域中；随后将该受控内 存区页地址作为一个新任务，写入数据处理线程组的任务队列中，并在数据处理线程组 中唤醒一个空闲的数据处理线程；如果Socket项中m_uKeepAlive的状态为 KEEP_ALIVE_TIMEOUT，则表示该Socket项已超出HTTP协议的Keep-Alive期，不予接受 HTTP请求，并且如果超期过长的话，还应该将该Socket项删除，关闭Socket，释放资 源，并且将状态切换为KEEP_ALIVE_NO；
(3)、当数据处理线程被唤醒之后，即从任务队列中抽取头部的新任务，得到HTTP请 求数据所处的受控内存区页地址，从而得到HTTP请求数据信息；首先依据HTTP协议， 针对m_szReqStringGotten域进行HTTP协议分析，得到HTTP请求结构中的其他域信息； 此时，应该判断该请求的合法性检查，若不合法，则应关闭该Socket，并停止该HTTP 请求的进一步服务；若合法，则进行进一步的访问控制检测，若当前系统不允许该HTTP 请求的访问，也应关闭该Socket，并停止该HTTP请求的进一步服务；若允许访问，则针 对HTTP请求中客户欲访问的URL文件对象，进行相应的文件I/O，获取该文件的属性信 息和实体内容数据，结合HTTP协议头复用技术，生成HTTP响应数据，并存储于数据缓 存区中；随后在发送线程组中唤醒一个空闲的发送线程；
(4)、发送线程被唤醒后，首先从任务队列中抽取头部的新任务，得到HTTP响应控制 信息所处的受控内存区的页地址，从而获知HTTP响应控制信息，进一步得知HTTP响应 数据所处的数据缓存区页地址，从而得到HTTP响应数据信息，以及需要发送的客户地址， 从而发送线程便直接将响应数据向客户端进行发送。
2、根据权利要求1所述的构建基于软流水结构的Web服务器的方法，其特征在于： 所述数据缓存区采用页式机制管理，首先组织10个不同等级的自由页面链，随后将用户 需求的页面数规整为最短分解链，而后在相应的自由页面链上分配。

技术领域\n本发明主要涉及到计算机领域中Web服务器，特指一种构建基于软流水结构的Web 服务器的方法。\n背景技术\n近来Internet上Web应用一直处于爆炸型增长阶段，目前以Web形式发布的信息海 量，种类繁多。因此，用户以Web方式访问信息的频率高，访问数据量大，据统计Web 流量在Internet总流量中的比例已经超过了60％。HTTP请求具有猝发特点，经常以猝发、 自相似流的形式访问Web服务器，高峰时的HTTP请求率超过平均值的8～10倍，故而大 型Web站点经常出于服务器超载的现象。已有研究表明，一般Web用户期望的理想Web 响应时间为1秒，难以忍受超过8-10秒的等待时间；电子商务网站的理想响应时间应在 7秒之内，否则将会损失超过30％的潜在客户。正由于Web应用所具有的规模和访问特性， 必然要求Web服务器具有良好的性能，用于满足客户所需的服务质量。\n从体系结构的角度来分类，可将目前主流的Web服务器划分为三大类，单进程型 (Single Process，SP)、对称多线程型(Symmetrical Multiple Threads，SMT)、非对 称多线程型(Asymmetrical Multiple Threads，AMT)等。\n单进程型Web服务器由单个进程负责多个链接的联结和监听，完成每个用户请求的接 收、分析和处理，以及响应数据的发送等所有环节。为提高服务器的处理能力，此类服 务器一般都采用非阻塞I/O操作以及I/O复用技术。该类服务器避免了进程间通讯和进 程切换现场的开销，但可扩展性不强。此类结构的典型服务器有zeus， micro-server(μserver)，IIS等。\n对称多线程型在单线程型的基础上加以改进，提供多个进程或是线程用于任务处理， 每个进程/线程独立完成一个请求的全部操作步骤，多个进程/线程同时执行，提高服务 器的并行处理能力，提高服务器的性能。所有进程功能和能力完全一样，此类服务器存 在进程/线程之间的调度和切换开销。对于进程/线程的创建和管理机制方面，常用方法 有两种，或每接收到一个新请求，临时创建新进程，处理请求完毕后，删除该线程；或 是事先创建一组进程，每接收一个新请求，则从进程池中分配一个空闲进程用于请求处 理。Apache和KNOT系统是典型的对称多进程型结构。\n非对称多线程型体系结构则以Flash服务器为典型代表。该类服务器除了传统的请求 处理线程外，还包括若干专门进行I/O的辅助线程。每个用户请求首先由一个进程执行 操作，若该进程需要设备I/O时，则将该项I/O操作转交给辅助线程接着执行，本线程 将转为处理其它的客户请求。这样的结构能有效减少线程的阻塞时间，提高服务效率。 但线程和辅助线程之间存在IPC通讯，增加了系统通讯开销。本质上，除却辅助线程外， 该类型的Web服务器所使用的工作线程同样是对称或是同构的。\n总而言之，目前Web服务器均采用对称或是同构结构，即所有的线程功能完全相同， 具有同等能力，独立或在辅助线程的帮助下完成Web请求的全过程。此类的Web服务器 具有任务间并行的能力，并行的粒度是任务，即Web请求。易知，该体系结构的Web服 务器处理单个Web请求中各环节是串行的，如果某个环节被阻塞，则整个任务必然停止。 更关键的是，作为有限资源的线程也会被阻塞，从而极大浪费资源。\n发明内容\n本发明要解决的技术问题就在于：针对现有技术存在的技术问题，提供一种构建基 于软流水结构的Web服务器的方法，并将之高效实现，得到高性能的Web服务器，从而 能够降低Web请求处理的并发粒度，提高服务器的并行处理能力，使之能高性能、稳定 地运行于服务器平台，满足高负载的Web环境需求。\n为了解决上述技术问题，本发明提出的解决方案为：一种构建基于软流水结构的Web 服务器的方法，其特征在于：将Web服务器中完成HTTP请求处理的完整流程依序分解为 四个流水栈，每个流水栈内所包含的线程组只完成HTTP请求处理的特定环节并将控制数 据依次传递给与之相连的后序流水栈，前后序的流水栈之间通过受控内存区传递自洽的 控制数据信息，通过数据缓存区对用户所访问的对象数据进行存储，并利用Socket区来 管理用于数据接收和发送的Socket；\n所述四个流水栈中的线程组依序为连接线程组、接收线程组、数据处理线程组和发 送线程组，且流水栈完成HTTP请求处理的流程为：\n(1)、连接线程组中的任意一个连接线程接受客户的一个新Socket连接请求，并将该 新Socket插入到Socket区中空闲的Socket项中，并且将该项的m_uKeepAlive设置为 KEEP_ALIVE_UNKNOWN状态，同时将m_nTimeoutTicks设置为当前时间，随后在接收线程 组中唤醒一个空闲的接收线程；\n(2)、当接收线程被唤醒后，将检测所有的Socket项，首先判断该Socket项的 m_uKeepAlive，如果为KEEP_ALIVE_UNKNOWN或是KEEP_ALIVE_OK的话，则试图接收该 Socket中客户端所发送过来的Http请求，并判断该请求的完整性；如果完整的话，则从 受控内存区自由链中抽取头部的一页，分配新受控内存区页，创建一个HTTP请求结构， 并将所接收到的HTTP请求串写入该结构的m_szReqStringGotten域中；随后将该受控内 存区页地址作为一个新任务，写入数据处理线程组的任务队列中，并在数据处理线程组 中唤醒一个空闲的数据处理线程；如果Socket项中m_uKeepAlive的状态为 KEEP_ALIVE_TIMEOUT，则表示该Socket项以超出HTTP协议的Keep-Alive期，不于接收 HTTP请求，并且如果超期过长的话，还应该将该Socket项删除，关闭Socket，释放资 源，并且将状态切换为KEEP_ALIVE_NO；\n(3)、当数据处理线程被唤醒之后，即从任务队列中抽取头部的新任务，得到HTTP请 求数据所处的受控内存区页地址，从而得到HTTP请求数据信息；首先依据HTTP协议， 针对m_szReqStringGotten域进行HTTP协议分析，得到HTTP请求结构中的其他域信息； 此时，应该判断该请求的合法性检查，若不合法，则应关闭该Socket，并停止该HTTP 请求的进一步服务；若合法，则进行进一步的访问控制检测，若当前系统不允许该HTTP 请求的访问，也应关闭该Socket，并停止该HTTP请求的进一步服务；若允许访问，则针 对HTTP请求中客户欲访问的URL文件对象，进行相应的文件I/O，获取该文件的属性信 息和实体内容数据，结合HTTP协议头复用技术，生成HTTP响应数据，并存储于数据缓 存区中；随后在发送线程组中唤醒一个空闲的发送线程；\n(4)、发送线程被唤醒后，首先从任务队列中抽取头部的新任务，得到HTTP响应控制 信息所处的受控内存区的页地址，从而获知HTTP响应控制信息，进一步得知HTTP响应 数据所处的数据缓存区页地址，从而得到HTTP响应数据信息，以及需要发送的客户地址， 从而发送线程便直接将响应数据向客户端进行发送。\n所述数据缓存区采用页式机制管理，首先组织10个不同等级的自由页面链，随后将 用户需求的页面数规整为最短分解链，而后在相应的自由页面链上分配。\n与现有技术相比，本发明的优点在于：本发明解决了现有Web服务器结构中HTTP请 求间的并行粒度并行程度不高，性能不强的问题，本发明通过将完整的HTTP请求处理采 用流水化的体系结构来完成，从而可以实现HTTP请求内的并行性，能重叠处理HTTP请 求，得到更小的并行粒度，获取更高的并行处理能力；再结合高效的线程调度策略和数 据缓存方法，从而获得了较传统Web服务器优势更为明显的服务器性能。实验结果表明， 本发明的Web服务器结构具有高性能、运行稳定等优点。\n附图说明\n图1是本发明基于软流水结构的Web服务器结构示意图；\n图2是本发明主线程的流程示意图；\n图3是本发明连接线程的流程示意图；\n图4是本发明接收线程的流程示意图；\n图5是本发明数据处理线程的流程示意图；\n图6是本发明发送线程的流程示意图；\n图7是本发明中线程状态转换示意图；\n图8是本发明中数据缓存区的结构示意图；\n图9是本发明中Hash结构的示意图。\n具体实施方式\n以下将结合附图对本发明做进一步详细说明。\n本发明的构建基于软流水结构的Web服务器的方法是将Web服务器中完成HTTP请求 处理的完整流程依序分解为四个流水栈，每个流水栈内所包含的线程组只完成HTTP请求 处理的特定环节并将控制数据依次传递给与之相连的后序流水栈，前后序的流水栈之间 通过受控内存区传递自洽的控制数据信息，通过数据缓存区对用户所访问的对象数据进 行存储，并利用Socket区来管理用于数据接收和发送的Socket。\n如图1所示的基于软流水结构的Web服务器的体系结构和主要组成部分。由图不难 得知，Web服务器系统主要由主线程、四个流水栈(四组线程组)、数据缓存区(Data Cahce， DC)、受控内存区(Managed Buffer，MB)、Socket区组成。主线程负责服务器系统的初 始化、配置和线程的管理。四组线程组包括连接线程组、接收线程组、数据处理线程组 和发送线程组，各组线程是完成相应流水栈的功能体，组内线程同构，组间线程异构。 其中连接线程组位于客户链接建立阶段，负责建立客户发起的链接请求，并进行有效管 理；接收线程组位于请求接收阶段，完成接受客户端的新网络链接，接收并分析客户提 交的HTTP请求；数据处理线程组位于数据处理阶段，包括对客户所请求URL指定文件对 象数据的读取、对象数据的缓存以及HTTP响应数据的生成；发送线程组位于响应发送阶 段，负责将HTTP响应数据交付网络发送；数据缓存区用于存储对象数据，则针对该对象 的再次访问就可从缓存中直接获取数据，而无需再次进行磁盘I/O，从而提高系统的处理 能力。受控内存区则用于存储前后序线程之间所传递的自洽控制信息。而Socket区保存 包括新链接和处于Keep-Alive状态的所有存活socket，便于接收线程接收客户请求。\n下面将依照HTTP请求处理的逻辑时序流程，结合如图2、图3、图4、图5和图6所 示的各线程的流程示意图，详细讲解基于软流水体系结构的Web服务器的构建、各组成 部分之间的指令流和数据流的相互关系。\n当Web服务器启动时，服务器首先加载主线程。主线程将首先读取服务器系统的配置 文件，了解服务器的监听端口、URL文件集的物理路径、DC的大小、线程组中所包含的 线程数目等系统关键属性信息。随后将创建一个主监听Socket，并生成四组线程组。最 后唤醒一个连接线程来监听该主监听端口。此时，该主线程并不退出或是自行杀死，而 是进行睡眠状态，定期唤醒，检测流水栈线程的运行状态，并检测系统管理员是否正在 退出Web服务器，从而依据管理员命令，杀死所有的线程，并关闭主监听Socket，随后 释放所有的系统资源，关闭Web服务，退出系统。(参见图2)\n每个流水栈实现上是一组线程，每个线程均可独立完成HTTP请求的同一处理阶段的 相关操作。线程之间的相互关系存在两种类型：线程组内和组间。组内的线程功能和能 力同构，均可独立完成某个流水栈的功能；而线程间则具有前后序关系，存在控制相关 和数据相关。处理同一请求的后序线程必须在相应的前序线程执行完毕后，才能运行。 由于前后序线程之间使用受控内存区传递自洽的控制信息，因此前后序线程在实际运行 时可以消除数据相关，前序线程在传递控制数据后，便可自行进行其它请求的相应处理 操作。每个线程组维护一个任务队列，组内所有线程均从该队列中获取新任务。\n客户向Web服务器提交Socket连接建立请求，服务器的连接线程将截获该请求，完 成TCP/IP的Socket建立操作，创建一个新的活跃Socket，并将之放置在Socket区中。 随后，唤醒一个接收线程，使其针对该Socket进行后续操作。被唤醒接收线程将逐一查 阅本线程所具有的活跃Socket，检测该Socket是否包含客户刚发来的HTTP请求。如果 接收到一个完整的HTTP请求，则将该请求打包为一个自洽的HTTP请求控制数据，并从 MB中的自由链表中查找一页空闲页，分配所对应的MB页，将该自洽的HTTP请求控制数 据写入所分配的MB页中。随后将该MB页的首地址作为任务控制信息，创建一个新任务 结构，插入数据处理线程组的任务队列中，并调度一个空闲的数据处理线程，唤醒之。 被唤醒的数据处理线程将首先从任务队列中提取一个新任务，得到存储HTTP请求控制数 据的MB页地址，从而获知完整的HTTP请求信息。随后按照HTTP协议的要求，分析并提 取出HTTP请求的相关信息，得到客户所请求的URL文件对象。进行Hash计算，判断该 文件对象是否刚被访问过，并被缓存在DC中。若是，则可直接创建一个新任务结构。如 果欲访问的文件对象没有被缓存，则首先依据页使用位图、自由链数组和页表项数组进 行DC页的分配。同时也需要分配一个Hash结构。此时，将所读取得到的文件数据以HTTP 响应的形式写入DC中，结合HTTP协议头复用技术，所缓存的数据应也包含HTTP协议头 信息。如果DC过满的话，则需要同时参考LRU数组的信息，进行Hash对象和DC对象的 淘汰。不论是已缓存的对象，或是刚缓存的对象，在刚访问完毕后，都应该将该对象所 对应的LRU数组项更新。同时，都应分配一个MB页，创建一个新任务结构，将DC的首 页地址信息写入任务结构中，插入发送线程组的任务队列中，调度一个空闲发送线程并 唤醒之。被调度和唤醒的发送线程将从本线程组的任务队列中获取一个新任务，获取MB 页地址，得到欲发送的HTTP响应数据，直接向客户Socket进行数据发送即可。\n参见图7给出了线程的状态转换图，该图表明线程具有三种状态：睡眠状态，表示该 线程睡眠，释放CPU和其它系统资源，等待被调度；运行状态，表示该线程正在执行Web 请求特定流水栈操作的处理过程中；等待状态，表示该线程处于中断模式中，主要是在 等待诸如文件读或是网络发送等中断操作。每组线程缺省模式均为睡眠状态，释放CPU 资源。若前序线程刚执行完毕一个请求的前序流水栈，则首先生成一个自洽的控制信息， 存储于后序流水栈的任务队列尾部，并从后序线程组中任意挑选一个处于睡眠状态的线 程，唤醒并置为可执行状态。所谓自洽数据，是指数据中包含流水栈进行操作所需的所 有信息，主要是HTTP请求信息，以及HTTP响应信息。流水栈线程在得到这些信息之后， 便能依据自己的功能体，正确地理解所欲完成操作的的信息和属性，可正确执行任务。 从而，前后序线程依靠自洽控制数据的传递来消除前后序线程之间的数据相关行，从而 进一步提高Web服务器的并行性能。\n每个线程开始执行后，首先从本流水栈的任务队列头部抽取一个新任务，开始执行流 水栈的功能操作。当处理完毕之后，判断本流水栈的任务队列是否还存在新的任务请求， 若有，则接着执行下一个新任务；否则的话，转入睡眠状态。当正处于运行状态的线程 需要进行磁盘I/O以读取文件，或是进行网络读或发送等操作时，该线程将被中断阻塞， 处于等待状态；当中断操作完成时，该线程又转换为运行状态。\n具体的说，连接线程被阻塞在accept调用上，返回时必然是已经接受了客户的一个 新Socket连接请求。将该新Socket插入到Socket区中空闲的Socket项中，并且将该 项的m_uKeepAlive设置为KEEP_ALIVE_UNKNOWN状态，同时将m_nTimeoutTicks设置为 当前时间。随后，将唤醒一个空闲的接收线程。(参见图3)\nSocket区中每项的结构如下所示。\ntypedef struct\n{\n   /*keepalive status flag*/\n   volatile unsigned char m_uKeepAlive；\n   /*is socket  item processing*/\n   volatile unsigned char  m_uProcessing；\n   /*timeout jiffies*/\n   volatile unsigned long m_nTimeoutTicks；\n}TSocketList；\n接收线程被唤醒后，将检测所有的Socket项，首先判断该Socket项的m_uKeepAlive， 如果为KEEP_ALIVE_UNKNOWN或是KEEP_ALIVE_OK的话，则试图接收该Socket中客户端 所发送过来的HTTP请求，并判断该请求的完整性。如果完整的话，则从MB自由链中抽 取头部的一页，分配新MB页，创建一个HTTP请求结构，并将所接收到的HTTP请求串写 入该结构的m_szReqStringGotten域中。随后将该MB页地址作为一个新任务，写入数据 处理线程组的任务队列中，并唤醒一个空闲的数据处理线程。如果Socket项中 m_uKeepAlive的状态为KEEP_ALIVE_TIMEOUT，则表示该Socket项以超出HTTP协议的 Keep-Alive期，不于接收HTTP请求。并且如果超期过长的话，还应该将该Socket项删 除，关闭Socket，释放资源，并且将状态切换为KEEP_ALIVE_NO。(参见图4)\n如下给出了HTTP请求的数据结构。\ntypedef struct\n{\n   char m_szReqStringGotten[MAX_REQSTR_LEN]；\n   unsigned int m_uSocketIndex；\n   char m_OrigFileName[MAX_FIELD_LEN]；\n   char m_ExtFileName[MIN_FIELD_LEN]；\n   char m_Encodings[MID_FIELD_LEN]；\n   int m_Method；\n   char m_Protocol[MIN_FIELD_LEN]；\n   off_t m_BytesToSend；\n   off_t m_BytesSent；\n   int m_OneOne；/*HTTP/1.1 or better*/\n   /*Referer*/\n   char*m_Referer；\n   /*User-Agent*/\n   char*m_UserAgent；\n   /*Cookie*/\n   char*m_Cookie；\n   /*Content-Type*/\n   char*m_ContentType；\n   /*Host*/\n   char*m_HostName；\n   /*_Authorization*/\n   char*m_Authorization；\n   /*If-Modified-Since*/\n   time_t_m_IfModifiedSince；\n   /*If-Range*/\n   time_t m_RangeIf；\n   /*Content-Length*/\n   size_t m_ContentLength；\n   /*index for object’s hash position*/\n   unsigned long m_uHashIndex；\n   unsigned long m_uListIndex；\n   char   m_Type[MIN_FIELD_LEN]；\n   int    m_GotRange；\n   off_t  m_FirstByteIndex，m_LastByteIndex；\n   int    m_KeepAlive；\n   char   m_ReqHost[MID_FIELD_LEN]；\n   char*  m_HdrHost；\n   size_t m_ReadSize，m_ReadIndex，m_CheckedIndex；\n   int    m_CheckedState；\n   int    m_Status；\n}THttpRequest；\n该结构包含了诸如所获取的完整用户请求、分离得到的用户URL请求、用户host地 址、HTTP协议版本号、用户Agent、用户Cookie、欲获取数据的起始偏移等等。\n数据处理线程被唤醒之后，首先从任务队列中抽取头部的新任务，得到HTTP请求数 据所处的MB页地址，从而得到HTTP请求数据信息。首先依据HTTP协议，针对 m_szReqStringGotten域进行HTTP协议分析，得到HTTP请求结构中的其他域信息。此时， 应该判断该请求的合法性检查，若不合法，则应关闭该Socket，并停止该HTTP请求的进 一步服务。若合法，则进行进一步的访问控制检测，若当前系统不允许该HTTP请求的访 问，也应关闭该Socket，并停止该HTTP请求的进一步服务。若允许访问，则针对HTTP 请求中客户欲访问的URL文件对象，进行相应的文件I/O，获取该文件的属性信息和实体 内容数据。此时，便涉及到数据缓存区的管理、Hash机制和淘汰机制。(参见图5)\n图8给出了数据缓存区的结构示意图。数据缓存区主要用于文件对象数据的缓存，管 理机制主要涉及数据缓存的分配和释放、缓存对象的淘汰机制。数据缓存区主要包括控 制区(页使用位图、LRU数组、Hash数组、自由链数组以及页表项数组)、数据区。\n面向一个大型应用的Web服务器需要快速的处理大量数据请求，应能针对每个缓存需 求快速地分配最节省但能满足需求的数据缓存空间。数据缓存区使用页式管理机制，所 有的数据缓存将被划分为整数个页面，缓存的分配也以页面为基本单位。页面管理上， 借鉴并扩展了伙伴系统的管理策略，即数据缓存管理器首先按照20、......、29级别维 护十个自由页面链；在进行数据缓存分配时，管理器将依据对象的实际大小计算出所需 页面数；随后将所需页面数按照29、......、20的顺序划分为最短的分解链，表示对不 同页面块的分配需求，例如15应划分为8+4+2+1，而非4+4+4+2+1；最后按需分配。在 分配时，应首先满足大块的分配需求，随后依次满足较小块的需求。在进行实际分配时， 不可避免地会出现特定阶链上的空闲页面块不能满足分配需求的情形，此时就需要将需 求链上的页面块作二分分解，例如将8分解为4+4，试图在下一阶上满足分配。这样，完 整的数据缓存区的分配需求将以页面块链表的形式得到满足。\n页使用位图针对每个级别分别设定，相应级别上的每一位对应着相应级别的两块相邻 页面块。每一位的初始化取值为0。每个空闲块被分配，或是每个已分配块被释放都应将 相应的页使用位取反。由此可知，该位取值为0时，表示此相邻两块或均空闲，或均以 分配；若取值为1，则表示此相邻两块必然是其中一块被分配，而另外一块空闲。基于此 信息，位使用位图可应用于页面的分配分解和释放合并。若某页面块被释放时，它将检 测所对应级别上的位的取值情况，若为1，则表示另外块已是空闲，故应置上该位为0， 并上翻至上一级别，判断取值，并如此迭代。这样，一个页面块的释放将可能会影响到 相邻若干块，并最终形成一个可能的最大页面块。\n在对象缓存和淘汰方面，Web服务器使用散列的方法将对象散列，便于快速查找和定 位。图9给出了Hash结构示意图。Hash数组中存储了缓存于DC中对象的所有必需信息， 包括文件路径，对象大小和对象的修改时间，等待对象列表，以及该对象所存储的首页 地址；此外，还包括维护Hash结构的必需信息，如使用标志位、发送标志位等。需要说 明的是，DC的数据区中仅仅包含了对象的实体数据，是可由网络发送的完整数据，不包 含任何的控制信息和解释信息。\nWeb服务器系统在实现中对散列碰撞队列长度进行上限限定，如果是发生碰撞队列满 链或是整个数据缓存的空闲空间太小从而不能满足欲缓存对象的缓存，则会发生对象淘 汰。淘汰是必须借鉴LRU数组中的相关信息。LRU主要包含了对象的被访问时间，对象所 对应Hash元素的下标等信息。\n依据HTTP/1.1协议可知，针对特定访问文件，其HTTP响应头信息固定，因此本发明 采用HTTP协议头复用技术，即在作对象数据缓存时的同时就生成响应的HTTP响应头， 和对象数据同时存储于DC中。故而针对该文件的后序访问处理便避免了HTTP响应头的 再次生成，减少开销，增强了系统的处理能力。\n此时，数据处理线程便可以生成一个对应的HTTP响应数据(HTTP响应结构如下所示)。 则应从MB自由链中抽取头部的一页，分配新MB页，创建一个HTTP响应结构，添充内容 数据。随后将该MB页地址作为一个新任务，写入发送线程组的任务队列中，并唤醒一个 空闲的发送线程。\ntypedef struct\n{\n   size_t           m_ResponseLen；\n   char             m_Response[MAX_RSP_HEAD_LEN]；\n   size_t           m_FileLength；\n   unsigned long    m_ulObjectPageIndex；\n   char             m_sPath[MAX_FIELD_LEN]；\n   unsigned int     m_uSocketIndex；\n   /*index for object’s hash position*/\n   unsigned long    m_uHashIndex；\n   unsigned long    m_uListIndex；\n}THttpResponse；\n该结构包含了响应头的长度、响应数据的总长度、对象所缓存的DC地址、欲发送的 Socket在Socket链表中的索引号、对象文件路径等信息。\n发送线程被唤醒后，首先从任务队列中抽取头部的新任务，得到HTTP响应数据所处 的MB页地址，从而得到HTTP响应数据信息，以及需要发送的客户地址，从而发送线程 便直接将响应数据向客户端进行零拷贝发送。(参见图6)\n服务器在进行对象数据缓存时进行了一次所必须的内存拷贝，将对象数据缓存于缓存 中。在进行数据发送时，系统仅需要创建一个mbuf，以页(4096字节)为单位分割发送。 如果本次所发送数据单元有一页大小，则直接使用内存映射的方法，实现零拷贝的数据 发送：如果不足一页，则可以修改mbuf的ref_cnt值，使其大于1，同时指定mbuf中的 数据区偏移量，从而也实现零拷贝发送。\n受控内存区主要负责前后序线程之间传递自洽的控制信息，特别是接收线程向数据处 理线程，以及数据处理线程向发送线程传递控制信息。因此，也需要能快速得以分配和 释放。所有受控内存区同样采用页式管理机制。但由于控制信息数据量较小，完全可以 适当地放大页面尺寸，从而能将所有类型的控制信息都存放在一页中，那么分配和释放 均是以一页为单位。因此受控内存区的分配和释放就十分简单，仅仅将所有的空闲页放 入一个自由队列即可，分配时从队列头部摘除一页，释放时则将该页添加至队列尾部即 可。