Multithreaded Protable Runtime (MPR)
MPR是一個跨平臺的多線程可移植運行時灰瞻。
包括以下內(nèi)容：
- 內(nèi)存分配（memory allocation)
- 動態(tài)模塊加載（dynamic module loading)
- 安全的字符處理 (safe string handing)
- 列表(lists)
- 哈希（hashing)
- 命令行執(zhí)行(command execution)
- 套接字通信(socket communications)
- 線程 (threads)
- 線程同步 （thread synchronization)
- 線程池 (thread-pool)
- 事件（events)
- 定時器 （timers)
- debug trace
- 日志（logging)
Appweb 是建立在一個稱為MPR的可移植運行層上的帚稠。MPR將產(chǎn)品的其余部分和底層平臺隔離開待笑，使Appweb可以高度移植到新的操作系統(tǒng)或硬件上振乏。
MPR提供了一整套服務(wù)恰聘，用來幫助構(gòu)建高性能，多線程管理的系統(tǒng)服務(wù)應(yīng)用豌熄，包括：線程管理授嘀，動態(tài)模塊加載，網(wǎng)絡(luò)锣险，安全字符串處理,定時器蹄皱，XML解析和日志。
MPR還提供了一個更安全的編程環(huán)境芯肤，因為它取代了容易出現(xiàn)緩沖區(qū)溢出和其他類型安全漏洞的“C”API. MPR包括一個高性能巷折，安全的字符串庫，支持安全的編程風格崖咨。
MPR的事件處理機制可以輕松的集成到現(xiàn)有應(yīng)用中锻拘。它支持單線程和多線程架構(gòu)，輪詢（polled)或異步事件通知(async event notification), POSIX select等待 或 Windows消息循環(huán)（message loops）击蹲。
與C/C++結(jié)合使用時署拟，API web可以輕松集成到大多數(shù)C/C++應(yīng)用程序中。
MPR包括高性能內(nèi)存分配器和分代垃圾收集器歌豺。
內(nèi)存分配器是快速的推穷，聚合的分配器，具有非常低的內(nèi)存碎片类咧。它針對小塊內(nèi)存（<4K）的頻繁分配進行了優(yōu)化馒铃，并使用后臺收集器來釋放未使用的內(nèi)存。
垃圾收集器在C程序中有點不尋常痕惋。但是区宇，垃圾收集器特別適合長時間運行的服務(wù)，類似web服務(wù)器值戳，因為它幾乎消除了內(nèi)存泄漏议谷。與必須調(diào)用free釋放的內(nèi)存的傳統(tǒng)內(nèi)存分配器不同，appweb 4使用相反的方式堕虹。
必須標記出仍需使用的內(nèi)存卧晓，以防垃圾回收叶洞。這意味著必須為所有活動的內(nèi)存保留托管引用。
Appweb HTTP Server Core
與運行在其上的動態(tài)模塊相比禀崖，Appweb HTTP Core 是Appweb產(chǎn)品中較小的組件之一。Http Server Core 為處理器螟炫，過濾器和連接器提供一組服務(wù)波附，以便在向客戶端提供內(nèi)容時使用。
設(shè)計目標為集中任務(wù)為模塊服務(wù)的組件昼钻，從而使組件不會重復掸屡。
核心服務(wù)包含：主要的HTTP處理，套接字通信然评，初始化和解析Appweb配置仅财，服務(wù)器（server），虛擬主機（virtual host） 和 目錄授權(quán)管理碗淌， 請求管道管理 和 請求處理盏求。
核心服務(wù)同樣配置還強制執(zhí)行配置文件中請求的任何沙箱資源限制。例如：線程限制亿眠、請求的URI 和 主體（body）大小限制碎罚。這使Appweb使用確定的系統(tǒng)資源，并作為一個合格的系統(tǒng)公民（system citizen）纳像。
核心服務(wù)可以被配置為單線程或多線程荆烈。通過適當?shù)纳澈邢拗疲绻枰怪海梢悦棵胩幚頂?shù)千個請求憔购。
Appweb Configuration
Appweb配置
Appweb使用Apache樣式配置文件。Appweb啟動時會讀取此配置文件岔帽，它會管理Appweb配置的各個方面玫鸟，包括要偵聽的端口和地址，要加載的模塊山卦，在何處查找網(wǎng)頁以及如何記錄請求鞋邑。
配置文件支持各種指令，例如虛擬主機账蓉，目錄身份驗證枚碗，端口綁定，別名铸本，日志記錄和請求管道配置肮雨。它具有條件聲明并支持包含其他配置文件。Appweb通過一次遍歷解析配置文件箱玷，這意味著指令的順序很重要怨规。
Request Processing
處理請求
Appweb HTTP Server core 管理請求的處理和構(gòu)建處理請求的管道陌宿。
當新的HTTP請求到達時，Appweb將檢查請求到達的網(wǎng)絡(luò)接口波丰，如果它被分配給基于IP的虛擬主機壳坪，Appweb將路由（route）請求以由該虛擬主機處理。如果配置了基于名稱的虛擬主機掰烟，則必須推遲確定哪個
虛擬主機將處理請求爽蝴，直到使用默認服務(wù)器解析最初的請求，解析出HTTP報頭纫骑。
HTTP Header Parsing
HTTP報頭解析
HTTP請求的第一行指定要使用的HTTP操作方法蝎亚，要訪問的URI以及要使用的HTTP協(xié)議的變體。這通诚裙荩看起來像：
GET /index.html HTTP / 1.1
一些典型的Http header如下：
| Header | Description |
|---|---|
| Authorization | Authorization details including user name, realm, password digest and other authorization parameters to implement Basic and Digest authentication. |
| Connection | Describe how the TCP/IP connection should be managed when the request completes. |
| Content-Length | Length of any addition data with a POST request. |
| Content-Type | Mime types the client prefers to accept in response to this request. |
| Cookie | Cookie associated with the URI in the clients cookie cache. |
| Host | Name to the target host to serve the request. This specifies the host name when using virtual hosting. |
| If-Modified-Since | Only return the content if it has been modified since the date specified. Clients who have cached copies of a document (or graphics) use this header to allow the server to skip copying the document if it has not changed. |
| Keep-Alive | Request the server to keep the connection alive so that subsequent requests can reuse the connection. |
For example:
Connection: keep-alive
Appweb解析HTTP頭并將其之存儲在哈希表中发框，以備請求處理程序和管道階段性訪問。處理完所有的頭（header）后煤墙，Appweb繼續(xù)進行處理程序匹配梅惯。
這將在從客戶端讀取任何關(guān)聯(lián)的POST數(shù)據(jù)之前發(fā)生。POST數(shù)據(jù)可以是客戶端提交的表單數(shù)據(jù)番捂，也可以是使用PUT方法上傳的文件个唧。
Request Routing
請求路由
Appweb有一個強大的請求路由引擎（request routing engine).引擎配置了Appweb配置文件中的一組路由。當一個請求到達時设预，它測試各種路由徙歼，并選擇處理請求的最佳路由。在程序中鳖枕，路由可以根據(jù)需要在重定向或重寫請求魄梯。
一個Appweb通常具有很多路由。通過將路由正則表達式與請求URI相匹配宾符，依次對所配置的路由進行測試酿秸。路由可能要求在處理請求之前滿足進一步的先決條件。如果不滿足所需條件魏烫，將測試配置中的下一個路由辣苏。
如果所有的先前的路由都不合格，總是會有一個catch-all的路由來處理請求哄褒。
要定義路由稀蟋，請使用Route指令。例如：
<Route /projects/video>
SetHandler videoHandler
</Route>
上述例子呐赡，將導致videoHandler響應(yīng)URI的http: //site 部分之后任何以“/projects/video”開頭URI退客。
Request Pipeline<a id="sec-1-2-5" name="sec-1-2-5"></a>
請求管道
Appweb的核心使用雙向管道來處理請求并生成響應(yīng)。這包括隊列(queues),分組（packets），緩沖(buffering)和事件調(diào)度（event scheduling）的機制萌狂。
管道（pipeline)的架構(gòu)使高度優(yōu)化過的档玻，可以支持無拷貝的高效數(shù)據(jù)轉(zhuǎn)發(fā)。
它使用對網(wǎng)絡(luò)的向量化（vectored）茫藏、分散/聚集（scatter/gather）寫入误趴，以避免在寫入網(wǎng)絡(luò)前在單個緩沖區(qū)中對數(shù)據(jù)和報頭進行高代價的聚合。
-
Pipeline Stages
管道階段
pipeline.jpg
Request Piple是由一個輸入流（incoming stream）和一個輸出流（outgoing stream)組成的务傲。每一個流又由 階段 組成冤留。
每一個階段有一個帶有2個服務(wù)例程的數(shù)據(jù)隊列，一個服務(wù)例程用于接受不排隊的數(shù)據(jù)树灶，另一個用于（有延遲地）服務(wù)之前排隊的數(shù)據(jù)。
Piple stages 支持流控（flow-control）糯而，如果下游（downstream stage）當前無法接收數(shù)據(jù)天通，可以將數(shù)據(jù)放入隊列，以接收延遲地服務(wù)熄驼。
一個典型的管道包含以下階段：
- One handler(一個處理程序)
- Zero or more filters（0個或更多的過濾器）
- One network connector（一個網(wǎng)絡(luò)連接器）
Http core
Http core 負責解析HTTP請求像寒。HTTP請求第一行指定請求的URI資源，請求頭（request header)提供附加上下文（additional context)瓜贾。
Http core存儲解析的headers诺祸，并且創(chuàng)建一個request pipeline去處理請求。輸入和輸出管道是分開構(gòu)造的祭芦，因為每個方向可能需要一組不同的過濾器筷笨。
Routing Engine
路由引擎
Routing Engine將request與配置的請求路由（request routes）相匹配，并為request選擇最佳的路由龟劲。
Routing Engine 指定管理請求和其他上下文的處理程序胃夏，例如在哪里查找需要的服務(wù)文檔。
Routing Engine 可以重寫請求昌跌，然后重新路由仰禀。
Routing Engine 同時還管理HTTP認證。
根據(jù)請求URI和HTTP header 選擇合適的處理程序蚕愤。有ESP答恶，PHP，CGI和靜態(tài)文本數(shù)據(jù)的處理程序萍诱。
Handlers
處理程序
Handlers 處理接收到的request并產(chǎn)生相應(yīng)的響應(yīng)悬嗓。它根據(jù)HTTP請求的URI，header砂沛，正文數(shù)據(jù)（body data）和潛在的應(yīng)用程序會話狀態(tài)生成響應(yīng)內(nèi)容烫扼。
在由網(wǎng)絡(luò)連接器傳輸?shù)娇蛻舳酥埃敵鰯?shù)據(jù)流經(jīng)管道碍庵。
每一個請求（request)都有一個處理程序(handler)映企。Appweb core基于request匹配算法來選擇處理程序（handler）.
處理程序（handler)在appweb配置文件中通過 AddHandler 和 SetHander 來配置悟狱。
Filters
過濾器
過濾器的工作是以某種方式置換數(shù)據(jù)并將其傳遞到管道的下一個階段。過濾器彼此連接堰氓，并且可以在傳入和傳出管道方向上使用多個過濾器挤渐。
過濾器的順序相當重要。例如双絮，在加密之前壓縮數(shù)據(jù)和加密之后壓縮數(shù)據(jù)完全不同浴麻。Appweb 提供 AddInputFileter 和 AddOutputFilter 指令以幫助構(gòu)建過濾器管道。
Appweb使用過濾器來實現(xiàn)傳輸授權(quán)（|Transfer Authorization）囤攀，塊數(shù)據(jù)編碼（Chunk Encoding)和HTTP遠程請求软免。通過使用過濾器來是夢想這些功能，它們將自動可供所有處理程序和所有內(nèi)容類型使用焚挠。
connectors
連接器
連接器負責發(fā)送輸出數(shù)據(jù)到客戶端膏萧。它接收一組表示要發(fā)送給客戶端的數(shù)據(jù)包。連接器負責請求Appweb HTTP core 創(chuàng)建的帶有HTTP響應(yīng)頭的數(shù)據(jù)包蝌衔。
正是在這個階段榛泛，appweb 可以確定TCP/IP連接是否可以為同一連接上的后續(xù)請求繼續(xù)保持活動狀態(tài)。（keep-alive）噩斟。
Delayed Headers
延遲Headers
連接器將會接受必須被填充為HTTP響應(yīng)的一個空的header packet曹锨。
通過延遲產(chǎn)生HTTP header 直到最后一刻，Appweb可以最大化每一個機會去優(yōu)化響應(yīng)并且使用HTTP/1.1的 Keep-Alive特性剃允，即使對動態(tài)生成的數(shù)據(jù)也是如此沛简。
Send Connector
發(fā)送連接器
當文件處理程序和發(fā)送連接器通信時，它將通過不讀取靜態(tài)文件數(shù)據(jù)來優(yōu)化操作斥废。相反覆享，它將會發(fā)送空到數(shù)據(jù)包到發(fā)送連接器，發(fā)送連接器將會使用操作系統(tǒng)的 sendfile(或其等效) 原語营袜。
這避免了靜態(tài)文件數(shù)據(jù)傳輸?shù)紸ppweb的用戶進程中撒顿。
Net Connector
網(wǎng)絡(luò)連接器
網(wǎng)絡(luò)連接器是一種通用網(wǎng)絡(luò)連接器，可以將內(nèi)容從任何處理程序（haandler）傳輸?shù)娇蛻舳思园濉ＫС窒蛄浚╲ector)寫入凤壁，以避免在與HTTP，range or chunk header 的交互時拷貝數(shù)據(jù)跪另。
WebFrameWorks
Web框架
Appweb 支持ESP和PHP的可加載模塊Web框架拧抖。
Embedder Server Page Web Framework
嵌入式網(wǎng)頁服務(wù)器框架
（內(nèi)容略）
PHP
PHP是一種廣泛使用的通用腳本語言，特別適用于Web開發(fā)免绿，可以嵌入到HTML中唧席。Appweb為PHP Web框架提供了一個快速的內(nèi)存處理程序。
Security
安全
Appweb提供一套旨在提高Web服務(wù)器安全性的措施：
- Secure Sockets Layer （安全鏈路層）
- Authorization directives (認證指令）
- Sandbox directives (沙盒指令)
- MPR – secure portable runtime （安全可移植運行時）
- Manager monitioring process (管理監(jiān)控進程)
Secure Sockets
Appweb支持MbedTLS和OpenSSL.你可以配置基于服務(wù)器和（或）客戶端證書的身份認證，支持SSL和TLS淌哟。
Authentication
認證
Appweb提供摘要式身份驗證機制迹卢，并支持基于文件和基于PAM的身份驗證后端。
Sandbox
沙盒
沙盒是應(yīng)用于在受限環(huán)境中運行Appweb的術(shù)語徒仓。Appweb有一組配置文件指令腐碱，允許你定義沙盒，該沙盒限制Appweb可用于給定請求的資源掉弛。
通過使用定義良好的沙盒指令症见，可以幫助你確保應(yīng)用程序和系統(tǒng)不會受到惡意請求的危害。
總結(jié)
| 組件 | 描述 |
|---|---|
| Multithreaded Portable Runtime | Cross-platform, multi-threaded portable runtime. Includes services for memory allocation, dynamic module loading, safe string handling, lists, hashing, command execution, socket communications, threads, thread synchronization, thread-pool, events, timers, debug trace and logging. |
| Appweb HTTP Core Library | Core HTTP server. Includes services for initialization, HTTP protocol handling, socket connection management, logging, virtual hosts, directory and location blocks, request processing pipeline, and module loading and management. |
| File Handler | The File handler serves static content such as HTML pages, images and PDF files. It works cooperatively with the Send connector to eliminate reading such content into memory. The File handler sends details of the content name via the processing pipeline to the Send connector which uses special O/S APIs to directly copy files to the network. |
| ESP Handler | The Embedded Server Pages (ESP) web framework is an advanced, Model,View,Controller "C" language web framework. |
| PHP Handler | In-memory handler module for the PHP web environment. |
| CGI Handler | Common Gateway Interface handler. |
| Chunk Filter | The Chunk applies Transfer Chunk Encoding to outgoing data. Chunk encoding enables the HTTP connection to be reused for subsequent requests without having to establish a new TCP/IP connection. This can significantly improve network and application performance. |
| Range Filter | The Range filter selects the requested I/O range by the client. The Range filter works cooperatively with the File handler and Send connector to eliminate copying and reading static content for ranged requests. |
| Net Connector | The Net connector is the general purpose transmitter of content to the client. It supports vectored gather/scatter writes for optimal performance. |
| Send Connector | The Send connector is a special purpose transmitter of static file content to the client. It uses operating system APIs to send file data to the client without reading the data into Appweb. It also uses vectored gather/scatter I/O to blend response, chunk, and range headers into the static data. These strategies dramatically boost the performance of serving static data. |
| Secure Sockets Layer (SSL) | Secure Socket Layer protocol stack. This is a virtual interface that can selectively support a variety of SSL providers including: the MbedTLS and OpenSSL stacks. |
