前言

上一篇我們透過 AI 輔助得到簡單的 PRD 跟技術規格，今天就能更深入認識我們的待測系統了，首先從傳輸規格開始，這裡最少包含兩個資料結構:封包的打包與拆解、事件訊息的定義跟入參出參

TCP/IP 的封包格式

在開始談封包格式前，容我借鑑網路最有名的 TCP/IP 來解釋這個概念

開始之前舉個例子，想像你是蝦皮倉庫的作業員，一邊是來自各供應商或者自營商大大小小的貨物，一邊是一些特定尺寸的紙箱，你要怎麼打包，怎麼紀錄內容物?
另外一邊，當顧客收到貨物時怎麼確認包裹沒有破損缺件?
應對的做法包含但不限於:

1. 把原始商品的長寬高跟重量建檔
2. 把可用的紙箱長寬高跟最大承重建檔
3. 透過演算法把訂單跟一箱能塞進去的商品做運算，評估尺寸跟重量後，決定要分成幾箱打包
4. 生成打包清單，由電子或者人工一一揀選到箱子中，並把打包清單一併放入，封箱
5. 經過檢查站查核無誤之後，進入配送流程

透過上述例子，大家會對封包有更具體的概念，網路跟運輸不是把東西丟進去就算了，為了確保最佳效率跟破損偵測等需求，需要額外做很多事，主題拉回來，我們看看 TCP/IP 是怎麼做的
乾貨先來，打包的流程大概是這樣

純資料訊息得經過層層包裝，加上來源目的 Port, IP 等資料以便後面的網路資訊系統處理

深入看一下 TCP 檔頭的部分

眼尖的你可以觀察到以下資訊:

• 來源跟目標 Port: 跟我們寄信一樣要指定從哪裡來到哪裡去
• 流水號: 幫封包排序用
• 資料偏移: 告訴接收方哪邊開始是真的資料
• 檢查碼: 用來核對資料是否有錯亂或者被篡改
• 資料: 最後才是真的資料
  有沒有覺得跟上面的蝦皮倉庫範例似曾相似?
  有興趣可以延伸去搜尋 TCP/IP Header，就引用到這

我們的封包格式

講完 TCP/IP 的做法，回到我們的實作，因為簡單展示目的，我們的封包檔頭就只有兩個欄位: 命令代號跟資料長度
目標是知道處理的對象是什麼，以及期望長度有多少，以免發生斷包或者黏包的狀況，而把資料亂接亂用

備註:

• 斷包: 應該收到 100 bytes，但是因為網路分發的關係，這 socket 包只有前半部，就是斷包，上層要能偵測並等待完整封包到來
• 黏包: 資料長度說是 32 bytes，結果收到總資料有 200 bytes，那表示這 socket 包不只含有一個我們定義的封包，要當做一串鞭炮來看待，一節讀完再繼續讀下一節

┌──────────────┬──────────────┬─────────────────────┐
│  Command ID  │    Length    │       Payload       │
│   (4 bytes)  │   (4 bytes)  │    (Length bytes)   │
│    uint32    │    uint32    │    ProtoBuf Data    │
└──────────────┴──────────────┴─────────────────────┘

小結

這邊趁解釋封包打包拆解過程，順便科普一下 TCP/IP 檔頭的原理跟成因，藉由成熟的 TCP/IP 再回頭看我們的極簡設計，讓大部分比較少接觸網路底層的讀者可以對網路世界應用有更立體的理解
下一篇會一一解釋我們簡單的丟骰子待測系統中用到定義出來的這些訊息跟參數
熬過的前面的科普，後面會越來越接近實際實作，也越來越有趣，敬請期待