516超巨星离网七年彼得罗斯·吉吉斯伦敦大学学院乔治·诺米科斯兰卡斯特大学马特·考尔德微软哥伦比亚大学瓦西莱奥斯·科特罗尼斯FORTH-ICS莱夫特里斯·马纳萨基斯FORTH-ICS克塞诺丰塔斯·迪米特罗普洛斯克里特大学摘要伊森·卡茨-巴塞特哥伦比亚大学乔治斯·斯马拉格达基斯TU Delft内容超级巨头将绝大多数互联网流量提供给最终用户。近年来，一些公司投入巨资在最终用户网络内部署服务和服务器随着几十个超级巨人和数千台服务器部署在网络内部，这些离网（即在超级巨人网络之外）部署改变了互联网的结构以前研究它们的努力依赖于专有数据或专门的每超级巨人测量技术，这些技术既不能扩展也不能概括，只能提供当今互联网上内容交付的有限视图。在本文中，我们开发了一个通用的和易于实现的方法学来衡量超巨星的网外扩张。我们的主要观察是，超级巨头越来越多地加密他们的流量，以保护他们的客户因此，我们可以分析端口443的互联网范围内的公共扫描，并检索TLS证书，以发现哪些IP地址托管Hypergiant证书，从而推断出托管相应Hypergiants的网外网络。我们的研究结果显示，从2013年到2021年，托管Hypergiant离线的网络数量增加了两倍，达到4.5k个网络。最大的超级巨头主导着这些部署，几乎所有这些网络都为谷歌、Netflix、Facebook或Akamai中的至少一个（越来越多的是两个或更多）托管网外服务。这四个超级巨人在网络中拥有网外网络，可以访问相当一部分最终用户。CCS概念• 网络→网络测量。关键词超级巨人、内容分发网络、TLS、服务器部署。ACM参考格式：Petros Gigis 、 Matt Calder 、 Lefteris Manassakis 、 George Nomikos 、Vasileios Kotronis、Xenofontas Dimitropoulos、Ethan Katz-Bassett和Georgios Smaragdakis。2021.《超巨星离网七年》在ACM SIGCOMM2021会议（SIGCOMM '21），2021年8月23日至27日，虚拟本作品采用知识共享署名国际4.0许可协议进行许可SIGCOMM©2021计算机协会。ACM ISBN 978-1-4503-8383-7/21/08。https://doi.org/10.1145/3452296.3472928图1：HypergiantHobbes Flow ， USA.ACM ， 纽 约 州 纽 约 市 ， 美 国 ， 18 页 。https://doi.org/10.1145/3452296.34729281引言互联网用户的绝大多数流量来自少数内容提供商、云提供商和内容交付网络，这些网络是出站流量较大的网络，包括Google、Netflix、Facebook和Akamai。 这些供应商，被称为超巨人（HG）的Labovitz等。al [64]，为全球数十亿用户提供内容。2019年，超过一半的互联网流量仅来自5个HG [32，85，104]，这是自2009年以来流量的重大整合，当时最大的150个AS贡献了一半的流量，而2007年则需要数千个AS [64]。面对不断增长的内容需求，为了提供高质量的用户体验，HGs在其基础设施上投入了大量他们构建了网络中心[54，96]，并推出纤维来构建其骨干[10，16，62]。他们在全球范围内的托管设施和互联网交换点（IXP）进行对等[48，90，113]。 它们还直接与眼球网络对等，绕过中转提供商以提高用户性能并降低成本[10，11，28，40，64，69，81]。例如，Google拥有超过7500个网络[11]（约1000个）。2020年），通过在100多个托管设施和150个IXP建立托管服务[50]。HG HG运营自己的网络和网络中心，服务器从自己的AS分配IP地址。一些HGs还在眼球或其他网络内安装服务器，为这些网络中的用户或他们的客户提供服务[53，69，79，81]。这些服务器被分配了托管网络的IP地址自2000年以来，Akamai已在全球数百个网络中部署了服务器[69，81]。我们将这些服务器称为离网服务器，因为它们在HG自己的网络之外，而不是HG在自己的网络上托管的网内服务器（见图2）。1）。最近，其他HGs也遵循了这一模式，例如，谷歌推出ISP AS最终用户Hypergiant AS服务器到服务器连接超巨型离网服务器AS级对等超巨型上网服务器517SIGCOMMGigis等人Google Global Cache [53] ， Netflix 有 Open Connect [79] ，Facebook[89]和阿里巴巴[7]运营自己的CDN。尽管HGs在提供互联网内容方面发挥着主导作用，但研究界缺乏通用和可扩展的方法来跟踪其增长和对互联网拓扑结构的影响为什么要在网外测量Hypergiant？能够跟踪其他网络，特别是眼球网络中的超级巨人的扩张，对互联网结构和互联网流量的建模有影响通过部署离线，HG的内容被本地化在托管网络内，跨网络边界的流量更少。这种观点挑战了研究社区对网络之间对等和交换流量的价值的心理模型，并可能影响网络中立性监管的范围和考虑。它也对网络性能产生影响，因为跨越网络边界是有代价的[28，44，69]。此外，在网络内操作服务器提高了Hypergiens的战略地位，因为它们能够控制其网络内的源服务器以及其他网络内的服务器，从而优化向最终用户的内容递送。展望未来，重要的是要了解负责最终用户消耗的90%流量的主要超级巨头是否已经采取措施在新兴网络中提供服务（例如，5G），其需要接近移动用户和性能保证。研究界对主要超级巨头的全球扩张战略缺乏很好的了解，也不知道有多少互联网人口可以在当地得到服务这些见解可以为其他领域的研究提供第8节根据我们的结果重新审视了其中的一些主题，主要超巨星的网外足迹挑战和以前的工作。大型HG的网外服务器（例如，Google、Netflix、Facebook、Akamai和许多其他公司）通常使用由托管网络（由ISP而不是HG）公布的IP地址，这使得无法使用传统技术（如检查BGP源）将服务器识别为属于HG。 已经使用了替代方法，但是它们要么需要访问分布式有利点，因此具有有限的覆盖范围，要么它们是针对特定的HG定制的，因此缺乏通用性并且对于HG可能做出的改变是脆弱的。第一类早期方法依赖于从许多位置发出DNS查询，因为HG可以通过将DNS查询解析到服务器的IP地址来将用户引导到特定服务器。这些方法要么使用分布式测量平台[88，102]，开放递归解析器（通常错误地）将响应来自任意主机的查询[55，105]，或者众包请求[3，74]。 研究YouTube基础设施的方法使用了不同网络中的5个有利位置[ 103 ]以及开放DNS解析器和PlanetLab的组合[ 2 ]。然而，这些技术都没有真正实现全球覆盖，随着HG扩大其足迹并使用任意类型，这变得越来越成为一个问题[23]，并且（ab）使用开放式解析器的研究也引起了伦理问题。第二类早期方法通过针对单个HG定制的基于DNS的技术来绕过对分布式有利位置的研究已经通过使用DNS扩展客户端子网（ECS）来模拟从世界各地发出DNS查询，其允许DNS查询包括客户端允许研究人员向HG发出似乎来自任意位置/前缀的查询[22，101]。然而，许多HG不支持ECS，即使是支持ECS的HG也可能只 回 复 来 自 白 名 单 解 析 器 的 ECS 查 询 [26] 。 此外， 即 使 是Google，早期基于ECS的映射的主题，现在也只响应域名的DNS查询，例如www.google.com，具有在线服务器的IP地址，因此基于ECS的映射工作不再发现Google的离线。 其他研究通过利用离线DNS记录的命名方案中的模式来映射Facebook [13- 15]和Netflix[17]离线，然后根据这些模式彻底尝试查询。这种方法是脆弱和繁琐的，因为主机名模式可能会改变，需要每个HG定制的模式，因此可能难以扩展，并且不是通用的，因为一些HG没有可利用的命名约定。我们的方法。我们提出了第一种方法，用于识别网外，这是一般的，跨超巨头的工作，并完成，实现全球覆盖的他们的网外足迹。此外，我们的方法适合使用现有的公共数据集，使我们能够将其应用于纵向研究，揭示网外部署的增长。我们的方法依赖于两个关键的观察结果。首先，Hyper-giant近年来，传输层安全（TLS）的使用急剧增加，因此今天的大多数互联网流量都是加密的[32]。加密技术在HGs中的采用率特别高，加密的Google流量百分比从2014年的50%增加到2020年的95%。TLS 证 书 验 证 服 务 器 中 运 行 的 服 务 的 身 份 ， 因 此 拥 有Hypergiant证书的服务器如果Hypergiant网络之外的服务器拥有该证书，则它是Hypergiant的离线服务器，我们将在本文后面验证这一观察结果。 由于TLS证书和消息交换是标准化的，因此IP地址空间的TLS扫描提供了一种识别离线的方法，该方法适用于任何Hypergiant（使用TLS），并且可以覆盖所有可公开寻址的服务器。其次，由于该方法依赖于标准TLS扫描，因此我们可以使用现有的证书语料库来执行历史和纵向分析。 这样的语料库可容易地用于商业和研究用途，例如， [2017- 07 - 17][2017 - 07 - 17][2017 -07 - 17][2017 - 07 - 17]TLS的广泛采用和可用的认证数据集相结合，为推断所有HG的网外足迹提供了机会，并大大提高了社区我们的贡献：我们开发了一种通用的方法来推断所有的HG的离网足迹通过分析扫描证书的语料库。 我们通过分析HTTP（S）报头语料库来增强我们的方法，以区分托管在第三方平台上的HG服务（例如，在AWS中运行的Netflixweb服务器）与在其自己的服务器上运行的HG服务（例如，Netflix Open Connect视频缓存）。通过将我们的方法应用于跨越七年（2013-2021）的证书语料库，我们发现托管HG离网安装的AS数量增加了两倍，达到4.5k··518七年在超巨型生命的离线SIGCOMM '21，2021年8月23日至27日2021年4月我们通过调查HG运营商验证我们的结果那些回答的人表示，我们正确地发现了89-95%托管其网外的AS。在托管任何HG离网的网络中，我们的分析显示，绝大多数托管至少四个最大的HG之一（Google，Netflix，Facebook和Akamai，就其离网的网络数量而言是四个最大的已经拥有至少一个HG的AS倾向于随着时间的推移拥有更多的HG。大多数离网都在中小型AS中，这并不奇怪，因为大多数AS通常都很小，但大型AS中也有不适当的份额。超级巨头在欧洲、亚洲和拉丁美洲迅速扩大了他们的网外足迹，最近一次是指数级增长。由 于 这 种 扩 展 ， 很 大 一 部 分 最 终 用 户 群 体 可 能 会 通 过Google、Netflix、Facebook和Akamai的离线部署获得服务。我们的分析揭示了HGs的不同策略 虽然许多超级巨头已经大幅扩张，但我们也观察到部署的萎缩，最明显的是Akamai。藏物 为了支持未来的研究，我们通过我们的项目网站向研究社区公开我们的软件和结果[45]：https://github.com/pgigis/sigcomm2021-hypergiants-offnets本文不涉及的内容：由于我们并不详细了解各个HG的业务策略、部署规划、对等安排以及性能和成本目标，因此我们的研究不是对不同HG的直接比较。具有较小网外占用空间的HG仍然可以服务更多用户或提供更好的性能。 不同HG离网足迹的性能评估超出了本工作的范围。2背景在HTTPS中，HTTP流量使用加密协议传输层安全性（TLS）进行加密，该协议使用交换和验证的公共证书来保护通信。公钥证书的标准格式是X.509[33]。证书包含几个字段[33，91]。 正如我们将在第4节中更详细地解释的那样，我们使用以下字段和属性来确定证书属于哪个组织和站点以及证书是否有效：受试者姓名。此字段通过多个（子）字段标识与证书相关联的实体 本文使用组织条目，命名与证书相关联的组织（例如，Google LLC）。dNS名称。 DNS名称dNSName扩展列出了此证书认证的域（例如，*. google.com，*. google.com.br，*. googlevideo.com，.- 是的- 是的）。服务器名称指示（SNI）。 SNI是TLS协议的扩展，它允许服务器为不同的主机名提供多个证书，所有证书都在一个IP地址下[35]。在TLS握手阶段，客户端提供它想要访问的主机名，服务器用相应的证书回复如果客户端不包含此扩展，服务器将使用其默认证书进行回复。有效期。 它使用NotBefore和NotAfter字段定义时间窗口，在该时间窗口内证书应被视为有效。 这些值取决于所有者的策略（例如，Netflix使用的是短命的[84]）。证书颁发机构。 它指示证书是证书颁发机构（CA）还是最终实体。证书链和验证。 为了反映从CA到证书所有者组织的分层信任链，通常将证书组织在链式列表中。证书链本质上是一个有序的证书列表，包含TLS证书和CA证书，使接收方能够验证发送方和所有涉及的CA都是可信的。 该链以最终实体（EE）证书开始，并且链中的每个证书由链中的下一个证书所标识的实体签名。位于EE证书和根证书之间的任何证书都称为中间证书。第一个中间证书是EE证书的签名者/颁发者。根CA证书是倒数第二个中间证书的签名者/颁发者，是终止链的CA签名证书（通常预先安装在客户端）。链中所有证书的签名都必须经过验证，直到根CA证书。3个挑战乍一看，扫描TLS证书似乎可以立即解决定位所有离网服务器的问 题 - 如 果 然 而 ， 一 些 挑 战 出 现 了 ， 主 要 是 由 于 不 同 的Hypergiens的复杂和异构的部署策略确定要查找哪些证书并不简单，因为不一定有一个证书可以明确识别每个Hypergiant。事实上，不同的Hypergiens部署了非常不同的证书管理策略（参见附录A.3）。此外，服务基础设施可以反映商业历史的遗迹。例如，LinkedIn和Github已经被微软收购，但可能使用不同的服务基础设施，无论是他们自己的还是第三方的。我们希望我们的技术足够通用，以适应这些策略，而不需要对每个Hypergiant进行重大调整或损害覆盖范围（发现HG的网外足迹）或准确性（对服务器所有权的在Hypergiant之外的服务器上存在Hypergiant证书许多部署模型可能导致其他服务器拥有该证书：一些超级巨头将其自己的基础设施用于一些服务，而将第三方CDN用于其他服务（例如， Twitter的图片来自Akamai和Verizon，但其他一些内容来自他们自己的基础设施，Netflix使用亚马逊的网络前端，但自己的CDN用于视频）。一些超巨星（例如， Apple和Microsoft [95]）拥有自己的基础设施，但也使用第三方CDN服务器来实现弹性，容量和/或扩展其足迹。这些服务器可以具有来自Hypergiant的证书（可能除了来自CDN的证书之外）并且提供Hypergiant的服务，即使它们不是Hypergiant的一部分······519SIGCOMMGigis等人超级巨人Hypergiant的证书可能存在于不为Hypergiant提供基础设施服务的服务器上。云提供商提供AWS Outposts，AzureStack和Google GKE等产品的内部版本，这些产品由云提供商管理，但不托管公共服务。然而，这些服务器可以在管理界面上托管用于云提供商的证书。类似地，HG证书可以存在于用于其业务的方面而不是内容服务的服务器上，诸如工资单。一些像CloudFlare这样的超级巨头向他们代理服务的客户颁发TLS证书，因此提供CloudFlare颁发的证书的客户服务器可能会被误认为是CloudFlare离线。对非Hypergiant IP地址空间的简单扫描可能无法发现所有的网外。 对于通过任播提供内容的Hypergiants [23]，网内和网外服务器的面向用户的IP地址是相同的，这使得区分彼此变得复杂，并且对该接口的查询将基于查询的源到达特定的任播实例。因此，简单地从一个或几个位置扫描IP地址空间不足以发现任播IP地址的每个实例[30]，可能会留下一些HG足迹。4方法我们开发了一种使用TLS证书扫描作为构建块的方法，并使用我们开发的技术来解决第3节中提到的挑战。首先，我们通过扫描网络来学习Hypergiant的TLS指纹（第4.2节）。第二，我们在离线IP地址的扫描中搜索TLS指纹，以识别候选地址（第4.3节）。第三，我们通过再次扫描网络来学习Hypergiant的HTTP（S）头指纹（第4.4节）。第四，我们通过扫描HTTP（S）头指纹来确认网外候选者（第4.5节）。 我们的方法解决了大多数挑战，但我们在第7节中讨论了它们仍然存在的局限性。4.1验证证书在整个过程中，我们只使用有效证书。如先前研究[24，29]中所建议的，我们根据形成WebPKI（从公共CA数据库[77]中提取）的可信根证书和中间证书列表验证每个证书链的中间/根证书。根据NotAfter和NotBefore字段，我们丢弃（在收集证书时）过期的任何证书我们还丢弃了所有自签名的最终实体证书，因为它们可以由任何人颁发以模仿有效的HG证书。在我们的研究期间，超过三分之一的主机返回了我们排除的无效证书。4.2学习Hypergiant TLS指纹Hypergiant可能没有一个定义TLS证书，例如，如果它使用不同的证书运行不同的服务， 那么 我们 首先 学习 识别 特定Hypergiant的指纹，以便稍后将指纹应用于Internet范围的扫描。该步骤的输入是超巨星的名称（例如，“Hypergiant（第4.6提供了我们在本文中使用的扫描的详细信息直觉是，在这个IP空间中具有与Hypergiant名称匹配的终端实体（EE）证书的服务器极有可能是Hypergiant的网内服务器，因此为Hypergiant的服务基础设施提供了可靠的指纹。我们对EE证书感兴趣，因为它们包含服务器所有者的信息，而中间/根证书可以包含第三方组织信息。根据在Hypergiant地址空间中找到的EE证书任何组织都有可能获得域验证（DV）[1]证书，例如，在主题名称的组织字段中使用“google“，因为该字段不是有效的或权威的，因此组织本身不是可靠的指纹。 为了补充它，我们从网络服务器的最终实体证书中提取DNS名 称 列表（ TLS dNSName 字 段 ， 已 验 证 ） ， 创 建 一 组 由Hypergiant提供服务的DNS名称。4.3利用指纹识别网外候选人然后，我们使用指纹-特别是DNS名称集-在Hypergiant外部的IP地址上搜索Hypergiant的证书的存在，因为这些是其候选的网外。我们再次搜索超巨星的名字，例如，“google“，在主题名称的TLS组织字段中。 对于每个匹配的证书，我们检查证书的dNSNames字段中的所有DNS名称是否都在Hypergiant的DNS名称集中，这些DNS名称来自我们在上一步中找到的网上证书。如果它们是，则提供TLS证书的IP地址是离线的候选者通过要求证书中的所有DNS名称都出现在网上证书中，我们过滤掉了HG是证书提供商的情况（例如，Cloudflare）以及Hypergiant与另一个组织共享证书的情况。4.4学习Hypergiant HTTP（ S）指 纹 我 们 识 别Hypergiant HTTP（S）报头中的指纹，作为排除具有证书的网外候选者的基础。Hypergiant，但实际上不在其离线服务器之列（§3）。 大型内容提供商和CDN经常使用HTTP响应报头进行调试，我们检查这些报头以创建每个Hypergiant指纹，使用2020年9月Rapid7HTTP和HTTPS扫描中的在线服务器的响应。我们过滤掉常见的标准标头（例如，缓存控制和内容长度）。 由于一个特定的Hypergiant的服务器可能会共享调试头，我们确定了50个最常见的头名称-值对和每个Hypergiant的网络服务器最常见的头名称。接下来，我们进行了手动分类和验证，以找到识别HypergiantWeb服务器的头指纹超巨星的数量很少，因此我们发现，基于个案的检查适合我们的工作。我们离开··超巨星离网七年SIGCOMM520Hypergiant头名称标头值记录Akamai服务器Akamai GHost有[5]Cloudflare谷歌FacebookCF请求ID服务器X-FB-X-FBgws*有[31]已披露[49，59]有[39]表1：用于标识HG服务器的报头的示例。空标头值表示仅使用标头名称进行匹配。以 * 结尾的前缀表示前缀匹配。这一步的自动化为今后的工作。对于最常出现的环标头，HG特定标头很容易从唯一标头名称或包含超巨星缩写名称的值中识别。在近80%的情况下，我们发现公共文档或披露证实了HGs使用这些表1显示了几个示例，附录A.5提供了完整的列表。我们还通过对内容的独立测试（例如，google.com）。一个有趣的案例是Netflix，因为我们发现它的一小部分服务器使用默认的ngnix头进行响应。 对于我们的分析，我们将具有Netflix证书和默认ngnix HTTP（S）头的服务器视为Netflix离线。4.5使用HTTP（S）我们将这些HTTP（S）头指纹应用于第4.3节中的网外候选人，并将任何匹配Hypergiant指纹的人分类为网外。 要将IP分配给AS，我们使用附录A.1中描述的标准IP到AS映射技术。 我们还对HGs的网内和网外进行了注释，如附录A.2所述。4.6数据集证书数据集。Rapid7在端口443上收集 IPv4范围扫描中观察到的X.509证书[67]。我们使用的数据集从10月开始每三个月2013年4月2021年，其中包括127，812，006个唯一证书。我们从11月开始使用Censys [36]的端口443扫描进行补充。2019年4月2021年我们排除了无法转换为X.509格式的证书以及缺少关键信息的证书。HTTP（S）头。 我们使用的语料库可用的HTTP（S）头从Rapid7从10月。2013年4月2021年超巨星列表 我们使用先前发布的调查[18，19，32，64，112]编制了一份HGs列表，然后选择23个在其网站上声称拥有CDN的HGs，并且我们能够识别具有匹配组织的证书。检查的HG：Akamai、阿里巴巴、亚马逊、苹果、Bamtech、Highwinds、CDN 77、Cachefly、Cdnetworks、Chinacache、Cloudflare、迪士尼、Facebook、Fastly、谷歌、Hulu、Incapsula、Limelight、微软、Netflix、Twit-ter、Verizon和雅虎。5验证我们发现我们的扫描和测量技术是准确的，然后根据超巨星的信息和早期方法的结果验证我们的结果，发现我们的结果是可信的。扫描语料库的比较我们论文中的大多数结果都依赖于Rapid7扫描，因此我们首先评估了它与Censys和我们进行的主动扫描（11月11日）相比的完整性。21-25，2019）的整个公共可路由的非bogon IPv4地址空间的SSL/TLS证书端口443。 我们使用修改后的证书工具[97]来与服务器执行TLS握手以获取它们的证书。 我们的扫描获取了13，156，080个唯一的最终实体证书。表2比较了2019年11月的扫描和Rapid7和Censys扫描Rapid7和Censys中具有证书的IP地址数量非常相似。然而，我们的认证扫描发现了大约20%的地址，我们将其归因于两个原因。首先，Rapid7和Censys都必须对投诉做出回应，并从扫描中删除IP地址[12，29，110]。由于两次扫描都已运行多年，随着时间的推移，更多的地址空间被排除在外造成这种差异的第二个原因是，我们的扫描几乎花了四天的时间来执行，这可能比其他更快的扫描触发更少的速率限制。然而，当我们将注意力转向托管至少一个HG的AS总数时（第6列），所有三个数据集的数字非常相似，因为它们是最后四列中报告的足迹最大的四个超级巨头（Google，Netflix，Facebook和Akamai）。另一个观察结果是，每个HG的IP地址的数量与相应HG的网外的大小或分布无关，因为每个HG在如何将IP分配给服务器方面具有不同的策略[ 42 ]）。我们已经确认，一些HG只有几个前端IP地址用于多个服务器，而另一些HG则有多个IP地址用于一个服务器。例如，在我们的主动扫描（11月。2019年），我们从 1 ， 708 个离网AS 的33 ，769 个IP 地址中收集了Facebook证书。在同一活动中，我们从更多的IP地址（105，686）收集了Akamai证书，尽管Akamai的离网足迹较小，有1，194个离网AS。因此，在本文的其余部分，我们将重点关注每个Hypergiant的离线AS足迹。伦理考量。在我们的扫描中，我们仍然是“好互联网公民”，遵循最佳实践[37]，以避免触发任何形式的警报。我们维护一个黑名单，并使用适当的rDNS名称，网站和滥用联系人的客户端因此，这项工作不会引起任何道德问题。主动测量验证。 我们提供了额外的验证我们的推断使用主动测量。 为了实现这一点，我们使用ZGrab2 [115]工具，它提供了快速捕获HTTP（S）横幅，包括HTTP头和TLS证书验证。 我们提供了一个（IP地址，域）对的输入列表，ZGrab2在对默认文档执行GET请求时正确地设置了HTTP主机头和TLS SNI字段。在这个分析中，我们断言，如果我们正确地推断出一个服务器是 一个特 定的 Hypergiant 的 离网 服务 器， 它 不应 该服 务 于Hypergiant没有托管的域的请求（即， TLS验证应该失败）。 为了测试这一点，对于我们推断为特定Hypergiant的网外IP地址，我们随机选择10个其他Hypergiant，并为每个Hypergiant扫描请求其他Hypergiant服务的50个最受欢迎域名之一的IP地址。令人惊讶的是，我们发现，只有89.7%的推断出的网外没有验证随机选择的域。在10.3%正确验证的请求中，我们推断97%属于Akamai，并且请求域（LinkedIn，KDDI，Disney）也由第三方CDN（如Akamai）提供服务这一结果凸显了理解内容交付的挑战SIGCOMMP. Gigis等人521扫描（缩写）日期#IPv4 IP有证书有证书的AS数量AS唯一数量任何# ASes w/ Hypergiant Certificates谷歌Netflix FacebookAkamaiRapid7（R7）Nov. 2019年10月18日，35,009,71457,769843,7883,1371,7601,7371,235Censys（CS）Nov. 2019年10月19日34,235,59058,1832113,9743,3551,6891,7461,248认证（AC）2019年11月21-25日41,357,38859,1785193,8023,1491,7151,7621,236表2：2019年11月我们研究中的三个证书扫描语料库的统计数据生态系统：大型内容提供商可以选择自托管和外部CDN的组合，以实现冗余和额外的容量（§3）。然而，Akamai是我们分析中的例外，因为它不创建自己的内容或拥有自己的用户，其平台交付其他公司的内容，非常像交付内容的“云提供商”。在这个分析中，我们断言HG地址空间之外的服务器不应该服务于HG域，除非我们推断它们是离网的。 使用2020年11月的Rapid7和Censys数据集，我们从5700万个IP地址中随机选择了一个25%的样本，这些IP地址具有响应式Web服务器，我们没有推断出是Hypergiant在网上。然后，对于每个选定的IP地址，我们选择10个随机HG域，如前面的分析所述从我们的随机样本中，我们发现844个AS中有0.1%（17，029）的IP地址具有有效的TLS响应。 其中，98%是我们正确推断为HG离网的服务器。我们相信剩下的2%是CDN托管网站的客户来源。来自Hypergiens的验证 我们对HG运营商进行了调查，采用了与早期ISP映射工作类似的方法[98]。调查问题见附录A.4。四个汞团体答复了我们的验证请求，其中包括四个最大的汞团体。所有四个人都同意，对网外足迹的估计是非常好的。一位HG运营商表示，我们识别为托管HG网外的AS中有6%不在HG的列表中，HG列表中有11%没有被我们的技术发现（同时也表明HG的列表可能不是100%正确）。对于其他三个HG，我们将HG足迹低估了5%（一个HG）或约10%（两个HG）。 由于IP到AS映射中的错误，由于AS选择退出TLS扫描（例如，表2显示了不同的扫描揭示了不同的覆盖率），或者是因为我们测量和验证之间的波动。我们错过的网外是不同类型网络的混合 我们的结果与Akamai在研究期间的公开报告一致[4]。与之前的结果比较 我们的技术适用于实验数据集，这使得我们的结果能够与使用不同方法的先前研究进行比较。Google：我们将我们的结果与2016年4月发布的发现Google离线方法的最新结果进行了比较[22]，该方法报告了1445个托管Google离线的AS。在1445个AS中，我们的方法识别了1421个（98%），同时还识别了另外283个（其中68个是在2016年4月之前识别的）。Facebook：据我们所知，之前唯一报告FacebookCDN数字的工作属于一个参与2018年3月黑客攻击的团队[ 13 ]，并于2018年8月，2019年11月[ 14 ]和2021年4月[ 15 ]发布更新结果。该团队通过猜测，表3：根据Rapid7数据集（2013年10月至2021年4月）检查的HG列表，按托管HG网外的最大AS数量排序（通过证书和标题验证）。（* 有关Cloudflare的讨论，请参见第6.1节的最后一段基于Facebook命名约定和全球机场代码的网外DNS名称。我们的技术在该团队2018年的数据发现了1201个AS中的1153个2019年数据，2021年数据中2187个AS中的2068个（95%） 我们在两个数据集中应用了相同的IP到AS映射。Netflix：之前的一项研究[18]报告称，2017年5月15日，743个AS托管了Netflix Open Connect服务器。2017年4月，我们报告了769起AS。6HGS&的离网足迹增长本节讨论HGS离网部署的足迹和增长。我们通过网络类型来描述他们的增长，地区和互联网用户的覆盖面我们还评论了网络提供商6.1超巨星统计我们首先考虑Rapid7证书数据集。在图2中，我们显示了在我们的研究期间，从10月10日起，拥有证书的IP地址的数量2013年4月2021年 我们直接从原始Rapid7数据报告该数字，即，在验证证书之前。然后，我们应用§4.1-§4.3中的方法来推断使用与我们研究的任何HG相关联的证书的IP地址。 在图2中（参考右侧y轴），我们绘制了我们推断的服务于任何HG的IP地址的百分比，这些HG托管在每个HG中（虚线）或非HG AS中（虚线）。在2021年初，在Rapid7中看到的具有有效证书的IP地址中，只有约3.8%与我们研究的任何HG相关联，无论是托管在HG的AS中表3报告了在我们的研究期开始时（10月20日）托管每个HG离网足迹的AS数量2013年）和研究期结束时（4月。2021）后，验证与标题（§4.5）。超级巨人名称HG离网2013/10(only证书）Max[快照]2021/04(only证书）1.谷歌1044（1105）3810[2021/04]小行星3810（3835）2.Facebook0（8）2214[2021/04]二二一四（二九）3.Netflix四十七（一百四十三）2115[2021/04]二一一五（二二八八）4.Akamai978（1013）1463[2018/04]1094（1107）5.阿里巴巴0（0）184[2018/01]一百三十六（三百零一）6.Cloudflare0（2）110*[2021/01]110*（137）7.亚马逊0（147）112[2017/07]六十二（二百一十八）超巨星离网七年SIGCOMM522Rapid7中的IP数量HG AS非HG AS中的IP403.02.5302.0201.51.0100.500.04000350030002500200015001000500图2：原始Rapid7数据集文件中托管TLS证书的IP地址（百万）（左侧y轴）。其中，托管HG证书的%，按IP地址是否属于HG AS（右y轴）细分表的中间列给出了观察到的HG的离网托管AS的最大数量以及最大部署发生时的时间戳。 该表根据HG的最大AS足迹对HG进行排名 。 对 于 一 半 的 HGs （ 微 软 ， Hulu ， 迪 斯 尼 ， 雅 虎 ！ ，Chinacache，Fastly，Cachefly，Incapsula，CDN77，Bamtech和Highwinds），我们的方法推断在我们的研究期间没有离线足迹，因此该表排除了它们。人道主义团体的部署战略各不相同。 在第5节中，我们解释了IP地址的绝对数量是一个很好的比较指标。对于某些HG，托管在非HGAS中的具有证书的IP地址（前4个HG，见表3）的百分比非常高，例如，谷歌，Netflix，Facebook，和其他非常低，例如，亚马逊然而，IP地址的总数仅占具有证书的IP地址的数据集的一小部分。我们还注意到有两个不同的HG组。首先，有四个最大的HGs，即Google，Netflix，Facebook和Akamai，它们在2021年初已经在1,000多个AS中进行了脱网。对于某些HG，例如，Google和Akamai，服务器安装的离网足迹的大小（在使用标头进行验证之后）非常接近服务存在的离网足迹的大小（仅通过证书推断;请参见括号中的值在一些其他的HG中，例如，阿里巴巴则不是这样，因为他们依靠其他HGs或数据中心提供商运营的服务器来运行服务。CloudFlare提出了一个有趣的案例，因为我们的手动调查显示它没有离线足迹，但是，由于它在其他网络中运行的客户端中发布和安装证书（并支持其DNS服务1.1.1.1），Cloudflare被错误地识别为离线。6.2纵向生长图 3 根 据 我 们 对 Rapid7 证 书 数 据 集 的 分 析 绘 制 了 前 4 大 HG（Google、Netflix、Facebook和Akamai）的网外足迹增长（使用HTTP（S）标头验证除Akamai外，这些HG的网外足迹正在大幅增长。自2016年夏天推出自己的CDN以来，Facebook表现出了快速增长[61]。Netflix的情况是最复杂的，需要人工调查。尽管Netflix的离线足迹在2015年后不断增长（我们推测这可能是由于与0图3：前四大温室气体的网外足迹随时间的增长情况互联网服务提供商[72]和推出开放连接的战略决策），我们观察到2017年4月之后有很大一部分IP地址响应过期证书。这在图3中可见（实线）。当我们忽略此证书的到期日期时，我们可以恢复Netflix的活动，如Netflix虚线所示。10月，2019年，这些IP地址的默认证书更改回有效证书。 我们还通过使用PTR记录来验证这一点，该记录当时包含有关Netflix足迹的信息。我们还观察到，在2017年4月之前和2019年7月之后，为Netflix提供证书的IP地址中有26.8%停止响应端口443上的HTTPS请求。为了进一步研究，我们下载并研究了Rapid7对HTTPS GET（端口443）和HTTP GET（端口80）请求的响应。 我们发现这些IP地址在此期间实际上是活动的，但在HTTP而不是HTTP
我的内容管理
展开
