Tag: control

TCP 標準被整理到 RFC 9293

看到「RFC 9293: Transmission Control Protocol (TCP)」這篇，主要是把本來分散在各個 RFC 的文件 (從 RFC 793 開始) 全部整理成一份，另外把一些已知的勘誤表放進來：

This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168.

然後淘汰掉 (obselete) 一卡車 RFC 文件 XD

翻資料發現 2014 的時候 HTTP/1.1 被幹過一次類似的事情，不過是反過來被拆開：「HTTP/1.1 的更新」，這次把 RFC 2616 幹掉分成 RFC 7230～RFC 7235。

然後今年因為 HTTP 的關係又被幹了一次，這次 HTTP/1.1 又被整回來變成一份文件，但是把裡面的一些概念拆開：「HTTP 標準的翻新」。

其中 RFC 9110 定義 HTTP Semantics，RFC 9111 定義 HTTP Caching，然後 RFC 9112 與 RFC 9113 拿來定義了 HTTP/1.1 與 HTTP/2，另外先把 HTTP/3 的號碼保留下來的 RFC 9114。

不斷 refactor 以及加新功能的文件...

Git 的「災難處理」

但印象中之前看過 (在 Internet Archive 上可以看到 4 Sep 2017 的版本)，但搜尋 Hacker News 後發現沒有提過... 這幾天紅起來的「Dangit, Git!?!」，也有簡體中文版可以看。

裡面其實提到了很多要怎麼處理不小心塞錯資料進 Git 的情況，不過好像還是有些東西沒涵蓋到，像是遇到不小心塞到 credentials 進去後需要清除掉的 git rebase -i HASH，接著一連串的手動修 conflict 與 git rebase --continue，最後再接上 git push --force 這種禁招...

另外推一下「為你自己學 Git」這本書，裡面其實也有提到類似的情境：

第7章：修改歷史紀錄
7.1 狀況題 修改歷史訊息
7.2 狀況題 把多個 Commit 合併成一個Commit
7.3 狀況題 把一個 Commit 拆解成多個Commit
7.4 狀況題 想要在某些 Commit 之間再加新的Commit
7.5 狀況題 想要刪除某幾個 Commit 或是調整Commit 的順序
7.6 Reset、Revert 跟 Rebase 指令有什麼差別？

這本書也有網頁版，在 gitbook.tw 這邊。

Dolt，本機開發測試用的 MySQL server

看到「Dolt is Git for Data!」這個專案，是個在本機上跑的 MySQL server，另外可以在上面的資料進行版本控制，看起來很適合本機開發測試。

首先抓下來可以看到沒幾個檔案 (這是 linux-amd64 版)，也可以看到跟 Git 的關係：

$ tree
.
├── bin
│   ├── dolt
│   ├── git-dolt
│   └── git-dolt-smudge
└── LICENSES

然後用 bin/dolt sql-server -P 3307 -u root -p passw0rd 跑就可以把一個相容於 MySQL 的伺服器跑在 port 3307，然後用 mysql -h 127.0.0.1 --port 3307 -u root -p 就可以輸入密碼 passw0rd 登入進去：

$ mysql -h 127.0.0.1 --port 3307 -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.7.9-Vitess

可以從 Server version 看到專案是用了 Vitess 實做的 MySQL 界面。

另外測了一下，透過連線所做的變更 (像是 CREATE DATABASE 與 CREATE TABLE，以及 CRUD 中的 CUD) 是不會寫回磁碟裡的，嘗試了不同的設定，不管改什麼都是這樣，應該是故意設計成這樣。

在本機跑 test case 測試應該還不錯，會比 SQLite 的 :memory: 更接近 MySQL 一些，不過在 CI 裡的話應該是可以直接把 MySQL 跑起來...

FreeBSD 要從 Subversion 換到 Git

在 #bsdchat 上面看到 FreeBSD 提供了 Git repository，翻了一下看起來是最近在切換，這邊有翻到慣例的 HEADS UP：「HEADS UP: FreeBSD changing from Subversion to Git this weekend」。

The FreeBSD project will be moving it's source repo from subversion to git starting this this weekend. The docs repo was moved 2 weeks ago. The ports repo will move at the end of March, 2021 due to timing issues.

大概是 2008 年先把 src tree 從 CVS 換到 Subversion 上：「FreeBSD src 部份由 CVS 轉換到 Subversion」。

然後 2012 年把 ports tree 換過去：「FreeBSD ports 將從 CVS 轉移到 Subversion 上...」。

雖然已經很久沒用 FreeBSD 了 (最近碰到最接近的系統應該是 pfSense)，但還是先恭喜他們總算要切換了，兩邊的能量差太多了...

TCP Congestion Control Algorithm 的選擇

先前 Ubuntu 桌機用 BBR 跑了一陣子，但有遇到一些問題 (可以參考「Dropbox 測試 BBRv2 的結果」這篇)，所以暫時換成 Westwood，但還是陸陸續續會看一下各種研究。

剛剛在「[tor-relays] TCP CCA for Tor Relays (and especially Bridges)」這邊看到一個經驗談：

Here are my completely unscientific scribbles of how all the various algorithms behaved. The scenario is uploading for a minute or so, observing the speed in MB/sec visually, then recording how it appeared to change during that minute (and then repeating this a couple of times to be certain).

tcp_bic.ko       -- 6...5...4
tcp_highspeed.ko -- 2
tcp_htcp.ko      -- 1.5...3...2
tcp_hybla.ko     -- 3...2...1
tcp_illinois.ko  -- 6...7...10
tcp_lp.ko        -- 2...1
tcp_scalable.ko  -- 5...4...3
tcp_vegas.ko     -- 2.5
tcp_veno.ko      -- 2.5
tcp_westwood.ko  -- <1
tcp_yeah.ko      -- 2...5...6

上面是「目視法」觀察到的速度 (MB/sec)，看了一下維基百科上 TCP-Illinois 的說明，看起來設計的目的是提供給頻寬大、latency 高的情境下：

It is especially targeted at high-speed, long-distance networks.

來跑跑看好了...

Bitbucket 放棄 Mercurial

Bitbucket 放棄對 Mercurial 的支援：「Sunsetting Mercurial support in Bitbucket」。

兩個時間點，一個是明年二月不能再新增，另外一個是明年六月完全停用：

February 1, 2020: users will no longer be able to create new Mercurial repositories
June 1, 2020: users will not be able to use Mercurial features in Bitbucket or via its API and all Mercurial repositories will be removed.

在 Mercurial 網站上的 wiki 也更新了：「Mercurial Hosting」，對於不想要搬到 Git 的人可以在這份列表裡找替代方案。

Open Distro for Elasticsearch 的比較

先前提到的「AWS 對 Elastic Stack 實作免費的開源版本 Open Distro for Elasticsearch」，在「Open Distro for Elasticsearch Review」這邊有整理了一份重點：

可以看到主要重點都在安全性那塊...

走不同方向的 Git Hosting：sr.ht

看到「sr.ht, the hacker's forge, now open for public alpha」這篇，講 sr.ht 這個 Git Hosting。

文章裡面有提到，目前大多數的 Git Hosting 都很像，不管是 Bitbucket、GitLab、其實大家都是抄 GitHub 的界面與功能抄得很開心...

sr.ht 則是從不同的角度來設計 Git Hosting，避免了大量 js 的界面，但還是提供了很豐富的功能 (支援 markdown 文件、CI、透過 mailing list 討論、有一個 ticket system 可以放各種事項、wiki、...)。

其實還是支援了現在 Git Hosting 常見的功能，只是功能與界面上不太相同而已 XD

又一個 TCP BBR 的測試結果

TCP BBR 是 Google 發表的 TCP congestion control 演算法，是一個純伺服器端就能夠改善 TCP 壅塞處理的機制。在 Linux Kernel 4.9 之後被納入了。

而 Spotify 有大量資料要傳到使用者端 (像是音檔)，剛好是 TCP BBR 改善的對象之一，實際測試後得到了很不錯的改善數據：「Smoother Streaming with BBR」。

Spotify 公佈的資料沒有提到平台，所以先稍微了解一下他的音質，也就是「Audio settings」這篇。

在 Desktop 是 160kbps/320kbps Ogg (Standard/HQ)。在 Web Player 則是 128kbps/256kbps AAC (Standard/HQ)。

行動平台部份比較複雜，在 iOS 上是 96kbps/160kbps/256kbps Ogg (Normal/High/Extreme)，另外有 Automatic 自動調整的設定。在 Android 平台則是 24kbps HE-AACv2 (Low) 與 96kbps/160kbps/320kbps Ogg (Normal/High/Very high) 以及 Automatic。

而最後 Chromecast 則是 128kbps/256kbps (Standard/Premium)。

測試時可以發現 shutter (指跟不上播放速度) 的情況降低了 6%～10%，而且下載速度增加了 5%～7% (對於慢速的裝置改善更多，10%～15%)：

Taking daily averages, stutter decreased 6-10% for the BBR group. Bandwidth increased by 10-15% for the slower download cohorts, and by 5-7% for the median. There was no difference in latency between groups.

而各地區的差異也可以看出來改善很多：

另外他們在測試時，剛好遇到秘魯的機房連外發生問題，結果意外發現 BBR 還是可以穩定在這種網路環境下運作：

In Peru, the non-BBR group saw a 400-500% increase in stutter. In the BBR group, stutter only increased 30-50%.

In this scenario, the BBR group had 4x bandwidth for slower downloads (the 10th percentile), 2x higher median bandwidth, and 5x less stutter!

在 Ubuntu 18.04 上可以直接設定 BBR，在 Ubuntu 16.04 則可以參考「Ubuntu 16.04 用 speedtest-cli 測試 TCP BBR 效能」這篇的方式升級 kernel 後設定 BBR。