• UNIX网络编程——tcp流协议产生的粘包问题和解决方案


           我们在前面曾经说过,发送端可以是一K一K地发送数据,而接收端的应用程序可以两K两K地提走数据,当然也有可能一次提走3K或6K数据,或者一次只提走几个字节的数据,也就是说,应用程序所看到的数据是一个整体,或说是一个流(stream),在底层通讯中这些数据可能被拆成很多数据包来发送,但是一个数据包有多少字节对应用程序是不可见的,因此TCP协议是面向流的协议,这也是容易出现粘包问题的原因。而UDP是面向消息的协议,每个UDP段都是一条消息,应用程序必须以消息为单位提取数据,不能一次提取任意字节的数据,这一点和TCP是很不同的。


    一、粘包问题可以用下图来表示:


    假设主机A发送了两个数据包M1和M2给主机B,由于主机B一次接收的字节数是不确定的,故可能存在上图的4种情况,

    1、分两次接收两个数据包,一次一个,没有粘包问题;

    2、一次接收了两个数据包,存在粘包问题;

    3、第一个接收了M1和M2的一部分,第二次接收M2的另一部分,存在粘包问题;

    4、第一次接收了M1的一部分,第二次接收M1的另一部分和M2,存在粘包问题;

    当然实际的情况可能不止以上4种,可以得知的是在互联网上通信很容易造成粘包问题。


    二、粘包问题产生的原因

    如下图所示,产生的原因主要有3个,当应用程序write 写入的大小大于套接口发送缓冲区大小时;当进行MSS大小的tcp分段时;当以太网帧的payload大于MTU进行ip分片时;都很容易产生粘包问题。



    三、粘包问题的解决方案

    本质上是要在应用层维护消息与消息的边界
    1、定长包
    2、包尾加 (ftp)
    3、包头加上包体长度

    4、更复杂的应用层协议

           对于条目2,缺点是如果消息本身含有 字符,则也分不清消息的边界,条目4不在本文讨论范围内。

           对于条目1,即我们需要发送和接收定长包。因为TCP协议是面向流的,read和write调用的返回值往往小于参数指定的字节数。对于read调用(套接字标志为阻塞),如果接收缓冲区中有20字节,请求读100个字节,就会返回20。对于write调用,如果请求写100个字节,而发送缓冲区中只有20个字节的空闲位置,那么write会阻塞,直到把100个字节全部交给发送缓冲区才返回,但如果socket文件描述符有O_NONBLOCK标志,则write不阻塞,直接返回20。为避免这些情况干扰主程序的逻辑,确保读写我们所请求的字节数,我们实现了两个包装函数readn和writen,如下所示。

            ssize_t readn(int fd, void * buf, size_t count)
            {
                size_t nleft = count;
                ssize_t nread;
                char *bufp = (char *)buf;
    
                while (nleft > 0)
                {
    
                    if ((nread = read(fd, bufp, nleft)) < 0)
                    {
    
                        if (errno == EINTR)
                            continue;
                        return -1;
                    }
    
                    else if (nread == 0) //对方关闭或者已经读到eof
                        return count - nleft;
    
                    bufp += nread;
                    nleft -= nread;
                }
    
                return count;
            }
    
            ssize_t writen(int fd, const void * buf, size_t count)
            {
                size_t nleft = count;
                ssize_t nwritten;
                char *bufp = (char *)buf;
    
                while (nleft > 0)
                {
    
                    if ((nwritten = write(fd, bufp, nleft)) < 0)
                    {
    
                        if (errno == EINTR)
                            continue;
                        return -1;
                    }
    
                    else if (nwritten == 0)
                        continue;
    
                    bufp += nwritten;
                    nleft -= nwritten;
                }
    
                return count;
    
            }

           需要注意的是一旦在我们的客户端/服务器程序中使用了这两个函数,则每次读取和写入的大小应该是一致的,比如设置为1024个字节,但定长包的问题在于不能根据实际情况读取数据,可能会造成网络阻塞,比如现在我们只是敲入了几个字符,却还是得发送1024个字节,造成极大的空间浪费。

           此时条目3是比较好的解决办法,其实也可以算是自定义的一种简单应用层协议。比如我们可以自定义一个包体结构:

    struct packet {
        int len;
        char buf[1024];
    };
         先接收固定的4个字节,从中得知实际数据的长度n,再调用readn 读取n个字符,这样数据包之间有了界定,且不用发送定长包浪费网络资源,是比较好的解决方案。服务器端在前面的fork程序的基础上把do_service函数更改如下:
    void do_service(int conn)
    {
        struct packet recvbuf;
        int n;
        while (1)
        {
            memset(&recvbuf, 0, sizeof(recvbuf));
            int ret = readn(conn, &recvbuf.len, 4);
            if (ret == -1)
                ERR_EXIT("read error");
            else if (ret < 4)   //客户端关闭
            {
                printf("client close
    ");
                break;
            }
    
            n = ntohl(recvbuf.len);
            ret = readn(conn, recvbuf.buf, n);
            if (ret == -1)
                ERR_EXIT("read error");
            if (ret < n)   //客户端关闭
            {
                printf("client close
    ");
                break;
            }
    
            fputs(recvbuf.buf, stdout);
            writen(conn, &recvbuf, 4 + n);
        }
    }
    客户端程序的修改与上类似,不再赘述。

  • 相关阅读:
    maven
    Web开发入门
    网络编程之Socket
    自定义注解与设计模式
    数据交换格式与SpringIOC底层实现
    caffe笔记之例程学习(二)
    caffe笔记之例程学习
    ubuntu14.04 caffe环境配置
    Pattern Recognition (Fourth Edition)读书笔记之mvnrnd函数
    MIF文件编写小技巧
  • 原文地址:https://www.cnblogs.com/wangfengju/p/6172514.html
Copyright © 2020-2023  润新知