前端學HTTP之日誌記錄

前面的話

　　幾乎全部的服務器和代理都會記錄下它們所處理的HTTP事務摘要。這麼作出於一系列的緣由：跟蹤使用狀況、安全性、計費、錯誤檢測等等。本文將介紹日誌記錄

 

記錄內容

　　大多數狀況下，日誌的記錄出於兩種緣由：査找服務器或代理中存在的問題(好比，哪些請求失敗了)，或者是生成Web站點訪問方式的統計信息。統計數據對市場營銷、計費和容量規劃(好比，決定是否須要增長服務器或帶寬)都很是有用

　　能夠把一個HTTP事務中全部的首部都記錄下來，但對天天要處理數百萬個事務的服務器和代理來講，這些數據的體積超大，很快就會失控。不該該記錄實際上並不感興趣，甚至歷來都不會去看一眼的數據

　　一般，只記錄事務的基本信息就好了。一般會記錄下來的幾個字段示例爲：HTTP方法；客戶端和服務器的HTTP版本；所請求資源的URL；響應的HTTP狀態碼；請求和響應報文的尺寸(包含全部的實體主體部分)；事務開始時的時間戳；Referer首部和User-Agent首部的值

　　HTTP方法和URL說明了請求試圖作些什麼——好比，GET某個資源或POST某個訂單。能夠用URL來記錄Web站點上頁面的受歡迎程度

　　版本字符串給出了與客戶端和服務器有關的一些提示，在客戶端和服務器之間出現一些比較奇怪或非預期的交互動做時，它會很是有用。好比，若是請求的失敗率高於預期，那版本信息指向的多是一個沒法與服務器進行交互的新版瀏覽器

　　HTTP狀態碼說明了請求的執行情況：是否成功執行，認證請求是否失敗，資源是否找到等

　　請求/響應的大小和時間戳主要用於記帳——記錄流入、流出或流經應用程序的字節有多少。還可用時間戳將觀察到的問題與當時發起的一些請求關聯起來

 

日誌格式

　　大部分商用和開源的HTTP應用程序都支持以一種或多種經常使用格式進行日誌記錄。不少這樣的應用程序都支持管理者配置日誌格式，建立自定義的格式

　　應用程序支持管理者使用這些更標準的格式的主要好處之一在於，能夠充分利用那些已構建好的工具處理這些日誌，併產生基本的統計信息。有不少開源包和商用包均可用來壓縮日誌，以進行彙報。使用標準格式，應用程序及其管理員就均可以利用這些包了

【常見日誌格式】

　　如今，最多見的日誌格式之一就是經常使用日誌格式。這種日誌格式最初由NCSA定義，不少服務器在默認狀況下都會使用這種日誌格式。能夠將大部分商用及開源服務器配置爲使用這種格式，有不少商用及免費工具均可輔助解析經常使用日誌格式的文件。下表按序列出了經常使用日誌格式中的字段

　　下面列出了幾個常見日誌格式條目

　　在這些例子中，字段的分配以下所示

　　[注意]remotehost字段能夠是http-guide.com那樣的主機名，也能夠是209.1.32.44這樣的IP地址

　　第二個(usemame)和第三個(auth-username)字段之間的破折號說明字段爲空。這說明要麼是沒有進行ident査找(第二個字段爲空)，要麼是沒有進行認證(第三 個字段爲空)

【組合日誌格式】

　　另外一種經常使用日誌格式爲組合日誌格式(Combined Log Format)，例如Apache服務器就支持這種格式。組合日誌格式與經常使用日誌格式很相似。實際上，它就是經常使用日誌格式的精確鏡像，只是添加了兩個字段。User-Agent字段用於說明是哪一個HTTP客戶端應用程序在發起已被記錄的請求，而Referer字段則提供了更多與請求端在何處找到這個URL的有關信息

　　下面列出了新加的組合日誌格式字段

字段                描述
Referer            Referer首部的內容
User-Agent         User-Agent首部的內容    

　　下例給出了一個組合日誌格式的條目

　　Referer字段和User-Agent字段的值以下所示 

　　上面的組合日誌格式條目示例中的前七個字段和經常使用日誌格式中的徹底同樣。兩個新字段Referer和User-Agent附加在日誌條目的末尾

【網景擴展日誌格式】

　　網景進入商用HTTP應用程序領域時，爲其服務器定義了不少其餘HTTP應用程序開發者已接納的日誌格式。網景的格式是基於NCSA的經常使用日誌格式的，但它們擴展了該格式，以支持與代理和Web緩存這樣的HTTP應用程序相關的字段

　　網景擴展日誌格式的前7個字段與經常使用日誌格式中的那些字段徹底相同。下表按序列出了網景擴展日誌格式引入的新字段

　　下面給出了一個網景擴展日誌格式的條目

209.1.32.44    - - [03/Oct/2016:14:16:00-0400] "GET / HTTP/1.0" 200 1024 200 1024 0 0 215 260
279 254 3

　　在這個例子中，擴展字段的值以下所示

　　上面的網景擴展日誌格式條目示例中的前7個字段是經常使用日誌格式條目示例的鏡像

　　另外一種網景日誌格式，網景擴展2日誌格式採用了擴展日誌格式，並添加了一些與HTTP代理和Web緩存應用程序有關的附加信息。這些附加字段有助於更好地描繪HTTP客戶端和HTTP代理應用程序間的交互圖景

　　網景擴展2日誌格式是基於網景擴展日誌格式的，初始字段與網景擴展日誌的字段徹底相同

　　下表按序列出了網景擴展2日誌格式新加的字段

　　下例給出了一個網景擴展2日誌格式的條目

209.1.32.44    - - [03/Oct/2016:14:16:00-0400] "GET / HTTP/1.0" 200 1024 200 1024 0 0 215 260 
279 254 3 DIRECT FIN WRITTEN

　　這個例子中拓展字段的值以下所示

　　上面的網景擴展2日誌格式條目中的前16個字段就是網景擴展日誌格式示例條目的鏡像

　　下表列出了有效的網景路由代碼

　　下表列出了有效的網景完成狀態碼

　　下表列出了有效的網景緩存代碼

　　與不少其餘HTTP應用程序同樣，網景應用程序也有其餘的日誌格式，包括一種靈活日誌格式和一種管理者輸出自定義日誌字段的方式。這些格式給予管理者更大的控制權，並能夠選擇在日誌中報告HTTP事務處理的哪些部分(首部、狀態、尺寸等)，以自定義其日誌

　　因爲很難預測管理者但願從其日誌中獲取哪些信息，才添加了管理者配置自定義格式的能力。不少其餘的代理和服務器都有發佈自定義日誌的能力

【Squid代理日誌格式】

　　Squid代理緩存(http://www.squid-cache.org)是Web上一個很古老的部分。其起源能夠回溯到一個早期的Web代理緩存項目(ftp://ftp.cs.colorado.edu/pub/techreports/schwartz/Harvest.Conf.ps.Z)。Squid是開源社團多年來擴展加強的一個開源項目。有不少工具能夠用來輔助管理Squid應用程序，包括一些有助於處理、審覈及開發其日誌的工具。不少後繼代理緩存都爲本身的日誌使用了Squid格式，這樣才能更好地利用這些工具

　　Squid日誌條目的格式至關簡單。下表總結了該日誌格式的字段

　　下面給出了一個Squid日誌格式條目的例子

　　這些字段的值以下所示

　　下表列出了各類Squid結果代碼

命中率測量

　　原始服務器一般會出於計費的目的保留詳細的日誌記錄。內容提供者須要知道URL的受訪頻率，廣告商須要知道廣告的出現頻率，網站做者須要知道所編寫的內容的受歡迎程度。客戶端直接訪問Web服務器時，日誌記錄能夠很好地跟蹤這些信息

　　可是，緩存服務器位於客戶端和服務器之間，用於防止服務器同時處理大量訪問請求(這正是緩存的目的)。緩存要處理不少HTTP請求，並在不訪問原始服務器的狀況下知足它們的請求，服務器中沒有客戶端訪問其內容的記錄，致使日誌文件中出現遺漏

　　因爲日誌數據會遺失，因此，內容提供者會對其最重要的頁面進行緩存清除(cache bust)。緩存清除是指內容提供者有意將某些內容設置爲沒法緩存，這樣，全部對此內容的請求都會被導向原始服務器。因而，原始服務器就能夠記錄下訪問狀況了。不使用緩存可能會生成更好的日誌，但會減緩原始服務器和網絡的請求速度，並增長其負荷

　　因爲代理緩存(及一些客戶端)都會保留本身的日誌，因此若是服務器可以訪問這些日誌(或者至少有一種粗略的方式能夠判斷代理緩存會以怎樣的頻率提供其內容)，就能夠避免使用緩存清除。命中率測量協議是對HTTP的一種擴展，它爲這個問題提供了一種解決方案。命中率測量協議要求緩存週期性地向原始服務器彙報緩存訪問的統計數據

　　命中率測量協議定義了一種HTTP擴展，它提供了一些基本的功能，緩存和服務器能夠實現這些功能來共享訪問信息，規範已緩存資源的可以使用次數

　　緩存給日誌訪問帶來了問題，命中率測量並非這個問題的完整解決方案，但它確實提供了一種基本方式，以獲取服務器但願跟蹤的度量值。命中率測量協議並無(並且可能永遠都不會)獲得普遍的實現或應用。也就是說，在維護緩存性能增益的同時，像命中率測量這樣的合做方案會給出一些提供精確訪問統計信息的承諾。但願這會推進命中率測量協議的實現，而不是把內容標記爲不可緩存的

【Meter 首部】

　　命中率測量擴展建議使用新增長的首部Meter，緩存和服務器能夠經過它在相互間傳輸與用法和報告有關的指令，這與用來進行緩存指令交換的Cache-Control首部很相似

　　下表列出了定義的各類指令和誰能夠在Meter首部傳輸這些指令

　　下圖給出了一個執行中的命中串測量實例。事務的第一部分就是客戶端和代理緩存之間一個普通的HTTP事務，但在代理請求中，要注意有插入的Meter首部和來自服務器的響應。這裏，代理正在通知服務器它能夠進行命中率測量。做爲迴應，服務器則請求代理報告它的命中次數

　　從客戶端的角度來看，請求正常結束了，代理開始表明服務器跟蹤該請求資源的命中次數。稍後，代理會嘗試與服務器再次驗證資源。代理會在發送給服務器的條件請求中嵌入它跟蹤記錄的計量信息

 

隱私

　　日誌記錄實際上就是服務器和代理執行的一項管理功能，因此整個操做對用戶來講都是透明的。一般，用戶甚至都不清楚他們的HTTP事務已被記錄

　　Web應用程序的開發者和管理者要清楚跟蹤用戶的HTTP事務可能帶來的影響。他能夠根據獲取的信息收集不少有關用戶的狀況。很顯然，這些信息能夠用於不良目的——歧視、騷擾、勒索等。進行日誌記錄的Web服務器和代理必定要注意保護其終端用戶的隱私

　　有些狀況下，好比在工做環境中，跟蹤某用戶的使用狀況以確保他沒有偷懶是可行的，但管理員也應該將監視你們事務處理的事情公之於衆

　　簡單來講，日誌記錄對管理者和開發者來講都是頗有用的工具。只是要清楚在沒有得到用戶許可，或在其不知情的狀況下，使用記錄其行爲的日誌可能會存在侵犯隱私的問題