Linux作為一個強大的操作系統(tǒng)，提供了一系列內(nèi)核參數(shù)供我們進行調(diào)優(yōu)。光TCP的調(diào)優(yōu)參數(shù)就有50多個。在和線上問題斗智斗勇的過程中，筆者積累了一些在內(nèi)網(wǎng)環(huán)境應該進行調(diào)優(yōu)的參數(shù)。在此分享出來，希望對大家有所幫助。

調(diào)優(yōu)清單

好了，在這里先列出調(diào)優(yōu)清單。請記住，這里只是筆者在內(nèi)網(wǎng)進行TCP內(nèi)核參數(shù)調(diào)優(yōu)的經(jīng)驗，僅供參考。同時，筆者還會在余下的博客里面詳細解釋了為什么要進行這些調(diào)優(yōu)!

當然了，這里只列出TCP的部分內(nèi)核參數(shù)，更多web性能上的建議，請看

tcp_max_syn_backlog,somaxconn,tcp_abort_on_overflow

tcp_max_syn_backlog,somaxconn,tcp_abort_on_overflow這三個參數(shù)是關于

內(nèi)核TCP連接緩沖隊列的設置。如果應用層來不及將已經(jīng)三次握手建立成功的TCP連接從隊列中取出,溢出了這個緩沖隊列(全連接隊列)之后就會丟棄這個連接。如下圖所示:

從而產(chǎn)生一些詭異的現(xiàn)象,這個現(xiàn)象詭異之處就在于，是在TCP第三次握手的時候丟棄連接

就如圖中所示,第二次握手的SYNACK發(fā)送給client端了。所以就會出現(xiàn)client端認為連接成功，而Server端確已經(jīng)丟棄了這個連接的現(xiàn)象!由于無法感知到Server已經(jīng)丟棄了連接。

所以如果沒有心跳的話，只有在發(fā)出第一個請求后，Server才會發(fā)送一個reset端通知這個連接已經(jīng)被丟棄了，建立連接后第二天再用，也會報錯!所以我們要調(diào)大Backlog隊列!

echo 2048 > /proc/sys/inet/ipv4/tcp_max_syn_backlog
echo 2048 > /proc/sys/net/core/somaxconn

當然了，為了盡量避免第一筆調(diào)用失敗問題，我們也同時要設置

echo 1 > /proc/sys/net/ipv4/tcp_abort_on_overflow

設置這個值以后，Server端內(nèi)核就會在這個連接被溢出之后發(fā)送一個reset包給client端。

如果我們的client端是NIO的話，就可以收到一個socket close的事件以感知到連接被關閉!

注意Java默認的Backlog是50

這個TCP Backlog的隊列大小值是min(tcp_max_syn_backlog,somaxconn,應用層設置的backlog),而Java如果不做額外設置，Backlog默認值僅僅只有50。C語言在使用listen調(diào)用的時候需要傳進Backlog參數(shù)。

tcp_tw_recycle

tcp_tw_recycle這個參數(shù)一般是用來抑制TIME_WAIT數(shù)量的,但是它有一個副作用。即在tcp_timestamps開啟(Linux默認開啟)，tcp_tw_recycle會經(jīng)常導致下面這種現(xiàn)象。

也即，如果你的Server開啟了tcp_tw_recycle，那么別人如果通過NAT之類的調(diào)用你的Server的話，NAT后面的機器只有一臺機器能正常工作，其它情況大概率失敗。具體原因呢由下圖所示:

在tcp_tw_recycle=1同時tcp_timestamps(默認開啟的情況下),對同一個IP的連接會做這樣的限制，也即之前后建立的連接的時間戳必須要大于之前建立連接的最后時間戳，但是經(jīng)過NAT的一個IP后面是不同的機器，時間戳相差極大，就會導致內(nèi)核直接丟棄時間戳較低的連接的現(xiàn)象。由于這個參數(shù)導致的問題，高版本內(nèi)核已經(jīng)去掉了這個參數(shù)。如果考慮TIME_WAIT問題，可以考慮設置一下

echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse

tcp_syn_retries

這個參數(shù)值得是client發(fā)送SYN如果server端不回復的話，重傳SYN的次數(shù)。對我們的直接影響呢就是connet建立連接時的超時時間。當然Java通過一些C原生系統(tǒng)調(diào)用的組合使得我們可以進行超時時間的設置。在Linux里面默認設置是5,下面給出建議值3和默認值5之間的超時時間。

下圖給出了，重傳和超時情況的對應圖:

當然了，不同內(nèi)核版本的超時時間可能不一樣，因為初始RTO在內(nèi)核小版本間都會有細微的變化。所以，有時候在抓包時候可能會出現(xiàn)(3,6,12……)這樣的序列。當然Java的API有超時時間:

java:
 // 函數(shù)調(diào)用中攜帶有超時時間
 public void connect(SocketAddress endpoint, int timeout) ;

所以，對于Java而言，這個內(nèi)核參數(shù)的設置沒有那么重要。但是，有些代碼可能會有忘了設置timeout的情況，例如某個版本的Kafka就是，所以它在我們一些混沌測試的情況下，容災恢復的時間會達到一分多鐘，主要時間就是卡在connect上面-_-!，而這時我們的tcp_syn_retries設置的是5，也即超時時間63s。減少這個恢復時間的手段就是:

echo 3 > /proc/sys/net/ipv4/tcp_syn_retries

tcp_retries2

這個參數(shù)表面意思是在傳輸過程中tcp的重傳次數(shù)。但在某個版本之后Linux內(nèi)核僅僅用這個tcp_retries2來計算超時時間，在這段時間的重傳次數(shù)純粹由RTO等環(huán)境因素決定，重傳超時時間在5/15下的表現(xiàn)為:

如果我們在應用層設置的Socket所有ReadTimeout都很小的話(例如3s),這個內(nèi)核參數(shù)調(diào)整是沒有必要的。但是，筆者經(jīng)常發(fā)現(xiàn)有的系統(tǒng)，因為一兩個慢的接口或者SQL，所以將ReadTimeout設的很大的情況。

平常這種情況是沒有問題的，因為慢請求頻率很低，不會對系統(tǒng)造成什么風險。但是，物理機突然宕機時候的情況就不一樣了，由于ReadTimeOut設置的過大，導致所有落到這臺宕機的機器都會在min(ReadTimeOut,(924.6s-1044.6s)(Linux默認tcp_retries2是15))后才能從read系統(tǒng)調(diào)用返回。假設ReadTimeout設置了個5min，系統(tǒng)總線程數(shù)是200，那么只要5min內(nèi)有200個請求落到宕機的server就會使A系統(tǒng)失去響應!

但如果將tcp_retries2設置為5,那么超時返回時間即為min(ReadTimeOut 5min,25.6-51.2s),也就是30s左右，極大的緩解了這一情況。

echo 5 > /proc/sys/net/ipv4/tcp_retries2

但是針對這種現(xiàn)象，最好要做資源上的隔離,例如線程上的隔離或者機器級的隔離。

golang的goroutine調(diào)度模型就可以很好的解決線程資源不夠的問題，但缺點是goroutine里面不能有阻塞的系統(tǒng)調(diào)用，不然也會和上面一樣，但僅僅對于系統(tǒng)之間互相調(diào)用而言，都是非阻塞IO,所以golang做微服務還是非常Nice的。當然了我大Java用純IO事件觸發(fā)編寫代碼也不會有問題，就是對心智負擔太高-_-!

物理機突然宕機和進程宕不一樣

值得注意的是，物理機宕機和進程宕但內(nèi)核還存在表現(xiàn)完全不一樣。

僅僅進程宕而內(nèi)核存活，那么內(nèi)核會立馬發(fā)送reset給對端，從而不會卡住A系統(tǒng)的線程資源。

tcp_slow_start_after_idle

還有一個可能需要調(diào)整的參數(shù)是tcp_slow_start_after_idle，Linux默認是1，即開啟狀態(tài)。開啟這個參數(shù)后，我們的TCP擁塞窗口會在一個RTO時間空閑之后重置為初始擁塞窗口(CWND)大小，這無疑大幅的減少了長連接的優(yōu)勢。對應Linux源碼為:

static void tcp_event_data_sent(struct tcp_sock *tp,
                struct sk_buff *skb, struct sock *sk){
    // 如果開啟了start_after_idle,而且這次發(fā)送的時間-上次發(fā)送的時間>一個rto，就重置tcp擁塞窗口
    if (sysctl_tcp_slow_start_after_idle &&
        (!tp->packets_out && (s32)(now - tp->lsndtime) > icsk->icsk_rto))
        tcp_cwnd_restart(sk, __sk_dst_get(sk));
}

關閉這個參數(shù)后，無疑會提高某些請求的傳輸速度(在帶寬夠的情況下)。

echo 0 > /proc/sys/net/ipv4/tcp_slow_start_after_idle

當然了，Linux啟用這個參數(shù)也是有理由的，如果我們的網(wǎng)絡情況是時刻在變化的，例如拿個手機到處移動，那么將擁塞窗口重置確實是個不錯的選項。但是就我們內(nèi)網(wǎng)系統(tǒng)間調(diào)用而言，是不太必要的了。

初始CWND大小

毫無疑問，新建連接之后的初始TCP擁塞窗口大小也直接影響到我們的請求速率。在Linux2.6.32源碼中，其初始擁塞窗口是(2-4個)mss大小，對應于內(nèi)網(wǎng)估計也就是(2.8-5.6K)(MTU 1500)，這個大小對于某些大請求可能有點捉襟見肘。

在Linux 2.6.39以上或者某些RedHat維護的小版本中已經(jīng)把CWND

增大到RFC 6928所規(guī)定的的10段，也就是在內(nèi)網(wǎng)里面估計14K左右(MTU 1500)。

Linux 新版本/* TCP initial congestion window */#define TCP_INIT_CWND 10

總結

Linux提供了一大堆內(nèi)參參數(shù)供我們進行調(diào)優(yōu)，其默認設置的參數(shù)在很多情況下并不是最佳實踐，所以我們需要潛心研究，找到最適合當前環(huán)境的組合。