內容分發網絡 Content Delivery Network
前言
除去 WordPress, 許多博客網站是托管於 GitHub Pages 上的，但其在國內的速度實在是難以稱道。
所以使用國內服務商的 CDN 對其進行加速不失為一個好辦法。
內容分發網絡（Content Delivery Network，CDN）通過將站點內容發布至遍布全國的海量加速節點，使其用戶可就近獲取所需內容，避免網絡擁堵、地域、運營商等因素帶來的訪問延遲問題，有效提升下載速度、降低響應時間，提供流暢的用戶體驗。
曾經我使用的策略是在國內托管 Coding Pages，以及為了讓百度能抓取到博客內容，還做了一番配置。
但是 Coding 的服務並不穩定，且經常變動一些策略。
現在更是下線整合到靜態部署中，且似乎因為 API 的問題實名認證總是不能通過，暫時都無法使用。
所以便干脆使用 CDN 來進行加速。並且也可以輕松被百度抓取了。
因為我域名購置於騰訊雲，且騰訊雲 CDN 每月贈送免費 10G 流量。
所以我直接采用騰訊雲的 CDN 來實現。
注意：域名需要備案（按需簽發 SSL 證書）
步驟
首先開通騰訊雲 - 內容分發網絡。
添加自己的域名
設置源站
管理 > 基本配置
這里是 GitHub Pages 提供的 IP 地址，可以添加多行。
可選：建議前往
高級配置開啟 HTTPS 配置
回源協議
證書管理 > 編輯 > 協議跟隨 (如果沒開啟 HTTPS，默認的 HTTP 也可以
設置 CNAME
前往 域名解析
根據需要將 CDN 提供的 CNAME 線路類型設置為 境內。境外 則仍默認解析回 GitHub Pages。
配置緩存
默認的緩存時間非常長，不配置的話就會導致 CDN 的文件長時間沒有更新。
可以參見騰訊雲文檔 緩存配置問題
也可以在 刷新預熱 處手動刷新。
后話
測試發現首頁基本可以秒開，速度確實不錯。
至於流量萬一不夠用怎么辦，emm，大概等這里真有這么大訪問量的時候，就不至於還要在這樣各處薅羊毛了吧。
FAQ
CNAME 與 MX 記錄沖突導致郵件丟失
值得注意的是，設置 CDN 的方式是使用 CNAME 重定向到 CDN 域名。
如果你同時將裸域名（developingmonkey2022.org）作為博客域名和域名郵箱（比如我的郵箱：me@developingmonkey2022.org），那么你可能會遇到 CNAME 與 MX 記錄沖突問題。
如果你的運營商沒有這么提示你，那也最好不要這么做，因為這會導致域名郵箱發生郵件丟失。
在過去解析尚未規范時，部分運營商是允許同時在裸域名上設置 CNAME 和 MX 記錄的。
但如今按照 RFC 標准協議，CNAME 優先級最高，所以在解析請求過程中，會優先返回 CNAME 解析記錄結果。
這樣設置的結果就是導致無法解析到用戶設置的 MX 記錄（設置權重也沒有用），影響郵箱的正常收發。
現在，大部分運營商會提示 CNAME 與 MX 記錄發生沖突，來避免這種情況。
我此前之所以使用 GitHub Pages 托管，卻仍然能夠使用域名郵箱，是因為我使用了 GitHub 提供的 A 記錄解析。
185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153而如今加了 CDN 又回到了這一兩難的局面。
最后想着長痛不如短痛，下定決定將博客主域名更換為 www.developingmonkey2022.org
裸域名仍舊使用 A 記錄和 MX 記錄。
設置 A 記錄的作用是用戶訪問 developingmonkey2022.org 時（GitHub Pages 的 CNAME 文件提前設置為 www.developingmonkey2022.org），那么 GitHub Pages 會自動從 developingmonkey2022.org 跳轉為 www.developingmonkey2022.org。
此外，谷歌瀏覽器會自動隱藏 www 域名前綴，所以一定程度上減少觀感的影響。
以及我發現一些企業的網站都采取的裸域名跳轉 www 域名的方式。
譬如：
- 語雀：https://yuque.com,
- JetBrains（著名的 IDE 軟件開發商）：https://jetbrains.com（我在幾年前的視頻里發現他們留的還是裸域名的網址，而現在則是跳轉 www 鏈接。）
當然如果你對域名郵箱沒有需求，且域名非常短又很酷，使用裸域名也並非不可。
此外還有一種解決方案就是 CNAME Flattening。
有些服務商（如 Cloudflare、CloudXNS）可以直接將 CNAME 解析為對應的 A 記錄（IP 地址），這時在裸域名上設置 CNAME 就相當於設置 A 記錄。
以往騰訊雲允許 CNAME 與 MX 並存，再然后提示沖突不允許，到了現在又可以同時設置了。但最好是一次性可以解析到 A 記錄的 CNAME。
我嘗試在 www 域名上加了 CNAME 開啟了 CDN，裸域名 CNAME 到 www，就會影響郵箱。
這時的路徑就相當於：@ -> www(CNAME) -> cdn(CNAME) -> A。可能無法使用 CNAME Flattening 。
而直接 CNAME 到 GitHub Pages 時，郵箱網址都可以正常工作。@ -> GitHub Pages(CNAME) -> A
PS. 怎么感覺自己最近說話都有點翻譯腔了。
CDN 刷新
有了 CDN，這也意味着你的頁面可能會因此延遲更新（對於用戶來說）。
因此，CDN 往往提供了刷新預熱功能。譬如指定 URL 或者目錄進行更新。
其實延遲的一會兒也不算是什么事，遇到着急的鏈接手動去控制台刷新即可。
但說實話，每次登陸到網站上操作着實有些浪費時間。
那么不如考慮一下命令行工具。
需要 Python & pip
- 騰訊雲命令行工具 TCCLI
- 安裝 TCCLI：介紹如何安裝 TCCLI。
- 配置 TCCLI：介紹在開始使用 TCCLI 之前，需要完成 TCCLI 的初始化配置。
- 使用 TCCLI：介紹如何使用 TCCLI 創建雲服務器及相關使用說明。
- 使用高級功能：介紹 TCCLI 的高級功能，例如多版本接口訪問、返回結果過濾等。
Example:
# 注意這里的參數是 Array
# 刷新目錄
tccli cdn PurgePathCache --Paths '["https://www.developingmonkey2022.org/links/"]' --FlushType flush
# 刷新鏈接
tccli cdn PurgeUrlsCache --Urls '["https://www.developingmonkey2022.org/links/index.html"]'PurgePathCache
PurgePathCache 用於批量提交目錄刷新，根據域名的加速區域進行對應區域的刷新。
默認情況下境內、境外加速區域每日目錄刷新額度為各 100 條，每次最多可提交 20 條。
–Paths
目錄列表，需要包含協議頭部 http:// 或 https://
–FlushType
刷新類型
- flush：刷新產生更新的資源
- delete：刷新全部資源
PurgeUrlsCache
PurgeUrlsCache 用於批量提交 URL 進行刷新，根據 URL 中域名的當前加速區域進行對應區域的刷新。
默認情況下境內、境外加速區域每日 URL 刷新額度各為 10000 條，每次最多可提交 1000 條。
–Urls
URL 列表，需要包含協議頭部 http:// 或 https://
后后話
2020-03-26
因為不知騰訊雲 CDN 為何掛了，轉為使用 Cloudflare 了，自動 Flattening。
后發現不是騰訊雲的問題，是 GitHub Pages 的 HTTPS 證書被劫持了。Github pages 的 HTTPS 是不是出問題了？
既然已經更改為 www 主域名，也還是繼續使用裸域名跳轉 www 的策略吧。
2020-04-17
開始使用又拍雲 CDN，申請了 又拍雲聯盟，拿到了代金券。
后來到了五月，發現百度索引竟然所剩無幾。原本還以為國內 CDN （此前的騰訊雲確實可以）會被收錄的。
測試發現百度 抓取診斷 抓取失敗時錯誤信息為 拒絕訪問。
難不成時又拍雲的一些 CDN 點也禁止百度抓取了？
我不斷對抓取的 IP 進行報錯，百度抓取診斷就會換一個 IP 抓，於是乎排除掉一些拒絕訪問的 IP，有些 IP 倒是可以抓取成功了。
2020-05-24
但卻並非如此，索引量仍舊在下降，我提交了又拍雲工單，客服反饋是回源訪問時源站本身便是 403 拒絕訪問。（但我正常訪問均正常。）
所以我猜想的是又拍雲部分 CDN IP 有緩存時，所以回抓取成功，而其他 IP 無緩存時，則會回源，回源的過程中沒有過濾百度爬蟲的 User Agent，所以回源 GitHub Pages 仍舊會被拒絕。
此后我開啟了又拍雲的源站資源遷移，即可將源站靜態資源無縫遷移到又拍雲存儲，當客戶端下次訪問相同的資源時，無需回用戶自主源。
隨后過了幾天，索引量果然回升了……
2021-05-27
后續得到了又拍雲的贊助，寫了一篇又拍雲的軟文？，不過我之前也確實一直在用又拍雲，並列舉了優劣，也算是真心實意地推薦。