幹壞事是進步最大的原動力
在 Twitter 上看到 CloudFront 又擴點的消息了：
Amazon CloudFront announces nine new Edge locations globally across major cities in North America, Europe & Asia! https://t.co/HoQmJLtBPJ pic.twitter.com/54TDIEiDaX
— Amazon Web Services (@awscloud) July 24, 2018
點進去一看發現亞洲的點又是擴東京：
And in Asia, one Edge location is being added in Tokyo, Japan, our ninth in the city.
同樣是日本，不考慮擴一下大阪的點嗎... 或是加開名古屋的點？(蠻多海纜從志摩跟豐橋拉上去的)
在 Twitter 上看到 AWS 宣佈 CloudFront 加了四個點：
Amazon CloudFront announces four new Edge locations, including its first location in Cape Town, South Africa! 🇿🇦https://t.co/9fXgdgp9jL pic.twitter.com/5O7yYlkBZR
— Amazon Web Services (@awscloud) July 12, 2018
點進去後發現這四個點包括了台北：
Amazon CloudFront announces four new Edge locations: Cape Town, South Africa; Denver, Colorado; Frankfurt, Germany; and Taipei, Taiwan.
在 CloudFront 的列表裡也增加到三個點：
Bangalore, India; Chennai, India (2); Hong Kong, China (3); Kuala Lumpur, Malaysia; Mumbai, India (2); Manila, Philippines; New Delhi, India; Osaka, Japan; Seoul, South Korea (4); Singapore (3); Taipei, Taiwan(3); Tokyo, Japan (8)
這樣應該可以再減少被導去海外節點的機會 (通常是香港或日本)，不過狀況會怎麼樣還要再觀察... 先前加第二個點後，觀察到的現象是有減少，但還是會發生。現在加到第三個後不知道會不會解決...
AWS 宣佈 CloudFront 在非洲的第一個節點開在南非的約翰尼斯堡 (Johannesburg)：「Amazon CloudFront Expands into Africa with new Edge Location in Johannesburg and first Edge Location in Bangalore」。
這樣各大洲都有點了...
看到 Amazon CloudFront 宣佈在東京開到第八個點了：「Amazon CloudFront launches eighth Edge location in Tokyo, Japan」。
Amazon CloudFront announces the addition of an eighth Edge location in Tokyo, Japan. The addition of another Edge location continues to expand CloudFront's capacity in the region, allowing us to serve increased volumes of web traffic.
這個成長速度有點驚人，一月才加了兩個，現在又要再加一個... 不過大阪還是維持一個。
最近在寫網頁時發現 Bootstrap 的網站上給的 CDN 網址改了，從本來用的 maxcdn.bootstrapcdn.com (MaxCDN) 變成 stackpath.bootstrapcdn.com (StackPath，本來的 Highwinds)。
而且看起來跟 MaxCDN 的合作已經全部停了，現在 maxcdn.bootstrapcdn.com 也是指到 StackPath 上。
翻了 Wayback Machine 上的記錄，看起來是在 20180409045017 與 20180410051321 這之間換的，也就是大約是在 2018/04/10 前後換的。不知道後面的交易是什麼...
可以參考 K 社的 SmokePing 資料「SmokePing Latency Page for netdna.bootstrapcdn.com (NetDNA, Bootstrap)」：
可以看到 HiNet 走的點的latency 比之前好不少...
在朋友的 tweet 裡看到微軟啟用自己的 Azure CDN 了，先前應該是提供 Akamai 與 EdgeCast 的服務：「Announcing Microsoft's own Content Delivery Network」。
看圖似乎是有台灣的點，不過我找不到可以測試 traceroute 的 endpoint，頁面上用的圖還是 EdgeCast 的啊 XDDD
;; ANSWER SECTION: azurecomcdn.azureedge.net. 1604 IN CNAME azurecomcdn.ec.azureedge.net. azurecomcdn.ec.azureedge.net. 3404 IN CNAME cs9.wpc.v0cdn.net. cs9.wpc.v0cdn.net. 3404 IN A 117.18.232.200
然後公測期間優惠價 50%：
Azure Content Delivery Network Standard from Verizon (S1) and Akamai (S2) and Microsoft (S3)*
*S3 is currently in public preview. CDN rates will be 50% of the stated price during this period.
以往在 GitHub 上如果要使用 HTTPS 只能使用 *.github.io 網域，現在 GitHub 宣佈透過 Let's Encrypt 的服務支援了：「Custom domains on GitHub Pages gain support for HTTPS」：
We have partnered with the certificate authority Let’s Encrypt on this project. As supporters of Let’s Encrypt’s mission to make the web more secure for everyone, we’ve officially become Silver-level sponsors of the initiative.
不過目前只支援 CNAME record (標準) 或是 ALIAS record 的方式 (非標準，也稱為 ANAME，有些 DNS provider 有支援，主要用在網域本身 (i.e. root domain) 無法使用 CNAME)。
如果是使用 A record，則是需要更新 IP 位置：
If you are using
Arecords, you must update your site’s DNS records with new IP addresses. Please see our guide to setting up your custom domain with Pages and update any A records you might have set.
另外也提供 HTTP 轉 HTTPS 的選項：
以前 HTTPS 還得自己弄伺服器處理，現在可以直接往 GitHub 上丟了...
另外用查出來的 IP 看了一下架構，IP 是 Fastly 的，所以應該是跟 Fastly 合作，但不確定是 Fastly 自己搞定 Let's Encrypt 的憑證，或是 Fastly 提供 Port 80/443 的 TCP Proxy？
Twitter 上看到了 Amazon CloudFront 宣佈了台北的第二個 PoP：
Amazon CloudFront announces 2 new Edge Locations, adding a second location in Taipei & a third location in Singapore. https://t.co/pU5gDbJWBT pic.twitter.com/9U4ZLBSXmk
— Amazon Web Services (@awscloud) April 25, 2018
這個也是喊好久了，從去年就有消息一直到現在... 這樣台灣多了一個 backup，比較不會導去香港或是日本了。不過新 PoP 的代碼找不到，試著找 tsa 與 tpe 以及後面接數字，還是只有找到 tpe50，不知道是不是後來不露出代碼了...
Cloudflare 推出了 Spectrum，文章標題提到的 65533 應該是指 80 & 443 以外其他的 port：「Introducing Spectrum: Extending Cloudflare To 65,533 More Ports」。
然後因為 TCP proxy 不像 HTTP proxy 與 WebSocket proxy 可以靠 Host header 資訊判斷，在 TCP proxy 需要獨占 IP address 使用 (i.e. 一個 IP address 只能給一個客戶用)，而因為 IPv4 address 不夠的關係，這個功能只開放給 Enterprise 客戶用：
Today we are introducing Spectrum, which brings Cloudflare’s security and acceleration to the whole spectrum of TCP ports and protocols for our Enterprise customers.
雖然現在限定在 Enterprise 客戶，但 Cloudflare 還是希望看看有沒有其他想法，目前提出來的選項包括了開放 IPv6 address 給所有人用，或是變成獨立付費項目：
Why just Enterprise? While HTTP can use the Host header to identify services, TCP relies on each service having a unique IP address in order to identify it. Since IPv4 addresses are endangered, it’s quite expensive for us to delegate an IP per application and we needed to limit use. We’re actively thinking about ways to bring Spectrum to everyone. One idea is to offer IPv6-only Spectrum to non-Enterprise customers. Another idea is let anyone use Spectrum but pay for the IPv4 address. We’re not sure yet, but if you prefer one to the other, feel free to comment and let us know.
類似的產品應該是 clean pipe 類的服務，但一般 clean pipe 是透過 routing 重導清洗流量，而非像 Cloudflare 這樣設計... 不知道後續會有什麼樣的變化。
HTTPS Everywhere 是我很喜歡的一個套件，裡面有 Ruleset，會將 Ruleset 表內認定有支援 HTTPS 網站的 HTTP request 都改成 HTTPS，這可以降低被攔截的風險。像是網站雖然有 HSTS 但第一次連線時走 HTTP 的情況，以及網站本身有支援 HTTPS 但沒有設定 HSTS 時，在網址列上誤打 HTTP 版本的情況。
先前版本的 Ruleset 是隨著軟體更新時，包在軟體內一起更新。這樣的缺點是更新速度比較慢，但好處是不需要伺服器端，而且隱私性也比較高。而現在 EFF 決定還是要推出線上更新的版本，以加速 Ruleset 更新的速度：「HTTPS Everywhere Introduces New Feature: Continual Ruleset Updates」。
We've modified the extension to periodically check in with EFF to see if a new list is available.
而頻寬的部份由 Fastly 贊助：
If you haven't already, please install and contribute to HTTPS Everywhere, and consider donating to EFF to support our work!
如果對這點有疑慮的，也還是可以關掉 auto updater 避免洩漏資訊給 EFF 或是 Fastly。