一直以來我們都知道socket的緩存會(huì)對tcp性能產(chǎn)生影響，也有無數(shù)文章告訴我們應(yīng)該調(diào)大socke緩存。

但是究竟調(diào)多大？

什么時(shí)候調(diào)？

有哪些手段調(diào)？

具體影響究竟如何？

這些問題似乎也沒有人真正說明白。

下面我們就構(gòu)建起一個(gè)簡單的實(shí)驗(yàn)環(huán)境，在兩臺(tái)虛擬機(jī)之間探究一下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ù)實(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：

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

/proc/sys/net/ipv4/tcp_rmem

/proc/sys/net/ipv4/tcp_wmem

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

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

[root@localhost network_turning]# cat /proc/sys/net/ipv4/tcp_rmem40961310726291456[root@localhost network_turning]# cat /proc/sys/net/ipv4/tcp_wmem4096163844194304

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

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

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

max：決定其最大長度。在一個(gè)tcp鏈接中，對應(yīng)的buffer長度將在min和max之間變化。導(dǎo)致變化的主要因素是當(dāng)前內(nèi)存壓力。如果使用setsockopt設(shè)置了對應(yīng)buffer長度的話，這個(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)整的開關(guān)，1為默認(rèn)值打開，0為關(guān)閉。

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

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

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

[root@localhost network_turning]# cat /proc/sys/net/core/rmem_default212992[root@localhost network_turning]# cat /proc/sys/net/core/rmem_max212992[root@localhost network_turning]# cat /proc/sys/net/core/wmem_default212992[root@localhost network_turning]# cat /proc/sys/net/core/wmem_max212992

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

[root@localhost network_turning]# uname -r5.5.15-200.fc31.x86_64[root@localhost zorro]# uname -r4.18.0-147.5.1.el8_1.x86_64

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

[root@localhost zorro]# wget --no-proxy http://192.168.247.129/bigfile--2020-04-13 1433--  http://192.168.247.129/bigfileConnecting to 192.168.247.129:80... connected.HTTP request sent, awaiting response... 200 OKLength: 1073741824 (1.0G)Saving to: 'bigfile'bigfile                   100%[=====================================>]   1.00G   337MB/s    in 3.0s2020-04-13 1436 (337 MB/s) - 'bigfile' saved [1073741824/1073741824]

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

[root@localhost zorro]# cat htb.sh#!/bin/bashtc qd del dev ens33 roottc qd add dev ens33 root handle 1: htb default 100tc cl add dev ens33 parent 1: classid 1:1 htb rate 20000mbit burst 20ktc cl add dev ens33 parent 1:1 classid 1:10 htb rate 1000mbit burst 20ktc cl add dev ens33 parent 1:1 classid 1:100 htb rate 20000mbit burst 20ktc qd add dev ens33 parent 1:10 handle 10: fq_codeltc qd add dev ens33 parent 1:100 handle 100: fq_codeltc fi add dev ens33 protocol ip parent 1:0 prio 1 u32 match ip sport 80 0xffff flowid 1:10

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

[root@localhost zorro]# wget --no-proxy http://192.168.247.129/bigfile--2020-04-13 1438--  http://192.168.247.129/bigfileConnecting to 192.168.247.129:80... connected.HTTP request sent, awaiting response... 200 OKLength: 1073741824 (1.0G)Saving to: 'bigfile'bigfile                   100%[=====================================>]   1.00G  91.6MB/s    in 11s2020-04-13 1449 (91.7 MB/s) - 'bigfile' saved [1073741824/1073741824]

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

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

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

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

緩存對讀寫性能的影響

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

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

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

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

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

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

[root@localhost zorro]# cat htb.sh#!/bin/bashtc qd del dev ens33 roottc qd add dev ens33 root handle 1: htb default 100tc cl add dev ens33 parent 1: classid 1:1 htb rate 20000mbit burst 20ktc cl add dev ens33 parent 1:1 classid 1:10 htb rate 1000mbit burst 20ktc cl add dev ens33 parent 1:1 classid 1:100 htb rate 20000mbit burst 20ktc qd add dev ens33 parent 1:10 handle 10: netem delay 200mstc qd add dev ens33 parent 1:100 handle 100: fq_codeltc fi add dev ens33 protocol ip parent 1:0 prio 1 u32 match ip sport 80 0xffff flowid 1:10

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

[root@localhost zorro]# httping 192.168.247.129PING 192.168.247.129:80 (/):connected to 192.168.247.129:80 (426 bytes), seq=0 time= 17.37 msconnected to 192.168.247.129:80 (426 bytes), seq=1 time=  1.22 msconnected to 192.168.247.129:80 (426 bytes), seq=2 time=  1.25 msconnected to 192.168.247.129:80 (426 bytes), seq=3 time=  1.47 msconnected to 192.168.247.129:80 (426 bytes), seq=4 time=  1.55 msconnected to 192.168.247.129:80 (426 bytes), seq=5 time=  1.35 ms^CGot signal 2--- http://192.168.247.129/ ping statistics ---6 connects, 6 ok, 0.00% failed, time 5480msround-trip min/avg/max = 1.2/4.0/17.4 ms[root@localhost zorro]# httping 192.168.247.129PING 192.168.247.129:80 (/):connected to 192.168.247.129:80 (426 bytes), seq=0 time=404.59 msconnected to 192.168.247.129:80 (426 bytes), seq=1 time=403.72 msconnected to 192.168.247.129:80 (426 bytes), seq=2 time=404.61 msconnected to 192.168.247.129:80 (426 bytes), seq=3 time=403.73 msconnected to 192.168.247.129:80 (426 bytes), seq=4 time=404.16 ms^CGot signal 2--- http://192.168.247.129/ ping statistics ---5 connects, 5 ok, 0.00% failed, time 6334msround-trip min/avg/max = 403.7/404.2/404.6 ms

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

[root@localhost zorro]# wget --no-proxy http://192.168.247.129/bigfile--2020-04-13 1428--  http://192.168.247.129/bigfileConnecting to 192.168.247.129:80... connected.HTTP request sent, awaiting response... 200 OKLength: 1073741824 (1.0G)Saving to: 'bigfile'bigfile                    15%[=====>                                ] 162.61M  13.4MB/s    eta 87s

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

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

我們先來分析一下當(dāng)前的問題，為什么加大了網(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。在這樣的帶寬下，假定沒有buffer影響，網(wǎng)絡(luò)發(fā)送1m數(shù)據(jù)的速度需要10ms，之后這1m數(shù)據(jù)需要通過網(wǎng)絡(luò)發(fā)送給對端。然后對端返回接收成功給服務(wù)端，服務(wù)端接收到寫成功之后理解為此次寫操作完成，之后發(fā)送下一個(gè)1m。

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

有了這個(gè)理論模型，我們就大概知道應(yīng)該把buffer調(diào)整為多大了，實(shí)際上就是應(yīng)該讓一次寫操作的數(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。

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

[root@localhost zorro]# echo 52428800 52428800 52428800 >/proc/sys/net/ipv4/tcp_wmem[root@localhost zorro]# cat !$cat /proc/sys/net/ipv4/tcp_wmem524288005242880052428800

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

[root@localhost zorro]# wget --no-proxy http://192.168.247.129/bigfile--2020-04-13 1554--  http://192.168.247.129/bigfileConnecting to 192.168.247.129:80... connected.HTTP request sent, awaiting response... 200 OKLength: 1073741824 (1.0G)Saving to: 'bigfile'bigfile                    21%[=======>                              ] 222.25M  14.9MB/s    eta 69s

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

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

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

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

[root@localhost zorro]# echo 52428800 52428800 52428800 >/proc/sys/net/ipv4/tcp_rmem[root@localhost zorro]# cat !$cat /proc/sys/net/ipv4/tcp_rmem524288005242880052428800

再做下載測試：

[root@localhost zorro]# wget --no-proxy http://192.168.247.129/bigfile--2020-04-13 1540--  http://192.168.247.129/bigfileConnecting to 192.168.247.129:80... connected.HTTP request sent, awaiting response... 200 OKLength: 1073741824 (1.0G)Saving to: 'bigfile'bigfile                   100%[=====================================>]   1.00G  92.7MB/s    in 13s2020-04-13 1553 (77.8 MB/s) - 'bigfile' saved [1073741824/1073741824]

這時(shí)的下載速率才比較符合我們理論中的狀況。

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

[root@localhost zorro]# echo 104857600 104857600 104857600 > /proc/sys/net/ipv4/tcp_rmem[root@localhost zorro]# cat /proc/sys/net/ipv4/tcp_rmem104857600104857600104857600[root@localhost zorro]# wget --no-proxy http://192.168.247.129/bigfile--2020-04-13 1529--  http://192.168.247.129/bigfileConnecting to 192.168.247.129:80... connected.HTTP request sent, awaiting response... 200 OKLength: 1073741824 (1.0G)Saving to: 'bigfile'bigfile                   100%[=====================================>]   1.00G  89.2MB/s    in 13s2020-04-13 1543 (76.9 MB/s) - 'bigfile' saved [1073741824/1073741824]

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

/proc/sys/net/ipv4/tcp_adv_win_scale

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

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

[root@localhost zorro]# ss -io state established '( dport = 80 or sport = 80 )'Netid     Recv-Q     Send-Q           Local Address:Port              Peer Address:Port     Processtcp       0          0              192.168.247.130:47864          192.168.247.129:http
 ts sack cubic wscale:7,11 rto:603 rtt:200.748/75.374 ato:40 mss:1448 pmtu:1500 rcvmss:1448 advmss:1448 cwnd:10 bytes_sent:149 bytes_acked:150 bytes_received:448880 segs_out:107 segs_in:312 data_segs_out:1 data_segs_in:310 send 577.0Kbps lastsnd:1061 lastrcv:49 lastack:50 pacing_rate 1.2Mbps delivery_rate 57.8Kbps delivered:2 app_limited busy:201ms rcv_rtt:202.512 rcv_space:115840 rcv_ssthresh:963295 minrtt:200.474[root@localhost zorro]# ss -io state established '( dport = 80 or sport = 80 )'Netid     Recv-Q     Send-Q           Local Address:Port              Peer Address:Port     Processtcp       0          0              192.168.247.130:47864          192.168.247.129:http
 ts sack cubic wscale:7,11 rto:603 rtt:200.748/75.374 ato:40 mss:1448 pmtu:1500 rcvmss:1448 advmss:1448 cwnd:10 bytes_sent:149 bytes_acked:150 bytes_received:48189440 segs_out:1619 segs_in:33282 data_segs_out:1 data_segs_in:33280 send 577.0Kbps lastsnd:2623 lastrcv:1 lastack:3 pacing_rate 1.2Mbps delivery_rate 57.8Kbps delivered:2 app_limited busy:201ms rcv_rtt:294.552 rcv_space:16550640 rcv_ssthresh:52423872 minrtt:200.474[root@localhost zorro]# ss -io state established '( dport = 80 or sport = 80 )'Netid     Recv-Q     Send-Q           Local Address:Port              Peer Address:Port     Processtcp       0          0              192.168.247.130:47864          192.168.247.129:http
 ts sack cubic wscale:7,11 rto:603 rtt:200.748/75.374 ato:40 mss:1448 pmtu:1500 rcvmss:1448 advmss:1448 cwnd:10 bytes_sent:149 bytes_acked:150 bytes_received:104552840 segs_out:2804 segs_in:72207 data_segs_out:1 data_segs_in:72205 send 577.0Kbps lastsnd:3221 lastack:601 pacing_rate 1.2Mbps delivery_rate 57.8Kbps delivered:2 app_limited busy:201ms rcv_rtt:286.159 rcv_space:25868520 rcv_ssthresh:52427352 minrtt:200.474

總結(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)門CP通告窗口受到接收方剩余緩存大小的影響。接收緩存小的話，則會(huì)通告對方發(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ā)送變慢的問題，可以考慮調(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ù)過程和慢啟動(dòng)過程的效果。比如，bbr這種對丟包不敏感的擁塞控制算法，在有丟包的情況下，對窗口的影響比其他擁塞控制算法更小。

而如果網(wǎng)絡(luò)僅僅是延時(shí)大，丟包很少的話，選什么擁塞控制算法對帶寬利用率影響并不大，緩存影響會(huì)更大。

審核編輯：湯梓紅