多路復(fù)用其實(shí)并不是什么新技術(shù)，它的作用是在一個(gè)通訊連接的基礎(chǔ)上可以同時(shí)進(jìn)行多個(gè)請求響應(yīng)處理。對于網(wǎng)絡(luò)通訊來其實(shí)不存在這一說法，因?yàn)榫W(wǎng)絡(luò)層面只負(fù)責(zé)數(shù)據(jù)傳輸；由于上層應(yīng)用協(xié)議的制訂問題，導(dǎo)致了很多傳統(tǒng)服務(wù)并不能支持多路復(fù)用；如：http1.1，sqlserver和redis等等，雖然有些服務(wù)提供批量處理，但這些處理都基于一個(gè)RPS下。下面通過圖解來了解釋單路和多路復(fù)用的區(qū)別。

單路存在的問題

每個(gè)請求響應(yīng)獨(dú)占一個(gè)連接，并獨(dú)占連接網(wǎng)絡(luò)讀寫；這樣導(dǎo)致連接在有大量時(shí)間被閑置無法更好地利用網(wǎng)絡(luò)資源。由于是獨(dú)占讀寫IO，這樣導(dǎo)致RPS處理量由必須由IO承擔(dān)，IO操作起來比較損耗性能，這樣在高RPS處理就出現(xiàn)性能問題。由于不能有效的合并IO也會(huì)導(dǎo)致在通訊中的帶寬存在浪費(fèi)情況，特別對于比較小的請求數(shù)據(jù)包。通訊上的延時(shí)當(dāng)要持大量的RPS那就必須要有更多連接支撐，連接數(shù)增加也對資源的開銷有所增加。

多路復(fù)用的優(yōu)點(diǎn)

多路復(fù)用可以在一個(gè)連接上同時(shí)處理多個(gè)請求響應(yīng)，這樣可以大大的減少連接的數(shù)量，并提高了網(wǎng)絡(luò)的處理能力。由于是共享連接不同請求響應(yīng)數(shù)據(jù)包可以合并到一個(gè)IO上處理，這樣可以大大降低IO的處理量，讓性能表現(xiàn)得更出色。

通過多路復(fù)用實(shí)現(xiàn)百萬級(jí)RPS

多路復(fù)用是不是真的如此出色呢，以下在.net core上使用多路復(fù)用實(shí)現(xiàn)單服務(wù)百萬RPS吞吐，并能達(dá)到比較低的延時(shí)性。以下是測試流程：

由于基礎(chǔ)通訊不具備消息包合并功能，所以在BeetleX的基礎(chǔ)上做集成測試，主要BeetleX會(huì)自動(dòng)合并消息到一個(gè)Buffer上，從而降低IO的讀寫。

測試消息結(jié)構(gòu)

本測試使用了Protobuf作為基礎(chǔ)交互消息，畢竟Protobuf已經(jīng)是一個(gè)二進(jìn)制序列化標(biāo)準(zhǔn)了。

請求消息

整個(gè)測試開啟了10個(gè)連接，在這10個(gè)連接的基礎(chǔ)上進(jìn)行請求響應(yīng)復(fù)用。

測試配置

測試環(huán)境是兩臺(tái)服務(wù)器，配置是阿里云上的12核服務(wù)器（對應(yīng)的物理機(jī)應(yīng)該是6核12線程）

服務(wù)和客戶端的系統(tǒng)都是：Ubuntu 16.04

Dotnet core版本是：2.14

測試結(jié)果

客戶端統(tǒng)計(jì)結(jié)果

服務(wù)端統(tǒng)計(jì)信息

帶寬統(tǒng)計(jì)

測試使用了10個(gè)連接進(jìn)行多路復(fù)用，每秒接收響應(yīng)量在100W，大部分響應(yīng)延時(shí)在1-3毫秒之間。