Home » Posts tagged "google"

Mozilla 跟 Google 都宣佈了 TLS 1.0 與 TLS 1.1 的退役計畫

UpdateApple 也宣佈了,時間點跟大家都差不多:「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+,就要看各網站或是服務的族群了...

把 Google 服務拔乾淨的 Chromium

有人試著把 Chromium 裡的 Google 相關服務都拔乾淨,叫做 ungoogled-chromium

Modifications to Google Chromium for removing Google integration and enhancing privacy, control, and transparency

有提供志願者包好的 pre-built binary,但看了一下版本有點舊,而且不能確定裡面有沒有什麼加料... 要用的人可能還是要考慮自己編一包出來。

在「Add a PPA or APT repo」這邊有人在討論要怎麼包 PPA 出來,不過看起來卡關了...

Cloudflare 決定支援 QUIC

Cloudflare 決定支援 QUIC 了:「Get a head start with QUIC」、「The QUICening」。

QUIC 目前被使用的範圍比較小 (相較於 HTTP/2):

  • 主流瀏覽器內只有 Google Chrome 有支援 QUIC,其他主流瀏覽器都沒有支援。不過 Google Chrome 也夠大了...
  • 因為是走 UDP,所以防火牆要另外開。

而 Google Chrome 上面可以安裝「HTTP/2 and SPDY indicator」看到連線的狀態。雖然套件名稱沒有 QUIC,但實際上是可以看出 QUIC 的,基本上 Google 的服務應該都是走 QUIC。

各家 Serverless 服務冷啟動 (Cold Start) 的時間

看到「Serverless: Cold Start War」這篇分析了 AWS LambdaAzure FunctionsGoogle Cloud Functions 的冷啟動特性。

裡面分析了多久沒有 request 會需要冷啟動、記憶體的大小對於冷啟動速度的影響、程式語言的影響,以及程式大小的影響。

對於量很少,但是又很在意速度的人來說也許可以研究一下。不過只要有點量 (就算一分鐘只有一次) 應該都不會遇到這塊問題...

Chrome 把所謂的「trivial subdomain」移除後有人爆氣了...

先前在「關閉新版 Google Chrome 網址列雞婆省略 www 的行為...」提到 Google Chromewww 這些常見的 subdomain 從顯示列上移除的事情。我是因為用 beta channel 所以比較快就開始抱怨,而一般使用者在這幾天 stable channel 更新後開始收到這樣的改變,於是就爆炸了:「Incorrect transforms when stripping subdomains」。

有人直接噴這是什麼鳥蛋決策 XDDD

I actually thought Chrome was malfunctioning. This decision seems totally arbitrary. Was there any research done to justify this decision, or was it the whimsy of a PM who thought it would be a cool UX thing?

另外有人問 Google 是不是應該去開個 CVE,直接認定是安全性威脅... XD

然後一如往常的,被打上 Restrict-AddIssueComment-EditIssue 不讓其他人加意見進去了... 大概不會有下文了 XD

話說回來,這幾天測 Firefox 發現頗吃 CPU 與 GPU 的效能 (相較於 Google Chrome),實在換不過去...

又一個 TCP BBR 的測試結果

TCP BBRGoogle 發表的 TCP congestion control 演算法,是一個純伺服器端就能夠改善 TCP 壅塞處理的機制。在 Linux Kernel 4.9 之後被納入了。

Spotify 有大量資料要傳到使用者端 (像是音檔),剛好是 TCP BBR 改善的對象之一,實際測試後得到了很不錯的改善數據:「Smoother Streaming with BBR」。

Spotify 公佈的資料沒有提到平台,所以先稍微了解一下他的音質,也就是「Audio settings」這篇。

在 Desktop 是 160kbps/320kbps Ogg (Standard/HQ)。在 Web Player 則是 128kbps/256kbps AAC (Standard/HQ)。

行動平台部份比較複雜,在 iOS 上是 96kbps/160kbps/256kbps Ogg (Normal/High/Extreme),另外有 Automatic 自動調整的設定。在 Android 平台則是 24kbps HE-AACv2 (Low) 與 96kbps/160kbps/320kbps Ogg (Normal/High/Very high) 以及 Automatic。

而最後 Chromecast 則是 128kbps/256kbps (Standard/Premium)。

測試時可以發現 shutter (指跟不上播放速度) 的情況降低了 6%~10%,而且下載速度增加了 5%~7% (對於慢速的裝置改善更多,10%~15%):

Taking daily averages, stutter decreased 6-10% for the BBR group. Bandwidth increased by 10-15% for the slower download cohorts, and by 5-7% for the median. There was no difference in latency between groups.

而各地區的差異也可以看出來改善很多:

另外他們在測試時,剛好遇到秘魯的機房連外發生問題,結果意外發現 BBR 還是可以穩定在這種網路環境下運作:

In Peru, the non-BBR group saw a 400-500% increase in stutter. In the BBR group, stutter only increased 30-50%.

In this scenario, the BBR group had 4x bandwidth for slower downloads (the 10th percentile), 2x higher median bandwidth, and 5x less stutter!

Ubuntu 18.04 上可以直接設定 BBR,在 Ubuntu 16.04 則可以參考「Ubuntu 16.04 用 speedtest-cli 測試 TCP BBR 效能」這篇的方式升級 kernel 後設定 BBR。

Archives