一直以來我們都知道socket的緩存會對tcp性能產(chǎn)生影響，也有無數(shù)文章告訴我們應(yīng)該調(diào)大socke緩存。但是究竟調(diào)多大？什么時候調(diào)？有哪些手段調(diào)？具體影響究竟如何？這些問題似乎也沒有人真正說明白。下面我們就構(gòu)建起一個簡單的實驗環(huán)境，在兩臺虛擬機之間探究一下Socket緩存究竟如何影響TCP的性能？對分析過程不感興趣的可以直接看最后的結(jié)論。

影響Socket緩存的參數(shù)

首先，我們要先來列出Linux中可以影響Socket緩存的調(diào)整參數(shù)。在proc目錄下，它們的路徑和對應(yīng)說明為：

/proc/sys/net/core/rmem_default
/proc/sys/net/core/rmem_max
/proc/sys/net/core/wmem_default
/proc/sys/net/core/wmem_max

這些文件用來設(shè)置所有socket的發(fā)送和接收緩存大小，所以既影響TCP，也影響UDP。

針對UDP：

這些參數(shù)實際的作用跟 SO_RCVBUF 和 SO_SNDBUF 的 socket option 相關(guān)。如果我們不用setsockopt去更改創(chuàng)建出來的 socket buffer 長度的話，那么就使用 rmem_default 和 wmem_default 來作為默認(rèn)的接收和發(fā)送的 socket buffer 長度。如果修改這些socket option的話，那么他們可以修改的上限是由 rmem_max 和 wmem_max 來限定的。

針對TCP：

除了以上四個文件的影響外，還包括如下文件：

/proc/sys/net/ipv4/tcp_rmem

/proc/sys/net/ipv4/tcp_wmem

對于TCP來說，上面core目錄下的四個文件的作用效果一樣，只是默認(rèn)值不再是 rmem_default 和 wmem_default ，而是由 tcp_rmem 和 tcp_wmem 文件中所顯示的第二個值決定。通過setsockopt可以調(diào)整的最大值依然由rmem_max和wmem_max限制。

查看tcp_rmem和tcp_wmem的文件內(nèi)容會發(fā)現(xiàn)，文件中包含三個值：

三個值依次表示：min default max

min：決定 tcp socket buffer 最小長度。

default：決定其默認(rèn)長度。

max：決定其最大長度。在一個tcp鏈接中，對應(yīng)的buffer長度將在min和max之間變化。導(dǎo)致變化的主要因素是當(dāng)前內(nèi)存壓力。如果使用setsockopt設(shè)置了對應(yīng)buffer長度的話，這個值將被忽略。相當(dāng)于關(guān)閉了tcp buffer的動態(tài)調(diào)整。

/proc/sys/net/ipv4/tcp_moderate_rcvbuf

這個文件是服務(wù)器是否支持緩存動態(tài)調(diào)整的開關(guān)，1為默認(rèn)值打開，0為關(guān)閉。

另外要注意的是，使用 setsockopt 設(shè)置對應(yīng)buffer長度的時候，實際生效的值將是設(shè)置值的2倍。

當(dāng)然，這里面所有的rmem都是針對接收緩存的限制，而wmem都是針對發(fā)送緩存的限制。

我們目前的實驗環(huán)境配置都采用默認(rèn)值：

另外需要說明的是，我們目前的實驗環(huán)境是兩臺虛擬機，一個是centos 8，另一個是fedora 31：

我們將要做的測試也很簡單，我們將在centos 8上開啟一個web服務(wù)，并共享一個bigfile。然后在fedora 31上去下載這個文件。通過下載的速度來觀察socket緩存對tcp的性能影響。我們先來做一下基準(zhǔn)測試，當(dāng)前在默認(rèn)設(shè)置下，下載速度為：

bigfile是個1G的文件，在同一個宿主機的兩個虛擬機之間，他們的傳輸速率達到了337MB/s。這是當(dāng)前基準(zhǔn)環(huán)境狀態(tài)。影響虛擬機之間的帶寬的因素較多，我們希望在測試過程中盡量避免其他因素干擾。所以這里我們打算對web服務(wù)器的80端口進行限速。為了不影響其他進程的速率，我們使用htb進行限速，腳本如下：

使用htb給網(wǎng)絡(luò)流量做了2個分類，針對80端口的流量限制了1000mbit/s的速率限制，其他端口是20000mbit/s的限制，這在當(dāng)前環(huán)境下相當(dāng)于沒有限速。之后，我們在centos 8的web服務(wù)器上執(zhí)行此腳本并在fedora 31上測試下載速率：

1000mbit的速率限制基本符合要求。

那么問題來了，此時socket緩存在這個1000mbit的帶寬限制下，對tcp的傳輸性能有什么影響呢？

如果你喜歡折騰的話，你可以在這個環(huán)境上分別調(diào)大調(diào)小客戶端和服務(wù)端的緩存大小來分別測試一下，你會發(fā)現(xiàn)，此時對socket的緩存大小做任何調(diào)整，似乎對tcp的傳輸效率都沒有什么影響。

所以這里我們需要先分析一下，socket緩存大小到底在什么情況下會對tcp性能有影響？

緩存對讀寫性能的影響

這其實是個通用問題：緩存到底在什么情況下會影響讀寫性能？

**答案也很簡單：在讀寫的相關(guān)環(huán)節(jié)之間有較大的性能差距時，緩存會有比較大的影響。**比如，進程要把數(shù)據(jù)寫到硬盤里。因為硬盤寫的速度很慢，而內(nèi)存很快，所以可以先把數(shù)據(jù)寫到內(nèi)存里，然后應(yīng)用程度寫操作就很快返回，應(yīng)用程序此時覺得很快寫完了。后續(xù)這些數(shù)據(jù)將由內(nèi)核幫助應(yīng)用把數(shù)據(jù)從內(nèi)存再寫到硬盤里。

無論如何，當(dāng)寫操作產(chǎn)生數(shù)據(jù)的速度，大于實際要接受數(shù)據(jù)的速度時，buffer才有意義。

在我們當(dāng)前的測試環(huán)境中，數(shù)據(jù)下載時，web服務(wù)器是數(shù)據(jù)發(fā)送方，客戶端是數(shù)據(jù)接收方，中間通過虛擬機的網(wǎng)絡(luò)傳輸。在計算機上，一般原則上講，讀數(shù)據(jù)的速率要快于寫數(shù)據(jù)的速率。所以此時兩個虛擬機之間并沒有寫速率大于度速率的問題。所以此時，調(diào)整socket緩存對tcp基本不存在性能影響。

那么如何才能讓我們的模型產(chǎn)生影響呢？

答案也很簡單，給網(wǎng)絡(luò)加比較大的延時就可以了。如果我們把每個tcp包的傳輸過程當(dāng)作一次寫操作的話，那么網(wǎng)絡(luò)延時變大將導(dǎo)致寫操作的處理速度變長。網(wǎng)絡(luò)就會成為應(yīng)用程序?qū)懰俣鹊钠款i。我們給我們的80端口再加入一個200ms的延時：

再次在web服務(wù)器上執(zhí)行此腳本，在客戶端fedora 31上在延時前后使用httping測量一下rtt時間：

200ms的網(wǎng)絡(luò)延時，體現(xiàn)在http協(xié)議上會有400ms的rtt時間。此時，網(wǎng)絡(luò)的速率會成為傳輸過程的瓶頸，雖然帶寬沒有下降，但是我們測試一下真實下載速度會發(fā)現(xiàn)，帶寬無法利用滿了：

下載速率穩(wěn)定在13.4MB/s，離1000mbit/s的真實速率還差的很遠(yuǎn)。此時就體現(xiàn)出了tcp在大延時網(wǎng)絡(luò)上的性能瓶頸了。那么如何解決呢？

大延時網(wǎng)絡(luò)提高TCP帶寬利用率

我們先來分析一下當(dāng)前的問題，為什么加大了網(wǎng)絡(luò)延時會導(dǎo)致tcp帶寬利用率下降？

因為我們的帶寬是1000mbit/s，做個換算為字節(jié)數(shù)是125mB/s，當(dāng)然這是理論值。為了運算方便，我們假定網(wǎng)絡(luò)帶寬就是100mB/s。在這樣的帶寬下，假定沒有buffer影響，網(wǎng)絡(luò)發(fā)送1m數(shù)據(jù)的速度需要10ms，之后這1m數(shù)據(jù)需要通過網(wǎng)絡(luò)發(fā)送給對端。然后對端返回接收成功給服務(wù)端，服務(wù)端接收到寫成功之后理解為此次寫操作完成，之后發(fā)送下一個1m。

在當(dāng)前網(wǎng)絡(luò)上我們發(fā)現(xiàn)，1m本身之需10ms，但是傳輸1m到對端在等對端反會接收成功的消息，要至少400ms。因為網(wǎng)絡(luò)一個rtt時間就是400ms。那么在寫1m之后，我們至少要等400ms之后才能發(fā)送下一個1M。這樣的帶寬利用率僅為10ms(數(shù)據(jù)發(fā)送時間)/400ms(rtt等待時間) = 2.5%。這是在沒有buffer影響的情況下，實際上我們當(dāng)前環(huán)境是有buffer的，所以當(dāng)前的帶寬利用率要遠(yuǎn)遠(yuǎn)大于沒有buffer的理論情況。

有了這個理論模型，我們就大概知道應(yīng)該把buffer調(diào)整為多大了，實際上就是應(yīng)該讓一次寫操作的數(shù)據(jù)把網(wǎng)絡(luò)延時，導(dǎo)致浪費的帶寬填滿。在延時為400ms，帶寬為125mB/s的網(wǎng)絡(luò)上，要填滿延時期間的浪費帶寬的字節(jié)數(shù)該是多少呢？那就是著名的帶寬延時積了。即：帶寬(125mB/s) X 延時rtt(0.4s) = 50m。

所以，如果一次寫可以寫滿到50m，發(fā)送給對方。那么等待的400ms中理論上將不會有帶寬未被利用的情況。那么在當(dāng)前測試環(huán)境中，應(yīng)該調(diào)整的就是發(fā)送方的tcp_wmem緩存大小。根據(jù)上述的各個文件的含義，我們知道只要把/proc/sys/net/ipv4/tcp_wmem文件中的對應(yīng)值做調(diào)整，那么就會有效影響當(dāng)前服務(wù)端的tcp socekt buffer長度。我們來試一下，在centos 8上做如下調(diào)整：

然后在fedora 31測試下載速度：

發(fā)現(xiàn)目前下載速率穩(wěn)定在15M/s左右。雖然有所提升，但是依然并沒達到真正充分利用帶寬的效果。這是為啥呢？理論錯了么？

如果我們對TCP理解比較深入的話，我們會知道，TCP傳輸過程中，真正能決定一次寫長度的并不直接受tcp socket wmem的長度影響，嚴(yán)格來說，是受到tcp發(fā)送窗口大小的影響。而tcp發(fā)送窗口大小還要受到接收端的通告窗口來決定。就是說，tcp發(fā)送窗口決定了是不是能填滿大延時網(wǎng)絡(luò)的帶寬，而接收端的通告窗口決定了發(fā)送窗口有多大。

那么接受方的通告窗口長度是怎么決定的呢？在內(nèi)核中，使用tcp_select_window()方法來決定通告窗口大小。詳細(xì)分析這個方法，我們發(fā)現(xiàn)，接受方的通告窗口大小會受到接受方本地的tcp socket rmem的剩余長度影響。就是說，在一個tcp鏈接中，發(fā)送窗口受到對端tcp socket rmem剩余長度影響。

所以，除了調(diào)整發(fā)送方wmem外，還要調(diào)整接受方的rmem。我們再來試一下，在fedora 31上執(zhí)行：

再做下載測試：

這時的下載速率才比較符合我們理論中的狀況。當(dāng)然，因為發(fā)送窗口大小受到的是“剩余”接收緩存大小影響，所以我們推薦此時應(yīng)該把/proc/sys/net/ipv4/tcp_rmem的大小調(diào)的比理論值更大一些。比如大一倍：

此時理論上應(yīng)該獲得比剛才更理想的下載速率。另外還有一個文件需要注意：

/proc/sys/net/ipv4/tcp_adv_win_scale

這個值用來影響緩存中有多大空間用來存放overhead相關(guān)數(shù)據(jù)，所謂overhead數(shù)據(jù)可以理解為比如TCP報頭等非業(yè)務(wù)數(shù)據(jù)。假設(shè)緩存字節(jié)數(shù)為bytes，這個值說明，有bytes/2的tcp_adv_win_scale次方的空間用來存放overhead數(shù)據(jù)。默認(rèn)值為1表示有1/2的緩存空間用來放overhead，此值為二表示1/4的空間。當(dāng)tcp_adv_win_scale <= 0的時候，overhead空間運算為：bytes-bytes/2^(-tcp_adv_win_scale)。取值范圍是：[-31, 31]。

可以在下載過程中使用ss命令查看rcv_space和rcv_ssthresh的變化：

總結(jié)

從原理上看，一個延時大的網(wǎng)絡(luò)不應(yīng)該影響其帶寬的利用。之所以大延時網(wǎng)絡(luò)上的帶寬利用率低，主要原因是延時變大之后，發(fā)送方發(fā)的數(shù)據(jù)不能及時到達接收方。導(dǎo)致發(fā)送緩存滿之后，不能再持續(xù)發(fā)送數(shù)據(jù)。接收方則因為TCP通告窗口受到接收方剩余緩存大小的影響。接收緩存小的話，則會通告對方發(fā)送窗口變小。進而影響發(fā)送方不能以大窗口發(fā)送數(shù)據(jù)。所以，這里的調(diào)優(yōu)思路應(yīng)該是，發(fā)送方調(diào)大tcp_wmem，接收方調(diào)大tcp_rmem。那么調(diào)成多大合適呢？如果我們把大延時網(wǎng)絡(luò)想象成一個緩存的話，那么緩存的大小應(yīng)該是帶寬延時（rtt）積。假設(shè)帶寬為1000Mbit/s，rtt時間為400ms，那么緩存應(yīng)該調(diào)整為大約50Mbyte左右。接收方tcp_rmem應(yīng)該更大一些，以便在接受方不能及時處理數(shù)據(jù)的情況下，不至于產(chǎn)生剩余緩存變小而影響通告窗口導(dǎo)致發(fā)送變慢的問題，可以考慮調(diào)整為2倍的帶寬延時積。在這個例子中就是100M左右。此時在原理上，tcp的吞度量應(yīng)該能達到高延時網(wǎng)絡(luò)的帶寬上限了。

但是網(wǎng)絡(luò)環(huán)境本身很復(fù)雜。首先：網(wǎng)絡(luò)路徑上的一堆網(wǎng)絡(luò)設(shè)備本身會有一定緩存。所以我們大多數(shù)情況不用按照上述理論值調(diào)整本地的tcp緩存大小。其次，高延時網(wǎng)絡(luò)一般伴隨著丟包幾率高。當(dāng)產(chǎn)生丟包的時候，帶寬利用率低就不再只是緩存的影響了。此時擁塞控制本身會導(dǎo)致帶寬利用率達不到要求。所以，選擇不同的擁塞控制算法，更多影響的是丟包之后的快速恢復(fù)過程和慢啟動過程的效果。比如，bbr這種對丟包不敏感的擁塞控制算法，在有丟包的情況下，對窗口的影響比其他擁塞控制算法更小。而如果網(wǎng)絡(luò)僅僅是延時大，丟包很少的話，選什么擁塞控制算法對帶寬利用率影響并不大，緩存影響會更大。