cache

Google Chrome 要藉由拆開 HTTP Cache 提昇隱私

在「Prepare For Fewer Cache Hits As Chrome Partitions Their HTTP Cache」這邊看到的，Google Chrome 打算要拆開 HTTP Cache 以提昇安全性與隱私性。

有 cache 跟沒有 cache 可以從讀取時間猜測出來，這樣就可以知道瀏覽器是否有這個特定 url 的 cache。

在原文的作者所給的例子沒有這麼明顯，這邊舉個實際一點的例子來說好了... 我想要知道你有沒有看過 zonble 的「返校」這篇文章，我就拿這篇文章裡面特有的資源來判斷。

以這篇文章來說，我可以選擇第一張圖片的網址 https://i0.wp.com/c1.staticflickr.com/1/603/31746363443_3c4f33ab18_n.jpg?resize=320%2C200&ssl=1 這個 url 來判斷讀取時間，藉此我就可以反推你有沒有看過這篇文章，達到攻擊隱私的效果。

解決的方法就是作者文章裡所提到的方法，把 HTTP cache 依照不同的網站而分開 (在 Safari 已經支援這個功能，而 Firefox 正在研究中)。

當然這樣做應該會對流量有些影響，但考慮到這些日子有很多新技術可以增加下載速度，這個功能應該是還能做...

StackOverflow 講 cache 的文章...

這篇是 StackOverflow 在講 cache 的文章，裡面不是什麼新東西，只是看到有趣的項目所以拿出來講：「How Stack Overflow Caches Apps for a Multi-Tenant Architecture」。

在講 cache 前通常都會說明各種儲存空間速度的差異，但裡面混了一個奇怪的東西：

L1: 1.3ns
L2: 3.92ns (3x slower)
L3: 11.11ns (8.5x slower)
DDR4 RAM: 100ns (77x slower)
NVMe SSD: 120,000ns (92,307x slower)
SATA/SAS SSD: 400,000ns (307,692x slower)
Rotational HDD: 2–6ms (1,538,461x slower)
Microsoft Live Login: 12 redirects and 5s (3,846,153,846x slower, approximately)

裡面混了一個不是 storage 的東西進去比較，你們是對 Microsoft 的帳號系統有多不爽 XDDD

另外他們列出了目前 Redis 的使用情況：

For the curious, some quick stats from last Tuesday (2019-07-30) This is across all instances on the primary boxes (because we split them up for organization, not performance…one instance could handle everything we do quite easily):
Our Redis physical servers have 256GB of memory, but less than 96GB used.
1,586,553,473 commands processed per day (3,726,580,897 commands and 86,982 per second peak across all instances – due to replicas)
Average of 2.01% CPU utilization (3.04% peak) for the entire server (< 1% even for the most active instance)
124,415,398 active keys (422,818,481 including replicas)
Those numbers are across 308,065,226 HTTP hits (64,717,337 of which were question pages)

然後更長的版本可以在作者自己的 blog 上讀到，裡面講到的 cache invalidate (purge) 這部份有談到一些他們的作法：「Stack Overflow: How We Do App Caching - 2019 Edition」。

補上 nginx 對 favicon 的壓縮...

從「Compressed favicons are 70% smaller but 75% of them are served uncompressed」這邊看到的，他們發現大約有 73.5% 的網站沒有壓縮 favicon.ico 檔：

The HTTP Archive dataset of favicons from 4 million websites crawled from desktop devices on May 2019 shows that 73,5 % of all favicons are offered without any compression with an average file size of 10,5 kiB, 21,5 % are offered with Gzip compression at an average file size of 4 kiB, and 5 % offer Brotli compression at an average file size of 3 kiB.

我自己的也沒加... 補上 gzip 相關的設定後，favicon.ico 的傳輸量從 4.2KB 降到 1.2KB。

我是使用 nginx，在 Ubuntu 上 nginx 的 nginx.conf 內 gzip 預設已經有開，所以只要增加一些設定讓他知道要處理 ico 檔案就可以了。

方法是在 /etc/nginx/conf.d/gzip.conf 裡面放：

gzip_comp_level 9;
gzip_types image/vnd.microsoft.icon image/x-icon;
gzip_vary on;

跟文章裡面提到的多了兩個設定，一個是 gzip_comp_level 改成 9 (預設是 1)，另外有 gzip 時應該要在 Vary 表示，避免 cache 出錯。

Cloudflare 改善了同時下載同一個檔案的效率...

在「Live video just got more live: Introducing Concurrent Streaming Acceleration」這邊 Cloudflare 說明他們改善了同時下載同一個 cache-miss 檔案時的效率。

本來的架構在 cache-miss 時，CDN 這端會先取得 exclusive lock，然後到 origin server 抓檔案。如果這時候有其他人也要抓同一個檔案，就會先卡住，避免同時間對 origin server 產生大量連線：

這個架構在一般的情況下其實還 ok，就算是 Windows Update 這種等級的量，畢竟就是一次性的情況而已。但對於現代愈來愈普及的 HTTP(S) streaming 技術來說，因為檔案一直產生，這就會是常常遇到的問題了。

由於 lock 機制增加了不少延遲，所以在使用者端就需要多抓一些緩衝時間才能確保品質，這增加了直播的互動延遲，所以 Cloudflare 改善了這個部分，讓所有人都可以同時下載，而非等到發起的使用者下載完才能下載：

沒有太多意外的，從 Cloudflare 內部數字可以看出來這讓 lock 時間大幅下降，對於使用者來說也大幅降低了 TTFB (time to first byte)：

不確定其他家的情況...

Backblaze 與 Cloudflare 合作，免除傳輸費用

先前知道不少單位會選擇用 CloudFront 的原因就是 S3 到 CloudFront 這段是不需要傳輸費用的。畢竟 CDN 的 hit rate 還是有限，用其他家 CDN 得付這塊費用。

而現在 Backblaze 宣佈跟 Cloudflare 合作，免除掉 Backblaze 到 Cloudflare 的費用：「Backblaze and Cloudflare Partner to Provide Free Data Transfer」。

Today we are announcing that beginning immediately, Backblaze B2 customers will be able to download data stored in B2 to Cloudflare for zero transfer fees.

AWS 這邊會不會有其他動作呢...

Python 3 內建的 lru_cache...

Twitter 上看到 Python 3 內建的 lru_cache()：

One of my favorite Python 3 builtins is functools.lru_cache(): with a simple decorator, repeated function calls become O(1) table lookups. https://t.co/ORphGWvkCz pic.twitter.com/NmYVIxO9mE
— Jake VanderPlas (@jakevdp) August 8, 2018

從文件上可以看到預設值是 128 個：

@functools.lru_cache(maxsize=128, typed=False)

tweet 裡面有討論到 memory leak 的問題可以看一下，不過如果是拿來寫工具的話，應該不會有什麼問題...

ALB 支援 Slow Start 了

這個功能在 ELB Classic 年代時有跟 AWS 提過，到 ALB 支援了 (總算...)：「Application Load Balancer Announces Slow Start Support for its Load Balancing Algorithm」。

Application Load Balancers now support a slow start mode that allows you to add new targets without overwhelming them with a flood of requests. With the slow start mode, targets warm up before accepting their fair share of requests based on a ramp-up period that you specify.

然後時間可以設定，從 30 秒到 15 分鐘：

Slow start mode can be enabled by target group and can be configured for a duration of 30 seconds to 15 minutes. The load balancer linearly increases the number of requests sent to a new target in a target group up to its fair share during the slow start ramp-up window.

就之前的經驗來說，這在跑 PHP 的時候會很需要這個功能 (之前是在 F5 的設備上設定)。其他的語言因為性質不太一樣，可能不會這麼吃這個功能。

主要是因為 PHP 是在 request 進來時 compile 並且 cache。所以在機器剛起來時，儘量將 CPU 留給 opcache，把常用的頁面 compile 完並且放進 cache，而不是讓大量的連線灌進來，這樣對使用體驗不會太好... (要避免 CPU 吃滿 100% 很久，造成每個連線都很慢才跑完)

AWS 推出 Slow Start 後對 auto scaling 時的順暢度會好不少...

透過 memcached UDP (Port 11211) 的攻擊...

Cloudflare 發表了一篇關於公開的 memcached 伺服器，利用 UDP (Port 11211) 的放大攻擊：「Memcrashed - Major amplification attacks from UDP port 11211」。

用地圖展示後可以清楚看出來哪些區域受到的攻擊比較大：

另外 Shodan 上的資料頁可以參考，不過就不保證都有開 UDP/11211 了：

這種伺服器還是藏到內部網路啦...

Netflix 在 Time Series Data Storage 上的努力...

在「Scaling Time Series Data Storage — Part I」這篇看到 Netflix 在 Time Series Data Storage 上所做的努力...

因為應用在寫多讀少的場景，所以選擇使用 Cassandra，遇到瓶頸後把常寫入的與不太會改變的拆開儲存，並且用不同方式最佳化。包括了 cache 與 compression 都拿出來用了...

不知道他們內部有沒有評估 ScyllaDB 的想法...

Working Set Size (WSS) 的想法

Netflix 的 Brendan Gregg (他比較知名的發明是 Flame Graph) 寫了一篇「How To Measure the Working Set Size on Linux」，他想要量測單位時間內會用到的記憶體區塊大小：

The Working Set Size (WSS) is how much memory an application needs to keep working. Your app may have populated 100 Gbytes of main memory, but only uses 50 Mbytes each second to do its job. That's the working set size. It is used for capacity planning and scalability analysis.

這可以拿來分析這些應用程式是否能夠利用 L1/L2/L3 cache 大幅增加執行速度，於是就可以做成圖，像是這樣：

在 Netflix 這樣人數的公司，需要設計一些有用的指標，另外發展出對應的工具，讓其他人更容易迅速掌握狀況，畢竟不是每個人都有上天下海的能力，遇到狀況可以馬上有頭緒進行 trouble shooting...