一、TCP知識體系

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

二、性能法則

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

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

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

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

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

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

3. 利用TCP offload

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

4. TCP NODELAY

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

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

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

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

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

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

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

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

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

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

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

對于帶寬比較大，RTT時間比較長的應(yīng)用場景，可以參考。

6. 使用REUSEPORT

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

三、設(shè)計法則

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

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

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

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

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

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

3. TCP stream流式傳輸

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

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

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

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

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

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

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

下圖是采用pipeline的交互圖。客戶端無需等待響應(yīng)就可以連續(xù)發(fā)送多個請求。

對于TCP來說，請求1、請求2和請求3看成一個請求，響應(yīng)1、響應(yīng)2和響應(yīng)3看成一個響應(yīng);對于上層應(yīng)用來說，則是3個請求，3個響應(yīng)。

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

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

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

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

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

1. MTU

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

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

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

這方面一般可以通過抓包的方式去查明問題。

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

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

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

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

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

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

五、總結(jié)

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