zoukankan      html  css  js  c++  java
  • 【TCP/IP】Nagle 算法以及所谓 TCP 粘包

    一、Nagle 算法

    我们以 SSH 协议举例,通常在 SSH 连接中,单次击键就会引发数据流的传输。如果使用 IPv4,一次按键会生成约 88 字节大小的 TCP/IPv4 包(使用安全加密和认证):20 字节的 IP 头部,20 字节的 TCP 头部(假设没有选项),数据部分为 48 字节。这些小包(称为微型报(tinygram))会造成相当高的网络传输代价。也就是说,与包的其他部分相比,有效的应用数据所占比例甚微。

    上述问题不会对局域网产生很大影响,因为大部分局域网不存在拥塞,而且这些包无需传输很远。然而对于广域网来说则会加重拥塞,严重影响网络性能。John 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 控制着发包速率。

    二、TCP 粘包

    1. Golang 代码演示

    我们利用 Golang 先来实现一段服务端的代码,如下所示:

    package main
    
    import (
    	"bufio"
    	"fmt"
    	"io"
    	"net"
    )
    
    func main() {
    	network := "tcp"
    	address := "127.0.0.1:30000"
    	listen, err := net.Listen(network, address)
    	if err != nil {
    		fmt.Printf("main | net.Listen(%s, %s) failed to execute", network, address)
    		return
    	}
    	defer listen.Close()
    	for {
    		conn, err := listen.Accept()
    		if err != nil {
    			fmt.Println("accept failed, err:", err)
    			continue
    		}
    		go process(conn)
    	}
    }
    
    func process(conn net.Conn) {
    	defer conn.Close()
    	reader := bufio.NewReader(conn)
    	var buf [1024]byte
    	for {
    		n, err := reader.Read(buf[:])
    		if err == io.EOF {
    			break
    		}
    		if err != nil {
    			fmt.Println("read from client failed, err:", err)
    			break
    		}
    		recvStr := string(buf[:n])
    		fmt.Println("收到client发来的资源:", recvStr)
    	}
    }
    

    紧接着来实现客户端的代码:

    package main
    
    import (
    	"fmt"
    	"net"
    )
    
    func main() {
    	conn, err := net.Dial("tcp", "127.0.0.1:30000")
    	if err != nil {
    		fmt.Println("dial failed, err", err)
    		return
    	}
    	defer conn.Close()
      // 循环发送20次 Hello World! This is a test demo.
    	for i := 0; i < 20; i++ {
    		msg := `Hello World! This is a test demo.`
    		conn.Write([]byte(msg))
    	}
    }
    

    先开启服务端代码,后允许客户端代码,输出结果如下:

    收到client发来的资源: Hello World! This is a test demo.Hello World! This is a test demo.Hello World! This is a test demo.Hello World! This is a test demo.Hello World! This is a test demo.Hello World! This is a test demo.Hello World! This isdemo.Hello World! This is a test demo.Hello World! This is a test demo.Hello World! This is a test demo.Hello World! This is a test demo.Hello World! This is a test demo.Hello World! This is a test demo.
    收到client发来的资源: Hello World! This is a test demo.Hello World! This is a test demo.Hello World! This is a test demo.Hello World! This is a test demo.Hello World! This is a test demo.Hello World! This is a test demo.Hello World! This isdemo.
    

    可以发现输出的结果并没有像客户端发送的次数一样,原先在客户端发送20次的代码在服务端只接收了两次。这看起来像是 TCP 发送的包被粘住了一样,故而产生了所谓“粘包”的问题。

    这里为代码做下总结,“粘包”问题的缘由可能发生在发送端也可能发生在接收端:

    • 由 Nagle 算法造成的发送端的粘包:Nagle 算法是一种改善网络传输效率的算法。简单来说就是当我们提交一段数据给 TCP 发送时,TCP 并不立刻发送此段数据,而是等待一小段时间看看在等待期间是否还有要发送的数据,若有则会一次把这好几段数据发送出去。
    • 接收端接受不及时造成的接收端粘包:TCP 会把接收到的数据存在自己的缓冲区中,然后通应用层取数据。当应用层由于某些原因不能及时地把 TCP 的数据取出来,就会造成 TCP 缓冲区中存放了几段数据。

    2. 粘包的本质

    从上面结果我们也看到了,上层通过 TCP 传递的数据好像被胶水黏在了一起,所以有了所谓的 TCP 粘包问题。但是在这里我们需要纠正的一个点是:TCP 是流协议,根本不存在所谓的粘包一说。

    send(2) Upon successful completion, the number of types which were send is returned.

    Otherwise, -1 is returned and the global variable errno is set to indicate the error.

    recv(2) These calls return the number of bytes received, or -1 if an error occurred.

    文档中已提及:sendrecv 的返回值表示成功发送/接收端字节数。所以对于应用层来说,黏包确实是个伪命题,TCP 本来就是一个基于字节流的协议而不是消息包的协议,它只会将你的数据编程字节流发到对面去,而且保证顺序不会乱,而对于字节流的解析,就需要我们自己来搞定了。

    3. 解决粘包问题

    解决黏包问题的最关键一步就是确定消息边界。首先我们需要明白什么是消息,在我认为,消息就是一段有意义的信息报文,例如一次 HTTP 请求或者像我们上面代码中所要发送的 Hello World! This is a test demo.

    所以我们要找到消息边界,这并不难理解,确定消息边界就是确定消息的开始或者结束。简单地说,就三个办法:

    • 定长消息:协议提前约定好包的长度为多少,每当接收端接收到固定长度的字节就确定一个包;
    • 消息分隔符:利用特殊符号标志着消息的开始或者结束,例如 HTTP 协议中的换行符;
    • 长度前缀:先发送N个字节代表包的大小(注意大端和小端问题),后续解析也按长度读取解析。

    接下来我们来延时下如何利用长度前缀解决粘包问题。

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

    package proto
    
    import (
      "bufio"
      "bytes"
      "encoding/binary"
    )
    
    // Encode 将消息message进行编码,返回byte切片
    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
    }
    

    接下来在服务端和客户端分别使用上面定义的 proto 包的 DecodeEncode 函数处理数据

    服务端代码如下:

    func main() {
      listen, err := net.Listen("tcp", "127.0.0.1:30000")
      if err != nil {
        fmt.Println("listen failed, err:", err)
        return
      }
      defer listen.Close()
      for {
        conn, err := listen.Accept()
        if err != nil {
          fmt.Println("accept failed, err:", err)
          continue
        }
        go process(conn)
      }
    }
    
    func process(conn net.Conn) {
      defer conn.Close()
      reader := bufio.NewReader(conn)
      for {
        msg, err := proto.Decode(reader)
        if err == io.EOF {
          return
        }
        if err != nil {
          fmt.Println("decode msg failed, err:", err)
          return
        }
        fmt.Println("收到client发来的数据", msg)
      }
    }
    

    客户端代码如下:

    func main() {
      conn, err := net.Dial("tcp", "127.0.0.1:3000")
      if err != nil {
        fmt.Println("dial failed, err", err)
        return
      }
      defer conn.Close()
      for i := 0; i < 20; i++ {
        msg := `Hello World! This is a test demo.`
        data, err := proto.Encode(msg)
        if err != nil {
          fmt.Println("encode msg failed, err:", err)
          return
        }
        conn.Write(data)
      }
    }
    

    三、延时 ACK 与 Nagle 算法结合

    延时 ACK 是指接收端不会每个包都发送一次 ACK 确认,而是当接收到一个包后延迟一段时间,以期望这段时间内仍有包被接收到,这是就可以只发送一次 ACK 确认之前收到的数据包,以减少网络带宽压力。

    但若将延时 ACK 与 Nagle 算法直接结合使用,得到的效果可能不尽如人意。考虑以下情景,客户端使用延时 ACK 方法发送一个对服务器的请求,而服务端的响应数据并不适合在同一个包中传输,如下图所示:

    从图中可以看到,在接收到来自服务器端端两个包以后,客户端并不立即发送 ACK,而是处于等待状态,希望有数据一同捎带发送。通常情况下,TCP 在接收到两个全长的数据包后就应返回一个 ACK,但这里并非如此。在服务器端,由于使用了 Nagle 算法,直到收到 ACK 前都不能发送新数据,因为任一时刻只允许至多一个小数据包在传。因此延时 ACK 与 Nagle 算法的结合导致了某种程度的死锁(两端互相等待对方作出行动),当然这种死锁并不是永久的,在延时 ACK 计时器或者响应端超时之后,将会得到解除。

    参考资料:

    【1】TCP/IP 详解 卷1:协议

  • 相关阅读:
    判断输入的字符串是否含有特殊字符和表情
    表单转换为JSON
    重写Alert和confirm方法去除地址显示
    C语言内存管理
    自定义C语言中常用的字符串操作函数
    C语言中定义字符串的几种方式
    WebStorm常用快捷键
    鼠标点击特效
    打印指定年份的日历
    VS code 生成.exe可执行文件失效问题
  • 原文地址:https://www.cnblogs.com/jojop/p/14376423.html
Copyright © 2011-2022 走看看