已经被废弃的 tcp_tw_recycle
最近準備自己動手部署測試kubernetes集群，注備寫一個 hands on 的手冊。突發奇想將 centos 原有的內核從3.10更新到了4.14版本，并執行一些常規的優化操作。沒有想到在修改了 sysctl.conf 里面的一些參數，希望能對新的 kubernetes 性能有所幫助。
當我在其中一臺 node 節點 執行 sysctl -p 的時候發現如下錯誤：
sysctl: cannot stat /proc/sys/net/ipv4/tcp_tw_recycle: No such file or directory
納尼，沒有tcp_tw_recycle這個參數了？ 怎么回事。。。
net.ipv4.tcp_tw_reuse = 0? 表示開啟重用。允許將TIME-WAIT sockets重新用于新的TCP連接，默認為0，表示關閉
net.ipv4.tcp_tw_recycle = 0? 表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認為0，表示關閉
net.ipv4.tcp_fin_timeout = 60? 表示如果套接字由本端要求關閉，這個參數決定了它保持在FIN-WAIT-2狀態的時間（可改為30，一般來說FIN-WAIT-2的連接也極少）
好像上面3個內核調整參數，都是很多 Linux 運維工程師的標配了，怎么我一升級內核就不行了？ 自己狠下心來好好去的看了 kernel 的文檔，Linux 從4.12內核版本開始移除了 tcp_tw_recycle 這個參數。 好嘛，小弟我手賤賤，升級到了4.14現在沒有這個參數，只能硬著頭皮去掉。
但是這個參數對 linux 系統回收大量 tcp timeout wait 有幫助，tcp_tw_recycle通常會和tcp_tw_reuse參數一起使用，用于解決服務器TIME_WAIT狀態連接過多的問題。 但是 kernel 為什么又要取消掉呢？?
簡單來說就是，Linux會丟棄所有來自遠端的timestramp時間戳小于上次記錄的時間戳(由同一個遠端發送的)的任何數據包。也就是說要使用該選項，則必須保證數據包的時間戳是單調遞增的。同時從4.10內核開始，官方修改了時間戳的生成機制，所以導致?tcp_tw_recycle 和新時間戳機制工作在一起不那么友好，同時?tcp_tw_recycle 幫助也不那么的大。
此處的時間戳并不是我們通常意義上面的絕對時間，而是一個相對時間。很多情況下，我們是沒法保證時間戳單調遞增的，比如業務服務器之前部署了NAT，LVS等情況。相信很多小伙伴上班的公司大概率實用實用各種公有云，而各種公有云的 LVS 網關都是 FullNAT 。所以可能導致在高并發的情況下，莫名其妙的 TCP 建聯不是那么順暢或者丟連接。
而這也是很多優化文章中并沒有提及的一點，大部分文章都是簡單的推薦將net.ipv4.tcp_tw_recycle設置為1，卻忽略了該選項的局限性，最終造成嚴重的后果(比如我們之前就遇到過部署在nat后端的業務網站有的用戶訪問沒有問題，但有的用戶就是打不開網頁)。
想深究原因？ 讓我們一起來看看到底為什么，一起往底層看看。。。。
?
TCP 狀態機
這次我們要關注的不是上半部分的 TCP 新建連接，而是下半部分的 TCP 斷開連接。 別人老談 TCP 3次握手，我就來談 TCP 4次“揮手告別”。
在說 TCP 斷開連接之前，我想先插入點內容。 就是為什么要在 TCP 傳輸種引入 TIMEWAIT 這個概念。
第一個作用就是避免新連接接收到重復的數據包，由于使用了時間戳，重復的數據包會因為時間戳過期被丟棄。
第二個作用是確保遠端不是處于LAST-ACK狀態，如果ACK包丟失，遠端沒有成功獲取到最后一個ACK包，則會重發FIN包。直到：
1.放棄(連接斷開)
2.收到ACK包
3.收到RST包
如果FIN包被及時接收到，并且本地端仍然是TIME-WAIT狀態，那ACK包會被發送，此時就是正常的四次揮手流程。
如果TIME-WAIT的條目已經被新連接所復用，則新連接的SYN包會被忽略掉，并且會收到FIN包的重傳，本地會回復一個RST包(因為此時本地連接為SYN-SENT狀態)，這會讓遠程端跳出LAST-ACK狀態，最初的SYN包也會在1秒后重新發送，然后完成連接的建立，整個過程不會中斷，只是有輕微的延遲。流程如下:
?
?
TIMEWAIT 流程圖
?
BB 嘮叨了這么半天，我們回到正題，看看下面的一個完整 TCP 斷開連接的過程：
?
TCP 4次揮手告別
?
TIME_WAIT永遠是出現在主動發送斷開連接請求的一方(下文中我們稱之為客戶)，劃重點：這一點面試的時候經常會被問到。 嘿嘿，這個可以做為面試官的殺手锏，上圖邏輯保證好多人不知道。（我咋這么壞呢。。。）
客戶在收到服務器端發送的FIN(表示"我們也要斷開連接了")后發送ACK報文，并且進入TIME_WAIT狀態，等待2MSL(MaximumSegmentLifetime 最大報文生存時間)。對于Linux，字段為TCP_TIMEWAIT_LEN硬編碼為30秒，對于Windows為2分鐘(可自行調整)。
說到?TCP_TIMEWAIT_LEN 這個我就多啰嗦幾句，很多資深運維小伙伴，在早起為了加快 tcp timeout 的回收時間，經常會修改這個內核頭文件中定義的宏數據，然后重編譯內核。 說實話確實有一些用處，至少早起阿里很多基礎平臺的運維就是這么干的，至于其他大廠不得而知，這個仁者見仁吧。
客戶端 TCP連接 “揮手告別”，為什么客戶端不直接進入CLOSED狀態，而是要在TIME_WAIT等待那么久呢，我猜主要是基于如下考慮：
1. 確保遠程端（服務端）能夠正確處于關閉狀態
?
Ack 包異常丟棄?
? ? 確保 TCP 連接在各種情況下，都能正常的關閉。我們的網絡 IP 協議本身就是盡力而為的傳輸，所有傳輸的可靠性都是靠 TCP 協議棧來完成的。假如當 TCP 自身傳輸信令的過程中也出現了一些異常呢？ 是不是我們 TCP 傳輸協議本身需要一定的容錯機制。
2.?防止上一次連接中的包，又重新收到，影響新連接
?
正常連接中，出現了 SEQ3 異常重新收到
又回到了上面說到的 IP 網絡本身盡力而為的傳輸機制，并不保證數據包在底層傳輸的時候，接收方收到的數據包的數據順序不一定是按照發送方的順序，再加上數據傳輸延遲，就讓上圖的問題發生的情況成為了大概率事件。
說了這么多，TCP TIMEWAIT 在一個服務器上大量堆積有什么危害嗎？?
1.占用連接資源
TIME_WAIT占用的1分鐘時間內，相同四元組(源地址，源端口，目標地址，目標端口)的連接無法創建，通常一個ip可以開啟的端口為net.ipv4.ip_local_port_range指定的32768-61000，如果TIME_WAIT狀態過多，會導致無法創建新連接。
2.占用內存資源
這個占用資源并不是很多，可以不用擔心。 （現在服務器內存真心多，不怕。 如果你實用的虛擬機，而且還是短鏈接巨多，內存分配不那么充足的情況下，還要節省成本， 那就要當心咯）
那我們如何解決這樣的問題：
1.修改為長連接，代價較大，長連接對服務器性能有影響。
2.增加可用端口范圍(修改net.ipv4.ip_local_port_range); 增加服務端口，比如采用80，81等多個端口提供服務; 增加客戶端ip(適用于負載均衡，比如nginx，采用多個ip連接后端服務器); 增加服務端ip; 這些方式治標不治本，只能緩解問題。
3.將net.ipv4.tcp_max_tw_buckets設置為很小的值(默認是18000). 當TIME_WAIT連接數量達到給定的值時，所有的TIME_WAIT連接會被立刻清除，并打印警告信息。但這種粗暴的清理掉所有的連接，意味著有些連接并沒有成功等待2MSL，就會造成通訊異常。
4.修改TCP_TIMEWAIT_LEN值，減少等待時間，但這個需要修改內核并重新編譯。（這個之前提過，有某個大廠的小伙伴之前這么做的，有效果，但是有其他負面情況，我沒有做完整的評估，自己斟酌實用）
5.打開tcp_tw_recycle和tcp_timestamps選項。
6.打開tcp_tw_reuse和tcp_timestamps選項。
注意，注意，注意，重要的事情說三遍。 5和6之間只能選擇一個，不能同時打開。
個人的一點小建議：
tcp_tw_recycle 選項在4.10內核之前還只是不適用于NAT/LB的情況(其他情況下，我們也非常不推薦開啟該選項)，但4.10內核后徹底沒有了用武之地，并且在4.12內核中被移除.
tcp_tw_reuse 選項仍然可用。在服務器上面，啟用該選項對于連入的TCP連接來說不起作用，但是對于客戶端(比如服務器上面某個服務以客戶端形式運行，比如nginx反向代理)等是一個可以考慮的方案。
修改TCP_TIMEWAIT_LEN是非常不建議的行為。
作者：自在的LEE
鏈接：https://www.jianshu.com/p/25e99b2d1956
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
總結
以上是生活随笔為你收集整理的已经被废弃的 tcp_tw_recycle的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 完整制作网吧系统全过程
- 下一篇： Trapcode Particular