OpenSSH 要內建阻擋系統了

在「OpenSSH introduces options to penalize undesirable behavior」這邊看到 OpenSSH 要內建阻擋系統了,算是取代了 fail2ban 的一些功能?

還蠻... 特別的?不知道為什麼現在這個時間點會想要實作這個功能?

這個功能在 OpenBSD 7.6 上面預設會開啟,這點不確定其他 distribution 會怎麼安排:

So now we know: starting with OpenBSD 7.6, PerSourcePenalties will be enabled by default, and admins who do not themselves run PF or other network translation mechanisms will need to keep the consequences of inconsiderate NAT use in mind.

合併 GitHub Actions 的 IP address

GitHub 官方文件「About GitHub's IP addresses」中,是有提到 https://api.github.com/meta 這組 API endpoint,可以取得當下的 GitHub Actions 所使用的連外 IP address,不過如果你實際掃下來後會發現量相當大,以現在的情況來說,IPv4 address 有 3708 筆,IPv6 address 則有 801 筆:

$ cat github-actions-ipv4.txt | wc
   3708    3708   58233
$ cat github-actions-ipv6.txt | wc
    801     801   17522

實際去看的時候會看到一些吐血的,像是這包 /31 的:

13.105.49.0/31
13.105.49.2/31
13.105.49.4/31
13.105.49.6/31
13.105.49.8/31
13.105.49.10/31
13.105.49.12/31
13.105.49.14/31
13.105.49.16/31

這包還真的就整整 128 筆,你就不能輸出個 13.105.49.0/24 嗎...

ChatGPT 問了要怎麼解決,被提示有 netmask 這個工具可以用,不需要另外自己編譯,可以直接用 apt 裝起來然後倒進去讓他跑就好,整包搭配 jqHTTPie 處理掉 (換 curl 基本上也沒問題):

netmask --cidr -- $(http https://api.github.com/meta | jq -r '.actions[]')

Update:看到資安的朋友按讚突然想到,這邊用了 $() 把資料丟到 command line 包裝,可能會有安全上的顧慮,請自己斟酌...

不過整包 (IPv4 + IPv6) 還是有 3187 行,但總是有個方法可以整理起來用,不用自己刻一堆程式處理...

南極洲使用 Internet 的痛點

在「Engineering for Slow Internet (brr.fyi)」這邊看到的,這幾天還蠻紅的文章,在講網路受限的情況下要怎麼想辦法:「Engineering for Slow Internet」,作者是南極洲計畫 (USAP) 的 IT (目前已經回美國本土)。

主要的技術限制有幾個,第一個是對外網路的時間是有限的,因為受限於經過上空的衛星是有限的,這是 2023 年十月的一些資料:

可以看到主要是 DSCS (五顆服役中,但不是每科都有經過南極上空) 與 TDRS-6

這個是物理限制,沒有 workaround 可以做,所以所有人都得照著對應的時段安排傳輸。不過應該有其他的衛星可以隨時聯絡 (emergency channel),畢竟算是半個軍事計畫?

Hacker News 上也有人討論到 Starlink 好像還是有一些衛星會飛過南極洲,但不確定是否有 relay 的能力,如果有的話似乎也能考慮看看?(不過可能會需要客製天線,畢竟緯度的關係,設備需要的工作溫度區間不太一樣)

另外一個大問題是 latency,平均的 latency 是 750ms,而且 jitter 會到數秒:

Round-trip latency averaging around 750 milliseconds, with jitter between packets sometimes exceeding several seconds.

第三個是速度,一般使用者的平均網路速度大約是個位數的 kbps 到狀況好的時候大約是 2mbps,差不多是 1990 年代數據機的速度:

Available speeds, to the end-user device, that range from a couple kbps (yes, you read that right), up to 2 mbps on a really good day.

文章基本上就是圍繞這些問題在討論。

因為 latency 過高,而很多應用程式 (web 或是 app) 寫死 timeout,所以造成網路明明就有慢慢在傳輸資料,你放著慢慢傳遲早會傳完,但卻因為超時而失敗。

另外因為頻寬有限的問題,沒有提供續傳機制 (app 裡面沒做,或是沒有提供檔案直接讓有技術能力的人下載,像是 wget -c 這樣的工具) 就很容易因為失敗浪費頻寬。

另外是遇到軟體更新機制 (像是安全性更新) 無法下載檔案後直接安裝,都會有裝到一半中間要連網的事情。

另外一塊是現在太多工具太肥大,一個簡單的功能要先下載一包 20MB javascript 之類的 (然後換算一下前面提到的頻寬,在網路最好的情況下得花 80 秒下載這包 javascript)。

如果你的使用者族群包括了這類網路狀況不是很好的地區,這篇提到的蠻多東西都還蠻值得參考的。

Internet Archive 被 DDoS 攻擊

在「The Internet Archive is under a DDoS attack (archive.org)」這邊看到 Internet ArchiveDDoS 貓,原始連結在 https://mastodon.archive.org/@internetarchive/112513905401989149 這邊:

現在是有感覺到 loading 的速度不快 (不過以前就不快了),然後 traceroute 看起來有輕微的 packet loss...

記得 Internet Archive 的頻寬一直都是滿的 (翻到 2020 年時有提到的「Internet Archive 的頻寬...」),對於以灌流量的 DDoS 攻擊是沒什麼抵抗力的。

以他們家的情況來看,大概只能請上游幫忙擋?

OpenBSD 提供了關閉 Nagle's algorithm 的 sysctl 選項

看到「Demise of Nagle's algorithm (RFC 896 - Congestion Control) predicted via sysctl」這篇,OpenBSD 提供 sysctl 的選項直接關閉 Nagle's algorithm

The below changeset introduces sysctl net.inet.tcp.nodelay, which if set to 1 will simply cause TCP_NODELAY to be set on all TCP sockets.

不過裡面提到了 John Nagle 在 2015 年的時候有在 Hacker News 上面回覆 (id=10608356),大概介紹了一下背景,以及提出了他的看法:

That still irks me. The real problem is not tinygram prevention. It's ACK delays, and that stupid fixed timer. They both went into TCP around the same time, but independently. I did tinygram prevention (the Nagle algorithm) and Berkeley did delayed ACKs, both in the early 1980s. The combination of the two is awful. Unfortunately by the time I found about delayed ACKs, I had changed jobs, was out of networking, and doing a product for Autodesk on non-networked PCs.

然後翻了一下 John Nagle 的 Hacker News 帳號,看起來還蠻活躍的?常常 comment 一些東西...

Vector embedding

最近累積起來的東西,都跟 vector embedding 有關,第二篇甚至有提到透過 embedding 切入可以找到不少 LLM 有趣的使用方式:

自己編 llama.cpp 的時候會產生出 embeeding 這隻程式,就可以測試把文字轉成 vector 的功能,接著就可以套用高維空間的數學運算了,像是最常被提到的是利用兩個 vector 的夾角來判斷相似度。

因為是對一堆 vector 處理,就不太需要去管輸出格式的問題 (像是 ChatGPT 會自由輸出任何東西),對程式開發上會方便不少...

Nagle's algorithm + TCP delayed acknowledgment

Hacker News 上看到「It's always TCP_NODELAY (brooker.co.za)」,在講常遇到的 TCP 效能問題,原文在「It’s always TCP_NODELAY. Every damn time.」這邊。

這邊提到了兩個 TCP 上的演算法,Nagle's algorithm 是把小封包積著,等到收到 ack 後再集中丟出去,這樣可以降低 TCP overhead;而 TCP delayed acknowledgment 則是在收到封包後要傳回的 ack 累積起來縮成一個 ack 丟出去 (或是等到 timeout),也是為了降低 TCP overhead。

可以看到這兩者的邏輯上雖然都是想要降低 TCP overhead,但方法剛好會打架。而且這兩個在 Linux 下系統預設都會啟用,所以成立條件不算少見,只要發送方的每個封包都比較小就容易觸發 (大封包的情況則是因為把 buffer 塞滿後就會丟出去,所以就不會延遲)。

這時候遇到 application protocol 很吃 latency 的設計時 (像是 ping-pong 類型的溝通),就容易撞到效能問題。

也因為很常見,所以 Hacker News 上也有好幾個人都有提到他們在工作上解過好幾次。

技術上的解決方案是關掉其中一個就可以了,但可以看到通常都是關掉 Nagle's algorithm (也就是設定 TCP_NODELAY),一方面因為大多數伺服器端的軟體都提供這個選項,改起來比較方便 (因為會被回報);另外一方面是是「趕快把封包送出去」會比「趕快收到 ack」來的有效率...

算是因為網路發展後產生的問題,以前只有 64kbps 專線 (8KB/sec) 的年代會斤斤計較這些東西:一個 IPv4 header 要 20 bytes,TCP header 也要 20 bytes,只傳 1 byte 的資料的確很傷頻寬。

但現在網路環境不太一樣了,尤其是文章裡面提到的環境通常是機房,1Gbps 與 10Gbps 算是常態,遇到 bandwidth 不會吃滿,但很需要 rps (request per second) 數量時,拿之前的演算法就容易中獎了...

LinkedIn 決定要在平台上面弄出遊戲...

也是清連結的消息,三月中的消息,LinkedIn 想要在平台上面弄出遊戲:「LinkedIn plans to add gaming to its platform」。

會是 puzzle 類型的遊戲,而且看起來有東西了:

It will be doing so by tapping into the same wave of puzzle-mania that helped simple games like Wordle find viral success and millions of players. Three early efforts are games called “Queens”, “Inference” and “Crossclimb.”

然後當時跟 LinkedIn 發言人確認也證實了這點:

“We’re playing with adding puzzle-based games within the LinkedIn experience to unlock a bit of fun, deepen relationships, and hopefully spark the opportunity for conversations,” the spokesperson said in a message to TechCrunch. “Stay tuned for more!”

試著走向更一般性的 social network?目前 LinkedIn 上面應該都是雞湯文與 clickbait,這個變化好像有點大...

北韓的動畫承包團隊

2023 年的時候在北韓的 internet 上發現一台沒有設定好的伺服器,於是就有人 dump 下來分析裡面的內容,然後就發現看起來是中國的團隊轉包給北韓團隊用的 server:「What We Learned Inside a North Korean Internet Server: How Well Do You Know Your Partners?」。

像是這張圖,可以看到上面有「EKACHI EPILKA」,這查一下可以查到「株式会社エカチエピルカ」,另外也可以看到簡體中文以及韓文的說明:

雖然拼圖不夠完整,但應該是可以看出輪廓了:目前比較像的情況應該是中國拿到合約後轉包給北韓的團隊,這對於有在關注日本動畫產業的人來說應該也不算太意外,日本的動畫產業已經是高度分工,自己國家內二包三包本來就很常見,如果是先包到中國,再分包到北韓的話也不算太奇怪:

There is no evidence to suggest that the companies identified in the images had any knowledge that a part of their project had been subcontracted to North Korean animators. In fact, as the editing comments on all the files, including those related to US-based animations, were written in Chinese, it is likely that the contracting arrangement was several steps downstream from the major producers.

不過法律上就有些狀況了,北韓應該是被制裁對象...

把 MIT license 當歌詞寫歌...?

在「AI-generated sad girl with piano performs the text of the MIT License (twitter.com/goodside)」這邊看到的推,把 MIT License 的條文當歌詞丟進去寫歌 (應該是最近很紅的 Suno.ai?):

WTF...