Tag: node

擾人的 lazy loading

維基百科上面有時候會想要看其他語言的頁面，以 Kalafina 這頁來說，想要點開跨國語系的 menu 點日文版頁面的時候，會出現這樣的情況：

游標移上去要點的時候，因為 lazy loading 跑完；DOM 被插入新的 node，造成本來想要的日文版連結跑到下面，然後按快一點的人就點到其他連結... 目前的解法是直接用 uBlock Origin 擋掉那個 node，讓他不要出現：

wikipedia.org##.cx-uls-relevant-languages-banner

這種類型的 UX flaw 在現代愈來愈多了，而且還是各 framework 都推薦的寫法... (各種 useEffect() 類的功能，頁面的結構先出來，再後續讀到內容時再更新頁面)

看到「Creating Perfect Font Fallbacks in CSS」這邊這段時想到的：

With font-display: swap, the browser will first render your text using the fallback typeface you specified in the font-family property[.]

font swapping 也是個讓人吐血的 UX flaw...

Node.js 20

看到 Node.js 推出 20 了，官方的公告：「Node.js 20 is now available!」。

裡面提到的 Permission Model，設計上看起來有點雷？這種東西應該要有白名單機制才對，目前看起來是實做黑名單機制...

然後結尾有提到 14 是這個月收攤，16 則是因為 OpenSSL 1.1.1 EoL，打算切齊而提前到今年九月收 (參考 OpenSSL 官方前陣子發的「OpenSSL 1.1.1 End of Life」)：

Also of note is that Node.js 14 will go End-of-Life in April 2023, so we advise you to start planning to upgrade to Node.js 18 (LTS) or Node.js 20 (soon to be LTS).

Please, consider that Node.js 16 (LTS) will go End-of-Life in September 2023, which was brought forward from April 2024 to coincide with the end of support of OpenSSL 1.1.1.

查了 18 會是 2025 年四月底，20 則會是 2026 年四月底...

Tor 0.4.7.7 支援 congestion control

Tor 首度在協定內支援了 congestion control：「Congestion Control Arrives in Tor 0.4.7-stable!」。

這個新功能會帶來效能的提昇：

Tor has released 0.4.7.7, the first stable Tor release with support for congestion control. Congestion control will eliminate the speed limit of current Tor, as well as reduce latency by minimizing queue lengths at relays. It will result in significant performance improvements in Tor, as well as increased utilization of our network capacity.

之所以沒有辦法直接利用 packet loss 的方式讓 TCP network stack 直接判斷 congestion control，是因為這樣會產生 side channel：

Crucially, we rejected mechanisms to provide congestion control by allowing packet drops, due to the ability to introduce end-to-end side channels in the packet drop pattern.

所以 Tor 得自己實做 congestion control 演算法，選擇的演算法是結合了 Vegas 的 Tor-Vegas，可以看到在實驗中，德國與香港的 exit node 效率大幅提昇：

另外也因為 0.4.7.7 也出來一個禮拜了，也可以看到 Advertised Bandwidth (算是 Tor network 觀察到的 bandwidth) 開始成長：

另外一個重要的點是 UDP 的支援計畫，看起來在這次改善後也比較有可行性了：

The astute reader will note that we rejected datagram transports. However, this does not mean that Tor will never carry UDP traffic. On the contrary, congestion control deployment means that queue delay and latency will be much more stable and predictable. This will enable us to carry UDP without packet drops in the network, and only drop UDP at the edges, when the congestion window becomes full. We are hopeful that this new behavior will match what existing UDP protocols expect, allowing their use over Tor.

Ptt 信件伺服器 node.ptt.cc 查不到反解的問題

就如同標題所說的，Ptt 對外寄信的伺服器 node.ptt.cc 查不到反解的問題：

$ host node.ptt.cc
node.ptt.cc has address 140.112.172.16
$ host 140.112.172.16
Host 16.172.112.140.in-addr.arpa not found: 2(SERVFAIL)

情況大概是這樣，Ptt 使用的 140.112.172.0/27 這個網段 (尾碼從 0～31) 不是 /24 以上的範圍，而 140.112.172.0/24 是台大計中管轄範圍，所以台大就把 140.112.172.x 這段的反解 PTR record 用 CNAME 的方式指到 x.0-31.172.112.140.in-addr.arpa，像是 140.112.172.16 這樣：

;; ANSWER SECTION:
16.172.112.140.in-addr.arpa. 86400 IN   CNAME   16.0-31.172.112.140.in-addr.arpa.

然後再針對 0-31.172.112.140.in-addr.arpa 設定 NS RR 到 ns0.ptt.cc 與 ns1.ptt.cc 兩台 NS server：

;; AUTHORITY SECTION:
0-31.172.112.140.in-addr.arpa. 86400 IN NS      ns1.ptt.cc.
0-31.172.112.140.in-addr.arpa. 86400 IN NS      ns0.ptt.cc.

但是 ns0.ptt.cc 與 ns1.ptt.cc 都不見了：

$ host ns0.ptt.cc
Host ns0.ptt.cc not found: 3(NXDOMAIN)
$ host ns1.ptt.cc
Host ns1.ptt.cc not found: 3(NXDOMAIN)

導致反解查不到對應的資料 (會是 SERVFAIL)：

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58463

猜了一下，看起來 ns0.ptt.cc 還活著，只是 Cloudflare 上面的 DNS record 沒設定過去：

$ dig ns0.ptt.cc @140.112.172.16

;; ANSWER SECTION:
ns0.ptt.cc.             300     IN      A       140.112.172.16

不過 ns1.ptt.cc (140.112.172.10) 看起來就沒服務了，但至少在 Cloudflare 上補個 DNS record 上去應該就會動了 (只是沒有兩台互相備援)。

使用 Tor 的 .onion 位置，而非透過 Exit Node 存取網站的好處

在「Twitter 的 Tor Onion 位置」與「BBC 這次拿出短波廣播...」這兩篇我都有在懷疑為什麼要提供 Tor 的 .onion 位置，不是直接透過 exit node 連出去就好了嗎，結果今天看到「Why offer an Onion Address rather than just encourage browsing-over-Tor?」這篇在解釋。

對使用者來說，用 .onion 的好處是隱私性會更好，因為 exit node 本身不一定安全，必須透過 HTTPS 保護才有基本的防護，而且就算用了 HTTPS 還是可以從 HTTPS 的 handshake 得到不少資訊。

對網路本身來說，exit node 算是稀缺資源，大多數人可以架 Tor 的 relay node，但沒辦法做 exit node，因為 exit node 的特性會導致常常收到各種警告。因此能用 .onion 位置存取，也會降低對 exit node 的壓力。

另外 CA/Browser 在 2020 的時候就允許發出 .onion 憑證：「讓 Tor 的 .onion 支援 HTTPS」，看起來應該也是多一層保護...

Tor 在德國的 Relay 節點比重過高的問題

在「The German Problem with Tor」這邊提到了 Tor 在德國的 Relay 節點比重過高的問題，遠超過第二名的法國：

This is where we come to Germany, which has the highest amount of Tor relay capacity in the World at 167Gbps, in contrast France is in 2nd place with 64.5Gbps of capacity aka more than 100Gbps lower than Germany.

從 Welcome to Tor Metrics 這邊可以拉資料出來看，在「rs.html#aggregate/cc」這頁可以看到差距，現在德國的 Relay 是第一名，比重約 37.7%，法國則是第二名，但卻只佔了 16.7%。

主要還是頻寬費用的關係吧？畢竟網路上租主機時也可以感覺到，德國的頻寬真的很便宜...

GitHub 推出 Package Registry

GitHub 推出了「GitHub Package Registry」，可以代管自己開發的軟體。

目前支援 npm (Node.js)、Docker、Maven (Java)、NuGet (.NET)、RubyGems (Ruby) 五個平台，

隔壁 GitLab 說我們早就有了而氣噗噗中：「Packaging now standard, dependency proxy next?」。

Anyway，省下一些事情，以前會透過 CI/CD 丟到像是 packagecloud.io 這樣的服務上讓內部使用，現在看起來 GitHub 上面可以解決一些簡單的情境...

AWS Lambda 支援 Node.js v8.10

AWS Lambda 的 Node.js 宣佈支援目前最新的 LTS 版本，v8.10：「AWS Lambda Supports Node.js v8.10」。

You can now develop your AWS Lambda functions using Node.js v8.10. In addition to the leveraging new features in Node.js v8.10 such as the new V8 6.0 engine, Lambda functions written in Node.js 8.10 can now use the async/await pattern to specify error or return values for the function execution.

就如同公告裡提到的，有很多語言特性是大家等很久的... 有些老東西可以考慮重寫 :o

Rust 是不錯啦，不過...

作者寫了一篇「Creating Rust-based NodeJS modules」講同樣演算法 Node.js 要跑 3.5 秒，Rust 只要跑 130ms，所以 Rust 很棒棒之類的...

So about 3.5 seconds for an answer, in web time that is like an eternity. Our algorithm is a very straight forward one, basically just a filter on a large array.

The exact same algorithm, with the exact same CSV and coordinates is now executing in about 130ms.

然後仔細看了一下他的範例，holy...

這讓我想到之前在「看到 zmx 貼了之前的連結，更確信 Uber 的問題不是技術問題了...」這篇提到的文章「Unwinding Uber’s Most Efficient Service」：

很想講「傻逼你先把演算法修好再來怪 Node.js 慢」，程式會愈來愈難維護都是你們這種人引入一堆複雜的東西 -_-

ElastiCache 支援 r4.* 了

每年 AWS re:Invent 要到的時候就會有很多新的消息出來，Amazon ElastiCache 的團隊應該也是配合著這一波放出消息：「Amazon ElastiCache Now Supports the R4 Node Family」。

包括了 memcached 與 Redis 都支援了：

Amazon ElastiCache now supports R4 node types. R4 nodes are optimized for latency sensitive and memory intensive workloads. They come in six sizes, providing 12.3GiB to 407GiB of available in-memory capacity. By setting up a 15-shard cluster for Redis, you can scale up to 6.1TiB of in-memory capacity. For Memcached, you can set up a 20-node cluster to support up to 8.14 TiB in-memory workloads. Equipped with the Intel Broadwell processor, and improved networking, R4 node family offers superior performance over the popular R3 node family.

這兩個應用都是看記憶體吃飯的...