Tcp实现文件传输的一些问题

一. 粘包问题

1. 概述

        Tcp粘包是指发送方发送的若干个数据包达到接收方时粘成一个包，从接收缓冲区来看，后一个数据包的头紧接着前一个数据包的尾。

        Tcp接收到数据包时，不会马上交给应用层进行处理，而是保存在接收缓冲区里，然后由应用程序主动从缓冲区读取收到的分组。这时，如果Tcp接收数据包到缓存的速度大于应用程序从缓存读取数据包的数据，多个数据包会被缓存，应用程序就可能读取到多个首尾相连在一起的包。

2. 解决思路

        由于Tcp是流式协议，内容与内容之间没有分界标志，我们可以自己人为地给这些数据划分边界，在接收方就可以根据边界分出一个一个的数据包。

        可以定义一个结构体MyDataPack表示数据包的头部，其中DatapackFlag可以自己定义字符串表示头部，比如我用的"DAEH_ATAD_PCT_YM"（MY_TCP_DATA_HEAD）的反序，这个字符串要避免与发送的内容一样；jsonSize表示要发送的json内容的长度。

struct MyDataPack
{
    char DatapackFlag[20];
    int jsonSize;
};

         对于要发送的内容，使用json格式进行发送，便于解析。流程图如下。

2. 文件传输的过程

        在文件传输过程中，为了避免接收方的接收速度跟不上发送方的发送速度，这里采用应答方式进行传输。收发双方先验证文件的文件名和md5值，主要存在以下三种情况：

1. 如果发送方想要发送的文件在接收方有同名文件，且md5值相同，说明接收方已经存有该文件，无需再次传输。
2. 如果接收方有文件名为md5值的文件，说明接收方接收不完整，可以根据文件名为md5的文件大小确定需要继续接收的为止（实现断点续传）。
3. 如果接收方没有同名文件且没有文件名为md5的文件，则此次接收的是新文件。

        在发送文件之前，发送方发送一个json数据，格式为：

{
    type:      "md5",
    md5:       "文件的md5值",
    file-path: "文件在发送方的路径"
}

        接收方收到json数据并解析，若接收方已有该文件，直接返回发送完成。否则返回这样的json数据（ack表示下一次接收的文件位置）：

{
    type:      "ack",
    file-path: "文件在发送方的路径",
    ack:       number(pos)
}

        然后，收发双方开始循环传输数据了。发送方发送数据块，其中发送方的seq和ack相对应。

{
    type: "file",
    content: {
        file-path:    "文件在发送方的位置",
        file-size:    "文件的总大小",
        file-content: "文件块数据",
        seq:          "文件块起始位置"
    }
    is-end: flase/true
}

        其时序图如下：