http協議----基於請求報文和響應報文完成一次http事務

應用層協議格式有兩種： 文字（開發容易，但互動解析困難如http smtp)，二進位制（互動解析容易，但理解起來困難memocache)

狀態碼：304 已經請求過，但是資源沒什麼改變返回304；對於get請求，只返回head，以表示資源有沒有

快取：在速度不匹配之間的網路元件之間新增快取以達到效能最優。請求首部中的if-Modified-Since,If-None-Match是關鍵資訊

 user-agent載入的僅僅是web框架，資源家在的過程就是向伺服器請求的過程，如果一個頁面有很多url，逐一請求主機的話，浪費時間，就需要通過快取提高載入速度，如果是多核資源，可能併發2個請求

所以，對於伺服器，可能同時接受到2個或多個請求，但這可能來自同一個請求客戶端！！！

現如今，伺服器面對的成千上萬的併發也就毫不奇怪了，常見的優化方式:例如看到第一屏，(只加載第一屏,除非新增滾輪)，或者壓垮所有服務。

pv:整個頁面有很多請求(連結)，通過日誌資料探勘做廣告投放和使用者行為分析，雖然有站長統計工具，但大型網站最好自行統計pv；計算標準是訪問一個網站入口後能完整的呈現頁面就算是一個pv

uv:獨立IP，日uv，一天內有多少獨立ip地址發起過頁面訪問

 為了客戶端開啟頁面時儘可能的快：通常的做法有：載入快取和併發訪問，不過現如今瀏覽器都是多執行緒的，任意瀏覽器對於單個域名執行緒數是有上限的，例如訪問域名A，開啟兩個執行緒，訪問域名B，開啟兩個執行緒

所以對於同一網站可以設定多個二級域名，並把資源，如圖片，視訊，文字檔案分散部署到各二級域名的方法來實現一個站點開啟多執行緒的方式達到訪問效率的優化。

httpd mpm多路處理模組有三種模式：prefork 主程序以管理員身份啟動生成多個子程序，可以監聽80埠，凡小於1024埠號的謂之特權埠

•  I/O型別：所謂I/O，一方請求服務，另一方呼叫服務，那麼，請求方如何得知什麼時候得知自己的請求被響應了呢（如何通知呼叫者)

同步synchronous:呼叫發出後，不會立即返回，一旦返回，則返回最終結果

非同步asychronous呼叫發出後，被呼叫方立即反饋訊息，但並非最終結果，被呼叫者通過回撥函式，狀態資訊，通知機制等通知呼叫方處理結果(銀行服務，拿到排隊號，被叫號的過程)

上述關注的是訊息通知的機制

------------------------------------------------------

以下關注的是請求發出者等待被呼叫者返回結果時的狀態

阻塞block：呼叫者沒結果一直出等待狀態，被掛起

非阻塞non-block：呼叫者不會被阻塞

• 阻塞式I/O blocking I/O：一個程序通常只能處理單步I/O
• 非阻塞式I/O：盲等待，polling模型正基於此，過一段時間就去諮詢是否完成，效率不一定優於阻塞，所謂非阻塞，是指從磁碟載入資料到核心空間這一段；從核心記憶體複製到應用程序階段仍是阻塞的
• I/O多路複用，一個程序只能處理單步I/O，以向伺服器請求資源為例，一步負責監聽請求(網路I/O)，一步負責請求資料，由於從核心空間複製資料到應用程序記憶體時處於阻塞狀態，這時程序處於“不可終止睡眠狀態”，即使網路I/O發生異動也不可能作出響應，按理說，在請求時間過長時，我們也無法取消請求，可現實生活中的例子告訴我們，我們確實可以取消請求，這就是多路複用I/O(無非是在網路請求和磁碟請求之間添加了一個“代理”，代i理會轉發請求給空閒的程序，支援兩路以上的複用----這就是select() 由BSE研發 poll()和select()功能一致，但是侷限在於1024條請求，儘管可以改程式碼，但實際上1024是併發的極限，超出後拒絕服務，select是複用代理)---其實還得阻塞，只不過可以分身乾點別的

• 事件驅動式I/O：被呼叫者會回覆呼叫者-----你的請求我拿到了，10分鐘後ok，你可以先乾點別的，這就免去了盲等(這一階段一個程序可以處理n個請求);然而第二步從核心記憶體到程序記憶體的過程依然阻塞；一旦收到就緒的通知，會呼叫回撥函式完成後續的操作(callback)
• 非同步I/O

一個典型的應用程序發起I/O請求的步驟

向核心空間請求資料-------->核心沒有------>向磁碟請求資料------>把磁碟資料複製到核心記憶體----->再把資料拷貝到應用程序記憶體（每個應用程序都有各自獨立的空間）；真正的I/O過程就是從核心複製資料到應用程序記憶體的那一步