粘包问题、mmap和分片上传

一、粘包问题：

如果一端要把文件发给另一端，要发送两个部分的数据：其一是文件名，用于对端创建文件；另一个部分是文件内容。服务端在接收文件名，实际上并不知道有多长，所以它会试图把网络缓冲区的所有内容都读取出来，但是send底层基于的协议是TCP协议 ——这是一种流式协议。这样的情况下，服务端没办法区分到底是哪些部分是文件名而哪些部分是文件内容。完全可能会出现服务端把文件名和文件内容混杂在一起的情况，这种就是江湖中所谓的"粘包"问题。

定义一个结构体规定TCP发送和接收的实际长度从而确定单个消息的边界。

typedef struct train_s{
int size;
char buf[1000];
} train_t;

1、文件比较大时使用循环机制：发送方使用一个循环来读取文件内容，每当读取一定字节的数据之后，将这些数据的大小和内容填充进小火车当中；接收方就不断的使用recv接收小火车的火车头和车厢，先读取4个字节的火车头，再根据车厢长度接收后续内容。

2、服务端往客户端已经关闭的网络socket中写入数据，导致进程收到SIGPIPE信号异常终止。解决方法是给send的最后一个参数加上MSG_NOSIGNAL选项。

3、调用recv的时候，需要传入一个整型的长度参数，但是遗憾的是，这个长度参数是描述的是最大的长度，而实际recv的长度可能并没有达到最大的长度——因为TCP是一种流式协议，它只能负责每个报文可靠有序地发送和接收，但是并不能保证传输到网络缓冲区当中的就是完整的一个小火车（即数据到达有延迟）。解决方案就是给recv函数设置MSG_WAITALL属性，这样的话， recv在不遇到EOF或者异常关闭的情况就能一定把最大长度数据读取出来。

二、mmap:

采用read和send传输数据时，首先打开一个普通文件，数据会从磁盘通过DMA设备传输到内存，即文件对象当中的内核缓冲区部分，然后调用read 数据会从内核缓冲区拷贝到一个用户态的buf 上面（buf是 read 函数的参数），接下来调用send，就将数据拷贝到了网络发送缓冲区，最终实现了文件传输。

但这里涉及到了大量不必要的拷贝操作。

使用mmap系统调用直接建立文件和用户态空间buf的映射。可以减少一次拷贝。

下面是使用mmap的例子：

//假设文件本身的内容是hello#include <func.h>
int main(int argc, char *argv[])
{// ./mmap file1ARGS_CHECK(argc, 2);// 先open文件int fd = open(argv[1], O_RDWR);ERROR_CHECK(fd, -1, "open");// 建立内存和磁盘之间的映射char *p = (char *)mmap(NULL, 5, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);ERROR_CHECK(p, MAP_FAILED, "mmap"); // mmap失败返回不是NULLfor (int i = 0; i < 5; ++i){printf("%c", *(p + i));}printf("\n");*(p + 4) = '0';for (int i = 0; i < 10; ++i){printf("%c", *(p + i));}munmap(p, 5);close(fd);return 0;
}

运行结果：

mmap的底层原理 :

read/write 是让数据在内核态的文件对象和用户态内存之间进行来回拷贝，文件对象会和一片由操作系统管理的内存区域（被称为页缓存）相关联，一般来说，操作系统会选择一个合适策略并使用专门的硬件(比如DMA设备)来同步磁盘和页缓存当中的内容，这样 read/write 操作最终就会影响到磁盘。而 mmap 的处理就更加简单粗暴，它直接把页缓存的一部分映射到用户态内存，这样用户在用户态当中的操作就直接对应页缓存的操作。这样看上去的话， mmap 的效率总是会比 read/write 更加高，因为它避免了一次数据在用户态和内核态之间的拷贝。但是考虑到 read/write 的特殊性质——它们总是顺序地而不是随机地访问磁盘文件的内容，所以操作系统可以根据这个特点进行优化，比如文件内容的预读等等，最终经过测试—— read/write 在顺序读写的时候性能更好，而 mmap 在随机访问的时候性能更好。