Tag: p2p

目前最老的 BitTorrent 種子 20 年了：The Fanimatrix

The Fanimatrix 的 BitTorrent 種子是目前還活著的 BitTorrent 種子最老的，從 2003 年九月建立的種子，至今要 20 年了：「The World’s Oldest Active Torrent Turns 20 Years Old」。

在 2022 的報告裡面 BitTorrent 的流量大約是 2.91% (雖然這份報告本身有些地方很詭異，但就還是可以當個參考)：「2022 Global Internet Phenomena Report」，在「BitTorrent is Still the King of Upstream Internet Traffic, But for How Long?」這邊也在討論 BitTorrent 的占比逐漸下降。

但這就是 open protocol 的特性，你沒辦法殺掉他，而且他在對應的領域還是活的很好...

cURL 放入 ipfs:// 支援

在 Hacker News 上看到 cURL 支援 ipfs:// 的消息：「IPFS support got merged into curl (twitter.com/bmann)」。

Hacker News 上有人提到這包支援的特性與問題：

This patch makes curl utilize a gateway for ipfs:// addresses. It prefers a local one but can also use public gateways. It makes no effort to verify that the final product's cryptographic hash corresponds to the one in the address.

依照說明是透過 gateway 處理，如果本地端有的話就用本地端的 gateway，不然就用 public gateway。另外就是沒有驗證 hash...

不算是原生支援，但還行...？

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.

qBittorrent 支援 BitTorrent v2

在「Thursday January 06th 2022 - qBittorrent v4.4.0 release」這邊可以看到 qBittorrent v4.4.0 支援 BitTorrent v2 (BEP 52) 了：

FEATURE: Support for v2 torrents along with libtorrent 2.0.x support (glassez, Chocobo1)

先前在「libtorrent 宣佈支援 BitTorrent v2」這邊有提到過 libtorrent 要支援 BitTorrent v2 的消息，而 qBittorrent 算是 libtorrent 的使用大戶，支援 BitTorrent v2 後會讓 BitTorrent v2 的使用率增加不少。

用了一年多才出現一個比較大的 client 跳進去支援，看起來大家的動力的確不高...

對 Tor 網路的攻擊

在「Is “KAX17” performing de-anonymization Attacks against Tor Users?」這邊看到針對 Tor 網路攻擊的一些說明...

BTCMITM20 這組比較好理解，目標也比較明確：

primary motivation: financial profit (by replacing bitcoin addresses in tor exit traffic)

KAX17 這組看起來就比較像是政府單位在後面掛：

motivation: unknown; plausible: Sybil attack; collection of tor client and/or onion service IP addresses; deanonymization of tor users and/or onion services

其中可以看到同時掌握了不少 hop，這樣就很有機會一路串起來：

To provide a worst-case snapshot, on 2020–09–08 KAX17's overall tor network visibility would allow them to de-anonymize tor users with the following probabilities:

  • first hop probability (guard) : 10.34%
  • second hop probability (middle): 24.33%
  • last hop probability (exit): 4.6%

由於 Tor 是匿名網路，目前最好的防禦方式還是讓更多人參與加入節點，降低單一團體可以取得足夠組出的資料... 之後找機會整理一下跑了一年多 exit node 的想法好了。

用 iptables 擋特定國家的封包

這兩天發現 ubuntu-20.04.3-live-server-amd64.iso 這個 BitTorrent 的 ISO image 有大量來自 CN 的連線在狂抓，導致整個上傳頻寬都被吃滿：

沒想到第一次用 iptables 的 xt_geoip 居然是這個用途... 主要是參考「GeoIP Blocking Ubuntu 20.04LTS」這邊的方法，不過因為我的 rtorrent 是跑在 Docker 裡面的，有另外要注意的地方。

首先是安裝軟體，這邊要裝 xtables-addons-common 與 libtext-csv-xs-perl：

sudo apt install -y libtext-csv-xs-perl xtables-addons-common

再來是建立目錄，並且下載一包 GeoIP 的資料 (從 DBIP 下載) 並且轉成 xt_geoip 可以用的格式：

sudo mkdir /usr/share/xt_geoip
cd /usr/share/xt_geoip
sudo /usr/lib/xtables-addons/xt_geoip_dl
sudo /usr/bin/perl /usr/lib/xtables-addons/xt_geoip_build

然後就是加到 iptables 的條件裡面了，我加到兩個地方，一個是 INPUT chain，另外一個是 DOCKER-USER chain (參考「Docker and iptables」這邊的說明)，假設你是用 port 6991 的話就這樣加：

sudo iptables -I INPUT -p tcp -m geoip --source-country CN -m tcp --dport 6991 -j DROP
sudo iptables -I DOCKER-USER -p tcp -m geoip --source-country CN -m tcp --dport 6991 -j DROP

然後可以考慮每個禮拜更新一次資料庫。

另外在找資料的時候發現「Free updated GeoIP legacy databases」這邊有人放出 MaxMind 的版本，不過免費版的應該都差不多，這邊就用 xtables-addons-common 內預設的。

弄完以後就正常多了...

Windows 上包裝 Syncthing 的 SyncTrayzor

在「SyncTrayzor is an open source Syncthing client for Windows」這邊看到有人將 Syncthing 包裝好，讓使用者在 Windows 上直接設定，而不需要另外開瀏覽器設定：

Syncthing is a popular peer-to-peer file sharing/synchronization software. It uses a web GUI which can be a little confusing for beginners. SyncTrayzor is an open source client that makes the P2P tool more user-friendly.

Syncthing 比較特別的觀念就是每一台都要設定允許其他台分享 (通常是這樣)。假設你有四台 Syncthing 要設定，每一台都要設定允許其他三台的分享。

不過也可以有其他的設計，像是你可以在 VPS hosting 上租一台空間很大的機器，然後其他機器都只對 VPS 這台機器同步，這樣就比較像有中央 server 的架構。

對於有多電腦的人還蠻好用的東西...

BiglyBT 支援 BitTorrent v2

先前提到的「libtorrent 宣佈支援 BitTorrent v2」，BiglyBT 整合完了：「BiglyBT is the First Torrent Client to Support the BitTorrent V2 Spec」。

看了一下 BiglyBT 的介紹，主要是因為當初 https://en.wikipedia.org/wiki/Vuze 變成 adware 之後分支出來的：

BiglyBT is a feature filled, open source, ad-free, bittorrent client.

BiglyBT is the continuation of the Vuze/Azureus open source project first created in 2003, and is being actively developed by the original coders.

不過這是 Java 寫的 client，目前需求也不大，我自己應該還是會繼續等 qBittorrent 支援，看起來在這邊：「BitTorrent v2 #13344」，不過現在看起來沒什麼進展...

libtorrent 宣佈支援 BitTorrent v2

看到 libtorrent 宣佈支援 BitTorrent v2 (BEP 52) 的消息：「BitTorrent v2」。

BitTorrent v2 這個規格丟出來好久了，但一直都是 draft，而且沒什麼人想要理他，直到 Google 成功產生出 SHA-1 collision 的時候稍微有些音量跑出來，但沒想到居然有人跳下去支援了...

對使用者比較有感覺的差異是從 SHA-1 換成 SHA-2 的 SHA-256 了，這個會影響到整個 torrent file 的結構與 Magnet URI 的部份。

另外一個比較大的改變是 torrent 檔資料結構，有兩個比較大的改變。

第一個是以前用固定的 block size 切割，然後每個 block 產生出 hash，所以 torrent 檔會隨著 block size 選擇的大小 (成反比) 檔案大小 (成正比) 有關，現在會用 Merkle tree，所以只要有 root hash 就可以了。

第二個是以前是把所有檔案包在一起 hash，現在是個別檔案都有自己的 hash (改成 root hash)，所以現在變成可以跨 torrent 檔共用檔案。

然後 libtorrent 的文章裡有提到向前相容的方法，不過以產品面上來說沒有什麼太大的誘因，libtorrent 雖然大，但其他幾家的支援度應該也是重點...

libtorrent 要支援 WebTorrent 協定了

一開始是看到「Libtorrent Adds WebTorrent Support, Expanding the Reach of Browser Torrenting」這篇，但看的時候發現裡面把 libtorrent 與 libTorrent 搞混 (這兩套不一樣，libTorrent 是 rTorrent 作者開發的)，就暫時沒管這篇文章了...

剛剛看到「libtorrent adds support for the WebTorrent protocol」這篇，然後回頭去看本來 TorrentFreak 上的文章，發現已經拿掉本來提到的 rTorrent 了。(可以參考 Internet Archive 上的存檔資料 20200709223911)

WebTorrent 的支援對於 BitTorrent 社群算是很大的進展，主要是因為瀏覽器內就算用上 WebRTC 也沒有辦法模擬出 BitTorrent 的協定，所以只能調整協定，也就是這邊提到的 WebTorrent。

但訂了新的協定，最大的問題還是現有的 BitTorrent 程式都不支援 WebTorrent，所以沒辦法享用現有的 ecosystem，變成獨立的系統，對於推廣上面很不利...

而 libtorrent 算是第一個夠大的 library (對應到 client 的數量) 宣佈支援 WebTorrent，這樣用瀏覽器的人就會有更多機會透過 WebTorrent 協定對通了，接下來等更加發佈新版後應該就可以在 WebTorrent 上看到更多節點了...