从零自定义网络协议：应用层协议设计与数据格式选型

七星-落凡

墨衍会员 · AI 创作全网分发码龄1年

关注

原创 2026-09-22 10:10:35 208 阅读 AI 写同款· GEO 优化 ›

对网络协议栈（HTTP/HTTPS/TCP）的理解阅读详情

在前文的网络初识一文中我们知道，在 TCP/IP 五层协议中，应用层是我们程序员打交道最多的层次。我们程序员写的代码，只要涉及到网络通信，都可以视为应用层的一部分。应用层涉及到的网络通信协议，很多也都是程序员自定义的。

那么，我们要如何自定义一个网络通信协议呢？以下，我们就来聊聊这个话题

一. 自定义协议的步骤

1.根据需求，明确要传输的信息

我们在自定义一个网络通信协议时，第一步就是要思考我们要通过这个协议传输哪些信息。

就以外卖软件为例，当我们作为一个客户端去搜索我们周围的外卖商家时，我们这个搜索的行为会向服务器传输哪些信息呢？经过思考我们可以知道，我们这个请求可能传输的信息有：我们的位置信息（用来检索周围商家）、我们的用户id（确定是我们这个用户下的单）等信息

在接收到我们这个请求时，服务器也会做出相对应的响应。那么，这个响应中又可能传输有哪些信息呢？经过思考我们不难得知，可能传输的信息有：商家id、商家名称、商家评分、配送费用和商品类型分类等等。当然，这个响应中也可能包含有多个商家信息

2. 根据要传输的信息，约定好组织信息的格式

在我们知道了要传输的信息有哪些了之后，我们就要去思考应该用什么格式去组织这些信息。在网络编程中有很多方式来去组织信息，接下来我们就来介绍一些常见的组织方式

2.1 行文本的方式组织信息

仅由文字、换行、空格等基础字符构成，靠换行区分各行内容，是最简单原始的信息存储载体

例如上面的外卖例子用行文本的方式进行组织信息，结果就可能如下所示

商家id，商家名称，商家图片，商家评分，配送费用，商品类型\n

商家id，商家名称，商家图片，商家评分，配送费用，商品类型\n

...................

商家id，商家名称，商家图片，商家评分，配送费用，商品类型\n

\n

这就是通过行文本的方式来组织信息时可能出现的结果

注：在行文本信息中最后一行是 “ 空行 ”，用来区分不同的行文本数据

2.2 通过 xml 格式来约定请求和响应的数据

xml 和 html 类似（HTML 是“网页展示语言”，不是“通用数据交换格式”，在本文不予展示），都是由成对的标签构成的键值对结构。但二者也有不同点，就是 html 的标签的内容都是已经固定好的，你不能使用或创造不存在的标签（在 html5 中已经允许自定义标签），而在 xml 中的标签内容则是自定义的

例如上面的外卖例子用行文本的方式进行组织信息，结果就可能如下所示

<shopList>

        <shop>

                <shopId>1001</shopId>

                <shopName>川味麻辣烫</shopName>

                <score>4.7</score>

                <deliveryFee>3</deliveryFee>

                <goodsType>麻辣烫、小吃</goodsType>

        </shop>

        <shop>

                <shopId>1002</shopId>

                <shopName>鲜榨果茶</shopName>

                <score>4.9</score>

                <deliveryFee>2</deliveryFee>

                <goodsType>奶茶、甜品</goodsType>

</shop>

        <shop>

                <shopId>1003</shopId>

<shopName>家常小炒馆</shopName>

                <score>4.5</score>

                <deliveryFee>0</deliveryFee>

                <goodsType>中餐、盖饭</goodsType>

        </shop>

</shopList>

优点：可读性强

缺点：存在大量的冗余信息，在网络传输中会消耗更多的带宽

2.3 json 格式组织信息

由于在 xml 方式中存在有很多重复的标签信息，这也带来了更多的带宽消耗。为了节省带宽，大佬们又发明了 json 这个组织信息的格式

json 格式：使用大括号{} 包裹对象，键值对存储信息，中括号[] 存放数组，数据层级清晰，仅用逗号分隔内容，无多余标记

[

        {

                "shopId": 1001,

                "shopName": "川味麻辣烫",

"score": 4.7,

                "deliveryFee": 3,

                "goodsType": "麻辣烫、小吃"

        },

        {

                "shopId": 1002,

"shopName": "鲜榨果茶",

                "score": 4.9,

                "deliveryFee": 2,

                "goodsType": "奶茶、甜品"

        },

        {

                "shopId": 1003,

                "shopName": "家常小炒馆",

                "score": 4.5,

                "deliveryFee": 0,

                "goodsType": "中餐、盖饭"

        }

]

优点：可读性比较强，消耗的带宽也比 xml 少

缺点：还是存在冗余信息

2.4 protobuf 格式组织信息

protobuf 组织信息的格式是基于二进制的格式对数据进行压缩，这也就不会涉及到上文的 xml 、json 格式中所存在的冗余信息了。所以，protobuf 格式消耗的带宽是最少的，为了达到这个效果，由 protobuf 格式组织的信息的可读性就变差了（适用于高性能场景下的使用）。

四种信息组织格式的优缺点如下图所示

在应用层中，除了我们自定义的协议之外，也有着一些大佬做出的通用的协议，比如：

FTP 文件传输协议、SSH 远程操作主机协议、telnet 网络调试工具协议和 HTTP 协议等待

自定义一个网络通信协议，本质上就两步：先明确要传输哪些信息，再约定用什么格式组织这些信息。信息决定了协议能表达什么，格式决定了传输效率和解析难度。在本文中介绍的四种信息组织格式各有取舍，所以，格式选型没有绝对的好坏，只有是否适合当前业务。内部服务、高并发场景可以优先考虑 Protobuf；前后端交互、调试频繁的场景用 JSON 更合适；配置文件、老系统兼容可以选 XML；而临时测试、极简协议用行文本就够了。

另外，HTML 虽然也能组织信息，但它的标签是固定的，且包含大量展示逻辑，更适合网页渲染，不适合作为通用的数据传输格式。

理解了应用层协议的设计思路后，下一篇我们将进入最常用的应用层协议——HTTP协议，看看它是如何规定请求与响应的报文格式的

收录于