一、TCP知識(shí)體系

我們從三個(gè)維度去分析服務(wù)器開(kāi)發(fā)的TCP知識(shí)體系，分別為性能法則、設(shè)計(jì)法則和避坑法則。

二、性能法則

性能法則大致總結(jié)如下：

1. 減少數(shù)據(jù)傳遞

下面引用了左耳朵的"程序員如何用技術(shù)變現(xiàn)"文章中的一部分：

從上面我們可以看出減少數(shù)據(jù)傳遞對(duì)于性能是非常重要的。

2. 根據(jù)場(chǎng)景設(shè)置MTU

如果是內(nèi)網(wǎng)應(yīng)用，通過(guò)合理設(shè)置MTU來(lái)提升性能是不能忽視的一種手段;對(duì)于移動(dòng)應(yīng)用，一般可以設(shè)置MTU為1492;對(duì)于外網(wǎng)應(yīng)用，則設(shè)置通用的1500。

3. 利用TCP offload

帶寬消耗高的應(yīng)用，可以考慮利用TCP offload來(lái)提升性能。

4. TCP NODELAY

目前服務(wù)器程序一般建議設(shè)置NODELAY為true，如果需要對(duì)小數(shù)據(jù)包合并，則可以考慮在應(yīng)用層做數(shù)據(jù)合并(參考下圖Wikipedia中內(nèi)容)。

詳細(xì)內(nèi)容請(qǐng)參考："https://en.wikipedia.org/wiki/Nagle%27s_algorithm"

5. 采用合適的擁塞控制算法

下圖展示了數(shù)據(jù)包經(jīng)過(guò)路由器Queue的場(chǎng)景。

第一種是最理想的情況，數(shù)據(jù)包到達(dá)路由器，無(wú)需等待就能直接轉(zhuǎn)發(fā)出去;第二種是等待一段時(shí)間，才能發(fā)送出去;第三種是因?yàn)槁酚善鱭ueue滿，數(shù)據(jù)包被路由器丟掉。

發(fā)送數(shù)據(jù)過(guò)猛可能導(dǎo)致第三種情況發(fā)生。

下面展示了Linux默認(rèn)算法CUBIC和BBR算法在丟包情況下的吞吐量對(duì)比：

從上圖可以看出，BBR擁塞控制算法可以在20%丟包率以下保持吞吐量，因此BBR的抗網(wǎng)絡(luò)抖動(dòng)性比CUBIC要好。

BBR算法優(yōu)異的根本原因如下：

• 在有一定丟包率的網(wǎng)絡(luò)鏈路上充分利用帶寬
• 降低路由器的queue占用率，從而降低延遲

一般建議在非網(wǎng)絡(luò)擁塞導(dǎo)致丟包的場(chǎng)合使用BBR算法，例如移動(dòng)應(yīng)用。

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

6. 使用REUSEPORT

針對(duì)短連接應(yīng)用(例如PHP應(yīng)用)，為防止服務(wù)器應(yīng)用來(lái)不及接收連接請(qǐng)求，可以采用Linux REUSEPORT機(jī)制。我們開(kāi)發(fā)的數(shù)據(jù)庫(kù)中間件Cetus利用REUSEPORT機(jī)制成功避開(kāi)了應(yīng)用短連接的沖擊。

三、設(shè)計(jì)法則

1. 規(guī)避TCP HOL問(wèn)題

盡量采用多連接，不要采用單個(gè)連接來(lái)傳遞大量數(shù)據(jù)。

2. 傳輸盡量平穩(wěn)，不抖動(dòng)

如果數(shù)據(jù)傳輸比較抖動(dòng)，那么容易導(dǎo)致如下問(wèn)題：

• 內(nèi)存膨脹
• 性能不穩(wěn)定
• 壓縮算法效率低下

在開(kāi)發(fā)數(shù)據(jù)庫(kù)中間件Cetus的時(shí)候，我們控制了每次數(shù)據(jù)傳輸?shù)膫鬏斄?，在采用同樣壓縮算法的情況下，cetus壓縮比遠(yuǎn)遠(yuǎn)好于MySQL的壓縮比。

3. TCP stream流式傳輸

TCP stream主要用在中間件服務(wù)。

下圖是沒(méi)有采用TCP stream的交互圖。中間件接收完Server端的響應(yīng)后，才開(kāi)始發(fā)送給客戶端。不少數(shù)據(jù)庫(kù)中間件采用這樣的工作方式，導(dǎo)致中間件內(nèi)存消耗巨大。

下圖采用了TCP stream方式后，不僅降低了延遲，也降低了內(nèi)存消耗(因?yàn)闊o(wú)需保留所有響應(yīng))。

服務(wù)器中間件程序最好實(shí)現(xiàn)TCP stream，否則易發(fā)生內(nèi)存炸裂等問(wèn)題。

4. 上層應(yīng)用pipeline機(jī)制

TCP本身并不具備pipeline機(jī)制，但上層應(yīng)用可以利用pineline機(jī)制來(lái)提升服務(wù)器應(yīng)用的吞吐量。

下圖是沒(méi)有采用pipeline的交互圖，客戶端需接收到服務(wù)器響應(yīng)后才能發(fā)送下一個(gè)請(qǐng)求。

下圖是采用pipeline的交互圖?？蛻舳藷o(wú)需等待響應(yīng)就可以連續(xù)發(fā)送多個(gè)請(qǐng)求。

對(duì)于TCP來(lái)說(shuō)，請(qǐng)求1、請(qǐng)求2和請(qǐng)求3看成一個(gè)請(qǐng)求，響應(yīng)1、響應(yīng)2和響應(yīng)3看成一個(gè)響應(yīng);對(duì)于上層應(yīng)用來(lái)說(shuō)，則是3個(gè)請(qǐng)求，3個(gè)響應(yīng)。

目前，很多協(xié)議或者軟件采用pipeline機(jī)制來(lái)提升應(yīng)用的吞吐量，例如HTTP v2協(xié)議支持pipeline發(fā)送請(qǐng)求，Redis采用pipeline機(jī)制來(lái)提升應(yīng)用的吞吐量。

5. 合并小數(shù)據(jù)

運(yùn)行TCPCopy的時(shí)候，intercept返回響應(yīng)包的TCP/IP header給tcpcopy。一般TCP/IP header只有幾十字節(jié)，如果每次write操作只傳輸一個(gè)響應(yīng)包的TCP/IP header，那么效率就會(huì)非常低。為了提升傳輸效率，intercept合并若干個(gè)響應(yīng)包的TCP/IP header信息一起發(fā)送。

四、避坑法則4.1 加上keepalive機(jī)制

TCP keepalive機(jī)制可以用來(lái)檢測(cè)連接是否還存活，具體可以參考"對(duì)付Reset流氓干擾：TCP keepalive"。

1. MTU

參考:"https://wiki.archlinux.org/index.php/Jumbo_frames"

2. 確保網(wǎng)絡(luò)通暢

云環(huán)境、中途設(shè)備程序、TCP offload和負(fù)載均衡器或多或少存在一些問(wèn)題，而這些問(wèn)題如果不及時(shí)解決，會(huì)極大影響程序的性能和問(wèn)題排查。

這方面一般可以通過(guò)抓包的方式去查明問(wèn)題。

下面展示了負(fù)載均衡器自身bug導(dǎo)致了網(wǎng)絡(luò)不通暢。

由于負(fù)載均衡器沒(méi)有嚴(yán)格按照TCP session的方式進(jìn)行負(fù)載均衡，有些TCP session的數(shù)據(jù)包跑到了不同的機(jī)器，進(jìn)而導(dǎo)致應(yīng)用端報(bào)請(qǐng)求超時(shí)。

最初連接的數(shù)據(jù)包跑到了180機(jī)器。

后來(lái)這個(gè)連接的數(shù)據(jù)包跑到了176機(jī)器(參考下圖)。

負(fù)載均衡器出現(xiàn)這種bug，會(huì)造成用戶的極大困擾，很難查明問(wèn)題原因。

這時(shí)要么更換負(fù)載均衡器，要么找廠商解決負(fù)載均衡器的bug，否則上層應(yīng)用會(huì)一直報(bào)網(wǎng)絡(luò)超時(shí)等問(wèn)題。

五、總結(jié)

對(duì)于服務(wù)器開(kāi)發(fā)人員，只有了解了TCP知識(shí)體系后，開(kāi)發(fā)起來(lái)才能夠得心應(yīng)手，同時(shí)可以規(guī)避一些潛在的坑。