modules.jpg

Multithreaded Protable Runtime (MPR)

MPR是一个跨平台的多线程可移植运行时。
包括以下内容：

1. 内存分配（memory allocation)
2. 动态模块加载（dynamic module loading)
3. 安全的字符处理 (safe string handing)
4. 列表(lists)
5. 哈希（hashing)
6. 命令行执行(command execution)
7. 套接字通信(socket communications)
8. 线程 (threads)
9. 线程同步 （thread synchronization)
10. 线程池 (thread-pool)
11. 事件（events)
12. 定时器 （timers)
13. debug trace
14. 日志（logging)

Appweb 是建立在一个称为MPR的可移植运行层上的。MPR将产品的其余部分和底层平台隔离开，使Appweb可以高度移植到新的操作系统或硬件上。
MPR提供了一整套服务，用来帮助构建高性能，多线程管理的系统服务应用，包括：线程管理，动态模块加载，网络，安全字符串处理,定时器，XML解析和日志。
MPR还提供了一个更安全的编程环境，因为它取代了容易出现缓冲区溢出和其他类型安全漏洞的“C”API. MPR包括一个高性能，安全的字符串库，支持安全的编程风格。
MPR的事件处理机制可以轻松的集成到现有应用中。它支持单线程和多线程架构，轮询（polled)或异步事件通知(async event notification), POSIX select等待 或 Windows消息循环（message loops）。
与C/C++结合使用时，API web可以轻松集成到大多数C/C++应用程序中。
MPR包括高性能内存分配器和分代垃圾收集器。
内存分配器是快速的，聚合的分配器，具有非常低的内存碎片。它针对小块内存（<4K）的频繁分配进行了优化，并使用后台收集器来释放未使用的内存。
垃圾收集器在C程序中有点不寻常。但是，垃圾收集器特别适合长时间运行的服务，类似web服务器，因为它几乎消除了内存泄漏。与必须调用free释放的内存的传统内存分配器不同，appweb 4使用相反的方式。
必须标记出仍需使用的内存，以防垃圾回收。这意味着必须为所有活动的内存保留托管引用。

Appweb HTTP Server Core

与运行在其上的动态模块相比，Appweb HTTP Core 是Appweb产品中较小的组件之一。Http Server Core 为处理器，过滤器和连接器提供一组服务，以便在向客户端提供内容时使用。
设计目标为集中任务为模块服务的组件，从而使组件不会重复。
核心服务包含：主要的HTTP处理，套接字通信，初始化和解析Appweb配置，服务器（server），虚拟主机（virtual host） 和 目录授权管理， 请求管道管理 和 请求处理。
核心服务同样配置还强制执行配置文件中请求的任何沙箱资源限制。例如：线程限制、请求的URI 和 主体（body）大小限制。这使Appweb使用确定的系统资源，并作为一个合格的系统公民（system citizen）。
核心服务可以被配置为单线程或多线程。通过适当的沙盒限制，如果需要，它可以每秒处理数千个请求。

Appweb Configuration

Appweb配置
Appweb使用Apache样式配置文件。Appweb启动时会读取此配置文件，它会管理Appweb配置的各个方面，包括要侦听的端口和地址，要加载的模块，在何处查找网页以及如何记录请求。
配置文件支持各种指令，例如虚拟主机，目录身份验证，端口绑定，别名，日志记录和请求管道配置。它具有条件声明并支持包含其他配置文件。Appweb通过一次遍历解析配置文件，这意味着指令的顺序很重要。

Request Processing

处理请求
Appweb HTTP Server core 管理请求的处理和构建处理请求的管道。
当新的HTTP请求到达时，Appweb将检查请求到达的网络接口，如果它被分配给基于IP的虚拟主机，Appweb将路由（route）请求以由该虚拟主机处理。如果配置了基于名称的虚拟主机，则必须推迟确定哪个
虚拟主机将处理请求，直到使用默认服务器解析最初的请求，解析出HTTP报头。

HTTP Header Parsing

HTTP报头解析
HTTP请求的第一行指定要使用的HTTP操作方法，要访问的URI以及要使用的HTTP协议的变体。这通常看起来像：

GET /index.html HTTP / 1.1

一些典型的Http header如下：

For example:

Connection: keep-alive

Appweb解析HTTP头并将其之存储在哈希表中，以备请求处理程序和管道阶段性访问。处理完所有的头（header）后，Appweb继续进行处理程序匹配。
这将在从客户端读取任何关联的POST数据之前发生。POST数据可以是客户端提交的表单数据，也可以是使用PUT方法上传的文件。

Request Routing

请求路由
Appweb有一个强大的请求路由引擎（request routing engine).引擎配置了Appweb配置文件中的一组路由。当一个请求到达时，它测试各种路由，并选择处理请求的最佳路由。在程序中，路由可以根据需要在重定向或重写请求。

一个Appweb通常具有很多路由。通过将路由正则表达式与请求URI相匹配，依次对所配置的路由进行测试。路由可能要求在处理请求之前满足进一步的先决条件。如果不满足所需条件，将测试配置中的下一个路由。
如果所有的先前的路由都不合格，总是会有一个catch-all的路由来处理请求。

要定义路由，请使用Route指令。例如：

<Route /projects/video>
    SetHandler videoHandler
</Route>

上述例子，将导致videoHandler响应URI的http: //site 部分之后任何以“/projects/video”开头URI。

Request Pipeline<a id="sec-1-2-5" name="sec-1-2-5"></a>

请求管道
Appweb的核心使用双向管道来处理请求并生成响应。这包括队列(queues),分组（packets），缓冲(buffering)和事件调度（event scheduling）的机制。
管道（pipeline)的架构使高度优化过的，可以支持无拷贝的高效数据转发。
它使用对网络的向量化（vectored）、分散/聚集（scatter/gather）写入，以避免在写入网络前在单个缓冲区中对数据和报头进行高代价的聚合。

1. Pipeline Stages

   管道阶段

   pipeline.jpg

Request Piple是由一个输入流（incoming stream）和一个输出流（outgoing stream)组成的。每一个流又由 阶段 组成。
每一个阶段有一个带有2个服务例程的数据队列，一个服务例程用于接受不排队的数据，另一个用于（有延迟地）服务之前排队的数据。
Piple stages 支持流控（flow-control），如果下游（downstream stage）当前无法接收数据，可以将数据放入队列，以接收延迟地服务。
一个典型的管道包含以下阶段：
- One handler(一个处理程序)
- Zero or more filters（0个或更多的过滤器）
- One network connector（一个网络连接器）

Http core

Http core 负责解析HTTP请求。HTTP请求第一行指定请求的URI资源，请求头（request header)提供附加上下文（additional context)。
Http core存储解析的headers，并且创建一个request pipeline去处理请求。输入和输出管道是分开构造的，因为每个方向可能需要一组不同的过滤器。

Routing Engine

路由引擎
Routing Engine将request与配置的请求路由（request routes）相匹配，并为request选择最佳的路由。
Routing Engine 指定管理请求和其他上下文的处理程序，例如在哪里查找需要的服务文档。
Routing Engine 可以重写请求，然后重新路由。
Routing Engine 同时还管理HTTP认证。

根据请求URI和HTTP header 选择合适的处理程序。有ESP，PHP，CGI和静态文本数据的处理程序。

Handlers

处理程序
Handlers 处理接收到的request并产生相应的响应。它根据HTTP请求的URI，header，正文数据（body data）和潜在的应用程序会话状态生成响应内容。
在由网络连接器传输到客户端之前，输出数据流经管道。
每一个请求（request)都有一个处理程序(handler)。Appweb core基于request匹配算法来选择处理程序（handler）.
处理程序（handler)在appweb配置文件中通过 AddHandler 和 SetHander 来配置。

Filters

过滤器
过滤器的工作是以某种方式置换数据并将其传递到管道的下一个阶段。过滤器彼此连接，并且可以在传入和传出管道方向上使用多个过滤器。
过滤器的顺序相当重要。例如，在加密之前压缩数据和加密之后压缩数据完全不同。Appweb 提供 AddInputFileter 和 AddOutputFilter 指令以帮助构建过滤器管道。
Appweb使用过滤器来实现传输授权（|Transfer Authorization），块数据编码（Chunk Encoding)和HTTP远程请求。通过使用过滤器来是梦想这些功能，它们将自动可供所有处理程序和所有内容类型使用。

connectors

连接器
连接器负责发送输出数据到客户端。它接收一组表示要发送给客户端的数据包。连接器负责请求Appweb HTTP core 创建的带有HTTP响应头的数据包。
正是在这个阶段，appweb 可以确定TCP/IP连接是否可以为同一连接上的后续请求继续保持活动状态。（keep-alive）。

Delayed Headers

延迟Headers
连接器将会接受必须被填充为HTTP响应的一个空的header packet。
通过延迟产生HTTP header 直到最后一刻，Appweb可以最大化每一个机会去优化响应并且使用HTTP/1.1的 Keep-Alive特性，即使对动态生成的数据也是如此。

Send Connector

发送连接器
当文件处理程序和发送连接器通信时，它将通过不读取静态文件数据来优化操作。相反，它将会发送空到数据包到发送连接器，发送连接器将会使用操作系统的 sendfile(或其等效) 原语。
这避免了静态文件数据传输到Appweb的用户进程中。

Net Connector

网络连接器
网络连接器是一种通用网络连接器，可以将内容从任何处理程序（haandler）传输到客户端。它支持向量（vector)写入，以避免在与HTTP，range or chunk header 的交互时拷贝数据。

WebFrameWorks

Web框架
Appweb 支持ESP和PHP的可加载模块Web框架。

Embedder Server Page Web Framework

嵌入式网页服务器框架
（内容略）

PHP

PHP是一种广泛使用的通用脚本语言，特别适用于Web开发，可以嵌入到HTML中。Appweb为PHP Web框架提供了一个快速的内存处理程序。

Security

安全
Appweb提供一套旨在提高Web服务器安全性的措施：

1. Secure Sockets Layer （安全链路层）
2. Authorization directives (认证指令）
3. Sandbox directives (沙盒指令)
4. MPR – secure portable runtime （安全可移植运行时）
5. Manager monitioring process (管理监控进程)

Secure Sockets

Appweb支持MbedTLS和OpenSSL.你可以配置基于服务器和（或）客户端证书的身份认证，支持SSL和TLS。

Authentication

认证
Appweb提供摘要式身份验证机制，并支持基于文件和基于PAM的身份验证后端。

Sandbox

沙盒
沙盒是应用于在受限环境中运行Appweb的术语。Appweb有一组配置文件指令，允许你定义沙盒，该沙盒限制Appweb可用于给定请求的资源。
通过使用定义良好的沙盒指令，可以帮助你确保应用程序和系统不会受到恶意请求的危害。

总结