幹壞事是進步最大的原動力
兩個禮拜前才宣佈改名：「Linode 改名叫 Akamai Connected Cloud」，現在就宣佈漲價了：「Akamai’s Cloud Computing Services: Pricing Update」。
這次最注目的是這個，VPS 的部份漲 20%，只有最低的機種維持 US$5/mo：
The price of Shared and Dedicated compute plans will increase by 20%. Our shared Nanode plan remains unchanged at US$5 per month.
降 bandwidth overage cost 只是擺在一起好看而已。
在 Hacker News 上翻一下，也有不少討論：「Linode increases price of compute plans and more (linode.com)」。
先不提 AWS 在後面撐著的 AWS Lightsail，這樣看起來 Vultr 愈來愈有競爭性了？
Linode 改名叫做 Akamai Connected Cloud：「A Bold New Approach to the Cloud」、「Akamai Unveils Akamai Connected Cloud and New Cloud Computing Services」。
所以 Akamai 走的路線是整合品牌，這樣其實有很大的機會是會讓 Linode 本來的速度被大組織架構拖慢。
啊，反正現在已經沒在用 Linode 了，只能跟 HN 裡「Linode rebranded as Akamai’s cloud computing services (linode.com)」討論一樣，RIP Linode...
Akamai 把自家的 shared domains 申請加入 PSL (Public Suffix List)：「Adding Akamai Shared Domains to the Public Suffix List」。
提到 PSL，常被拿來舉例的應該就是 supercookie 了，也就是把 cookie 的有效網域設到 .com 或是 .org 這種 top level domain，這樣就可以跨很多站台追蹤使用者了 (所以被稱為 supercookie)，而 PSL 則可以被拿來限制這些網域名稱。
而在 Akamai 的例子來說，edgekey.net 下面的使用者都會共用 cookie，對於安全與隱私的考量其實不太好。這次把這些網域加到 PSL 之後，變成 edgekey.net 這層無法設定 cookie，而 one.edgekey.net 與 two.edgekey.net 各自有自己的 cookie namespace，這樣就好一些了...
順帶一提，除了瀏覽器會引入 PSL 來過濾外，使用者端可以靠 Privacy Badge 來過濾掉這類的 cookie，因為 Privacy Badge 會針對這類網域清掉 cookie 再送出 HTTP request。
Akamai 的文章裡面也有提到這件事情：
The PSL contains multi-party domain suffixes and is used by a wide range of client software (for example, web browsers) to implement policy decisions, such as to prevent cookies from being set on public or multi-party domains.
目前在 Hacker News 首頁第一名，Akamai 併購 Linode：「Akamai To Acquire Linode to Provide Businesses with a Developer-friendly and Massively-distributed Platform to Build, Run and Secure Applications」，Linode 的新聞稿則是在「Linode and Akamai」，Hacker News 上的討論在「Akamai to Acquire Linode (akamai.com)」這邊。
併購金額與預期的時間表：
Under terms of the agreement, Akamai has agreed to acquire all of the outstanding equity of Linode Limited Liability Company for approximately $900 million, after customary purchase price adjustments. As a result of structuring the transaction as an asset purchase, Akamai expects to achieve cash income tax savings over the next 15 years that have an estimated net present value of approximately $120 million. The transaction is expected to close in the first quarter of 2022 and is subject to customary closing conditions.
好像會有記者會... 應該會有更多說明。
整理資料的時候看到以前就看到的資訊，Akamai 有提供工具，可以看 DNS resolver 的資訊：「Introducing a New whoami Tool for DNS Resolver Information」。
這拿來分析 168.95.1.1 或是 8.8.8.8 這些服務還蠻好用的，這些對外雖然有一個 IP address 在服務，但後面是一整個 cluster，所以可以利用 Akamai 的這個工具來看分析。
像是 8.8.8.8 會給接近的 EDNS Client Subnet (ECS) 資訊 (ip 的部份看起來是隨便給一個)：
$ dig whoami.ds.akahelp.net txt @8.8.8.8 [...] ;; ANSWER SECTION: whoami.ds.akahelp.net. 20 IN TXT "ns" "172.217.43.194" whoami.ds.akahelp.net. 20 IN TXT "ecs" "111.250.35.0/24/24" whoami.ds.akahelp.net. 20 IN TXT "ip" "111.250.35.149"
而 1.1.1.1 會給假的 ECS 資訊：
$ dig whoami.ds.akahelp.net txt @1.1.1.1 [...] ;; ANSWER SECTION: whoami.ds.akahelp.net. 20 IN TXT "ns" "2400:cb00:80:1024::a29e:f134" whoami.ds.akahelp.net. 20 IN TXT "ip" "2400:cb00:80:1024::a29e:f134" whoami.ds.akahelp.net. 20 IN TXT "ecs" "111.250.0.0/24/24"
然後 168.95.1.1 則是連 ECS 都不給 XDDD
$ dig whoami.ds.akahelp.net txt @168.95.1.1 [...] ;; ANSWER SECTION: whoami.ds.akahelp.net. 20 IN TXT "ns" "2001:b000:180:8002:0:2:9:114"
之前在找 DNS 類問題的時候還算可以用的工具...
沒介紹過 Akamai 的一些架構，先講到 Akamai 的 Edge 端 Serverless 架構是 EdgeWorkers，跑的是 JavaScript：
EdgeWorkers lets developers just code — integrating into existing CI/CD workflows and enabling multiple teams to work in parallel using JavaScript. EdgeWorkers eliminates the hassle of managing compute resources and building for scale.
然後這次推出的是 EdgeKV，目前還在 Beta 版：「Serverless Storage at the Edge (EdgeKV Beta)」。
如同名字所說的，架構上 Key-Value 架構，放棄了 CAP theorem 裡面的 C，改走 Eventual Consistency：
EdgeKV uses what is known in distributing computing as an eventual consistency model to perform writes and updates. This model achieves high availability with low read latency by propagating data writes globally. The period of time it takes the system to distribute data globally is called the “inconsistency window”.
隔壁 Cloudflare Workers KV 也是 Eventual Consistency (出自「How KV works」這邊)：
KV achieves this performance by being eventually-consistent. Changes are immediately visible in the edge location at which they're made, but may take up to 60 seconds to propagate to all other edge locations.
看起來算是補上競爭對手的產品線...
在 Hacker News 上看到的方式：「Which DNS」，另外在「Show HN: Which DNS servers are you pointing to? (nameserve.rs)」這邊也有一些討論。
這個方式是去抓 DNS server 對外的 IP，像 HiNet 的 168.95.1.1 這種 DNS server 後面都有一堆 resolver，這個方式可以知道出去的 IP 是哪個，可以幫助分析 routing 之類的問題...
記得 Akamai 有類似的服務，不過查了一下沒找到之前有印象的那個，反倒是查到另外一組可以用的：「Introducing a New whoami Tool for DNS Resolver Information」。
最近剛好跟朋友有聊到 1.1.1.1，然後就有提到我不推薦使用 1.1.1.1 的原因。
主要是因為 Cloudflare 以隱私的理由所以不打算支援 EDNS Client Subnet (ECS)，而 ECS 這項技術可以把 client 的 subnet 資訊帶給 DNS server，讓 DNS server 可以配出更精準的伺服器，而關於 Cloudflare 不支援的這點，可以在「1.1.1.1 supports ECS?」這邊看到一些討論。
這個問題在 Akamai 這種超大 CDN，在同一個地區的各 ISP 都有伺服器的情況下特別明顯。
以我家第四台的 cable 線路來說 (我的備用線路)，是走亞太 (APOL) 的線路出去，如果從自己的 ISP 查 www.akamai.com 的位置，可以查到 23.76.81.151，用 mtr 可以發現是走到 EBIX (也是亞太) 裡面的伺服器：
gslin@rpi3p [~] [13:35] host www.akamai.com www.akamai.com is an alias for www.akamai.comv2.edgekey.net. www.akamai.comv2.edgekey.net is an alias for e1699.dscx.akamaiedge.net. e1699.dscx.akamaiedge.net has address 23.76.81.151 e1699.dscx.akamaiedge.net has IPv6 address 2600:1417:76:594::6a3 e1699.dscx.akamaiedge.net has IPv6 address 2600:1417:76:58a::6a3 gslin@rpi3p [~] [13:35] mtr -w 23.76.81.151 Start: 2020-04-05T13:35:49+0000 HOST: rpi3p Loss% Snt Last Avg Best Wrst StDev 1.|-- unknown 0.0% 10 0.5 0.5 0.4 0.6 0.0 2.|-- NK219-91-13-254.adsl.dynamic.apol.com.tw 0.0% 10 7.8 8.2 6.1 11.9 1.7 3.|-- 10.251.11.6 0.0% 10 19.3 25.6 19.3 33.5 4.7 4.|-- 10.251.231.5 0.0% 10 25.4 23.4 19.8 29.1 3.7 5.|-- 10.251.231.1 0.0% 10 8.0 10.7 5.7 24.0 5.7 6.|-- 10.251.230.34 0.0% 10 26.6 20.6 5.9 110.0 32.1 7.|-- 10.251.230.29 0.0% 10 58.4 35.4 6.6 81.2 30.9 8.|-- 202-178-245-162.cm.static.apol.com.tw 0.0% 10 9.5 18.4 7.4 78.5 21.3 9.|-- 203-79-250-201.static.apol.com.tw 0.0% 10 8.5 8.2 6.4 9.8 1.0 10.|-- 211.76.96.191 0.0% 10 7.2 10.2 6.7 15.6 2.7 11.|-- 203-79-254-10.ebix.net.tw 0.0% 10 2226. 3802. 2226. 6017. 1314.6 12.|-- a23-76-81-151.deploy.static.akamaitechnologies.com 0.0% 10 6.4 9.4 6.3 16.4 3.3
但如果從 1.1.1.1 查，會查到在中華電信內的 Akamai 伺服器，於是在尖峰時間反而變得很慢：
gslin@rpi3p [~] [13:36] host www.akamai.com 1.1.1.1 Using domain server: Name: 1.1.1.1 Address: 1.1.1.1#53 Aliases: www.akamai.com is an alias for www.akamai.comv2.edgekey.net. www.akamai.comv2.edgekey.net is an alias for e1699.dscx.akamaiedge.net. e1699.dscx.akamaiedge.net has address 23.48.142.132 e1699.dscx.akamaiedge.net has IPv6 address 2001:b034:1:1ea7::6a3 e1699.dscx.akamaiedge.net has IPv6 address 2001:b034:1:1e9f::6a3 gslin@rpi3p [~] [13:39] mtr -w 23.48.142.132 Start: 2020-04-05T13:39:42+0000 HOST: rpi3p Loss% Snt Last Avg Best Wrst StDev 1.|-- unknown 0.0% 10 0.4 0.5 0.4 0.6 0.1 2.|-- NK219-91-13-254.adsl.dynamic.apol.com.tw 0.0% 10 8.7 17.0 6.1 81.2 22.8 3.|-- 10.251.11.6 0.0% 10 26.7 24.6 21.4 29.3 2.8 4.|-- 10.251.231.5 0.0% 10 26.8 29.9 16.8 88.6 21.0 5.|-- 10.251.231.1 0.0% 10 7.2 8.3 6.8 12.7 1.8 6.|-- 10.251.230.34 0.0% 10 10.3 8.9 5.9 11.0 1.6 7.|-- 10.251.230.29 0.0% 10 6.3 10.1 5.4 31.7 7.8 8.|-- 202-178-245-162.cm.static.apol.com.tw 0.0% 10 8.8 9.1 7.3 13.2 1.8 9.|-- 203-79-250-209.static.apol.com.tw 0.0% 10 10.0 8.6 6.3 10.8 1.5 10.|-- 211.76.96.67 0.0% 10 7.9 9.0 4.0 12.4 2.6 11.|-- 109-84-21-113-static.chief.net.tw 0.0% 10 18.3 11.7 7.0 25.1 5.7 12.|-- 21-252-123-103-static.chief.net.tw 0.0% 10 9.4 10.0 7.7 15.0 2.2 13.|-- 203-75-228-5.HINET-IP.hinet.net 0.0% 10 10.1 10.8 7.0 21.2 4.3 14.|-- r4209-s2.hinet.net 0.0% 10 9.4 10.5 6.3 17.9 3.7 15.|-- tpdt-3012.hinet.net 0.0% 10 92.0 61.6 11.1 141.6 53.8 16.|-- tpdt-3301.hinet.net 0.0% 10 42.9 38.8 7.3 100.8 33.6 17.|-- a23-48-142-132.deploy.static.akamaitechnologies.com 0.0% 10 8.2 15.5 8.2 46.6 12.4
跨 ISP 的線路品質通常都沒有同一個 ISP 內來的好，但因為沒有 EDNS Client Subnet (ECS) 的資訊，所以只能導去當地 (地理上) 預設的點，latency 應該還是夠低，但頻寬就未必足夠了。
用 8.8.8.8 會好一點，但目前最建議的還是用 ISP 自家的 DNS resolver，當 ISP 的 DNS Resolver 不支援 EDNS Client Subnet 時，CDN 也還是會正確讀到 ISP 的資訊，配到的伺服器的頻寬就不會太差...
在朋友的 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 在 2/28 遭受 DDoS 攻擊，蠻快就把事故報告丟出來了：「February 28th DDoS Incident Report」。
不過跟 GitHub 其他文章不太一樣，這篇算是 PR 稿吧，簡單來說就是花錢買 Akamai Prolexic 的過濾服務解決... Akamai 方的 PR 稿則是在「Memcached-fueled 1.3 Tbps attacks - The Akamai Blog」這邊可以看到。
17:21 UTC 發現問題，然後判斷超過 100Gbps，所以 17:26 決定讓 Akamai Prolexic 接管過濾：
At 17:21 UTC our network monitoring system detected an anomaly in the ratio of ingress to egress traffic and notified the on-call engineer and others in our chat system. This graph shows inbound versus outbound throughput over transit links:
Given the increase in inbound transit bandwidth to over 100Gbps in one of our facilities, the decision was made to move traffic to Akamai, who could help provide additional edge network capacity. At 17:26 UTC the command was initiated via our ChatOps tooling to withdraw BGP announcements over transit providers and announce AS36459 exclusively over our links to Akamai. Routes reconverged in the next few minutes and access control lists mitigated the attack at their border. Monitoring of transit bandwidth levels and load balancer response codes indicated a full recovery at 17:30 UTC. At 17:34 UTC routes to internet exchanges were withdrawn as a follow-up to shift an additional 40Gbps away from our edge.
就這樣而已，完全就是 PR 稿 XDDD
