一、TCP知識(shí)體系
我們從三個(gè)維度去分析服務(wù)器開發(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)用，通過合理設(shè)置MTU來提升性能是不能忽視的一種手段;對(duì)于移動(dòng)應(yīng)用，一般可以設(shè)置MTU為1492;對(duì)于外網(wǎng)應(yīng)用，則設(shè)置通用的1500。
3. 利用TCP offload
帶寬消耗高的應(yīng)用，可以考慮利用TCP offload來提升性能。
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)過路由器Queue的場(chǎng)景。
第一種是最理想的情況，數(shù)據(jù)包到達(dá)路由器，無需等待就能直接轉(zhuǎn)發(fā)出去;第二種是等待一段時(shí)間，才能發(fā)送出去;第三種是因?yàn)槁酚善鱭ueue滿，數(shù)據(jù)包被路由器丟掉。
發(fā)送數(shù)據(jù)過猛可能導(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)用來不及接收連接請(qǐng)求，可以采用Linux REUSEPORT機(jī)制。我們開發(fā)的數(shù)據(jù)庫(kù)中間件Cetus利用REUSEPORT機(jī)制成功避開了應(yīng)用短連接的沖擊。
三、設(shè)計(jì)法則
1. 規(guī)避TCP HOL問題
盡量采用多連接，不要采用單個(gè)連接來傳遞大量數(shù)據(jù)。
2. 傳輸盡量平穩(wěn)，不抖動(dòng)
如果數(shù)據(jù)傳輸比較抖動(dòng)，那么容易導(dǎo)致如下問題：
- 內(nèi)存膨脹
- 性能不穩(wěn)定
- 壓縮算法效率低下
在開發(fā)數(shù)據(jù)庫(kù)中間件Cetus的時(shí)候，我們控制了每次數(shù)據(jù)傳輸?shù)膫鬏斄?，在采用同樣壓縮算法的情況下，cetus壓縮比遠(yuǎn)遠(yuǎn)好于MySQL的壓縮比。
3. TCP stream流式傳輸
TCP stream主要用在中間件服務(wù)。
下圖是沒有采用TCP stream的交互圖。中間件接收完Server端的響應(yīng)后，才開始發(fā)送給客戶端。不少數(shù)據(jù)庫(kù)中間件采用這樣的工作方式，導(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ā)送下一個(gè)請(qǐng)求。
下圖是采用pipeline的交互圖。客戶端無需等待響應(yīng)就可以連續(xù)發(fā)送多個(gè)請(qǐng)求。
對(duì)于TCP來說，請(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)用來說，則是3個(gè)請(qǐng)求，3個(gè)響應(yīng)。
目前，很多協(xié)議或者軟件采用pipeline機(jī)制來提升應(yīng)用的吞吐量，例如HTTP v2協(xié)議支持pipeline發(fā)送請(qǐng)求，Redis采用pipeline機(jī)制來提升應(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ī)制可以用來檢測(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ù)載均衡器或多或少存在一些問題，而這些問題如果不及時(shí)解決，會(huì)極大影響程序的性能和問題排查。
這方面一般可以通過抓包的方式去查明問題。
下面展示了負(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)用端報(bào)請(qǐng)求超時(shí)。
最初連接
后來這個(gè)連接的數(shù)據(jù)包跑到了176機(jī)器(參考下圖)。
負(fù)載均衡器出現(xiàn)這種bug，會(huì)造成用戶的極大困擾，很難查明問題原因。
這時(shí)要么更換負(fù)載均衡器，要么找廠商解決負(fù)載均衡器的bug，否則上層應(yīng)用會(huì)一直報(bào)網(wǎng)絡(luò)超時(shí)等問題。
五、總結(jié)
對(duì)于服務(wù)器開發(fā)人員，只有了解了TCP知識(shí)體系后，開發(fā)起來才能夠得心應(yīng)手，同時(shí)可以規(guī)避一些潛在的坑。
【責(zé)任編輯：趙寧寧 TEL：（010）68476606】