0 前言

应用程序之间要想相互通信，一起配合来实现业务性能，还需传输协定反对。

传输协定就是应用程序之间对话的语言。设计传输协定，并无太多标准和要求，只需通信单方的应用程序都能正确处理该协定 && 无歧义。

1 断句

1.1 分隔符

传输协定也是种语言，传输数据时，首要解决的就是断句。

对传输层，收到的数据是怎么的？

就是一段段的字节，但因网络不确定性，你收到的分段并不一定是生产者收回去的分段。

那在协定中也加上“标点符号”不就行？

而且，并不需要像自然语言中那么多种的标点符号，而只需定义一个分隔符即可。

这方法确实可行，很多传输协定就采纳这种办法，比方 HTTP 1.0 协定，它的分隔符是换行（\r\n）。但这有个问题：自然语言中，标点符号是专用的，它没有别的含意，和文字人造辨别。
但在数据传输过程，无论你定义什么字符作为分隔符，实践上都有可能会在传输的数据中呈现。

那如何辨别“数据内的分隔符”和真正的分隔符？

得在发送数据阶段，加上分隔符前，把数据内的分隔符 本义 ，收到数据后再 本义 回来。
这确实是个麻烦过程，损失了一些性能。

1.2 预置长度

更加实用的办法。

给每句话后面加一个示意这句话长度的数字，收到数据时，按长度读。

如：03 下雨天 03 留客天 02 天留 03 我不留
这里固定应用 2 位数字寄存长度，每句话最长可反对 99 个字。接管后的解决就简略了，先读取 2 位数字 03，晓得接下来 3 个字是第一句话，那就等这 3 个字都收到，即可作为第一句话，同理读第二句话、第三句话。

这很好解决断句问题，实现比分隔符办法更简略，性能也更好，是广泛采纳的分隔数据的办法。

redis 的 aof 文件如同就是前置长度哦，经典计划无处不在~

前置长度是不是也有相似问题呢，03 也可能是失常文字里的内容，也是要本义吧？

你能够想一下，最好本人实现一下接收数据进行解析的代码，你就会明确，前置长度无需本义。因为解析时，可明确晓得以后读到的这个地位应该是长度还是真正数据，它不须要依据数据流中的内容来确定。

2 双工收发

2.1 单工通信

任一时刻，数据只能单向传输，一个人说时，另一个人只能听。
HTTP 1.0 协定就是这样，客户端与服务端建设个连贯后，客户端发个申请，直到服务端返回响应或申请超时，这段时间内，这个连贯通道上不能再发其余申请。

这种单工通信，效率低，很多浏览器和 APP 为解决性能问题，只能同时在服务端和客户端间创立多条连贯。

单工通信时，一句对一句，申请和响应按序顺次收发，有个人造对应关系。就像被女朋友质问时，女朋友问一句，你才敢答一句。这沟通效率有何意义？

2.2 双工通信

而 TCP 连贯是全双工通道，可同时进行数据的双向收发，互不影响。要进步吞吐量，应用层协定必须反对双工通信。

双工通信，不论是客户端还是服务端建设好连贯后，单方都能基于该 socket 进行收发音讯，而不是服务器只能 accept 到 message 后能力做些解决。

如果说你和你对象有边听边说的本事，换成双工协定后，根本就是在和女人讲道理，你们就会凌乱到分不清到底在答复问题 or 陈说观点。
并发下，程序也无奈保障。理论设计协议时，个别不关怀程序，只需确保申请和响应可能正确对应。

解决对应问题

发送申请时，给每个申请加个序号：该序号在本次会话内保障惟一，而后在响应中带上申请的序号，这就能把申请和响应对应上。

加上序号后，即便如抢答个别凌乱，也分得清到底在说啥。

你和你对象就能对本人收回去的申请来编号，回复对方响应的时候，带上对方申请的编号即可。这就解决了双工通信的次要问题。

在一次会话过程中，结尾的先是惟一序列号吗？而后前面跟数据长度，再是内容吗？
那接到音讯的一方，如何分辨序列号的长度大小，做到区分序列号和内容前的数据长度信息？

结尾就必定是数据长度，序号也是数据的一部分！所以应该在数据长度的前面。

3 总结

设计传输协定时，只有单方应用程序可能辨认传输协定，相互交换即可，并没啥相对的标准。

首要得解决断句，有“分隔符”和“前置长度”两种断句计划。

应用 ID 来标识申请与响应对应关系的办法，是比拟通用的实现双工通信的办法，可无效晋升数据传输的吞吐量。

解决了断句，实现了双工通信，配合专用序列化办法，即可实现高性能的网络通信协定，实现高性能的过程间通信。很多 MQ、RPC 框架都是用这种形式来实现它们本人的公有应用层传输协定。

简略的高性能通信程序：你和你对象三组对话，服务端是你对象，客户端是你本人，让俩人在客厅碰见一百万次，记录下总共耗时。

https://github.com/WangYangA9…
https://sourcegraph.com/githu…