導言：作為寫作愛好者，不可錯過為您精心挑選的10篇robots協議，它們將為您的寫作提供全新的視角，我們衷心期待您的閱讀，并希望這些內容能為您提供靈感和參考。

篇1

歷史事件一，Facebook屏蔽谷歌搜索

FACEBOOK中的內容，只要谷歌想抓取，放到搜索引擎上，從技術角度來說是沒有丁點難度的。但是直到今天谷歌都沒有抓取FACEBOOK中的海量用戶內容，而這些海量的內容對谷歌來講是巨大的損失。

那么假如沒有robots協議，谷歌便可以隨意抓取，而facebook根本無力抵抗，其用戶生產的UGC內容就會肆意的出現在谷歌的搜索結果中，而facebook依靠用戶UGC生成出的內容護城河也將功虧一簣，用戶要想搜索好友不通過facebook搜索而是繞過facebook直接從谷歌所搜就可以，這對facebook來說就無法構成閉環，必將損失慘重。

歷史事件二，默多克旗下新聞屏蔽谷歌搜索

從傳統媒體起家的默多克，對于搜索引擎的態度相當不友善，默多克曾將雅虎谷歌等搜索引擎都說成是”網絡寄生蟲“。

當然，谷歌的回應很簡單，如果不想讓貴站的內容出現在搜索結果中，請使用robots協議禁止我們抓取即可。

隨后默多克在09年開始展開計劃，對谷歌等搜索引擎展開行動，對旗下多家新聞網站屏蔽搜索爬蟲。谷歌便不再抓取。那么現在我們假設沒有robots協議的話，谷歌就會肆無忌憚的繼續抓取新聞網站的內容，很可能就成為了真正的“寄生蟲”，并且還會與默多克集團的官司不斷。

好在谷歌遵守了，直接堵住了默多克的嘴，而隨后默多克也無話可說。

歷史事件三，淘寶屏蔽百度搜索

2008年百度有啊C2C平臺上線，利用搜索優勢打算與阿里正面競爭。淘寶采取對抗措施，屏蔽百度抓取淘寶內容，而百度也無可奈何，只能望內容興嘆。

如果沒有robots協議的話，那么淘寶就沒有辦法屏蔽百度，百度就可以依然肆無忌憚的抓取淘寶的海量內容，讓阿里的計劃全盤落空，啞巴吃黃連。

而好在百度遵守規則，通過遵守規則與阿里競爭，哪怕最后百度有啊以失敗告終，也沒越過雷池一步。

歷史事件四，京東屏蔽一淘

京東與阿里想來水火不容，京東屏蔽支付寶，屏蔽新浪微博登錄，而屏蔽阿里系的一淘搜索自然也在情理之中，是一種正常的商業競爭行為。而一淘失去京東的商品搜索結果，對自身損失也可謂極大。

好的，那么假如現在沒有ROBOTS協議，阿里也同樣可以毫無壓力的抓取京東的內容，充實自己的一淘搜索結果，京東也只能隔空罵阿里流氓并且束手無策。

當然，好在大家都是按照規矩競爭，阿里的一淘就算做的再差也沒有去抓取京東的內容。

歷史事件五，優酷同時屏蔽百度與谷歌搜索

08年末由于優酷面臨寬帶運營的成本壓力，所以在段時間內屏蔽了搜索引擎以減輕自己的服務器壓力。

而如果當時沒有ROBOTS協議的話，那么所搜索引擎的抓取將使優酷面臨更巨大的成本壓力，難以過冬，甚至很有可能命懸一線。

而ROBOTS協議，給了優酷喘息的機會。

歷史事件六，QQ空間

QQ空間自從誕生以來就只對旗下的搜搜開放，而對百度和谷歌等一直是屏蔽措施，我們無法在百度和谷歌上搜索到QQ空間的大量內容。直到2012年，QQ空間才終于將內容向其他搜索引擎開放。

篇2

在騰訊訴奇虎“扣扣保鏢”案中，奇虎公司兩次借用“消費者”的名義為其行為做正當性辯護，而在審理該案中，兩級法院的判決并未忽視對消費者權益的關切，而是立足于反不正當競爭法的價值本身，從保障消費者的“知情權”和“選擇權”的角度，對相關行為是否構成不正當競爭進行了深入剖析。

篇3

杰圖公司將含有侵權內容的“百度地圖”服務內嵌于自己的網站中，進一步擴大了百度公司的侵權范圍，與百度公司構成共同的侵權和不正當競爭行為。

篇4

從好的方面看，如此一來，360會對百度形成

篇5

中圖分類號:TP393文獻標識碼:A 文章編號:1009-3044(2010)17-4640-02

Finding out and Analysis Information of Attacking in Server of Web

YAO Kai-rong

(Jingzhou Vocation and Technical College,Jingzhou 434100,China)

Abstract: Looking over server logging of Web prevents a kind of basic method to attack and invading effectively. This text explains mainly how to find out , analyse the mark attacked and invading in numerous information through server logging of Web, provide the concrete instance.

Key words: Web server; logging; attack

隨著Internet上Web服務的發展,很多單位都建立有自己的網站。與此同時,他們在網站建設和管理中都會遇到各種各樣的安全問題。因為管理Web網站不只是監視其速度和內容傳送,更重要的是了解對這些Web網站的外來訪問,跟蹤包含有攻擊和入侵的“幕后”數據等。而這些要求都可以通過對Web服務器Logging的查看和分析來做到。由于Web服務是Internet所提供的最豐富的服務,各種Web服務器自然受到的攻擊最多,雖然有很多措施防止遭受攻擊和入侵,但查看Web服務器的logging仍然是最直接、常用又有效的一種方法。由于Web服務器運行時間長,logging十分龐大,因此查看logging是件很繁瑣的事情,如果抓不住重點,攻擊線索就容易被忽略。

本文從兩類Web服務器Apache和IIS的logging分析入手,介紹如何通過Web服務器logging,在眾多信息里查找、分析攻擊和入侵的痕跡,找出漏洞,防范攻擊,從而加強Web服務器的安全。

1 Web服務器logging分析的原理

Web服務器logging記錄了服務器接收處理請求以及運行錯誤等各種原始信息。通過進行logging統計、分析,就能有效地掌握服務器的運行狀況,發現和排除不安全因素,更好地加強系統的維護和管理?？蛻舳?瀏覽器)訪問WEB服務器時logging的記錄過程為[1]:

1)客戶端和Web服務器建立tcp連接,連接建立以后,向Web 服務器發出訪問請求,根據HTTP協議,該請求中包含了客戶端的IP地址、瀏覽器類型、請求的URL等一系列信息。

2)Web服務器收到請求后,將客戶端要求的頁面內容返回到客戶端。如果出現錯誤,那么返回錯誤代碼。

3)服務器端將訪問信息和錯誤信息記錄到logging里。在客戶機的請求里包含了很多有用的信息,例如:客戶端類型等等。最后,Web服務器將請求的Web頁內容返回給客戶機。

Logging記錄客戶端的IP地址、訪問發生的時間、訪問請求的頁面、Web服務器對于該請求返回的狀態信息、返回給客戶端的內容的大小、該請求的引用地址、客戶瀏覽器類型等信息。對于IIS,其默認記錄存放在c:winntsystem32logfilesw3svc1,文件名就是當天的日期,記錄格式是標準的W3C擴展記錄格式,可以被各種logging分析工具解析,默認的格式包括時間、訪問者IP地址、訪問的方法、請求的資源、HTTP狀態等。對于其中的HTTP狀態,200-299表示訪問成功;300-399表示需要客戶端反應來滿足請求;400-499和500-599表示客戶端和服務器出錯;其中常用的如404表示資源沒找到,403表示訪問被禁止。Apache的默認記錄存放在/usr/local/apache/logs,其中最有用的記錄文件是access_log,其格式包括客戶端IP、個人標識、用戶名、訪問方式、HTTP狀態、傳輸的字節數等。

2 Web服務器logging分析的方法、步驟

1) 信息收集

非法攻擊Web服務器通常先收集信息,然后通過遠程命令分步實施入侵。我們模擬使用的工具是netcat,Web服務器IP為10.10.20.8,客戶端IP為10.10.20.11。

C:>nc -n 10.10.20.8 80

HEAD / HTTP/1.0

HTTP/1.1 200 OK

Server: Microsoft-IIS/4.0

Date: Sun, 07 Oct 2005 14:31:00 GMT

Content-Type: text/html

Set-Cookie: ASPSESSIONIDGQQQQQPA=IHOJAGJDECOLLGIBNKMCEEED; path=/

Cache-control: private

在IIS和Apache的logging顯示如下:

IIS: 15:08:44 10.10.20.11 HEAD /Default.asp 200

Linux: 10.10.20.11- - [07/Oct/2005:15:56:39 -0700] "HEAD / HTTP/1.0" 200 0

以上的活動看上去很正常,也不會對服務器產生任何影響,但通常是攻擊的前奏。

2) 站點鏡像

攻擊服務器通常通過鏡像一個站點來進行,常用鏡像工具有Windows下的Teleport pro和Unix下的Wget。

下面是使用這兩個工具后服務器logging里的部分信息:

16:30:52 10.10.20.11 GET /Default.asp 200

16:30:52 10.10.20.11 GET /robots.txt 404

16:30:52 10.10.20.11 GET /header_protecting_your_privacy.gif 200

16:30:52 10.10.20.11 GET /header_fec_reqs.gif 200

16:30:55 10.10.20.11 GET /photo_contribs_sidebar.jpg 200

16:30:55 10.10.20.11 GET /g2klogo_white_bgd.gif 200

16:30:55 10.10.20.11 GET /header_contribute_on_line.gif 200

16:32:01 10.10.20.12 GET /Default.asp 200

16:32:01 10.10.20.12 GET /robots.txt 404

16:32:01 10.10.20.12 GET /header_contribute_on_line.gif 200

16:32:01 10.10.20.12 GET /g2klogo_white_bgd.gif 200

16:32:01 10.10.20.12 GET /photo_contribs_sidebar.jpg 200

16:32:01 10.10.20.12 GET /header_fec_reqs.gif 200

16:32:01 10.10.20.12 GET /header_protecting_your_privacy.gif 200

10.10.20.11是使用Wget的Unix客戶端,10.10.20.12是使用Teleport pro的Windows客戶端,都請求robots.txt文件,該文件是請求沒被鏡像所要用到的,所以看到有對robots.txt文件的請求,即表明有鏡像的企圖。當然,在Wget和Teleport pro客戶端,可以人為禁止對robots.txt文件的訪問,這時,其辨別可以看是否有從同一IP地址來的重復資源請求。

3) 漏洞掃描

隨著攻擊的發展,我們可以用一些Web漏洞檢查軟件(如 Whisker)檢查已知曉的各種漏洞。下面是運行Whisker的IIS和Apache的相關記錄:

IIS

12:07:56 10.10.20.12 GET /SiteServer/Publishing/viewcode.asp 404

12:07:56 10.10.20.12 GET /advworks/equipment/catalog_type.asp 404

12:07:56 10.10.20.12 GET /iisadmpwd/aexp4b.htr 200

12:07:56 10.10.20.12 HEAD /scripts/tools/newdsn.exe 404

12:07:56 10.10.20.12 HEAD /msadc/msadcs.dll 200

12:07:56 10.10.20.12 HEAD /scripts/proxy/ 403

12:07:56 10.10.20.12 HEAD /scripts/proxy/w3proxy.dll 500

12:07:56 10.10.20.12 GET /scripts/proxy/w3proxy.dll 500

Apache

10.10.20.11-[07/Oct/2005:12:57:28 -0700] "GET /cfcache.map HTTP/1.0" 404 266

10.10.20.11-[07/Oct/2005:12:57:28 -0700] "GET /cfappman/index.cfm HTTP/1.0" 404 273

10.10.20.11-[07/Oct/2005:12:57:29 -0700] "HEAD /cgi-bin/pfdisplay.cgi HTTP/1.0" 404

檢查這種攻擊的重點是看同一IP地址對cgi目錄文件請求出現多個404狀態。這時就要查看相應cgi目錄里的程序安全性。

4)遠程攻擊

下面以針對IIS的MDAC攻擊為例,來了解遠程攻擊在logging里的記錄情況。

17:48:49 10.10.20.11 GET /msadc/msadcs.dll 200

17:48:51 10.10.20.11 POST /msadc/msadcs.dll 200

當攻擊發生后,在logging中會留下對msadcs.dll的請求記錄。另一個常見的攻擊是asp源代碼泄漏的漏洞,當這種攻擊發生時,logging文件會有如下記錄:

17:50:13 10.10.20.12 GET /default.asp+.htr 200

對于未授權訪問的攻擊記錄,Apache log會顯示:

[07/Oct/2005:18:58:29 -0700] "GET /private/ HTTP/1.0" 401 462

3 總結

篇6

淺要的說明了網站診斷的重要性后，那倒底網站怎么做診斷呢，SEO初學者只要按照以下步驟操作，就可以對一個網站進行全面的診斷，找出網站內部的不足，以便于優化完善。下面結合一個網站的診斷實例來講解，以便于初學者理解。

要說明的是，這個網站是推一把線下10期學員新做的一個網站，網站內容并不多，項目也是虛擬的，建站的目的是為了通過實踐掌握教學內容，網站的名稱叫：釀蜜坊蜂產品專賣店，網址：，以下簡稱“診斷網站”，不啰嗦了，下面進入如何診斷網站十二步。

第一步，檢查各網頁標題是否設置正確

這個診斷項目是最重要的，網站標題是搜索引擎識別、抓取，收錄網站重要依據，是獲得較好排名和展現給用戶的第一要素，SEO沒有什么比這更重要的啦。見過很多號自稱SEO高手的連個標題都寫不好。

正確的網站頁面標題格式應該如下：(注意：指網站所有頁面)

首頁標題：關鍵詞_網站名稱

欄目頁標題：欄目名稱_網站名稱

內容頁標題：文章標題_欄目頁_網站名稱

診斷網站狀況：

首頁標題：蜂蜜減肥法，蜂蜜面膜，蜂蜜美容小知識—釀蜜坊蜂產品專賣店

欄目頁標題：行業新聞-蜂蜜減肥法，蜂蜜面膜，蜂蜜美容小知識—釀蜜坊蜂產品專賣店

內容頁標題：蜂蜜加白醋能減肥嗎—蜂蜜白醋減肥方法-蜂蜜減肥法，蜂蜜面膜，蜂蜜美容小知識—釀蜜坊蜂產品專賣店

分析：目標網站首頁、欄目頁及內容頁書寫順序正確，標題中還自動重復了首頁標題，有利于搜索引擎對網站內容的理解和抓取。如果你的網站沒有達到此標準，盡快改過來吧。

第二步，檢查首頁標題的長度及符號

在第一步中我們已經談到網頁標題的重要性，首頁標題更是重中之重了，怎樣寫首頁標題不是本文討論的重點，但是你要知道首頁標題要寫好有那些要求。

要求是：標題字數不超過30個漢字，核心關鍵3-5個，用“，”或者“|”線隔開，公司名用“—”聯接，用戶搜索次數最大的關鍵詞排在最前面，不要問我原因，你懂的。

診斷網站狀況：

首頁標題：蜂蜜減肥法，蜂蜜面膜，蜂蜜美容小知識—釀蜜坊蜂產品專賣店

診斷分析：診斷網站首頁標題字數28字。關鍵詞之間才用“，”分隔，公司名用“—”橫線連接，符合要求。

第三步，診斷網頁是否有標題重復與描述重復。

1、各網頁標題診斷

要求：對各個頁面進行診斷，包括首頁、欄目頁、內容頁，每個頁面標題不能重復，否則搜索引擎以為你的網站每個頁面都是相同的內容，而其實每個頁面的內容不可能是相同的，比如“產品中心”欄目是介紹不同產品的，“企業新聞”欄目是發表企業相關新聞動態的。

診斷網站狀況：沒有發現重標題的網頁。

例如：企業簡介欄目標題：關于釀蜜坊-要想身體好，蜂蜜的作用與功效不得了，健康天使——釀蜜坊專賣店;

內容欄目標題：油菜春漿蜂皇漿-蜂蜜減肥法，蜂蜜面膜，蜂蜜美容小知識—釀蜜坊蜂產品專賣店

2、描述重復診斷

與網頁標題診斷一樣，每個頁面都要有不同的描述，切不要都是一樣的描述內容。

要求：準確的描述網頁內容，不能有關鍵詞堆砌。每個頁面都應該有不同的描述。長度合理。

診斷網站狀況：沒有發現重復的網頁標題，但發現一些產品頁描述不正確或者過于簡單，產生的原因是系統自動生成，產品第一段內容很關鍵，尤其是前100字，要對產品進行精準的描述。

診斷分析：雖然網站沒重復的標題及描述，但標題及描述不合理，網頁標題沒有體現該網頁內容，相近度高，原因可能是網站管理系統自動生成標題和描述適成的，對于小型網站或者企業網站，建議網頁標題及描述手寫更準確。

第四步，網站URL的唯一性

網站URL要具有唯一性，如果不相同的頁面有洋同URL，搜索引擎在排名時會分散權重，網站難以獲得好的排名

要求：正確的選擇首選域，內鏈和外鏈要統一，做好301重定向。

診斷網站狀況：

網站首選域為：，內鏈和外鏈基本統一。

訪問/index.html和xxx.cn及都是同一頁面，無301重定向。

網站內鏈和外鏈建設選擇為首選域。

診斷分析：做301轉向對于SEO新人來說，可能技術有難度，這方面可能要請技術人員協助解決。

第五步，網站URL靜態化

雖然百度SEO指南中說，百度蜘蛛對于動態網頁的抓取沒有岐意，但細心的你可以發現獲得良好排名的網站，其URL必然是靜態化的，至于什么是靜態化的網頁，很多初學者說會動的網頁，就是動態的，其實這是錯誤的看法，只要URL中包含“?”“%”等符號，就是動態的網頁，多說了幾句，掃一下盲。

要求：網站全部采用靜態化，有利于網站收錄及排名。

診斷網站狀況：網站所有網頁均是偽靜態

如：/info/contact.html

診斷分析：全站最深層次為三層，符合要求

第六步，診斷圖片ALT屬性

百度官方SEO指南中強調，蜘蛛暫時無法讀取圖片、flash等的內容，網站中出現圖片時，要做好圖片屬性設置，也就是ALT啦，一方面它可以告訴搜索引擎這是關于什么的圖片，另一方面當瀏覽器無法展示圖片時，會以文字的形式展現，還可增加關鍵詞密度。

要求：1、網站所有圖片都加上ALT屬性，命名合理，不重復。

2、圖片上方、或者下方加上關鍵詞錨文本

3、增加圖片頁面的內鏈和外鏈，優化重要圖片

診斷網站狀況：發現網站所有圖片沒有ALT屬性，修改完善圖片ALT屬性，對重要圖片進行優化，做好圖片站內鏈接，圖片周圍多出現關鍵詞和錨文本。

診斷分析：做好ALT屬性可以展現網站對搜索引擎的友好度，增加客戶體驗性。

第七步，診斷robots文件

對收錄及排名沒有影響、不重要的網頁內容，或者不想讓搜索引擎抓取的內容，可以通過robots協議禁止

要求：網站中要有robots文件，并且代碼正確，對不需要搜索引擎抓取的部分進行禁止。

診斷網站狀況：網站有robots文件，對一些無需抓取的內容進行了禁止。

robots文件網址：xxx.cn/robots.txt

診斷分析：robots文件重要，但書寫一定要正確，否則可以事得其反，最好請技術人員解決。

第八步，診斷死鏈接

死鏈接就是用戶點擊無法展示的頁面，或者已經不在的頁面，死鏈接會影響搜索引擎的友好度，會告成因客戶體驗差，而流失目標客戶，嚴重影響轉化率。

要求：網站無死鏈接。

診斷網站狀況：整站無死鏈接

診斷分析：如何診斷死鏈接，查找死鏈接可以借助站長工具，這個不要我多講吧。

第九步，網站404頁面

404頁面是當網站出現死鏈接時，自動轉到404頁面，引導用戶瀏覽其它首頁，避免用戶流失。

要求：網站要有友好的404頁，對死鏈接進行轉化引導。

診斷網站狀況：網站沒有404網頁，設計和完善好404頁面。

第十步，網站空間速度診斷

為什么要求網站空間打開速度要快，這個問題也太小白了吧，你會在一個等了半天也不開的門前，傻等半天嗎?客戶是沒有耐心等待的

要求：網站打開速快，不影響用戶抓取和用戶瀏覽

診斷網站狀況：最快5毫秒，最慢68妙，電信平均：36毫秒，聯通平均：56毫秒

診斷分析：速度就不解釋了，當然是越快越好。

第十一步，快照更新診斷

只有快照更新有規律的網站，才是搜索引擎喜歡的網站，如果你的網站快照好久都沒有更新，那你就要想想是不是百度不愛你啦，百度可能不喜歡你的網站了，我們必須經常更新網站內容，讓蜘蛛不斷有新東西吃，有新鮮感，

要求：百度快照更新不超過去3天，網站有經常更新版塊，如新聞更新、產品更新、評論更新等，并適時更新。

診斷網站狀況：百度第一次快照時間：2012-9-25，最新快照時間2012-10-15，更新速度慢，站內有新聞更新版塊，無用戶評論交互功能。

診斷分析：建議用適當提高網站外鏈和網站內容更新，改善兩次快照間隔時間太長的現象

篇7

1、收集待索引網頁的url

Internet上存在的網頁數量絕對是個天文數字，每天新增的網頁也不計其數，搜索引擎需要首先找到要索引收錄的對象。

具體到Google而言，雖然對GoogleBot是否存在DeepBot與FreshBot的區別存在爭議——至于是否叫這么兩個名字更是眾說紛耘，當然，名字本身并不重要——至少到目前為止，主流的看法是，在Google的robots中，的確存在著相當部分專門為真正的索引收錄頁頁準備“素材”的robots——在這里我們姑且仍稱之為FreshBot吧——它們的任務便是每天不停地掃描Internet，以發現并維護一個龐大的url列表供DeepBot使用，換言之，當其訪問、讀取其一個網頁時，目的并不在于索引這個網頁，而是找出這個網頁中的所有鏈接。——當然，這樣似乎在效率上存在矛盾，有點不太可信。不過，我們可以簡單地通過以下方式判斷：FreshBot在掃描網頁時不具備“排它性”，也即是說，位于Google不同的數據中心的多個robots可能在某個很短的時間周期，比如說一天甚至一小時，訪問同一個頁面，而DeepBot在索引、緩存頁面時則不會出現類似的情況，即Google會限制由某個數據中心的robots來完成這項工作的，而不會出現兩個數據中心同時索引網頁同一個版本的情況，如果這種說法沒有破綻的話，則似乎可以從服務器訪問日志中時?？梢钥吹皆醋圆煌琁P的GoogleBot在很短的時間內多次訪問同一個網頁證明FreshBot的存在。因此，有時候發現GoogleBot頻繁訪問網站也不要高興得太早，也許其根本不是在索引網頁而只是在掃描url。

FreshBot記錄的信息包括網頁的url、Time Stamp(網頁創建或更新的時間戳)，以及網頁的Head信息(注：這一點存在爭議，也有不少人相信FreshBot不會去讀取目標網頁信息的，而是將這部分工作交由DeepBot完成。不過，筆者傾向于前一種說法，因為在FreshBot向DeepBot提交的url列表中，會將網站設置禁止索引、收錄的頁面排除在外，以提高效率，而網站進行此類設置時除使用robots.txt外還有相當部分是通過mata標簽中的“noindex”實現的，不讀取目標網頁的head似乎是無法實現這一點的)，如果網頁不可訪問，比如說網絡中斷或服務器故障，FreshBot則會記下該url并擇機重試，但在該url可訪問之前，不會將其加入向DeepBot提交的url列表。

總的來說，FreshBot對服務器帶寬、資源的占用還是比較小的。最后，FreshBot對記錄信息按不同的優先級進行分類，向DeepBot提交，根據優先級不同，主要有以下幾種：

A：新建網頁；B：舊網頁/新的Time Stamp，即存在更新的網頁；C：使用301/302重定向的網頁；D：復雜的動態url，如使用多個參數的動態url，Google可能需要附加的工作才能正確分析其內容?！S著Google對動態網頁支持能力的提高，這一分類可能已經取消；E：其他類型的文件，如指向PDF、DOC文件的鏈接，對這些文件的索引，也可能需要附加的工作；F：舊網頁/舊的Time Stamp，即未更新的網頁，注意，這里的時間戳不是以Google搜索結果中顯示的日期為準，而是與Google索引數據庫中的日期比對；G：錯誤的url，即訪問時返回404回應的頁面；

優先級按由A至G的順序排列，依次降低。需要強調的是，這里所言之優先級是相對的，比如說同樣是新建網頁，根據指向其的鏈接質量、數量的不同，優先級也有著很大的區別，具有源自相關的權威網站鏈接的網頁具有較高的優先級。此外，這里所指的優先級僅針對同一網站內部的頁面，事實上，不同網站也有有著不同的優先級，換言之，對權威網站中的網頁而言，即使其最低優先級的404 url，也可能比許多其他網站優先級最高的新建網頁更具優勢。

2、網頁的索引與收錄

接下來才進入真正的索引與收錄網頁過程。從上面的介紹可以看出，FreshBot提交的url列表是相當龐大的，根據語言、網站位置等不同，對特定網站的索引工作將分配至不同的數據中心完成。整個索引過程，由于龐大的數據量，可能需要幾周甚至更長時間才能完成。

正如上文所言，DeepBot會首先索引優先級較高的網站/網頁，優先級越高，出現在Google索引數據庫及至最終出現在Google搜索結果頁面中的速度便越快。對新建網頁而言，只要進入到這個階段，即使整個索引過程沒有完成，相應的網頁便已具備出現在Google索引庫中的可能，相信許多朋友在Google中使用“site:somedomain.com”搜索時常?？吹綐俗檠a充結果只顯示網頁url或只顯示網頁標題與url但沒有描述的頁面，此即是處于這一階段網頁的正常結果。當Google真正讀取、分析、緩存了這個頁面后，其便會從補充結果中逃出而顯示正常的信息?！斎?，前提是該網頁具有足夠的鏈接，特別是來自權威網站的鏈接，并且，索引庫中沒有與該網頁內容相同或近似的記錄(Duplicate Content過濾)。

對動態url而言，雖然如今Google宣稱在對其處理方面已不存在障礙，不過，可以觀察到的事實仍然顯示動態url出現在補充結果中的幾率遠大于使用靜態url的網頁，往往需要更多、更有價值的鏈接才能從補充結果中逸出。

而對于上文中之“F”類，即未更新的網頁，DeepBot會將其時間戳與Google索引數據庫中的日期比對，確認盡管可能搜索結果中相應頁面信息未來得及更新但只要索引了最新版本即可——考慮網頁多次更新、修改的情況——；至于“G”類即404 url，則會查找索引庫中是否存在相應的記錄，如果有，將其刪除。

3、數據中心間的同步

前文我們提到過，DeepBot索引某個網頁時會由特定的數據中心完成，而不會出現多個數據中心同時讀取該網頁，分別獲得網頁最近版本的情況，這樣，在索引過程完成后，便需要一個數據同步過程，將網頁的最新版本在多個數據中心得到更新。

這就是之前著名的Google Dance。不過，在BigDaddy更新后，數據中心間的同步不再象那樣集中在特定的時間段，而是以一種連續的、時效性更強的方式進行。盡管不同數據中心間仍存在一定的差異，但差異已經不大，而且，維持的時間也很短。

提高搜索引擎索引收錄網頁的效率，根據上面的介紹，可以看出，要想讓您的網頁盡可能快、盡可能多地被搜索引擎收錄，至少應從如下幾方面進行優化：

提高網站反相鏈接的數量與質量，源自權威網站的鏈接可以讓您的網站/網頁在第一時間內被搜索引擎“看到”。當然，這也是老生常談了。從上面的介紹可以看出，要提高網頁被搜索引擎收錄的效率，首先要讓搜索引擎找到您的網頁，鏈接是搜索引擎找到網頁的唯一途徑——“唯一”一詞存在些許爭議，見下面的SiteMaps部分——從這個角度看，向搜索引擎提交網站之類的作法沒有必要且沒有意義，相對而言，要想讓您的網站被收錄，獲得外部網站的鏈接才是根本，同時，高質量的鏈接也是讓網頁步出補充結果的關鍵因素。

網頁設計要秉持“搜索引擎友好”的原則，從搜索引擎spider的視角設計與優化網頁，確保網站的內部鏈接對搜索引擎“可見”，相對于獲得外部網站鏈接的難度，合理規劃的內部鏈接是提高搜索引擎索引與收錄效率更經濟、有效的途徑——除非網站根本未被搜索引擎收錄。

如果您的網站使用動態url，或者導航菜單使用JavaScript，那么，當在網頁收錄方面遇到障礙時，應首先從這里著手。

使用SiteMaps。事實上，許多人認為Google取消了FreshBot的一個主要原因便是SiteMaps(xml)協議的廣泛應用，認為這樣只需讀取網站提供的SiteMaps便可得到網頁更新信息，而不需FreshBot耗時費力地掃描。這種說法還是有一定道理的，雖然目前不能確定Google究竟直接使用SiteMaps作為DeepBot的索引列表還是用做FreshBot的掃描路標，但SiteMaps能夠提高網站索引收錄的效率則是不爭的事實。比如說，SEO探索曾做過如下的測試：

兩個網頁，獲得的鏈接情況相同，一個加入SiteMaps而另一未加入，出現在SiteMaps中的網頁很快被收錄，而另一個頁面則在過了很長時間后才被收錄；

篇8

1.百度對自個兒旗下的服務給予特別待遇

大家在百度上輕易搜一下子便會發覺，百度旗下的百度各種學科，百度曉得，百度貼吧…等，在搜索最后結果中有相當高的名次，在某些高熱度網站關鍵詞上頭，幾乎大多的搜索最后結果都是來自百度自身的產品。在這些個方面，百度從來表現出來出公平性，與google差距甚大。

2.百度的蛛蛛給眾多服務器增加了壓力

固然Baiduspider或者遵循那一個robots.txt文件，不過在某些大網站上頭，百度蛛蛛依舊發瘋的爬動，很很長時間候，固然它不收錄網站，不過它依舊發瘋的爬動，給眾多網站服務器增加莫大的壓力。

3.百度競價名次，如今叫百度搜索推廣

篇9

>> 互聯網安全的常用技術 論在互聯網的管理中網絡管理協議的應用研究 基于互聯網地址協議的應用與發展研究 空間互聯網傳輸協議和存在的問題 Robots協議維護互聯網秩序 基于互聯網信報控制協議的災情信息獲取技術研究與應用 互聯網金融的發展研究 “互聯網+教育”的發展研究 基于互聯網旅游的研究 “互聯網+審判”的實證研究 基于社會系統研究方法的“互聯網+電子商務物流”體系研究 戰術互聯網抗毀性方法研究 互聯網企業數據資產價值評估方法研究 淺析IPv6互聯網協議的安全性 BGP路由協議在鐵通互聯網中的應用 互聯網行業VIE協議控制的法律效力 淺析OSI七層協議在互聯網中的效應 移動互聯網時代下的高校輔導員工作方法創新研究 互聯網時代改進和完善黨管媒體的方法研究 移動互聯網業務對移動網絡沖擊的評估方法研究 常見問題解答 當前所在位置：l

第二確定您所研究的協議的最新版本的RFC文件。

如前文所述，在RFC-2400中有協議的完整清單，按照清單找到的RFC一般是協議的最新版本，如果協議的STATE是Standard就更好了。如下文所分析的FTP協議的RFC文件是RFC-959。

第三，獲取RFC文件

根據RFC文件編號查看以上站點的RFCs文件索引

在里面您可以很快地找到您要找的RFC文件。

第四，閱讀描述協議的RFC文件全文

這不用說了。

第五，實踐

實踐是檢驗真理的唯一標準，雖然互聯網協議不是什么真理，但如果能實踐一下對理解和掌握都有好處，許多互聯網應用層的協議可視程度非常高，協議中許多控制和參數用英文短語來表示，所傳輸的數據如文本也是ASCII碼，如HTTP，FTP等，這類協議單純用Telnet就可以模擬一下客戶端程序的運作，當然，編程實現是最好的鍛煉。

第六，總結

總結確實是不錯的學習方法，自己的文章是一面鏡子。

3.舉例：FTP協議分析

FTP協議的定義在 RFC-959 "FILE TRANSFER PROTOCOL"（Standard，Recommended）。

3.1介紹

FTP 文件傳輸協議（File Transfer Protocol）

FTP協議是一個應用層協議，在TCP上實現的。

開發FTP的目的是

1）促進文件（計算機程序和/或數據）的共享。

2）鼓勵對遠程計算機間接或隱式（implicit）（通過程序）的使用。

3）對用戶屏蔽不同主機系統中的文件儲存的細節。

4）可靠和高效率地實現文件的傳送。

用戶雖然可以直接通過一個終端使用FTP協議，但FTP協議的設計主要是給程序使用的。

3.2常用的FTP命令解釋

由于篇幅所限，這里不對以上每個FTP命令做解釋，這里僅解釋一下作者認為比較重要或常用的FTP命令，如果讀者需要深入了解請參閱 RFC-959 "FILE TRANSFER PROTOCOL"。

USER NAME（USER〈sp〉〈username〉）

本命令的參數〈username〉標識用戶名，服務器憑這個用戶的權限使用文件系統。這個命令一般是在控制連接后的第一個命令。這個命令成功執行后，服務器會等待PASS命令，PASS也成功執行后，用戶才算等錄成功，可以存取Server-FTP中的文件。

PASSWORD（PASS〈sp〉〈password〉）

這個命令是USER命令的補充，向Server-FTP發送由〈password〉所表示的密碼，該命令執行成功，USER命令所指示的〈username〉才算成功登錄。這里的〈password〉是明文傳送。

CHANGE WORKING DIRECTORY（CWD〈SP〉〈pathname〉）

令Server-FTP改變當前目錄到〈pathname〉。

LOGOUT（QUIT）

這個命令表示用戶停止使用FTP，Server-FTP會關閉控制連接。

DATA PORT（PORT 〈SP〉〈host-port〉）

User-FTP這個命令告訴Server-FTP，等待Server-DTP連接的DTP（可能是User-DTP或其他的Server-DTP）的地址，〈host-port〉所指示的就是這個地址，具體的PORT命令形式如下。

PORT h1，h2，h3，h4，p1，p2

以上六個參數都是小于256的數字。

h1，h2，h3，h4表示IP地址，如192，168，0，1 表示IP地址是192.168.0.1的主機。

p1，p2，表示端口號，注意p1和p2都是小于256，所以1000表示為3，232（1000=3*256+232）

RETRIEVE（RETR〈SP〉〈pathname〉）

這個命令請求Server-FTP通過數據連接向User-DTP傳送由〈pathname〉指示的文件的數據。

STOR（RETR 〈SP〉〈pathname〉）

這個命令請求Server-FTP通過數據連接接收User-DTP傳送的數據，數據保存在由〈pathname〉指示的文件中。注意〈pathname〉是在Server-FTP的主機上的。

PRINT WORKING DIRECTORY（PWD）

Server-FTP收到該命令后在回應中返回當前工作目錄名。

LIST（LIST [〈SP〉〈pathname〉]）

Server-FTP收到該命令后向User-DTP發送目錄〈pathname〉的文件目錄信息。如果沒有〈pathname〉參數，則返回當前目錄的文件目錄信息。

STATUS（STAT [〈SP〉〈pathname〉]）

這個命令的回應有兩種情況，沒有〈pathname〉參數和有〈pathname〉參數。

1）沒有參數，Server-FTP會在回應中返回的一些狀態信息，如以下是我Linux上的Server-FTP返回的信息：

211-zfm.home FTP server status：

Version wu-2.4.2-VR17（1）Mon Apr 19 09：21：53 EDT 1999

Connected to zfl_k6.home（192.168.0.1）

Logged in as fszfl

TYPE：ASCII，FORM：Nonprint；STRUcture：File；transfer MODE：Stream

No data connection

0 data bytes received in 0 files

0 data bytes transmitted in 0 files

0 data bytes total in 0 files

145 traffic bytes received in 0 transfers

4306 traffic bytes transmitted in 0 transfers

4501 traffic bytes total in 0 transfers

211 End of status

2）如果有〈pathname〉參數，則在回應中返回〈pathname〉的目錄信息，如以下是我發送STAT . 的結果：

213-status of .：

total 64

drwxrwxr-x 2 fszfl fszfl 1024 Nov 25 01：37 .

drwx------ 12 fszfl fszfl 1024 Nov 29 00：35 ..

213 End of Status

這個功能好象和LIST有點相似，但LIST中的目錄信息在數據連接中返回的。

HELP [〈SP〉〈string〉]

這是幫助命令，如果沒有參數則返回FTP命令列表，如果有參數則返回〈string〉表示的命令的語法。

3.3 FTP回應

3.3.1 回應的格式

FTP回應有3位數字編碼和有關信息的文本組成，編碼后一個分隔符，如果回應中返回信息的長度大于一行，則編碼后跟減號（-），否則跟空格（〈sp〉）。多于一行的信息可以參考上面的例子。注意最后還有"213 End of Status"表示信息的結束。FTP回應使用的編碼是約定好的，信息文本可以由具體的Server-FTP設計。顯然，編碼為了方便程序設計，文本信息可以方便閱讀。

為了敘述方便，下文把這3位編碼稱為回應碼。

3.3.2 回應碼含義

3位回應碼的每一位都有確定的含義。第一位表示命令的執行結果，表示成功，失敗，或命令沒有完成。第二位表示回應的類型，第三位一般指第二位的進一步細化，預留給將來的發展。

第1位可能的取值：

1yz 初步確認（Positive Preliminary reply）

表示請求的命令已經開始，請等待進一步的回應，在此之前不要發送新的FTP命令。

2yz 完成確認（Positive Completion reply）

表示請求的命令已經成功完成，可以發送新的請求。

3yz 中間狀態確認（Positive Intermediate reply）

請求的命令已經被接受，等待下一條相關的命令提供進一步的信息。這個回應用于一些命令序列中，如USER和PASS，如果USER被接受則可以得到這個回應，表明還需要密碼來完成用戶的登錄。

4yz 暫時否認（Transient Negative Completion reply）

Server-FTP由于一些暫時的原因沒有接收命令，User-FTP最好重新請求這個命令。如果是命令序列，則需要從該序列的第一條指令開始。

5yz 命令有錯（Permanent Negative Completion reply）

命令沒有被接收，具體的拒絕原因由回應碼第二位指出。

第2位可能的取值，描述回應的分類：

x0z 語法（Syntax）- 命令語法不正確，或Server-FTP沒有實現這個功能。

x1z 信息（Information）- 描述如STAT或HELP等命令要求Server-FTP信息的返回。

x2z 連接（Connections）- 描述有關控制和數據連接。

x3z 帳戶和認證（Authentication and accounting）- 登錄過程的回應。

x4z 現在還沒有指定。

x5z 文件系統（File system）- 這個回應反映服務器的文件系統的狀態。

第3位的的含義需要根據第1，2位的值再細化。

3.3.3 回應舉例

3位回應碼的不同組合產生了許多不同的含義，篇幅所限不一一列舉，具體請查 RFC-959。下面是幾個例子：

200 Command okay.

500 Syntax error，command unrecognized.

501 Syntax error in parameters or arguments

篇10

2、中國領潮互聯網時代的管理變革。以“人單合一”為核心的“海爾模式”，被稱為繼管理1.0(美國泰勒制)、管理2.0(日本豐田模式)之后的管理3.0(中國成功經驗)。3月24日，全國企業管理創新大會以“互聯網時代的管理變革”為中心議題，隆重推出海爾模式。國務院國資委、工業和信息化部、中國企業聯合會，以及哈佛商學院、沃頓商學院、美國會計師學會，共同把來自互聯網的海爾模式，推薦為人類第三代管理。它標志著來自中國的第一個普世價值，出自互聯網。

3、中國電子商務爆發臨界點5%，互聯網已經成為中國擴大內需的新引擎。2012年12月3日，阿里巴巴集團宣布，旗下淘寶和天貓的交易額本年度突破一萬億元。天貓雙十一購物狂歡節創造191億單日銷售額。根據國家統計局數據，2011年全國各省社會消費品零售總額為18.39萬億，一萬億相當于其總量的5.4%。而根據國家統計局的2011年全國各省社會消費品零售總額排行，可以排列第五位，僅次于廣東、山東、江蘇和浙江。

4、中國互聯網社會治理的第一個成功范例產生。由百度與奇虎360之間的搜索引擎大戰，觸發了新治理模式的產生。11月1日，在中國互聯網協會組織下，12家企業簽署《互聯網搜索引擎服務自律公約》，承諾遵守包括robots協議在內的國際行業慣例、公平競爭、保護用戶權益。這件事的重要性在于，它是介于政府與市場之間的社會機制，在調解行業復雜矛盾中，發揮了自組織、自協調作用。開創了政府干預與市場自發調節之外，互聯網治理的一種可行的新模式。

5、微信走上中國互聯網的歷史舞臺。支持發送語音短信、視頻、圖片和文字的跨平臺智能即時通訊工具微信問世。有潛力成為繼QQ之后，中國互聯網的又一殺手應用。