慎用TCP的選項SO LINGER

最近有一次效能測試，通訊程式出現錯誤，表現為伺服器處理速度明顯降低，檢查發現伺服器的很多控制代碼出於time_wait狀態，justin這個流氓的自己承認測試用例寫的有問題，在recv函式返回0後，沒有close控制代碼。

我很鬱悶google了一下如何處理這類錯誤，發現了so_linger這個選項，發現這個選項可以避免埠的狀態進入time_wait狀態，大膽的進行了一下測試。發現在效能測試中，伺服器的表現好了不少，暗爽。

//使用so_linger，close後不進入time_wait狀態

struct linger linger;

linger.l_onoff = 1;

linger.l_linger = 0;

setsockopt(serversocket,

sol_socket, so_linger,

(const char *) &linger,

sizeof(linger));

周3發版本，突然發現很多同事的都報告出現了一些錯誤，從客戶端的日誌反饋看，客戶端在最後階段往往沒有收到幾個我們的伺服器的返回命令，於是立即想到了可能是這個選項導致了麻煩。注釋這個選項後，果然大家的程式都正常了。

回頭仔細讀了一下《unix網路程式設計》卷1，才慢慢回想起來，time_wait的作用是保證在主動關閉埠後，保證資料讓對端收到，richard.steven的原話是」time_wait是我們的朋友。」

由於我們客戶端要和多個遊戲伺服器通訊，而且之間還有一些時序關係，所以我們不能使用這種讓使用者丟棄一部分資料的方式。對於tcp的細節感覺還是不熟悉，呵呵。

不能丟棄time_wait狀態，但是讓他縮短一些也是可以的。我們可以在l_linger引數上動點手腳，當l_onoff非0是。l_linge也非0的時候，套介面在time_wait上將拖延一段時間，l_linger秒，而不再是2msl的超時[注]。我也打算繼續試驗一下。

【注】，根據《unix網路程式設計》卷1，需要注意的是，l_linger非0的解釋在不同的平台可能不一樣，bsd平台的實現是0.01s。