幹壞事是進步最大的原動力
從 mailing list 收到 lighttpd 出新版的通知信，本來以為是 security fix，結果看了一下發現雖然版號是從 1.4.55 變到 1.4.56，但這個版本支援了 HTTP/2，以及 Brotli 壓縮：「Release-1 4 56 - Lighttpd - lighty labs」。
lighttpd 應該是我還在學校的時候幫 PIXNET 用的東西？他跑 FastCGI 模式接 PHP 當時效能還不錯... 現在自己架站的習慣是用 nginx 了。
反倒是他當年因為要更方便的支援 FastCGI 而生的 spawn-fcgi 讓 nginx 與其他專案沿用，後來是各家專案自己都原生支援 FastCGI 或是其他協定，所以重要性就淡了一些...
這次的更新推出的 HTTP/2 算是補上蠻重要的功能，不知道會對 lighttpd 社群帶來什麼能量...
CloudFront 宣佈支援 Brotli：「Amazon CloudFront announces support for Brotli compression」。
官方的說明發現 Gzip 可以好 24%：
CloudFront's Brotli edge compression delivers up to 24% smaller file sizes as compared to Gzip.
Akamai 在「Understanding Brotli's Potential」這邊提到的測試數字稍微做了分類，可以看到在 html 下 Brotli 帶來的改善是最多的。
以前在 CloudFront 上還是可以支援 Brotli，主要是透過後端支援 Brotli 的方式傳回不同的資料，再加上 Vary: Accept-Encoding 的設定讓 CloudFront 針對不同的 Accept-Encoding 分開 cache。
這次的支援等於是讓 CloudFront 理解 Brotli，就可以提昇 hit rate 並且降低後端的壓力：
Prior to today, you could enable Brotli compression at the origin by whitelisting the 'Accept-Encoding' header. Now CloudFront includes 'br' in the normalized 'Accept-Encoding' header before forwarding it to your origin. You no longer need to whitelist the 'Accept-Encoding' header to enable Brotli origin compression, improving your overall cache hit ratio. Additionally, if your origin sends uncompressed content to CloudFront, CloudFront can now automatically compress cacheable responses at the edge using Brotli.
算是補產品線...
在 Twitter 上看到有人提到 curl 支援 Brotli 了：「HTTP: implement Brotli content encoding」。
Brotli 對文字系列的資料比較有幫助 (像是 html)：
Unlike most general purpose compression algorithms, Brotli uses a pre-defined 120 kilobyte dictionary, in addition to the dynamically populated ("sliding window") dictionary. The pre-defined dictionary contains over 13000 common words, phrases and other substrings derived from a large corpus of text and HTML documents. Using a pre-defined dictionary has been shown to increase compression where a file mostly contains commonly-used words.
現在還在 master 裡面，之後的 release 版本應該就會支援了...
在「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.
Facebook 發了一篇出來，講 Zstandard：「Smaller and faster data compression with Zstandard」，可以看到：
如果與 Google 去年 open source 出來的 Brotli 相比，Zstandard 則是著重在速度，想要做出一個比 zlib 快很多但又比 zlib 壓的好的壓縮演算法。
之前有提過這件事情，由於 Firefox 已經支援 Brotli 了 (Google 推出 Brotli 無損壓縮法)，所以 CloudFlare 的人整理了目前的效能比較：「Results of experimenting with Brotli for dynamic web content」。
主要還是 Brotli 拿了不少資源來換壓縮率，對於 static content 由於可以事先算好而大勝不少 (大約可以再榨出 15% 的壓縮率，從 zlib 9 的 27.7% 降到 brotli 10 的 23.3%)：
The current state of Brotli gives us some mixed impressions. There is no yes/no answer to the question "Is Brotli better than gzip?". It definitely looks like a big win for static content compression, but on the web where the content is dynamic we also need to consider on-the-fly compression.
另外對於大檔案、網路速度不快的連線來說也頗有幫助，但對於 on-the-fly 的壓縮反而會比較慢。
Google 推出了 Brotli 這個無損壓縮法：「Introducing Brotli: a new compression algorithm for the internet」。
Google 推出的 Zopfli 相容於 DEFLATE 的超慢壓縮演算法，但可以多壓榨出 3%～8% 的壓縮率。而 Brotli 則是重新設計，壓縮與解壓縮速度跟 DEFLATE 差不多，但壓縮率比 Zopfli 多了 20%～26%。
This new format allows us to get 20–26% higher compression ratios over Zopfli. In our study ‘Comparison of Brotli, Deflate, Zopfli, LZMA, LZHAM and Bzip2 Compression Algorithms’ we show that Brotli is roughly as fast as zlib’s Deflate implementation.
由於目標是希望讓瀏覽器支援新的壓縮法，Google 把 Brotli 往 RFC 提案，試著變成公開標準：「Brotli Compressed Data Format」。
看了看 commit log，看起來已經開發一陣子了...