cdn方案建議書 cdn方案建議書篇一：網站通用CDN改造建議書 網站通用 CDN改造建議書 2010年6月 北京藍汛通信技術有限責任公司 目錄 1. 面向CACHE改造網站的通用建議. 1 1.1 CACHE設備的一般工作原理 . 1 1.2 控制設備的緩存動作 . 2 1.2.1使用HTML Meta Tags和 HTTP Headers. 2 1.2.2不起作用的Pragma HTTP Headers . 2 1.2.3使用Expires HTTP Header控制內容更新 . 3 1.2.4Cache-Control HTTP headers . 3 1.2.5認證條件和認證 . 4 1.3 建造CACHE易于識別的WEB站點. 5 1.4 寫CACHE易于識別的腳本. 6 2. 其它CDN加速相關問題 . 7 2.1 圖片加速優先 . 7 2.2 分離不同性質的域名 . 7 2.3 用戶登錄后個性化信息的改造 . 8 2.4 加速后如何獲取頁面訪問量統計結果 . 8 2.5 內容刷新 . 8 2.6 內容分頁、URL不變的情況 . 8 2.7 將訪問頻率高的從數據庫獲取的內容發布為靜態頁面 . 9 2.8 評論和原ASP文件分開顯示 . 9 2.9 避免使用重新定向 . 9 2.10 URL參數部分避免使用中文字符和IP，URL不可過長 . 9 2.11 對于受口令保護的頁面，CACHE設備如何處理 . 10 2.12 我將我的頁面標記成了可緩存，可是我的瀏覽器的每次請求都穿過了CACHE設備，如何能強制CACHE保存內容副本？ . 10 1. 面向Cache改造網站的通用建議 1.1 Cache設備的一般工作原理 所有的Cache設備都有一套規則來確定何時向用戶提供Cache中已有的可用內容。有些規則通過http 1.01.1 規范設置，有些規則可以由管理員在Cache設備上設置。 一般而言，下面是一些應普遍遵循的規則： 1、 2、 如果響應Headers標明對象不可Cache，設備就不Cache； 如果響應Headers中沒有過期驗證的Header（如Etag或 Last-Modified），Cache設備將認為此對象為不可Cache。 3、 4、 如果請求要經過用戶認證或是保密內容，響應內容將不被Cache 被cache的內容如果符合一下條件之一，將被認為不過時，不需 向源站檢查，就可提供給請求客戶： ? 被Cache內容具有過期時間或其它控制有效期Header設 置，且按此設置內容尚不過期； ? 瀏覽器在設置成一次會話檢查一次的情況下，在緩存中發現 此副本。 ? 代理服務器中發現此副本，該副本已經有相當長的時間沒有 被修改過了。 5、 如果副本過期，Cache設備會向源站確認內容是否可用，如果源 站告訴Cache設備內容不可用，Cache設備從源站獲取最新內容， 否則將Cache設備內容提供給用戶，同時延長Cache中副本的過 期時間。 總之，通過副本“Freshness”確認，在該內容未改變的情況下，避免 服務器再次發送全部內容，確保了訪問客戶能從Cache設備上立刻獲得所需內容。 1.2 控制設備的緩存動作 1.2.1使用HTML Meta Tags和 HTTP Headers HTML作者可以在文檔中放入meta tags標明文檔不可緩存， 或在指定時間后過期。Meta tags容易使用但效率不高，因為它控制瀏覽器的緩存動作，而不能控制專用Cache設備的緩存動作。 HTTP headers卻可以讓你同時控制瀏覽器和專用Cache設備的緩 存動作，他們通常由Web服務器自動生成，不能在HTML頁面中看到。根據使用服務器的不同，你可以在不同程度上控制Headers。HTTP headers在HTML頁面之前發送，只能被瀏覽器和中間層Cache設備看 到。典型的HTTP 1.1 響應頭可能像這個樣子： HTTP/1.1 200 OK Date: Fri, 30 Oct 1998 13:19:41 GMT Server: Apache/1.3.3 (Unix) Cache-Control: max-age=3600, must-revalidate Expires: Fri, 30 Oct 1998 14:19:41 GMT Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT ETag: 3e86-410-3596fbbc Content-Length: 1040 Content-Type: text/html 1.2.2不起作用的Pragma HTTP Headers 許多人認為指定一個pragma值為“no cache”可以使內容不被 cache，這種說法并不正確，HTTP規范沒有對Pragma 響應header做 出任何規定。相反只討論了pragma請求header。雖然可能有少數Cache 設備支持這個響應header，但大部分不支持，所以設置它不起作用 在藍汛公司使用的cache 設備中加入filter，可以對“pragma: no cache”頁面強行cache。 1.2.3使用Expires HTTP Header控制內容更新 Expires HTTP header是一種控制Cache設備的基本方式，它告訴 設備某一副本在多長的時間內不過期，在此之后，設備將回源站檢查頁面是否被更新過。事實上，所有的Cache設備都支持Expires header。大多數Web服務器允許通過幾種方式設置Expires 響應Header。服務 器通常允許你為頁面設置一個絕對過期時間。 Expires header對控制靜態圖片的緩存動作尤其有效，因為他們不 經常變化，站點對用戶響應速度肯定會比較快。它對控制有規律改變的頁面也很有效，比如你每天早上6點更新頁面，你就可以設定副本在早上6點過期，Cache設備就知道何時去源站獲取新的內容，而不用用戶作任何操作。 Expires header的唯一值就是一個HTTP 日期；任何其他值都會被 按過時理解，造成內容不可緩存。還要注意，HTTP date是GMT（Greenwich Mean Time）時間，而不是本地時間。格式：Expires: Fri, 30 Oct 1998 14:19:41 GMT 如果你使用Expires header，就必須確保服務器時鐘準確。方法之 一是使用NTP（Network Time Protocol），找本地系統管理員確定可以 使用哪些NTP Server。 使用Expires header要注意確保Web服務器和Cache設備的時間 一致，否則就可能出現Cache設備把過時內容提供給用戶的結果。 最后一點，記住在頁面過期之前為頁面指定新的過期時間，否則所 有的用戶請求都要回源站驗證，增加源站的負載和延遲。 1.2.4Cache-Control HTTP headers HTTP 1.0缺乏對cache設備緩存動作的控制方法，HTTP 1.1引入 了一種新的headers：Cache-Control response headers， web發行系統可以通過它解決頁面過期問題，實現對頁面內容的更多地控制 可用的Cache-Control response headers 包括：cdn方案建議書篇二：店鋪裝修優化建議 商家店鋪裝修優化建議 一、 背景 目前店中店商家店鋪由商家自己裝修。商家在裝修店鋪過程中造成了一些問題。其中最為嚴重的就是網頁速度過慢。為了提升頁面速度，提高客戶體驗和轉化率。特制訂該規范。 二、 問題概述 1，嵌套外部網站xml 外部網站xml數據傳輸比較慢.有的數據量比較大.并且很多是垃圾數據.并且在頁面沒有加載完情況.沒有數據顯示.造成了頁面加載速度慢. 解決方法建議：不引用外部網站XML 2，嵌套外部網站swf 網站中swf格式文件加載速度比較慢.目前在很多網站已經禁止在頁面使用swf格式文件，改為用js方式實現。目前店鋪中還有很多這種情況。 解決方法建議：不嵌套外部網站swf，改用js方式實現 3使用很多大圖片 網站圖片過大.直接造成了頁面加載速度慢.嚴重情況圖片請求超時打不開. 解決方法建議：壓縮圖片大小，控制圖片大小在100K以下 4外鏈了很多第三方網站js 外鏈js一方面加載速度慢.另一方面執行時候效率沒有保證.嚴重情況會造成用戶瀏覽器死機. 解決方法建議：不外鏈第三方js，可在自定義模塊中添加js。 5外鏈了很多沒有經過cdn優化處理的網站的圖片 由于某些網站圖片沒有走cdn.只在一個指定區域或者網絡運營商下打開速度可以.其它情況不支持. 解決方法建議：使用一號店圖片空間或淘寶相冊或有cdn加速的圖片空間。 6. 自定義模塊太多并且不規范造成頁面渲染過慢 自定義模塊過多,并且不規范造成了頁面渲染速度過慢. 解決方法建議：減少自定義模塊，模塊建議不多于三個 三、 舉例 商家：新農哥 原本店鋪打開速度為6.8s，新農哥參照我們提出優化建議進行修改，現在店鋪打開速度已經降到3.8s，提高了56%。 以下為新農哥店鋪的優化點： 四、 規范店鋪裝修建議 1、通欄自定義模塊.輪換廣告模塊980寬度的圖片不超過3張,高度不超過200px 2、中欄或者兩欄的右欄自定義模塊輪換廣告圖片高度不超過300px 3、自定義模塊采用div，css樣式，去除table格式,并且整個店鋪首頁自定義模塊不多于3個 4、 不引用外部xml格式數據 ，js文件以及swf文件 5、店鋪內建議只使用1號店或淘寶或有cdn加速的圖片空間,并且圖片禁止超過100KB,最好控制在50KB以內cdn方案建議書篇三：IPS解決方案建議 采用入侵防御系統 網絡安全解決方案 1. 需求分析 1.1 權威研究指出系統入侵/滲透是目前最大的安全威脅 VanDyke Software 組織的一次廣泛而具有影響力的調查顯示，66% 的公司認為系統滲透是政府、組織和企業所面臨的最大威脅。 該項調查還顯示，被調查企業所經歷的最為嚴重的八種威脅分別是：病毒（占 78%）、系統滲透（占 50%）、DoS (占 40%)、內部人員錯誤操作（占 29%）、電子欺詐（占 28%）、數據或網絡故障（占 20%）以及內部人員的非法訪問（占 16%）。 圖 1 權威調查揭示2/3的受訪者認為系統滲透/入侵是面臨的最大安全威脅 1.2 現有的安全架構無法應對系統入侵的新威脅 雖然在被調查的企業中，有 86% 已經部署了防火墻（老實說，相對于時代的發展和今天的大環境，這個數字低得讓人無法接受），但很明顯，防火墻面對很多入侵行為仍然無計可施。普通的防火墻設計旨在拒絕那些明顯可疑的網絡流量（例如，企業的安全策略完全禁止 Telnet 訪(轉 載于:wWw.xmsJOB.cOm 廈門培 訓 考 試 網:cdn方案)問，但仍有某些用戶試圖通過 Telnet 訪問某個設備），但仍允許某些流量通過（例如，發送到內部 Web 服務器的 Web 流量）。 圖 2 現有的FW無法識別攔截應用層面攻擊 問題在于，很多攻擊都會嘗試利用那些外圍防火墻允許通過的協議的漏洞，而且，一旦 Web 服務器遭到攻擊，攻擊者會以此為跳板繼續對其它內部服務器發起攻擊。一旦服務器上被安裝了“rootkit”或“后門”，那么黑客們就能夠在未來的任何時間里“大搖大擺”地訪問這臺機器。 一般來說，我們僅將防火墻部署在網絡外圍。但很多攻擊，無論是全球性攻擊還是其它類型的攻擊，往往都是從組織內部發起的。虛擬專用網、便攜式計算機以及無線網絡都能夠接入到內部網絡，而且經常會越過防火墻。入侵檢測系統在檢測可疑活動時可能很有效，但卻不能提供對攻擊的防護。臭名昭著的蠕蟲（例如 Slammer 和 Blaster）都具有驚人的傳播速度，當系統發出警報時，蠕蟲實際上已經導致了損失，而且正在飛速地向外擴散。 圖 3 攻擊歷史回顧提醒我們蠕蟲的快速傳播曾造成巨大損失 1.3 安全缺口在擴大 隨之網絡和應用的不斷發展，安全的需求也在不斷增長，而我們現有的安全能力卻沒有提高，造成安全缺口不斷在擴大，如下圖所示： 圖 4 安全缺口在不斷擴大 1.4 系統和網絡安全面臨的實際問題 依靠現有的FW、IDS等安全設備，我們已經不能及時掌握網絡和系統的安全狀況，也無法及時攔截攻擊和進行補救。下面是一些亟待解決的問題： 1. FW、IDS已經不能保護應用安全，攻擊能夠穿透防火墻，比如SQL注入攻擊，而我們不可能將SQL使用的TCP端口在防火墻上關閉，因為這樣會將正常的SQL操作也阻斷。這說明FW不能對數據流作深度分析，不能檢測到應用層面的攻擊，僅起到訪問控制的作用，而IDS雖然能夠監測到攻擊，但是卻不能夠及時自動的攔截攻擊，需要大量的人工干預，效率較低。 2. 網絡中的設備和系統越來越多，同時，這些設備和系統使用的操作系統和應用軟件存在的漏洞也不斷被發現，應用層面的攻擊正是利用了這些漏洞，比如，微軟已經公布了很多Web 服務器軟件 IIS和數據庫軟件