【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:协议

posted @ 2021-02-05 10:41  周二鸭  阅读(1853)  评论(0编辑  收藏  举报