新聞中心
Stack Exchange上有超過三百萬個不同的鏈接。經(jīng)過很長時間,許多鏈接已經(jīng)不能用了。

創(chuàng)新互聯(lián)公司專注于天柱網(wǎng)站建設(shè)服務(wù)及定制,我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供天柱營銷型網(wǎng)站建設(shè),天柱網(wǎng)站制作、天柱網(wǎng)頁設(shè)計、天柱網(wǎng)站官網(wǎng)定制、重慶小程序開發(fā)服務(wù),打造天柱網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供天柱網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。
最近我花時間編寫了一個工具,它能判斷哪些是壞鏈,能幫助我們來修復(fù)壞鏈。
我們是怎么做的?
首先,我們要對他人的網(wǎng)站心存敬意。
做一個好的網(wǎng)民
● 對每個域名限制請求
我們采用自動過期的set,來確保十秒鐘內(nèi)對單個域名不會請求多過一次。當我們覺得需要對某些鏈接進行更多的測試時,我們也做了特殊處理。
- public class AutoExpireSet
- {
- Dictionary
items = new Dictionary (); - Dictionary
expireOverride = - new Dictionary
(); - int defaultDurationSeconds;
- public AutoExpireSet(int defaultDurationSeconds)
- {
- this.defaultDurationSeconds =
- defaultDurationSeconds;
- }
- public bool TryReserve(T t)
- {
- bool reserved = false;
- lock (this)
- {
- DateTime dt;
- if (!items.TryGetValue(t, out dt))
- {
- dt = DateTime.MinValue;
- }
- if (dt < DateTime.UtcNow)
- {
- TimeSpan span;
- if (!expireOverride.TryGetValue(t, out span))
- {
- span =
- TimeSpan.FromSeconds(defaultDurationSeconds);
- }
- items[t] = DateTime.UtcNow.Add(span);
- reserved = true;
- }
- }
- return reserved;
- }
- public void ExpireOverride(T t, TimeSpan span)
- {
- lock (this)
- {
- expireOverride[t] = span;
- }
- }
- }
● 健壯的驗證函數(shù)
我們的驗證函數(shù)包括了許多我認為非常重要的概念。
- public ValidateResult Validate(
- bool useHeadMethod = true,
- bool enableKeepAlive = false,
- int timeoutSeconds = 30 )
- {
- ValidateResult result = new ValidateResult();
- HttpWebRequest request = WebRequest.Create(Uri)
- as HttpWebRequest;
- if (useHeadMethod)
- {
- request.Method = "HEAD";
- }
- else
- {
- request.Method = "GET";
- }
- // always compress, if you get back a 404 from a HEAD
- // it can be quite big.
- request.AutomaticDecompression = DecompressionMethods.GZip;
- request.AllowAutoRedirect = false;
- request.UserAgent = UserAgentString;
- request.Timeout = timeoutSeconds * 1000;
- request.KeepAlive = enableKeepAlive;
- HttpWebResponse response = null;
- try
- {
- response = request.GetResponse() as HttpWebResponse;
- result.StatusCode = response.StatusCode;
- if (response.StatusCode ==
- HttpStatusCode.Redirect ||
- response.StatusCode ==
- HttpStatusCode.MovedPermanently ||
- response.StatusCode ==
- HttpStatusCode.SeeOther ||
- response.StatusCode ==
- HttpStatusCode.TemporaryRedirect)
- {
- try
- {
- Uri targetUri =
- new Uri(Uri, response.Headers["Location"]);
- var scheme = targetUri.Scheme.ToLower();
- if (scheme == "http" || scheme == "https")
- {
- result.RedirectResult =
- new ExternalUrl(targetUri);
- }
- else
- {
- // this little gem was born out of
- // http://tinyurl.com/18r
- // redirecting to about:blank
- result.StatusCode =
- HttpStatusCode.SwitchingProtocols;
- result.WebExceptionStatus = null;
- }
- }
- catch (UriFormatException)
- {
- // another gem ... people sometimes redirect to
- // http://nonsense:port/yay
- result.StatusCode =
- HttpStatusCode.SwitchingProtocols;
- result.WebExceptionStatus =
- WebExceptionStatus.NameResolutionFailure;
- }
- }
● 從***天開始就設(shè)置正確的User Agent字符串
如果什么地方出錯了,你希望他人能夠聯(lián)系到你。我們的鏈接爬蟲的user agent字符串為: Mozilla/5.0 (compatible; stackexchangebot/1.0; +http://meta.stackoverflow.com/q/130398)。
● 處理302, 303, 307等頁面跳轉(zhuǎn)
盡管302和303跳轉(zhuǎn)非常常見,307卻不多見。它被作為一種針對瀏覽器的錯誤表現(xiàn)的解決方法被引入,解釋見此處。
307***的例子是http://www.haskell.org。我非常不贊同在首頁就跳轉(zhuǎn)地做法,URL重寫以及其他的工具可以解決這個問題,而不需要有多余的跳轉(zhuǎn);但是,首頁跳轉(zhuǎn)仍舊存在。
當你跳轉(zhuǎn)時,你需要繼續(xù)測試。我們的鏈接測試機會測試最多五層。你需要設(shè)置層次上限,否則你會陷入無限循環(huán)。
跳轉(zhuǎn)有時很奇怪,網(wǎng)站有時會把你導(dǎo)向到about:config或一個不存在的URL。檢驗跳轉(zhuǎn)的頁面信息很重要。
● 當你獲得所需要的信息時,請及時中斷請求
在TCP協(xié)議中,包收到時,特殊的狀態(tài)會被標記。當客戶端發(fā)送給服務(wù)器的包中標記了FIN的話,連接會早早的中止。調(diào)用request.Abort你可以避免在404時從服務(wù)器端下載大量數(shù)據(jù)。
當測試鏈接時,你經(jīng)常需要避免HTTP keepalive。因為我們的測試機沒必要給服務(wù)器造成不必要得連接負擔。
中斷可以減少壓縮,但我非常贊成啟用壓縮。
● 先使用HEAD請求,再用GET請求
一些服務(wù)器不使用HEAD。例如,Amazon完全禁止了,對HEAD請求返回405。在ASP.NET MVC中,人們經(jīng)常顯式設(shè)置路由經(jīng)過的verb屬性。程序員們在規(guī)定使用HttpVerbs.Get時往往沒有使用HttpVerbs.Head。所以當你失敗時(沒有獲得200響應(yīng)),你需要重新使用GET verb來測試。(譯者:這一段不是很懂,如有錯誤請指正。)
● 忽略robots.txt
開始我打算做一個好網(wǎng)民,解析了所有的robots.txt文件,遵守排除和爬蟲頻率。但事實上許多網(wǎng)站如GitHub, Delicious和Facebook都有針對爬蟲的白名單。所有的爬蟲都被屏蔽了,除了那些著名的允許爬蟲的網(wǎng)站(如Google, Yahoo和Bing)。因為鏈接測試機是不會抓取網(wǎng)頁,關(guān)注robots.txt也不現(xiàn)實,所以我建議忽略robots.txt。這在Meta Stack Overflow也有討論。
● 使用合理的超時
測試時,我們給網(wǎng)站30s來響應(yīng),但有些網(wǎng)站需要更長時間。你當然不想讓一個惡意的網(wǎng)站讓你的測試機停止。所以我們采用30s作為最長的響應(yīng)時間。
● 用很多線程來測試鏈接
我用在悉尼的開發(fā)電腦來做鏈接測試,顯然串行的三百萬次訪問不知道會占用多長時間。所以我用了30個線程。
并發(fā)當然也會帶來一些技術(shù)挑戰(zhàn)。你也不想在等待一個域名釋放資源的時候讓一個線程阻塞。
我采用Async類來管理隊列。相對于微軟的任務(wù)并行庫(Microsoft Task Parallel Library),我更喜歡Async,因為使用它來限制線程池中的線程數(shù)量非常簡單,而且API也簡單易用。
● 一次實效不代表***失效
我仍舊在調(diào)整判斷一個鏈接是壞鏈的算法。一次失效有可能是偶然事件。一個星期內(nèi)的數(shù)次失效可能是服務(wù)器壞掉或者不幸的巧合。
現(xiàn)在隔天的兩次失效看起來比較可靠 – 我們沒有去尋找最***的算法,而是讓用戶告訴我們什么時候出錯了,但我們相信出錯率不高。
同樣的我們?nèi)耘f需要確定在一次成功測試之后多久藥重新測試。我想每隔三個月測一次就足夠了。
測試鏈接的一些有趣發(fā)現(xiàn)
Kernel.org被黑了
2011年9月1日,Kernel.org被黑了。你要問,這和測試鏈接有什么關(guān)系呢?
事實證明有人破壞了所有的文檔鏈接,這些鏈接今天仍舊不能用。例如http://www.kernel.org/pub/software/scm /git/docs/git-svn.html 在Stack Overflow的150個左右的帖子里出現(xiàn)過,現(xiàn)在它們會將你導(dǎo)向到404頁面,而它的新地址應(yīng)該在:http://git-scm.com/docs /git-svn。在所有我碰到的壞鏈中,git文檔的壞鏈是最嚴重的。將近影響了6000個帖子。采用Apache的重寫功能來處理它是非常容易的。
有的網(wǎng)站的URL不能給你任何信息
http://www.microsoft.com/downloads/details.aspx?familyid=e59c3964-672d-4511-bb3e-2d5e1db91038displaylang=en 是個壞鏈,在60個左右的帖子中出現(xiàn)。想象下,如果這個鏈接類似于http://www.microsoft.com/downloads/ie- developer-toolbar-beta-3,那么就算微軟打算移走這個鏈接,我們?nèi)耘f克一猜測它可能帶我們?nèi)サ绞裁错撁妗?/p>
將你的404頁面做的別致和有用–從GitHub學(xué)到的
在所有的404頁面中,GitHub的讓我最生氣。
你問為什么?
它看起來很酷,有相當不錯的視覺效果。有些人就是看什么都不順眼。
嗯,事實上是:
https://github.com/dbalatero/typhoeus 在50個左右的帖子里被引用,而它已經(jīng)轉(zhuǎn)移到https://github.com/typhoeus。GitHub沒有使用任何的跳轉(zhuǎn),僅僅將你轉(zhuǎn)到404頁面。
對url采用最基本的解析以確定真正想要去的頁面是非常小的開銷:
對不起,我們沒有找到你鏈接到的頁面。用戶經(jīng)常會改變賬戶導(dǎo)致鏈接失效?!眛yphoeus”庫也存在于:https://github.com/typhoeus
是的,沒有任何信息告訴我我犯了個錯誤。GitHub應(yīng)該讓404頁面變得更有用。對我來說GitHub 404頁面最讓我氣憤地是我花了很多力氣而找不到結(jié)果。不要給我漂亮的頁面,能提供一些有用的信息嗎。
你可以做多一步,跳轉(zhuǎn)到他們新的首頁去,我理解賬號是非常有技巧的,但它看起來在GitHub上是多么不可思議的常見錯誤啊。
在Stack Overflow上我們花了很多時間來優(yōu)化這種情況,例如“你最喜歡的程序員笑話是什么?”,討論區(qū)認為這個問題不會持續(xù)很久,所以我們盡可能解釋為什么要移除它,以及哪里可以找到它。
Oracle的問題
Oracle收購Sun對Java生態(tài)圈來說是個永遠的沉重的打擊。Oracle的任務(wù)是重新樹立品牌,重構(gòu)Java 生態(tài)圈,但這是錯誤的引導(dǎo)。大量的文檔都沒有被正確定向。就連最近的在dev.java.net下的所有項目都沒有正確的跳轉(zhuǎn)頁面。Hudson這個 Java持續(xù)集成的服務(wù)器曾經(jīng)使用https://hudson.dev.java.net/ (譯者注:也失效了),Stack Overflow中150個帖子都引用了它。
個人的教訓(xùn)
href 標題的重要性
在短鏈的世界里,看起來在URI里使用任何合理的標題不再那么被鼓勵了。事實上過去的三年里你訪問的5%的鏈接都失效了。我相信我的博客中也有許多壞鏈。修復(fù)壞鏈是個困難的任務(wù),尤其在沒有上下文的情況下,這項任務(wù)變得更加困難。
所以我決定為我的鏈接都加上合理的標題。不僅因為能讓搜索引擎更好地搜索結(jié)果,也能讓用戶知道受損的圖片下是什么內(nèi)容,同時在處理壞的勢后能幫我修復(fù)它。
超鏈接是很脆弱的
當我們使用Google時,我們從來沒得到404。它確保我們在雜亂無章的網(wǎng)絡(luò)中高效的搜索。測試很多的鏈接告訴你現(xiàn)實并沒有那么的好。那么意味著我要避免使用鏈接嗎?當然不是,知道問題的存在能夠幫我思考我寫下的內(nèi)容。我會避免寫出失去意義的文章。在Stack Overflow我們經(jīng)常看到如下的回復(fù):
See this blog post over here. 看看這里的文章。
當外部資源鏈接失效的時候,這種答案就沒有了意義。
當前名稱:從測試300萬個超鏈接接學(xué)到的
標題鏈接:http://www.5511xx.com/article/copdhig.html


咨詢
建站咨詢
