1.客户端消息数据的最新 seq 可能导致有些离线消息不能同步到客户端，解决方案：
服务端，把每一条客户端需要接收的消息，加 4 个字段：
消息接收时间（此条数据的产生时间）、消息同步到客户端的时间、客户端确认已收到该消息的时间、客户端已阅读该消息的时间。

2.可靠投递的实现方式，是客户端以分布式事务的方式，从服务端获取消息。事务执行成功，则更新上述 4 个字段中的某个字段。你可以直接找个分布式事务的组件来用就行。

3.大量消息的优化投递方式：批量投递 + 分批投递 + 每批压缩。

4.你要做企业级 IM ，请拒绝 UDP ，因为很多企业级防火墙与网管，把 UDP 传输无脑当攻击。

@detached
站在工作分工与快速入门的角度来看，您说的很对。

但如果是站在学习的角度，想学地透彻，就需要去学习其发展史，需要学习底层的构成，需要了解其上层的发展、应用与案例。

举个简单的例子，java 程序员，去学习如何操作文件。从您的角度来说，去谷歌一下 java 文件 io 的相关例子与代码，就能学懂。但是，当 java 同时操作海量文件时，当 java 操作不同设备上的文件时，当 java 通过不同渠道操作文件时，当 java 绕着地球一圈操作文件时，所产生的的各种性能问题、各种错误问题，要分析这些问题，如何产生，能否解决，如何解决，各种解决方案的代价如何，这就不仅仅只是 java 这一门课程能学到的。

@hello2090 举一个例子，程序运行的性能问题，是如何产生的。

如果你不懂数学，给你 RSA 、DES 、MD5 等加密解密与哈希算法的代码，你是看不懂的。代码，只是实现数据结构与控制流程的方法，至于为啥要设计这种数据结构、为啥要用这种流程，它与协议以及更底层的知识相关。比如驱动里的一些缓存大小、循环间隔时间，它与下层电路逻辑有关。

所以，你要学懂某一层次的东西，可能需要掌握其上层或下层的知识才行。

到此，有两种学习方式，一种是学院派的至下而上，比如 数学 + 物理 -> 模拟电路 -> 数字电路 -> 组成原理 -> 汇编语言 -> C/C++ -> 操作系统，另一种是自上而下，比如以某种编程语言为主，来教你网络编程的书籍。两种学习方法各有优缺点，选择你喜欢的方式就好。

漏洞是防不了的，只能等补丁来修复。

计算机有很多分类，就拿大家都熟悉的前端与后端这两个分支来说，建议去找找这两个分支的知识树，你会发现，它下面还有及其庞大的子分支，而且每个子分支，其包含的知识量，与再分的分支，都有可能会让人耗尽一生的精力去研究，去改良，去创新。

每个人的时间都有限。有些人在你关心的分支上，只了解皮毛，但他却可能在你不感兴趣的方向，有很深的建树。还有些人，可能在每个分支，都只是浅尝辄止，但他关注的是知识分支的数量，而非深度，这类人你也不能说他不行，因为有些项目管理之类的岗位，恰好是需要这类人去协调各种专门的技术岗位。

低功耗 NAS 设备，那是上个世纪的事情了。

自从有了 WIFI 插座与 WIFI 开机卡，NAS 的装机思路完全变了。

现在讲究是，高性能，虽然高功耗，但高性能意味着能在更短时间内完成任务，然后用 WIFI 设备进行控制开关，实现用的时候远程开机，用完手动关闭或自动关闭设备。

而且，如果只是需要挂载一个硬盘，甚至有很多便宜的硬路由都有这功能，完全不需要多功能的 NAS 了。

楼主可能不太明白，就算在商业上，除了那种大于几十万的定制项目之外，小于这个金额的，乙方要求甲方保留开发公司的信息，都可能是一件比较困难的事情。甚至很多几万块的通用型软件，甲方很有可能会问一下，能不能改 logo 并且替换或删除开发公司信息。

你这开源作品，在那些人的眼里，和送钱是没区别的。和他们谈这些规则，就像对牛弹琴。

而且你拿 MIT 与 github ，去国内法院起诉，也是一件为难法官的事情。

你的出发点没问题，只是目前你的诉求，超出了当前国内的现状。建议，你如果能调整自己的心态，就继续开源，否则就闭源。

@chutsetien MediaWiki 的编辑器的 parsoid ，从长期服务版、老版本、最新版，都有问题。安装包与 docker 版本都存在相同的问题。去年 9 月份测的，现在新版本不知道改正了没。

分析历史协议的制定，要考虑当时的主流设备与经济情况。

现在内存便宜，各种网络设备，以及网卡，都能以很便宜的成本，缓存大容量的数据。

但以前不是这个情况，那时候内存死贵，因此大家才愿意牺牲时间，来换取更低成本。因此，等待与重传剩余所有数据，在那个时期，比缓存且仅重传失效数据，在经济价值上要好的多。

这个话题就像千年虫问题一样。其实直接用动态长度的时间变量，能够一次性彻底解决千年虫问题，但经济成本太高了，因为变长的变量，在存储与运算代价，要高于定长变量好几倍，这个问题在很多低成本的小型硬件上影响更大。所以，业界解决千年虫的方案，只是把 32 位变量换成 64 位变量了，虽然能用很长的时间，并且在经济上很划算，但却是治标不治本的方案。

多角度扬声的专业术语叫环绕声，主流的有 5.1 声道 或 7.1 声道。

目前 7.1 声道最经济的实现方案，并不在笔记本上，而是在台式机上。以前大部分的 ATX 大主板，7.1 环绕声的支持都是标配，自带 4 路 3.5mm 音频输出。这类主板现在淘宝二手拆机大概 200 多元价位。然后买一个 100 元以内的低频音箱，加上 3 对每对约 30 元以内的 USB 小音箱，加上音频延长线材与插排，不到 300 元就能体验入门版的 7.1 声道。

如果是笔记本方案，真正支持 4 输出的外置专业声卡，基本上 2 千元起步。这类声卡主要的成本，是超低延迟音频 DSP 、带有幻象电源来支持专业电容话筒，你只为了 7.1 声道来买这种声卡，有点像是为了吃蛋筒而买一个蛋卷冰激凌，浪费钱。

个人觉得 7.1 声道的最好体验，并不是各种蓝光电影大作，而是 COD 之类的 3A 游戏。这类游戏配上专业的 7.1 环绕声，才是完整体验。这也是为什么很多人用笔记本玩 3A 游戏，觉得 3A 游戏也不过如此的重要原因之一。因为 3A 游戏的完整体验，是需要一套家庭影院的设备，包括独立的听音室、遮光窗帘、超大屏幕、7.1 音响设备，这才能把宏伟壮丽的画面与全方位震撼的声音完全体现出来。没有这套东西，3A 游戏就只是个手机游戏。

但正因为现在房价居高，你又不可能在高层住宅里弄一套拆家音量的扰民听音设备，因此能完整用上这一套东西的，至少也要是市内联排别墅，或郊区独栋。但拥有这种经济条件的人，一般也没时间折腾这些东西。

其实一个简单的二级网络 + 全局 VPN 代理，就可以轻松破解掉现在 所有 的行为分析，对，你没看错，我写的是所有。

二级网络的意思是，需要安装认证软件的机器上，装两个网卡。连接公司网络的网卡为外网网卡，另一个内网网卡连接交换机，交换机再连接一台内网机器，需要做一位违规事情的应用，放在内网机器上，内网机器用 VPN 开全局代理。

当然，这样做也是有弊端的：
1.很多基于底层网络协议，以及 UDP 协议，可能会被行为分析大幅度降低性能，甚至会被阻断。只有 TCP 才能畅通无阻。

2.内网机器的大部分性能可能会被用于 VPN 的加密解密。VPN 对端的机器也是如此。

@zhea55
你的方案只适合那种没部署安全设备的公司，也就是公司网管偷了懒，用家用设备来部署公司网络。

很多大企业，网络出口部署了各种防火墙、入侵检测，导致 p2p 打洞、甚至 UDP 内网传输都会被当做攻击，被挡住，这种场景下只能走最原始的 tcp 连接 + VPN 公网服务器中转才能打通连接，凡是基于 p2p 与 UDP 的方案全部失效。

这就是为啥很多人说 zerotier 之类的不好用或不通的原因。

C++也是分等级的。

普通 QT 那种 C++，看一本 C++的书，再去看 QT 的例子，然后基于谷歌解决问题，感觉也够了。数据库，用各种框架加谷歌现成的 SQL 例子，网络通信有 grpc 等各类组件，当个 API 调用师，躺赢即可。

中级 C++，需要懂一些数据结构与算法。

高级 C++，需要懂 OS 、网络通信、数据库的一些基本原理。

顶级 C++，需要懂一些底层的知识，从组成原理开始，到汇编、到各种 CPU 的一些特定比如频率、指令集等等。

超纲 C++，需要学一下底层电路的知识，能加深对性能的理解。

以上这些知识，都有书籍。建议用关键字去知乎和豆瓣搜，书我就不推荐了，因为书的种类很多，我推荐的书的写作风格，不一定适合你。有些朋友甚至喜欢去看视频教程。

其实就是一个简单的经济学原理：

1.以前的情况是，IT 行业对外服务的从业者人数少，边际效用作用强，因此每一个服务对于从业者而言收益极高。

行业内岗位供不应求，同时行业门槛极高，因此才造成连续好几年的行业普遍高薪。

2.后来各种大学、专科、培训班，瞅准这个机会，大批量制造从业者，导致整个供应关系倒转，从而上述的情况反转。

1.初学别发文件，也别发字符串，而是发一个长度为 16 或 32 的 byte array ，方便你调试、对比与检查。

2.发送前，把要发送的内容，全部先装入一个完整的 byte array 里。

3.发送端，一个一个字节地发送。接收端，一个一个字节地接受。使用调试模式，单步运行，收到一个字节，就对比一下。

这样子，问题在哪，你就能自己找出来了。

数组发送没问题后，再来说说文件。

接收端，别单方面进行接受，而是，需要发送的文件，在接收端，也存一份。然后还是一个一个字节地收发，接收端，收到一个字节，就拿去和文件对比。当接收到不一样的字节时，那个代码位置，下个断点，进行调试，看看发生了什么问题。

上面的事情都解决后，恢复成正常 buffer 收发。你甚至可以用超大 buffer 来提高性能。

1.阿里云操作 API ，所以内网还是外网，与这个没关系。

2.VPN 组网也能实现。

你这么在乎 10T 小姐姐，却连个 raid 与备份都没有嘛？