ref: https://lwn.net/Articles/853637/

如果對 SO_REUSEPORT 這個能夠提供網路服務吞吐量的 socket options 不陌生的話，那這篇文章強烈推薦看看。
本篇文章是從討論開啟 SO_REUSEPORT 這個選項會出現的一些行為以及可能可以怎麼做

最直得看的應該是留言區本身，有很多不同層級的討論，大家最愛講的 Google SRE 人也都出來分享自己的經驗了。

正常情況下，每個 TCP Port 只能被一個 process 給使用來聽取封包，但是對於一些網路重度使用的系統來說，就算讓該 process 將連線給分散到其他的 process 去處理，該 process 依然可能是系統的效能瓶頸。
Linux Kernel 3.9 後引入的 SO_REUSEPORT 參數就是為了解決這個效能問題而來的，這個參數允許多個 Process 同時使用一個 TCP Port，每當底層有一條新的連線請求時， Kernel 會從眾多的候選人之一中挑選一個可用來處理。
這種情況下，網路應用程式就可以專心處理連線工作，然後實務上同時執行多個 Process 即可。底層的 Kernel 會幫忙做連線的負載分配。

當眾多候選 process 其中之一掛掉了(可能是 crash，也有可能是有意的重啟)， kernel 會注意到這個候選人要說掰掰，這候選人處理的所有 connection 都會被移除，比較糟糕的是其他待在 Accept-Queue 那些還沒被建立連線的連線請求也會一併被移除。
作者認為 Kernel 應該要有能力可以轉移那些 Accept-queue 中的連線到其他還工作的候選 process 下去處理，這樣使用者/Client 的連線就不會需要處理太多重連的問題。

文章後面都在探討可行的做法以及這個問題可能會導致什麼問題。

留言區滿熱鬧的，譬如說
1. 有人認為 server 重啟的情況實在太少見，有需要為這麽少見的情況導入這麼複雜的修改到 Kernel 中?
a. 有人回答使用 Let's Encrypt 你可能每幾週就要重啟一次。
b. Google SRE 回答其內部因為調整設定的緣由，幾乎無時無刻都需要重啟服務，不過這問題已經從別的層級去處理掉，所以修改 Kernel 對他們的用途不太大。
2. 有人提出 Nginx 本身有 live migration 的功能，可以將 fd 給轉移到其他的 process 去處理。
a. 有人提出這邊談的是 socket/connection 的層級，這些東西都還沒發生到 userspace process 同時也不是 userspace 應用程式可以接觸處理的。
b. 本文探討的是 bind(), accept(), listen() 這類型 function call 之間 kernel 會幫忙做的事情。

有興趣的別忘了閱讀留言區

本篇文章要來探討 Kubernetes/Docker 一些關於 connection timeout 的事情，文章非常長，這邊幫大家重點整理

1. 跟我之前分享的 DNS timeout 問題類似，都會踩到 Kernel 的 race condition，都是 __ip_conntrack_confirm 這個人丟掉大家封包的
2. 本文著重於怎麼發現這個問題，如何減緩這個問題。對於喜歡研究細節的人值得一看。
3. 2017年底作者團隊開始將服務遷移到 Kubernetes (v1.8), Flannel(1.9.0)，開始發現團隊中基於 Scala 的應用程式出現封包 timeout 的問題，這導致部分請求回應都延遲1-3秒
4. 決定認真調查網路問題，經由研究與錄製封包後發現 TCP 重送(SYN)的現象，該現象導致第一個封包會特別慢
5. 接下來要縮小範圍，使用環境中的一個VM作為基底，上面安裝 docker，開始觀察相關的網路流量與封包，發現可以重製這個行為，第一個封包從容器出去後，宿主機上面的真實網卡卻看不到，直到下次第二個封包就可以。藉由這個行為他們判斷，問題出在VM上，跟底層其餘硬體架構無關，藉此縮小問題範圍。
6. 介紹 iptalbes + SNAT + conntrack
7. 問題發生在 Kernel 裡面針對 SNAT 去選擇對外 source IP 時會出錯，因為(1)挑選一個適當的 source port, (2)將該紀錄寫到 conntrack 這兩個步驟中間會有落差，因此如果兩個封包同時進入(1)，選到一樣的結果，後續要跑(2)就會有一個人寫不進去，導致封包被丟棄
8. 一種解決方法是告訴 kernel 請隨機幫我挑選對外的 source port, 這樣就算大家同時執行(1)，有很大的機會會挑到不同的 source port，藉此減少衝突的機會。
9. iptables 執行 --masquerate 的時候可以下 --random-fully 這個參數
10. 團隊當時客製化 Flannel 來解決這個問題

註: 對 SNAT 有興趣瞭解的可以參考我之前撰寫的 SNAT Kernel 原始碼閱讀文章
https://www.hwchiu.com/iptables-masquerade.html
https://www.hwchiu.com/iptables-masquerade-handson.html

https://tech.xing.com/a-reason-for-unexplained-connection-timeouts-on-kubernetes-docker-abd041cf7e02

想在 30 分鐘內學會 Git 嗎？看這裡就對了！

Git 是一種「原始碼版本控制」軟體，它可以儲存原始碼每個版本之間的差異，然後您可以要求「時光回溯」到任何指定的版本。這可以防止一天到晚改規格的客戶或老闆，在您辛苦更動原始碼後，來一句要命的：「還是之前的那一版比較好」。我個人認為，它是程式設計中，最重要的 7 大軟體之一（文字編輯器、編譯器、版本控制器、自動化建構系統、單元測試軟體、環境佈建系統、與除錯器）。

這類「版本控制軟體」，依照流行先後，著名的有 CVS、Subversion、與 Git。目前最流行的版本控制軟體是「Git」，流行原因多多少少是因為 Linux 核心（Linux Kernel）原始碼，就是用這套軟體保持各個版本差異的。不少公司也要求程式設計師寫好原始碼後，一律都得回存 Git 系統才算完工，不能只是存在私人的硬碟就了事。所以 Git 就變成業界必備的軟體之一。

補習班常常有同學問我，有沒有那種很簡單的 Git 說明書，不用講太深，但要在 30 ~ 60 分鐘內就掌握常用功能的教材？之前一直找不到，不過今天幫大家找到了！還有中文版喔！叫做「Git 簡明指南」。鏈結如下：

https://rogerdudler.github.io/git-guide/index.zh.html

其實它的原文名稱有點好玩：「Git - The Simple Guide, No Deep Shit!」。這類標題通常能騷動我個性中愛作怪的小惡魔，讓我會心一笑後點進去看看。看完後，果然「一點點深的便便」都沒有... XD 還有中文版（簡中）！心想這麼讚的東西不介紹怎麼行！就花時間寫了這一篇。

希望今天的分享對各位的日常工作有幫助！我也很鼓勵大家能找到適合自己的「七大系統」，把它弄熟。畢竟「工欲善其事，必先利其器」嘛！我個人習慣使用的七大系統，也列在底下讓大家參考：

1. 文字編輯器：vim。不好學，但游標移動速度與文字操控能力超快！
2. 編譯器：gcc。因為我寫 C 語言比較多，所以用 gcc。
3. 版本控制器：git。其實我之前是熟 subversion。不過 git 也很好用喔！
4. 自動化建構系統：make。可以把編譯、安裝...等囉哩八唆的指令濃縮成一個簡稱（如：build, install...等）。打完按下 enter 後就可以去泡咖啡了！還能偵測哪些原始碼已經編譯過，不需重新編譯已縮短作業時間。
5. 單元測試軟體：CUnit。嚴格來說，這算一套「函式庫」，可以針對你寫好的原始碼做測試。由於我寫 C 較多，所以用 CUnit。如果您寫的程式碼是 Java 或其它，可能得找相對應的測試軟體。
6. 環境佈建軟體：VirtualBox。用它的原因是 Win, Mac, Linux 全平台都支援。我會把程式設計環境灌好後的 VirtualBox 映像檔保存好，每次要乾淨環境就 new 一個新的虛擬機起來。最近迷上 Vagrant，想知道 Vagrant 是什麼的可以看這篇： http://goo.gl/29mBs9
7. 除錯器：gdb。雖然是文字介面，但連線到運算能力很差的開發板上想除錯，也只有 gdb 跑得動。用久了也習慣了。

其實最近還想加上第八項「(8) 軟體部署系統：Docker」，不過還在研究，也還沒熟悉。等熟悉了再跟大家報告。 :-)

如果覺得文章不錯，還煩請各位不吝按讚打賞或分享一下喔！ m(^ ^)m