Linux 序列化与反序列化：原理分析与自定义协议实现

在有了上面对于序列化和反序列化的认识后，下面我们来看一张图。

通过这张图我们就要来重新认识 read, write, recv, send 这些 IO 函数。

首先我们要知道当我们在使用 Socket 编程相关的 API 接口时，会在内核中形成发送缓冲区和接收缓冲区。

所以当我们使用上面那些 IO 函数来传递消息时，并不是真的把数据直接传送给对方了，而是将你要发送的内容拷贝到缓冲区中。

所以这里我们就可以输出第一个结论：write 等 IO 函数的本质就是拷贝，发送数据是拷贝，读取数据也同样是拷贝！！！

那么下面就又会出现一个问题：那么我们通过 write 等函数将数据拷贝到缓冲区中，什么时候将数据发出去呢？发多少呢？

那么答案就是我们要输出的第二个结论：这些工作都由 TCP 自己来决定，所以 TCP 才叫做传输控制协议！！！

那么这里面还有一个隐性问题，那就是：发送的过程中数据发少了怎么办？

可能有人没看懂这个问题，就比如：当我们通过 write 函数向缓冲区中拷贝数据时，有没有可能缓冲区快满了，只能拷贝进去一部分？或者当 TCP 想要将数据发送到对方的接收缓冲区中时，对方的接收缓冲区也快满了，如果发送数据，也是只能发送一部分呢？

当然是有可能的，如果发送的数据缺斤少两，那么对方收到的消息也不会是完整的，那么可能就会出问题，而这种问题叫做："半包"问题。

与半包问题相对应的还有一种问题叫做："粘包"问题，这个问题产生的原因正好与半包问题相反。

"粘包"问题产生的原因就是：发送方一次性发送了多组数据，但是这几组数据都很小，而接收方的缓冲区又很大，所以可能会出现接收方通过 read 函数来读取数据时，直接将这几组数据一次性全读了出来，但是代价就是这几组数据"粘"在了一起，不知道每一组数据的开始和结束，这就是"粘包"问题。

而**"半包"问题或者"粘包"问题我们就需要自定义协议来解决**，而在这里我们得先弄清TCP 协议，UDP 协议等协议与自定义协议的区别：

这里用生活中送快递的例子来说明，TCP 协议等就像快递员一样，它们不关心包裹中的内容是什么，它们关心的只是将包裹从厂商送到你的手里，这中间出现的问题，如：包裹丢了，包裹少发了，包裹顺序乱了等这些问题它们会解决。

但是对于你收到的包裹中是否是你想要的东西，这与它们没有关系，这就与自定义协议有关，也就是你在网上下单，你买的是牛仔裤，厂家给你发的也是牛仔裤，这就相当于你和厂家"约定"好的一样，自定义协议管的就是包裹中的具体内容。

那么我们接着思考：TCP 协议发送数据的时候，是怎么让数据出现在接收方的接收缓冲区中的呢？

答案就是拷贝，这里我们就要输出第三个结论了：主机间通信的本质就是把发送方发送缓冲区内部的数据，拷贝到接收方的接收缓冲区中，一样是拷贝。

那么下面我们就来思考：为什么 TCP 通信的时候，是全双工的，即在发送数据的同时也可以读取数据？

其实经过我们上面的讲解答案已经很明显了，第四个结论：就是因为有两对发送和接收缓冲区啊，不管是发送方还是接收方，都有一个发送缓冲区，一个接收缓冲区，它们之间互不影响，那么自然就可以做到全双工通信。

那么这里还有一个衍生问题：一个文件描述符有一套缓冲区，那么我们通过 socket 接口创建的多个文件描述符呢？

答案就是每一个通过 socket 接口成功创建的文件描述符，内核都会为它们分配一套独立的缓冲区，这其实也很好理解，未来可能会有多个客户端和服务端进行通信，每个客户端都应该有自己的缓冲区，而不是和别人共用一个缓冲区。

那么我们最后再来思考一个问题：用户通过 write 函数向缓冲区中拷贝数据，TCP 从缓冲区中拿出数据将其拷贝到对端的缓冲区中，有没有感觉这种方式很熟悉呢？

当然熟悉了，因为这不就是我们之前讲的生产者消费者模型嘛，那么这里就要输出第五个结论：我们的任务，在每一个发送单元，都是一个 CP 问题，是用户和内核之间在进行生产和消费！！！

三、网络版计算器

3.1 约定方案

这里我们先来规定一下我们的网络版计算器该怎样去实现，也就是"约定"客户端和服务端之间的传输的一些规则，下面我们来看：

约定方案一：

1. 客户端发送的数据形式为 "1+2" 的字符串
2. 这个字符串中有两个操作数，且都是整型，不能是浮点型等其他类型
3. 两个数字之间会有一个字符是运算符，不能是其他字符
4. 数字和运算符之间没有空格

约定方案二：

1. 定义结构体来标识我们需要交互的信息
2. 发送数据时将这个结构体按照一个规则转化成字符串，接受到数据的时候再按照相同的规则把字符串转化会结构体

以上就是我们在实现网络版计算器中客户端和服务端要遵守的规则。

3.2 代码实现

在上一篇文章中我们使用了 Socket 编程的各种接口，而我们今天来玩点不一样的，我们自己来封装一个 Socket 接口类去使用。

而我们封装的 Socket 接口类我们使用一种常见的设计模式来实现，即：模板方法类，具体怎么来实现，下面我们就来看看吧。

3.2.1 准备工作

首先呢我们先创建出这些文件，其中 Main.cc 和 Client.cc 分别表示服务端和客户端，剩下的我们基本都认识，前面都见过，唯独这里面的 InetAddr.hpp 我们之前没有见过。

#pragma once // 这个类，描述 client socket 信息的类 // 方便我们后续用它来管理客户端
#include <iostream>
#include <string>
#include <cstring>
#include <sys/types.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <netinet/in.h>
#define Conv(addr) ((struct sockaddr*)&addr)

class InetAddr {
private:
    void Net2Host() {
        _port = ntohs(_addr.sin_port);
        char ipbuffer[64];
        inet_ntop(AF_INET, &(_addr.sin_addr.s_addr), ipbuffer, sizeof(ipbuffer));
        _ip = ipbuffer;
    }
    void Host2Net() {
        memset(&_addr, 0, sizeof(_addr));
        _addr.sin_family = AF_INET;
        _addr.sin_port = htons(_port);
        inet_pton(AF_INET, _ip.c_str(), &(_addr.sin_addr.s_addr));
    }
public:
    InetAddr() {}
    InetAddr(const struct sockaddr_in &addr) : _addr(addr) { Net2Host(); }
    InetAddr(uint16_t port, const std::string &ip = "0.0.0.0") : _port(port), _ip(ip) { Host2Net(); }
    void Init(const struct sockaddr_in &addr) { _addr = addr; Net2Host(); }
    std::string Ip() { return _ip; }
    uint16_t Port() { return _port; }
    struct sockaddr* Addr() { return Conv(_addr); }
    socklen_t Length() { return sizeof(_addr); }
    std::string ToString() { return _ip + "-" + std::to_string(_port); }
    bool operator==(const InetAddr &addr) { return (_ip == addr._ip && _port == addr._port); }
    ~InetAddr() { }
private:
    struct sockaddr_in _addr; // 网络风格地址
    std::string _ip;          // 主机风格地址
    uint16_t _port;
}; 

这个类我们是对 Socket 套接字进行了封装，便于我们完成主机序到网络序和网络序到主机序的转换，并且里面的方法也能够方便我们拿到 IP 地址和端口号。

这个类不是我们要讲的重点，所以这里我们就不过多赘述，直接用就行。

3.2.2 Socket 封装

那么下面我们就来看看模板方法类是怎么用的。

那么首先我们先定义一个 Socket 类，把它作为基类，里面有一些纯虚函数，未来是需要子类来实现的，包括：create, bind, listen 这些我们熟知的创建套接字的流程函数，子类都要将其实现。

而基类中还有一个函数将这三个函数整合在一起，按顺序执行，所以我们未来执行的思路就是让基类指针指向子类对象，然后再让子类对象去调用它继承下来的 Build 函数，一次性调用者三个函数完成创建套接字的流程，这就是模板方法类。

那么不说废话，下面我们就来实现一下里面的几个函数：

这里我们创建一个 TcpSocket 的子类，由它来完成基类中相关函数的实现。

这里我们对于创建套接字过程中如果失败了我们要直接终止进程，所以我们通过枚举列举了几个变量，让代码看起来更美观，更直接。

之后我们再实现这三个函数时，分别要用到 sockfd, port, backlog 这三种属性，这三个函数都要用到 sockfd，所以这里我们直接把 sockfd 给当成类内成员变量来使用，而对于 backlog，它是已完成连接队列的最大长度，这里我们直接将其默认为一个固定值即可。

所以未来我们只需要传入一个端口号即可，这里我们可以去看一下 InetAddr.hpp 中的相关实现，我们只传端口号即可，IP 地址我们默认绑定的就是任意 IP 地址，即：0.0.0.0。

那么创建套接字的工作完成了，下面的工作自然就是连接了，那么下面我们就先来实现 accept 函数：

这就是目前要实现的 Accept 函数，对于 Accept 函数，我们不仅要它成功后返回的文件描述符，还要知道发送信息的客户端的相关属性，如：IP 地址和端口号，这些信息都会保存在 peer 中，然后我们通过传进来的 addr 来调用 Init 函数，实现赋值操作，即可拿到客户端的相关信息。

而我们上面在实现时我们将返回值设置为我们自定义的 Socket 类，这样做的原因可以让我们未来创建出来的 sockfd 都能够使用我们所设计的 Socket 类，不然就只有 listensockfd，即监听套接字能用，那我们就没有单独设计 Socket 类的意义了。

目前我们的 Socket 类就先实现到这里，后面我们有需要的功能再来实现。

3.2.3 TcpServer.hpp 的实现

那么下面我们就来着手实现服务端的相关功能。

有了上面铺垫，那么对于 TcpServer 我们就可以直接写出上面的内容，端口号不用多说，我们未来是要传给 build 函数的，所以将其作为成员变量无可厚非，而我们设计出 Socket 类，就是要用它，所以我们也不单独设计 Init 函数了，直接在构造函数中通过 build 函数完成初始化的工作。

那么完成了初始化的工作，下面就是让整个服务端运行起来，所以我们下面要实现一个 run 函数：

首先我们可以将 Run 函数实现到这个地步，这里我们采用多进程的方式来让服务端可以同时与多个客户端进行通信，来处理客户端的请求。

而要实现这一点我们就要解决父进程等待子进程结束的问题，如果不解决，父进程就必须得等待子进程结束才能接着执行，那么这种方式导致的结果就是服务端只能同时服务一个客户端。

可能有人不理解为什么，我们来设想一个场景：你作为客户端，是想让服务端能够长时间服务你还是服务一次直接挂掉了？

答案显然是第二种，那么服务端要处理客户端请求的函数或者功能一定是一个死循环，这样才能随时处理客户端的请求，那么既然是死循环，子进程什么时候结束就是未知数，难道父进程要一直等吗？或者说你愿意排队吗？

我们当然不想等，我们要的就是客户端随时给服务端发送请求，服务端就要立刻处理我们的请求，所以我们不能让父进程一直在等待子进程。

当然这里的做法很多，我选择了一种较为简单的一种，就是利用信号，也算是回顾一下我们前面所学的知识。

那么在上面的代码中我们想要打印出新创建的文件描述符是多少，但是这里我们还没有实现，所以我们要在 Socket 类中实现一下：

实现这个功能很简单，这里不再多说。

那么下面就是父进程和子进程要做的事了，那么它们首先要做的就是关闭他们用不到的文件，也就是通过 Close 函数来关闭文件描述符所对应的文件，因为是多进程，所以文件是有引用计数的，所以不必担心文件被彻底关闭，那么下面我们就来实现一下该函数：

思路同样很简单，我们实现之后就可以用来关闭文件，对于子进程而言，它用不到 listensocket，所以子进程要将其关闭，对于父进程而言，它用不到新创建的 sockfd，所以父进程要将其关闭。

那么接下来就是子进程要干的事了，那就是处理客户端传来的请求，也就是要计算的字符串，下面我们接着看：

那么首先既然要处理客户端的请求我们就要先拿到客户端传进来的数据，所以这里我又设计了一个 Recv 函数用来接收客户端传来的数据，并对读取到的字节进行了简单的判断。

那么既然接收到了数据，那么我们先不谈怎么处理客户端传来的数据，那么我们肯定要将处理后的数据传回给客户端，所以下面我们先实现 Send 函数：

send 函数实现完，我们就可以来实践一下了，看我们目前的代码能否支持客户端和服务端之间的通信。

从结果中我们可以看到此时我们的代码是可以进行通信的，但是我们也看到了我们通信的内容，也就是服务端返回的字符串一直在变长，这一点我们也能理解：

因为我们把要处理的字符串放在了外面，并且接收数据时我们是通过 += 让其累加的，所以字符串会越来越长。

那么我这样写肯定是有原因的，我们在上面讲了可能会出现半包问题，那么我们如何判断读取的数据是否完整呢？

答案就是通过这种方式，只有这样我们才能判断读取的内容是否完整不是吗？

但是我们现在还没有说清楚，通过上面的讲述只是对于后面的设计有了一个大概的方向，那么下面我们就用三个问题确定最终的方向：

1. 如何知道字符串 in 里面至少有一个完整的报文呢？ 2. 如何把这个完整的报文交给上层呢？ 3. 上层拿到了报文又该如何处理呢？

这三个问题就概括了我们后面要做的事，而这三个问题的答案又都与协议有关，所以下面我们就要将目光放在协议上面去了。

3.2.4 Protocol 协议的实现

下面我们就来看看自定义协议中都有哪些东西：

我们曾经说过协议就是一个结构体，但那是站在 C 语言的角度来解释的，而我们今天是用 C++ 来编写代码的，所以我们这里要用到的就是 class 类。

而在这里我们定义了两个类，分别是：Request 和 Response，这两个类分别用来处理请求和发送回复，因为我们要做的是一个计算器，所以 Request 类中要有要计算的两个数和运算符号。

而Response 类中我们要返回计算后的结果，而在该类中我又定义了一个_code 的成员变量，这个变量用来表示可信度，就比如：如果客户端传来的是 10 / 0，那么我们就无法给 result 一个准确的值，所以如果是这种情况，我们就需要_code 变量来表明此时的 result 是不可信的，是错误的。

那么这两个类还需要做的事情就是完成序列化和反序列化，由它们完成序列化和反序列化后，再交给上层去进行处理，也就是计算结果，那么下面我们就要来了解怎么进行序列化与反序列化。

我们要实现序列化和反序列化就要用到 Jsoncpp 库，那么下面我们就来简单认识一下 Jsoncpp 库：

Jsoncpp 是一个用于处理 JSON 数据的 C++ 库。它提供了将 JSON 数据序列化为字符串以及从字符串反序列化为 C++ 数据结构的功能。Jsoncpp 是开源的，广泛用于各种需要处理 JSON 数据的 C++ 项目中。

那么在该库中就提供了进行序列化和反序列化的相关接口，那么下面我们依次来认识一下。

序列化：

1. 使用 Json::Value 的 toStyledString 方法

我们首先要定义一个 Json 库中的 Value 对象，这是一个万能对象，然后用法就是利用 [] 在里面填入你要用到的属性，= 号后面就是该属性所对应的数据。

然后我们在通过 Value 对象的 toStyledString 函数进行转化，结果就如上面所示的那样，是一个结构化的数据，那么这时候有人就要问了：这怎么长得不像是一个字符串，更像是一个结构化的数据呢？

那是因为在生成的字符串中间利用了 "\n" 等特殊字符，让字符串看来更加美观，结构更加清晰。

那么有人就说：那我就想看看完整的一条长字符串呢？

2. 使用 Json::FastWriter

如你所愿，我们可以定义一个 FastWriter 对象，通过调用该对象的 write 函数，将我们上面初始化后的 Value 对象给传进去，返回一个字符串，打印出的结果就是一个连续的长字符串。

序列化的方式还有很多种，剩下的我们就不再一一列举了，那么下面我们就来看看是如何进行反序列化的。

对于反序列化我们只介绍一种，那就是：使用 Json::Reader，下面我们就来看看它是怎么使用的：

我们要创建一个 Reader 对象，并调用该对象的 parse 函数，该函数我们需要传入两个参数，第一个就是我们要反序列化的字符串，第二个就是要将反序列化后的结果存入一个 Value 对象中，所以我们还要创建一个 Value 对象。

而我们要打印的时候要用到 Value 对象的相关方法，如果里面是 string 类型的参数，就用 asString，int 类型就用 asInt，其余皆是如此，但是 char 类型是没有的，我们可以用 asInt 代替。

至此我们对于序列化和反序列化的简单认识就到这里，下面我们就来着手写一下我们的 Request 和 Response 类：

上面的代码逻辑并不复杂，所以这里就不过多赘述了。

那么即使我们完成了序列化和反序列化的工作，依旧没有解决我们上面的问题，即：我们怎么知道字符串中有一个完整的报文呢？

所以仅仅完成序列化和反序列化的工作是不够的，而我们的做法则是给我们经过序列化的字符串添加一个报头，即：有效载荷长度，用它记录我们序列化后长字符串的长度，作为我们判断报文是否完整的一个标准。

所以下面就来完成上面的工作：

这里我们的做法是新创建一个 Protocol 类，在里面实现一个 Package 方法用来完成上面的工作，并且为了使我们最后的字符串可读性比较好，所以我们在中间添加了 "\r\n"。

最终该函数将返回一个完全体状态的一个报文，但是我们依旧没有解决上面所说的判断完整报文的问题，所以下面我们还要接着完善。

所有工作准备就绪下面我们就要彻底解决该问题，那么我们的思路就是将我们上面包装好的字符串 origin_str 传进去，并将其设置为输入输出型参数，至于为什么后面我们就知道了，并且我们传进去一个字符串 package 作为输出型参数，用来接收一个完整的报文。

那么下面我们就来实现一下该功能：

这里的实现思路我在上面已经通过注释进行了说明，这里我解释一下为什么要将 origin_str 设置成输入输出型参数：

在代码的上面我们其实解决的都是半包问题，即读取的报文不完整，但是我们上面也说了，不止有半包问题，还可能会有粘包问题，而将 origin_str 设置成输入输出型参数就是为了解决粘包问题。

如果是粘包问题，那么我们截取一个完整的 jsonstr 后，再次调用该函数，得到的依旧是上次已截取出来的结果，所以为了避免影响后面的逻辑，这里必须要把一个完整的报文从 origin_str 中给去掉。

这里不理解的可以看上面我们当时在写 protocol 之前的测试，我们读到的字符串是一直在增加的，如果出现粘包问题，不将完整的报文去除掉，是会出问题的。

那么经过 Unpack 函数的调用后，我们就能拿到一个完整的 jsonstr，那么下面我们就要对这个客户端传来的请求进行处理了，所以我们下面的思路就是解析客户端传来的请求，那么在实现该功能之前我们先来捋顺一下思路：

因为服务端只负责 IO 工作，所以对于解析客户端请求的工作肯定是不能交给服务端来完成的，所以这里我们让服务端将该工作交给其他人去完成，即通过 function 来完成函数的回调工作。

而我们将回调的函数返回值设置为 string，参数也设置为 string，返回值返回的就是我们未来要发给客户端的结果，而传进去的参数就是通过 Recv 读取到的字符串。

那么下面我们就来实现一下该回调函数：

这里我的做法是单独再创建一个 Parser 类来处理客户端的请求，里面的 Parse 函数就是用来完成该工作的。

上面实现的思路我也通过注释进行了说明，这里单独说一下最后为什么不直接将处理后的结果发给客户端而是要进行打包：

因为客户端未来也要从缓冲区中去读取服务端发来的数据，也同样会面临和服务端一样的半包问题和粘包问题，所以为了使客户端能够得到完整的结果，所以我们要对其进行打包，未来客户端也要执行和服务端一样的思路来保证报文的完整性。

上面我们也看到了，我们的解析工作中还缺少了处理客户端请求的工作，所以下面我们就要来实现该功能：

这里**我的做法是创建一个 Calculator 类，在这个类中实现 Exec 函数来完成上面的工作，这里的逻辑也很简单，通过判断 req 对象中的运算符，通过 switch 语句就可以完成上面的工作，这里我只实现了常见的 +, -, , /, % 五种运算。*

当然，为了让该模块与 Parser 模块关联起来，我们要对 Parser 类做一些调整：

3.2.5 客户端代码 (Client.cc) 和服务端代码 (Main.cc) 的实现

下面我们先在 Main.cc，即服务端代码中将各个模块整合起来：

上面就是未来我们运行服务端的完整代码了，通过将服务器，Parser，Calculator 这三个模块关联起来，我们就可以完成与客户端建立连接，解析客户端请求，处理客户端请求的全部工作了。

上面服务端的代码写完了，下面我们就来看看客户端的代码该怎么写吧：

上面就是客户端的完整代码，客户端中需要用到的一些额外的函数我都已经放在了上面，这些函数没什么难度，就不多讲了。

在实现客户端代码的过程中我们操作的可以看着下面这张图来一步一步进行：

这张图我们在最上面是见过的，按照这张图的顺序我们就能顺利地把客户端要做的事给顺下来。

那么所有工作已经准备就绪，下面我们就来看看我们实现的网络版计算器的实践效果：

从结果中可以看到网络计算器的功能已经实现了，包括除 0 问题等特殊情况我们也可以通过打印出来的_code 来判断结果正确与否。