GCDAsyncSocket 如何順序發送？ ？ ？例如先發送，文件名，再發長度，再發送文件，還必須要在文件名發送完了之後發送下一個
学习是最好的投资！
簡單的講，TCP連接在網路傳輸時是無序（主要是為了優化資料傳輸）的，但是TCP有對應的「排序」處理，所以對於同一個連接（例如客戶端A與服務端S之間的這條連接），TCP Socket底層已經實現了順序，你按照a、b、c的順序發，接收方就會依序收到a、b、c。這也是TCP相對UDP的優勢。
所以你的問題應該不是GCDAsyncSocket的問題。
Socket只管收發數據，沒有具體的業務邏輯，所以對於socket應用一般都有自己的數據格式，比如把各個參數用分隔符拼接起來（例如：文件名|文件），或者使用通用的格式xml或json等方便解析（ {"filename": "", "data": ""} ）。同時因為MTU 的限制，所以一條完整的業務資料可能在發送時會被拆包發送，又因為網路原因可能出現丟包，所以在自訂的資料格式中會加入「socket資料長度」的參數，類似HTTP POST 的Content-Length，長度一般會加在一條資料的最開始部分，用來標記後面整條socket資料的長度。 「長度」參數不參與資料格式，雙方約定的一定子節長度來表示這個「socket資料長度」參數。接收方處理資料時，先解析前幾位的“長度”，然後根據這個長度來確定後面的完整資料。
Socket開發中遇到問題如果不能明顯的確定原因，建議先抓包分析，先看看資料是怎麼傳輸的，排查掉網路故障，再確定是發送方問題還是接收方問題。如果收發方都沒問題，業務代碼也沒問題，最後再考慮查「網路代理」的原因，例如路由器、電信商等等，在天朝網路中間層也很容易出問題。
簡單的講，TCP連接在網路傳輸時是無序（主要是為了優化資料傳輸）的，但是TCP有對應的「排序」處理，所以對於同一個連接（例如客戶端A與服務端S之間的這條連接），TCP Socket底層已經實現了順序，你按照a、b、c的順序發，接收方就會依序收到a、b、c。這也是TCP相對UDP的優勢。
所以你的問題應該不是GCDAsyncSocket的問題。
Socket只管收發數據，沒有具體的業務邏輯，所以對於socket應用一般都有自己的數據格式，比如把各個參數用分隔符拼接起來（例如：文件名|文件），或者使用通用的格式xml或json等方便解析（ {"filename": "", "data": ""} ）。同時因為MTU 的限制，所以一條完整的業務資料可能在發送時會被拆包發送，又因為網路原因可能出現丟包，所以在自訂的資料格式中會加入「socket資料長度」的參數，類似HTTP POST 的Content-Length，長度一般會加在一條資料的最開始部分，用來標記後面整條socket資料的長度。 「長度」參數不參與資料格式，雙方約定的一定子節長度來表示這個「socket資料長度」參數。接收方處理資料時，先解析前幾位的“長度”，然後根據這個長度來確定後面的完整資料。
Socket開發中遇到問題如果不能明顯的確定原因，建議先抓包分析，先看看資料是怎麼傳輸的，排查掉網路故障，再確定是發送方問題還是接收方問題。如果收發方都沒問題，業務代碼也沒問題，最後再考慮查「網路代理」的原因，例如路由器、電信商等等，在天朝網路中間層也很容易出問題。