一、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.
文档中已提及：send 和 recv 的返回值表示成功发送/接收端字节数。所以对于应用层来说，黏包确实是个伪命题，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 包的 Decode 和 Encode 函数处理数据
服务端代码如下：
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:协议