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.ccns1.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.ccns1.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)、DockerMaven (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 LambdaNode.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」。

包括了 memcachedRedis 都支援了:

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.

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

Node.js 第一個 8.x LTS 推出

推出啦:「Node v8.9.0 (LTS)」,另外可以看「NEWS: Node.js 8 Moves into Long-Term Support and Node.js 9 Becomes the New Current Release Line」這篇。

從 6 到 8 多了 async & await (ES7),應該會是對整個生態系改變最大的功能了,可以預期會有一堆人濫用... XD

剛剛測 nlts 參數發現還沒更新,先用 n 8.9.0 換上去...

Node.js 安全性更新:zlib...

前幾天「Node.js 預定在十月 24 號發表安全性更新」提到 Node.js 會發表安全性更新,已經看到 4/6/8 都出新版了:「Node v4.8.5 (Maintenance)」、「Node v6.11.5 (LTS)」、「Node v8.8.0 (Current)」。

這次安全更新的 CVECVE-2017-14919

CVE-2017-14919 - In zlib v1.2.9, a change was made that causes an error to be raised when a raw deflate stream is initialized with windowBits set to 8. On some versions this crashes Node and you cannot recover from it, while on some versions it throws an exception. Node.js will now gracefully set windowBits to 9 replicating the legacy behavior to avoid a DOS vector. nodejs-private/node-private#95

zlib 的 manualwindowBits 說明:

For the current implementation of deflate(), a windowBits value of 8 (a window size of 256 bytes) is not supported. As a result, a request for 8 will result in 9 (a 512-byte window). In that case, providing 8 to inflateInit2() will result in an error when the zlib header with 9 is checked against the initialization of inflate(). The remedy is to not use 8 with deflateInit2() with this initialization, or at least in that case use 9 with inflateInit2().

唔?XD

另外文章可以看出來 Node.js 團隊是選擇在 GitHub 上用另外一個 organization 在管這類不會事前公開的事情...