Twitter预连接到错误的域名

Twitter试图减少外部链接的加载时间，但它反而让速度变慢了。它错误地将域名正常化到无法再用于完成其任务的程度。

我以前写过关于何时使用<；link rel="；preconnect"；>；的信息。如果您不熟悉这个主题，那篇文章也可以作为介绍。

Twitter通过其t.co链接缩短服务重定向链接。它曾经是其服务的有用补充，因为它帮助人们保持在严格的性格限制之下。链接缩短器将所有链接减少到23个字符。Twitter通过点击流数据和对热门链接的洞察，获得了更多关于其用户的数据洞察力。

然而，链路缩短服务还有另一个代价：链路解析速度较慢。浏览器需要连接到Twitter的链接缩短服务，然后重定向到目标网站，而不是直接点击进入目标网站。为了加快这一过程，每当你将链接卡滚动到视图中时，Twitter都会预先连接到它的链接缩短服务。链接卡是显示链接的图像、标题和描述的框。这表明Twitter发现人们极有可能点击推文中的外部链接。

为了进一步加快速度，Twitter还预先连接到重定向另一端的目的地网站。不过，这就是它犯了一些错误的地方。

您可能会想，既然它已经知道目的地址，为什么还要使用链接缩短服务。重读上一段，以澄清Twitter的动机。

在我继续讨论这些问题之前，我必须先谈一谈隐私问题。预连接不传输任何HTTP标头、Cookie或其他标识数据。目标网站不知道客户端为什么在这一点上打开到它的连接。它刚刚打开了一个连接，正在等待传入的请求。它的服务器可以识别用于建立连接的TLS库和版本，但这绝不是唯一的数据。可以观察到相关网络流量的第三方将知道用户试图连接到或看到与所讨论的域名或服务器的链接。

也就是说，Twitter经常会预先连接到错误的网站。作为示例，让我们看看@CtrlBlog和@nyTimes发布的tweet。这些帐户共享的链接链接到www.ctrl.blog和www.nytimes.com域。Twitter没有在这里预先连接，而是预先连接到ctrl.blog和nytimes.com。当然，这些连接连接到错误的服务器，因此它们永远不会被使用。

奇怪的是，通过Twitter Advertising发布的推文(不管你是否将该推文视为广告)没有这个问题。这些tweet不使用t.co，总是预先连接到正确的服务器(除了预先连接到错误的服务器之外)。

用于预连接的不正确域名似乎源自Twitter API的显示URL属性。它把万维网去掉了。前缀以生成URL的“显示版本”。我对此没有问题，因为前缀对人类来说是完全没有意义的。然而，它确实具有重要的技术功能。Twitter不会将其从实际的重定向URL中删除。

让我们更详细地了解当用户单击链接以及浏览器开始使用预连接时会发生什么。

首先，浏览器现在需要解析包括www的域名。前缀。其次，浏览器需要建立TCP连接并建立TLS连接。如果Twitter一开始只连接到正确的域，那么所有这些步骤都已经完成了。

很难说这个问题是什么时候开始的。我不能看老版本的Twitter，因为它的页面在互联网档案馆的Wayback机器上不能很好地工作。想想看，Twitter应该从一开始就预先连接到所有这些网站吗？

在我关于何时使用<；link rel=<；link rel=<；preconnect"；>；的文章中，我讨论了使用预连接技术有益的情况。我同意Twitter的观点，在某些情况下，预连接到目的地地址可能会很有用。例如，当Twitter消息或链接卡是页面上唯一的东西时，或者当您停止滚动并使其在一两秒钟内可见时。

然而，Twitter不分青红皂白地预先连接到您在提要中滚动的每个链接。从技术上讲，只有当您将鼠标悬停在链接上时，它才会预连接。但是，默认情况下，当您将鼠标光标放在主提要上并向下滚动时，您会将鼠标悬停在每个链接上。根据你关注的人的链接共享习惯，预连接的数量很快就会增加。这可能会降低您在网络速度较慢或低端设备上的浏览体验。

正确测试预连接行为需要专业工具和技能。Web浏览器中的开发人员工具在预连接方面做得不好。它们甚至没有记录在网络选项卡中。Safari为每个预连接显示一条消息，并在其控制台选项卡中警告未使用的预连接。