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

資料“斷句”

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

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

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

單工和雙工通信

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

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

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

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

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

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

　　　　作者：李潘　　　　出處：http://wing011203.cnblogs.com/ 　　　　本文著作權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利，

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/546745.html