go tcp粘包 接受发送处理

浏览:728次阅读
没有评论

为什么会出现粘包

主要原因就是 tcp 数据传递模式是流模式,在保持长连接的时候可以进行多次的收和发。

“粘包”可发生在发送端也可发生在接收端:

  1. 由 Nagle 算法造成的发送端的粘包:Nagle 算法是一种改善网络传输效率的算法。简单来说就是当我们提交一段数据给 TCP 发送时,TCP 并不立刻发送此段数据,而是等待一小段时间看看在等待期间是否还有要发送的数据,若有则会一次把这两段数据发送出去。

  2. 接收端接收不及时造成的接收端粘包:TCP 会把接收到的数据存在自己的缓冲区中,然后通知应用层取数据。当应用层由于某些原因不能及时的把 TCP 的数据取出来,就会造成 TCP 缓冲区中存放了几段数据。

解决办法

出现”粘包”的关键在于接收方不确定将要传输的数据包的大小,因此我们可以对数据包进行封包和拆包的操作。

封包:封包就是给一段数据加上包头,这样一来数据包就分为包头和包体两部分内容了 (过滤非法包时封包会加入”包尾”内容)。包头部分的长度是固定的,并且它存储了包体的长度,根据包头长度固定以及包头中含有包体长度的变量就能正确的拆分出一个完整的数据包。

我们可以自己定义一个协议,比如数据包的前 4 个字节为包头,里面存储的是发送的数据的长度。

// socket_stick/proto/proto.go
package proto

import (
    "bufio"
    "bytes"
    "encoding/binary"
)

// Encode 将消息编码
func Encode(message string) ([]byte, error) {
    // 读取消息的长度,转换成 int32 类型(占 4 个字节)var length = int32(len(message))
    var pkg = new(bytes.Buffer)
    // 写入消息头
    err := binary.Write(pkg, binary.LittleEndian, length)
    if err != nil {return nil, err}
    // 写入消息实体
    err = binary.Write(pkg, binary.LittleEndian, []byte(message))
    if err != nil {return nil, err}
    return pkg.Bytes(), nil}

// Decode 解码消息
func Decode(reader *bufio.Reader) (string, error) {
    // 读取消息的长度
    lengthByte, _ := reader.Peek(4) // 读取前 4 个字节的数据
    lengthBuff := bytes.NewBuffer(lengthByte)
    var length int32
    err := binary.Read(lengthBuff, binary.LittleEndian, &length)
    if err != nil {return "", err}
    // Buffered 返回缓冲中现有的可读取的字节数。if int32(reader.Buffered()) < length+4 {return "", err}

    // 读取真正的消息数据
    pack := make([]byte, int(4+length))
    _, err = reader.Read(pack)
    if err != nil {return "", err}
    return string(pack[4:]), nil
}

以上文章转载自:Go-TCP 粘包

在 PHP 中应用

function encode($msg){return pack("L",strlen($msg)).$msg;
}

开始我也想按照 PHP 的写法来仿写

// 此示范未完成是错误的
func encode(msg string) ([]byte,error){byt := []byte(msg)
    length := len(msg)
    //>> 此处不知道怎么把 length 搞到 byte 里面去 可能还没学到这里
    return byt,nil// 此处我不会 哈哈哈
}

由此可见 PHP 是世界上最好的语言 哈哈哈哈

注: 本流程对接 HPsocket 组件进行通讯

正文完
 
包子
版权声明:本站原创文章,由 包子 2021-10-11发表,共计1614字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
评论(没有评论)