請(qǐng)先看下這個(gè)case：

對(duì)某一個(gè)key value應(yīng)用，從網(wǎng)卡接收數(shù)據(jù)包到應(yīng)用層處理，再把數(shù)據(jù)發(fā)送出去，整個(gè)系統(tǒng)資源消耗情況如下：

可以看出，Sockets接口+TCP是系統(tǒng)瓶頸。

根據(jù)下圖模型，瓶頸在于TCP(包括sockets接口)。

要想提升系統(tǒng)吞吐量，必須要優(yōu)化TCP。

由于網(wǎng)絡(luò)延遲的存在，對(duì)用戶體驗(yàn)影響更大的是如何快速傳遞數(shù)據(jù)到客戶端，而這屬于流量?jī)?yōu)化的范疇。

本文講述如何優(yōu)化TCP性能和TCP數(shù)據(jù)傳遞。

1. 什么是TCP加速

引用百度百科的定義：

主流的TCP加速方式主要有 ：基于流量的加速傳遞和數(shù)據(jù)包處理性能優(yōu)化。

基于流量的方式主要通過修改擁塞控制算法來達(dá)到快速傳遞數(shù)據(jù)包的目的。

數(shù)據(jù)包處理性能優(yōu)化包括內(nèi)核優(yōu)化、TCP offload和基于用戶態(tài)TCP協(xié)議的方式。這些方式可用于優(yōu)化數(shù)據(jù)包處理，從而提升系統(tǒng)的吞吐量。

2. 基于流量的TCP加速方式

(1) TCP雙邊加速

TCP雙邊加速需要在TCP連接的兩端部署硬件設(shè)備或安裝軟件。

雙邊加速的優(yōu)點(diǎn)是可以利用壓縮等技術(shù)進(jìn)一步提升TCP傳輸效率，缺點(diǎn)是部署麻煩。

雙邊加速一般應(yīng)用于公司不同分支之間的遠(yuǎn)距離訪問。

下圖是雙邊加速的一個(gè)例子。TCP加速設(shè)備之間采用SCTP的協(xié)議進(jìn)行交互，而原本TCP對(duì)端跟TCP加速設(shè)備之間則采用常規(guī)的TCP協(xié)議進(jìn)行交互。這種透明代理的方式方便了TCP加速設(shè)備之間采用特殊的方式來加速。

(2) 單邊加速

TCP單邊加速只需要在在TCP的一端部署軟件或設(shè)備，達(dá)到提升TCP快速傳輸數(shù)據(jù)的目的。

絕大部分TCP單邊加速都是通過修改TCP的擁塞控制算法來實(shí)現(xiàn)。

下圖顯示了某商用化產(chǎn)品的單邊加速情況，數(shù)據(jù)包的發(fā)送很暴力，并沒有慢啟動(dòng)過程。這種無視網(wǎng)絡(luò)狀況發(fā)送數(shù)據(jù)包的方式，大部分場(chǎng)景下確實(shí)能夠提升性能，但這樣的性能提升方式其實(shí)是搶占了互聯(lián)網(wǎng)帶寬資源，就像高速公路走應(yīng)急車道一樣。

近幾年出現(xiàn)的google擁塞控制算法BBR可以看成是單邊加速的一種。

上圖展示了相對(duì)于傳統(tǒng)擁塞控制算法CUBIC，BBR算法在網(wǎng)絡(luò)丟包情況下仍然表現(xiàn)優(yōu)異，原因在于BBR算法摒棄丟包作為擁塞控制的直接反饋因素，通過實(shí)時(shí)計(jì)算帶寬和最小RTT來決定發(fā)送速率和窗口大小。

在移動(dòng)應(yīng)用場(chǎng)合，大部分網(wǎng)絡(luò)丟包并不是由于路由器網(wǎng)絡(luò)擁塞導(dǎo)致，因此在移動(dòng)場(chǎng)合，BBR算法具有更好的適應(yīng)性。

在Linux內(nèi)核4.9以上版本(不包括docker環(huán)境)，使用BBR算法，一般只需要在sysctl.conf文件加上下面兩句：

然后執(zhí)行sysctl -p使其生效。

TCP單邊加速的優(yōu)點(diǎn)是只需要在一側(cè)進(jìn)行部署，缺點(diǎn)是無法直接利用壓縮等功能，而且大都會(huì)破壞互聯(lián)網(wǎng)的公平性。

3. 內(nèi)核優(yōu)化

(1) 純內(nèi)核優(yōu)化

根據(jù)Wikipedia內(nèi)容：

我們得知，內(nèi)核需要根據(jù)實(shí)際場(chǎng)景進(jìn)行優(yōu)化，不能一概而論。合理優(yōu)化，可以提升性能很多(有時(shí)能夠提升10倍)，但如果盲目?jī)?yōu)化，性能反而下降。

當(dāng)今的內(nèi)核，在大部分場(chǎng)景下，TCP buffer能夠自動(dòng)調(diào)整buffer大小來匹配傳輸，所以在內(nèi)核方面需要優(yōu)化的地方就是選擇合適的擁塞控制算法。

下面是Linux默認(rèn)算法CUBIC和BBR算法在丟包情況下的對(duì)比情況：

在丟包情況下，BBR所受影響沒有Linux TCP默認(rèn)算法CUBIC那么大，而且在20%以下的丟包率情況下性能遠(yuǎn)超CUBIC。一般建議在非網(wǎng)絡(luò)擁塞導(dǎo)致丟包的場(chǎng)合使用BBR算法，例如移動(dòng)應(yīng)用。

對(duì)于帶寬比較大，RTT時(shí)間比較長(zhǎng)的應(yīng)用場(chǎng)景，可以參考。

(2) Dedicated fast path

由于內(nèi)核處理TCP是通用的處理方式，不同的場(chǎng)景，執(zhí)行的路徑是不一樣的，針對(duì)某些場(chǎng)景做特殊的優(yōu)化，可以大大提升TCP的處理性能。

這方面可以參考論文"TAS: TCP Accleration as an OS Service"。

4. TCP offload

內(nèi)核消耗性能的地方主要有如下四個(gè)方面：

目前TCP offload常用的功能是TCP/IP checksum offload和TCP segmentation offload，主要是解決上面第二個(gè)問題。

其它問題需要更加強(qiáng)大的網(wǎng)卡支持，這方面可以參考"https://www.dell.com/downloads/global/power/1q04-her.pdf"。

"TCP Offload Engines"論文中描述了網(wǎng)絡(luò)應(yīng)用內(nèi)存拷貝的情況，具體參考下圖。

不管是發(fā)送路徑還是接收路徑，系統(tǒng)存在大量?jī)?nèi)存拷貝，直接影響了TCP/IP協(xié)議棧性能，可以利用TCP offload功能，NIC直接拷貝到應(yīng)用的buffer中去，減少拷貝次數(shù)，從而提升性能。

TCP offload可能是未來的趨勢(shì)，部署方便，代價(jià)小，是非常值得關(guān)注的一個(gè)方向。

5. 用戶態(tài)TCP協(xié)議

用戶態(tài)的協(xié)議棧在下列場(chǎng)合比較有用：

是否要采用用戶態(tài)TCP協(xié)議棧，可以參考"https://blog.cloudflare.com/why-we-use-the-linux-kernels-tcp-stack/".

6. 總結(jié)

TCP加速是一個(gè)很大的領(lǐng)域，這方面應(yīng)用得好，可以極大提升程序的性能，因此性能優(yōu)化不要忽視這方面內(nèi)容。