CppExplore

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

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

Packet *pack=(Packet *)buf

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

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

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

struct FieldLoc
{
 int loc;
 int len;
};

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