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 會幫忙做的事情。
有興趣的別忘了閱讀留言區
socket連線 在 [問題] C Socket Connect 問題!! - 看板C_and_CPP - 批踢踢實業坊 的必吃
各位大大好!!
狀況1:
小弟在寫C Socket 在Server啟動後，Client再啟動
此時第一次連線成功後沒問題!!!
但是我又重新啟動一次Clinet(Server沒重新啟動)這時會連不上線一段一間
之後會
1.連上線(過很長一段時間)
2.完全連不上
狀況2:
當我Server正在連線中時(與Clinet連線中)
我重新啟動Server，再重新啟動Clinet 是可以連的上的
但是我又重新啟動一次Client
之後會
1.連上線(過很長一段時間)
2.完全連不上
請各位幫我想想看是哪邊出了問題?
補一小段程式碼:
stcp = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
setsockopt(stcp, SOL_SOCKET, SO_REUSEADDR,(void*)&enable, sizeof(enable));
setsockopt(stcp, SOL_SOCKET, SO_REUSEPORT,(void*)&enable, sizeof(enable));
感謝各位大大!!!
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.118.206.95
... <看更多>