Tag: application

IE11 的淘汰計畫

微軟宣佈了淘汰 IE11 的計畫：「The future of Internet Explorer on Windows 10 is in Microsoft Edge」。

標題上方的說明先把重點提出來了：

The Internet Explorer 11 desktop application will be retired on June 15, 2022

不過要注意，Windows 10 LTSC 與 server 版的日期不在這次公告的範圍：

Note: This retirement does not affect in-market Windows 10 LTSC or Server Internet Explorer 11 desktop applications. It also does not affect the MSHTML (Trident) engine. For a full list of what is in scope for this announcement, and for other technical questions, please see our FAQ.

在 FAQ 裡面看起來 Windows 10 LTSC 與 Server 版應該會照著本身作業系統的維護週期走。

另外在文章裡也有提到 Microsoft 365 產品線只支援到今年八月 17 日 (文字部份出自維基百科的「Internet Explorer 11」)：

On August 17, 2020, Microsoft published a timeline indicating that the Microsoft Teams product will stop supporting Internet Explorer 11 on November 30, 2020, and Microsoft 365 products will end Internet Explorer 11 support on August 17, 2021.

對一般使用上影響應該不會太大，因為目前市占率的關係，一般網站使用 Chromium 為底的瀏覽器應該都會動，主要的影響應該是遇到一些古董系統，一定得用 IE 才能使用。

ALB 支援 Sticky Session

又是一個以為很久前就已經支援，但實際上沒支援的功能...

ALB 支援使用 cookie 實現 sticky session 功能：「Application Load Balancer now supports Application Cookie Stickiness」。

使用者的 session 通常會使用 cookie 記錄，而如果有多台 server 提供服務時，session 裡的資訊就需要找一個 shared session storage 放，以確保使用者在連到不同的 server 時都還是可以讀到對應的 session，比較傳統的方案就是直接把 session 塞進資料庫，後來發展出 memcached 或是 Redis 可以用。

但有些買來的軟體並沒有考慮到這點 (常常都是內部系統)，導致前面放 load balancer 時，必須想個辦法記錄使用者使用後端的哪台機器，這樣就可以在後端不支援 shared session storage 的情況下，還是可以讓應用正常運作。

透過 cookie 實做的 sticky session 算是蠻常見的作法，只是以為早就有了...

cURL 支援 Zstandard

在「curl 7.72.0 – more compression」這邊看到新版的 cURL 要支援 Zstandard 了，查了一下發現 Zstandard 有對應的 RFC，在 RFC 8478：「Zstandard Compression and the application/zstd Media Type」。

對應到 server 端的部份，看起來可以用 tokers/zstd-nginx-module 搭 (在 nginx 環境下)，不然就是 application 端要自己壓縮了。

不過普及率比較高的演算法是 Google 主導的 Brotli，查了一下壓縮率大概在同一個等級。

Facebook 沒有自家瀏覽器，推這些東西比較辛苦一點，但這次 cURL 決定支援 Zstandard 算是一個開始，讓開發者多了一個選擇可以用...

jQuery 3.5.0 的修正，補 XSS 漏洞

這次 jQuery 3.5.0 修正了一個安全性漏洞：「jQuery 3.5.0 Released!」，不過實測了一下，不完全算是 jQuery 的自己出的問題，比較像是幫使用者擦屁股。

jQuery 的說明如果看不懂，可以交叉參考「XSS Game」這篇的說明，搜尋 htmlPrefilter 應該就可以看到了。

這次修正的函數是被 html() 用到的 htmlPrefilter()，這個函數會在 3.5.0 之前會把 <tag/> 這樣的元素轉成 <tag></tag>，而 3.5.0 之後會保留本來的形式。

利用這個特性，就可以用這樣的字串來打穿 WAF：

<style><style/><script>alert(1)<\/script>

原因是 WAF 在看到時會以為 <script> 是 <style> 內部的 data 而認為不是 XSS 攻擊而穿過 WAF 的檢查，但實際上被 jQuery 展開後變成：

<style><style></style><script>alert(1)<\/script>

而最前面的 <style><style></style> 被當作是一包，後面的 <script> 就成功被拉出來執行了。

這是相同程式碼使用 jQuery 3.4.1 與 jQuery 3.5.0 的差異，我把 alert(1) 改成 document.write(1)，比較容易在 JSFiddle 上看出差異：

不過回過來分析，會發現一開始用 html() 才是問題的起點，要修正問題應該要從這邊下手，而不是用 WAF 擋...

AWS 的 ALB 可以用最少未處理連線數分配了

AWS 的 ALB 總算提供「最少連線數」的功能了：「Application Load Balancer now supports Least Outstanding Requests algorithm for load balancing requests」。

先前只有 Round robin (RR)，現在支援 Least outstanding requests (LOR) 後可以往比較少的塞了，這個方法在大多數的應用上比 RR 合理多了，現有的 ALB 應該都可以考慮換過去...

補功能不算快，但有種已知用火的感覺 XD

Slack 改善桌面應用程式的效能與記憶體用量

Slack 桌面版改版的消息，在「Slack’s new desktop app loads 33 percent faster and uses less RAM」與「Slack speeds up its web and desktop client」這邊都有提到這兩個數字，不過看了官方的「When a rewrite isn’t: rebuilding Slack on the desktop」這篇，好像沒提到這兩個數字... 但看引用的圖片似乎是官方的評估數字，不知道是從哪邊得到的。

這是一個堅持繼續使用 Electron 的前提下改善效能的過程。如果過個幾年他們決定寫 native application 也不意外就是了，要一直壓榨效能，最後大概都會走到這邊... 當然也有可能靠 Google 一直改善 V8 engine 的效能撐很久 (畢竟 Google 是真狂砸人改善)，現在大家都在賭可以改善多少 XD

這一波最主要的記憶體用量改善是來自於現在使用的 workspace 當然要有完整資料，而其他 workspace 的頁面就只保留狀態 (透過 Redux)：

從記憶體用量可以看出來：

也可以理解因為這樣就不需要在啟動時馬上處理所有 workspace 的資料，所以啟動時間也就下降了不少，但這邊的 trade-off 是切換時的速度就會變慢 (需要重新 render)，不過大概是考慮到常見情境下的切換次數而決定這樣做，應該還算 ok...

Python 上觀察 Memory Leak

Zendesk 的「Hunting for Memory Leaks in Python applications」這篇介紹了 memory_profiler 這個工具，可以比較長期的觀察記憶體使用量的問題。

首先是先看正常與疑似異常的分析：

然後可以拉出資料型態資訊：

這些資訊要找 memory leak 還是蠻粗糙的，但算是給了個方向，而且用起來算是簡單...

AWS Lambda 可以直接掛進 ALB 了...

AWS 這次對 Lambda 還發表了不少功能，除了前面提到透過 Layout 支援其他語言以外 (e.g. Ruby)，這邊要再提到另外一個重要的功能。

這次是 ALB 可以直接呼叫 lambda function 了：「Lambda functions as targets for Application Load Balancers」。

以前還得靠 API Gateway 整半天 (因為版本設定)，現在直接用 ALB 接就可以了？而且 ALB 這邊有規劃對應的 quota：

There is no change to the hourly price of ALB. The load balancer capacity units (LCUs) of ALB now include 0.4 GB per hour of data processing to AWS Lambda targets.

這樣就更接近 serverless 了...

B2 的 Application Key

來講個 Backblaze 放出來一陣子的功能：「What’s New In B2: Application Keys + Java SDK」。

B2 的價位很便宜 (單位成本比 S3 低不少)，加上前 10 GB 屬於 free tier 不收費，拿來丟一些資料還蠻方便的。

以往的 B2 在 API 操作只提供一把 master key，安全性上需要很小心，只要被攻陷就直接打穿了，現在則是提供 application key 操作，但不像 AWS 的 IAM 那樣可以在一個 key 上設很多權限。B2 提供的架構很簡單，只能針對一個 bucket 設定權限。這應該是解決 B2 最常見的情境？也就是需要在各機器上分別備份...

另外摸索了一陣子後才確認用法，在文章的 comment 有提到：

You use the ApplicationKeyID with the ApplicationKey, and not the account ID, per the b2_authorize_account documentation.

In a sense, the master key is a special case of this: the AccountID is the ‘key ID’ for the master key.

也就是產生 application key 的時候會給你 secret key 以外，也會給你另外一組 key id，要用這兩個傳入呼叫 API，所有的操作都會受到限制。

關於備份的工具，大家蠻常用 rclone 的，主要是因為他可以加密再丟上去，讓 Backblaze 沒辦法直接存取內容。而 rclone 在 Ubuntu 18.04 可以 apt 直接裝，先前的版本則需要透過 snap 裝 (實在不愛 snap...)，不過看起來還需要新版才會支援 application key。

過陣子來把現有的 master key 換一換...

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 時的順暢度會好不少...