我的專欄： HTTP學習筆記
起點
爬蟲開始訪問的 URL 初始集合被稱作根集（root set）。
文檔 A 開始， 可以到達 B、 C 和 D， 然後是 E 和 F， 然後到 J， 然後到 K。 但沒有從 A 到 G， 或從 A到 N 的鏈路。
爬蟲在 Web 上移動時， 會不停地對 HTML 頁面進行解析。它要對所解析的每個頁面上的 URL 鏈接進行分析， 並將這些鏈接添加到需要爬行的頁面列表中去。
環路
機器人在 Web 上爬行時， 要特別小心不要陷入循環， 或環路（cycle） 之中。
環路的不利
• 它們會使爬蟲陷入可能會將其困住的循環之中。 循環會使未經良好設計的爬蟲不停地兜圈子， 把所有時間都耗費在不停地獲取相同的頁面上。
• 爬蟲不斷地獲取相同的頁面時， 另一端的 Web 服務器也在遭受着打擊。 如果爬蟲與服務器連接良好， 它就會擊垮 Web 站點， 阻止所有真實用戶訪問這個站點。
• 即使循環自身不是什麼問題，爬蟲也是在獲取大量重複的頁面。
規範化URL
由於 URL“別名” 的存在， 即使使用了正確的數據結構， 有時也很難分辨出以前是否訪問過某個頁面。
(1) 如果沒有指定端口的話， 就向主機名中添加“:80”。
(2) 將所有轉義符 %xx 都轉換成等價字符。
(3) 刪除 # 標籤。
動態虛擬Web空間
惡意網管可能會有意創建一些複雜的爬蟲循環來陷害那些無辜的、 毫無戒備的機器人。即使這個惡意 Web 服務器實際上並不包含任何文件，那些沒有惡意的網管們可能會在無意中通過符號連接或動態內容構造出爬蟲陷阱。
如何使Web機器人有更好的表現
| 規範化 URL | 將 URL 轉換爲標準形式以避免語法上的別名 |
| 廣度優先的爬行 | 每次爬蟲都有大量潛在的 URL 要去爬行。 |
| 節流 | 限制一段時間內機器人可以從一個 Web 站點獲取的頁面數量 |
| 限制 URL 的大小 | 機器人可能會拒絕爬行超出特定長度（通常是 1KB） 的 URL。 |
| URL/ 站點黑名單 | 維護一個與機器人環路和陷阱相對應的已知站點及 URL 列表。 發現新問題時， 就將其加入黑名單。 |
| 模式檢測 |
文件系統的符號連接和類似的錯誤配置所造成的環路會遵循某種模式 |
| 內容指紋 | 一些更復雜的 Web 爬蟲會使用指紋這種更直接的方式來檢測重複。 使用內容指紋的機器人會獲取頁面內容中的字節， 並計算出一個校驗和（checksum）。 |
| 人工監視 | 設計所有產品級機器人時都要有診斷和日誌功能， |
機器人的HTTP
識別請求首部
• User-Agent：將發起請求的機器人名字告知服務器。
• From：提供機器人的用戶 / 管理者的 E-mail 地址。
• Accept：告知服務器可以發送哪些媒體類型。 這有助於確保機器人只接收它感興趣的內容（文本、 圖片等）。
• Referer：提供包含了當前請求 URL 的文檔的 URL。
虛擬主機
機器人實現者要支持 Host 首部。
條件請求
只在內容發生變化時才重新獲取內容是很有意義的。有些機器人實現了條件 HTTP 請求，它們會對時間戳或實體標籤進行比較， 看看它們最近獲取的版本是否已經升級了。
對響應的處理
狀態碼
機器人應該能夠處理一些常見的， 以及預期的狀態碼。 所有機器人都應該理解 200 OK 和 404 Not Found 這樣的狀態碼。
實體
除了 HTTP 首部所嵌的信息之外， 機器人也會在實體中查找信息。
行爲不當的機器人
失控機器人
如果機器人存在編程邏輯錯誤， 或者陷入了環路之中， 就可能會向 Web 服務器發出大量的負載——很可能會使服務器過載， 並拒絕爲任何其他人提供服務。
失效的URL
有些機器人會去訪問 URL 列表。 這些列表可能很老了。 如果一個 Web 站點對其內容進行了大量的修改， 機器人可能會對大量不存在的 URL 發起請求。
很長的錯誤URL
由於環路和編程錯誤的存在， 機器人可能會向 Web 站點請求一些很大的、 無意義的 URL。
愛打聽的機器人
有些機器人可能會得到一些指向私有數據的 URL， 這樣， 通過因特網搜索引擎和其他應用程序就可以很方便地訪問這些數據了。 而在最壞的情況下， 則會認爲這種行爲是對隱私的侵犯。
動態網關訪問
機器人並不總是知道它們訪問的是什麼內容。 機器人可能會獲取一個內容來自網關應用程序的 URL。
機器人的規範
(1) 識別
識別你的機器人
用 HTTP 的 User-Agent 字段將機器人的名字告訴 Web 服務器。 這樣可以幫助管理員理解機器人所做的事情。 有些機器人還會在 User-Agent首部包含一個描述機器人目的和策略的 URL。
識別你的機器
確保機器人是從一臺帶有 DNS 條目的機器上運行的， 這樣 Web 站點才能夠將機器人的 IP 地址反向 DNS 爲主機名。 這有助於管理者識別出對機器人負責的組織。
識別聯絡人
用 HTTP 的 From 字段提供一個聯絡的 E-mail 地。
(2) 操作
保持警惕
如果機器人要全天候運行， 就要格外小心。 需要有操作人員不間斷地對機器人進行監視， 直到它有了豐富的經驗爲止。
做好準備
開始機器人之旅時，一定要通知你所在的組織。你的組織可能要觀測網絡帶寬的耗費，作好應對各種公共查詢的準備。
監視並記錄日誌
機器人應該裝備有豐富的診斷和日誌記錄工具， 這樣才能記錄進展、 識別所有的機器人陷阱， 進行完整性檢查看看工作是否正常。
學習並適應
在每次爬行中你都會學到新的東西。 要讓機器人逐步適應， 這樣， 它在每次爬行之後都會有所進步， 並能避開一些常見的陷阱。
(3) 約束自己的行爲
對 URL 進行過濾
如果一個 URL 指向的好像是你不理解或不感興趣的數據， 你可能會希望跳過它。 要確保你得到的就是你想要的。
過濾動態 URL
通常， 機器人不會想去爬行來自動態網關的內容。 機器人不知道應該如何正確地格式化查詢請求， 並將其發送給網關， 而它得到的結果也很可能是錯誤的或臨時的。
對 Accept 首部進行過濾
機器人應該用 HTTP 的 Accept 首部來告訴服務器它能夠理解哪種內容。
遵循 robots.txt
機器人應該接受站點上 robots.txt 的控制。
制約自己
機器人應該記錄訪問每個站點的次數以及訪問的時間， 並通過這些信息來確保它沒有太頻繁地訪問某個站點。
(4) 容忍存在環路、 重複和其他問題
處理所有返回代碼
必須做好處理所有 HTTP 狀態碼的準備， 包括各種重定向和錯誤碼。 還應該對這些代碼進行記錄和監視。
規範 URL
試着將所有 URL 都轉化爲標準形式來消除常見的別名
積極地避免環路的出現
努力地檢測並避免環路的出現。 有些環路是故意造成的惡意環路。 這些環路可能很難檢測。 有的站點會帶有一些怪異的 URL， 要監視對這類站點進行的大量訪問。
維護一個黑名單
找到陷阱、 環路、 故障站點和不希望機器人訪問的站點時， 要將其加入一個黑名單， 不要再次訪問這些站點。
(5) 可擴展性
瞭解所需空間
事先通過數學計算明確你要解決的問題規模有多大。
瞭解所需帶寬
瞭解你有多少網絡帶寬可用， 以及在要求的時間內完成機器人任務所需的帶寬大小。
瞭解所需的時間
瞭解機器人完成其任務所需花費的時間， 檢查這個進度是否與自己的估計相符。
分而治之
對大規模的爬行來說， 可以使用帶有多個網卡的大型多處理器服務器， 也可以使用多臺較小的計算機共同配合工作。
(6) 可靠性
徹底測試
在將機器人放出去之前， 要對其進行徹底的內部測試。
檢查點
所有嚴謹的機器人都要保存其進展的快照， 出現故障時可以從那裏重新開始。
故障恢復
預測故障的發生， 對機器人進行設計， 使其能夠在發生故障時繼續工作。
搜索引擎
得到最廣泛使用的 Web 機器人都是因特網搜索引擎。 因特網搜索引擎可以幫助用戶找到世界範圍內涉及任意主題的文檔。
全文索引
全文索引就是一個數據庫， 給它一個單詞， 它可以立即提供包含那個單詞的所有文檔。 創建了索引之後， 就不需要對文檔自身進行掃描了。
• 單詞“a” 位於文檔 A 和 B 中；
• 單詞“best” 位於文檔 A 和 C 中；
• 單詞“drill” 位於文檔 A 和 B 中；
• 單詞“routine” 位於文檔 B 和 C 中；
• 單詞“the” 位於所有的三份文檔 A、 B 和 C 中。
發佈查詢請求
搜索查詢請求的實例
