幹壞事是進步最大的原動力
看到一個 demo 展示瀏覽器內 CSS 的處理能力，看起來已經足夠到可以處理不少貼圖與光線效果的部分了：「CSS FPS」。
This is demo of a CSS powered 3D environment. Geometry is created with HTML elements and CSS transforms. Textures and lightmaps are composed by layering multiple background-images and colour is applied using CSS blend-modes.
不過遊戲應該會需要更多種類的效果，這部份目前應該還是得靠 javascript 來產生... (如果要在瀏覽器裡面跑)
AWS 宣佈 Lambda 支援 Ruby 2.5：「AWS Lambda Supports Ruby」。
另外宣佈可以透過 Layer 的方式讓任何程式語言在上面跑 (前面提到的 Ruby 看起來就是用這個方式支援的)：「New for AWS Lambda – Use Any Programming Language and Share Common Components」。
The Runtime API is the future of how we’ll support new languages in Lambda. For example, this is how we built support for the Ruby language.
Cloudflare 算是很早就參與 TLS 1.3 發展的廠商。在參與過程中他們希望讓支援 TLS 1.3 draft 的瀏覽器可以開始使用 TLS 1.3 draft，但又不希望因為 draft 頻繁修改而導致本來的使用者受到影響，所以就找了方法讓兩者並存：「Know your SCM_RIGHTS」。
這個方法就是 SCM_RIGHTS，可以讓另外一個 process 存取自己的 file description。
You can use UNIX-domain sockets to pass file descriptors between applications, and like everything else in UNIX connections are files.
所以他們的作法就是先讀取 TLS 裡 Client Hello 的資料，如果裡面有看到想要使用 TLS 1.3 的訊息，就透過前面提到的 SCM_RIGHTS 丟進 Golang 寫的程式跑：
We let OpenSSL read the “Client Hello” message from an established TCP connection. If the “Client Hello” indicated TLS version 1.3, we would use SCM_RIGHTS to send it to the Go process. The Go process would in turn try to parse the rest of the “Client Hello”, if it were successful it would proceed with TLS 1.3 connection, and upon failure it would give the file descriptor back to OpenSSL, to handle regularly.
這樣本來的 stack 就只要修改一小段程式碼，將當時還很頻繁修改的 TLS 1.3 draft 丟到另外一個 process 跑，就比較不用擔心本來的 stack 會有狀況了。
看到 wagoodman/dive 這個工具，只要給 Docker 的 image 與 tag 資訊，就可以看每一層裡面的內容：
安裝上也有提供各平台的套件包 (deb、rpm 之類的)。操作的熱鍵在首頁的下方也有提供，用起來很方便。
Update：Apple 也宣佈了，時間點跟大家都差不多：「Deprecation of Legacy TLS 1.0 and 1.1 Versions」。
Mozilla 宣佈了「Removing Old Versions of TLS」，而 Google 也宣佈了「Modernizing Transport Security」，兩篇都是講自家瀏覽器 TLS 1.0 與 TLS 1.1 的退役時程。
Mozilla 這邊的計畫是 2020 年三月移除：
In March of 2020, Firefox will disable support for TLS 1.0 and TLS 1.1.
Google 這邊的計畫則是 Chrome 81 移除，換算成時間會從 2020 年一月開始影響到 canary channel，到 release channel 應該跟 Firefox 差不多時間：
In line with these industry standards, Google Chrome will deprecate TLS 1.0 and TLS 1.1 in Chrome 72. Sites using these versions will begin to see deprecation warnings in the DevTools console in that release. TLS 1.0 and 1.1 will be disabled altogether in Chrome 81. This will affect users on early release channels starting January 2020.
差不多試從現在開始的一年半。
雖然這是講瀏覽器端的支援，但如果伺服器想要只支援 TLS 1.2+ 的話，就得考慮一下舊 client 支援的情況了。
桌機影響會比較小 (升級比較方便，替代方案也比較多)，而行動平台看起來需要 Android 4.4+、iOS 7+，就要看各網站或是服務的族群了...
EFF 的「Transport-Layer Encryption vs End-to-End Encryption - GIF」這篇文章介紹了 Transport-Layer Encryption 與 End-to-End Encryption 的差異，最後還給了一張 GIF 說明：
其實 GIF 給的範例還蠻清楚的，在 Transport-Layer Encryption 中服務提供商可以看到原始內容 (以 GIF 內提到的例子就是 Google)，而在 End-to-End Encryption 中就不行，只有傳輸雙方可以知道原始內容。
然後文章裡也提到了 Tor Messenger，可以吃現有的通訊軟體，然後在上面疊出 End-to-End Encryption。
Reddit 說明了他們如何處理 pageview：「View Counting at Reddit」。
以 Reddit 的規模有提到兩個重點，第一個在善用 Redis 的 HyperLogLog 這個資料結構，當量大的時候其實可以允許有微小的誤差：
The amount of memory varies per implementation, but in the case of this implementation, we could count over 1 million IDs using just 12 kilobytes of space, which would be 0.15% of the original space usage!
維基百科上有說明當資料量在 109 這個等級時，用 1.5KB 的記憶體只有 2% 的誤差值：
The HyperLogLog algorithm is able to estimate cardinalities of > 109 with a typical error rate of 2%, using 1.5 kB of memory.
第二個則是寫入允許短時間的誤差 (pageview 不會即時反應)，透過批次處理降低對 Cassandra cluster 的負荷：
Writes to Cassandra are batched in 10-second groups per post in order to avoid overloading the cluster.
可以注意到把 Redis 當作 cache 層而非 storage 層。
主要原因應該跟 Redis 定位是 data structure server 而非 data structure storage 有關 (可以從對 Durability 的作法看出來)，而使用 Cassandra 存 key-value 非常容易 scale，但讀取很慢。剛好兩個相輔相成。
在「How eBay’s Shopping Cart used compression techniques to solve network I/O bottlenecks」這邊 eBay 描述了他們怎麼解決在 MongoDB 上遇到的問題，不過我看的是他們怎麼用 MongoDB，而不是這次解決的問題：
It’s easier to think of the MongoDB layer as a “cache” and the Oracle store as the persistent copy. If there’s a cache miss (that is, missing data in MongoDB), the services fall back to recover the data from Oracle and make further downstream calls to recompute the cart.
把 MongoDB 當作 cache layer，當 cache miss 的時候還是會回去底層的 Oracle 撈資料計算，這用法頗有趣的...
不拿 memcached 出來用的原因不知道是為什麼，是要找個有 HA 方案的 cache layer 嗎？還是有針對 JSON document 做判斷操作？
Stripe 在宣佈要淘汰 TLS 1.0 與 TLS 1.1 的計畫公告中 (「Upgrading to SHA-2 and TLS 1.2」) 提到了：
Why SHA-1, TLS 1.0 and 1.1 are insecure
但在文章裡面還是沒有提到為什麼 TLS 1.1 不安全。
在維基百科的「Transport Layer Security」條目中試著找內容，發現應該是 Data integrity 這段，TLS 1.1 不支援 HMAC-SHA256/384 與 AEAD，只支援比較弱的 HMAC-MD5 或是 HMAC-SHA1。