Cloudflare 看這次 815 斷電的網路使用變化

Cloudflare 分析了這次 815 停電對網路造成的影響:「Power outage hits the island of Taiwan. Here’s what we learned.」。

以 Cloudflare 在是方機房的 QPS 來看,停電後反而沒有太大變化:

把裝置種類拆開來看,可以看到桌機的使用量下降,但手機的使用量上升:

這點從 HiNet 的使用頻寬也可以看出來,頻寬使用量降了 25% (從光世代與 ADSL/VDSL 換到行動網路上?):

Backblaze B2 的降價...

Backblaze B2 是個 cloud storage 服務 (類似於 Amazon S3),最近宣布降價:「Backblaze B2 Drops Download Price By 60%」。

這次降價是降流量的部分,從 USD$0.05/GB 降到 USD$0.02/GB。參考去年的價錢:「Cheapest Secure Cloud Storage Provider: B2」。

不知道可以傳多快,另外是工具的豐富度比 S3 還是差不少 :o

Linode 推出 $5/month 方案,DigitalOcean 推出 load balancer

LinodeDigitalOcean 這兩家有名的 VPS 都推出新的功能:「High-Memory Instances and $5 Linodes」、「Load Balancers: Simplifying High Availability」。

Linode 另外將 $10/month 方案的硬碟空間加大:

And finally, the existing Linode 2GB ($10/mo) plan is receiving a free storage upgrade from 24GiB to 30GiB.

本來對外的速度限制在 125Mbps max 拉到 1000Mbps:(本來的資料可以參考之前的頁面)

And finally finally, we’ve also increased the outbound network speed limit on all plans to be at minimum 1000 Mbits. Existing Linodes will need to reboot to pick up the new value, that’s it!

Google Play Store 將支援 Brotli 壓縮

在「Intern Impact: Brotli compression for Play Store app downloads」這邊介紹了 Google Play Store 引入 Brotli 的情況。

選擇 Brotli 除了是 Google 自家研發出來的東西以外,另外是考量到 Brotli 的壓縮與解壓縮速 (尤其是後者) 不會增加太多,卻可以多出不少壓縮率。維基百科這邊說明的是文字的部份:

Replacing deflate with brotli typically gives an increase of 20% in compression density for text files, while compression and decompression speeds are roughly unchanged.

不過實際在 Google Play Store 上測試 binary 的效果也不錯:

當然,如同之前提到的「Google 再次改善 Android 的 APK 更新,讓下載的量更小」,在去年 12 月時 Google 對於背景更新的下載 File-by-File 的更新來降低流量 (但在手機上會需要大量的 CPU 資源計算,不過因為是背景 idle 時跑而不會影響使用者,所以被採用),透過這兩個改善互相搭配繼續壓低流量。

在接下來的幾個禮拜會生效:

Brotli compression for app downloads is rolling out now, and users should start to enjoy the benefits over the coming weeks.

Amazon Lightsail:AWS 的 VPS 服務

所以 AWS 決定也跳進來搞 VPS 服務了?推出了 Amazon Lightsail:「Amazon Lightsail – The Power of AWS, the Simplicity of a VPS」。

定價策略就跟 VPS 一樣:

如果你熟悉數字的話,這其實跟 DigitalOcean 的規格與價錢一模一樣 (參考「Pricing on DigitalOcean」這頁),連備份的 USD$0.05/GB/month 也相同。目前雖然只有 us-east-1 有,但看起來複製並不難...

FAQ 裡有提到可以透過 VPC peering 連進 AWS:

You can connect your Lightsail instances to VPC resources in your AWS account privately, by using VPC peering. Just choose Enable VPC peering on your Lightsail account page, and Lightsail does the work for you. Once VPC peering is enabled, you can address other AWS resources in your default AWS VPC by using their private IPs.

有趣的是,這個頻寬費用超級便宜... 目前比較不確定的是 bandwidth 是不是 pool-based (沒用完的流量可以挪到其他機器上用),另外這邊的頻寬計算方式是不是算 us-east-1 內?

這個方案好有趣...

Amazon EC2 推出 m4.16xlarge

Amazon EC2m4 系列推出更大台的機器,m4.16xlarge:「Expanding the M4 Instance Type – New M4.16xlarge」。

先前 m4 最大的是是 m4.10xlarge,現在則是往上拉... 比較特別的是這款機器可以吃到 20Gbps (跟之前出的 x1.32xlarge 相同),更早推出的 m4.10xlarge,以及 {c4,c3,g2,r3,i2,d2}.8xlarge 都只能吃到 10Gbps。

選擇會更活一點... 不過到這個等級的應用應該都規劃過 scale 架構才對?雖然也是有可能有那種買來的 application 啦...

Google 研發出的 BBR: Congestion-Based Congestion Control

Google 針對 TCP 的 congestion control 研究出了新的方法,是個純 sender-side 的演匴法,可以讓現有的 internet 直接換上去使用:「[net-next,14/14] tcp_bbr: add BBR congestion control」。

在 long-lived TCP connection 愈來愈普及後 (像是 HTTP/2),TCP 連線的最佳化可以用統計模型來計算,這也就是 BBR 的想法:

In a nutshell, BBR creates an explicit model of the network pipe by sequentially probing the bottleneck bandwidth and RTT. On the arrival of each ACK, BBR derives the current delivery rate of the last round trip, and feeds it through a windowed max-filter to estimate the bottleneck bandwidth. Conversely it uses a windowed min-filter to estimate the round trip propagation delay. The max-filtered bandwidth and min-filtered RTT estimates form BBR's model of the network pipe.

不過 QUIC 不是也開始有進展了嗎?(參考「Google Chrome 52 預設開啟了更快的 QUIC (被戲稱為 TCP/2)」這篇)

感覺 QUIC 解決的比較徹底,不過 443/udp 的 firewall 問題的確也是個需要時間解決的課題...

印度 ISP 跟 Torrent 站台合作加速下載

在「Indian ISPs Speed Up BitTorrent by ‘Peering’ With a Torrent Site」這篇講到印度的 ISP 跟 torrent 站台 TorBox 合作,加速下載的速度。

裡面提到了蠻有趣的加速技巧:

They help users to download content faster by linking them to local peers in their own network.

不知道是不是指 Local Peer Discovery (BEP-14) 的技術,如果是的話大概可以猜出作法... 這樣可以降低不少 ISP 對外頻寬的流量與成本。

CloudFlare 對 HiNet 成本的抱怨 (還有其他 ISP...)

CloudFlare 特地寫了一篇討拍文在分析對六個 ISP 的超高成本:「Bandwidth Costs Around the World」。

其他的就不講了,先看對價錢的定義:

As a benchmark, let's assume the cost of transit in Europe and North America is 10 units (per Mbps).

然後來看亞洲區以及 HiNet 的部份寫了什麼:

Two Asian locations stand out as being especially expensive: Seoul and Taipei. In these markets, with powerful incumbents (Korea Telecom and HiNet), transit costs 15x as much as in Europe or North America, or 150 units.

成本大約是 15 倍。另外說明這六個 ISP 佔了他們 50% 的頻寬成本 (以及 6% 的流量):

Today, however, there are six expensive networks (HiNet, Korea Telecom, Optus, Telecom Argentina, Telefonica, Telstra) that are more than an order of magnitude more expensive than other bandwidth providers around the globe and refuse to discuss local peering relationships. To give you a sense, these six networks represent less than 6% of the traffic but nearly 50% of our bandwidth costs.

為什麼有種濃濃的既視感 XDDD

愈來愈吃資源的影音廣告 (VPAID)

作者提到了現在的影音廣告愈來愈誇張:「A few months ago, I brought to light the insane state of today's advertising...」。

作者放了一個空白頁面,裡面只放了一個影音廣告,然後打開後發現,光是一個影音廣告就會產生 5559 個連線 (喂喂) 與 53MB 的流量,而且還會無止盡的成長 (不會停,會一直讀取新的廣告):

To showcase just how evil they still are, I took a single AdX ad tag and put it on an otherwise empty page. A static image ad loads, but it's secretly a VPAID one. It then randomly switches to a video, then back to a static image, then back again - it's like a never-ending self-reloading cascade of garbage.

Right now after several minutes of just leaving this one single ad open, I'm at 53MB downloaded and 5559 requests. By the time I finished typing this, I was at 6140 requests. A single ad did this. Without reloading the page, just leaving it open.

作者把過程錄了下來,好慘啊...: