Month: November 2017

靜態站台的選擇...

在 Hacker News 首頁上看到的文章，講 Jekyll 一路跟 Amazon S3 與 Amazon CloudFront 接上去的步驟：「Jekyll CBCD Pipeline to the Cloud」。

我看了以後覺得好麻煩 @_@

然後回頭看 Hacker News 上的評論：「Jekyll Static Web Hosting – Deployment Pipeline on AWS | Hacker News」，看到這段：

What a nightmare. I'm sure there are use cases for a setup like this, but this is not the system I'd like to maintain. I use Jekyll because of it's simplicity. I edit my site in my favorite text editor and rsync to shared hosting.

好多人都有同感啊 XDDD

另外有人提到 Netlify 這個服務：

After I discovered Netlify, I'm kind of thinking "why bother". It's free, I just push to my repo and they take care of all the building/publishing/hosting/CDNs, and they're very responsive for support and have high availability. I'm a very happy customer (or rather leech, as I don't pay anything).

下面評價看起來還算不錯，而且有 free tier 可以用，也許可以找機會玩看看...

Amazon RDS 支援更大的硬碟空間與更多的 IOPS

Amazon RDS 的升級：「Amazon RDS Now Supports Database Storage Size up to 16TB and Faster Scaling for MySQL, MariaDB, Oracle, and PostgreSQL Engines」。

空間上限從 6TB 變成 16TB，而且可以無痛升。另外 IOPS 上限從 30K 變成 40K：

Starting today, you can create Amazon RDS database instances for MySQL, MariaDB, Oracle, and PostgreSQL database engines with up to 16TB of storage. Existing database instances can also be scaled up to 16TB storage without any downtime.

The new storage limit is an increase from 6TB and is supported for Provisioned IOPS and General Purpose SSD storage types. You can also provision up to 40,000 IOPS for Provisioned IOPS storage volumes, an increase from 30,000 IOPS.

不過隔壁的 Amazon Aurora 還是大很多啊 (64TB)，而且實際上不用管劃多大，他會自己長大：

Q: What are the minimum and maximum storage limits of an Amazon Aurora database?

The minimum storage is 10GB. Based on your database usage, your Amazon Aurora storage will automatically grow, up to 64 TB, in 10GB increments with no impact to database performance. There is no need to provision storage in advance.

PChome 24h 連線會慢的原因... (續篇)

上一篇「PChome 24h 連線會慢的原因...」寫到 DNS resolver 會倒在路邊，但沒寫會怎麼倒... 因為規格書上沒有寫當問不到要問的東西時要怎麼處理，所以每一家處理的方式都不太一樣。

我把對各 DNS resolver 查詢 100 次的結果放在 GitHub Gist 上：「Query 24h.pchome.com.tw」，大家都是回 SERVFAIL，只是時間不一樣 (最後一個 x.xxxx total 的部份表示實際秒數，wall clock)。

先看這次的主角好了，HiNet 的 168.95.1.1 與 168.95.192.1，同時也應該是 PChome 24h 服務使用人數最多的 DNS resolver。

這兩個 DNS resolver 在遇到問題時不會馬上回 SERVFAIL，加上業界有小道消息說中華自己改了不少 code，所以跟一般的 open source software 行為不太一樣。由於看不到 PChome 端的 DNS packet，所以只能就行為來猜... 應該是在第一輪都查不到後，會先 random sleep 一段時間，然後再去問一次，如果第二次還是失敗的話才回應 SERVFAIL。

這個 random sleep 看起來可能是 10 秒，因為數據上看起來最長的時間就是這個了。

SEEDNet 的 139.175.1.1 以及 Google 的 8.8.8.8 都沒這個問題，都會馬上回應 SERVFAIL。

前陣子新出的 9.9.9.9 (參考「新的 DNS Resolver：9.9.9.9」) 則是有些特別的狀況，可以看到前面有三個 query 很慢 (第 2、3、5 三行)，但後面的速度就正常了。可能是新加坡那邊有三台伺服器在服務 (目前我這邊測試的機器到 9.9.9.9 會到新加坡)，在第一次遇到都沒有答案時會有特殊的演算法先確認，之後就會 cache 住？

所以各家 DNS resolver 反應都不太一樣，然後最大那家有問題 XD

24h.pchome.com.tw 慢一次，ecvip.pchome.com.tw 再慢一次，圖片的 a.ecimg.tw 再慢一次，一個頁面上多來幾個 domain 就會讓人受不了了 XD

其實我只要改成 8.8.8.8 或是改走 proxy.hinet.net 就可以解決啦，但還是寫下來吧 (抓頭)。

Happy Eyeballs (RFC 6555)

在「PChome 24h 連線會慢的原因...」這篇的 comment 有讀者提到了 Happy Eyeballs 應該可以解決這個問題：

除了可以在維基百科上面看到外，比較正式的說明可以參考 RFC 6555：「Happy Eyeballs: Success with Dual-Stack Hosts」，其中在「6. Example Algorithm」就有提到 Google Chrome 與 Mozilla Firefox 怎麼實做 Happy Eyeballs：

What follows is the algorithm implemented in Google Chrome and Mozilla Firefox.

  1. Call getaddinfo(), which returns a list of IP addresses sorted by the host's address preference policy.
  2. Initiate a connection attempt with the first address in that list (e.g., IPv6).
  3. If that connection does not complete within a short period of time (Firefox and Chrome use 300 ms), initiate a connection attempt with the first address belonging to the other address family (e.g., IPv4).
  4. The first connection that is established is used. The other connection is discarded.

If an algorithm were to cache connection success/failure, the caching would occur after step 4 determined which connection was successful.

Other example algorithms include [Perreault] and [Andrews].

可以看到 Happy Eyeballs 的演算法是要避免 IPv6 network 不通的情況卡住很慢 (如果在 300ms 內連線沒有建起來，就會儘快往另外一個 address family 嘗試)，而不是在 DNS 層避免問題 (也就是 getaddinfo() 觸發的 DNS query)。

這次的情況是 DNS query 很慢，就會導致還是一開始就很慢，Happy Eyeballs 沒辦法解決這個問題。

不過話說回來，我是有印象知道有這個演算法，但不知道有「Happy Eyeballs」這個這麼逗趣的名字... (掩面)

AWS Certificate Manager 支援 DNS 認證的方式頒發憑證了

AWS Certificate Manager (ACM) 可以用 DNS 的方式認證了：「Easier Certificate Validation Using DNS with AWS Certificate Manager」。

不過這不同於 Let's Encrypt 在推的 dns-01，而是 AWS 自己定義的方式：

然後文章後面又再次提醒了一次，如果要用在 Amazon CloudFront，必須使用 us-east-1 的 ACM：

Note that your certificate must be in the US East (N. Virginia) Region to use the certificate with CloudFront.

這個方式讓自動化更容易做... 以前需要收信確認，雖然也是可以寫程式硬幹，但就得冒著 AWS 改版造成程式失效的風險。

Amazon Aurora (PostgreSQL 版本) 開放到其他區域了

上個月月底才宣佈 Amazon Aurora 推出 PostgreSQL 版本 (參考「Amazon Aurora 也支援 PostgreSQL 了」)，不過當時只有少數的四個區域開放 (us-east-1、us-east-2、us-west-2、eu-west-1)，還不到一個月的時間就擴張了：「Amazon Aurora with PostgreSQL Compatibility Region Expansion」。

不過還是沒有東京與新加坡這兩個台灣比較常用的區域... 看起來都是比較新的 region，但首爾應該也是新的區域啊，不知道怎麼選擇的：

The PostgreSQL-compatible edition of Amazon Aurora is now available in four additional AWS regions: Canada (Central), EU (Frankfurt), Asia Pacific (Sydney), and Asia Pacific (Mumbai). This increases the number of available regions to eight, as the service launched on October 24, 2017 in US East (N. Virginia), US East (Ohio), US West (Oregon), and EU (Ireland).

就算關掉 Google 的定位服務也還是會蒐集位置資訊...

就如標題所寫的，Quartz 獨家刊出來的新聞，即使你關掉 Google 的定位服務，Google 還是會蒐集你的位置 (而且跟 Google 發言人確認後也證實)：「Google collects Android users’ locations even when location services are disabled」。

而且是全背景作業，在你沒有開定位服務，沒有插 SIM 卡，也沒有跑任何 app，他就會將定位資訊傳出去：

Many people realize that smartphones track their locations. But what if you actively turn off location services, haven’t used any apps, and haven’t even inserted a carrier SIM card?

從今年年初開始這樣搞的，Google 發言人只宣稱這個資料並沒有被用來整合到「network sync system」，並且會立即丟掉 (所以你還是不知道被用到什麼地方)：

“In January of this year, we began looking into using Cell ID codes as an additional signal to further improve the speed and performance of message delivery,” the Google spokesperson said in an email. “However, we never incorporated Cell ID into our network sync system, so that data was immediately discarded, and we updated it to no longer request Cell ID.”

這句話的意思其實代表著是丟掉 raw data，改以統計的方式轉移存到其他系統。

另外 John Gruber 在「Google Collects Android Users' Locations Even When Location Services Are Disabled」其實寫的更直接：

If they were “never used or stored”, why did they start collecting them in the first place? This is like a kid caught with their hand in the cookie jar saying they weren’t going to eat any cookies. Sure.

白話一點就是「你當我傻逼啊」。

應該會促進 microG 的發展... (參考「microG 的進展...」)

解鎖 iPhone 的 Diper ID...

Twitter 上看到 Diper ID 這個糟糕的東西：

查了資料，操作方式可以從這個影片看到：

這明顯有資安問題啊 XDDD

PChome 24h 連線會慢的原因...

Update：續篇請參考「PChome 24h 連線會慢的原因... (續篇)」。

tl;dr：因為他們的 DNS servers 不會對 IPv6 的 AAAA record 正確的回應 NXDOMAIN，導致 DNS resolver 會不斷嘗試。

好像一行就把原因講完了啊，還是多寫一些細節好了。

起因於我的電腦連 PChome 24h 時常常會卡住，Google Chrome 會寫「Resolving host...」，於是就花了些時間找這個問題。

一開始先用幾個工具測試，發現 host 會卡，但不知道卡什麼：

$ host 24h.pchome.com.tw

拿 tcpdump 出來聽的時候發現 host 會跑 A、AAAA 以及 MX 三個種類，而後面兩個都會卡住：

24h.pchome.com.tw is an alias for shopping.gs1.pchome.com.tw.
shopping.gs1.pchome.com.tw has address 210.242.43.53
;; connection timed out; no servers could be reached
;; connection timed out; no servers could be reached

這樣就有方向了... 我的電腦是 Dual-stack network (同時有 IPv4 address 與 IPv6 address)，所以可以預期 Google Chrome 會去查 IPv6 address。而國內很多網站都還沒有把有 IPv6 的情境當標準測試，很容易中獎...

有了方向後，用 dig 測試 IPv6 的 AAAA，發現都是給 SERVFAIL，而且多跑幾次就發現會卡住：

$ dig 24h.pchome.com.tw aaaa @168.95.192.1

然後對 {cheetah,dns,dns2,dns3,wolf}.pchome.com.tw (上層登記的) 與 dns4.pchome.com.tw (實際多的) 測，可以拿到 CNAME record，像是這樣：

$ dig 24h.pchome.com.tw aaaa @dns.pchome.com.tw

; <<>> DiG 9.9.5-3ubuntu0.16-Ubuntu <<>> 24h.pchome.com.tw aaaa @dns.pchome.com.tw
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26037
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 6
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;24h.pchome.com.tw.             IN      AAAA

;; ANSWER SECTION:
24h.pchome.com.tw.      300     IN      CNAME   shopping.gs1.pchome.com.tw.

;; AUTHORITY SECTION:
gs1.pchome.com.tw.      300     IN      NS      ns3.gs1.pchome.com.tw.
gs1.pchome.com.tw.      300     IN      NS      ns1.gs1.pchome.com.tw.
gs1.pchome.com.tw.      300     IN      NS      ns4.gs1.pchome.com.tw.
gs1.pchome.com.tw.      300     IN      NS      ns5.gs1.pchome.com.tw.
gs1.pchome.com.tw.      300     IN      NS      ns2.gs1.pchome.com.tw.

;; ADDITIONAL SECTION:
ns1.gs1.pchome.com.tw.  300     IN      A       210.242.216.91
ns2.gs1.pchome.com.tw.  300     IN      A       210.242.216.92
ns3.gs1.pchome.com.tw.  300     IN      A       210.242.43.93
ns4.gs1.pchome.com.tw.  300     IN      A       203.69.38.91
ns5.gs1.pchome.com.tw.  300     IN      A       210.71.147.91

;; Query time: 12 msec
;; SERVER: 210.59.230.85#53(210.59.230.85)
;; WHEN: Wed Nov 22 11:05:24 CST 2017
;; MSG SIZE  rcvd: 243

但往 ns{1,2,3,4,5}.gs1.pchome.com.tw 問的時候給不出答案，也不給 NXDOMAIN，像是這樣：

$ dig shopping.gs1.pchome.com.tw aaaa @ns1.gs1.pchome.com.tw

; <<>> DiG 9.9.5-3ubuntu0.16-Ubuntu <<>> shopping.gs1.pchome.com.tw aaaa @ns1.gs1.pchome.com.tw
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36249
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 6
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;shopping.gs1.pchome.com.tw.    IN      AAAA

;; AUTHORITY SECTION:
gs1.pchome.com.tw.      3600    IN      NS      ns3.gs1.pchome.com.tw.
gs1.pchome.com.tw.      3600    IN      NS      ns4.gs1.pchome.com.tw.
gs1.pchome.com.tw.      3600    IN      NS      ns5.gs1.pchome.com.tw.
gs1.pchome.com.tw.      3600    IN      NS      ns1.gs1.pchome.com.tw.
gs1.pchome.com.tw.      3600    IN      NS      ns2.gs1.pchome.com.tw.

;; ADDITIONAL SECTION:
ns3.gs1.pchome.com.tw.  3600    IN      A       210.242.43.93
ns4.gs1.pchome.com.tw.  3600    IN      A       203.69.38.91
ns5.gs1.pchome.com.tw.  3600    IN      A       210.71.147.91
ns1.gs1.pchome.com.tw.  3600    IN      A       210.242.216.91
ns2.gs1.pchome.com.tw.  3600    IN      A       210.242.216.92

;; Query time: 11 msec
;; SERVER: 210.242.216.91#53(210.242.216.91)
;; WHEN: Wed Nov 22 11:07:17 CST 2017
;; MSG SIZE  rcvd: 310

於是 DNS resolver 就倒在路邊了...

Google 的 .search 網域

在 Netcraft 的「November 2017 Web Server Survey」這篇看到關於 Google 弄到的 .search 網域：

This month the controversial new .search gTLD being run by Google’s Charleston Road Registry subsidiary was found for the first time, with www.nic.search responding to the survey. Google hopes it will be able to run .search as a dotless domain which will automatically redirect users to their search engine of choice. This proposal has been criticised for going against ICANN’s own rules, which prohibits this functionality due to the potential for conflicts with existing names on internal networks. This feature could also cause confusion for users who have come to expect that typing words into their address bar will perform a search query for that term.

It is currently uncertain whether or not Google will be allowed to run the .search TLD as a dotless domain, however with the launch of the first site on this TLD this month Google is one step closer to the provision of this service.

找了一下資料，ICANNWiki 上的「.search」有些資料，另外也有新聞資訊 (2013 年的)：「Google Wants To Operate .Search As A “Dotless” Domain, Plans To Open .Cloud, .Blog And .App To Others」。

不太妙...