1. 背景與目標(biāo)
本次任務(wù)的目標(biāo)是將一個(gè)用 Haskell 編寫的加密傳輸協(xié)議（Metro.TP.RSA）移植到 Go 語言中，并封裝為標(biāo)準(zhǔn)的 net.Conn 接口，以便替換原有的 XORConn 實(shí)現(xiàn)。
該協(xié)議不僅僅是簡單的加密，還是一個(gè)帶有狀態(tài)協(xié)商的混合協(xié)議，主要包含以下特性：
- 身份握手：基于 RSA 公私鑰交換指紋（SHA256），驗(yàn)證客戶端和服務(wù)端的合法性。
- 模式協(xié)商：支持三種傳輸模式：
-
Plain(0): 明文直連。 -
RSA(1): 全程使用 RSA-OAEP 加密（傳統(tǒng)/兼容模式）。 -
AES(2): 使用協(xié)商出的 Session Key 進(jìn)行 AES-256-CTR 加密（高性能模式）。
2. 遇到的核心問題
在初步移植完成后，我們遇到了一個(gè)非常詭異的現(xiàn)象：
- Plain 模式：一切正常，握手成功，數(shù)據(jù)傳輸流暢。
- AES/RSA 模式：握手看似完成，但隨后連接陷入“假死”狀態(tài)（Hang），無法讀取數(shù)據(jù)。
通常如果是加密算法錯(cuò)誤（如 IV 錯(cuò)誤、Padding 錯(cuò)誤），程序往往會(huì)直接報(bào)錯(cuò)（Decryption Failed）。這種“卡住”的現(xiàn)象通常意味著協(xié)議狀態(tài)機(jī)不同步或數(shù)據(jù)分包（Framing）出了問題。
3. 深度排查：字節(jié)級(jí)“腦裂”
經(jīng)過排查，問題的根源隱藏在 Haskell 和 Go 對枚舉類型（Enum）默認(rèn)序列化行為的差異中。
3.1 協(xié)議差異分析
-
Haskell 端 (
Data.Binary)：
RSAMode派生自Generic。對于這種簡單的 Sum Type（枚舉），Haskell 的標(biāo)準(zhǔn)二進(jìn)制庫將其編碼為 1 個(gè)字節(jié) 的索引值（0, 1, 2）。 -
Go 端 (舊代碼)：
我們在發(fā)送模式時(shí)，習(xí)慣性地使用了binary.BigEndian.PutUint64，發(fā)送了 8 個(gè)字節(jié)。
3.2 故障重現(xiàn)
當(dāng) Go 客戶端請求 AES 模式 (2) 時(shí)，發(fā)生了以下交互：
-
Go 發(fā)送：
00 00 00 00 00 00 00 02(8字節(jié))。 -
Haskell 接收：讀取 1個(gè)字節(jié)，讀到了
00。 -
Haskell 狀態(tài)：
00對應(yīng)Plain模式。Haskell 認(rèn)為協(xié)商結(jié)束，進(jìn)入明文接收狀態(tài)。 - Go 狀態(tài)：發(fā)送完畢，認(rèn)為協(xié)商成功，進(jìn)入 AES 模式，開始發(fā)送加密后的 Session Key。
- 結(jié)果（腦裂）：
- Haskell 在等明文應(yīng)用數(shù)據(jù)。
- Go 發(fā)送了一堆加密的二進(jìn)制流（Session Key）。
- Haskell 讀入這些亂碼試圖處理，導(dǎo)致邏輯錯(cuò)亂或在等待后續(xù)數(shù)據(jù)包頭（Length Header）時(shí)無限阻塞。
3.3 為什么 Plain 模式能跑通？
這是一個(gè)極具迷惑性的巧合。
當(dāng) Go 請求 Plain (0) 時(shí)，發(fā)送的是 00 00 00 00 00 00 00 00。
Haskell 讀取第一個(gè)字節(jié) 00，解析為 Plain。
雖然 Go 多發(fā)了7個(gè)字節(jié)的 00，但因?yàn)楹罄m(xù)是明文傳輸，這幾個(gè)空字節(jié)可能被應(yīng)用層忽略或恰好未造成嚴(yán)重破壞（視具體應(yīng)用層協(xié)議而定），從而掩蓋了 bug。
4. 解決方案與最終實(shí)現(xiàn)
4.1 修復(fù)序列化
將 Go 代碼中的模式發(fā)送與接收嚴(yán)格限制為 1 字節(jié)：
// 發(fā)送 (Client)
modeByte := []byte{byte(mode)}
c.sendDataOAEP(modeByte)
// 接收 (Server)
modeBytes, _ := c.recvDataOAEP()
mode := int(modeBytes[0])
4.2 完善流式處理
由于 AES-CTR 是流加密，但協(xié)議定義了 [Length][IV][Body] 的封包格式，而 net.Conn.Read 是流式的。為了防止 TCP 粘包或斷包導(dǎo)致解密失敗，我們在 Go 結(jié)構(gòu)體中引入了 bytes.Buffer：
type RSAConn struct {
net.Conn
// ... keys ...
readBuf bytes.Buffer // 關(guān)鍵：內(nèi)部緩沖
}
func (c *RSAConn) Read(b []byte) (n int, err error) {
// 優(yōu)先從緩沖區(qū)吐出已解密數(shù)據(jù)
if c.readBuf.Len() > 0 {
return c.readBuf.Read(b)
}
// 緩沖區(qū)空，從網(wǎng)絡(luò)讀取完整的一個(gè)加密包，解密后填入緩沖區(qū)
// ... recvDataAES logic ...
}
5. 總結(jié)與經(jīng)驗(yàn)
-
跨語言協(xié)議必須精確到字節(jié)：不要假設(shè)
Int是 4 字節(jié)還是 8 字節(jié)，也不要依賴語言特定的序列化庫（如 Haskell 的Generic或 Go 的gob），除非你完全掌控兩端的實(shí)現(xiàn)。明確規(guī)定uint8、uint64(BigEndian) 是最穩(wěn)妥的。 - 警惕“部分正?！钡?Bug：Plain 模式的正常運(yùn)行是最大的干擾項(xiàng)，它讓我們誤以為握手邏輯是完美的，從而將排查方向引向了復(fù)雜的加密算法本身，實(shí)際上問題只是簡單的類型寬度不匹配。
-
流式接口的適配：將基于包（Packet-based）的協(xié)議適配到流（Stream-based）接口（如
io.Reader）時(shí)，必須實(shí)現(xiàn)內(nèi)部緩沖機(jī)制，否則極易出現(xiàn)粘包處理不當(dāng)?shù)膯栴}。
通過這次修復(fù)，我們成功實(shí)現(xiàn)了一個(gè)兼容 Haskell 后端、支持 RSA 身份驗(yàn)證和 AES 高速加密的 Go 語言傳輸層模塊，為后續(xù)的服務(wù)端功能擴(kuò)展（如 CS2 開箱服務(wù)）打下了堅(jiān)實(shí)基礎(chǔ)。
