前端學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伺服器和代理一定要注意保護其終端使用者的隱私

　　有些情況下，比如在工作環境中，跟蹤某使用者的使用情況以確保他沒有偷懶是可行的，但管理員也應該將監視大家事務處理的事情公之於眾

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