2. 程式人生 > >golang中tcp socket粘包問題和處理

golang中tcp socket粘包問題和處理

阿新 • • 發佈：2017-07-30
enc pack 獲取 人工 過程 reader 主動 exit ase

轉自：http://www.01happy.com/golang-tcp-socket-adhere/

在用golang開發人工客服系統的時候碰到了粘包問題，那麽什麽是粘包呢？例如我們和客戶端約定數據交互格式是一個json格式的字符串：

{"Id":1,"Name":"golang","Message":"message"}

當客戶端發送數據給服務端的時候，如果服務端沒有及時接收，客戶端又發送了一條數據上來，這時候服務端才進行接收的話就會收到兩個連續的字符串，形如：

{"Id":1,"Name":"golang","Message":"message"}{"Id":1,"Name":"golang","Message":"message"}

如果接收緩沖區滿了的話，那麽也有可能接收到半截的json字符串，醬紫的話還怎麽用json解碼呢？真是頭疼。以下用golang模擬了下這個粘包的產生。

備註：下面貼的代碼均可以運行於golang 1.3.1，如果發現有問題可以聯系我

粘包示例：

server.go

//粘包問題演示服務端
package main
 
import (
    "fmt"
    "net"
    "os"
)
 
func main() {
    netListen, err := net.Listen("tcp", ":9988")
    CheckError(err)
 
    defer netListen.Close()
 
    Log("Waiting for clients")
    for {
        conn, err := netListen.Accept()
        if err != nil {
            continue
        }
 
        Log(conn.RemoteAddr().String(), " tcp connect success")
        go handleConnection(conn)
    }
}
 
func handleConnection(conn net.Conn) {
    buffer := make([]byte, 1024)
    for {
        n, err := conn.Read(buffer)
        if err != nil {
            Log(conn.RemoteAddr().String(), " connection error: ", err)
            return
        }
        Log(conn.RemoteAddr().String(), "receive data length:", n)
        Log(conn.RemoteAddr().String(), "receive data:", buffer[:n])
        Log(conn.RemoteAddr().String(), "receive data string:", string(buffer[:n]))
    }
}
 
func Log(v ...interface{}) {
    fmt.Println(v...)
}
 
func CheckError(err error) {
    if err != nil {
        fmt.Fprintf(os.Stderr, "Fatal error: %s", err.Error())
        os.Exit(1)
    }
}

　　client.go

//粘包問題演示客戶端
package main
 
import (
    "fmt"
    "net"
    "os"
    "time"
)
 
func sender(conn net.Conn) {
    for i := 0; i < 100; i++ {
        words := "{\"Id\":1,\"Name\":\"golang\",\"Message\":\"message\"}"
        conn.Write([]byte(words))
    }
}
 
func main() {
    server := "127.0.0.1:9988"
    tcpAddr, err := net.ResolveTCPAddr("tcp4", server)
    if err != nil {
        fmt.Fprintf(os.Stderr, "Fatal error: %s", err.Error())
        os.Exit(1)
    }
 
    conn, err := net.DialTCP("tcp", nil, tcpAddr)
    if err != nil {
        fmt.Fprintf(os.Stderr, "Fatal error: %s", err.Error())
        os.Exit(1)
    }
 
    defer conn.Close()
 
    fmt.Println("connect success")
 
    go sender(conn)
 
    for {
        time.Sleep(1 * 1e9)
    }
}

　　運行後查看服務端輸出：

技術分享

可以看到json格式的字符串都粘到一起了，有種淡淡的憂傷了——頭疼的事情又來了。

粘包產生原因

關於粘包的產生原因網上有很多相關的說明，主要原因就是tcp數據傳遞模式是流模式，在保持長連接的時候可以進行多次的收和發。如果要深入了解可以看看tcp協議方面的內容。這裏推薦下鳥哥的私房菜，講的非常通俗易懂。

粘包解決辦法

主要有兩種方法：

1、客戶端發送一次就斷開連接，需要發送數據的時候再次連接，典型如http。下面用golang演示一下這個過程，確實不會出現粘包問題。

//客戶端代碼，演示了發送一次數據就斷開連接的
package main
 
import (
    "fmt"
    "net"
    "os"
    "time"
)
 
func main() {
    server := "127.0.0.1:9988"
 
    for i := 0; i < 10000; i++ {
        tcpAddr, err := net.ResolveTCPAddr("tcp4", server)
        if err != nil {
            fmt.Fprintf(os.Stderr, "Fatal error: %s", err.Error())
            os.Exit(1)
        }
 
        conn, err := net.DialTCP("tcp", nil, tcpAddr)
        if err != nil {
            fmt.Fprintf(os.Stderr, "Fatal error: %s", err.Error())
            os.Exit(1)
        }
 
        words := "{\"Id\":1,\"Name\":\"golang\",\"Message\":\"message\"}"
        conn.Write([]byte(words))
 
        conn.Close()
    }
 
    for {
        time.Sleep(1 * 1e9)
    }
}

　　

服務端代碼參考上面演示粘包產生過程的服務端代碼

2、包頭+數據的格式，根據包頭信息讀取到需要分析的數據。形式如下圖：

技術分享

golang粘包問題包頭定義

從數據流中讀取數據的時候，只要根據包頭和數據長度就能取到需要的數據。這個其實就是平時說的協議（protocol），只是這個數據傳輸協議非常簡單，不像tcp、ip等協議有較多的定義。在實際的過程中通常會定義協議類或者協議文件來封裝封包和解包的過程。下面代碼演示了封包和解包的過程：

protocol.go

//通訊協議處理，主要處理封包和解包的過程
package protocol
 
import (
    "bytes"
    "encoding/binary"
)
 
const (
    ConstHeader         = "www.01happy.com"
    ConstHeaderLength   = 15
    ConstSaveDataLength = 4
)
 
//封包
func Packet(message []byte) []byte {
    return append(append([]byte(ConstHeader), IntToBytes(len(message))...), message...)
}
 
//解包
func Unpack(buffer []byte, readerChannel chan []byte) []byte {
    length := len(buffer)
 
    var i int
    for i = 0; i < length; i = i + 1 {
        if length < i+ConstHeaderLength+ConstSaveDataLength {
            break
        }
        if string(buffer[i:i+ConstHeaderLength]) == ConstHeader {
            messageLength := BytesToInt(buffer[i+ConstHeaderLength : i+ConstHeaderLength+ConstSaveDataLength])
            if length < i+ConstHeaderLength+ConstSaveDataLength+messageLength {
                break
            }
            data := buffer[i+ConstHeaderLength+ConstSaveDataLength : i+ConstHeaderLength+ConstSaveDataLength+messageLength]
            readerChannel <- data
 
            i += ConstHeaderLength + ConstSaveDataLength + messageLength - 1
        }
    }
 
    if i == length {
        return make([]byte, 0)
    }
    return buffer[i:]
}
 
//整形轉換成字節
func IntToBytes(n int) []byte {
    x := int32(n)
 
    bytesBuffer := bytes.NewBuffer([]byte{})
    binary.Write(bytesBuffer, binary.BigEndian, x)
    return bytesBuffer.Bytes()
}
 
//字節轉換成整形
func BytesToInt(b []byte) int {
    bytesBuffer := bytes.NewBuffer(b)
 
    var x int32
    binary.Read(bytesBuffer, binary.BigEndian, &x)
 
    return int(x)
}

　　tips：解包的過程中要註意數組越界的問題；另外包頭要註意唯一性

server.go

//服務端解包過程
package main
 
import (
    "./protocol"
    "fmt"
    "net"
    "os"
)
 
func main() {
    netListen, err := net.Listen("tcp", ":9988")
    CheckError(err)
 
    defer netListen.Close()
 
    Log("Waiting for clients")
    for {
        conn, err := netListen.Accept()
        if err != nil {
            continue
        }
 
        Log(conn.RemoteAddr().String(), " tcp connect success")
        go handleConnection(conn)
    }
}
 
func handleConnection(conn net.Conn) {
    //聲明一個臨時緩沖區，用來存儲被截斷的數據
    tmpBuffer := make([]byte, 0)
 
    //聲明一個管道用於接收解包的數據
    readerChannel := make(chan []byte, 16)
    go reader(readerChannel)
 
    buffer := make([]byte, 1024)
    for {
        n, err := conn.Read(buffer)
        if err != nil {
            Log(conn.RemoteAddr().String(), " connection error: ", err)
            return
        }
 
        tmpBuffer = protocol.Unpack(append(tmpBuffer, buffer[:n]...), readerChannel)
    }
}
 
func reader(readerChannel chan []byte) {
    for {
        select {
        case data := <-readerChannel:
            Log(string(data))
        }
    }
}
 
func Log(v ...interface{}) {
    fmt.Println(v...)
}
 
func CheckError(err error) {
    if err != nil {
        fmt.Fprintf(os.Stderr, "Fatal error: %s", err.Error())
        os.Exit(1)
    }
}

　　client.go

//客戶端發送封包
package main
 
import (
    "./protocol"
    "fmt"
    "net"
    "os"
    "time"
)
 
func sender(conn net.Conn) {
    for i := 0; i < 1000; i++ {
        words := "{\"Id\":1,\"Name\":\"golang\",\"Message\":\"message\"}"
        conn.Write(protocol.Packet([]byte(words)))
    }
    fmt.Println("send over")
}
 
func main() {
    server := "127.0.0.1:9988"
    tcpAddr, err := net.ResolveTCPAddr("tcp4", server)
    if err != nil {
        fmt.Fprintf(os.Stderr, "Fatal error: %s", err.Error())
        os.Exit(1)
    }
 
    conn, err := net.DialTCP("tcp", nil, tcpAddr)
    if err != nil {
        fmt.Fprintf(os.Stderr, "Fatal error: %s", err.Error())
        os.Exit(1)
    }
 
    defer conn.Close()
    fmt.Println("connect success")
    go sender(conn)
    for {
        time.Sleep(1 * 1e9)
    }
}

　　運行這個程序可以看到服務端很好的獲取到期望的json格式數據。完整代碼演示下載：

最後

上面演示的兩種方法適用於不同的場景。第一種方法比較適合被動型的場景，例如打開網頁，用戶有請求才處理交互。第二種方法適合於主動推送的類型，例如即時聊天系統，因為要即時給用戶推送消息，保持長連接是不可避免的，這時候就要用這種方法。

golang中tcp socket粘包問題和處理

相關推薦

golang中tcp socket粘包問題和處理

enc pack 獲取 人工 過程 reader 主動 exit ase 轉自：http://www.01happy.com/golang-tcp-socket-adhere/ 在用golang開發人工客服系統的時候碰到了粘包問題，那麽什麽是粘包呢？例如我們和客戶端約定數據

TCP UDP粘包和程序部分

TCP 半連線池原理 #客戶端 import socket client = socket.socket(socket.AF_INET,socket.SOCK_STREAM) client.connect(("127.0.0.1",9999)) while

Socket 粘包和分包問題

概念 Socket通訊時會對傳送的位元組資料進行分包和粘包處理，屬於一種Socket內部的優化機制。 粘包： 當傳送的位元組資料包比較小且頻繁傳送時，Socket內部會將位元組資料進行粘包處理，既將頻繁傳送的小位元組資料打包成 一個整包進行傳送，降低記憶體的消

【Python】TCP Socket的粘包和分包的處理

概述 在進行TCP Socket開發時，都需要處理資料包粘包和分包的情況。本文詳細講解解決該問題的步驟。使用的語言是Python。實際上解決該問題很簡單，在應用層下，定義一個協議：訊息頭部+訊息長度+訊息正文即可。 那什麼是粘包和分包呢？ 關於分包和粘

Netty中處理TCP粘包和拆包

什麼是粘包和拆包 TCP是個”流”協議，流其實就是沒有界限的一串資料。 TCP底層中並不瞭解上層業務資料的具體含義，它會根據TCP緩衝區的實際情況進行包劃分，所以在TCP中就有可能一個完整地包會被TCP拆分成多個包，也有可能吧多個小的包封裝成一個大的資料包傳

socket編程 粘包和半包 問題的及處理

當前 多少 分包 轉義 保存 長連接 完整 過去 高效 一般在socket處理大數據量傳輸的時候會產生粘包和半包問題，有的時候tcp為了提高效率會緩沖N個包後再一起發出去，這個與緩存和網絡有關系。 粘包 為x.5個包 半包 為0.5個包 由於網絡原因 一次可能會來 0.5/

tcp粘包和拆包的處理方案

隨著智慧硬體越來越流行，很多後端開發人員都有可能接觸到socket程式設計。而很多情況下，伺服器與端上需要保證資料的有序，穩定到達，自然而然就會選擇基於tcp/ip協議的socekt開發。開發過程中，經常會遇到tcp粘包，拆包的問題，本文將從產生原因，和解決方案以及work

關於TCP粘包和半包的處理

今日，在程式設計過程中需要在區域網內不同的電腦間傳輸檔案，遇到了TCP協議的粘包和半包現象。經過思考和借鑑，找到了一個比較好的解決方法。因為在傳輸檔案時要先傳輸檔名和檔案大小，然後再傳輸檔案，所以電腦間的應用程式實現了一個小的協議。這個協議需要解碼TCP傳輸的內容。在有粘包

Linux下的socket程式設計實踐（四）TCP的粘包問題和常用解決方案

TCP粘包問題的產生 由於TCP協議是基於位元組流並且無邊界的傳輸協議, 因此很有可能產生粘包問題。此外，傳送方引起的粘包是由TCP協議本身造成的，TCP為提高傳輸效率，傳送方往往要收集到足夠多的資料

Unity3D筆記——Socket粘包分包的理解和最簡單的處理方式

前言：Unity3D筆記是我平時做一些好玩的測試和研究，記錄的筆記。會比較詳細也可能隨口一提就過了。 所以大家見諒了，內容一般都會是原創的（非原創我會註明轉載）。由於很多內容其他的朋友也肯定研究發表過，大家請指出錯誤。 之前做的答題遊戲，在向伺服器申請題目列表時遇到

Unity Socket傳輸 TCP粘包和拆包原因以及解決策略

3. 乙太網的payload大於MTU進行IP分片。MTU指：一種通訊協議的某一層上面所能通過的最大資料包大小。如果IP層有一個數據包要傳，而且資料的長度比鏈路層的MTU大，那麼IP層就會進行分片，把資料包分成若干片，讓每一片都不超過MTU。注意，IP分片可以發生在原始傳送端主機上，也可以發生在中間路由器上

處理粘包和半包有關問題的socket分包Java實現

- 處理粘包和半包問題的socket分包Java實現 只知道原理，程式碼實現還不知道怎麼實現？請高手指點，謝謝！高分饋贈!------解決方案-------------------- 一般在socket處理大資料量傳輸的時候會產生粘包和半包問題，有的時候tcp為了提高效

socket傳輸過程中產生的粘包拆包問題

這篇部落格中就出現了socket傳輸過程中的粘包拆包問題。就是因為socket傳送的是無界線的資料流。所以當多個包的大小不一，並且傳送出去的時候，緩衝區的大小不一樣，會導致包與包之間和合並和包的拆分問題。 對於上圖粘包、拆包問題的場景： 客戶端和伺服器建立一個

TCP通訊粘包問題分析和解決（全）

在socket網路程式中，TCP和UDP分別是面向連線和非面向連線的。因此TCP的socket程式設計，收發兩端（客戶端和伺服器端）都要有成對的socket，因此，傳送端為了將多個發往接收端的包，更有效的發到對方，使用了優化方法（Nagle演算法），將多次間隔較小、資料量小的

基於tcp的粘包處理終極版本

為什麼會存在粘包問題? 因為tcp是流失協議 因為接收方不知道傳送方的的資料總量和資料劃分的界限, 解決的思路: 接收方需要先獲取資料的長度 需要傳送方先發送資料的長度給接收方 接收方收到長度之後 按照資料長度來獲取資料 struct 模組  可以將python中的資料型別 轉換成by

Tcp粘包和拆包的原因

最近研究Netty網路程式設計，以前專案中也遇到過資料接收過程中資料質量太差問題，很可能是TCP傳輸過程中問題，特此記錄。 問題產生 一個完整的業務可能會被TCP拆分成多個包進行傳送，也有可能把多個小的包封裝成一個大的資料包傳送，這個就是TCP的拆包和封包問

tcp粘包和拆包、斷包

    while (1) {       var packLen = _.unpack('packLen', tcpBuffer.slice(0, 2));       len = packLen.len;       // console.log('pack len------:' + len);    

TCP通訊粘包問題分析和解決

什麼時候需要考慮粘包問題?1.如果利用tcp每次傳送資料，就與對方建立連線，然後雙方傳送完一段資料後，就關閉連線，這樣就不會出現粘包問題（因為只有一種包結構,類似於http協議）。關閉連線主要是要雙方都發送close連線（參考tcp關閉協議）。如：A需要傳送一段字串給B，那麼

CocoaAsyncSocket + Protobuf 處理粘包和拆包問題

 在上一篇文章《iOS之ProtocolBuffer搭建和示例demo》分享環境的搭建, 我們和伺服器進行IM通訊用了github有名的框架CocoaAsynSocket, 然後和伺服器之間的資料媒介是ProtoBuf。然後後面在開發的過程中也碰到了拆包和粘包問題，這方面

我所經歷過的tcp“粘包”及其處理

         剛畢業參加工作的時候， 我對計算機網路和網路程式設計一無所知。 當時要負責一個客戶端介面軟體的維護和開發， 而另一個“同事”要離職， 哎， 扯遠了。          我當時在程式碼中讀到一個註釋， 其中有“粘包”二字， 當時比較納悶： 不都說tcp是好東