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

影響Socket緩存的參數

首先，我們要先來列出Linux中可以影響Socket緩存的調整參數。在proc目錄下，它們的路徑和對應說明為：

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

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

針對UDP：

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

針對TCP：

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

/proc/sys/net/ipv4/tcp_rmem

/proc/sys/net/ipv4/tcp_wmem

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

查看tcp_rmem和tcp_wmem的文件內容會發現，文件中包含三個值：

三個值依次表示：min default max

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

default：決定其默認長度。

max：決定其最大長度。在一個tcp鏈接中，對應的buffer長度將在min和max之間變化。導致變化的主要因素是當前內存壓力。如果使用setsockopt設置了對應buffer長度的話，這個值將被忽略。相當于關閉了tcp buffer的動態調整。

/proc/sys/net/ipv4/tcp_moderate_rcvbuf

這個文件是服務器是否支持緩存動態調整的開關，1為默認值打開，0為關閉。

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

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

我們目前的實驗環境配置都采用默認值：

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

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

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

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

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

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

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

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

緩存對讀寫性能的影響

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

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

無論如何，當寫操作產生數據的速度，大于實際要接受數據的速度時，buffer才有意義。

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

那么如何才能讓我們的模型產生影響呢？

答案也很簡單，給網絡加比較大的延時就可以了。如果我們把每個tcp包的傳輸過程當作一次寫操作的話，那么網絡延時變大將導致寫操作的處理速度變長。網絡就會成為應用程序寫速度的瓶頸。我們給我們的80端口再加入一個200ms的延時：

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

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

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

大延時網絡提高TCP帶寬利用率

我們先來分析一下當前的問題，為什么加大了網絡延時會導致tcp帶寬利用率下降？

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

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

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

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

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

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

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

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

所以，除了調整發送方wmem外，還要調整接受方的rmem。我們再來試一下，在fedora 31上執行：

再做下載測試：

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

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

/proc/sys/net/ipv4/tcp_adv_win_scale

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

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

總結

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

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