Windows 7 終止支援

Windows 7 跳出畫面才發現 2020/01/14 終止支援,官方的說明可以在「Windows 7 support ended on January 14, 2020」這邊看到。維基百科上也查的到資料:

Mainstream support ended on January 13, 2015.
Extended support ended on January 14, 2020.
Extended Security Updates paid in yearly installments for 1, 2, or 3 years (or free for Windows Virtual Desktop users) until at most January 10, 2023 only for Professional and Enterprise volume licensed editions.

大量授權用戶可以採購延伸授權,另外 Windows Virtual Desktop (跑在 Azure 上的版本) 則是免費提供。雖然沒有更新,但我猜可能還是會有人把 patch 整理出來讓使用者裝吧...

TCP Congestion Control Algorithm 的選擇

先前 Ubuntu 桌機用 BBR 跑了一陣子,但有遇到一些問題 (可以參考「Dropbox 測試 BBRv2 的結果」這篇),所以暫時換成 Westwood,但還是陸陸續續會看一下各種研究。

剛剛在「[tor-relays] TCP CCA for Tor Relays (and especially Bridges)」這邊看到一個經驗談:

Here are my completely unscientific scribbles of how all the various algorithms behaved. The scenario is uploading for a minute or so, observing the speed in MB/sec visually, then recording how it appeared to change during that minute (and then repeating this a couple of times to be certain).

tcp_bic.ko       -- 6...5...4
tcp_highspeed.ko -- 2
tcp_htcp.ko      -- 1.5...3...2
tcp_hybla.ko     -- 3...2...1
tcp_illinois.ko  -- 6...7...10
tcp_lp.ko        -- 2...1
tcp_scalable.ko  -- 5...4...3
tcp_vegas.ko     -- 2.5
tcp_veno.ko      -- 2.5
tcp_westwood.ko  -- <1
tcp_yeah.ko      -- 2...5...6

上面是「目視法」觀察到的速度 (MB/sec),看了一下維基百科上 TCP-Illinois 的說明,看起來設計的目的是提供給頻寬大、latency 高的情境下:

It is especially targeted at high-speed, long-distance networks.

來跑跑看好了...

nginx + fcgiwrap (spawn-fcgi) + Mailgraph

手上還是有固定一台機器是自己架設 Postfix 管理郵件系統,所以還是想跑個 Mailgraph 看一下有多少量在上面跑...

不過因為 Mailgraph 的 web interface 只有 CGI 界面,但 nginx 不支援 CGI,所以需要找個工具透過 nginx 支援的 FastCGI 轉換進去。

概念與設定都不算太難,但是得把工具找齊才會動 (這段花了不少時間),所以記錄一下怎麼做,以後找比較好找資料。

首先先裝 Mailgraph 與 fcgiwrap:

sudo apt install -y fcgiwrap mailgraph

這兩個程式預設都會跑起來。如果沒有的話自己用 sudo service fcgiwrap statussudo service mailgraph status。接下來在 nginx 的找個 virtual host 裡面這樣設:

    location /mailgraph/ {
        index mailgraph.cgi;

        location ~ \.cgi$ {
            include fastcgi.conf;

            fastcgi_pass unix:/var/run/fcgiwrap.socket;
        }
    }

然後把 Mailgraph 的 CGI 與 css 透過 symbolic link 建到 document root 的 mailgraph/ 下:

export DOCUMENT_ROOT="/srv/home.gslin.org"
cd "${DOCUMENT_ROOT}"
sudo mkdir mailgraph
sudo ln -s /usr/lib/cgi-bin/mailgraph.* .

接著重讀設定檔,或是重跑 nginx,就應該可以在 https://virtualhost.com/mailgraph/ 下看到了。

在家裡遺失 Kindle 的找法...

Hacker News Daily 上看到的文章,作者遺失了 Kindle,但是確定在家裡 (因為在 router log 上看得到):「Any way to find a lost Kindle inside a house?」。

然後作者發現每天早上五點半到六點半 Kindle 會自己同步,所以塞了一個夠大的 PDF 進去以確保有夠長的時間連在網路上,然後用三台跑 Kali Linux 的筆電定位,完全是一個殺雞用牛刀的概念 XDDD (還是他家真的超大?)

但記得這要在剛遺失的時候就要找,不然等到 Kindle 的電池也沒電就沒救了 XDDD 以原文作者的情況,如果真的是這種 case 說不定到時候會拿金屬探測器掃 XDDD

Arch Linux 決定把套件壓縮演算法從 xz 換成 Zstandard

看到 Arch Linux 的公告,他們決定把套件的壓縮演算法從 xz 換成 Zstandard:「Now using Zstandard instead of xz for package compression」。

從 xz 換成 Zstandard 主要的原因在於不用犧牲太多空間 (多 0.8% 的空間),但解壓縮的速度可以大幅提昇 (提昇 13 倍):

zstd and xz trade blows in their compression ratio. Recompressing all packages to zstd with our options yields a total ~0.8% increase in package size on all of our packages combined, but the decompression time for all packages saw a ~1300% speedup.

看起來是不斷發酵... 在幾個月前隔壁棚的 Fedora 先換過去了,計畫在「Changes/Switch RPMs to zstd compression」這邊可以翻到,而 issue tracking system 上的記錄可以參考「Issue #350: F31 System-Wide Change: Switch RPMs to zstd compression - release-notes - Pagure.io」。

看起來會是趨勢了...

CVE 成長速度好快啊...

看到 phpBB 公告的「phpBB 3.2.9 Release - Please Update」這邊,裡面提到了安全性更新的 CVE 編號:

The issues have been assigned CVE-2020-5501 and CVE-2020-5502 respectively.

想說今年也才過完六天而已... 撈了一下資料,發現寫這篇文章當下,CVE 編號已經被申請到 CVE-2020-5956 了,這速度有夠快 XDDD

Raspberry Pi 4 的散熱問題

找被動散熱資料的時候翻到的,Raspberry Pi 4 有新的韌體可以刷,而新的韌體會降低一些功率消耗,也讓溫度降一些:「Thermal testing Raspberry Pi 4」。

會找被動散熱是因為手上的 Raspberry Pi (一代) 已經壞了兩顆風扇了,大概每年要換一次,風扇的成本是不高,但換起來總是頗麻煩...

而新的 Raspberry Pi 4 在拿到後,發現整包附的是散熱片 + 風扇組合,跑起來也還不錯,但長遠來看還是希望找個被動散熱方案...

目前看到幾個測試,一個是搜尋到在 Reddit 上的「Raspberry Pi 4 heatsink testing」這篇 (或是作者自己的 blog 上:「Raspberry Pi 4 heatsink testing」),裡面提到散熱片夠大,或是用銅製散熱片,在全速跑的時候不會降速:

另外在「Raspberry Pi 4 ICE Tower CPU Cooling Fan Tested」這邊也有看到不開風扇情況下,用散熱塔也行:

另外是整個機殼都拿來散熱的方式,看起來也還行:

如果真的不夠用而需要再拼的話,也許會考慮製冷片,不過先買個殼測試看看...

Dropbox 測試 BBRv2 的結果

BBRv1 有不少問題,在 BBRv2 有一些改善 (目前還在測試階段,在「TCP BBR v2 Alpha/Preview Release」這邊可以看到一些說明),而 Dropbox 則是跳下去測試,並且公佈結果:「Evaluating BBRv2 on the Dropbox Edge Network」。


Spoiler alert: BBRv2 is slower than BBRv1 but that’s a good thing.

在文章開頭的這張圖就說明了 BBRv2 的速度比較慢,但是說明這是朝好的方向改善。

BBRv1 的問題其實我自己都有遇到:我自己的 Ubuntu 桌機跑 BBRv1,在我上傳大量資料的時候 (只開一條連線),會導致 PPPoE 的 health check 失敗,於是就斷線了,另外 VM 裡面的 Windows 7 因為也是 bridge mode 跑 PPPoE,也可以看到斷線嘗試重連的訊息,於是只好改掉...

上面提到的問題就是 BBRv1 造成 packet loss 過高,除了我遇到的問題外,這對於其他 loss-based 的 TCP congestion algorithm 來說會有很大的傷害 (i.e. 不公平):

Other tradeoffs were quite conceptual: BBRv1’s unfairness towards loss-based congestion controls (e.g. CUBIC, Compound), RTT-unfairness between BBRv1 flows, and (almost) total disregard for the packet loss:

另外一個改善是 BBRv2 加入了 ECN 機制,可以更清楚知道塞住的情況。

整體上來說應該會好不少,不知道之後正式釋出後會不會直接換掉 Linux Kernel 裡的 BBRv1,或是不換,讓 BBRv1 與 BBRv2 共存?

HTTP/1.1 與 HTTP/2 的最佳化技巧

這篇在討論,無論是 HTTP/1.1 時代,或是 HTTP/2 時代下 (裡面還包括了 HTTP/2 的 Server Push),各種讓下載速度最佳化的技巧以及造成的複雜度:「Performance testing HTTP/1.1 vs HTTP/2 vs HTTP/2 + Server Push for REST APIs」。

文章裡其中一個提到的是各類「打包」的技巧,也就是 JavaScript 的 bundle,或是 CSS 的 Image sprites,甚至是 API 的合併,像是很多人會考慮的 GraphQL

雖然在 HTTP/2 年代我們常說可以省下來,但這並不代表「打包」在 HTTP/2 情境下沒有效果,只是改善的幅度比較少,所以這個最佳化的技巧比起 HTTP/1.1 年代,可以放到後面一點再做,先把人力放到其他地方。但如果團隊工具已經熟悉打包技巧的話 (可能是以前就已經做好了),其實繼續使用沒有太大問題...

另外是 Server Push 的情境,意外的反而可以提昇不少速度,看起來主要是少了請求的時間,所以快不少。

再來是跨網域時 CORS 的問題,在 Flash 的年代是一個 crossdomain.xml 解決,但現在的解法是多一個 OPTIONS request,反而造成很大的效能問題... 文章裡提到現在看起來有個 Draft 在發展與 Flash 類似的機制:「Origin Policy」。

作者在測試完後得到的結論其實跟蠻多「直覺」相反的:

  • If speed is the overriding requirement, keep using compound documents.
  • If a simpler, elegant API is the most important, having smaller-scoped, many endpoints is definitely viable.
  • Caching only makes a bit of difference.
  • Optimizations benefit the server more than the client.

Ptt 開始限縮 Telnet 協定連線方式

Ptt 開始關掉一些沒有加密的 Telnet 登入方式:「[公告] 正式支援Websocket連線/telnet連接埠調整」。

本來有 Telnet 很多 Port 可以連,現在限制到 Port 23:

此外, PTT 將會逐漸關閉無加密的 telnet 連線方式.
PTT 預計於 2020/03/01 起對 telnet 連接埠作以下調整.

到 2020/02/29 止 telnet 連接埠: 23, 443, 3000-3010, 8888
從 2020/03/01 起 telnet 連接埠: 23

同時也宣布扶正 WebSocket 連線方式:

經過一段時間的測試與參數微調後,
Websocket 已經足以支撐 PTT 的連線量,
PTT 即日起將 Websocket 列入正式支援的連線方式.

完全關閉不知道會是什麼時候,也許 2021 年?另外 Linux 下好像還是只有 SSH client 堪用,Websocket 還是只能透過瀏覽器操作...