Stack Exchange上有超过三百万个不同的链接。经过很长时间，许多链接已经不能用了。
最近我花时间编写了一个工具，它能判断哪些是坏链，能帮助我们来修复死链链。
我们是怎么做的?
首先，我们要对他人的网站心存敬意。
做一个好的网民
● 对每个域名限制请求
我们采用自动过期的set，来确保十秒钟内对单个域名不会请求多过一次。当我们觉得需要对某些链接进行更多的测试时，我们也做了特殊处理。
public class AutoExpireSet<T> { Dictionary<T, DateTime> items = new Dictionary<T, DateTime>(); Dictionary<T, TimeSpan> expireOverride = new Dictionary<T, TimeSpan>(); 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; } } }
● 健壮的验证函数
我们的验证函数包括了许多我认为非常重要的概念。
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; } }
● 从第一天开始就设置正确的User Agent字符串
如果什么地方出错了，你希望他人能够联系到你。我们的链接爬虫的user agent字符串为: Mozilla/5.0 (compatible; stackexchangebot/1.0; +http://meta.stackoverflow.com/q/130398)。
● 处理302, 303, 307等页面跳转
尽管302和303跳转非常常见，307却不多见。它被作为一种针对浏览器的错误表现的解决方法被引入，解释见此处。
307最著名的例子是http://www.haskell.org。我非常不赞同在首页就跳转地做法，URL重写以及其他的工具可以解决这个问题，而不需要有多余的跳转;但是，首页跳转仍旧存在。
当你跳转时，你需要继续测试。我们的链接测试机会测试最多五层。你需要设置层次上限，否则你会陷入无限循环。
跳转有时很奇怪，网站有时会把你导向到about:config或一个不存在的URL。检验跳转的页面信息很重要。
● 当你获得所需要的信息时，请及时中断请求
在TCP协议中，包收到时，特殊的状态会被标记。当客户端发送给服务器的包中标记了FIN的话，连接会早早的中止。调用request.Abort你可以避免在404时从服务器端下载大量数据。
当测试链接时，你经常需要避免HTTP keepalive。因为我们的测试机没必要给服务器造成不必要得连接负担。
中断可以减少压缩,但我非常赞成启用压缩。
● 先使用HEAD请求，再用GET请求
一些服务器不使用HEAD。例如，Amazon完全禁止了，对HEAD请求返回405。在ASP.NET MVC中，人们经常显式设置路由经过的verb属性。程序员们在规定使用HttpVerbs.Get时往往没有使用HttpVerbs.Head。所以当你失败时(没有获得200响应)，你需要重新使用GET verb来测试。(译者：这一段不是很懂，如有错误请指正。)
● 忽略robots.txt
开始我打算做一个好网民，解析了所有的robots.txt文件，遵守排除和爬虫频率。但事实上许多网站如GitHub, Delicious和Facebook都有针对爬虫的白名单。所有的爬虫都被屏蔽了，除了那些著名的允许爬虫的网站(如Google, Yahoo和Bing)。因为链接测试机是不会抓取网页，关注robots.txt也不现实，所以我建议忽略robots.txt。这在Meta Stack Overflow也有讨论。
● 使用合理的超时
测试时，我们给网站30s来响应，但有些网站需要更长时间。你当然不想让一个恶意的网站让你的测试机停止。所以我们采用30s作为最长的响应时间。
● 用很多线程来测试链接
我用在悉尼的开发电脑来做链接测试，显然串行的三百万次访问不知道会占用多长时间。所以我用了30个线程。
并发当然也会带来一些技术挑战。你也不想在等待一个域名释放资源的时候让一个线程阻塞。
我采用Async类来管理队列。相对于微软的任务并行库(Microsoft Task Parallel Library)，我更喜欢Async，因为使用它来限制线程池中的线程数量非常简单，而且API也简单易用。
● 一次实效不代表永久失效
我仍旧在调整判断一个链接是坏链的算法。一次失效有可能是偶然事件。一个星期内的数次失效可能是服务器坏掉或者不幸的巧合。
现在隔天的两次失效看起来比较可靠 – 我们没有去寻找最完美的算法，而是让用户告诉我们什么时候出错了，但我们相信出错率不高。
同样的我们仍旧需要确定在一次成功测试之后多久药重新测试。我想每隔三个月测一次就足够了。
测试链接的一些有趣发现
Kernel.org被黑了
2011年9月1日，Kernel.org被黑了。你要问，这和测试链接有什么关系呢?
事实证明有人破坏了所有的文档链接，这些链接今天仍旧不能用。例如http://www.kernel.org/pub/software/scm/git/docs/git-svn.html 在Stack Overflow的150个左右的帖子里出现过，现在它们会将你导向到404页面，而它的新地址应该在：http://git-scm.com/docs/git-svn。在所有我碰到的坏链中，git文档的坏链是最严重的。将近影响了6000个帖子。采用Apache的重写功能来处理它是非常容易的。
有的网站的URL不能给你任何信息
http://www.microsoft.com/downloads/details.aspx?familyid=e59c3964-672d-4511-bb3e-2d5e1db91038displaylang=en 是个坏链，在60个左右的帖子中出现。想象下，如果这个链接类似于http://www.microsoft.com/downloads/ie-developer-toolbar-beta-3，那么就算微软打算移走这个链接，我们仍旧克一猜测它可能带我们去到什么页面。
将你的404页面做的别致和有用–从GitHub学到的
在所有的404页面中，GitHub的让我最生气。
你问为什么?
它看起来很酷，有相当不错的视觉效果。有些人就是看什么都不顺眼。
嗯，事实上是：
https://github.com/dbalatero/typhoeus 在50个左右的帖子里被引用，而它已经转移到https://github.com/typhoeus。GitHub没有使用任何的跳转，仅仅将你转到404页面。
对url采用最基本的解析以确定真正想要去的页面是非常小的开销：
对不起，我们没有找到你链接到的页面。用户经常会改变账户导致链接失效。”typhoeus”库也存在于：https://github.com/typhoeus
是的，没有任何信息告诉我我犯了个错误。GitHub应该让404页面变得更有用。对我来说GitHub 404页面最让我气愤地是我花了很多力气而找不到结果。不要给我漂亮的页面，能提供一些有用的信息吗。
你可以做多一步，跳转到他们新的首页去，我理解账号是非常有技巧的，但它看起来在GitHub上是多么不可思议的常见错误啊。
在Stack Overflow上我们花了很多时间来优化这种情况，例如“你最喜欢的程序员笑话是什么?”，讨论区认为这个问题不会持续很久，所以我们尽可能解释为什么要移除它，以及哪里可以找到它。
Oracle的问题
Oracle收购Sun对Java生态圈来说是个永远的沉重的打击。Oracle的任务是重新树立品牌，重构Java生态圈，但这是错误的引导。大量的文档都没有被正确定向。就连最近的在dev.java.net下的所有项目都没有正确的跳转页面。Hudson这个Java持续集成的服务器曾经使用https://hudson.dev.java.net/ (译者注：也失效了)，Stack Overflow中150个帖子都引用了它。
个人的教训
href 标题的重要性
在短链的世界里，看起来在URI里使用任何合理的标题不再那么被鼓励了。事实上过去的三年里你访问的5%的链接都失效了。我相信我的博客中也有许多坏链。修复坏链是个困难的任务，尤其在没有上下文的情况下，这项任务变得更加困难。
所以我决定为我的链接都加上合理的标题。不仅因为能让搜索引擎更好地搜索结果，也能让用户知道受损的图片下是什么内容，同时在处理坏的势后能帮我修复它。
超链接是很脆弱的
当我们使用Google时，我们从来没得到404。它确保我们在杂乱无章的网络中高效的搜索。测试很多的链接告诉你现实并没有那么的好。那么意味着我要避免使用链接吗?当然不是，知道问题的存在能够帮我思考我写下的内容。我会避免写出失去意义的文章。在Stack Overflow我们经常看到如下的回复：
See this blog post over here. 看看这里的文章。
当外部资源链接失效的时候，这种答案就没有了意义。
参考资料
原文：samsaffron.com
翻译：伯乐在线
