Socket緩存如何影響TCP的性能

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

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

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

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

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

針對(duì)UDP：

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

針對(duì)TCP：

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

/proc/sys/net/ipv4/tcp_rmem

/proc/sys/net/ipv4/tcp_wmem

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

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

三個(gè)值依次表示：min default max

min：決定 tcp socket buffer 最小長(zhǎng)度。

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

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

/proc/sys/net/ipv4/tcp_moderate_rcvbuf

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

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

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

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

另外需要說(shuō)明的是，我們目前的實(shí)驗(yàn)環(huán)境是兩臺(tái)虛擬機(jī)，一個(gè)是centos 8，另一個(gè)是fedora 31：

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

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

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

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

那么問(wèn)題來(lái)了，此時(shí)socket緩存在這個(gè)1000mbit的帶寬限制下，對(duì)tcp的傳輸性能有什么影響呢？

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

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

緩存對(duì)讀寫(xiě)性能的影響

這其實(shí)是個(gè)通用問(wèn)題：緩存到底在什么情況下會(huì)影響讀寫(xiě)性能？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

然后在fedora 31測(cè)試下載速度：

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

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

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

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

再做下載測(cè)試：

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

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

/proc/sys/net/ipv4/tcp_adv_win_scale

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

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

總結(jié)

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

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