設計自己的小傳輸協議 導論與概念
1:聊一聊協議頭設計
? 早在《TCP/IP詳解》中的第一句話中,我們就知道協議的含義是這樣的:協議是通信雙方共同遵守的一套規則,提供格式定義、語義解釋等,使不同設備或軟件能夠正確交換信息。但是,就像我們的寫郵件,需要有一定的格式,告知首發地址,收信人和送信人一樣,我們的網絡協議一樣要有協議頭,來告訴我們解析收發程序如何正確的收發包。
? 網絡協議常使用分層封裝,每一層都在數據上加上專屬 header。發送端按層封裝,接收端逐層拆解,各層只解析自身字段,互不干擾。
? 這里,我們簡單說說幾個設計協議的重要的要點:
1. 簡潔高效
- 頭部字段應盡量少,減少帶寬與解析開銷;例如 IPv4 頭部僅最低 20 字節
2. 必要的元數據字段
- 包含版本號(version)、類型/協議字段(protocol/type)、長度(length)、源/目的標識(address/fileId)、狀態或標志(state/flags)等;
- 可選校驗字段如 checksum 或 CRC,提高傳輸可靠性,但應指明 CRC 多項式、初始值、Byte/bit 順序等細節。
3. 長度與分包管理
- 包括 payload 或 name 等可變長度字段長度(如 nameLen、payloadSize)防止粘包/拆包,支持分段重組和安全邊界解析
4. 一致的字節序
- 多平臺交互時需明確使用大端(big?endian)或小端格式,將所有多字節字段統一轉換至 network-order。避免跨平臺字節解釋錯誤。
5. 完整性校驗
- 校驗頭部或 header+payload 的完整性。指定 CRC 類型(如 CRC?32C 等),明確是否 checksum/remainder 等處理規則。
6. 可擴展性與兼容性
- 設計協議版本機制,當協議升級時,舊版能忽略未知字段或拒絕解析。此外可預留擴展字段或 flags,以支持未來功能擴展。
7. 解析流程明確安全防護
- 明確狀態機控制字段(如 current_state),規范包開始/數據/結束階段;避免 payload 中數據干擾 header 標識時,引入同步或轉義機制避免誤識包邊界。
我的設計:
筆者在這里,就是用了這樣的包來表達自己的設計:
#pragma pack(push, 1)
struct DataHeader {quint32 header_magic;quint16 protocol_version;quint8 current_state;quint64 fileId;quint64 offset;quint64 totalSize;quint32 nameLen;quint32 payloadSize;quint32 header_crc;
};
#pragma pack(pop)
? 這樣的設計比較的緊湊,其實說真的,對我們的CPU字節對齊訪問實際上還不太友好,需要一定的Alighment,這樣訪問是最好的實際上。
static constexpr const unsigned intDATAHEADER_SIZE= sizeof(DataHeader);static constexpr quint32 HEADER_MAGIC = 0x00114514; // Magic Number
static constexpr quint16 HEADER_VERSION = 1; // header version
static constexpr const unsigned int DEF_CHUNK_SZ = 16 * 1024; // default chunkable sizeenum class OperationState : quint8 {Start = 1, ///< At header stageData = 2,End = 3 ///< OK finished
};enum class CurrentState {ReadingHeader,ReadingName,ReadingPayload
};
? 這里就是進一步的明細我們的狀態機設計。OperationState說明了我們當前解析的Steps到達那一步,CurrentState實際上是復雜了一些,因為我們還需要進一步consume具體的header name來做處理,這里算是設計的失誤部分(這是筆者從最開始的文件傳輸脫胎出來的。)
CRC校驗
? 在數據傳輸或存儲過程中,誤碼是不可避免的。為了檢測這些錯誤,工程上常用 CRC(Cyclic Redundancy Check,循環冗余校驗)。這里筆者簡單說一下CRC
1. CRC 校驗是什么?
CRC 是一種差錯檢測算法。它的本質是利用一個固定的“生成多項式”,把原始數據看作一個二進制多項式,通過模 2 除法求出“余數”作為校驗值。
簡單理解:
- 發送端:計算數據的 CRC 余數,把它附在數據后面一起發出去。
- 接收端:收到數據后重新算一遍 CRC,如果結果為 0,就認為數據正確,否則說明數據出錯。
模 2 除法的特點
- 加減法用 異或 (XOR) 代替,無進位。
- 計算過程只涉及移位和異或,速度快且易于硬件實現。
2. CRC 工作流程
發送端:
- 選擇一個生成多項式 G(x)G(x)G(x),例如
10011
(對應 x? + x + 1)。 - 在原始數據末尾補上 n 個 0(n 為 G(x) 的階數)。
- 用補零后的數據模 2 除 G(x),得到余數 R。
- 把 R 作為校驗碼附在原始數據末尾發送。
接收端:
- 收到數據后,用同樣的 G(x) 進行模 2 除法。
- 余數若為 0,說明數據無誤;否則數據被破壞。
3. CRC 計算示例
假設:
- 數據:
1101011011
- 生成多項式:
10011
計算步驟:
- 數據補 4 個 0:
1101011011 0000
- 用
10011
逐位模 2 除,得到余數1110
。 - 發送數據:
1101011011 1110
。
接收端用 10011
除 11010110111110
,結果余數為 0,數據正確。
4. CRC-32 高效實現(查表法)
CRC-32 是應用最廣的 CRC 變種之一(如 PNG、ZIP、以太網等都使用它)。
直接按位計算 CRC 效率不高,常用 查表法:提前計算好 256 個字節對應的 CRC 值,然后逐字節查表加速。
下面是一個典型的 CRC-32 查表法 C++ 實現:
static const unsigned int crc32_table[] = {0x00000000, 0x04c11db7, 0x09823b6e, 0x0d4326d9,0x130476dc, 0x17c56b6b, 0x1a864db2, 0x1e475005,0x2608edb8, 0x22c9f00f, 0x2f8ad6d6, 0x2b4bcb61,0x350c9b64, 0x31cd86d3, 0x3c8ea00a, 0x384fbdbd,0x4c11db70, 0x48d0c6c7, 0x4593e01e, 0x4152fda9,0x5f15adac, 0x5bd4b01b, 0x569796c2, 0x52568b75,0x6a1936c8, 0x6ed82b7f, 0x639b0da6, 0x675a1011,0x791d4014, 0x7ddc5da3, 0x709f7b7a, 0x745e66cd,0x9823b6e0, 0x9ce2ab57, 0x91a18d8e, 0x95609039,0x8b27c03c, 0x8fe6dd8b, 0x82a5fb52, 0x8664e6e5,0xbe2b5b58, 0xbaea46ef, 0xb7a96036, 0xb3687d81,0xad2f2d84, 0xa9ee3033, 0xa4ad16ea, 0xa06c0b5d,0xd4326d90, 0xd0f37027, 0xddb056fe, 0xd9714b49,0xc7361b4c, 0xc3f706fb, 0xceb42022, 0xca753d95,0xf23a8028, 0xf6fb9d9f, 0xfbb8bb46, 0xff79a6f1,0xe13ef6f4, 0xe5ffeb43, 0xe8bccd9a, 0xec7dd02d,0x34867077, 0x30476dc0, 0x3d044b19, 0x39c556ae,0x278206ab, 0x23431b1c, 0x2e003dc5, 0x2ac12072,0x128e9dcf, 0x164f8078, 0x1b0ca6a1, 0x1fcdbb16,0x018aeb13, 0x054bf6a4, 0x0808d07d, 0x0cc9cdca,0x7897ab07, 0x7c56b6b0, 0x71159069, 0x75d48dde,0x6b93dddb, 0x6f52c06c, 0x6211e6b5, 0x66d0fb02,0x5e9f46bf, 0x5a5e5b08, 0x571d7dd1, 0x53dc6066,0x4d9b3063, 0x495a2dd4, 0x44190b0d, 0x40d816ba,0xaca5c697, 0xa864db20, 0xa527fdf9, 0xa1e6e04e,0xbfa1b04b, 0xbb60adfc, 0xb6238b25, 0xb2e29692,0x8aad2b2f, 0x8e6c3698, 0x832f1041, 0x87ee0df6,0x99a95df3, 0x9d684044, 0x902b669d, 0x94ea7b2a,0xe0b41de7, 0xe4750050, 0xe9362689, 0xedf73b3e,0xf3b06b3b, 0xf771768c, 0xfa325055, 0xfef34de2,0xc6bcf05f, 0xc27dede8, 0xcf3ecb31, 0xcbffd686,0xd5b88683, 0xd1799b34, 0xdc3abded, 0xd8fba05a,0x690ce0ee, 0x6dcdfd59, 0x608edb80, 0x644fc637,0x7a089632, 0x7ec98b85, 0x738aad5c, 0x774bb0eb,0x4f040d56, 0x4bc510e1, 0x46863638, 0x42472b8f,0x5c007b8a, 0x58c1663d, 0x558240e4, 0x51435d53,0x251d3b9e, 0x21dc2629, 0x2c9f00f0, 0x285e1d47,0x36194d42, 0x32d850f5, 0x3f9b762c, 0x3b5a6b9b,0x0315d626, 0x07d4cb91, 0x0a97ed48, 0x0e56f0ff,0x1011a0fa, 0x14d0bd4d, 0x19939b94, 0x1d528623,0xf12f560e, 0xf5ee4bb9, 0xf8ad6d60, 0xfc6c70d7,0xe22b20d2, 0xe6ea3d65, 0xeba91bbc, 0xef68060b,0xd727bbb6, 0xd3e6a601, 0xdea580d8, 0xda649d6f,0xc423cd6a, 0xc0e2d0dd, 0xcda1f604, 0xc960ebb3,0xbd3e8d7e, 0xb9ff90c9, 0xb4bcb610, 0xb07daba7,0xae3afba2, 0xaafbe615, 0xa7b8c0cc, 0xa379dd7b,0x9b3660c6, 0x9ff77d71, 0x92b45ba8, 0x9675461f,0x8832161a, 0x8cf30bad, 0x81b02d74, 0x857130c3,0x5d8a9099, 0x594b8d2e, 0x5408abf7, 0x50c9b640,0x4e8ee645, 0x4a4ffbf2, 0x470cdd2b, 0x43cdc09c,0x7b827d21, 0x7f436096, 0x7200464f, 0x76c15bf8,0x68860bfd, 0x6c47164a, 0x61043093, 0x65c52d24,0x119b4be9, 0x155a565e, 0x18197087, 0x1cd86d30,0x029f3d35, 0x065e2082, 0x0b1d065b, 0x0fdc1bec,0x3793a651, 0x3352bbe6, 0x3e119d3f, 0x3ad08088,0x2497d08d, 0x2056cd3a, 0x2d15ebe3, 0x29d4f654,0xc5a92679, 0xc1683bce, 0xcc2b1d17, 0xc8ea00a0,0xd6ad50a5, 0xd26c4d12, 0xdf2f6bcb, 0xdbee767c,0xe3a1cbc1, 0xe760d676, 0xea23f0af, 0xeee2ed18,0xf0a5bd1d, 0xf464a0aa, 0xf9278673, 0xfde69bc4,0x89b8fd09, 0x8d79e0be, 0x803ac667, 0x84fbdbd0,0x9abc8bd5, 0x9e7d9662, 0x933eb0bb, 0x97ffad0c,0xafb010b1, 0xab710d06, 0xa6322bdf, 0xa2f33668,0xbcb4666d, 0xb8757bda, 0xb5365d03, 0xb1f740b4
};quint32 header_crc(const QByteArray& data) {quint32 crc = 0xFFFFFFFFu;const uchar* buf = reinterpret_cast<const uchar*>(data.constData());int len = data.size();for (int i = 0; i < len; ++i) {quint8 index = (crc ^ buf[i]) & 0xFFU;crc = (crc >> 8) ^ crc32_table[index];}return crc ^ 0xFFFFFFFFu;
}
5. 校驗示例
CRC-32 的標準測試字符串是 123456789
,計算結果應為:
0xCBF43926
你可以直接測試:
qDebug() << QString::number(header_crc("123456789"), 16); // 輸出 cbf43926
基于QDataStream的拆裝包
一、QDataStream 簡介:寫入與讀取原始二進制數據
QDataStream
可用于序列化(寫入)和反序列化(讀取)基礎類型(如quint32
,quint64
,quint8
等)以及 Qt 數據類型,且支持跨平臺字節序一致性處理- 寫 raw bytes 時可使用
writeRawData()
,讀時用readRawData()
- 使用
setByteOrder()
可以控制(默認網絡大端或小端),確保跨平臺通信一致性
二、封包(Pack):將協議頭打入 QByteArray
1. 使用 <<
運算符逐字段寫入
QByteArray buf;
QDataStream out(&buf, QIODevice::WriteOnly);
out.setVersion(QDataStream::Qt_6_0); // 保證版本一致
out.setByteOrder(QDataStream::BigEndian); // 指定字節序out << quint32(header.header_magic)<< quint16(header.protocol_version)<< quint8(header.current_state)<< quint64(header.fileId)<< quint64(header.offset)<< quint64(header.totalSize)<< quint32(header.nameLen)<< quint32(header.payloadSize);
// header_crc 最后寫,值之前自計算
out << quint32(header.header_crc);
優點是類型自動序列化,并支持 Qt 類型一致性處理。確保 setVersion()
和 setByteOrder()
在寫與讀端匹配
2. 使用 writeRawData()
整塊寫入(只建議在已處理對齊和 byte order 的情況下)
QByteArray buf(sizeof(DataHeader), Qt::Uninitialized);
memcpy(buf.data(), &header, sizeof(header));
// 然后 writeRawData(buf.data(), buf.size())
注意:此方式依賴結構體內存布局,可能受編譯器對齊、endianness 影響,不推薦用于跨平臺協議實現
三、拆包(Unpack):使用 QDataStream
從 QByteArray
或 QIODevice
讀取
1. 逐字段讀取
QDataStream in(&buf, QIODevice::ReadOnly);
in.setVersion(QDataStream::Qt_6_0);
in.setByteOrder(QDataStream::BigEndian);quint32 magic;
in >> magic;
if (magic != HEADER_MAGIC) { /* 錯誤處理 */ }quint16 version;
in >> version;
// 檢查版本兼容性quint8 state;
in >> state;in >> fileId >> offset >> totalSize>> nameLen >> payloadSize;quint32 headerCRC;
in >> headerCRC;
可結合 CRC 校驗機制對 header 或 header+payload 范圍進行校驗。
2. 使用事務機制,避免半包讀取失敗
若數據分片接收,可使用 startTransaction()
/ commitTransaction()
/ abortTransaction()
來確保完整讀取,否則回退狀態等候后續數據(doc.qt.io)。
四、完整示例:pack 和 unpack 實現偽代碼
QByteArray packUpHeader(const DataHeader& h) {QByteArray buf;QDataStream out(&buf, QIODevice::WriteOnly);out.setVersion(QDataStream::Qt_6_0);out.setByteOrder(QDataStream::BigEndian);out << quint32(HEADER_MAGIC)<< quint16(HEADER_VERSION)<< quint8(h.current_state)<< quint64(h.fileId)<< quint64(h.offset)<< quint64(h.totalSize)<< quint32(h.nameLen)<< quint32(h.payloadSize);quint32 crc = calculateCRC(buf); // 計算前面部分 CRCout << quint32(crc);return buf;
}bool readOutHeader(QDataStream& in, DataHeader& h) {in.setVersion(QDataStream::Qt_6_0);in.setByteOrder(QDataStream::BigEndian);in.startTransaction();in >> h.header_magic >> h.protocol_version >> h.current_state>> h.fileId >> h.offset >> h.totalSize>> h.nameLen >> h.payloadSize >> h.header_crc;if (!in.commitTransaction())return false;if (h.header_magic != HEADER_MAGIC) return false;// 可讀出 CRC 后并校驗return true;
}
五、關鍵注意點匯總
項目 | 說明 |
---|---|
setVersion() | 保證寫讀端的 QDataStream 版本一致 |
setByteOrder() | 明確字節序,跨平臺通信穩定 |
類型匹配 | 使用 Qt 類型(quint32 等)確保大小一致性 |
原始寫入問題 | writeRawData() 可能繞過 byte order 和版本處理 |
錯誤處理 | 使用事務避免半包讀取導致數據錯亂 |
CRC 校驗 | header CRC 建議覆蓋 header 前半部分或 header+payload |
- 使用 QDataStream+QByteArray 封裝協議頭結構時,推薦逐字段寫入與讀取方法。
- 必須指定 數據流版本 和 字節序,保證跨平臺兼容。
- 事務機制 可防止不完整數據引起的解析錯誤。
- CRC 校驗 應明確覆蓋范圍并在拆包時驗證。
- 避免直接使用結構體內存布局進行 raw memcpy,以免產生平臺差異問題。