【正文】 會自動恢復(fù) Fikker 可用性。400 Bad Request HTTP Request Error用戶請求的 HTTP 頭出現(xiàn)錯誤，原因如下：(a)、頭太大，大于16K(b)、HTTP 頭缺少 Host 字段(c)、客戶端訪問的URL有錯誤400 Bad Request Invalid Host用戶訪問請求的 HTTP 頭無 Host 字段或 Host 字段有錯誤。HTTP 頭包含的 Host 主機(jī)字段，最大長度不能超過 200 個字節(jié)。注意：bps 帶寬是按照 bit 速率計算的，byte 速率乘 8 才是 bps 帶寬值。(4)、當(dāng)前頁面緩存占用內(nèi)存(CacheUsedMemSize)：用于頁面緩存的內(nèi)存占用統(tǒng)計，單位為 KB。(3) 、TR TotalRequest 總請求量，這個請求量包括了訪客對 Fikker 所有的有效連接訪問請求，不只限于動靜態(tài)頁面(html，asp，aspx，php，jsp，do 等)統(tǒng)計，還包含了網(wǎng)站下面其它所有的可請求資源 css，js，class，gif，jpg，jpeg，png，bmp，ico，swf 等后綴結(jié)尾的文件。(2)、一個主機(jī)名（或域名）允許對應(yīng)多個源站，多個源站之間應(yīng)用負(fù)載均衡規(guī)則。 | 和 淘寶 item 站點下面指 || | | 定的鏈接引用。(3)、Fikker 中可建立多個保護(hù)鏈。圖解1 (偽靜態(tài)實現(xiàn)原理):======================= ++ | | ++ | 源站處理動態(tài) URL | ++ ++ | | ++ | Fikker 轉(zhuǎn)向管理，將地址轉(zhuǎn)換成動態(tài) URL | ++ ++ | | ++ | 用戶訪問靜態(tài)地址 URL | ++ 圖解2 (重定向原理，返回 HTTP 狀態(tài) 302 Object Moved): ==================================================== ++ | | ++ | Fikker 轉(zhuǎn)向管理，返回給瀏覽器重定向 URL，狀態(tài) 302 | ++ ++ | | ++ | 用戶訪問地址 URL | ++. 轉(zhuǎn)向邏輯(1)、Last，訪問地址匹配成功后，立即終止，按照規(guī)則轉(zhuǎn)換(重寫) URL 轉(zhuǎn)發(fā)給源站。(3)、如果網(wǎng)站返回的內(nèi)容已經(jīng)是壓縮格式的內(nèi)容，并且是塊傳輸?shù)?TransferEncoding: chunked，F(xiàn)ikker便會將其去除頁面內(nèi)容中包含的 chunked 標(biāo)記，在 HTTP 頭中添加 ContentLength 字段屬性。. HTTP頭中有關(guān)gzip壓縮的字段(1)、AcceptEncoding: gzip, deflate, press：表明瀏覽器同時支持gzip，deflate和press壓縮，網(wǎng)站返回的頁面內(nèi)容可以被壓縮后再傳輸過來。. 緩存頁面淘汰優(yōu)先級(1)、淘汰過期緩存頁面，就是將超時的緩存頁面清理掉，騰出內(nèi)存空間，如果騰出來的內(nèi)存空間不夠新頁面的所需尺寸，進(jìn)入第二步。(2)、正則表達(dá)式匹配(Regular Expression Pattern)，可以設(shè)定復(fù)雜但豐富的匹配條件，詳細(xì)請參考相關(guān)的 Posix Regex 資料說明介紹。因為這部分頁面包含了只針對某一個用戶的私有數(shù)據(jù)，即相同的一個頁面，不同用戶獲取的頁面內(nèi)容是不同的。. 會員緩存 設(shè)計背景：一些社交（SNS），論壇（BBS），新聞（News），博客（Blog），電子商務(wù)（B2C，C2C）類網(wǎng)站，登錄用戶（會員）和非登錄用戶（游客）看到的網(wǎng)站頁面內(nèi)容可能是不同的，部分頁面中包含的內(nèi)容只有用戶登陸后才能查看，即便是相同的頁面鏈接地址URL，登錄用戶（會員）和非登錄用戶（游客）分別請求時，請求到的頁面內(nèi)容是不完全相同的。舉例：一個 500KB 的文本頁面，被壓縮以后為 110KB 左右，減少帶寬消耗 75% 左右，在大量并發(fā)訪問時，會節(jié)省大量的帶寬損耗。nostore非緩存非存儲標(biāo)識，F(xiàn)ikker不緩存不存儲。以上處理方式有如下好處：(1)、不讀寫硬盤，通過內(nèi)存進(jìn)行數(shù)據(jù)交換會極大的提高頁面相應(yīng)速度；(2)、文本頁面數(shù)據(jù)經(jīng)過 gzip 壓縮后存儲，即減少了對內(nèi)存空間的需求，也會極大的減少數(shù)據(jù)傳輸量，從整體上提高響應(yīng)速度和傳輸效率。Windows 下1個線程最大可滿足 1000 個并發(fā)連接的即時處理（20個線程最大可并發(fā)處理2萬個并發(fā)連接，單個端口最大服務(wù)6萬個并發(fā)連接）。偽靜態(tài)39。Fikker 網(wǎng)絡(luò)實現(xiàn)了全部非阻塞化（nonblock）處理，包括 Fikker 接收數(shù)據(jù)非阻塞，發(fā)送數(shù)據(jù)非阻塞，域名解析非阻塞。Fikker 是源站（網(wǎng)站）前置機(jī)，是放在源站（網(wǎng)站）前面的服務(wù)器?？醇椅淦?9。Master 主線程：（1）、按連接數(shù)對每一個 Slave 線程負(fù)載均衡；（2）、全非阻塞（nonblock）方式接受（accept）遠(yuǎn)程用戶的連接請求；（3）、將建立的連接（connection）按照負(fù)載均衡規(guī)則導(dǎo)出給 Slave 線程。(3) 、Fikker 應(yīng)用的智能規(guī)則如下：用戶 Request 請求時用到 CacheControl：| maxage = seconds 忽略| maxstale [ = seconds ] 忽略| onlyifcached 忽略| notransform 忽略| minfresh = seconds 忽略| cacheextension 忽略| nocache 是否啟用緩存? 配置選項| nostore 是否啟用緩存? 配置選項源站Response返回時用到 CacheControl：| maxage = seconds 緩存| smaxage = seconds 緩存| public 緩存| private [ = fieldname ] 不緩存| nocache [ = fieldname ] 不緩存| nostore 不緩存| mustrevalidate 不緩存| proxyrevalidate 不緩存| cacheextension 忽略| notransform 忽略Fikker 對此處理如下：maxage最大緩存有效期，從獲得 Response 報頭開始計算緩存有效期。注：參看rfc2616，章節(jié)： CacheControl，頁碼：Page 108用戶Request 請求時用到 Pragma：| nocache 不啟用緩存源站Response 返回時用到 Pragma：| nocache 不緩存源站Response 返回時用到 Expire 和 Date：Expires Date = 緩存有效期 緩存避免沖突策略：當(dāng)HTTP報頭中同時設(shè)置有 Expire，Pragma，CacheControl字段時，優(yōu)先權(quán)順序為 CacheControl Pragma Expire。（Fikker 頁面緩存 = 公共緩存 + 會員緩存 + 游客緩存）. 公共緩存頁面被緩存后，所有用戶都可訪問，是最