A. wireshark可以過濾http地址么
一、IP過濾：包括來源IP或者目標IP等於某個IP
比如：ip.src addr==192.168.0.208 or ip.src addr eq 192.168.0.208 顯示來源IP
ip.dst addr==192.168.0.208 or ip.dst addr eq 192.168.0.208 顯示目標IP
二、埠過濾：
比如：tcp.port eq 80 // 不管埠是來源的還是目標的都顯示
tcp.port == 80
tcp.port eq 2722
tcp.port eq 80 or udp.port eq 80
tcp.dstport == 80 // 只顯tcp協議的目標埠80
tcp.srcport == 80 // 只顯tcp協議的來源埠80
過濾埠范圍
tcp.port >= 1 and tcp.port <= 80
三、協議過濾：tcp
udp
arp
icmp
http
smtp
ftp
dns
msnms
ip
ssl
等等
排除ssl包，如!ssl 或者 not ssl
四、包長度過濾：
比如：
udp.length == 26 這個長度是指udp本身固定長度8加上udp下面那塊數據包之和
tcp.len >= 7 指的是ip數據包(tcp下面那塊數據),不包括tcp本身
ip.len == 94 除了乙太網頭固定長度14,其它都算是ip.len,即從ip本身到最後
frame.len == 119 整個數據包長度,從eth開始到最後
五、http模式過濾：
例子:
http.request.method == 「GET」
http.request.method == 「POST」
http.request.uri == 「/img/logo-e.gif」
http contains 「GET」
http contains 「HTTP/1.」
// GET包
http.request.method == 「GET」 && http contains 「Host: 」
http.request.method == 「GET」 && http contains 「User-Agent: 」
// POST包
http.request.method == 「POST」 && http contains 「Host: 」
http.request.method == 「POST」 && http contains 「User-Agent: 」
// 響應包
http contains 「HTTP/1.1 200 OK」 && http contains 「Content-Type: 」
http contains 「HTTP/1.0 200 OK」 && http contains 「Content-Type: 」
一定包含如下
Content-Type:
六、連接符 and / or
B. wireshark 怎樣過濾http協議內容
在wireshark軟體的那個filter框框裡面輸入http，就能只過濾HTTP協議的內容了。
C. 如何通過HTTP狀態碼查看搜索引擎蜘蛛如何爬行我的網站的
看IIS日誌或者apache日誌，發現有spider什麼的，就知道蜘蛛來過了。蜘蛛來了爬了幾頁，日誌裡面都會很清楚的反應出來。包括是否收錄，是否沒有找到頁面等。
D. 怎麼屏蔽蜘蛛爬取
在網站的根目錄裡面，放入robots.txt文件，這樣就可以屏蔽蜘蛛的爬取，不過在文件裡面要放入你不想讓蜘蛛爬取的地方。詳細的內容你打開這個網址可以看到 http://help..com/question?prod_en=search&class=499
E. 百度蜘蛛訪問日誌全HEAD開頭,是什麼意思
我回答下吧 網路會定期的訪問你的網頁 但又不想下載你網頁的全部內容 所以用HEAD的方法 HEAD 一般情況下會在伺服器上產生與GET相同的處理（除非代碼中對HEAD的情況做了處理），只不過返回給客戶端的是header信息，而沒有正文。通過這種HEAD請求，可以利用極少量的帶寬來獲得某網頁的頭部信息。通過頭信息中的HTTP狀態碼(200等)， 網路可以了解這個網頁的大體狀態，比如是否存在，是否轉向，是否可用等；通過Content-Length, Last-Modified 中的任一項與之前的訪問記錄做對比，網路可以進一步判斷這個網頁是否需要更新。一般都返回200 0 0所以你不要擔心以上內容是經過研究的
F. dotnet 實現對http訪問的請求及應答，最好能自定義埠號，不用webservice
HTTP協議我想任何IT人士都耳熟能詳了，大家都能說出個所以然來。但是如果我問你HTTP協議的請求方法有哪些？POST與GET的差異？GET或POST傳送數據量的大小有限制嗎？HTTP響應的狀態有哪些？以及在C#中你如何使用？如果你不能清楚地回答其中的大部分問題，那麼這篇文章就是為你准備的！大綱如下：
1、HTTP概述
1.1、HTTP協議的客戶端與伺服器的交互
1.2、HTTP消息
1.3、HTTP請求的方法
1.4、HTTP響應的代碼
2、抓包分析
3、POST與GET的差異
4、以一個實例說明C#中如何使用POST、GET等操作
4.1、HttpWebRequest
4.2、HttpWebResponse
4.3、編寫WinForm程序打開博客園首頁（附源碼）
1、HTTP概述
為了喚醒你對HTTP協議的記憶或使你能夠對HTTP協議有所了解，首先簡單一下HTTP協議。超文本傳輸協議（HTTP，HyperTextTransferProtocol）是互聯網上應用最為廣泛的一種網路協議。所有的WWW文件都必須遵守這個標准。設計HTTP最初的目的是為了提供一種發布和接收HTML頁面的方法。
HTTP的發展是萬維網協會（WorldWideWebConsortium）和Internet工作小組（InternetEngineeringTaskForce）合作的結果，（他們）最終發布了一系列的RFC，其中最著名的就是RFC2616。RFC2616定義了HTTP協議中一個現今被廣泛使用的版本——HTTP1.1。
1.1、HTTP協議的客戶端與伺服器的交互
HTTP是一個客戶端和伺服器端請求和應答的標准（TCP）。客戶端是終端用戶，伺服器端是網站。通過使用Web瀏覽器、網路爬蟲或者其它的工具，客戶端發起一個到伺服器上指定埠（默認埠為80）的HTTP請求。（我們稱這個客戶端）調用戶代理（useragent）。應答的伺服器上存儲著（一些）資源，比如HTML文件和圖像。（我們稱）這個應答伺服器為源伺服器（originserver）。在用戶代理和源伺服器中間可能存在多個中間層，比如代理，網關，或者隧道（tunnel）。盡管TCP/IP協議是互聯網上最流行的應用，HTTP協議並沒有規定必須使用它和（基於）它支持的層。事實上，HTTP可以在任何其他互聯網協議上，或者在其他網路上實現。HTTP只假定（其下層協議提供）可靠的傳輸，任何能夠提供這種保證的協議都可以被其使用。
通常，由HTTP客戶端發起一個請求，建立一個到伺服器指定埠（默認是80埠）的TCP連接。HTTP伺服器則在那個埠監聽客戶端發送過來的請求。一旦收到請求，伺服器（向客戶端）發回一個狀態行，比如"HTTP/1.1200OK"，和（響應的）消息，消息的消息體可能是請求的文件、錯誤消息、或者其它一些信息。
HTTP使用TCP而不是UDP的原因在於（打開一個）一個網頁必須傳送很多數據，而TCP協議提供傳輸控制，按順序組織數據，和錯誤糾正。通過HTTP或者HTTPS協議請求的資源由統一資源標識符（UniformResourceIdentifiers，或者，更准確一些，URI）來標識。
客戶端與伺服器端的結構與交互過程可以表示為下面2張圖：
圖1、Web客戶端-伺服器端結構（其中web伺服器的超文本鏈接，即通過網站上的一個鏈接跳轉到了其他伺服器上）
圖2、Web客戶端與伺服器端的交互
1.2、HTTP消息
客戶端與伺服器之間的交互用到了兩種類型的消息：請求（Request）和響應（Response）。
HTTP請求的格式為：圖3、HTTP請求的格式
HTTP響應的格式為：圖4、HTTP響應的格式
從上面可以看出HTTP的請求和響應消息的首部均包含可變數量的欄位，用一個空行（blankline）將所有首部欄位（header）與消息主體（body）分隔開來。一個首部欄位由欄位名和隨後的冒號、一個空格和欄位值組成，欄位名不區分大小寫。
報文頭可分為三類：一類應用於請求，一類應用於響應，還有一類描述主體。有一些報文頭（例如：Date）既可用於請求又可用於響應。描述主體的報文頭可以出現在POST請求和所有響應報文中。HTTP的首部欄位如下圖所示：圖5、HTTP首部欄位
1.3、HTTP請求的方法
HTTP/1.1協議中共定義了八種方法（有時也叫「動作」）來表明Request-URI指定的資源的不同操作方式：
OPTIONS
返回伺服器針對特定資源所支持的HTTP請求方法。也可以利用向Web伺服器發送'*'的請求來測試伺服器的功能性。
HEAD
向伺服器索要與GET請求相一致的響應，只不過響應體將不會被返回。這一方法可以在不必傳輸整個響應內容的情況下，就可以獲取包含在響應消息頭中的元信息。
GET
向特定的資源發出請求。注意：GET方法不應當被用於產生「副作用」的操作中，例如在WebApplication中。其中一個原因是GET可能會被網路蜘蛛等隨意訪問。
POST
向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。
PUT
向指定資源位置上傳其最新內容。
DELETE
請求伺服器刪除Request-URI所標識的資源。
TRACE
回顯伺服器收到的請求，主要用於測試或診斷。
CONNECT
HTTP/1.1協議中預留給能夠將連接改為管道方式的代理伺服器。
方法名稱是區分大小寫的。當某個請求所針對的資源不支持對應的請求方法的時候，伺服器應當返回狀態碼405（MethodNotAllowed）；當伺服器不認識或者不支持對應的請求方法的時候，應當返回狀態碼501（NotImplemented）。
HTTP伺服器至少應該實現GET和HEAD方法，其他方法都是可選的。此外，除了上述方法，特定的HTTP伺服器還能夠擴展自定義的方法。
安全方法
開發者應當意識到他們的軟體代表了用戶在網際網路上進行交互，並且應當告知用戶，他們正在進行的操作可能對他們自身或者其他人有未曾預料的重要影響。
特別地，對於GET和HEAD方法而言，除了進行獲取資源信息外，這些請求不應當再有任何其他意義。也就是說，這些方法應當被認為是「安全的」，即所謂安全的意味著該操作用於獲取信息而非修改信息。客戶端應當使用其他「非安全」方法，例如POST、PUT及DELETE來以特殊的方式（通常是按鈕而不是超鏈接）使得客戶能夠意識到可能要負的責任（例如一個按鈕帶來的資金交易）或者被告知正在請求的操作可能是不安全的（例如某個文件將被上傳或刪除）。
但是，不能想當然地認為伺服器不會在處理某個GET請求時不會產生任何副作用。事實上，很多動態資源會把這作為其特性。這里重要的區別在於用戶並沒有請求這一副作用，因此不應由用戶為這些副作用承擔責任。
冪等方法
假如在不考慮諸如錯誤或者過期等問題的情況下，若干次請求的副作用與單次請求相同或者根本沒有副作用，那麼這些請求方法就能夠被視作「冪等」的。GET，HEAD，PUT和DELETE方法都有這樣的冪等屬性，同樣由於根據協議，OPTIONS，TRACE都不應有副作用，因此也理所當然也是冪等的。
假如某個由若干個請求做成的請求串列產生的結果在重復執行這個請求串列或者其中任何一個或多個請求後仍沒有發生變化，則這個請求串列便是「冪等」的。但是，可能出現若干個請求做成的請求串列是「非冪等」的，即使這個請求串列中所有執行的請求方法都是冪等的。例如，這個請求串列的結果依賴於某個會在下次執行這個串列的過程中被修改的變數。
1.4、HTTP響應的代碼
伺服器程序響應的第一行叫狀態行。狀態行以HTTP版本號開始，後面跟著3位數字表示響應代碼，最後是易讀的響應短語。根據第一位可以把響應分成5類：圖6、HTTP響應代碼
2、抓包分析
現在我們對HTTP基本上算是了解了，下面我用wireshark抓取打開博客園首頁時，我的電腦與博客園伺服器的交互過程的HTTP數據包。做好准備工作，關閉一些可能幹擾我們抓取打開博客園的相關程序。如下圖，我們在瀏覽器中輸入www.cnblogs.com並確定時，首先抓到如下包：圖7、打開博客園抓取的包
從圖中可以看出，我們在瀏覽器中輸入www.cnblogs.com並確定時是向伺服器發送了一個HTTP請求消息：GET/HTTP/1.1。根據1.2中介紹的HTTP消息的格式，我們知道GET對應request、/對應request-line、HTTP/1.1對應版本號。除了請求行之外，發送了一些首部欄位，如：Accept、Accept-Language、User-Agent、Accept-Encoding、Host、Connection等。而且可以看出他們的格式就是：首部欄位名:欄位值，注意冒號後面有個空格。
接下來我們看一下GET/HTTP/1.1請求的響應消息是怎樣的：
圖8、GET/HTTP/1.1請求的響應消息
響應消息的狀態行是：HTTP/1.1200OK，其中HTTP/1.1對應版本號、200對應response-code、OK對應response-phrase。除了狀態行，還返回了一些首部欄位，如：Cache-Control、Content-Type、Content-Encoding、Expires、Last-Modified、Vary、Server等等。（通過上圖我們可以看出，博客用的是IIS7.0）
上面抓的是GET的數據包，現在我來看一個POST的數據包——打開博客園首頁過程中獲取左邊的分類信息就是通過POST請求返回的。圖9、POST數據包
我們可以看到，POST/ws/PublicUserService.asmx/GetLoginInfoHTTP/1.1。除了把GET換成了POST之外，其它信息差不多。下面我們放大看下發送的首部欄位：
圖10、POST/ws/PublicUserService.asmx/GetLoginInfoHTTP/1.1的首部欄位
NOTE：本節涉及的一些首部欄位我就不在這里解釋了。我想，到了這里大家對HTTP的認識應該更深入了一步。
3、POST與GET的差異
1.3中介紹了8種方法，其中GET與POST最基本和常用了。表單提交中get和post方式的區別歸納如下幾點：
GET是從伺服器上獲取數據，POST是向伺服器傳送數據。
GET是把參數數據隊列加到提交表單的ACTION屬性所指的URL中，值和表單內各個欄位一一對應，在URL中可以看到。POST是通過HTTPPOST機制，將表單內各個欄位與其內容放置在HTMLHEADER內一起傳送到ACTION屬性所指的URL地址。用戶看不到這個過程。
對於GET方式，伺服器端用Request.QueryString獲取變數的值，對於POST方式，伺服器端用Request.Form獲取提交的數據。
GET傳送的數據量較小，不能大於2KB（這主要是因為受URL長度限制）。POST傳送的數據量較大，一般被默認為不受限制。但理論上，限製取決於伺服器的處理能力。
GET安全性較低，POST安全性較高。因為GET在傳輸過程，數據被放在請求的URL中，而如今現有的很多伺服器、代理伺服器或者用戶代理都會將請求URL記錄到日誌文件中，然後放在某個地方，這樣就可能會有一些隱私的信息被第三方看到。另外，用戶也可以在瀏覽器上直接看到提交的數據，一些系統內部消息將會一同顯示在用戶面前。POST的所有操作對用戶來說都是不可見的。
在FORM提交的時候，如果不指定Method，則默認為GET請求（.net默認是POST），Form中提交的數據將會附加在url之後，以?分開與url分開。字母數字字元原樣發送，但空格轉換為「+」號，其它符號轉換為%XX,其中XX為該符號以16進製表示的ASCII（或ISOLatin-1）值。GET請求請提交的數據放置在HTTP請求協議頭中，而POST提交的數據則放在實體數據中；GET方式提交的數據最多隻能有2048位元組，而POST則沒有此限制。POST傳遞的參數在doc里，也就http協議所傳遞的文本，接受時再解析參數部分。獲得參數。一般用POST比較好。POST提交數據是隱式的，GET是通過在url裡面傳遞的，用來傳遞一些不需要保密的數據，GET是通過在URL里傳遞參數，POST不是。
說明：關於「POST與GET的差異」查考了網上前輩的資料，由於找不出源頭，到處都是轉帖，這里就不貼出相關網址了，或Google下就知道了。
4、以一個實例說明C#中如何使用POST、GET等操作
在介紹實例之前，我們要先介紹一下HttpWebRequest和HttpWebResponse，在C#中就是用這兩個類實現客戶端向伺服器端發送HTTP消息、客戶端接受伺服器端的HTTP響應。
4.1、HttpWebRequest
在設計實現實例之前我們首先要介紹一下HttpWebRequest這個類——提供WebRequest類的HTTP特定的實現，HttpWebRequest類對WebRequest中定義的屬性和方法提供支持，也對使用戶能夠直接與使用HTTP的伺服器交互的附加屬性和方法提供支持。
不要使用HttpWebRequest構造函數。使用System.Net.WebRequest.Create方法初始化新的HttpWebRequest對象。如果統一資源標識符(URI)的方案是http://或https://，則Create返回HttpWebRequest對象。
HTTP消息的首部欄位（headers），在HttpWebRequest中表示為公開的屬性。下表列出了由屬性或方法設置或由系統設置的HTTP標頭。如果本地計算機配置指定使用代理，或者如果請求指定代理，則使用代理發送請求。如果未指定代理，則請求發送到伺服器。
HttpWebRequest類主要包括如下方法，用於與HTTP伺服器交互：
Abort：取消對Internet資源的請求。
AddRange：向請求添加范圍標頭。
BeginGetRequestStream：開始對用來寫入數據的Stream對象的非同步請求。
BeginGetResponse：開始對Internet資源的非同步請求。
Create：初始化新的WebRequest。（從WebRequest繼承。）
CreateDefault：為指定的URI方案初始化新的WebRequest實例。（從WebRequest繼承。）
CreateObjRef：創建一個對象，該對象包含生成用於與遠程對象進行通信的代理所需的全部相關信息。（從MarshalByRefObject繼承。）
EndGetRequestStream：結束對用於寫入數據的Stream對象的非同步請求。
EndGetResponse：結束對Internet資源的非同步請求。
GetRequestStream：獲取用於寫入請求數據的Stream對象。
GetResponse：返回來自Internet資源的響應。
GetSystemWebProxy：返回當前模擬用戶的InternetExplorer設置中配置的代理。（從WebRequest繼承。）
InitializeLifetimeService：獲取控制此實例的生存期策略的生存期服務對象。（從MarshalByRefObject繼承。）
RegisterPrefix：為指定的URI注冊WebRequest子代。（從WebRequest繼承。）
4.2、HttpWebResponse
在設計實現實例之前我們還要介紹一下HttpWebRequest這個類——提供WebResponse類的HTTP特定的實現。此類包含對WebResponse類中的屬性和方法的HTTP特定用法的支持。HttpWebResponse類用於生成發送HTTP請求和接收HTTP響應的HTTP獨立客戶端應用程序。
注意
不要混淆HttpWebResponse和HttpResponse類；後者用於asp.NET應用程序，而且它的方法和屬性是通過ASP.NET的內部Response對象公開的。
決不要直接創建HttpWebResponse類的實例。而應當使用通過調用HttpWebRequest.GetResponse所返回的實例。您必須調用Stream.Close方法或HttpWebResponse.Close方法來關閉響應並將連接釋放出來供重用。不必同時調用Stream.Close和HttpWebResponse.Close，但這樣做不會導致錯誤。
從Internet資源返回的公共標頭信息公開為該類的屬性。有關完整的列表，請參見下表。可以從Headers屬性以名稱/值對的形式讀取其他標頭。下表顯示可以通過HttpWebResponse類的屬性使用的公共HTTP標頭。
通過調用GetResponseStream方法，以Stream的形式返回來自Internet資源的響應的內容。
HttpWebRequest類主要包括如下方法與HTTP伺服器交互：（與HttpWebRequest類相比，方法較少）
CreateObjRef：創建一個對象，該對象包含生成用於與遠程對象進行通信的代理所需的全部相關信息。（從MarshalByRefObject繼承。）
GetLifetimeService：檢索控制此實例的生存期策略的當前生存期服務對象。（從MarshalByRefObject繼承。）
GetResponseHeader：獲取與響應一起返回的標頭的內容。
GetResponseStream：獲取流，該流用於讀取來自伺服器的響應的體。
InitializeLifetimeService：獲取控制此實例的生存期策略的生存期服務對象。（從MarshalByRefObject繼承。）
4.3、編寫WinForm程序打開博客園首頁（附源碼）
通過前面兩小節的介紹，我們對HttpWebRequest類和HttpWebRequest類有所了解，現在我們就應用它們來編寫一個小程序來實踐。程序界面大概如下：
功能也比較簡單，就是通過點擊「在WebBrowser中顯示」按鈕就在下方的WebBrowser控制項中顯示博客園首頁，通過點擊查看「html源碼」按鈕就彈出一個對話框顯示博客園首頁的html源碼。
首先我們介紹如何實現——通過點擊查看「html源碼」按鈕就彈出一個對話框顯示博客園首頁的html源碼。核心代碼如下：
privatestringGetCnBlogs()
{
stringhtml=String.Empty;
HttpWebRequestcnbogs=(HttpWebRequest)System.Net.WebRequest.Create(txtURL.Text.ToString());
cnbogs.Accept="image/jpeg,application/x-ms-application,image/gif,application/xaml+xml,image/pjpeg,application/x-ms-xbap,application/x-shockwave-flash,application/vnd.ms-excel,application/vnd.ms-powerpoint,application/msword,application/QVOD,application/QVOD,*/*";
cnbogs.UserAgent="Mozilla/4.0(compatible;MSIE8.0;WindowsNT6.1;Trident/4.0;SLCC2;.NETCLR2.0.50727;.NETCLR3.5.30729;.NETCLR3.0.30729;MALN;CIBA;InfoPath.2;.NET4.0C;.NET4.0E;MEdiaCenterPC6.0;TabletPC2.0;AskTB5.6)";
cnbogs.Method="GET";
HttpWebResponsecnblogsRespone=(HttpWebResponse)cnbogs.GetResponse();
if(cnblogsRespone!=null&&cnblogsRespone.StatusCode==HttpStatusCode.OK)
{
using(StreamReadersr=newStreamReader(cnblogsRespone.GetResponseStream()))
{
html=sr.ReadToEnd();
}
}
returnhtml;
}
privatevoidbtnGetHtml_Click(objectsender,EventArgse)
{
MessageBox.Show(GetCnBlogs());
}
通過點擊查看「html源碼」按鈕就彈出一個對話框顯示博客園首頁的html源碼
其實這個過程更我們通過在瀏覽器中輸入博客園網站打開效果是一樣的，只不過在這里我們是通過HttpWebRequest類和HttpWebRequest類的對象來實現的。
然而，通過點擊「在WebBrowser中顯示」按鈕就在下方的WebBrowser控制項中顯示博客園首頁的功能類似，只不過是在WebBrowser控制項中顯示且我這里把一些常用的HTTP相關的操作封裝到一個命名空間Helper中，便於以後使用，本質跟上面的是一樣的。點擊下載整個項目的源碼。
我這個源碼還是比較簡陋，只是簡單地實現了使用HttpWebRequest類和HttpWebRequest類與HTTP伺服器交互，更完善的功能期待你去完成。補充說明：關於url的長度限制問題，IE的url最長可以傳2083字元（半形），而GET最多隻能到2048字元。但是RFC2616，HypertextTransferProtocol--HTTP/1.1，並沒有對url的最大長度做限制。
本文來自網學(http://myecs.cn)，轉載請註明出處：http://myecs.cn/lunwen-resource/Net-biancheng/C-zhongruheshiyong-POSTGET-deng-fushili-download/
G. 求屏蔽奇虎360爬行蜘蛛的方法
丟人啊 幫你網路了下。。 這方面實在不擅長。。
正如你所知道的，你不能總是依康蜘蛛引擎在訪問或者索引你的網站時能夠十分有效的運作。完全依靠他們自己的埠，蜘蛛會產生許多重復內容，把一些重要頁面當成垃圾，索引本不應該展示給用戶的鏈接入口，還會有其他的問題。有一些工具可以讓我們能夠充分控制蜘蛛在網站內部的活動，如meta robots標簽，robots.txt、canonical標簽等。今天，我講一下機器人控制技術使用的局限。為了讓蜘蛛不抓取某一個頁面，站長們有時會使用多個機器人控制技術， 來禁止搜索引擎訪問某個網頁。不幸的是，這些技術能有時互相抵觸：從另一方面說這樣的限制會把某些死鏈給隱藏掉了。那麼，當一個頁面的robots文件中被禁止訪問，或者被使用noindex tag 和 canonical tag時會發生什麼？快速復習在我們進入主題之前，讓我們看一下那些主流的robots的一些限制技巧吧：元機器人標簽元機器人標簽（meta Robots Tag）為搜索引擎機器人建立頁面等級說明。元機器人標簽應放在HTML文件的頭部。規范標簽（canonical tag）規范標簽（canonical tag）是一個位於網頁HTML頭部的頁面等級的元標簽。它告訴搜索引擎哪一個URL的顯示是規范的。它的目的是不讓搜索引擎抓取重復內容，同時將重復頁面的權重集中在規范的那一個頁面上。X機器人標簽自2007年以來，谷歌和其他搜索引擎已經支持把X-Robots-Tag作為一種方法來告訴蜘蛛爬行和索引的優先順序，X-Robots-Tag位於HTTP頭部，曾用於通知蜘蛛爬行和索引文件爾用。該標簽對控制那些非HTML文件的索引是很有用的，如PDF文件。機器人標簽robots.txt允許一些搜索引擎進入網站內部，但是它並不能保證具體某個頁面會不會被抓取和索引。除非出於SEO的原因，否則只有當確實有必要或者在站點上有需要屏蔽的robots時robots.txt才確實值得使用。我總是推薦使用元數據標簽「noindex」來代替它。避免沖突同時利用兩種方法來限制robot入口是不明智的：· meta Robots noindex （元機器人標簽「noindex」）· Canonical Tag （when pointing to a different URL） （標准標簽）· Robots.txt Disallow· X-Robots-Tag（x機器人標簽）盡管你很想去保持頁面的搜索結果，但是一個辦法總是比兩個好。讓我們來看看當在一個單一的URL中有很多robots路徑控制技術時會發生什麼。meta Robots noindex 和 Canonical標簽如果你的目標是一個URL的權重傳遞給另一個URL，爾你卻沒有其他的更好辦法的時候，那就只能用Canonical標簽。不要用元機器人標簽的「noindex」來給自己添麻煩。如果你使用兩個robot的方法，搜索引擎可能根本看不到你的Canonical標簽。權重傳遞的效用將會被忽略，因為機器人的noindex標簽會使它看不到Canonical標簽！meta Robots noindex & X-Robots-Tag noindex這些標簽是多餘的。這兩個標簽放置在同一個頁面我只能看到的是給SEO造成的不良影響。如果你能在元機器人 noindex 中改變頭文件，你就不應該使用x機器人標簽吧。Robots.txt Disallow &meta Robots noindex這是我看過的最常見的沖突：我之所以青睞meta Robots「noindex」的原因是因為它可以有效的阻止一個頁面被索引，同時它還還是可以傳遞權重到連接這個頁面的更深層次的頁面。這是一個雙贏的方法。robots.txt文件不允許完全限制搜索引擎查看頁面上的信息（以及其中有價值的內部鏈接），特別是不能限制url被索引。有什麼好處？我曾經單獨寫過一篇關於這個主題的文章。如果兩個標簽都使用，robots.txt保證會使meta Robots noindex 不被蜘蛛看到。你會受到robots.txt中disallow的影響並且錯過了所有的meta Robots noindex 帶來的所有好處。文章出處為 上海麗姿鷗，網站優化專家，轉載請保留出處！不勝感激！
H. 怎麼才能讓蜘蛛不抓取整個網站
Robots.txt 是存放在站點根目錄下的一個純文本文件。雖然它的設置很簡單，但是作用卻很強大。它可以指定搜索引擎蜘蛛只抓取指定的內容，或者是禁止搜索引擎蜘蛛抓取網站的部分或全部內容。
使用方法:
Robots.txt 文件應該放在網站根目錄下，並且該文件是可以通過互聯網進行訪問的。
例如：如果您的網站地址是 http://www..com/那麼，該文件必須能夠通過 http://www..com/robots.txt 打開並看到裡面的內容。
格式：
User-agent:
用於描述搜索引擎蜘蛛的名字，在" Robots.txt "文件中，如果有多條User-agent記錄說明有多個搜索引擎蜘蛛會受到該協議的限制，對該文件來說，至少要有一條User-agent記錄。如果該項的值設為*，則該協議對任何搜索引擎蜘蛛均有效，在" Robots.txt "文件中，"User-agent:*"這樣的記錄只能有一條。
Disallow:
用於描述不希望被訪問到的一個URL，這個URL可以是一條完整的路徑，也可以是部分的，任何以Disallow開頭的URL均不會被Robot訪問到。
舉例：
例一："Disallow:/help"是指/help.html 和/help/index.html都不允許搜索引擎蜘蛛抓取。
例二："Disallow:/help/"是指允許搜索引擎蜘蛛抓取/help.html，而不能抓取/help/index.html。
例三：Disallow記錄為空說明該網站的所有頁面都允許被搜索引擎抓取，在"/robots.txt"文件中，至少要有一條Disallow記錄。如果"/robots.txt"是一個空文件，則對於所有的搜索引擎蜘蛛，該網站都是開放的可以被抓取的。
#:Robots.txt 協議中的注釋符。
綜合例子 ：
例一：通過"/robots.txt"禁止所有搜索引擎蜘蛛抓取"/bin/cgi/"目錄，以及 "/tmp/"目錄和 /foo.html 文件，設置方法如下：
User-agent: *
Disallow: /bin/cgi/
Disallow: /tmp/
Disallow: /foo.html
例二：通過"/robots.txt"只允許某個搜索引擎抓取，而禁止其他的搜索引擎抓取。如：只允許名為"slurp"的搜索引擎蜘蛛抓取，而拒絕其他的搜索引擎蜘蛛抓取 "/cgi/" 目錄下的內容，設置方法如下：
User-agent: *
Disallow: /cgi/
User-agent: slurp
Disallow:
例三：禁止任何搜索引擎抓取我的網站，設置方法如下：
User-agent: *
Disallow: /
例四：只禁止某個搜索引擎抓取我的網站如：只禁止名為「slurp」的搜索引擎蜘蛛抓取，設置方法如下：
User-agent: slurp
Disallow: /
I. 請教關於HTTP響應頭的設置
有的網站會在伺服器運行一段時間後down掉，有很多原因可能造成這種現象：比如tomcat堆和非堆內存設置不足，程序沒能釋放內存空間造成內存溢出，或者某些進程一直運行沒能釋放，造成cup資源大量消耗。但除了程序本身的原因，還有可能是客服端訪問造成（當然這個客戶端也包含如蜘蛛軟體等搜索引擎），如果伺服器和客戶端建立的是長鏈接(可以用」netstat -a」命令查看網路訪問信息)，這就需要對http響應頭的connection做一定的設置。
在http1.1中request和reponse header中都有可能出現一個connection頭欄位，此header的含義是當client和server通信時對於長鏈接如何進行處理。在http1.1中，client和server都是默認對方支持長鏈接的， 如果client使用http1.1協議，但又不希望使用長鏈接，則需要在header中指明connection的值為close；如果server方也不想支持長鏈接，則在response中也需要明確說明connection的值為close。
不論request還是response的header中包含了值為close的connection，都表明當前正在使用的tcp鏈接在請求處理完畢後會被斷掉。以後client再進行新的請求時就必須創建新的tcp鏈接了。
HTTP Connection的close設置允許客戶端或伺服器中任何一方關閉底層的連接雙方都會要求在處理請求後關閉它們的TCP連接。
如何在程序中設置：可以在過濾器中加入：response.setHeader(「connection」, 「close」);
以下內容來自: HTTP Keep-Alive詳解
HTTP Keep Alive
HTTP Keep-Alive 很大程序上被誤解了，下面介紹一下它在HTTP/1.0和HTTP/1.1版本下是如何工作的，以及其在JAVA中的運行原理。
HTTP是一個請求<->響應模式的典型範例，即客戶端向伺服器發送一個請求信息，伺服器來響應這個信息。在老的HTTP版本中，每個請求都將被創建一個新的客戶端->伺服器的連接，在這個連接上發送請求，然後接收請求。這樣的模式有一個很大的優點就是，它很簡單，很容易理解和編程實現；它也有一個很大的缺點就是，它效率很低，因此Keep-Alive被提出用來解決效率低的問題。
HTTP/1.0
在HTTP/1.0版本中，並沒有官方的標准來規定Keep-Alive如何工作，因此實際上它是被附加到HTTP/1.0協議上，如果客戶端瀏覽器支持Keep-Alive，那麼就在HTTP請求頭中添加一個欄位 Connection: Keep-Alive，當伺服器收到附帶有Connection: Keep-Alive的請求時，它也會在響應頭中添加一個同樣的欄位來使用Keep-Alive。這樣一來，客戶端和伺服器之間的HTTP連接就會被保持，不會斷開（超過Keep-Alive規定的時間，意外斷電等情況除外），當客戶端發送另外一個請求時，就使用這條已經建立的連接
HTTP/1.1
在HTTP/1.1版本中，官方規定的Keep-Alive使用標准和在HTTP/1.0版本中有些不同，默認情況下所在HTTP1.1中所有連接都被保持，除非在請求頭或響應頭中指明要關閉：Connection: Close ，這也就是為什麼Connection: Keep-Alive欄位再沒有意義的原因。另外，還添加了一個新的欄位Keep-Alive:，因為這個欄位並沒有詳細描述用來做什麼，可忽略它
Not reliable（不可靠）
HTTP是一個無狀態協議，這意味著每個請求都是獨立的，Keep-Alive沒能改變這個結果。另外，Keep-Alive也不能保證客戶端和伺服器之間的連接一定是活躍的，在HTTP1.1版本中也如此。唯一能保證的就是當連接被關閉時你能得到一個通知，所以不應該讓程序依賴於Keep-Alive的保持連接特性，否則會有意想不到的後果
Keep-Alive和POST
在HTTP1.1細則中規定了在一個POST消息體後面不能有任何字元，還指出了對於某一個特定的瀏覽器可能並不遵循這個標准（比如在POST消息體的後面放置一個CRLF符）。而據我所知，大部分瀏覽器在POST消息體後都會自動跟一個CRLF符再發送，如何解決這個問題呢？根據上面的說明在POST請求頭中禁止使用Keep-Alive，或者由伺服器自動忽略這個CRLF，大部分伺服器都會自動忽略，但是在未經測試之前是不可能知道一個伺服器是否會這樣做。
以下內容來自: http://liugong.blog.163.com/blog/static/178272375201141344312315/
HTTP無狀態協議和Connection:Keep-Alive容易犯的誤區
名詞解釋：
HTTP無狀態：無狀態是指協議對於事務處理沒有記憶能力，伺服器不知道客戶端是什麼狀態。從另一方面講，打開一個伺服器上的網頁和你之前打開這個伺服器上的網頁之間沒有任何聯系
如果你要實現一個購物車，需要藉助於Cookie或Session或伺服器端API（如NSAPI and ISAPI）記錄這些信息，請求伺服器結算頁面時同時將這些信息提交到伺服器
當你登錄到一個網站時，你的登錄狀態也是由Cookie或Session來「記憶」的，因為伺服器並不知道你是否登錄
優點：伺服器不用為每個客戶端連接分配內存來記憶大量狀態，也不用在客戶端失去連接時去清理內存，以更高效地去處理WEB業務
缺點：客戶端的每次請求都需要攜帶相應參數，伺服器需要處理這些參數
Keep-Alive：參考另外一篇文章HTTP Keep-Alive 詳解
容易犯的誤區：
1、HTTP是一個無狀態的面向連接的協議，無狀態不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協議（無連接）
2、從HTTP/1.1起，默認都開啟了Keep-Alive，保持連接特性，簡單地說，當一個網頁打開完成後，客戶端和伺服器之間用於傳輸HTTP數據的TCP連接不會關閉，如果客戶端再次訪問這個伺服器上的網頁，會繼續使用這一條已經建立的連接
3、Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的伺服器軟體（如Apache）中設定這個時間
以下內容來自:http://www.l99.com/EditText_view.action?textId=446020&src=
Keep-Alive簡介及在Tomcat中配置
Keep-Alive功能使客戶端到伺服器端的連接持續有效，當出現對伺服器的後繼請求時，Keep-Alive功能避免了建立或者重新建立連接。市場上 的大部分Web伺服器，包括iPlanet、IIS和Apache，都支持HTTP Keep-Alive。對於提供靜態內容的網站來說，這個功能通常很有用。但是，對於負擔較重的網站來說，這里存在另外一個問題：雖然為客戶保留打開的連 接有一定的好處，但它同樣影響了性能，因為在處理暫停期間，本來可以釋放的資源仍舊被佔用。當Web伺服器和應用伺服器在同一台機器上運行時，Keep-Alive功能對資源利用的影響尤其突出。 此功能為HTTP 1.1預設的功能，HTTP 1.0加上Keep-Alive header也可以提供HTTP的持續作用功能。
Keep-Alive: timeout=5, max=100
timeout：過期時間5秒（對應httpd.conf里的參數是：KeepAliveTimeout），max是最多一百次請求，強制斷掉連接
就是在timeout時間內又有新的連接過來，同時max會自動減1，直到為0，強制斷掉。
Tomcat中的相關設置,在server.xml 中的Connector 元素中。
keepAliveTimeout：
此時間過後連接就close了，單位是milliseconds
maxKeepAliveRequests：
最大長連接個數（1表示禁用，-1表示不限制個數，默認100個。一般設置在100~200之間）.
maxKeepAliveRequests=」1″就可以避免tomcat產生大量的TIME_WAIT連接，從而從一定程度上避免tomcat假死。
<Connector executor=」tomcatThreadPool」
port=」80″ protocol=」HTTP/1.1″
connectionTimeout=」60000″
keepAliveTimeout=」15000″
maxKeepAliveRequests=」1″
redirectPort=」443″
maxHttpHeaderSize=」8192″ URIEncoding=」UTF-8″ enableLookups=」false」 acceptCount=」100″ disableUploadTimeout=」true」/>