1.几种常见的源码长连接实现方案
2.uniapp app端 + cesium + mars3d 开发指北 （四）
3.深入理解 IPFS - DHT 网络（1）

几种常见的长连接实现方案

       长连接的概念涉及多个领域，包括HTTP持久连接、解读TCP、源码UDP、解读QUIC、源码WebSocket等协议。解读ftp传输源码它们共同建立的源码是一个数据通路，可以持续收发信息。解读其中，源码微信在年开源的解读Mars项目，因其在长连接架构中的源码应用而广为人知。Mars作为客户端，解读还需要与服务端配合使用。源码

       国内大厂的解读网关团队普遍提供了长连接服务。这些服务包括消息推送、源码消息广播、多协议切换、HTTP代理、博易三级买卖指标源码多接入点容灾等功能，适用于即时通讯、弹幕、互动游戏、竞拍等多种业务场景。大厂如阿里的ACCS和美团的Shark等，提供了相关功能的公开资料。

       长连接主要解决数据的实时性问题。首先，它解决了数据推送的问题。例如，通过手机厂商提供的离线消息推送通道，实现APP与厂商服务的连接，确保消息在APP后端发送后，能迅速推送给用户。其次，长连接优化了API请求，第四方支付php源码尤其是在国内网络质量良好的情况下，代理HTTP(S)请求是性价比较高的方案。移动端网络库中添加拦截逻辑，将请求参数封装成底层报文，通过全双工数据通路发送给网关，网关组装为HTTP请求，内网发送给业务服务器，最后封装后回传至对应数据通道。

       一个完整的HTTPS请求步骤涉及多个环节，任何环节的错误都可能导致请求失败。例如，DNS污染、解析错误、慢响应、山区或海外用户导致的数据包往返延迟、握手过程复杂、证书过大、第三方聊天软件源码超时配置不合理、包过小导致慢启动等。以RTT为ms为例，采用TCP+TLS 1.2建立连接需要至少ms，打开TLS会话复用需要ms，采用TCP+TLS 1.3首次请求ms即可连接，复用为ms，QUIC协议首次为ms，复用为0ms。在弱网环境下，RTT可能更差，协议优化能带来更好的响应速度。

       本文是长连接技术方案的上篇，详细介绍了公开的业界长连接技术。下篇将探讨如何根据业务需求选择合适的长连接技术方案。目前，我们已经实现的第三方入住平台源码长连接方案已完全开源，欢迎获取所有源代码。

uniapp app端 + cesium + mars3d 开发指北 （四）

       在uniapp中利用Cesium和Mars3D开发时，有人提到通过npm包引入Cesium是最便捷的方法。动态引入的优点在于提升编译速度，这也是uni官方推荐的方式。然而，直接从`node_modules`导入时，可能会遇到控制台报错的情况，尽管理论上可以运行，但实际操作中需要解决这个问题。

       首先，通过`npm install cesium --save`安装Cesium包，然后按照npm上的示例进行项目引入。在尝试运行项目时，会遇到报错。查看源码发现，报错可能与缺少`CESIUM_BASE_URL`这个全局变量有关。由于uniapp自动获取路径语法出错，我们需要手动设置这个变量，指向Cesium的静态资源文件夹。

       源码中提供了`setBaseUrl`这个API，用于设置静态资源路径。根据Cesium的逻辑，我们需要设定一个指向导入Cesium源码文件夹的路径。这样，即使uniapp自动获取路径功能出问题，我们也能确保Cesium正确加载所需的资源。

       实测发现，有两种导入方式都能成功：一种是直接import引入并设置Cesium跨域和replaceAll的polyfill。这样，Cesium在uniapp的app端能正常渲染和运行。

       总的来说，虽然直接import引入Cesium需要额外注意跨域和polyfill的设置，但通过正确的路径配置，这一方式在uniapp app端开发中是可行的。

深入理解 IPFS - DHT 网络（1）

       深入理解 IPFS - DHT 网络（1）

       在探讨 IPFS 架构时，DHT（分布式哈希表）扮演着关键角色。本篇文章将从应用、原理两个角度深入剖析 DHT 网络。

       在 IPFS 网络层中，源码位于 libp2p。利用 go-libp2p 进行分析。

       假设两个节点，分别为 earth 和 mars，各自加入 DHT 网络。随后，他们需找到对方并互相发送消息。

       （一）节点初始化

       初始化节点仅需一行代码：libp2p.New()。自定义参数如监听地址与端口号 /ip4/.0.0.1/tcp/，相当于 .0.0.1:，但自解释性更强。通过 /ip4/1.2.3.4/tcp//p2p/QmcEPrat8ShnCph8WjkREzt5CPXF2RwhYxYBALDcLC1iV6，可以看到 PeerId QmcEPrat8ShnCph8WjkREzt5CPXF2RwhYxYBALDcLC1iV6，不仅通过 IP+端口寻址，通过 PeerId 也能直接定位到节点。

       初始化后，生成节点，ID 以 btcencode 编码，即 QmcEPrat8ShnCph8WjkREzt5CPXF2RwhYxYBALDcLC1iV6，即上文提及的 PeerID。完成初始化后，配置 端口的 handler。

       handleStream 函数实现类似于普通 socket 编程，读写数据即可。

       （二）加入 DHT 网络

       节点建立完成后，加入 DHT 网络是接下来的关键步骤。无论在比特币、以太坊还是早期的 BT 网络中，新节点加入网络时都需要种子（bootstrap）节点作为起点，扩展自己的路由表。

       （三）广而告之

       回到开头场景，假设初始化节点名为 mars，加入 DHT 网络后，需要向所有节点宣布自己是 mars 节点。

       原理将在下篇文章中深入分析。nodeName 转换为内容哈希，节点通过 Advertise 方法告知其他节点自己拥有此哈希，其他节点会更新路由表。当有请求查找此内容时，会告知拥有此内容的节点或更接近的节点。

       （四）寻找节点

       FindPeers 实现逻辑是寻找 earth 这个哈希地址，找到后建立双工连接，实现了服务端与客户端的通信。

       （五）演示

       （六）完善

       以上例子存在一个风险，任何节点都可声称自己是 mars 节点，通信双方难以信任。因此，适用于聊天室场景的这种模式。通过将内容寻址改为节点寻址，可找到可信的通信方，前提是已知要通信的节点 ID。

       以下是代码示例。