CppExplore

作者：CppExplore 網(wǎng)址：http://www.shnenglu.com/CppExplore/
本人職業(yè)是linux上網(wǎng)絡(luò)服務(wù)器的開(kāi)發(fā)，本文就網(wǎng)絡(luò)服務(wù)器的系統(tǒng)架構(gòu)設(shè)計(jì)的細(xì)枝末節(jié)展開(kāi)討論。歡迎任何的點(diǎn)評(píng)指導(dǎo)和討論，尤其是對(duì)文中的缺點(diǎn)或者更好的方案。
一 系統(tǒng)框架概述
網(wǎng)絡(luò)上的服務(wù)器，無(wú)論是嵌入式的網(wǎng)絡(luò)設(shè)備，還是pc上服務(wù)器，整體結(jié)構(gòu)以及主要思想都大體相同：根據(jù)業(yè)務(wù)模型確定主要數(shù)據(jù)結(jié)構(gòu)，根據(jù)數(shù)據(jù)結(jié)構(gòu)確定線程模型，在各個(gè)業(yè)務(wù)線程內(nèi)根據(jù)圍繞主要數(shù)據(jù)結(jié)構(gòu)進(jìn)行的操作確定狀態(tài)機(jī)模型，低層使用網(wǎng)絡(luò)層收發(fā)數(shù)據(jù)完成和其它網(wǎng)元的通訊。線程交互模型簡(jiǎn)單描述如下圖：

其中網(wǎng)絡(luò)層包括收發(fā)模塊，收數(shù)據(jù)模塊是單獨(dú)線程，而發(fā)數(shù)據(jù)模塊則被業(yè)務(wù)線程調(diào)用在其本身線程中發(fā)送數(shù)據(jù)，網(wǎng)絡(luò)層收到數(shù)據(jù)后也可能向多個(gè)業(yè)務(wù)線程發(fā)送消息，業(yè)務(wù)線程可能1個(gè)，也可能多個(gè)，業(yè)務(wù)線程之間可能存在消息發(fā)送，最終會(huì)調(diào)用網(wǎng)絡(luò)層的發(fā)送方法完成本server的功能。
二 網(wǎng)絡(luò)層
相對(duì)而言，網(wǎng)絡(luò)層的實(shí)現(xiàn)相對(duì)呆板、模式化，這個(gè)層面的要點(diǎn)在系統(tǒng)調(diào)用，實(shí)現(xiàn)方式要符合操作系統(tǒng)提供的api允許的使用方式，而不能天馬行空想當(dāng)然，因此提高這部分能力的重點(diǎn)在于系統(tǒng)性的學(xué)習(xí)（《unix網(wǎng)絡(luò)編程》），不再于經(jīng)驗(yàn)。
網(wǎng)絡(luò)層有3部分構(gòu)成：連接細(xì)節(jié)、多路復(fù)用函數(shù)、協(xié)議解析。
（1）連接細(xì)節(jié)。要實(shí)現(xiàn)各個(gè)協(xié)議的網(wǎng)絡(luò)層（協(xié)議棧），首先要面對(duì)的就是承載該協(xié)議的傳輸層協(xié)議，udp還是tcp，理論本身就不再多說(shuō)了。簡(jiǎn)單說(shuō)下編程上的差異：udp的網(wǎng)絡(luò)連接簡(jiǎn)單、收數(shù)據(jù)簡(jiǎn)單，tcp的則網(wǎng)絡(luò)連接復(fù)雜、收數(shù)據(jù)需要在應(yīng)用層面確定是否一個(gè)收包完畢，tcp部分可以參見(jiàn)《【原創(chuàng)】技術(shù)系列之 網(wǎng)絡(luò)模型（一）基礎(chǔ)篇》。
（2）多路復(fù)用函數(shù)。除了處理udp、tcp本身網(wǎng)絡(luò)連接的系統(tǒng)調(diào)用之外，還存在和udp/tcp無(wú)關(guān)的多路復(fù)用函數(shù)（select等），它們可以監(jiān)控tcp的網(wǎng)絡(luò)事件，也可以監(jiān)控udp的網(wǎng)絡(luò)事件，屬于網(wǎng)絡(luò)層的核心驅(qū)動(dòng)部分?？梢詤⒁?jiàn)《【原創(chuàng)】技術(shù)系列之 網(wǎng)絡(luò)模型（三）多路復(fù)用模型》
（3）協(xié)議解析。這部分相對(duì)獨(dú)立，是網(wǎng)絡(luò)層中和網(wǎng)絡(luò)連接、收發(fā)消息無(wú)關(guān)的部分，主要功能則是對(duì)該協(xié)議各種消息的解包(decode)、打包（encode)。
網(wǎng)絡(luò)層的主要線程是多路復(fù)用監(jiān)控線程（select/poll/epoll_wait等），網(wǎng)絡(luò)消息觸發(fā)該線程的運(yùn)轉(zhuǎn)，如果是收包，則調(diào)用read類(lèi)函數(shù)，收包完畢，進(jìn)行解包操作，之后根據(jù)需要向業(yè)務(wù)線程發(fā)送消息（也可以收包完畢后即把數(shù)據(jù)包裹在消息中發(fā)送給業(yè)務(wù)線程，由業(yè)務(wù)線程解包，單仍把解包打包操作歸在網(wǎng)絡(luò)層中）。
性能方面：為了描述方便，引入使用場(chǎng)景：轉(zhuǎn)發(fā)rtp碼流，這個(gè)場(chǎng)景需要盡量大的并發(fā)行和實(shí)時(shí)性。
（1）高性能函數(shù)。如果系統(tǒng)支持，使用epoll/port/kqueue等高性能多路復(fù)用函數(shù)。在此，將多路復(fù)用監(jiān)控線程封裝在RtpService類(lèi)中，將rtp連接，封裝在RtpConnection類(lèi)中。使用模型可以參見(jiàn)《【原創(chuàng)】技術(shù)系列之 網(wǎng)絡(luò)模型（二）》
（2）多線程支持。啟動(dòng)多個(gè)RtpService示例，也既是啟動(dòng)多個(gè)多路復(fù)用監(jiān)控線程。將RtpConnection對(duì)象均勻的插入到各個(gè)RtpService中，同時(shí)在RtpConnection中記錄它屬于的RtpService，便于刪除的時(shí)候找到它所在的RtpService。
（3）收數(shù)據(jù)線程直接轉(zhuǎn)發(fā)。處于實(shí)時(shí)性的需要，一定要在收數(shù)據(jù)的線程轉(zhuǎn)發(fā)數(shù)據(jù)，而不是向其它線程發(fā)送消息，讓其它線程完成發(fā)送。這樣做一是避免不必要的內(nèi)存復(fù)制，最重要的是，線程調(diào)度引起的時(shí)間不確定性不能保證轉(zhuǎn)發(fā)的實(shí)時(shí)性。
（4）讀寫(xiě)鎖代替普通鎖。分發(fā)數(shù)據(jù)的時(shí)候（轉(zhuǎn)發(fā)不需要）勢(shì)必要掃描一個(gè)容器中的對(duì)象，進(jìn)行分發(fā)操作，分發(fā)發(fā)生在不同的線程中，加鎖成為必然。讀寫(xiě)鎖代替普通鎖，使掃描操作不必互斥，也避免（2）中的多線程不能發(fā)揮多線程的效果。注意：測(cè)試發(fā)現(xiàn)，linux2.6內(nèi)核中的讀寫(xiě)鎖，只有在靜態(tài)初時(shí)化的時(shí)候，才能寫(xiě)優(yōu)先，使用pthread_rwlock_init進(jìn)行初始化，不管如何設(shè)置它的屬性（即便是設(shè)置屬性為寫(xiě)優(yōu)先），都不能實(shí)現(xiàn)寫(xiě)優(yōu)先效果，因此需要自己使用pthread_mutex_t和pthread_cond_t實(shí)現(xiàn)寫(xiě)優(yōu)先的讀寫(xiě)鎖，具體實(shí)現(xiàn)的細(xì)節(jié)就不再多說(shuō)了（可以參考《【原創(chuàng)】技術(shù)系列之 線程（二）》中線程消息隊(duì)列中鎖的實(shí)現(xiàn)），重要的是想法，不是實(shí)現(xiàn)。寫(xiě)優(yōu)先的必要性是因?yàn)檗D(zhuǎn)發(fā)線程活躍頻繁，而讀線程可以一直進(jìn)入讀鎖，造成寫(xiě)線程永久性的處于等待狀態(tài)。
（5）使用Epoll的ET模式。再此對(duì)epoll多說(shuō)一點(diǎn)，在《【原創(chuàng)】技術(shù)系列之 網(wǎng)絡(luò)模型（三）多路復(fù)用模型》
中因?yàn)槲耶?dāng)時(shí)的測(cè)試場(chǎng)景是普通的http交互，得出“LT和ET性能相當(dāng)”的結(jié)論，跟帖中網(wǎng)友bluesky給予更正，非常感謝。在這個(gè)rtp轉(zhuǎn)發(fā)的場(chǎng)景中，特別適合ET模式，一次觸發(fā)，必須讀盡接收緩沖區(qū)的數(shù)據(jù)，一是保證轉(zhuǎn)發(fā)實(shí)時(shí)性，一是避免剩余數(shù)據(jù)再次觸發(fā)（并發(fā)高的情況下，多路復(fù)用函數(shù)的被觸發(fā)已非常頻繁，因此要盡量減少不必要的觸發(fā)），這個(gè)場(chǎng)景下，多一次的讀操作微不足道。
（6）減少系統(tǒng)調(diào)用次數(shù)。系統(tǒng)調(diào)用是比內(nèi)存copy性能更差的操作，這個(gè)再后面的文章中會(huì)再詳細(xì)描述。網(wǎng)絡(luò)層中的系統(tǒng)可以減少的就是read/recv/recvfrom類(lèi)的操作，極端化低性能的操作就是一次讀一個(gè)字節(jié)，造成系統(tǒng)調(diào)用的次數(shù)大幅上升，一般的做法，是開(kāi)辟緩存（比如char buf[4096];），一次讀取盡可能多的字節(jié)。
（7）二進(jìn)制包使用結(jié)構(gòu)直接解包，字符性包延遲解包。這兩點(diǎn)的出發(fā)點(diǎn)都是盡量減少內(nèi)存復(fù)制。二進(jìn)制解包舉例：首先根據(jù)協(xié)議規(guī)定的包結(jié)構(gòu)，定義結(jié)構(gòu)體。
比如（注：網(wǎng)友powervv 跟帖指出，要點(diǎn)在于大小端主機(jī)序、網(wǎng)絡(luò)序和主機(jī)序之間的轉(zhuǎn)換、以及字節(jié)對(duì)齊問(wèn)題，避免誤導(dǎo)讀者，舉例做出修改）：

struct RTPHeader
{
#if __BYTE_ORDER == __BIG_ENDIAN
  unsigned char v:2; 
  unsigned char p:1;
  unsigned char x:1;
  unsigned char cc:4;
  unsigned char m:1;
  unsigned char pt:7; 
#else
  unsigned char cc:4; 
  unsigned char x:1; 
  unsigned char p:1; 
  unsigned char v:2; 
  unsigned char pt:7;
  unsigned char m:1;
#endif
  unsigned seq:16;
  unsigned tm:32;
  unsigned ssrc:32;
};

收數(shù)據(jù)到buf，解包過(guò)程則是：

Packet *pack=(Packet *)buf

完成解包，讀取seq的時(shí)候，需要ntohs轉(zhuǎn)化，tm同樣要ntohl。
打包相同：

char buf[12];
Packet *pack=(Packet *)buf;
packe->v=2;
.
pack->seq=htons(1);

字符性包解包，則一般是預(yù)解包掃描buf，將每個(gè)字段的偏移和長(zhǎng)度記錄下來(lái)，等需要的時(shí)候在進(jìn)行內(nèi)存復(fù)制操作（常用的則是立即復(fù)制出來(lái)）。通常將字段使用枚舉定義，比如有字段MAX_FIEDS_NUM個(gè)，定義開(kāi)始位置和偏移結(jié)構(gòu)：

struct FieldLoc
{
 int loc;
 int len;
};

則定義 FieldLoc[MAX_FIEDS_NUM]，準(zhǔn)備保存各個(gè)字段的偏移和長(zhǎng)度。至于掃描字段引起的性能損耗和內(nèi)存復(fù)制引起的性能比較將在后面闡述。
（8）內(nèi)存池相關(guān)、系統(tǒng)調(diào)用以及內(nèi)存復(fù)制等的代價(jià)這些通用性能部分后面會(huì)再有描述。