在 json-schema.org 上 7 天內超過 5 千萬次的請求

我承認，7 天並不是一個理想的分析時間長度，但這是我們目前所擁有的。先前，我們只有基本的網站分析，但那僅僅描述了整個故事的一小部分。我們在 GitHub Pages 上執行網站，前端使用 Cloudflare，這提供了 7 天的分析，關鍵的是，包括直接存取流量。

JSON Schema 網站託管了官方的 meta-schema。如果您不確定那是什麼意思，meta-schema 是 JSON Schema 的 JSON Schema。為什麼這很有趣？好吧，我們託管了 meta-schema 的所有歷史版本，而不僅僅是最新的版本。雖然我們不期望程式碼定期發出請求來下載 meta-schema，但請求的數量強烈表明它們確實這樣做。

為什麼現在？除了在帶版本號的 URL 上提供 meta-schema 之外，該網站一直以來都在 /schema 提供最新的 meta-schema。我們目前建議人們不要存取這個！我們加入了一個延遲重新導向，並帶有警告人們避免使用的訊息，但實際上，我們預期大多數存取將透過程式碼進行，而不是在瀏覽器中。（這意味著事情可能壞了。稍後會詳細說明。）

也許現在我們可以移除託管該 URL 了嗎？由於超出本文範圍的原因，使用它真的不是一個好主意，並且可能會產生您不期望的結果。如前所述，網站分析無法告訴我們在瀏覽器之外發生的事情，因此我們需要其他東西… 我們已經在使用 Cloudflare，因此決定申請開源免費的專業級方案… 在我們等待的同時，成本並不大，所以我決定我們現在應該看看數據。

本文中的數據是 2023-07-21 拍攝的七天快照。（在文章末尾，我將分享這個快照中的圖片，以及 2023-07-31 的圖片以供比較。）

• 注意事項 1：客戶端不應在生產程式碼中發出對 meta-schema 的請求。它可能適合作為 CI/CD 系統的一部分，但這也不太可能。相反，客戶端應儲存本機快取副本。任何顯著的請求數量都強烈暗示很少或沒有快取。

• 注意事項 2：流量分析數據是基於總流量的樣本。每個統計數據都使用不同的百分比。從 0.16% 到 16.67% 不等。我猜想，要進行真正的分析，需要處理大量的數字和保留日誌。您可以要求將日誌傳送到第三方… 但您需要企業級方案。儘管如此，這些見解仍然非常有趣。

• 注意事項 3：UI 中每個資料類別的「頂端」限制為 15 個項目。我認為我們可以使用他們的 API 來存取額外的數據，但這是我在 5 分鐘內無法弄清楚的事情，所以讓我們使用我們今天擁有的。

哦，是的，我們僅限於最後七天的數據。

我們在這裡分享什麼？

最好從一些引人注目的數字開始，然後深入了解究竟存取了什麼以及為什麼這很有趣，最後只是一些有趣的發現。

大數字

5192 萬個請求

211.47GB 的數據傳輸

105 萬個頁面瀏覽量

101 萬次訪問

所有 meta-schema！

大約 5100 萬個請求來自未宣告瀏覽器、客戶端或機器人名稱的某個東西。我們看到 Chrome 和 Firefox 佔據了領先地位，而在較低的排名中，我們看到 CURL 和各種索引機器人。

就存取的路徑而言，因此也就是存取了哪些 meta-schema，我發現結果很有趣且具有洞察力。

排名第一的結果是 1182 萬個，是 /draft-07/schema。這表明 draft-07 JSON Schema 是傳遞給行為不當的實作中最受歡迎的版本。（大多數行為良好的實作不會去下載 meta-schema，因為它們已經有了！這包括最受歡迎的實作！）

Draft-04 在列表中排名第四才出現。排名第二和第三的是 Draft 2019-09，但不是我們可能預期的那樣… 這裡的檔案 links 和 hyper-schema 是用於 Hyper Schema，而不是 JSON Schema 的主要驗證用例。

有人正在存取 Hyper Schema？

請記住，我們之前除了核心產品外，還發布了 JSON Hyper Schema。Hyper Schema 是一種超媒體規範。具體而言，在與 API 相關的情況下，超媒體即應用程式狀態引擎（HATEOAS）。（對於那些感興趣的人，更多閱讀資料：Richardson 成熟度模型）。我們決定暫停 JSON Hyper Schema，因為我們沒有資源來支持該規範的進展，大約在完成 draft 2020-12 的同時。（我們可以將 hyper-schema 和 links 之間的差異歸因於所使用的樣本。可以合理地假設兩者都是按順序存取的。）

這些對 Hyper Schema meta-schema 的請求來自哪裡？雖然物理位置並不有趣，但我們可以查看提供的使用者代理。前兩個覆蓋了 750 萬個請求，並沒有真正幫助… python-requests。最多，我們可以看到版本 2.27 和 2.28 的使用率大致相等。之後，我們從一個識別為 neptune-client 的東西跳到 63.5 萬個請求。好奇心被激發！

他們稱之為「實驗追蹤工具和模型註冊表」。這與機器學習（ML）Ops（MLOps）有關，專為數據科學家和 ML 工程師而建。我對 ML 了解甚少，所以我請我的同事分享他對 Neptune.ai 服務的看法，他對這個領域了解得多得多……

「一款軟體，當您調整機器學習模型的某些內容時，它會讓您執行一些計算，告訴您您的變更如何影響模型的優劣」- Julian Berman

嗯，對我來說已經夠簡單了！謝謝 Julian！

我想我們應該聯繫他們，以了解他們使用 Hyper Schema 的案例！

好的，那麼是誰還在存取 /schema？

不建議使用這個未帶版本號的 URI 來存取發布的最新 meta-schema。我們大約在四年前開始提醒人們注意這一點，如果您使用瀏覽器，您會看到帶有重新導向的訊息。

對此的大多數請求沒有來源，因此沒有什麼幫助。轉向使用者代理，我們看到大多數請求的使用者代理為「」。嘆氣。是啊！空白！這是不良的形式，我懷疑是什麼可能導致了這種情況。

當您查看相鄰的數據時，會發現剩餘的前 15 名使用者代理中，超過一半的請求明顯來自 IDE 和程式碼編輯器。我們看到了 IntelliJ 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 以來就沒有升級支援。

由此，我們可以推測許多在 AWS 上使用 JSON Schema 的 Java 生產服務，沒有理由放棄過時的 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.8 千次，也就是網站上的 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 job 在執行。如果我們排除排名第一的 IP 位址，我們就會失去所有高峰，這強烈表明這些爆量流量來自 Amazon 控制的 AWS 伺服器。

我們將聯繫 AWS，看看是否能獲得任何更具體的詳細資訊。這不太可能是 DoS 攻擊，但它表明有些地方出錯了。

ASN、OSI，這是什麼？

前兩個 ASN 來源是 Amazon 控制的，總計略超過 3900 萬次請求。

對於那些不是網路工程師的人來說，ASN 是一個 自治系統號碼，用於在網路上路由數據包，確保它們採用最快的路徑。如果你回想一下你學習 OSI 模型的時候（是的，我也不記得多少了），又名 開放系統互連模型，這些 ASN 被用作傳輸層的一部分。

重點是，我們無需查詢 IP 位址的所有者，就可以知道我們將近 80% 的流量來自 AWS！

國家

鑑於這麼多流量來自 AWS，大約 4300 萬次的請求來自美國和愛爾蘭並不令人意外。之後，芬蘭、印度和荷蘭組成了百萬俱樂部。接下來是德國和俄羅斯，然後是幾個來自亞洲的國家，都超過了 20 萬次。

來源

在 5192 萬次請求中，有驚人的 5112 萬次沒有宣告參照位址。排名前三的是 json-schema.org、Google，然後非常有趣的是，localhost！

奇怪的是，有 1.54 千次請求聲稱參照位址來自某個已失效的 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 上拍攝的照片