傳輸協議是應用程式之間對話的語言，涉及傳輸協議，並沒有太多規範和要求，只要通信雙方的應用程式都能正確處理這個協議，沒有歧義就可以了。

數據“斷句”

在數據傳輸的過程中，我們需要處理“斷句”，無論我們定義什麼字元作為分隔符，它都有可能會在傳輸的數據中出現，為了區分“數據內的分隔符”和真正的分隔符，我們需要在發送數據階段，加上分隔符之前，把數據內的分隔符做轉義，收到數據之後再轉義回來。

在實際應用中，更加實用的方法是我們在每句話前面加一個標識這句話長度的數字，收到書時，我們按照長度進行讀取。

這種預置長度的方法很好的解決了“斷句”的問題，並且實現的過程也比分隔符簡單，性能也好。

單工和雙工通信

所謂單工通信，是指在任何一個時刻，數據只能單向傳輸。

HTTP 1協議就是單工協議，客戶端和服務端建立一個連接後，客戶端發送一個請求，直到服務端返迴響應或者請求超時，這段時間內，這個連接通道上是不能再發送其他請求的。這種單工通信的效率比較低，很多瀏覽器和App為瞭解決這個問題，只能同時在服務端和客戶端之間創建很多連接。

所謂雙工通信，是指我們可以同時進行數據的雙向收發，互相不會受到任何影響。

TCP連接是一個全雙工通道，為了提供吞吐量，應用層協議也必須支持雙工通信。

在雙工通信場景下，如何保證數據發送順序呢？或者說如何保證響應和請求的對應關係呢？我們可以在發送請求的時候，給每個請求加一個序號，這個序號在本地會話內保證唯一，然後在響應中帶上請求的序號，通過這種方式，我們可以建立響應和請求的對應關係。

解決斷句問題，實現雙工通信，配合專用的序列化方法，我們可以實現一套高性能的網路通信協議，實現高性能的進程間通信，很多消息隊列、RPC框架都是用這種方式來實現它們自己的私有應用層傳輸協議。