[01] C#網路程式設計的最佳實踐
網路框架的選擇
C++語言裡面有asio和libuv等網路庫, 可以方便的進行各種高效程式設計. 但是C#裡面, 情況不太一樣, C#自帶的網路API有多種. 例如:
- Socket
- TcpStream(同步介面和BeginXXX非同步介面)
- TcpStream Async/Await
- Pipeline IO
- ASP.NET Core Bedrock
眾多網路庫, 但是每個程式設計模型都不太一樣, 和C++裡面我常用的reactor模型有很大區別. 最重要的是, 程式設計難度和效能不是很好. 尤其是後面三種模型, 都是面對輕負載的網際網路應用設計, 每個玩家跑兩個協程(一讀一寫)會對程序造成額外的負擔.
Golang面世的時候, 大家都說協程好用, 簡單, 效能高. 可是面對大量 高頻互動的應用, 最終還是需要重新編寫網路層(參見Gnet). 因為協程上下文切換需要消耗微秒左右的時間(通常是0.5us到1微秒左右), 另外有棧協程佔用額外的記憶體(無棧協程不存在這個問題).
所以在C#裡面需要選擇一個類似於Reactor模型的網路庫. Java裡面有Netty. 好在微軟把Netty移植到了.NET裡面, 所以我們只需要照著Netty的文件和DotNetty的Sample(包括原始碼)就可以寫出高效的網路框架.
另外DotNetty有libuv的外掛, 可以將傳輸層放到libuv內, 減少託管語言的消耗.
DotNetty程式設計
由於我們是伺服器程式設計, 需要處理多個Socket而不像客戶端只需要處理一兩個Socket, 所以在每個Socket上, 都需要做一些標記資訊, 用來標記當前Socket的狀態(是否登入, 使用者是哪個等等); 還需要一個管理維護的這些Socket的管理者類.
連結狀態
Socket的狀態可以使用IChannel.GetAttribute
來實現, 我們可以給IChannel上面增加一個SessionInfo
的屬性, 用來儲存當前連結的其他可變屬性. 那麼可以這麼做:
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);
//其他引數
}));
由於遊戲伺服器通常是有狀態服務, 所以連結上還需要儲存PlayerID, OpenID等資訊, 方便解碼器在解碼的時候, 直接把訊息派發給相應的處理器.
管理器和生命週期
託管語言有GC, 但是對於非託管資源還是需要手動管理. C#有IDisposable
模式, 可以簡化異常場景下資源釋放問題, 但是對於Socket這種生命週期比較長的資源就無能為力了.
所以, 我們必須要編寫自己的ChannelManager
類, 並且遵從:
- 新連結一定要立刻放到Manager裡面
- 通過ID來獲取IChannel, 不做長時間持有
- 想要長時間持有, 則使用WeakReference
- MessageHandler的異常裡面釋放Manager裡面的IChannel
- 心跳超時也要釋放IChannel
對於IChannel物件的持有, 一定要是短時間的持有
, 比如在一次函式呼叫內獲取, 否則問題會變得很複雜.
防止主動關閉Socket和異常同時發生, IChannel.CloseAsync()
函式呼叫需要try catch.
引數調節
GameServer一般來講單個網路執行緒就夠了, 但是作為閘道器是絕對不夠的, 所以網路庫需要支援多執行緒Loop. 好在DotNetty這方面比較簡單, 只需要構造的時候改一下引數, 具體可以看看Sample, 託管和Libuv的傳輸層構造不一樣.
var bootstrap = new ServerBootstrap();
//1個boss執行緒, N個工作執行緒
bootstrap.Group(this.bossGroup, this.workerGroup);
if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux)
|| RuntimeInformation.IsOSPlatform(OSPlatform.OSX))
{
//Linux下需要重用埠, 否則伺服器立馬重啟會端口占用
bootstrap
.Option(ChannelOption.SoReuseport, true)
.ChildOption(ChannelOption.SoReuseaddr, true);
}
bootstrap
.Channel<TcpServerChannel>()
//Linux預設backlog只有128, 併發較高的時候新連結會連不上來
.Option(ChannelOption.SoBacklog, 1024)
//跑滿一個網路需要最少 頻寬*延遲 的滑動視窗
//行動網路延遲比較高, 建議設定成64KB以上
//如果是內網通訊, 建議設定成128KB以上
.Option(ChannelOption.SoRcvbuf, 128 * 1024)
.Option(ChannelOption.SoSndbuf, 128 * 1024)
//將預設的記憶體分配器改成 記憶體池版本的分配器
//會佔用較多的記憶體, 但是GC負擔比較小
//一個堆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 =>
{
這裡強調一下高低水位. 如果往一個Socket不停的發訊息, 但是對端接收很慢, 那麼正確的做法就是要把他T掉, 否則一直髮下去, 伺服器可能會記憶體不足. 這部分記憶體是無法GC的, 處理不當可能會被攻擊.
編解碼器和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();
//這只是示例程式碼, 實際需要根據具體情況調整
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);
}
真實情況肯定要比這個複雜, 這裡只是一個簡單的sample. 讀取訊息因為需要考慮半包的存在, 所以需要ResetReaderIndex
, 在編碼的時候就不存在這個情況.
編碼的情況就要稍微簡單一些, 因為解碼可能包不完整, 但是編碼不會出現半個訊息的情況, 所以在編碼初期就能知道整個訊息的大小(也有部分序列化型別會不知道訊息長度).
var allocator = PooledByteBufferAllocator.Default;
var buffer = allocator.Buffer(Length);
buffer.WriteIntLE(Header);
buffer.WriteIntLE(MsgID);
//xxx這邊寫body
用ByteBuffer編碼Protobuf
之所以這邊要單獨提出來, 是因為高效能的伺服器程式設計, 需要榨乾一些能榨乾的東西(在力所能及的範圍內).
很多人做Protobuf IMessage
序列化的時候, 就是簡單的一句msg.ToByteArray()
. 如果伺服器是輕負載伺服器, 那麼這麼寫一點問題都沒有; 否則就會多產生一個byte[]陣列物件. 這顯然不是我們想要的.
對於編碼器來講, 我們肯定是希望我給定一個預定的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();
}
通過程式碼分析可以看出內部在使用CodedOutputStream
做編碼, 但是這個類的建構函式, 沒有支援Slice的過載. 通過dnSpy
反彙編發現有一個私有的過載:
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上面先申請好記憶體, 然後在寫到ByteBuffer上, 減少了一次拷貝
和記憶體申請
操作, 主要是對GC的壓力會減輕不少.
這邊給出示意程式碼:
var messageLength = msg.CalculateSize();
var buffer = allocator.Buffer(messageLength);
ArraySegment<byte> data = buffer.GetIoBuffer(buffer.WriterIndex, messageLength);
//這邊需要通過反射去呼叫CodedOutputStream物件的私有建構函式
//具體可以研究一下
using var stream = createCodedOutputStream(data.Array, data.Offset, messageLength);
msg.WriteTo(stream);
stream.Flush();
至此, 我們就實現了高效的編碼和解碼器.
網路小包的處理
小包處理的一般思路不外乎合批, 合批壓縮. 後者實現的難度要稍微高一點. 主要是遊戲的流量還沒有高到每一幀都會發送超過幾百位元組(小於128Byte的包壓縮起來效果沒那麼好).
所以, 只有登入的時候, 伺服器把玩家的幾十K到上百K資料傳送給客戶端的時候, 壓縮的時候才有效果; 平時只需要合批就可以了.
合批還能解決另外一個問題, 就是網絡卡PPS的瓶頸. 雖然是千兆網, 但是PPS一般都是在60W~100Wpps這個範圍. 意味著一味的發小包, 一秒最多收發60W到100W個小包, 所以需要通過合批來突破PPS的瓶頸.
這是騰訊雲SA2機型PPS的資料:
DotNetty中合批的兩種實現方式. 先說第一種.
DotNetty傳送訊息有兩個API:
- WriteAsync
- WriteAndFlushAsync 其中第一個API只是把ByteBuffer塞到Channel要傳送的佇列裡面去, 第二個API塞到佇列裡面去還會觸發真正的Send操作.
比如說我們要傳送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的原始碼, 發現他底層實現也是呼叫傳送一個List的API, 那麼就可以達到我們想要的效果.
還有一種方式, 就是把想要傳送的訊息攢一攢, 通過Allocter New一個更大的Buffer, 然後把這些訊息全部塞進去, 再一次性發出去. 彩虹聯萌伺服器用的就是這種方式, 大概10ms主動傳送一次.
DotNetty的缺點
與其說是DotNetty的缺點, 不如說是所有託管記憶體語言的缺點. 所有託語言申請和釋放資源的開銷是不固定的, 這是IO密集型應用面臨的巨大挑戰.
在C++/Rust帶有RAII的語言裡面, 申請一塊Buffer和釋放一塊Buffer的消耗都是比較固定的. 比如New一塊記憶體大概是25ns, Delete一塊大概是30~50ns.
但是在託管記憶體語言裡面, New一塊記憶體大概25ns, Delete就不一定了. 因為你不能手動Delete, 只能靠GC來Delete. 但是GC釋放資源的時候, 會有Stop. 不管是並行GC還是非並行GC, 只是Stop時間的長短.
只有消除GC之後, 程式才會跑得非常快, 和Benchmark Game內跑的一樣快.
所以, 為了避免這個問題, 需要:
-
把IO和計算分開
這就是傳統遊戲伺服器把Gateway和GameServer分開的好處. IO密集在Gateway, GC Stop對GameServer影響不大, 對玩家收發訊息影響也不大.
-
把IO放到C++/Rust裡面去
這不是奇思妙想, 是大家都這麼做. 例如ASP.NET Core就用libuv當做傳輸層.
所以對於遊戲伺服器來講, 可以在C++/Rust內實現傳輸層, 然後通過P/Invoke來和Native層通訊, 降低IO不斷分配記憶體對計算部分的影響.
-
將程式改造成Alloc Free
如果我不分配物件, 就不會有GC, 也就不會對計算有影響. 這也是筆者才彩虹聯萌伺服器內做的事情.
Alloc Free是我自己造的詞彙, 類似於Lock Free. 但是不是說不分配任何記憶體, 只是把高頻分配降低了, 低頻分配還是允許的, 否則程式碼會非常難寫.
參考: