用 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-commonlibtext-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 內預設的。

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

Memcached 與 Redis 的比較

在「Memcached vs Redis - More Different Than You Would Expect」這邊看到對 MemcachedRedis 的分析。

這兩套軟體都很常被拿來用作 cache 機制,所以一般來說比較時就是比兩邊都有的東西 (如果你要 pub-sub 之類的東西,在這兩套裡面只有 Redis 有)。

最前面還是先講了對使用者 (開發者) 的差異,很明顯的是 Redis 對各種不同的資聊結構都有支援,這點可以從 Redis 被官方被稱作 Data Structures Server 就可以知道 (在「An introduction to Redis data types and abstractions」這篇可以看到),而 Memcached 只支援了 key-value 架構。

不過如果是以 cache 來說,的確 key-value 架構就還蠻好用的。

後面就開始比較硬的主題了,提到了 Memcached 與 Redis 內部是怎麼使用記憶體的。

Memcached 的部份先提了 page/slab/chunk 的架構以及產生的效能限制與浪費,接著有提到 2020 年 refactor 的部份 (太久沒有看 Memcached 的消息,去年沒跟到這個部份),讓多 CPU 的支援度更好。

Redis 則是靠 jemalloc 來處理這個部份,另外加上 background thread 的機制降低 fragment。

然後是比較 cache expiration 的部份,可以看到兩者用的演算法在現實世界中都夠用 (尤其是當作 cache 來用),這部份跟印象中的架構差不多,應該是沒有太大變化。

最後是比較 cluster 的部份,Memcached 是 share nothing,所以沒什麼好說的,主要是靠 client library 實做 consistent hash 之類的架構打散;而 Redis 的話看起來有實做新的機制出來 (也沒跟到),之後有機會再看看可以做到什麼程度。

不過好像沒提到 proxy 之類的架構,基本上各大公司都有自己幹:

少了這塊對於 cluster 架構的完整性差蠻多的。

文章最後沒有下定論一定要用哪個比較好,兩者都有強項與弱項,還是得看情況來處理。不過我自己還是很喜歡用 Memcached 就是了...

jQuery UI 與 jQuery Mobile 進入維護模式

OpenJS Foundation (先前的 jQuery Foundation) 宣佈 jQuery UIjQuery Mobile 進入維護模式:「jQuery maintainers update and transition jQuery UI as part of overall modernization efforts」、「jQuery maintainers continue modernization initiative with deprecation of jQuery Mobile」。

jQuery UI is in maintenance-only mode. Users should not expect any new releases, though patches may be issued to resolve critical security, interoperability, or regression bugs.

The team announced that the cross-platform jQuery Mobile project under its umbrella is fully deprecated as of October 7, 2021.

應該就是沒有足夠的動能繼續開發了,維持個窗口在有 security issue 時處理...

Wasabi 與 Storj DCS

WasabiStorj 是在看到「Will Cloudflare R2 Win Customers from Amazon S3?」這篇文章時翻到了三個 Cloud Storage Provider,文章本身我倒是沒什麼吸收...。

第一個是 BackblazeB2,這個產品平常的曝光度就還算夠。

另外是 Wasabi 的部份,其中一個賣點是免費的頻寬,但其實限制意外的多。首先是各地區的價錢:

我找了一下到底是什麼地區,目前只有看到「Wasabi Technologies Inc Status」這邊有編號 (US-East-1、US-East-2、US-Central-1、US-West-1、EU-Central-1、AP-Northeast-1),但也沒找到地區... US 的都在美國沒問題,AP-Northeast-1 應該是日本,但 EU-Central-1 是哪裡就找不到了。

另外是 pay-as-you-go 的方案最小是 1TB,如果是歐美區的話是 US$5.99:

For customers using the Wasabi pay-as-you-go pricing model, Wasabi has a minimum monthly charge associated with 1 TB of active storage. If you store less than 1 TB of active storage in your account, you will still be charged for 1 TB of storage based on the pricing associated with the storage region you are using.

然後也有 90 天的最短計價時間:

Wasabi has a minimum storage duration policy that means if stored objects are deleted before they have been stored with Wasabi for a certain number of days (90 days when using the Wasabi pay-go pricing model), a Timed Deleted Storage charge equal to the storage charge for the remaining days will apply.

另外 Wasabi's free egress policy 這邊也可以看出來他們的設計就是拿來當 storage 用,然後前面需要擋 CDN 之類的服務。

最後一個是 Storj 的 DCS,US$4/TB/month 的空間費用,與 US$7/TB 的流量費用感覺還算便宜?他的做法是把檔案拆成 80 份,然後取 29 份就可以算回來:

How many Nodes are files stored on?

80. We split each file into 80 different encrypted pieces, and each piece is stored on a different Node.

When you retrieve an object, only 29 of its 80 pieces are needed to reconstitute that object. With no central point of failure, your data is always quickly available, all over the world.

這部份是則是透過 Reed-Solomon error correction 實做:

Automate file repair and know that Reed-Solomon erasure coding enables the highest levels of durability for all files uploaded to Storj DCS.

好一陣子沒看到 Reed-Solomon 了,沒想到在這邊看到... 先不管技術的部份,看起來 Storj DCS 的價錢可以玩看看。

Vultr 可以帶自己的 IP 位置使用

Twitter 上看到 Vultr 可以帶自己的 IP 使用:

翻了一下發現是 2015 年就提供的功能:「Announce IP Space on the Cloud with Vultr」,而旁邊的 LinodeDigitalOcean 似乎都沒翻到...

在文件「Configuring BGP on Vultr」這邊可以看到需要先驗證 IP 是你的,算是業界常見的作法,跟當初申請 AWSDirect Connect 類似的作法。

Amazon SES 總算支援 2048 bits RSA key 了

Amazon SES 總算是支援 2048 bits RSA key 了:「Amazon SES now supports 2048-bit DKIM keys」。

然後講一些幹話... 隔壁微軟早在 2019 年就支援 2048 bits RSA key 了:

Until now, Amazon SES supported a DKIM key length of 1024-bit, which is the current industry standard.

另外用 ECC 演算法的一直都沒進 standard,像是已經先 book 了 RFC 8463 位置的 Ed25519,在 draft 狀態放好久了:「A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)」,還有用 ECDSA 的「Defining Elliptic Curve Cryptography Algorithms for use with DKIM」也是放著,不知道是卡到什麼東西,可能是專利?

Cloudflare R2 Storage 的插曲...

Hacker News 首頁上看到「Cloudflare's Disruption (stratechery.com)」這篇,文章「Cloudflare’s Disruption」這篇其實還好,主要就是分析一下 Cloudflare R2 Storage 在下的棋,真的讓我想寫的是反而是 Hacker News 上的討論...

首先是提到了 S3 -> R2 -> Q1 -> P0 這個:

ksec 36 minutes ago | unvote [–]

^gt; The service will be called R2 — “one less than S3,” quipped Cloudflare CEO Matthew Prince in an interview with Protocol ahead of Cloudflare’s announcement

Oh I never thought of that. So the next one is Q1 and final one would be P0.

另外下面有也提到 IBMHAL

piaste 33 minutes ago | unvote [–]

And it is likely inspired by the old joke that 2001: A Space Odyssey's HAL was one less than "IBM".

下一個 Q1 是明年了,來看看 2022Q1 會不會有 P0 issue XDDD

GitHub 的 MySQL 架構與數字

前幾天 GitHub 有寫一篇文章提到他們的 MySQL 是怎麼 scale 的,另外裡面也有一些數字可以看:「Partitioning GitHub’s relational databases to handle scale」。

他們最主要的 database cluster 叫做 mysql1,裡面有提到 2019 年的時候這個 cluster 是 950K qps,其中 primary 有 50K qps:

In 2019, mysql1 answered 950,000 queries/s on average, 900,000 queries/s on replicas, and 50,000 queries/s on the primary.

在 2021 年的時候變成 1.125M qps,其中 75K qps 在 primary 上:

Today, in 2021, the same database tables are spread across several clusters. In two years, they saw continued growth, accelerating year-over-year. All hosts of these clusters combined answer 1,200,000 queries/s on average (1,125,000 queries/s on replicas, 75,000 queries/s on the primaries). At the same time, the average load on each host halved.

另外這幾年比較成熟的方案都拿出來用了,包括用 ProxySQL 降低連線數的壓力 (connection pool 的概念):

[W]e started using ProxySQL to reduce the number of connections opened against our primary MySQL instances.

ProxySQL is used for multiplexing client connections to MySQL primaries.

另外用 Vitess 協助 sharding 之間的轉移:

Vitess is a scaling layer on top of MySQL that helps with sharding needs. We use its vertical sharding feature to move sets of tables together in production without downtime.

這兩套應該是已經蠻成熟的了... 另外也可以發現老方法還是很好用,就算在 GitHub 這種量還是可以暴力解決很多事情。

DST Root CA X3 將在今天 22:01:15 過期

先前提到 Let's Encrypt 發出的憑證在 9/30 會產生問題,主因是 IdenTrustDST Root CA X3 會在 9/30 過期,交叉簽名加上 OpenSSL 1.0.2 的判斷條件太嚴格導致的:「OpenSSL 1.0.2 與 Let's Encrypt 在這個月月底的相容性問題」。

本來以為是 UTC 的 2021/09/30 23:59:59 之類的時間,結果因為要面對這個問題,需要確認正確的時間,結果發現不是 UTC 的 2021/09/30 23:59:59,而是一個奇怪的時間:

Validity
    Not Before: Sep 30 21:12:19 2000 GMT
    Not After : Sep 30 14:01:15 2021 GMT

所以是 2021/09/30 22:01:15 (台灣時間) 會過期,今天晚上可以看一下情況...

NLB 接 ALB?

AWS API Changes 上看到這個修改:「2021/09/27 - Elastic Load Balancing - 3 updated api methods」。

說明是這樣:

Adds new ALB-type target group to facilitate forwarding traffic from NLB to ALB

所以是 NLB 可以接到 ALB 嗎,這看起來讓彈性變大不少...