因為近來百度更新，要得有個網站在百度的名次消逝了，無可奈何調查了一下子網站的過訪日記，以便剖析名次消逝的端由。想要看懂網站的過訪日記，就務必理解些參變量表達的意義，在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。
下邊我們就幾個案件的例子施行恢復：
案件的例子一：某網站的日記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 /searchout.asp 200 17735 369 4656
這處我們可以獲得的資料是：這是一臺裝有IIS version 6的WEB服務器(經過#Software標識)，版本是1.0(#Version標識)，成日子是2005年元月三號的後半晌4點正(#Date標識)，下不熟悉成的W3C日記內部實質意義(經過#Fields標識)涵蓋日子、時間、Clientto Server的辦法、讀取的對象、參變量、客戶端的IP地址、客戶端上一個過訪的對象、服務回返的狀況、Server to Client的字節、Server收繳到的字節、處置該條目標操作一共運用的時間。最終恢復的最後結果是：
在2005年元月一號的後半晌4時2分22秒，70.25.29.53這個IP地址的客戶端向我們的服務器提交處理了一個GET：
/Enterprise/detail.asp?id=1612186
網址的煩請，這個煩請提交處理的網址有可能是從/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)，過載請注明來源。