C#網(wǎng)絡(luò)編程的最佳實踐
轉(zhuǎn)自：egmkang cnblogs.com/egmkang/p/13637768.html
網(wǎng)絡(luò)框架的選擇
C++語言里面有asio和libuv等網(wǎng)絡(luò)庫, 可以方便的進(jìn)行各種高效編程. 但是C#里面, 情況不太一樣, C#自帶的網(wǎng)絡(luò)API有多種. 例如:
Socket
TcpStream(同步接口和BeginXXX異步接口)
TcpStream Async/Await
Pipeline IO
ASP.NET Core Bedrock
眾多網(wǎng)絡(luò)庫, 但是每個編程模型都不太一樣, 和C++里面我常用的reactor模型有很大區(qū)別. 最重要的是, 編程難度和性能不是很好. 尤其是后面三種模型, 都是面對輕負(fù)載的互聯(lián)網(wǎng)應(yīng)用設(shè)計, 每個玩家跑兩個協(xié)程(一讀一寫)會對進(jìn)程造成額外的負(fù)擔(dān).
Golang面世的時候, 大家都說協(xié)程好用, 簡單, 性能高. 可是面對大量 高頻交互的應(yīng)用, 最終還是需要重新編寫網(wǎng)絡(luò)層(參見Gnet).
因為協(xié)程上下文切換需要消耗微秒左右的時間(通常是0.5us到1微秒左右), 另外有棧協(xié)程占用額外的內(nèi)存(無棧協(xié)程不存在這個問題).
所以在C#里面需要選擇一個類似于Reactor模型的網(wǎng)絡(luò)庫. Java里面有Netty. 好在微軟把Netty移植到了.NET里面, 所以我們只需要照著Netty的文檔和DotNetty的Sample(包括源碼)就可以寫出高效的網(wǎng)絡(luò)框架.
另外DotNetty有l(wèi)ibuv的插件, 可以將傳輸層放到libuv內(nèi), 減少托管語言的消耗.
DotNetty編程
由于我們是服務(wù)器編程, 需要處理多個Socket而不像客戶端只需要處理一兩個Socket, 所以在每個Socket上, 都需要做一些標(biāo)記信息, 用來標(biāo)記當(dāng)前Socket的狀態(tài)(是否登錄, 用戶是哪個等等); 還需要一個管理維護(hù)的這些Socket的管理者類.
鏈接狀態(tài)
Socket的狀態(tài)可以使用IChannel.GetAttribute來實現(xiàn), 我們可以給IChannel上面增加一個SessionInfo的屬性, 用來保存當(dāng)前鏈接的其他可變屬性. 那么可以這么做:
public class SessionInfo
{
//SessionID不可變
private readonly long sessionID;
public SessionInfo(long sessionID)
{
this.sessionID = sessionID;
}
//其他屬性
}
static readonly AttributeKey<ConnectionSessionInfo> SESSION_INFO = AttributeKey<ConnectionSessionInfo>.ValueOf("SessionInfo");
//新鏈接
bootstrap.ChildHandler(new ActionChannelInitializer<IChannel>(channel =>
{
var sessionInfo = new SessionInfo(++seed);
channel.GetAttribute(SESSION_INFO).Set(sessionInfo);
//其他參數(shù)
}));
由于游戲服務(wù)器通常是有狀態(tài)服務(wù), 所以鏈接上還需要保存PlayerID, OpenID等信息, 方便解碼器在解碼的時候, 直接把消息派發(fā)給相應(yīng)的處理器.
管理器和生命周期
托管語言有GC, 但是對于非托管資源還是需要手動管理. C#有IDisposable模式, 可以簡化異常場景下資源釋放問題, 但是對于Socket這種生命周期比較長的資源就無能為力了.
所以, 我們必須要編寫自己的ChannelManager類, 并且遵從:
新鏈接一定要立刻放到Manager里面
通過ID來獲取IChannel, 不做長時間持有
想要長時間持有, 則使用WeakReference
MessageHandler的異常里面釋放Manager里面的IChannel
心跳超時也要釋放IChannel
對于IChannel對象的持有, 一定要是短時間的持有, 比如在一次函數(shù)調(diào)用內(nèi)獲取, 否則問題會變得很復(fù)雜.
防止主動關(guān)閉Socket和異常同時發(fā)生, IChannel.CloseAsync()函數(shù)調(diào)用需要try catch.
參數(shù)調(diào)節(jié)
GameServer一般來講單個網(wǎng)絡(luò)線程就夠了, 但是作為網(wǎng)關(guān)是絕對不夠的, 所以網(wǎng)絡(luò)庫需要支持多線程Loop. 好在DotNetty這方面比較簡單, 只需要構(gòu)造的時候改一下參數(shù), 具體可以看看Sample, 托管和Libuv的傳輸層構(gòu)造不一樣.
var bootstrap = new ServerBootstrap();
//1個boss線程, N個工作線程
bootstrap.Group(this.bossGroup, this.workerGroup);
if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux)
|| RuntimeInformation.IsOSPlatform(OSPlatform.OSX))
{
//Linux下需要重用端口, 否則服務(wù)器立馬重啟會端口占用
bootstrap
.Option(ChannelOption.SoReuseport, true)
.ChildOption(ChannelOption.SoReuseaddr, true);
}
bootstrap
.Channel<TcpServerChannel>()
//Linux默認(rèn)backlog只有128, 并發(fā)較高的時候新鏈接會連不上來
.Option(ChannelOption.SoBacklog, 1024)
//跑滿一個網(wǎng)絡(luò)需要最少 帶寬*延遲 的滑動窗口
//移動網(wǎng)絡(luò)延遲比較高, 建議設(shè)置成64KB以上
//如果是內(nèi)網(wǎng)通訊, 建議設(shè)置成128KB以上
.Option(ChannelOption.SoRcvbuf, 128 * 1024)
.Option(ChannelOption.SoSndbuf, 128 * 1024)
//將默認(rèn)的內(nèi)存分配器改成 內(nèi)存池版本的分配器
//會占用較多的內(nèi)存, 但是GC負(fù)擔(dān)比較小
//一個堆16M, 會占用多個堆
.Option(ChannelOption.Allocator, PooledByteBufferAllocator.Default)
.ChildOption(ChannelOption.TcpNodelay, true)
.ChildOption(ChannelOption.SoKeepalive, true)
//開啟高低水位
.ChildOption(ChannelOption.WriteBufferLowWaterMark, 64 * 1024)
.ChildOption(ChannelOption.WriteBufferHighWaterMark, 128 * 1024)
.ChildHandler(new ActionChannelInitializer<IChannel>(channel =>
{
這里強調(diào)一下高低水位. 如果往一個Socket不停的發(fā)消息, 但是對端接收很慢, 那么正確的做法就是要把他T掉, 否則一直發(fā)下去, 服務(wù)器可能會內(nèi)存不足. 這部分內(nèi)存是無法GC的, 處理不當(dāng)可能會被攻擊.
編解碼器和ByteBuffer的使用
DotNetty有封裝好的IByteBuffer類, 該類是一個Stream, 支持Mark/Reset/Read/Write. 和Netty不太一樣的是ByteBuffer類沒有大小端, 而是在接口上做了大小端處理.
對于一個解碼器, 大致的樣式是:
public static (int length, uint msgID, IByteBuffer bytes) DecodeOneMessage(IByteBuffer buffer)
{
if (buffer.ReadableBytes < MinPacketLength)
{
return (0, 0, null);
}
buffer.MarkReaderIndex();
//這只是示例代碼, 實際需要根據(jù)具體情況調(diào)整
var head = buffer.ReadUnsignedIntLE();
var msgID = buffer.ReadUnsignedIntLE();
var bodyLength = head & 0xFFFFFF;
if (buffer.ReadableBytes < bodyLength)
{
buffer.ResetReaderIndex();
return (0, 0, null);
}
var bodyBytes = buffer.Allocator.Buffer(bodyLength);
buffer.ReadBytes(bodyBytes, bodyLength);
return (bodyLength + 4 + 4, msgID, bodyBytes);
}
真實情況肯定要比這個復(fù)雜, 這里只是一個簡單的sample. 讀取消息因為需要考慮半包的存在, 所以需要ResetReaderIndex, 在編碼的時候就不存在這個情況.
編碼的情況就要稍微簡單一些, 因為解碼可能包不完整, 但是編碼不會出現(xiàn)半個消息的情況, 所以在編碼初期就能知道整個消息的大小(也有部分序列化類型會不知道消息長度).
var allocator = PooledByteBufferAllocator.Default;
var buffer = allocator.Buffer(Length);
buffer.WriteIntLE(Header);
buffer.WriteIntLE(MsgID);
//xxx這邊寫body
用ByteBuffer編碼Protobuf
之所以這邊要單獨提出來, 是因為高性能的服務(wù)器編程, 需要榨干一些能榨干的東西(在力所能及的范圍內(nèi)).
很多人做Protobuf IMessage序列化的時候, 就是簡單的一句msg.ToByteArray(). 如果服務(wù)器是輕負(fù)載服務(wù)器, 那么這么寫一點問題都沒有; 否則就會多產(chǎn)生一個byte[]數(shù)組對象. 這顯然不是我們想要的.
對于編碼器來講, 我們肯定是希望我給定一個預(yù)定的byte[], 你序列化的時候往這里面寫. 所以我們來研究一下Protobuf的消息序列化.
//反編譯的代碼
public static Byte[] ToByteArray(this IMessage message)
{
ProtoPreconditions.CheckNotNull(message, "message");
CodedOutputStream codedOutputStream = new CodedOutputStream(new Byte[message.CalculateSize()]);
message.WriteTo(codedOutputStream);
return (Byte[])codedOutputStream.CheckNoSpaceLeft();
}
通過代碼分析可以看出內(nèi)部在使用CodedOutputStream做編碼, 但是這個類的構(gòu)造函數(shù), 沒有支持Slice的重載. 通過dnSpy反匯編發(fā)現(xiàn)有一個私有的重載:
private CodedOutputStream(byte[] buffer, int offset, int length)
{
this.output = null;
this.buffer = buffer;
this.position = offset;
this.limit = offset + length;
this.leaveOpen = true;
}
這就是我們所需要的接口, 有了這個接口就可以在ByteBuffer上面先申請好內(nèi)存, 然后在寫到ByteBuffer上, 減少了一次拷貝和內(nèi)存申請操作, 主要是對GC的壓力會減輕不少.
這邊給出示意代碼:
var messageLength = msg.CalculateSize();
var buffer = allocator.Buffer(messageLength);
ArraySegment<byte> data = buffer.GetIoBuffer(buffer.WriterIndex, messageLength);
//這邊需要通過反射去調(diào)用CodedOutputStream對象的私有構(gòu)造函數(shù)
//具體可以研究一下
using var stream = createCodedOutputStream(data.Array, data.Offset, messageLength);
msg.WriteTo(stream);
stream.Flush();
至此, 我們就實現(xiàn)了高效的編碼和解碼器.
網(wǎng)絡(luò)小包的處理
小包處理的一般思路不外乎合批, 合批壓縮. 后者實現(xiàn)的難度要稍微高一點. 主要是游戲的流量還沒有高到每一幀都會發(fā)送超過幾百字節(jié)(小于128Byte的包壓縮起來效果沒那么好).
所以, 只有登錄的時候, 服務(wù)器把玩家的幾十K到上百K數(shù)據(jù)發(fā)送給客戶端的時候, 壓縮的時候才有效果; 平時只需要合批就可以了.
合批還能解決另外一個問題, 就是網(wǎng)卡PPS的瓶頸. 雖然是千兆網(wǎng), 但是PPS一般都是在60W~100Wpps這個范圍. 意味著一味的發(fā)小包, 一秒最多收發(fā)60W到100W個小包, 所以需要通過合批來突破PPS的瓶頸.
這是騰訊云SA2機型PPS的數(shù)據(jù):
DotNetty中合批的兩種實現(xiàn)方式. 先說第一種.
DotNetty發(fā)送消息有兩個API:
WriteAsync
WriteAndFlushAsync 其中第一個API只是把ByteBuffer塞到Channel要發(fā)送的隊列里面去, 第二個API塞到隊列里面去還會觸發(fā)真正的Send操作.
比如說我們要發(fā)送4個消息, 那么可以先:
//queue是一個List<IMessage>
for(int i = 0; i < queue.Count; ++i)
{
if ((i + 1) % 4 == 0)
{
channel.WriteAndAsync(queue[i]);
}
else
{
channel.WriteAsync(queue[i]);
}
}
channel.Flush();
然后我們研究DotNetty的源碼, 發(fā)現(xiàn)他底層實現(xiàn)也是調(diào)用發(fā)送一個List的API, 那么就可以達(dá)到我們想要的效果.
還有一種方式, 就是把想要發(fā)送的消息攢一攢, 通過Allocter New一個更大的Buffer, 然后把這些消息全部塞進(jìn)去, 再一次性發(fā)出去. 彩虹聯(lián)萌服務(wù)器用的就是這種方式, 大概10ms主動發(fā)送一次.
DotNetty的缺點
與其說是DotNetty的缺點, 不如說是所有托管內(nèi)存語言的缺點. 所有托語言申請和釋放資源的開銷是不固定的, 這是IO密集型應(yīng)用面臨的巨大挑戰(zhàn).
在C++/Rust帶有RAII的語言里面, 申請一塊Buffer和釋放一塊Buffer的消耗都是比較固定的. 比如New一塊內(nèi)存大概是25ns, Delete一塊大概是30~50ns.
但是在托管內(nèi)存語言里面, New一塊內(nèi)存大概25ns, Delete就不一定了. 因為你不能手動Delete, 只能靠GC來Delete. 但是GC釋放資源的時候, 會有Stop. 不管是并行GC還是非并行GC, 只是Stop時間的長短.
只有消除GC之后, 程序才會跑得非?？? 和Benchmark Game內(nèi)跑的一樣快.
所以, 為了避免這個問題, 需要:
1、把IO和計算分開
這就是傳統(tǒng)游戲服務(wù)器把Gateway和GameServer分開的好處. IO密集在Gateway, GC Stop對GameServer影響不大, 對玩家收發(fā)消息影響也不大.
2、把IO放到C++/Rust里面去
這不是奇思妙想, 是大家都這么做. 例如ASP.NET Core就用libuv當(dāng)做傳輸層.
所以對于游戲服務(wù)器來講, 可以在C++/Rust內(nèi)實現(xiàn)傳輸層, 然后通過P/Invoke來和Native層通訊, 降低IO不斷分配內(nèi)存對計算部分的影響.
3、將程序改造成Alloc Free
如果我不分配對象, 就不會有GC, 也就不會對計算有影響. 這也是筆者才彩虹聯(lián)萌服務(wù)器內(nèi)做的事情.
Alloc Free是我自己造的詞匯, 類似于Lock Free. 但是不是說不分配任何內(nèi)存, 只是把高頻分配降低了, 低頻分配還是允許的, 否則代碼會非常難寫.
