相关参考添加链接描述 相关参考

什么是tcp

TCP,全称Transmission Control Protocol，是一种传输控制协议，TCP协议也是计算机网络中非常复杂的一个协议

tcp的特点

• tcp是面向连接的协议
• tcp是端到端的链接
• tcp提供可靠的传输服务
• tcp协议提供双工通信
• tcp是面向字节流的协议

tcp粘包

tcp有这么多的特点，但是为什么还会出现粘包呢？其实这是对tcp传输的一种优化而引起的一些问题。

• 为什么要优化？ 我们前面说了， tcp是面向字节流的协议，而不是消息包的协议，为什么是面向字节流？因为一个tcp连接，它负责传输数据，但是这些数据的大小是未知的，可能很大，也可能很小，而且是没有边界的，它只会将你的数据编程字节流发到对面去，而且保证顺序不会乱，而对于字节流的解析，就需要我们自己来搞定了，那数据怎么传输呢？方法来了，不管你是什么数据，我都给你转换成二进制。然后由tcp切割为tcp认为合适的长度。

• 那么这个长度怎么确定？ tcp协议简介有兴趣的同学可以看一下阮一峰的文章。 我们知道，从应用层到物理层，数据都是一层一层经过打包过的，我们可能一下子没法知道tcp最大传输多少，但是我们可以反推一下，以太网数据包（packet）的大小是固定的，最初是1518字节，后来增加到1522字节。其中， 1500 字节是负载（payload），22字节是头信息（head）。IP 数据包在以太网数据包的负载里面，它也有自己的头信息，最少需要20字节，所以 IP 数据包的负载最多为1480字节。TCP 数据包在 IP 数据包的负载里面。它的头信息最少也需要20字节，因此 TCP 数据包的最大负载是 1480 - 20 = 1460 字节。由于 IP 和 TCP 协议往往有额外的头信息，所以 TCP 负载实际为1400字节左右。

• 这里插播一个http2的一个改进 相关参考 在 HTTP/1 中，HTTP 请求和响应都是由「状态行、请求 / 响应头部、消息主体」三部分组成。一般而言，消息主体都会经过 gzip 压缩，或者本身传输的就是压缩过后的二进制文件（例如图片、音频），但状态行和头部却没有经过任何压缩，直接以纯文本传输。而http2里面的一个重大改进，就是压缩http的协议的头信息，怎么实现的头部压缩呢？主要是基于以下几点：

• 维护一份相同的静态字典（Static Table），包含常见的头部名称，以及特别常见的头部名称与值的组合；

• 维护一份相同的动态字典（Dynamic Table），可以动态地添加内容；

• 支持基于静态哈夫曼码表的哈夫曼编码（Huffman Coding）

• 好了，我们前面说了，一个tcp包负载是1400字节左右，那么你发送2000个字节，就需要发送两个数据包，第二个数据包可能就是600个字节。那么问题来了，明明一次可以发送1400字节，但是实际只发送600个字节，是不是有点浪费网络之间的IO,怎么办？John Nagle（约翰.纳格） 提出了一种简单有效的解决方法。也就是Nagle 算法。相关参考

• Nagle 算法 Nagle 算法的基本定义是任一时刻，最多只能有一个未被确认的小段。所谓“小段”，指的是长度小于 MSS 尺寸的数据块，而未被确认则是指没有收到对方的 ACK 数据包。Nagle 算法的规则（参考 tcp_output.c 文件里 tcp_nagle_check 函数注释）： 如果包长度达到 MSS，则允许发送； 如果该数据包含有 FIN，则允许发送； 设置了 TCP_NODELAY 选项，则允许发送； 未设置 TCP_CORK 选项时，若所有发出去的小数据包（包长度小于 MSS）均被确认，则允许发送； 上述条件都未满足，但发送了超时（一般为 200 ms），则立即发送。 该算法的精妙之处在于它实现了自时钟（self-clocking）控制：ACK 返回得快，数据传输也越快。在相对高延迟的广域网中，更需要减少微型报的数目，该算法使得单位时间内发送的报文段数据更少。也就是说，RTT 控制着发包速率。

• 简单理解 就是如果你普通的数据流，小于传输的负载量，我就不传输，等到下次有数据满足了我的负载量我再传输，但是我也不能一直等，如果时间超过200ms都么有数据流过来，那我就传输。

tcp粘包的演示

服务端

package main

import (
 "bufio"
 "fmt"
 "io"
 "net"
)

func main() {
 network:="tcp"
 address:="127.0.0.1:30000"
 //绑定和监听tpc和端口
 listen, err := net.Listen(network, address)
 if err != nil {
  fmt.Println("listen err")
 }
 //关闭监听
 defer listen.Close()
 for{
  //等待连接
  conn,err:=listen.Accept()
  if err != nil {
   fmt.Println("accept error")
  }
  //从连接里面读取数据
  go process(conn)
 }
}

func process(conn net.Conn){
 defer conn.Close()//关闭连接
 //读取连接数据
 reader:=bufio.NewReader(conn)
 //定义每次接收的长度
 buf:=make([]byte, 7)
 for  {
  //用buf接收连接发送的内容
  read, err := reader.Read(buf)
  //读完了
  if err == io.EOF {
   break
  }
  if err != nil {
   fmt.Println("read conn err")
  }
  fmt.Printf("the msg i read length is %d \n",read)
  str:=string(buf[:read])
  fmt.Println(str)
 }
}

客户端代码

package main

import (
 "fmt"
 "net"
)

func main() {
 network:="tcp"
 address:="127.0.0.1:30000"
 //拨号 请求创建tcp连接
 conn, err := net.Dial(network,address )
 if err != nil {
  fmt.Println("connect err")
 }
 //关闭连接
 defer conn.Close()
 //想tcp写入数据
 conn.Write([]byte("123456789"))
}

• 我们先后发送123，1234567，123456789和123，456并打印出来看看，我们来看截图里面的内容，发现出现了问题，这就是粘包造成的问题，可能会把你的消息分段发送，也可能会把多段消息合并 。

tcp粘包的解决

• tcp是只负责按顺序传输数据，并没有边界的概念，那么我们如果想要确定消息边界，就得发送一种信号，或者说一种约定，当接收者接到这种信号，就能知道是消息的开始还是结尾，比如我们的http请求有一个content-length 那么我们约定消息边界一般有三种模式
• 定长消息：协议提前约定好包的长度为多少，每当接收端接收到固定长度的字节就确定一个包，就像咱们上面截图的那个
• 消息分隔符：利用特殊符号标志着消息的开始或者结束，例如 HTTP 协议中的换行符；
• 长度前缀：先发送N个字节代表包的大小（注意大端和小端问题），后续解析也按长度读取解析。

粘包解决方案相关参考

• 这里我们使用第三种来实现，即给消息体添加一个长度前缀。
• 我们先来写一个文件，基于长度前缀来编码和解码消息

package tcp_code

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

// Encode 将消息编码后返回byte类型
func Encode(msg string)([]byte,error){
 //1.读取消息的长度,用int32存放消息长度,这个长度大概能支持4G的数据传输,如果用int64就代表16777216T
 length:=int32(len(msg))
 //定义一个Buffer结构体用来存储数据,Buffer是一个变长缓冲区,可读可写
 var pkg =new(bytes.Buffer)
 //把长度以二进制的形式写入消息头
 err := binary.Write(pkg, binary.LittleEndian, length)
 if err != nil {
  return nil, err
 }
 //把消息以二进制的形式写入pkg
 err = binary.Write(pkg, binary.LittleEndian, []byte(msg))
 if err != nil {
  return nil, err
 }
 //将缓冲区的数据返回
 return pkg.Bytes(),nil
}

// Decode 参数是从连接中获取的原始消息,用这个方法将消息体解码
func Decode(reader bufio.Reader)(string,error){
 //1.获取消息的长度
 //按照约定,读取前32的长度
 //Peek是返回字节类型,一个字节是8个bit,所以是4个字节即代表32位的长度的数据
 lengthByte,_:=reader.Peek(4)
 //转换为buff类型
 lengthBuff:=bytes.NewBuffer(lengthByte)

 //这个长度是指消息体的长度
 var length int32
 //将长度赋值给length
 err := binary.Read(lengthBuff, binary.LittleEndian, &length)
 if err != nil {
  return "", err
 }
 //消息体的长度加上4个字节 就是完整的消息体了
 totalLen:=length+4
 //查看当前缓存区中消息的长度,如果消息还没有传输完毕,先不处理
 if int32(reader.Buffered())<totalLen{
  return "", err
 }
 //定义一个切片从缓冲区获取数据
 pack:=make([]byte,totalLen)
 _, err = reader.Read(pack)
 if err != nil {
  return "", err
 }
 //返回消息 ,注意不要返回前4个byte,前4个byte代表的是消息体的长度
 return string(pack[4:]),nil
}

• 服务端代码

package main

import (
 tcp_code "acurd.com/pkg/pkg/tcp-code"
 "bufio"
 "fmt"
 "io"
 "net"
)

func main() {
 network:="tcp"
 address:="127.0.0.1:30000"
 //绑定和监听tpc和端口
 listen, err := net.Listen(network, address)
 if err != nil {
  fmt.Println("listen err")
 }
 //关闭监听
 defer listen.Close()
 for{
  //等待连接
  conn,err:=listen.Accept()
  if err != nil {
   fmt.Println("accept error")
  }
  //从连接里面读取数据
  go process(conn)
 }
}

func process(conn net.Conn){
 defer conn.Close()//关闭连接
 //读取连接数据
 reader:=bufio.NewReader(conn)
 //定义每次接收的长度
 for  {
  //使用decode解码消息
  msg, err := tcp_code.Decode(reader)
  //读完了
  if err == io.EOF {
   break
  }
  if err != nil {
   fmt.Println("read conn err")
  }
  fmt.Println(msg)
 }
}

• 客户端代码

package main

import (
 tcp_code "acurd.com/pkg/pkg/tcp-code"
 "bufio"
 "fmt"
 "io"
 "net"
)

func main() {
 network:="tcp"
 address:="127.0.0.1:30000"
 //绑定和监听tpc和端口
 listen, err := net.Listen(network, address)
 if err != nil {
  fmt.Println("listen err")
 }
 //关闭监听
 defer listen.Close()
 for{
  //等待连接
  conn,err:=listen.Accept()
  if err != nil {
   fmt.Println("accept error")
  }
  //从连接里面读取数据
  go process(conn)
 }
}

func process(conn net.Conn){
 defer conn.Close()//关闭连接
 //读取连接数据
 reader:=bufio.NewReader(conn)
 //定义每次接收的长度
 for  {
  //使用decode解码消息
  msg, err := tcp_code.Decode(reader)
  //读完了
  if err == io.EOF {
   break
  }
  if err != nil {
   fmt.Println("read conn err")
  }
  fmt.Println(msg)
 }
}

• 我们看一下效果，发送了两个消息，一12345678,一个是abcdefghi

总结

通过上面，我们了解到了原来粘包的问题，并不属于tcp的锅。tcp是基于数据流的传输，保证数据流的顺序，但是正式由于这种数据流的传输模式，对于tcp来说，自己就像一个传送带，传递的是一个个的快递包裹，源源不断。具体包裹到是什么，到哪里去，就需要接收端和发送端通过定制的协议来编码和解码解决。