重回github pages

02-03

之前折騰的各種vps，包括vultr、HostUS、DigitalOcean等等，由於一些不可抗力，伺服器開始都還很流暢，過一段時間就幾乎不可訪問了，ping值高達300多ms，ssh基本連不上！據說，某牆採用了流量探測的方法，發現異常流量也會直接搞得你不可用；還有就是坑爹的電信網，對國外出口流量本身就有限制，導致基本在家不可用。

最終一怒之下，還是把blog遷移到比較穩定可靠的github pages上來。

Github Pages 和 Hexo

github pages是github提供的一種空間託管服務，但是只能託管靜態文件，對於寫博客足以，靜態文件支持html、css這些常見的網頁件，markdown文件、jekyll文件，並不支持PHP這種動態腳本。雖然直接用jekyll也可以寫靜態博客，但是我發現jekyll對markdown的解析不是很好，相比而言hexo對markdown的解析更到位，至少我把之前在簡書上寫的markdown文章用hexo解析是好的，用jekyll解析的一塌糊塗。

使用hexo做靜態博客有個比較麻煩的地方是，hexo本身的博客源碼是基於node.js的，直接將源碼放在github上是不能解析的，必須用命令

hexo generate

生成public文件，public文件裡面是html、css文件，然後將其部署到github的http://username.github.io項目的master分支下，或者其他repository的gh-pages分支下，同時在source目錄下添加CNAME文件（CNAME裡面記錄自定義的域名），這樣hexo會把CNAME文件放到網站根目錄下。我自己的處理方式是，在blog項目的master分支下保存博客源碼，在gh-pages分支下保存html、css等靜態文件。

hexo支持直接部署在github上，但是每次都會覆蓋提交歷史，因為hexo是force的方式進行push，在_config.yml添加如下配置

deploy:n type: gitn repo: git@github.com:yuanwhy/blog.gitn branch : gh-pagesn message : yuanwhy-blog update {{ now(YYYY-MM-DD HH:mm:ss) }})n

執行deploy命令

hexo deploy

自定義域名與CNAME原理淺析

這裡簡單地解析下github pages的基本原理，以筆者的域名http://yuanwhy.com為例，我們在訪問http://yuanwhy.com的時候到底發生了什麼？

GET / HTTP/1.1nHost: yuanwhy.comnConnection: keep-alivenPragma: no-cachenCache-Control: no-cachenAccept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8nUpgrade-Insecure-Requests: 1nUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.110 Safari/537.36nAccept-Encoding: gzip, deflate, sdchnAccept-Language: zh-CN,zh;q=0.8n

這是我在chrome瀏覽器里輸入http://yuanwhy.com的時候，通過F12觀察到的請求頭header，注意在header裡面有一個欄位host，github的伺服器正是通過host來判斷應該向瀏覽器返回一個什麼樣的html頁面。當然前提是我得把http://yuanwhy.com這個域名建立A記錄指向github提供的伺服器地址。

github知道請求是要獲取http://yuanwhy.com的首頁，但是應該去哪個repository裡面找呢？這個時候我猜測，github伺服器肯定有資料庫存儲了http://yuanwhy.com和repository的對應關係，這個對應關係肯定是我在向blog項目的gh-pages分支添加CNAME文件的時候建立的，注意必須是gh-pages分支才會觸發這個關係的建立，或者http://yuanwhy.github.io項目的master分支也同樣能觸發。

但是這裡有個漏洞，如果我在自己項目的gh-pages的CNAME文件寫上了別人同樣指向github伺服器的域名，那麼他的域名會不會訪問到我的repository上？哈哈，有待驗證！