Unix/Linux编程：什么是TCP粘包？怎么解决这个问题

た入场券 2022-09-03 08:23 94阅读 0赞

在socket网络编程中，都是端到端通信，由客户端端口+服务端端口+客户端IP+服务端IP+传输协议组成的五元组可以明确的标识一条连接。在TCP的socket编程中，发送端和接收端都有成对的socket。**发送端为了将多个发往接收端的包，更加高效的发给接收端，于是采用了Nagle算法，将多次间隔较小，数据量较小的数据，合并成一个数据量大的数据块，然后进行封包**。那么这样一来，接收端就必须使用高效科学的拆包机制来分辨这些数据。

# 什么是TCP粘包问题 #

**TCP粘包就是指发送方发送的若干包数据到达接收方时粘成了一包，从接收缓冲区来看，后一包数据的头紧接着前一包数据的尾**。出现粘包的原因是多方面的，可能是来自接收方，也可能是来自发送方。

# 造成TCP粘包的原因 #

## 发送方原因 ##

TCP默认使用Nagle算法（主要作用：减少网络中报文段的数量），而Nagle算法主要做两件事：

*  只有上一个分组得到确认，才会发送下一个分组
 *  收集多个小分组，在一个确认到来时一起发送。

Nagle算法造成了发送方可能会出现粘包问题

>  *  TCP有一个数据流接口，应用程序可以通过它将任意尺寸的数据放入TCP栈中----即使一次只放一个字节也可以（！！！造成“发送端傻窗口综合征”）。但是，每个TCP段中都至少装载了40个字节的标记和首部，所以如果TCP发送了大量包含少量数据的分组，网络的性能就会严重下降，
>  *  Nagle算法试图在发送一个分组之前，将大量的TCP数据绑定在一起，以提高网络效率。
>  *  Nagle算法鼓励发送全尺寸的段，只有当所有其他分组都被确认之后，Nagle算法才允许发送非全尺寸的分组。如果其他分组仍然在传输过程中，就将那部分数据缓存起来。只有当挂起分组被确认，或者缓存中积累了足够发送一个全尺寸分组的数据时，才会将缓存的数据发送出去。
>  *  Nagle算法会引发几种HTTP性能问题。首先，小的HTTP报文可能无法填满一个分组，可能会因为等待哪些永远不会到达的额外数据而产生时延。其次，Nagle算法与延迟确认之间的交互存在问题------Nagle算法会阻止数据的发送，直到有确认分组到达为止。但确认分组自身会被延迟确认算法延迟100-200ms，当使用管道化连接时这些问题可能会更加严重，因为客户端可能会有多条报文要发送给同一个服务器，而且不希望有时延存在。
>  *  **HTTP应用程序常常会在自己的栈中设置参数TCP\_NODELAY，禁用Nagle算法，提高性能。如果这样做的话，一定要确保会向TCP写入大块的数据，这样就不会产生一堆小分组了**。

## 接收方原因 ##

TCP接收到数据包时，并不会马上交到应用层处理，或者说应用层并不会立即处理。实际上，TCP将接收到的数据包保存在接收缓存里，然后应用程序主动从缓存读取收到的分组。**这样一来，如果TCP接收数据报到缓存的速度岛屿应用程序从缓存中读取数据报的速度，多个包就会被缓存，应用程序就有可能读取到多个收尾相接粘到一起的包**

# 如何处理粘包现象 #

## 发送方 ##

对于发送方造成的粘包问题，可以通过关闭Nagle算法来解决，使用TCP\_NODELAY选项来关闭算法。

acl_socket* conn_fd = listen_fd_->acl_accept(NULL, 0, NULL);
            if (conn_fd == NULL) {
        
                if (open_flag_ & ACL_NON_BLOCKING) {
        
                    logger_error("accept error %s", strerror(errno));
                } else if (errno != EAGAIN && errno != EWOULDBLOCK) {
        
                    logger_error("accept error %s", strerror(errno));
                    return NULL;
                }
            }
    
            conn_fd->acl_tcp_set_nodelay();

void acl_tcp_set_nodelay(ACL_SOCKET fd)
    {
        
    	acl_tcp_nodelay(fd, 1);
    }
    // 1表示打开 TCP_NODELAY选项
    void acl_tcp_nodelay(ACL_SOCKET fd, int onoff)
    {
        
    	const char *myname = "acl_tcp_nodelay";
    	int   on = onoff ? 1 : 0;
    	int   n = acl_getsocktype(fd);
    
    #ifdef AF_INET6
    	if (n != AF_INET && n != AF_INET6)
    #else
    	if (n != AF_INET)
    #endif
    		return;
    
    	if (setsockopt(fd, IPPROTO_TCP, TCP_NODELAY,
    		(char *) &on, sizeof(on)) < 0) {
        
    
    		acl_msg_error("%s(%d): set nodelay error(%s), onoff(%d)",
    			myname, __LINE__, acl_last_serror(), onoff);
    	}
    }

## 接收方 ##

接收方没有办法来处理粘包问题，只能将问题交给应用层来处理

## 应用层 ##

应用层的解决办法简单可行，不仅能解决接收方的粘包问题，还可以解决发送方的粘包问题。

解决方法：**循环处理，应用程序从接收缓存中读取分组时，读完一条数据，就应该循环读取下一条数据，直到所有数据都被处理完成**，但是如何判断每条数据的长度呢？

*  **格式化数据：每条数据有固定的格式（开始符，结束符），这种方法简单易行，但是选择开始符和结束符时一定要确保每条数据的内部不包含开始符和结束符**。
 *  发送长度：发送每条数据时，将数据的长度一并发送，比如规定数据的前4位是数据的长度，应用层在处理时可以根据长度来判断每个分组的开始和结束位置、

# UDP会不会产生粘包问题呢？ #

TCP为了保证可靠传输并减少额外的开销(每次发包都要验证)，采用了基于流的传输，基于流的传输不认为消息是一条条的，是无保护消息边界的（保护消息边界：指传输协议把数据当做一条独立的消息在网上传输，接收端一次只能接受一条独立的消息）。

UDP则是面向消息的，是由保护边界的，接收方一次只接收一条独立的消息，所以不存在粘包问题

举个例子：有三个数据包，大小分别为2k、4k、6k，如果采用UDP发送的话，不管接受方的接收缓存有多大，我们必须要进行至少三次以上的发送才能把数据包发送完，但是使用TCP协议发送的话，我们只需要接受方的接收缓存有12k的大小，就可以一次把这3个数据包全部发送完毕。