json-schema.org 在 7 天内收到 5000 多万个请求

我承认，7 天并不是进行分析的理想时间长度，但这是我们目前拥有的数据。之前，我们只有基本的网站分析，但这只是故事的一部分。我们在 GitHub Pages 上运行网站，并使用 Cloudflare 作为前端，后者提供 7 天的分析数据，关键是包括直接访问流量。

JSON Schema 网站托管官方元模式。如果你不确定这意味着什么，元模式就是 JSON Schema 的 JSON Schema。为什么这很有趣？好吧，我们托管了元模式的所有历史版本，而不仅仅是最新的版本。虽然我们不希望代码定期发送请求来下载元模式，但请求数量强烈表明它们确实在这样做。

为什么现在？除了在版本化 URL 中提供元模式之外，该网站过去一直，并且将继续，在 /schema 提供最新的元模式。我们目前建议人们不要访问这个 URL！我们设置了带有警告消息的延迟重定向，但实际上，我们预计大多数访问将通过代码进行，而不是在浏览器中进行。（这意味着事情很可能出错了。稍后会详细介绍。）

也许现在我们可以删除对该 URL 的托管？由于本文范围之外的原因，使用它实际上不是一个好主意，并且可能会产生意想不到的结果。如前所述，网络分析不会告诉我们浏览器之外发生了什么，所以我们需要其他东西……我们已经在使用 Cloudflare，所以决定申请开源免费专业版计划……在我们等待的同时，成本并不高，所以我决定现在看看数据。

本文中的数据是 2023-07-21 采集的七天快照。（在文章最后，我将分享来自该快照的一张图片，以及来自 2023-07-31 的一张用于比较的图片。）

• 警告 1：客户端不应该在其生产代码中向元模式发送请求。在 CI/CD 系统中使用可能是合适的，但这也很不可能。相反，客户端应该存储一个本地缓存副本。任何明显的请求数量都强烈表明缓存很少或根本没有缓存。

• 警告 2：流量分析数据基于对总流量的样本。每个统计数据使用不同的百分比。从 0.16% 到 16.67% 不等。我想有很多数字需要计算，很多日志需要保存才能进行真正的分析。你可以要求将日志传输到第三方……但你需要企业版计划。无论如何，这些见解仍然很有趣。

• 警告 3：每个数据类别中的“顶部”在 UI 中限制为 15 个项目。我认为我们可以使用他们的 API 来访问更多数据，但这是我在 5 分钟内无法弄清楚的事情，所以让我们使用我们今天拥有的数据。

哦，对了，我们仅限于最近七天的数据。

我们在这里分享什么？

最好从一些引人注目的数字开始，然后深入了解究竟访问了什么以及为什么这很有趣，最后是一些有趣的发现。

大数字

5192 万个请求

211.47 GB 的数据传输

105 万次页面浏览

101 万次访问

所有元模式！

大约 5100 万个请求来自未声明浏览器、客户端或机器人名称的来源。我们看到 Chrome 和 Firefox 排名第一，而在更低的位置，我们看到了 CURL 和各种索引机器人。

就访问的路径（因此是元模式）而言，我发现结果很有趣且有见地。

排名第一的结果，为 1182 万次，是 /draft-07/schema。这表明 draft-07 JSON Schema 是最常传递给行为不当的实现的版本。（大多数行为良好的实现不会去下载元模式，因为它们已经拥有它！这包括最流行的实现！）

Draft-04 直到列表中的第 4 位才出现。排名第 2 和第 3 的是 Draft 2019-09，但并非像我们预期的那样……那里的文件，links 和 hyper-schema 是用于超链接模式的，而不是 JSON Schema 的主要验证用例。

有人正在访问超链接模式？

请记住，我们之前除了核心产品之外还发布了 JSON 超链接模式。超链接模式是一种超媒体规范。具体来说，与 API 相关，超媒体作为应用程序状态的引擎 (HATEOAS)。（对于感兴趣的人，进一步阅读：理查森成熟度模型）。我们决定暂停 JSON 超链接模式，因为我们没有资源来支持规范的进展，大约与完成 draft 2020-12 的时间相同。（我们可以将 hyper-schema 和 links 之间的差异归因于使用的样本。可以合理地假设两者都是按顺序访问的。）

这些对超链接模式元模式的请求来自哪里？虽然物理位置并不有趣，但我们可以查看提供的用户代理。排名前两位，涵盖了 750 万个请求，并没有真正帮助……python-requests。最多，我们可以看到版本 2.27 和 2.28 的使用量大致相等。之后，我们下降到 635k 个请求，来自一个标识为 neptune-client 的东西。好奇心被激发了！

他们称之为“实验跟踪工具和模型注册表”。这与机器学习 (ML) 操作 (MLOps) 相关，专为数据科学家和 ML 工程师而建。我对 ML 知之甚少，所以我请我的同事分享他对 Neptune.ai 服务的看法，他对这个领域了解得更多……

“当你在机器学习模型上调整某些东西时，这款软件让你运行一些计算，从而告诉你你的更改对模型的优劣影响有多大” - Julian Berman

嗯，这已经足够简单了，谢谢 Julian!

我想我们应该联系他们，了解他们对超链接模式的用例!

好的，那谁还在访问 /schema？

访问使用此非版本化 URI 发布的最新元模式是不建议的。大约四年前，我们开始让人们意识到这一点，如果你使用的是浏览器，你会看到 带有重定向的提示消息。

对该 URL 的绝大多数请求都没有引用来源，所以这不太有帮助。转向用户代理，我们看到绝大多数请求的用户代理是 ""。叹气。没错！空白！这是不好的做法，我对是什么导致这种情况有所怀疑。

当你查看相邻数据时，看到剩下的前 15 个用户代理中有一半以上，很明显大多数请求来自 IDE 和代码编辑器。我们看到了 InteliJ IDEA、WebStorm 以及每个的多个版本。但是，我们没有看到 VSCode。

果然，就我们所知，VSCode 没有提供用户代理。至少在进行与 JSON Schema 相关的请求时是这样。虽然我们喜欢 VSCode 以及内置的 JSON Schema 支持，但我们希望有一些事情能做得更好，而这是一个例子。

Visual Studio 提供了一个用户代理（我们将在稍后讨论其分析），但鉴于 Visual Studio Code 没有，我们无法区分它发出的请求和其他没有提供用户代理的请求。（我们通常会看到提供了一个用户代理。）

这里需要注意的是，由于将网站托管在 GitHub 上的限制，用于 /schema 的重定向是基于 HTML 的标头重定向，而不是使用您可能预期的 HTTP 302 状态码。这意味着，实际上，不太可能有任何进行这些请求的代码真正得到它们想要的东西。（重定向技术几乎完全由浏览器遵循，而不是像 CURL 这样的开发人员工具，因为它是非标准的）。当然，如果我们在 Visual Studio Code 中尝试这样做，我们会看到一个“无法解析内容”错误。它期望响应中的 JSON，但网站没有这样做。

谁在访问 draft-04？

过去 7 天，对 draft-04 元模式的总请求次数为 721 万次。

物理位置显示了一个惊喜，秘鲁领先于英国和俄罗斯。接下来是美国，占这 721 万次请求中的 573 万次。

这次，用户代理数据更有用。我们没有看到空代理字符串，直到插槽编号 10，仅占 7.8 万次请求。在顶部，我们看到 Java！我在这里做一个有根据的猜测，并说这与弗朗西斯·加利格 (Francis Galiegue) 的 Java 实现有关。他们是 JSON Schema 早期核心团队成员之一，并创建了一个 Java 实现，该实现自 draft-04 以来就没有升级支持。

由此，我们可以推测，生产中使用 JSON Schema 的许多 Java 服务在 AWS 上没有理由从过时的 JSON Schema 实现中迁移。也许他们正在使用更现代的 JSON Schema 版本本身，而实现正在错误地处理它们……但在没有测试的情况下，我目前只是在做一些有根据的猜测。

Java 占据了最大的份额，411 万次，接下来是 Mojolicious（一个 Perl 框架），然后是 Visual Studio，有 52.6 万次。现在这更有趣了。我还在这里注意到，Visual Studio 提供了一个更有用的用户代理字符串。看

Visual Studio/17.6 (JSON Editor; ASP.NET and Web Tools/17.6.326.62524)

如果我们考虑多个版本的 Visual Studio，这里很容易超过 100 万。它们占据了前 15 名中的 8 个。我们已经与正在开发 Visual Studio 的人有一些沟通渠道。对于 Visual Studio Code 来说，情况并非如此。我希望我们将来能够解决这个问题。

最新三个 JSON Schema 版本？

让我们看看访问带有 draft-07、2019-09 和 2020-12 的路径。

对于 draft-07，路径 /draft-07/schema 被访问了 1166 万次。下一个最大的是 1.8k，是发行说明……就像网站上的 HTML 文件一样（哦，看，那里也有个网站！）。

对于 2019-09，我们看到 2087 万次请求。为什么会有跳跃？links 和 hyper-schema 都获得了超过 800 万次请求。如前所述，很难将这些请求归因于任何原因，但让我们看看在排除它们后会发生什么。现在我们看到 405 万……还不错！尽管如此，我们必须考虑，使用 2019-09，我们将元模式拆分成了多个文件，特别是各个词汇表。我们看到每个词汇表都略高于 50 万次请求，通用元模式和核心略多。

过滤掉 hyper-schema URL 后，2019-09 的用户代理主要是 Java。

那么我们期望 2020-12 看到什么？我也很好奇。

我们看到 742 万次，其中没有与 Hyper Schema 有关。

其中，153 万次到 .../meta/core，其次是验证词汇表元模式，只有 57.784 万次。如果这是准确的，那就有点令人担忧。我们希望 /draft/2020-12/schema 是被访问次数最多的路径，但它直到第 8 位才出现，有 47.246 万次。

流量模式非常尖峰，并带有重复的时间模式。这可能是某个正在运行的 cron 作业。如果我们排除最顶级的 IP 地址，我们会丢失所有尖峰，这强烈表明这种突发流量来自某些 Amazon 控制的 AWS 服务器。

我们将联系 AWS，看看是否可以获得更多具体细节。这可能不是 DDoS 攻击，但它是一个表明出了问题的信号。

ASN、OSI，什么？

前两个 ASN 来源都由 Amazon 控制，总计超过 3900 万次请求。

对于那些不是网络工程师的人来说，ASN 是一个 自治系统编号，用于在互联网上路由数据包，确保它们走最快的路线。如果你回忆起学习 OSI 模型的时候（是的，我都不太记得了），也就是 开放系统互联模型，这些 ASN 作为传输层的一部分使用。

重点是，我们可以不查找 IP 地址所有者，就知道我们几乎 80% 的流量来自 AWS！

国家/地区

鉴于来自 AWS 的流量有多大，不足为奇的是，其中约 4300 万次请求来自美国和爱尔兰。在这之后，芬兰、印度和荷兰组成了 100 万俱乐部。紧随其后的是德国和俄罗斯，然后是亚洲的几个国家，所有国家都超过了 20 万。

来源

在这 5192 万次请求中，惊人的 5112 万次没有声明引用。排名前三的是 json-schema.org、Google，然后非常有趣的是 localhost！

奇怪的是，1.54k 次请求声明一个来自 Uber 结算的已失效的推荐来源，略高于 Duck Duck Go。

这一切意味着什么？

元模式的访问可能与使用百分比不相关，但至少在一定程度上是使用情况的指标。查看这些数据意味着我们正在联系 AWS，看看我们是否可以获得任何详细信息。这促使我们联系 IDE 制造商，尽管这样做已经在我们的清单上了。我们扩展了已知平台用户。人们使用适当的代理字符串真是太好了。

鉴于我们只能访问 7 天的历史记录，因此我们无法在更长的时间内了解太多信息。虽然传统的分析是有用的，我们确实使用它们，但它们无法告诉我们直接访问 JSON 文件的情况。

虽然其中一些数字很有趣，但我还没有确信它们在今天能提供多少实用价值。

以下是 2023 年 7 月 21 日和 2023 年 7 月 31 日路径的并排流量。

对本文有任何想法、评论、反馈吗？您对为什么我们会看到这些数据有任何想法吗？您对进一步研究或分析有任何想法吗？请进一步讨论：https://github.com/orgs/json-schema-org/discussions/480

图片由 Isaac Smith 在 Unsplash 上提供