網站排名核心技巧：如何正確分析W3C擴展日誌

仲介交易 HTTP://www.aliyun.com/zixun/aggregation/6858.html">SEO診斷 淘寶客 雲主機 技術大廳

由於最近百度更新，使得有個網站在百度的排名消失了，不得已調查了一下網站的訪問日誌，以便分析排名消失的原因。 想要看懂網站的訪問日誌，就必須瞭解些參數表示的意義，在IIS6.0中，這些參數是非常標準的，對我們分析蜘蛛的爬行和網頁的收錄是有非常大的説明的。

下面就讓我們來耐心的學習這些參數吧。

注：以下部分翻譯自Microsoft網站--《W3C Extended Log File Format (IIS 6.0)》的解釋。

W3C擴展日誌檔案格式是IIS(Microsoft IIS)的預設日誌格式，其內容編碼為預設的ASCII文本。 你可以通過IIS管理器選擇各種不同的欄位包含在這種日誌檔內，這樣可以使你的日誌內容更加人性化。 其實系統是通過HTTP.sys控制碼來處理W3C擴展日誌的，W3C內容格式完全是通過讀取HTTP.sys的內核緩存進行篩選獲取的。

下表中列出各種可選欄位(「欄位標識」列為實際參數名)及其描述，並通過Default列記錄該欄位是否預設被‘包含’了。

「欄位」 「欄位標識」 「描述」 「Default(Y/N )」

日期 date 動作發生時的日期。 Y

時間 time 動作發生時的時間(預設為UTC標準)。 Y

用戶端IP位址 c-ip 訪問伺服器的用戶端IP位址。 Y

使用者名 cs-username 通過身份驗證的訪問伺服器的使用者名。 不包括匿名使用者(用‘-’表示)。 Y

服務名 s-sitename 客戶所訪問的Internet服務名以及實例號。 N

伺服器名 s-computername 產生日誌條目的伺服器的名字。 N

伺服器IP 位址 s-ip 產生日誌條目的伺服器的IP位址。 Y

伺服器埠 s-port 服務端提供服務的傳輸層埠。 Y

方法 cs-method 用戶端執行的行為(主要是GET與POST行為)。 Y

URI Stem cs-uri-stem 被訪問的資源，如Default.asp等。 Y

URI Query cs-uri-query 用戶端提交的參數(包括GET與POST行為)。 Y

協定狀態 sc-status 用HTTP或者FTP術語所描述的、行為執行後的返回狀態。 Y

Win32狀態 sc-win32-status 用Microsoft Windows的術語所描述的動作狀態。 N

傳送的位元組數 sc-bytes 服務端發送給用戶端的位元組數。 N

接受位元組數 cs-bytes 服務端從用戶端接收到的位元組數。 N

花費時間 time-taken 執行此次行為所消耗的時間，以毫秒為單位。 N

協定版本 cs-version 用戶端所用的協定(HTTP、FTP)版本。 對HTTP協定來說是HTTP 1.0或者HTTP 1.1。 N

主機 cs-host 用戶端的HTTP報頭(host header)資訊。 N

使用者代理 cs(User-Agent) 用戶端所用的瀏覽器版本資訊。 Y

Cookie cs(Cookie) 發送或者接受到的cookie內容。 N

Referrer cs(Referer) 使用者流覽的前一個網址，當前網址是從該網址連結過來的。 N

協定底層狀態 sc-substatus 協定底層狀態的一些錯誤資訊。 Y

關於status codes欄位的更多詳細資料請流覽：「HTTP://go.microsoft.com/fwlink/?LinkId=14381」。

注：其實我們對比一下實際操作會發現「Default」一列是與客觀事實有些出入的:P。

下面我們就幾個案例進行「還原」：

案例一：某網站HTTP://www.test.com的日誌ex050104.log的一段內容：

#Software: Microsoft Internet Information Services 6.0

#Version: 1.0

#Date: 2005-01-03 16:00:00

#Fields: date time cs-method cs-uri-stem cs-uri-query c-ip cs(Referer) sc-status sc-bytes cs-bytes time-taken

2005-01-01 16:02:22 GET /Enterprise/detail.asp id=1612186 70.25.29.53 HTTP://www.test.com/searchout.asp 200 17735 369 4656

這裡我們可以得到的資料是：這是一台裝有IIS version 6的WEB伺服器(通過#Software標識)，版本是1.0(#Version標識)，成日期是2005年1月3日的下午4點正(#Date標識)， 下面生成的W3C日誌內容(通過#Fields標識)包括日期、時間、Clientto Server的方法、讀取的物件、參數、用戶端的IP位址、用戶端上一個訪問的物件、服務返回的狀態、Server to Client的位元組、 Server接收到的位元組、處理該條目的操作總共使用的時間。 最後還原的結果是：

在2005年1月1日的下午4時2分22秒，70.25.29.53這個IP位址的用戶端向我們的伺服器提交了一個GET：

HTTP://www.test.com/Enterprise/detail.asp?id=1612186

網址的請求，這個請求提交的網址可能是從HTTP://www.test.com/searchout.asp連結過來的，本次操作返回「操作成功」應答(成功完成操作)，此次操作中服務端發送給用戶端17735個位元組的資料， 服務端也接收到369個位元組的資料，此次操作總共花了4656毫秒。

從上面的知識點不難看到，其實我們要通過W3C擴展日誌對HTTP應用層行為進行監控的話，以下幾個欄位的記錄是必不可少的：

date、time、cs-method、cs-uri-stem、cs-uri-query、c-ip、cs-version、cs(User-Agent)、cs(Referer)、sc-status、

sc-bytes、cs-bytes、time-taken、cs-host、cs(Cookie)。 解說一下：

date和time就不用說了;

cs-method與cs-uri-stem、cs-uri-query聯合起來，很快就可以還原出c-ip究竟進行過怎麼樣的請求;

sc-status可以説明我們辨別這個請求是否成功‘執行’，從而辨別現象與這個請求操作的依從性;

cs-version、cs(User-Agent)、cs(Referer)、cs-bytes、cs-host與cs(Cookie)可以作為一個類比的特徵指紋，鑒別出一些非正常的請求，如HTTP探測、HTTP DoS與CC等 ;

cs-bytes、sc-bytes與time-taken可以説明我們辨別本次請求所耗費的各種資源的情況(如對頻寬的影響、CPU/記憶體資源佔用的影響)。

通過學習這些參數的含義後，我非常輕鬆地看完了網站訪問日誌，從中分析出了排名消失的初步原因或主要原因，為進一步調整優化提供了依據。 最後，一套行之有效的總結、歸類、對比方法可以更快地幫你定位到問題的根源，例如：「通過多個cs-uri-query的值相同或相似，且發生的時間點幾乎一致等各種因素，判斷其可能遭受過CC攻擊」等，這樣的案例常有存在， 關鍵看自己的領悟了。

　　91SEO小站(www.91seo.net)，轉載請注明出處。