HTTP 報文深度解析：二進制資料傳輸格式與協定版本協商機制

問題一：如何在 HTTP 中傳送二進制資料？

HTTP 協定本質上是基於文字的協定，但透過 Content-Type 與 Content-Transfer-Encoding 標頭，可完整支援二進制資料傳輸。

標準作法：Multipart/Form-Data

適用於檔案上傳（表單含檔案欄位）：

POST /upload HTTP/1.1
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="file"; name="image.png"
Content-Type: image/png

[二進制檔案內容...]
------WebKitFormBoundary7MA4YWxkTrZu0gW--

純二進制串流：Application/Octet-Stream

適用於 API 直接傳送檔案串流：

POST /api/data HTTP/1.1
Content-Type: application/octet-stream
Content-Length: 1024

[原始二進制位元組...]

接收端解析關鍵

• 讀取 Content-Type 判斷編碼方式。
• 依據 Content-Length 或 Transfer-Encoding: chunked 讀取 Body 長度。
• 使用對應解析器（如 MultipartParser、Buffer 直接寫入檔案）。

問題二：請求與回應的 HTTP 版本號必須一致嗎？

不必強制一致。 HTTP 協定設計為向下相容。

版本協商機制

版本差異的實際影響

• HTTP/1.0：預設短連線，無 Host 標頭（虛擬主機不支援），無 Chunked 編碼。
• HTTP/1.1：預設長連線、Host 標頭必填、Chunked 傳輸、管線化、快取控制增強。
• HTTP/2：二進制幀、多工、標頭壓縮、Server Push。

只要雙方遵守各自版本的 RFC 規範，版本號不一致不會導致通訊失敗，只會限制可用功能集合。

參考資源

詳細報文格式規範請參考：HTTP 協定詳細解析