Jack Jiang

我的最新工程MobileIMSDK:http://git.oschina.net/jackjiang/MobileIMSDK
posts - 147, comments - 13, trackbacks - 0, articles - 0

2018年5月7日

     摘要: 1、引言老读者应该还记得我在去年国庆节前分享过一篇《技术干货:从零开始,教你设计一个百万级的消息推送系统》,虽然我在文中有贴一些伪代码,依然有些朋友希望能直接分享一些可以运行的源码。好吧,质疑我穷我无话可说(因为是真穷。。),怀疑我撸码的能力那是绝对不行,所以这次准备拉起键盘大干一场——徒手撸套分布式IM出来!^_^!本文记录了我开发的一款面向IM学习者的 IM系统R...  阅读全文

posted @ 2019-10-14 22:49 Jack Jiang 阅读(41) | 评论 (0)编辑 收藏

     摘要: 本文为开源实验性工程:“github.com/GuoZhaoran/spikeSystem”的配套文章,原作者:“绘你一世倾城”,现为:猎豹移动php开发工程师,感谢原作者的技术分享。1、引言Go语言的出现,让开发高性能、高稳定性服务端系统变的容易,与高贵冷艳的Erlang语言不同的是,Go语言简单易学,在高性能服务端架构中的应用越来越广泛。对于即时...  阅读全文

posted @ 2019-10-12 14:46 Jack Jiang 阅读(18) | 评论 (0)编辑 收藏

     摘要: 0、引言站长提示:本文适合IM新手阅读,但最好有一定的网络编程经验,必竟实践性的代码上手就是网络编程。如果你对网络编程,以及IM的一些理论知识知之甚少,请务必首先阅读:《新手入门一篇就够:从零开发移动端IM》,该文为IM小白分类整理了详尽的理论资料,请按需补充相关知识。配套源码:本文写的比较浅显但不太易懂,建议结合代码一起来读,文章配套的完整源码 请从本文文末 “11、完整源...  阅读全文

posted @ 2019-10-09 14:49 Jack Jiang 阅读(152) | 评论 (0)编辑 收藏

     摘要: 原文来源:51CTO技术栈公众号,本文原题:NoSQL还是SQL?这一篇讲清楚,收录时有修订和改动。1、引言随着互联网大数据时代的到来,越来越多的网站、应用系统都需要支撑大量甚至海量数据存储,同时还伴有高并发、高可用、高可扩展等特性要求。很多时候,传统的关系型数据库在应付这些已经显得力不从心,并暴露了许多难以克服的问题。由此,各种各样的 NoSQL(Not Only SQL)数据库作为传统关系型数...  阅读全文

posted @ 2019-09-26 14:16 Jack Jiang 阅读(26) | 评论 (0)编辑 收藏

     摘要: 本文来自美团技术团队“照东”的分享,原题《Leaf——美团点评分布式ID生成系统》,收录时有勘误、修订并重新排版,感谢原作者的分享。1、引言鉴于IM系统中聊天消息ID生成算法和生成策略的重要性(因为某种意义上来说:聊天消息ID的优劣决定了IM应用层某些功能实现的难易度),所以即时通讯网近期正在着重整理有关IM中的聊天消息ID算法方面的文章,包括微信团...  阅读全文

posted @ 2019-09-23 16:25 Jack Jiang 阅读(25) | 评论 (0)编辑 收藏

     摘要: 本文来自融云技术团队原创分享,原文发布于“融云全球互联网通信云”公众号,原题《如何实现分布式场景下唯一 ID 生成?》,即时通讯网收录时有部分改动。1、引言对于IM应用来说,消息ID(或称序列号)是个看似不起眼,但非常重要的东西之一。消息ID的使用贯穿了IM技术逻辑的方方面面,比如:1)聊天消息的顺序保证;2)聊天消息QoS送达保证机制时的去重;3)特定聊天消息的精确查找和...  阅读全文

posted @ 2019-09-19 17:40 Jack Jiang 阅读(16) | 评论 (0)编辑 收藏

     摘要: 本文来自融云技术团队原创分享,原文发布于“ 融云全球互联网通信云”公众号,原题《IM 即时通讯之链路保活》,即时通讯网收录时有部分改动。1、引言众所周知,IM 即时通讯是一项对即时性要求非常高的技术,而保障消息即时到达的首要条件就是链路存活。那么在复杂的网络环境和国内安卓手机被深度定制化的条件下,如何保障链路存活呢?本文详解了融云安卓端IM产品在基于 TCP 协议实现链路保...  阅读全文

posted @ 2019-09-17 11:15 Jack Jiang 阅读(20) | 评论 (0)编辑 收藏

     摘要: 本文原作者:selfboot,博客地址:selfboot.cn,Github地址:github.com/selfboot,感谢原作者的技术分享。1、引言对于 DNS(Domain Name System) 大家肯定不陌生,不就是用来将一个网站的域名转换为对应的IP吗。当我们发现可以上QQ但不能浏览网页时,我们会想到可能是域名服务器挂掉了;当我们用别人提供的hosts文件浏览到一...  阅读全文

posted @ 2019-09-09 15:41 Jack Jiang 阅读(29) | 评论 (0)编辑 收藏

本文来自知乎官方技术团队的“知乎技术专栏”,感谢原作者faceair的无私分享。

1、引言

实时的响应总是让人兴奋的,就如你在微信里看到对方正在输入,如你在王者峡谷里一呼百应,如你们在直播弹幕里不约而同的 666,它们的背后都离不开长连接技术的加持。

每个互联网公司里几乎都有一套长连接系统,它们被应用在消息提醒、即时通讯、推送、直播弹幕、游戏、共享定位、股票行情等等场景。而当公司发展到一定规模,业务场景变得更复杂后,更有可能是多个业务都需要同时使用长连接系统。

业务间分开设计长连接会导致研发和维护成本陡增、浪费基础设施、增加客户端耗电、无法复用已有经验等等问题。共享长连接系统又需要协调好不同系统间的认证、鉴权、数据隔离、协议拓展、消息送达保证等等需求,迭代过程中协议需要向前兼容,同时因为不同业务的长连接汇聚到一个系统导致容量管理的难度也会增大。

经过了一年多的开发和演进,经过我们服务面向内和外的数个 App、接入十几个需求和形态各异的长连接业务、数百万设备同时在线、突发大规模消息发送等等场景的锤炼,我们提炼出一个长连接系统网关的通用解决方案,解决了多业务共用长连接时遇到的种种问题。

知乎长连接网关致力于业务数据解耦、消息高效分发、解决容量问题,同时提供一定程度的消息可靠性保证。

(本文同步发布于:http://www.52im.net/thread-2737-1-1.html

2、相关文章

3、我们怎么设计通讯协议?

3.1 业务解耦

支撑多业务的长连接网关实际上是同时对接多客户端和多业务后端的,是多对多的关系,他们之间只使用一条长连接通讯。

 

这种多对多的系统在设计时要避免强耦合。业务方逻辑也是会动态调整的,如果将业务的协议和逻辑与网关实现耦合会导致所有的业务都会互相牵连,协议升级和维护都会异常困难。

所以我们尝试使用经典的发布订阅模型来解耦长连接网关跟客户端与业务后端,它们之间只需要约定 Topic 即可自由互相发布订阅消息。传输的消息是纯二进制数据,网关也无需关心业务方的具体协议规范和序列化方式。



3.2 权限控制

我们使用发布订阅解耦了网关与业务方的实现,我们仍然需要控制客户端对 Topic 的发布订阅的权限,避免有意或无意的数据污染或越权访问。

假如讲师正在知乎 Live 的 165218 频道开讲,当客户端进入房间尝试订阅 165218 频道的 Topic 时就需要知乎 Live 的后端判断当前用户是否已经付费。这种情况下的权限实际上是很灵活的,当用户付费以后就能订阅,否则就不能订阅。权限的状态只有知乎 Live 业务后端知晓,网关无法独立作出判断。

所以我们在 ACL 规则中设计了基于回调的鉴权机制,可以配置 Live 相关 Topic 的订阅和发布动作都通过 HTTP 回调给 Live 的后端服务判断。



同时根据我们对内部业务的观察,大部分场景下业务需要的只是一个当前用户的私有 Topic 用来接收服务端下发的通知或消息,这种情况下如果让业务都设计回调接口来判断权限会很繁琐。

所以我们在 ACL 规则中设计了 Topic 模板变量来降低业务方的接入成本,我们给业务方配置允许订阅的 Topic 中包含连接的用户名变量标识,表示只允许用户订阅或发送消息到自己的 Topic。



此时网关可以在不跟业务方通信的情况下,独立快速判断客户端是否有权限订阅或往 Topic 发送消息。

3.3 消息可靠性保证


网关作为消息传输的枢纽,同时对接业务后端和客户端,在转发消息时需要保证消息在传输过程的可靠性。

TCP 只能保证了传输过程中的顺序和可靠性,但遇到 TCP 状态异常、客户端接收逻辑异常或发生了 Crash 等等情况时,传输中的消息就会发生丢失。

为了保证下发或上行的消息被对端正常处理,我们实现了回执和重传的功能。重要业务的消息在客户端收到并正确处理后需要发送回执,而网关内暂时保存客户端未收取的消息,网关会判断客户端的接收情况并尝试再次发送,直到正确收到了客户端的消息回执。



而面对服务端业务的大流量场景,服务端发给网关的每条消息都发送回执的方式效率较低,我们也提供了基于消息队列的接收和发送方式,后面介绍发布订阅实现时再详细阐述。

在设计通讯协议时我们参考了 MQTT 规范(详见《扫盲贴:认识MQTT通信协议》),拓展了认证和鉴权设计,完成了业务消息的隔离与解耦,保证了一定程度的传输可靠性。同时保持了与 MQTT 协议一定程度上兼容,这样便于我们直接使用 MQTT 的各端客户端实现,降低业务方接入成本。

4、我们怎么设计系统架构?

在设计项目整体架构时,我们优先考虑的是:

  • 1)可靠性;
  • 2)水平扩展能力;
  • 3)依赖组件成熟度;
  • 4)简单才值得信赖。


为了保证可靠性,我们没有考虑像传统长连接系统那样将内部数据存储、计算、消息路由等等组件全部集中到一个大的分布式系统中维护,这样增大系统实现和维护的复杂度。我们尝试将这几部分的组件独立出来,将存储、消息路由交给专业的系统完成,让每个组件的功能尽量单一且清晰。

同时我们也需要快速地水平扩展能力。互联网场景下各种营销活动都可能导致连接数陡增,同时发布订阅模型系统中下发消息数会随着 Topic 的订阅者的个数线性增长,此时网关暂存的客户端未接收消息的存储压力也倍增。将各个组件拆开后减少了进程内部状态,我们就可以将服务部署到容器中,利用容器来完成快速而且几乎无限制的水平扩展。

最终设计的系统架构如下图:
 

系统主要由四个主要组件组成:

  • 1)接入层使用 OpenResty 实现,负责连接负载均衡和会话保持;
  • 2)长连接 Broker,部署在容器中,负责协议解析、认证与鉴权、会话、发布订阅等逻辑;
  • 3)Redis 存储,持久化会话数据;
  • 4)Kafka 消息队列,分发消息给 Broker 或业务方。


其中 Kafka 和 Redis 都是业界广泛使用的基础组件,它们在知乎都已平台化和容器化 (详见:《Redis at Zhihu》、《知乎基于 Kubernetes 的 Kafka 平台的设计和实现》),它们也都能完成分钟级快速扩容。

5、我们如何构建长连接网关?

5.1 接入层

OpenResty 是业界使用非常广泛的支持 Lua 的 Nginx 拓展方案,灵活性、稳定性和性能都非常优异,我们在接入层的方案选型上也考虑使用 OpenResty。

接入层是最靠近用户的一侧,在这一层需要完成两件事:

  • 1)负载均衡,保证各长连接 Broker 实例上连接数相对均衡;
  • 2)会话保持,单个客户端每次连接到同一个 Broker,用来提供消息传输可靠性保证。


负载均衡其实有很多算法都能完成,不管是随机还是各种 Hash 算法都能比较好地实现,麻烦一些的是会话保持。

常见的四层负载均衡策略是根据连接来源 IP 进行一致性 Hash,在节点数不变的情况下这样能保证每次都 Hash 到同一个 Broker 中,甚至在节点数稍微改变时也能大概率找到之前连接的节点。

之前我们也使用过来源 IP Hash 的策略,主要有两个缺点:

  • 1)分布不够均匀,部分来源 IP 是大型局域网 NAT 出口,上面的连接数多,导致 Broker 上连接数不均衡;
  • 2)不能准确标识客户端,当移动客户端掉线切换网络就可能无法连接回刚才的 Broker 了。


所以我们考虑七层的负载均衡,根据客户端的唯一标识来进行一致性 Hash,这样随机性更好,同时也能保证在网络切换后也能正确路由。常规的方法是需要完整解析通讯协议,然后按协议的包进行转发,这样实现的成本很高,而且增加了协议解析出错的风险。

最后我们选择利用 Nginx 的 preread 机制实现七层负载均衡,对后面长连接 Broker 的实现的侵入性小,而且接入层的资源开销也小。

Nginx 在接受连接时可以指定预读取连接的数据到 preread buffer 中,我们通过解析 preread buffer 中的客户端发送的第一个报文提取客户端标识,再使用这个客户端标识进行一致性 Hash 就拿到了固定的 Broker。

5.2 发布与订阅

我们引入了业界广泛使用的消息队列 Kafka 来作为内部消息传输的枢纽。

前面提到了一些这么使用的原因:

  • 1)减少长连接 Broker 内部状态,让 Broker 可以无压力扩容;
  • 2)知乎内部已平台化,支持水平扩展。


还有一些原因是:

  • 1)使用消息队列削峰,避免突发性的上行或下行消息压垮系统;
  • 2)业务系统中大量使用 Kafka 传输数据,降低与业务方对接成本。


其中利用消息队列削峰好理解,下面我们看一下怎么利用 Kafka 与业务方更好地完成对接。

5.3 发布

连接 Broker 会根据路由配置将消息发布到 Kafka Topic,同时也会根据订阅配置去消费 Kafka 将消息下发给订阅客户端。

路由规则和订阅规则是分别配置的,那么可能会出现四种情况。

情况一:消息路由到 Kafka Topic,但不消费,适合数据上报的场景,如下图所示。



情况二:消息路由到 Kafka Topic,也被消费,普通的即时通讯场景,如下图所示。



情况三:直接从 Kafka Topic 消费并下发,用于纯下发消息的场景,如下图所示。



情况四:消息路由到一个 Topic,然后从另一个 Topic 消费,用于消息需要过滤或者预处理的场景,如下图所示。



这套路由策略的设计灵活性非常高,可以解决几乎所有的场景的消息路由需求。同时因为发布订阅基于 Kafka,可以保证在处理大规模数据时的消息可靠性。

5.4 订阅

当长连接 Broker 从 Kafka Topic 中消费出消息后会查找本地的订阅关系,然后将消息分发到客户端会话。

我们最开始直接使用 HashMap 存储客户端的订阅关系。当客户端订阅一个 Topic 时我们就将客户端的会话对象放入以 Topic 为 Key 的订阅 Map 中,当反查消息的订阅关系时直接用 Topic 从 Map 上取值就行。

因为这个订阅关系是共享对象,当订阅和取消订阅发生时就会有连接尝试操作这个共享对象。为了避免并发写我们给 HashMap 加了锁,但这个全局锁的冲突非常严重,严重影响性能。

最终我们通过分片细化了锁的粒度,分散了锁的冲突。

本地同时创建数百个 HashMap,当需要在某个 Key 上存取数据前通过 Hash 和取模找到其中一个 HashMap 然后进行操作,这样将全局锁分散到了数百个 HashMap 中,大大降低了操作冲突,也提升了整体的性能。

5.5 会话持久化

当消息被分发给会话 Session 对象后,由 Session 来控制消息的下发。

Session 会判断消息是否是重要 Topic 消息, 是的话将消息标记 QoS 等级为 1,同时将消息存储到 Redis 的未接收消息队列,并将消息下发给客户端。等到客户端对消息的 ACK 后,再将未确认队列中的消息删除。

有一些业界方案是在内存中维护了一个列表,在扩容或缩容时这部分数据没法跟着迁移。也有部分业界方案是在长连接集群中维护了一个分布式内存存储,这样实现起来复杂度也会变高。

我们将未确认消息队列放到了外部持久化存储中,保证了单个 Broker 宕机后,客户端重新上线连接到其他 Broker 也能恢复 Session 数据,减少了扩容和缩容的负担。

5.6 滑动窗口

在发送消息时,每条 QoS 1 的消息需要被经过传输、客户端处理、回传 ACK 才能确认下发完成,路径耗时较长。如果消息量较大,每条消息都等待这么长的确认才能下发下一条,下发通道带宽不能被充分利用。

为了保证发送的效率,我们参考 TCP 的滑动窗口设计了并行发送的机制(详见:《通俗易懂-深入理解TCP协议(下):RTT、滑动窗口、拥塞处理》)。我们设置一定的阈值为发送的滑动窗口,表示通道上可以同时有这么多条消息正在传输和被等待确认。



我们应用层设计的滑动窗口跟 TCP 的滑动窗口实际上还有些差异。

TCP 的滑动窗口内的 IP 报文无法保证顺序到达,而我们的通讯是基于 TCP 的所以我们的滑动窗口内的业务消息是顺序的,只有在连接状态异常、客户端逻辑异常等情况下才可能导致部分窗口内的消息乱序。

因为 TCP 协议保证了消息的接收顺序,所以正常的发送过程中不需要针对单条消息进行重试,只有在客户端重新连接后才对窗口内的未确认消息重新发送。消息的接收端同时会保留窗口大小的缓冲区用来消息去重,保证业务方接收到的消息不会重复。

我们基于 TCP 构建的滑动窗口保证了消息的顺序性同时也极大提升传输的吞吐量。

6、写在最后

知乎长连接网关由基础架构组 (Infra) 开发和维护,主要贡献者是@faceair@安江泽 。

基础架构组负责知乎的流量入口和内部基础设施建设,对外我们奋斗在直面海量流量的的第一战线,对内我们为所有的业务提供坚如磐石的基础设施,用户的每一次访问、每一个请求、内网的每一次调用都与我们的系统息息相关。

附录:更多网络编程相关资料

[1] 网络编程基础资料:
TCP/IP详解 - 第11章·UDP:用户数据报协议
TCP/IP详解 - 第17章·TCP:传输控制协议
TCP/IP详解 - 第18章·TCP连接的建立与终止
TCP/IP详解 - 第21章·TCP的超时与重传
技术往事:改变世界的TCP/IP协议(珍贵多图、手机慎点)
通俗易懂-深入理解TCP协议(上):理论基础
通俗易懂-深入理解TCP协议(下):RTT、滑动窗口、拥塞处理
理论经典:TCP协议的3次握手与4次挥手过程详解
理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程
计算机网络通讯协议关系图(中文珍藏版)
UDP中一个包的大小最大能多大?
P2P技术详解(一):NAT详解——详细原理、P2P简介
P2P技术详解(二):P2P中的NAT穿越(打洞)方案详解
P2P技术详解(三):P2P技术之STUN、TURN、ICE详解
通俗易懂:快速理解P2P技术中的NAT穿透原理
高性能网络编程(一):单台服务器并发TCP连接数到底可以有多少
高性能网络编程(二):上一个10年,著名的C10K并发连接问题
高性能网络编程(三):下一个10年,是时候考虑C10M并发问题了
高性能网络编程(四):从C10K到C10M高性能网络应用的理论探索
高性能网络编程(五):一文读懂高性能网络编程中的I/O模型
高性能网络编程(六):一文读懂高性能网络编程中的线程模型
不为人知的网络编程(一):浅析TCP协议中的疑难杂症(上篇)
不为人知的网络编程(二):浅析TCP协议中的疑难杂症(下篇)
不为人知的网络编程(三):关闭TCP连接时为什么会TIME_WAIT、CLOSE_WAIT
不为人知的网络编程(四):深入研究分析TCP的异常关闭
不为人知的网络编程(五):UDP的连接性和负载均衡
不为人知的网络编程(六):深入地理解UDP协议并用好它
不为人知的网络编程(七):如何让不可靠的UDP变的可靠?
不为人知的网络编程(八):从数据传输层深度解密HTTP
网络编程懒人入门(一):快速理解网络通信协议(上篇)
网络编程懒人入门(二):快速理解网络通信协议(下篇)
网络编程懒人入门(三):快速理解TCP协议一篇就够
网络编程懒人入门(四):快速理解TCP和UDP的差异
网络编程懒人入门(五):快速理解为什么说UDP有时比TCP更有优势
网络编程懒人入门(六):史上最通俗的集线器、交换机、路由器功能原理入门
网络编程懒人入门(七):深入浅出,全面理解HTTP协议
网络编程懒人入门(八):手把手教你写基于TCP的Socket长连接
网络编程懒人入门(九):通俗讲解,有了IP地址,为何还要用MAC地址?
技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解
让互联网更快:新一代QUIC协议在腾讯的技术实践分享
现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障
聊聊iOS中网络编程长连接的那些事
移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”
移动端IM开发者必读(二):史上最全移动弱网络优化方法总结
IPv6技术详解:基本概念、应用现状、技术实践(上篇)
IPv6技术详解:基本概念、应用现状、技术实践(下篇)
从HTTP/0.9到HTTP/2:一文读懂HTTP协议的历史演变和设计思路
脑残式网络编程入门(一):跟着动画来学TCP三次握手和四次挥手
脑残式网络编程入门(二):我们在读写Socket时,究竟在读写什么?
脑残式网络编程入门(三):HTTP协议必知必会的一些知识
脑残式网络编程入门(四):快速理解HTTP/2的服务器推送(Server Push)
脑残式网络编程入门(五):每天都在用的Ping命令,它到底是什么?
脑残式网络编程入门(六):什么是公网IP和内网IP?NAT转换又是什么鬼?
以网游服务端的网络接入层设计为例,理解实时通信的技术挑战
迈向高阶:优秀Android程序员必知必会的网络基础
全面了解移动端DNS域名劫持等杂症:技术原理、问题根源、解决方案等
美图App的移动端DNS优化实践:HTTPS请求耗时减小近半
Android程序员必知必会的网络通信传输层协议——UDP和TCP
IM开发者的零基础通信技术入门(一):通信交换技术的百年发展史(上)
IM开发者的零基础通信技术入门(二):通信交换技术的百年发展史(下)
IM开发者的零基础通信技术入门(三):国人通信方式的百年变迁
IM开发者的零基础通信技术入门(四):手机的演进,史上最全移动终端发展史
IM开发者的零基础通信技术入门(五):1G到5G,30年移动通信技术演进史
IM开发者的零基础通信技术入门(六):移动终端的接头人——“基站”技术
IM开发者的零基础通信技术入门(七):移动终端的千里马——“电磁波”
IM开发者的零基础通信技术入门(八):零基础,史上最强“天线”原理扫盲
IM开发者的零基础通信技术入门(九):无线通信网络的中枢——“核心网”
IM开发者的零基础通信技术入门(十):零基础,史上最强5G技术扫盲
IM开发者的零基础通信技术入门(十一):为什么WiFi信号差?一文即懂!
IM开发者的零基础通信技术入门(十二):上网卡顿?网络掉线?一文即懂!
IM开发者的零基础通信技术入门(十三):为什么手机信号差?一文即懂!
IM开发者的零基础通信技术入门(十四):高铁上无线上网有多难?一文即懂!
IM开发者的零基础通信技术入门(十五):理解定位技术,一篇就够
百度APP移动端网络深度优化实践分享(一):DNS优化篇
百度APP移动端网络深度优化实践分享(二):网络连接优化篇
百度APP移动端网络深度优化实践分享(三):移动端弱网优化篇
技术大牛陈硕的分享:由浅入深,网络编程学习经验干货总结
可能会搞砸你的面试:你知道一个TCP连接上能发起多少个HTTP请求吗?
知乎技术分享:知乎千万级并发的高性能长连接网关技术实践
>> 更多同类文章 ……

[2] NIO异步网络编程资料:
Java新一代网络编程模型AIO原理及Linux系统AIO介绍
有关“为何选择Netty”的11个疑问及解答
开源NIO框架八卦——到底是先有MINA还是先有Netty?
选Netty还是Mina:深入研究与对比(一)
选Netty还是Mina:深入研究与对比(二)
NIO框架入门(一):服务端基于Netty4的UDP双向通信Demo演示
NIO框架入门(二):服务端基于MINA2的UDP双向通信Demo演示
NIO框架入门(三):iOS与MINA2、Netty4的跨平台UDP双向通信实战
NIO框架入门(四):Android与MINA2、Netty4的跨平台UDP双向通信实战
Netty 4.x学习(一):ByteBuf详解
Netty 4.x学习(二):Channel和Pipeline详解
Netty 4.x学习(三):线程模型详解
Apache Mina框架高级篇(一):IoFilter详解
Apache Mina框架高级篇(二):IoHandler详解
MINA2 线程原理总结(含简单测试实例)
Apache MINA2.0 开发指南(中文版)[附件下载]
MINA、Netty的源代码(在线阅读版)已整理发布
解决MINA数据传输中TCP的粘包、缺包问题(有源码)
解决Mina中多个同类型Filter实例共存的问题
实践总结:Netty3.x升级Netty4.x遇到的那些坑(线程篇)
实践总结:Netty3.x VS Netty4.x的线程模型
详解Netty的安全性:原理介绍、代码演示(上篇)
详解Netty的安全性:原理介绍、代码演示(下篇)
详解Netty的优雅退出机制和原理
NIO框架详解:Netty的高性能之道
Twitter:如何使用Netty 4来减少JVM的GC开销(译文)
绝对干货:基于Netty实现海量接入的推送服务技术要点
Netty干货分享:京东京麦的生产级TCP网关技术实践总结
新手入门:目前为止最透彻的的Netty高性能原理和框架架构解析
写给初学者:Java高性能NIO框架Netty的学习方法和进阶策略
少啰嗦!一分钟带你读懂Java的NIO和经典IO的区别
史上最强Java NIO入门:担心从入门到放弃的,请读这篇!
手把手教你用Netty实现网络通信程序的心跳机制、断线重连机制
>> 更多同类文章 …

(本文同步发布于:http://www.52im.net/thread-2737-1-1.html

posted @ 2019-09-05 12:04 Jack Jiang 阅读(29) | 评论 (0)编辑 收藏

     摘要: 本文原作者: Wizey,作者博客:http://wenshixin.gitee.io,即时通讯网收录时有改动,感谢原作者的无私分享。1、引言典型的Web端即时通讯技术应用场景,主要有以下两种形式:1)作为完整的即时通讯产品进行应用:比如独立的Web端IM产品;2)作为某个更大系统中的一部分进行应用:比如客服系统(相当于工单系统里嵌入IM技术啦)。对于第一种场景,为了更好的划分功能逻辑,一个完整的...  阅读全文

posted @ 2019-09-02 15:40 Jack Jiang 阅读(139) | 评论 (0)编辑 收藏

     摘要: 本文原文由作者“司徒正美”发布于公众号“前端你别闹”,即时通讯网收录时有改动,感谢原作者的分享。1、引言1990 年,第一个Web浏览器的诞生;1991 年,WWW诞生,这标志着前端技术的开始。在这将近20年的前端发展史中,我们经历了从最早的纯静态页面,到JavaScript跨时代的诞生;从PC端到移动端;从依赖后端到前端可自由打包开发;从早期的网景...  阅读全文

posted @ 2019-08-22 18:05 Jack Jiang 阅读(44) | 评论 (0)编辑 收藏

本文来自网易云信团队的技术分享,原创发表于网易云信公众号,原文链接:mp.weixin.qq.com/s/LT2dASI7QVpcOVxDAsMeVg,收录时有改动。

1、引言

在不了解IM技术的人眼里,群聊是再平常不过的功能而已,万人群聊?应该也不难实现吧?!

确实,从前端功能界面上来看,群聊无非就是个循环向群员发送消息的一对多聊天消息分发模式而已,难在何处?

真实的情况是,群聊是IM系统中的高难度技术点之一。难在哪?难在服务端!从某种角度上说,群聊功能的架构设计和技术实现的品质,可以代表这款IM软件的技术水平。

群聊从后台的技术实现上说,至少有以下难点:

1)如何高效地进行大量群员消息的分发?

2)如何高效地管理群员的在线状态?

3)如何高效地读取群员的在线状态?

4)集群系统中,如何高效地保证群员消息的准确送达?

5)群聊消息该扩散写还是扩散读?

6)如何保证大量群聊消息分发的情况下不影响单聊消息体验?

7)如何应对大群突发事件下的性能负载?

.... ....

目前,市面上主流的IM产品中,微信群是500人上限,QQ群是3000人上限(3000人群是按年付费升级,很贵,不是为一般用户准备的)。一方面,从产品的定义上群成员数量不应过多,另一方面,技术成本也是个不可回避的因素。万人群这种超大规模群的技术难度,更是难已想象。

本文内容是网易云信团队为了响应万人群聊功能需求,在设计实现万人群聊技术方案中总结的技术实践,借此机会分享给各IM开发者同行。

(本文同步发布于:http://www.52im.net/thread-2707-1-1.html

学习交流:

- 即时通讯/推送技术开发交流5群:215477170[推荐]

- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM

2、概述

随着移动互联网的发展,即时通讯服务被广泛应用到各个行业,客户业务快速发展,传统百人或千人上限的群聊已经无法满足很多业务发展需求,因此网易云信IM推出万人群服务。

万人群场景需要解决以下问题:

1)消息需要按1:9999的比例进行转发投递,按常规消息处理流程将产生大量的子任务,对系统吞吐量的要求极高;

2)在微服务系统架构下,如果不采用一些优化方案,服务以及存储(DB、缓存等)之间的QPS和网络流量将非常高;

3)以群为单位的缓存(如群成员列表)内存存储开销较大(假设一个成员200Byte,万人群约2MB);

4)群成员登录后需要同步群离线消息,智能手机上App前后台切换产生的较多登录同步消息协议,因此需要优化消息同步方案。

为了解决以上问题,万人群技术方案采用了“聚合+分层/组+增量”的设计思路:

3、万人群消息的处理流程

1)按群维护在线群成员信息,主要包含两部分(可以理解为两个缓存集合):

a. 群成员在线信息:即用户在线状态变化(上线、下线)时,更新相应群的在线状态信息(即动态维护群有哪些成员在线);

b. 成员IM长连接信息:即用户新登录时,更新用户的Link信息(即登录所在Link的地址信息,消息转发时根据Link地址路由消息)。

2)IM Server收到群消息后,按群ID将消息路由到“群消息服务”模块;

3)群消息模块检查并预处理消息内容,然后通过“群成员在线状态”服务获取在线成员,完成消息转发的基础工作。为了减少群消息模块和群在线成员服务之间的网络流量,采用了“本地缓存+增量同步”的缓存策略,即本地缓存记录最后更新版本号和时间戳,每次同步群在线成员前先检查缓存版本号是否有变更,若有则按最后更新时间增量同步;

4)通过“群成员在线服务”获取在线群成员的Link链接信息,按Link分组路由消息(分组路由的原因:同一Link上的全部群成员只需要路由一条消息即可)。同样为了减少网络开销,成员Link信息也采用“本地缓存+增量同步”的方案;

5)群消息采用“漫游+历史”的存储方案,漫游的消息存储在分布式缓存中,历史消息异步写入HBase。用户登录后可以通过漫游快速的获取到最新消息,并可以通过拉取历史查看更早的消息。

4、万人群方案本地缓存增量同步策略

抛开群在线状态管理逻辑,群成员在线状态服务可以简单理解为分布式集中缓存。

增量同步技术方案如下:

如上图所示:

1)数据缓存是一个集合,其包含了多个缓存数据项,每一个数据项带有最后更新时间信息;另外缓存还有一个严格递增的版本号;

2)缓存数据变更(新增、修改、删除)后,需要增加版本号;

3)本地线程通过缓存管理读取数据时,管理服务先检查本地版本号和分布式缓存中的版本号是否一致,若不一致则按本地最新时间戳增量同步新数据项,并更新本地的版本号和最后更新时间(为了避免分布式集中缓存中并发写入导致的增量时间戳不可靠问题,增量更新时可以将本地记录的最后更新时间戳向前推移,比如减少20ms);

4)为避免本地多线程并发读取相同数据项导致并发更新本地缓存的问题,可以按缓存数据合并更新请求,即解决并发问题还可以减少网络开销;

5)缓存数据由大量数据项构成,为了避免单个缓存数据太大,可以将数据项中的属性业务场景精简(冷热分离),低频次读写的属性额外缓存。

5、万人群水平扩容方案

万人群采用大量本地缓存的方案解决消息处理性能和网络流量的问题,因此本地存储空间成了方案的瓶颈点。因此我们设计了分组路由的技术方案。

消息按群ID和路由策略定向路由到指定分组(集群)上处理,分组由多个计算节点组成,因此方案上可以做到分组内和分组间的水平扩缩容。

6、作为“云”服务,网易云信是如何实现万人群所需的计算资源的?

由于万人群对计算和存储资源消耗比较高,在实施和运维方案上也有一定的特殊性,为了保证业务的可靠性和稳定性,网易云信是将万人大群的能力,仅提供给专属的云客户(普通公有云客户是无法使用的)。

之所以能从软硬件基础设施上为万人群提供保障,网易云信的IM专有云必须具备以下资源能力:

1)需要专属的独立计算资源:保持计算资源独立,且资源冗余度比公有云高,且需要保证不会受到公有云上其他客户业务的影响;

2)需要专属的独立运维服务:从而根据客户业务场景制定最佳的业务监控、弹性扩容、故障迁移等运维方案。

总之,万人群聊的实现,过硬的技术方案设计和技术实现只是一方面,基础计算设施资源和运维能力也是不可或缺。

所以,从今以后,不要随随便便就喊万人群聊,甚至十万人群聊,这不是想实现就能实现的哦!

附录:更多群聊相关技术文章

快速裂变:见证微信强大后台架构从0到1的演进历程(一)
如何保证IM实时消息的“时序性”与“一致性”?
IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?
IM群聊消息如此复杂,如何保证不丢不重?
微信后台团队:微信后台异步消息队列的优化升级实践分享
移动端IM中大规模群消息的推送如何保证效率、实时性?
现代IM系统中聊天消息的同步和存储方案探讨
关于IM即时通讯群聊消息的乱序问题讨论
IM群聊消息的已读回执功能该怎么实现?
IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)?
一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践
[技术脑洞] 如果把14亿中国人拉到一个微信群里技术上能实现吗?
IM群聊机制,除了循环去发消息还有什么方式?如何优化?
网易云信技术分享:IM中的万人群聊技术方案实践总结
>> 更多同类文章 ……

(本文同步发布于:http://www.52im.net/thread-2707-1-1.html

posted @ 2019-08-14 10:07 Jack Jiang 阅读(23) | 评论 (0)编辑 收藏

     摘要: 本文原文由作者“张小方”原创发布于“高性能服务器开发”微信公众号,原题《心跳包机制设计详解》,即时通讯网收录时有改动。1、引言一般来说,没有真正动手做过网络通信应用的开发者,很难想象即时通讯应用中的心跳机制的作用。但不可否认,作为即时通讯应用,心跳机制是其网络通信技术底层中非常重要的一环,有没有心跳机制、心跳机制的算法实现好坏,都将直接影响即时通讯应...  阅读全文

posted @ 2019-08-08 12:01 Jack Jiang 阅读(37) | 评论 (0)编辑 收藏

     摘要: 本文由原作者松若章原创发布,作者主页:zhihu.com/people/hrsonion/posts,感谢原作者的无私分享。1、引言一道经典的面试题是:从 URL 在浏览器被被输入到页面展现的过程中发生了什么?大多数回答都是说请求响应之后 DOM 怎么被构建,被绘制出来。但是你有没有想过,收到的 HTML 如果包含几十个图片标签,这些图片是以什么方式、什么顺序、建立了多少连接、使用什么协议被下载下...  阅读全文

posted @ 2019-08-02 09:55 Jack Jiang 阅读(61) | 评论 (0)编辑 收藏

     摘要: 本文由百度技术团队“蔡锐”原创发表于“百度App技术”公众号,原题为《百度App网络深度优化系列《三》弱网优化》,感谢原作者的无私分享。一、前言网络优化解决的核心问题有三个,第一是安全问题,我们在《百度APP移动端网络深度优化实践分享(一):DNS优化篇》进行了详细的讲解。第二是速度问题,我们在《百度APP移动端网络深度优化实践分享(二):网络连接优...  阅读全文

posted @ 2019-07-29 10:29 Jack Jiang 阅读(30) | 评论 (0)编辑 收藏

     摘要: 本文引用自马蜂窝公众号,由马蜂窝技术团队原创分享。一、引言今天,越来越多的用户被马蜂窝持续积累的笔记、攻略、嗡嗡等优质的分享内容所吸引,在这里激发了去旅行的热情,同时也拉动了马蜂窝交易的增长。在帮助用户做出旅行决策、完成交易的过程中,IM 系统起到了重要的作用。IM 系统为用户与商家建立了直接沟通的渠道,帮助用户解答购买旅行产品中的问题,既促成了订单交易,也帮用户打消了疑虑,促成用户旅行愿望的实现...  阅读全文

posted @ 2019-07-24 21:44 Jack Jiang 阅读(30) | 评论 (0)编辑 收藏

     摘要: 本文由作者FreddyChen原创分享,为了更好的体现文章价值,引用时有少许改动,感谢原作者。1、写在前面一直想写一篇关于im即时通讯分享的文章,无奈工作太忙,很难抽出时间。今天终于从公司离职了,打算好好休息几天再重新找工作,趁时间空闲,决定静下心来写一篇文章,毕竟从前辈那里学到了很多东西。工作了五年半,这三四年来一直在做社交相关的项目,有直播、即时通讯、短视频分享、社区论坛等产品,深知即时通讯技...  阅读全文

posted @ 2019-07-22 12:48 Jack Jiang 阅读(83) | 评论 (0)编辑 收藏

     摘要: 1、引言本文以设计淘宝网的后台架构为例,介绍从一百个并发到千万级并发情况下服务端的架构的14次演进过程,同时列举出每个演进阶段会遇到的相关技术,让大家对架构的演进有一个整体的认知。文章最后汇总了一些架构设计的原则。(本文同步发布于:http://www.52im.net/thread-2665-1-1.html)2、关于作者huashiou:广东工业大学计算机科学与技术硕士毕业,大数据开发工程师。...  阅读全文

posted @ 2019-07-17 23:57 Jack Jiang 阅读(157) | 评论 (0)编辑 收藏

     摘要: 本文由DCloud 公司创始人王安原创发布于CSDN,原题《小程序技术演进史》,即时通讯网收录时有改动,感谢原作者。1、引言微信的成功,并非特定于某个具体的功能,微信的成功实际上是一大批创新技术和体验的成功合集,这也是它为何如此难此被超越的根本原因。作为微信这个超级社交应用中最为亮眼的技术之一——微信小程序,俨然已成历移动端小程序的代名词,很多人一提起“小程序&...  阅读全文

posted @ 2019-07-04 12:02 Jack Jiang 阅读(47) | 评论 (0)编辑 收藏

     摘要: 本文原题“《NIO 入门》,作者为“Gregory M. Travis”,他是《JDK 1.4 Tutorial》等书籍的作者。1、引言Java NIO是Java 1.4版加入的新特性,虽然Java技术日新月异,但历经10年,NIO依然为Java技术领域里最为重要的基础技术栈,而且依据现实的应用趋势,在可以预见的未来,它仍将继续在Java技术领域占据重要位置。网...  阅读全文

posted @ 2019-06-29 22:17 Jack Jiang 阅读(556) | 评论 (0)编辑 收藏

1、引言

很多初涉网络编程的程序员,在研究Java NIO(即异步IO)和经典IO(也就是常说的阻塞式IO)的API时,很快就会发现一个问题:我什么时候应该使用经典IO,什么时候应该使用NIO?

在本文中,将尝试用简明扼要的文字,阐明Java NIO和经典IO之间的差异、典型用例,以及这些差异如何影响我们的网络编程或数据传输代码的设计和实现的。

本文没有复杂理论,也没有像网上基它文章一样千篇一律的复制粘贴,有的只是接地气的通俗易懂,希望能给你带来帮助。

(本文同步发布于:http://www.52im.net/thread-2635-1-1.html

2、相关文章

3、Java NIO和IO的主要区别

下表总结了Java NIO和IO之间的主要区别。我将在表格后面的部分中详细介绍每个区别。

3.1 Stream Oriented vs. Buffer Oriented

Java NIO和IO之间的第一个重要区别是IO是面向流的,其中NIO是面向缓冲区的。那么,这意味着什么?

面向流的Java IO意味着您可以从流中一次读取一个或多个字节。你对读取的字节做什么取决于你。它们不会缓存在任何地方。此外,您无法在流中的数据中前后移动。如果需要在从流中读取的数据中前后移动,则需要先将其缓存在缓冲区中。

Java NIO的面向缓冲区的方法略有不同。数据被读入缓冲区,稍后处理该缓冲区。你可以根据需要在缓冲区中前后移动。这使你在处理过程中具有更大的灵活性。但是,你还需要检查缓冲区是否包含完整处理所需的所有数据。并且,你需要确保在将更多数据读入缓冲区时,不要覆盖尚未处理的缓冲区中的数据。

3.2 Blocking vs. Non-blocking IO

Java IO的各种流都是blocking的。这意味着,当线程调用read()或write()时,该线程将被阻塞,直到有一些数据要读取,或者数据被完全写入,在此期间,该线程无法执行任何其他操作。

Java NIO的非阻塞模式允许线程请求从通道读取数据,并且只获取当前可用的内容,或者根本没有数据,如果当前没有数据可用。线程可以继续使用其他内容,而不是在数据可供读取之前保持阻塞状态。

非阻塞写入也是如此,线程可以请求将某些数据写入通道,但不要等待它完全写入。然后线程可以继续并在同一时间做其他事情。

线程在IO调用中没有阻塞时花费空闲时间,通常在此期间在其他通道上执行IO。也就是说,单个线程现在可以管理多个输入和输出通道。

4、Selectors

Java NIO的选择器允许单个线程监视多个输入通道。你可以使用选择器注册多个通道,然后使用单个线程“选择”具有可用于处理的输入的通道,或者选择准备写入的通道。这种选择器机制使单个线程可以轻松管理多个通道。

5、NIO和经典IO如何影响应用程序的设计?

选择NIO或IO作为IO工具包可能会影响应用程序设计的以下方面:

1)API调用NIO或IO类;

2)处理数据;

3)用于处理数据的线程数。

5.1 API调用

当然,使用NIO时的API调用看起来与使用IO时不同。这并不奇怪。而不是仅仅从例如InputStream读取字节的数据字节,必须首先将数据读入缓冲区,然后从那里进行处理。

5.2 数据处理

使用纯NIO设计与IO设计时,数据处理也会受到影响。

在IO设计中,您从InputStream或Reader中读取字节的数据字节。想象一下,您正在处理基于行的文本数据流。

例如:

Name: Anna

Age: 25

Email: [url=mailto:anna@mailserver.com]anna@mailserver.com[/url]

Phone: 1234567890

这个文本行流可以像这样处理:

InputStream input = ... ; // get the InputStream from the client socket


BufferedReader reader = newBufferedReader(newInputStreamReader(input));


String nameLine   = reader.readLine();

String ageLine    = reader.readLine();

String emailLine  = reader.readLine();

String phoneLine  = reader.readLine();

注意处理状态是如何,由程序执行的程度决定的。换句话说,一旦第一个reader.readLine()方法返回,您就确定已经读取了整行文本。readLine()会阻塞直到读取整行,这就是原因。您还知道此行包含名称。同样,当第二个readLine()调用返回时,您知道此行包含年龄等。

正如您所看到的,只有当有新数据要读取时,程序才会进行,并且对于每个步骤,您都知道该数据是什么。一旦执行的线程已经超过读取代码中的某个数据片段,该线程就不会在数据中向后移动(通常不会)。

此图中还说明了此原则:

▲ Java IO:从阻塞流中读取数据

NIO的实现看起来会有所不同,这是一个简化的例子:

ByteBuffer buffer = ByteBuffer.allocate(48);

intbytesRead = inChannel.read(buffer);

注意第二行从通道读取字节到ByteBuffer。当该方法调用返回时,您不知道所需的所有数据是否都在缓冲区内。你只知道缓冲区包含一些字节,这使得处理更加困难。

想象一下,在第一次读取(缓冲)调用之后,是否所有读入缓冲区的内容都是半行。例如,“姓名:An”。你能处理这些数据吗?并不是的。在完成任何数据的处理之前,您需要等待至少一整行数据进入缓冲区。

那么你怎么知道缓冲区是否包含足够的数据来处理它?好吧,你没有。找出的唯一方法是查看缓冲区中的数据。结果是,在您知道所有数据是否存在之前,您可能需要多次检查缓冲区中的数据。这既低效又可能在程序设计方面变得混乱。

例如:

ByteBuffer buffer = ByteBuffer.allocate(48);

intbytesRead = inChannel.read(buffer);

while(! bufferFull(bytesRead) ) {

    bytesRead = inChannel.read(buffer);

}

bufferFull()方法必须跟踪读入缓冲区的数据量,并返回true或false,具体取决于缓冲区是否已满。换句话说,如果缓冲区已准备好进行处理,则认为它已满。

bufferFull()方法扫描缓冲区,但必须使缓冲区保持与调用bufferFull()方法之前相同的状态。如果不是,则可能无法在正确的位置读入读入缓冲区的下一个数据。这不是不可能的,但这是另一个需要注意的问题。

如果缓冲区已满,则可以对其进行处理。如果它不满,您可能能够部分处理那里的任何数据,如果这在您的特定情况下是有意义的。在许多情况下,它没有。

这个图中说明了is-data-in-buffer-ready循环:

▲ Java NIO:从通道读取数据,直到所有需要的数据都在缓冲区中

6、什么时候该用NIO?什么时候该用经典IO?

NIO允许您仅使用一个(或几个)线程来管理多个通道(网络连接或文件),但成本是解析数据可能比从阻塞流中读取数据时更复杂。

如果您需要同时管理数千个打开的连接,每个只发送一些数据,例如聊天服务器,在NIO中实现服务器可能是一个优势。同样,如果您需要与其他计算机保持大量开放连接,例如在P2P网络中,使用单个线程来管理所有出站连接可能是一个优势。

此图中说明了这一个线程,多个连接设计:

▲ Java NIO:管理多个连接的单个线程

如果您拥有较少带宽的连接,一次发送大量数据,那么可能最经典的IO服务器实现可能是最合适的。

此图说明了经典的IO服务器设计:

▲ Java IO:经典的IO服务器设计 - 由一个线程处理的一个连接

7、更简化的理解

以众所周之的数据读取过程为例,我们来一个更简化的理解。

对于数据读取,就读取速度来说:CPU > 内存 > 硬盘。

I- 就是从硬盘到内存

O- 就是从内存到硬盘

第一种方式:从硬盘读取数据,然后程序一直等,数据读完后,继续你的操作。这种方式是最简单的,叫阻塞IO(也就是经典IO)。

第二种方式:从硬盘读取数据,然后程序继续向下执行,等数据读取完后,通知当前程序读取完成(对硬件来说叫中断,对程序来说叫回调),然后此程序可以立即处理读取的数据,也可以执行完当前操作后再对读取完的数据进行操作。

8、总而言之

还是以数据读取为例,操作系统是按块Block(块)从硬盘拿数据,就如同一个大脸盆,一下子就放入了一盆水。但是,当 Java 使用的时候,旧的 IO(经典IO)确实基于 流 Stream的,也就是虽然操作系统给我了一脸盆水,但是我得用吸管慢慢喝。

由于经典IO的重重落后理念,于是,NIO 横空出世。。。

附录:更多NIO异步网络编程资料

Java新一代网络编程模型AIO原理及Linux系统AIO介绍
有关“为何选择Netty”的11个疑问及解答
开源NIO框架八卦——到底是先有MINA还是先有Netty?
选Netty还是Mina:深入研究与对比(一)
选Netty还是Mina:深入研究与对比(二)
NIO框架入门(一):服务端基于Netty4的UDP双向通信Demo演示
NIO框架入门(二):服务端基于MINA2的UDP双向通信Demo演示
NIO框架入门(三):iOS与MINA2、Netty4的跨平台UDP双向通信实战
NIO框架入门(四):Android与MINA2、Netty4的跨平台UDP双向通信实战
Netty 4.x学习(一):ByteBuf详解
Netty 4.x学习(二):Channel和Pipeline详解
Netty 4.x学习(三):线程模型详解
Apache Mina框架高级篇(一):IoFilter详解
Apache Mina框架高级篇(二):IoHandler详解
MINA2 线程原理总结(含简单测试实例)
Apache MINA2.0 开发指南(中文版)[附件下载]
MINA、Netty的源代码(在线阅读版)已整理发布
解决MINA数据传输中TCP的粘包、缺包问题(有源码)
解决Mina中多个同类型Filter实例共存的问题
实践总结:Netty3.x升级Netty4.x遇到的那些坑(线程篇)
实践总结:Netty3.x VS Netty4.x的线程模型
详解Netty的安全性:原理介绍、代码演示(上篇)
详解Netty的安全性:原理介绍、代码演示(下篇)
详解Netty的优雅退出机制和原理
NIO框架详解:Netty的高性能之道
Twitter:如何使用Netty 4来减少JVM的GC开销(译文)
绝对干货:基于Netty实现海量接入的推送服务技术要点
Netty干货分享:京东京麦的生产级TCP网关技术实践总结
新手入门:目前为止最透彻的的Netty高性能原理和框架架构解析
写给初学者:Java高性能NIO框架Netty的学习方法和进阶策略
少啰嗦!一分钟带你读懂Java的NIO和经典IO的区别
>> 更多同类文章 ……

(本文同步发布于:http://www.52im.net/thread-2635-1-1.html

posted @ 2019-06-25 16:32 Jack Jiang 阅读(381) | 评论 (0)编辑 收藏

     摘要: 1、引言对于即时通讯网来说,所有的技术文章和资料都在围绕即时通讯这个技术方向进行整理和分享,这一次也不例外。对于即时通讯系统(包括IM、消息推送系统等)来说,MQ消息中件间是非常常见的基础软件,但市面上种类众多、各有所长的MQ消息中件间产品,该怎么去选择?这是个问题!对于很多经验不足的开发者来说,一个公司内部用的IM聊天系统,总用户量也不过百十来人,动辄就是Kafka、MongoDB,美其名曰为了...  阅读全文

posted @ 2019-06-21 15:01 Jack Jiang 阅读(53) | 评论 (0)编辑 收藏

     摘要: 本文引用了作者“ ConardLi”的《用JS开发跨平台桌面应用,从原理到实践》一文部分内容,原文链接:segmentfault.com/a/1190000019426512,感谢原作者的无私分享。1、引言现在开发IM应用动不动就要求多端——即Android端、iOS端、PC端、Web端等,Android端和iOS端作为两种不同的移动端技术,单独开发...  阅读全文

posted @ 2019-06-14 11:11 Jack Jiang 阅读(38) | 评论 (0)编辑 收藏

     摘要: 本文引用了“蔷薇Nina”的“Nginx 相关介绍(Nginx是什么?能干嘛?)”一文部分内容,感谢作者的无私分享。1、引言Nginx(及其衍生产品)是目前被大量使用的服务端反向代理和负载均衡方案,从某种意义上来讲,Nginx几乎是低成本、高负载Web服务端代名词。如此深入人心的Nginx,很多人也想当然的认为,在IM或消息推送等场景下是否也能使用N...  阅读全文

posted @ 2019-06-07 21:33 Jack Jiang 阅读(45) | 评论 (0)编辑 收藏

     摘要: 1、引言相信看到这个标题,很多人的第一反应就是:对数据库进行分库分表啊!但是实际上,数据库层面的分库分表到底是用来干什么的,其不同的作用如何应对不同的场景,我觉得很多同学可能都没搞清楚。本篇文章我们一起来学习一下,对于一个支撑日活百万用户的高并发系统,数据库架构应该如何设计呢?本文的讨论和分享,将用一个创业公司的发展作为背景引入,方便大家理解。(本文同步发布于:http://www.52im.ne...  阅读全文

posted @ 2019-05-15 14:39 Jack Jiang 阅读(75) | 评论 (0)编辑 收藏

     摘要: 【来源申明】本文原文来自:微信公众号“鲜枣课堂”,官方网站:xzclass.com,原题为:《中国通信的百年沉浮》,本文引用时已征得原作者同意。为了更好的内容呈现,即时通讯网在收录时内容有稍许调整,转载时请注明原文来源信息,请尊重原作者的劳动。1、系列文章引言1.1 适合谁来阅读?本系列文章尽量使用最浅显易懂的文字、图片来组织内容,力求通信技术零基础的人群也能看懂。但个人建...  阅读全文

posted @ 2019-05-05 15:40 Jack Jiang 阅读(42) | 评论 (0)编辑 收藏

     摘要: 1、引言关于“负载均衡”的解释,百度词条里:负载均衡,英文叫Load Balance,意思就是将请求或者数据分摊到多个操作单元上进行执行,共同完成工作任务。负载均衡(Load Balance)建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。负载均衡有两方面的含义:1)首先,大量的并...  阅读全文

posted @ 2019-04-29 14:39 Jack Jiang 阅读(57) | 评论 (0)编辑 收藏

     摘要: 一、引言WebSocket是一种比较新的协议,它是伴随着html5规范而生的,虽然还比较年轻,但大多主流浏览器都已经支持。它使用方面、应用广泛,已经渗透到前后端开发的各种场景中。对http一问一答中二式流程(就是从所周之的“长轮询”技要啦)的不满,催生了支持双向通信的WebSocket诞生。WebSocket是个不太干净协议。本文将从8个常见的疑问入手,为还不了解WebSo...  阅读全文

posted @ 2019-04-25 14:27 Jack Jiang 阅读(71) | 评论 (0)编辑 收藏

     摘要: 本文由百度技术团队“蔡锐”原创发表于“百度App技术”公众号,原题为《百度App网络深度优化系列《二》连接优化》,感谢原作者的无私分享。一、前言在《百度APP移动端网络深度优化实践分享(一):DNS优化篇》里大家了解到网络优化一般会首选优化DNS,而接下来的HTTP协议成为优化的重点,一般优化者会选择协议切换,合并请求,精简数据包大小等手段来对HTT...  阅读全文

posted @ 2019-04-24 16:25 Jack Jiang 阅读(47) | 评论 (0)编辑 收藏

     摘要: 本文由百度技术团队“蔡锐”原创发表于“百度App技术”公众号,原题为《百度App网络深度优化系列《一》DNS优化》,感谢原作者的无私分享。一、前言网络优化是客户端几大技术方向中公认的一个深度领域,所以百度App给大家带来网络深度优化系列文章。本系列文章目录如下:《百度APP移动端网络深度优化实践分享(一):DNS优化篇》(* 本文)《百度APP移动端...  阅读全文

posted @ 2019-04-22 13:51 Jack Jiang 阅读(45) | 评论 (0)编辑 收藏

     摘要: 1、引言我,Scott,一家创业公司的 CTO。从业6年却很少写文章,近一年来接触了几十个刚毕业的前端新人,也面试了100多个前端工程师和Nodejs工程师,对于前端发展的这个职业算是有些感触吧,打算陆续写一些从业经验也好,技术分享也好,对自己前6年的经历做一些文字上的沉淀。此篇文章谨献给工作0 ~ 3年的前端工程师,内容都是我的亲身经历,不精彩但接地气。(本文同步发布于:http://www.5...  阅读全文

posted @ 2019-04-15 11:45 Jack Jiang 阅读(81) | 评论 (0)编辑 收藏

     摘要: 1、引言在文章《理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程》中,我们学会了用wireshark来分析TCP的“三次握手,四次挥手”,非常好用。这就是传说中的锤子,拿着 锤子,看什么都像 钉子!在这本文中,我对将准 HTTP这颗钉子,狠狠地砸下去。。。为了对网络数据包的“流转”有更加深刻的理解,我在docker(远程)上部署...  阅读全文

posted @ 2019-04-13 11:27 Jack Jiang 阅读(49) | 评论 (0)编辑 收藏

     摘要: 1、引言HTTPS(全称: Hypertext Transfer Protocol Secure,超文本传输安全协议),是以安全为目标的HTTP通道,简单讲是HTTP的安全版。本文,就来深入介绍下其原理。补充:限于篇幅,本文对于https的相关技术要点的介绍尽量简明扼要,如想要详细了解HTTPS的方方面面,请阅读《即时通讯安全篇(七):如果这样来理解HTTPS,一篇就够了》。(本文同步发布于:ht...  阅读全文

posted @ 2019-04-08 11:48 Jack Jiang 阅读(45) | 评论 (0)编辑 收藏

     摘要: 1、系列文章引言1.1 适合谁来阅读?本系列文章尽量使用最浅显易懂的文字、图片来组织内容,力求通信技术零基础的人群也能看懂。但个人建议,至少稍微了解过网络通信方面的知识后再看,会更有收获。如果您大学学习过《计算机网络》这门课,那么一定不要错过本系列文章。特别推荐即时通讯开发者来阅读,因为针对移动弱网的问题,确实可以找到很多有价值的答案。友情提示:本系列文章可能涉及以下通信技术范畴,如您有兴趣,也可...  阅读全文

posted @ 2019-04-02 13:06 Jack Jiang 阅读(46) | 评论 (0)编辑 收藏

1、引言

沟通是人类的最基本需求,复杂多变的沟通内容、沟通方式,正是人类文明之所以如此璀璨的关键所在。

在自然界中,要完成一件事情的沟通,我们可以直接通过声音传递给对方,这是再平常不过的事了(靠“吼”就能解决)。

随着计算机的普及,互联网改变了我们的生活,甚至改变了我们的沟通方式。现在,“有什么事微信或QQ上找我”已经是很多的人口头禅了。

那么,作为不懂技术的普通人,有没有想过,你每次使用QQ或微这种IM聊天应用时,你所发送的消息,是如何被计算机送达给对方的?(这显然不可能靠“吼”解决 ^_^)

本文将从非技术人员的视角,为你讲解一下IM聊天应用中的聊天消息是怎么发送的。

学习交流:

- 即时通讯/推送技术开发交流4群:101279154[推荐]

- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM

(本文同步发布于:http://www.52im.net/thread-2433-1-1.html

2、关于作者

巩鹏军:专注移动开发十多年,热爱即时通讯技术。个人微信公众号:“巩鹏军”。

3、阅读对象

本文适合非技术背景的读者阅读,如您喜欢本文,则下列文章您也可能喜欢:

技术往事:微信估值已超5千亿,雷军曾有机会收编张小龙及其Foxmail

QQ和微信凶猛成长的背后:腾讯网络基础架构的这些年

闲话即时通讯:腾讯的成长史本质就是一部QQ成长史

腾讯开发微信花了多少钱?技术难度真这么大?难在哪?

技术往事:史上最全QQ图标变迁过程,追寻IM巨人的演进历史

开发往事:深度讲述2010到2015,微信一路风雨的背后

开发往事:记录微信3.0版背后的故事(距微信1.0发布9个月时)

微信七年回顾:历经多少质疑和差评,才配拥有今天的强大

前创始团队成员分享:盘点微信的前世今生——微信成功的必然和偶然

QQ的成功,远没有你想象的那么顺利和轻松

[技术脑洞] 如果把14亿中国人拉到一个微信群里技术上能实现吗?

QQ和微信止步不前,意味着即时通讯社交应用创业的第2春已来?

那些年微信开发过的鸡肋功能,及其带给我们的思考

为什么说即时通讯社交APP创业就是一个坑?

即时通讯创业必读:解密微信的产品定位、创新思维、设计法则等

老罗最新发布了“子弹短信”这款IM,主打熟人社交能否对标微信?

盘点和反思在微信的阴影下艰难求生的移动端IM应用

QQ现状深度剖析:你还认为QQ已经被微信打败了吗?

那些年微信开发过的鸡肋功能,及其带给我们的思考

渐行渐远的人人网:十年亲历者的互联网社交产品复盘和反思

中国互联网社交二十年:全民见证的互联网创业演义

IM热门功能讨论:为什么微信里没有消息“已读”功能?

读懂微信:从1.0到7.0版本,一个主流IM社交工具的进化史

王欣回应微信封禁,解释为何取名“马桶MT”

同为IM社交产品中的王者,QQ与微信到底有什么区别

还原真实的腾讯:从最不被看好,到即时通讯巨头的草根创业史

如果您是专业技术人员,则跟本文相关的专业技术知识等,可以以下文章中找到:

从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

移动端IM中大规模群消息的推送如何保证效率、实时性?

IM消息送达保证机制实现(一):保证在线实时消息的可靠投递

IM消息送达保证机制实现(二):保证离线消息的可靠投递

如何保证IM实时消息的“时序性”与“一致性”?

IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?

IM群聊消息如此复杂,如何保证不丢不重?

完全自已开发的IM该如何设计“失败重试”机制?

好了,费话不多说,我们开始正文部分。。。

4、在微信里,我们发送一条聊天消息是如此简单

李雷在手机上打开微信(IM客户端),在聊天输框中输入“Hello!”,点击发送。几乎是瞬间,韩梅梅手机上的微信(IM客户端)就会显示李雷的头像后面跟着“Hello!”。

整个过程如下图所示:

▲ 一条聊天消息发送的全过程

从上面的图示可以看到,整个过程涉及三大部分:

1)李雷手机上的IM客户端(微信);

2)IM服务端;

3)韩梅梅手机上的IM客户端(微信)。

下面,我们逐一介绍每个部分的具体工作原理。

5、消息发送者:发送端是怎么工作的?

先看看发送端,李雷手机上的IM客户端中发生了什么?

从上图可以看出,发送一条信息经过三个步骤:

1)消息编辑:

李雷操作键盘输入要发送的文字,点击“发送”按钮。这一切都发生在IM客户端的界面模块中。类似用笔在信纸上写信,键盘就是笔,聊天框就是信纸;

2)消息入库:

IM客户端中的数据模块会先将聊天内容“Hello!”加上谁发给谁等信息,按标准格式打包为一条IM消息,并存入本地数据库。这类似信纸装入信封,填写地址,投入邮箱的过程。一条IM消息就是一封信,本地数据库就是李雷家的邮箱;

3)消息发送:

IM客户端中的网络模块通过长连接将IM消息发给IM服务端。这类似邮递员将信件汇总发往邮政局。网络模块就是邮递员,IM服务端就是邮政局。(长连接是IM客户端跟IM服务端一直保持的网络链路)。

6、消息“中转站”:IM服务端是怎么工作的?

担负“邮政局”职责的IM服务端是IM世界中全知全能的神,它认识所有人,经手所有消息,跟每个人都一直保持联系(长连接)。

每条消息在IM服务端中都要至少经过以下处理:

1)消息接收:

长连接服务从和李雷的长连接接收到“Hello!”的IM消息。IM服务端跟所有登录的IM客户端保持长连接(一条一直活跃的网络链路,每个客户端一条),长连接上定时会有心跳消息来监测客户端的在线离线状态,心跳消息就像邮递员每天都会在邮政局和邮箱之间巡回一样;

2)消息验证:

用户服务查询IM消息的目标人韩梅梅,以及发送人李雷和目标人韩梅梅是否好友关系,确保韩梅梅是真实存在而非虚构的,并且韩梅梅愿意接收李雷的消息,否则会给李雷退信。(一般IM服务端会将IM消息的副本存入数据库中备份);

3)消息转发:

在长连接服务中找到跟韩梅梅手机上IM客户端保持的长连接,并将消息发送给韩梅梅。

7、消息接收者:接收端又是怎么工作的呢?

下面看看韩梅梅手机上发生了什么?

韩梅梅手机上的IM客户端和李雷(发送者)的是一样的,但处理步骤是不同的:

1)消息接收:

网络模块通过跟IM服务端保持的长连接接收IM消息;

2)消息入库:

网络模块会将IM消息存入本地数据库,即信件投入了韩梅梅家的邮箱。网络模块就是邮递员,本地数据库就是韩梅梅家的邮箱;

3)消息展示:

界面模块获取发送人头像,和消息内容一起显示在聊天界面上。

经过上述过程,韩梅梅在自己手机上就看到了李雷发过来的“Hello!”,因为李雷和韩梅梅都是一直和服务器保持长连接,所以上述过程是瞬间完成的,李雷和韩梅梅感觉就像面对面聊天一样方便。这也是Instant Messaging名字的来历。

(本文同步发布于:http://www.52im.net/thread-2433-1-1.html

posted @ 2019-04-01 18:22 Jack Jiang 阅读(40) | 评论 (0)编辑 收藏

     摘要: 【来源申明】本文原文来自:微信公众号“鲜枣课堂”,官方网站:xzclass.com,原题为:《通信交换的百年沧桑(上)》,本文引用时已征得原作者同意。为了更好的内容呈现,即时通讯网在收录时内容有稍许调整,转载时请注明原文来源信息,请尊重原作者的劳动。1、本系列文章目录《IM开发者的零基础通信技术入门(一):通信交换技术的百年发展史(上)》(* 本文)《IM开发者的零基础通信...  阅读全文

posted @ 2019-03-26 12:08 Jack Jiang 阅读(37) | 评论 (0)编辑 收藏

     摘要: 本文来自公众号“玩不好就别玩”原创分享,原文链接:mp.weixin.qq.com/s/x5_OfICU2ijsxwMuVpqojg。文章内容为个人真实经历,虽平凡无奇,但感同身受。1、点评本文来自公众号“玩不好就别玩”原创分享。本次文章内容为个人真实经历,记录了作者个人离职鹅厂前最后一个月工作交接过程中的心理变化历程。内容虽平凡无奇,但同为程序员的...  阅读全文

posted @ 2019-03-01 18:25 Jack Jiang 阅读(52) | 评论 (0)编辑 收藏

     摘要: 本文为原创分享,转载请注明出处。1、引言即时通讯IM应用中的聊天消息时间显示是个再常见不过的需求,现在都讲究用户体验,所以时间显示再也不能像传统软件一样简单粗地暴显示成“年/月/日 时:分:秒”这样。所以,市面上几乎所有的IM都会对聊天消息的时间显示格化做人性化处理,从而提升用户体验(使用感受会明显友好)。这两天正在继续开发RainbowChat-Web产品,所以正需要这样...  阅读全文

posted @ 2019-02-23 16:54 Jack Jiang 阅读(84) | 评论 (0)编辑 收藏

     摘要: 本文原文内容引用自高可用架构公众号,内容有整理和修订。1、引言大家对下面这个排队的场景应该非常熟悉,这个是小米手机抢购的用户排队交互图,大家看到这些排队的兔子时,说明也有很多用户在同一时间向小米抢购系统提交了购买请求。▲ 小米手机抢购排队中...小米抢购系统后端服务面临巨大的压力,下图可以反映小米抢购系统面临的瞬间峰值压力。这张图截取自某年米粉节大秒服务后端其中一组LB(负载均衡层)的...  阅读全文

posted @ 2019-01-24 20:27 Jack Jiang 阅读(94) | 评论 (0)编辑 收藏

     摘要: 本文来自网易云音乐音视频实验室负责人刘华平在LiveVideoStackCon 2017大会上的分享,并由LiveVideoStack根据演讲内容整理而成(本次演讲PPT文稿,请从文末附件下载)。1、引言大家好,我是刘华平,从毕业到现在我一直在从事音视频领域相关工作,也有一些自己的创业项目,曾为早期Google Android SDK多媒体架构的构建作出贡献。就音频而言,无论是算法多样性,Code...  阅读全文

posted @ 2019-01-18 22:02 Jack Jiang 阅读(56) | 评论 (0)编辑 收藏

     摘要: 本文由爱奇艺技术团队原创分享,原题《爱奇艺Android客户端启动优化与分析》。1、引言互联网领域里有个八秒定律,如果网页打开时间超过8秒,便会有超过70%的用户放弃等待,对Android APP而言,要求更加严格,如果系统无响应时间超过5秒,便会出现ANR,APP可能会被强制关闭,因此,启动时间作为一个重要的性能指标,关系着用户的第一体验。爱奇艺安卓APP非常重视启动速度的优化,本文将从启动过程...  阅读全文

posted @ 2019-01-14 11:53 Jack Jiang 阅读(50) | 评论 (0)编辑 收藏

     摘要: 1、点评互联网发展至今已经高度发达,而对于互联网应用(尤其即时通讯技术这一块)的开发者来说,网络编程是基础中的基础,只有更好地理解相关基础知识,对于应用层的开发才能做到游刃有余。对于Android程序员来说,如果您觉得本文内容稍显枯燥,可以看看即时通讯网之前整理过的一篇类似文章《迈向高阶:优秀Android程序员必知必会的网络基础》,该文内容更偏向于知识点的概括。如果您希望更系统地学习网络编程方面...  阅读全文

posted @ 2019-01-10 11:15 Jack Jiang 阅读(48) | 评论 (0)编辑 收藏

     摘要: 本文来自腾讯QQ技术团队工程师许灵锋、周海发的技术分享。一、引言自 2015 年春节以来,QQ 春节红包经历了企业红包(2015 年)、刷一刷红包(2016 年)和 AR 红包(2017 年)几个阶段,通过不断创新玩法,活跃度节节攀升,成为春节一大玩点,给火红的春节带来一抹亮色。2017 年除夕,AR 红包、刷一刷红包再创新高,抢红包用户数达 3.42 亿,共刷出红包 37.77 亿个。那么,QQ...  阅读全文

posted @ 2019-01-07 12:10 Jack Jiang 阅读(83) | 评论 (0)编辑 收藏

     摘要: 本文原作者“minminaya”,作者网站:minminaya.cn,为了提升文章品质,即时通讯网对内容作了幅修订和改动,感谢原作者。1、引言对于IM应用和消息推送服务的开发者来说,在Android机型上的后台保活是个相当头疼的问题。老板一句:“为什么微信、QQ能收到消息,而你写的APP却不行?”,直接让人崩溃,话说老板你这APP要是整成微信、APP...  阅读全文

posted @ 2018-12-27 15:08 Jack Jiang 阅读(251) | 评论 (0)编辑 收藏

     摘要: 本文引用了颜向群发表于高可用架构公众号上的文章《聊聊HTTPS环境DNS优化:美图App请求耗时节约近半案例》的部分内容,感谢原作者。1、引言移动互联网时代,APP 厂商之间的竞争非常激烈,而良好的用户体验是必须优先考虑的,美图产品以高颜值著称,对产品的用户体验非常重视。从技术的角度来看,客户端的体验优化当中 DNS 优化是非常关键的一环,怎么降低 DNS 的耗时、怎么减少域名劫持等问题,都是大家...  阅读全文

posted @ 2018-12-25 16:30 Jack Jiang 阅读(114) | 评论 (0)编辑 收藏

     摘要: 本文由“猫爸iYao”原创分享,感谢作者。1、引言最近有个需求:评论@人(没错,就是IM聊天或者微博APP里的@人功能),就像下图这样:▲ 微信群聊界面里的@人功能 ▲ QQ群聊界面里的@人功能网上已经有一些文章分享了类似功能实现逻辑,但是几乎都是扩展EditText类,这种实现方式肯定不能进入我的首发阵容。你以为是因为它不符合面向对象六大...  阅读全文

posted @ 2018-12-23 21:31 Jack Jiang 阅读(119) | 评论 (0)编辑 收藏

     摘要: 本文由腾讯云加社区整理和发布,原文链接:cloud.tencent.com/developer/article/1004735,内容有删减和改动。1、引言在互联网一线做了十年的程序开发,经历了网易、百度、腾讯研究院、MIG 等几个地方,陆续做过 3D 游戏、2D 页游、浏览器、移动端翻译 app 等。积累了一些感悟,但必然有依然幼稚的地方,就当抛砖引玉,聊为笑谈。(本文同步发布于:http://w...  阅读全文

posted @ 2018-12-19 19:20 Jack Jiang 阅读(70) | 评论 (0)编辑 收藏

     摘要: 本文原作者“ manong”,原创发表于segmentfault,原文链接:segmentfault.com/a/11900000061581861、引言MySQL作为开源技术的代表作之一,是互联网得以广泛流行的重要基础技术之一。国外 GitHub、Airbnb、Yelp、Coursera 均在使用 MySQL 数据库,国内阿里巴巴、去哪儿网、腾讯、魅族、京东等等的部分关键...  阅读全文

posted @ 2018-12-17 13:34 Jack Jiang 阅读(140) | 评论 (0)编辑 收藏

     摘要: 1、引言达达创立于2014年5月,业务覆盖全国37个城市,拥有130万注册众包配送员,日均配送百万单,是全国领先的最后三公里物流配送平台。 达达的业务模式与滴滴以及Uber很相似,以众包的方式利用社会闲散人力资源,解决O2O最后三公里即时性配送难题(2016年4月,达达已经与京东到家合并)。 达达的业务组成简单直接——商家下单、配送员接单和配送,也正因为理解起来简...  阅读全文

posted @ 2018-12-10 19:32 Jack Jiang 阅读(103) | 评论 (0)编辑 收藏


1、引言

“恭喜你,成功的避过了所有的正确答案,选择了错误答案”。没错,我是一个数学专业的普通大学生(准确地说,是学渣一枚),排除万难,我终于还是入了程序员的坑(不好意思,给程序员抹黑了)!

(本文同步发布于:http://www.52im.net/thread-2127-1-1.html

2、生活爆锤了我一顿

我是一个平凡的人,人生也一直都是平淡且稀里糊涂的!像别人家孩子发生的事从来不会发生在我身上。在稀里糊涂的高考完之后,竟也能稀里糊涂的上了一个还凑活的本科院校(虽然是数学专业),算不上好,也算不上坏。没有像大多数的考生一样抱怨没发挥“好”,满怀憧憬的准备开启我的大学生活。

如绝大多数大学生一样,上午睡到自然醒,下午毒奶粉和撸啊撸,晚上喝酒聊天,打牌撸串,好不逍遥自在!本以为我会像当下大多数大学生一样”游戏”人生四年。

操蛋的是,生活毫不犹豫的给了我几皮锤,而且是一顿爆锤,锤的我是一脸懵逼。休学这种事情一向是别人家的孩子才会有的,没想到这次竟然到了我身上,不是因为世界那么大我想去看看,而是怀揣着对生活硬塞给我的迷茫回家休养。休学的生活更是极其的平淡无奇,没有北国的风光、江南的水乡,有的只是一张床、一间屋、一台电脑几本破书。

3、考验才刚刚开始

一年之后回到学校,本以为终于熬过了生活的几皮锤,没想到真正的考验才刚刚开始。“久不入凡尘”的我回到学校,一切都是那么的不适应。嘈杂的宿舍,陌生的舍友,12点以后的作息,熙来攘往的食堂,甚至安静的做着听45分钟的课……这一切都让我难以忍受。终于在第一堂统计课上了三十分钟后,满头大汗,全身都在颤抖的我终于再也忍受不了,在老师和同学们异样的眼光中我夺门而出,如逃命一般离去,那个学期我没有再去上过一节课。对人生未来没有任何方向,对生活失去信息的我,退学的念头在我心中愈发强烈。

庆幸的是,我原来的基友们因为大四有的外出培训和实习,宿舍剩下了很多空铺。于是我当天就收拾铺盖卷搬到了我原来的宿舍。原来的宿舍还剩两个舍友,这两个哥们也很6,不着急找工作。在我最艰难的时候陪我度过了最难熬的一段时光。起初我每天在宿舍床上躺着无所事事,看看电视打打游戏打发时光。后来我这两个哥们的一件事改变了我。

有些时候你难以想象两个爱玩游戏的人,一旦志同道合是多么可怕的一件事,当时他们来热衷于玩地下城和撸啊撸。这俩货玩游戏玩到什么程度呢?我只能用超强的自律来形容,地下城这个游戏玩过的朋友都知道早晨六点刷新疲劳。

于是乎,6点钟这俩货准时起床打开电脑撸一管疲劳之后七点多洗刷吃早饭,完事回来上午接着撸,下午两个人睡个午觉之后开黑打撸啊撸,晚上继续地下城。一个哥们一天撸6管疲劳(6个号),一哥们一天8管疲劳,每天晚上10点准时上床睡觉以备第二天6点能起床继续撸。这样“自律”的生活寒暑不断,风雨无阻。至今想起,我扔感觉佩服不已。终于,我深深折服于这俩货的“自律认真”,受他们影响我也加入了他们的队伍中。

4、人丑就应该多读书

好景不长!虽然我之前也爱玩游戏,但是却做不到一天6管疲劳,更别提8管疲劳。做不到像他们一样乐此不疲的沉入到游戏中去。慢慢地我又开始迷茫了,觉得这样的生活很没有意义,而且身边的人都要毕业了,对于未来,对于工作还一无所知,前途一片迷茫。

恰逢此时,我们学校的图书馆,在吸收了我几年重修费之后终于建成开放。照了照镜子,最终决定为了不让我那“天文数组”重修费不白交,我要去图书馆读读书。

起初,只是读一些文史小说之类的。后来不知道什么时候被猪油蒙了心,竟然鬼使神差的去读了一本HTML、CSS、JavaScript的书,正是这本书让我一步步的走上了不归路。当我使用代码敲出了第一个网页的时候,没错,就是“成就感”这种如毒品一样的感觉吸引了我。这次,我又回到了宿舍,还是和那俩货又混到了一起,不同的是,每天除了吃饭睡觉打游戏之外,敲代码成了我日常生活的一部分。

渐渐地,静态网页我也开始玩腻了。这个时候“动态网站”这个字眼走进了我眼睛。于是乎我又跑到了图书馆,找到了带我入行的第一本书。这本书现在看来虽然很简单,但确是陪我度过了大学里面最充实,最辉煌,真正带我入门的一本书《ASP.NET 从入门到精通》(ps:声明我不是卖书和推广书的!读书应该看看适不适合自己)。

自此正是开始了我的.NET学习与开发的生涯。

5、我好像走上了人生的巅峰

就这样学习了几个月之后,大三下学期(也就是我的老同学大四下学期)。老同学们开始毕业选题。当我看到他们的选题列表的时候。。。

没错,我的内心是这样的。在我免费承包了几个好基友的毕业设计之后,以后我的撸啊撸网名变成了“爷万众景仰”,走路仿佛都在带风。

老天仿佛开了眼,系里老师怕我们这个专业毕业后不好找工作,在大三大四开了计算机相关课程(事实证明我这些老师是多么的英明,我们班30多个同学,除最后有三十个入了程序相关行业的坑)。难以想象兴趣驱动的学习和考试驱动的学习差距是多么的大,经过几个月的学习与实战之后,没上过课的我,在考试中,有一哥们八分钟作弊被撵了出去,而我在一群崇拜的眼光中10分钟交了卷,最后竟然考了全系第一,拿到了一等奖学金。

回想生活是多么的操蛋,大一的时候我每天占座按时上课努力学习,想考第一,最终却不尽如人意。没想到大学快结束了,一天天逃课反而得到了原来自己以前最想要的。

6、离别的忧伤与找工作的迷茫

人们都说离别的时候,最后一个走的人是最痛苦的。而我注定是那最后一个走的。他们毕业以后,我和几个还在培训的同学在一起租了个房子度过了我大学生涯最后一段美好的时光。随着一个个找到工作的离去,偌大的房子就剩下了两个人。冬天还没到来,却感觉贼鸡儿冷。持续几个星期的感冒迟迟不好,又犯了鼻炎,整日呼吸都不顺畅,让我以为得了什么绝症,渐渐地感觉生活好像糟糕透了,我的心情也越来越差。不能再坐以待毙了,于是我决定出去找个工作。

7、新的挑战——入坑程序员

虽然在学校享受着别人“大神”的称呼,但实际上对找工作这件事我是慌得一比的,找到工作的同学都经过专业的培训,而我是野路子出身,也不知道自己学的怎么样。但当时想想出去面面也好,没人要就没人要,涨涨面试经验,不行回来再学习也行,于是抱着试试看的态度我准备出去找工作了。

尴尬的是大多数开发公司都集中在高新区,而学校到那里车程来回四五个小时。两天的奔波就面了两家公司,而且我连技术面试官的面都没见到,被人资就给打发回来了。再加上重感冒的原因有点吃不消,就想放弃。戏剧性的是,在我刚撤回简历的时候,一个电话邀我去面试,而且离我们学校还挺近。命运就是那么的有趣,鬼使神差的我又跟着去了。

当然,结局就是我最终去了这家公司也是我现在的公司。

原因很简单:

第一、这个办公环境是真的棒,国家甲级写字楼,还特么有漂亮的小姐姐给开门摁电梯,慢慢的逼格吸引了我,就连重感冒都感觉好了几分;

第二、当时的技术总监的技术水平折服了我,我想去学东西。

至此,经历重重磨难,我终于入了程序员的坑,开启了另一种人生!在这里我经历了朝九晚五的上班族生活,也经历了史上最要人命的加班生活,经历了每月1800的苦逼岁月,也经历了一年翻五倍薪的辉煌人生,做过小兵、当过带头大哥,孤军奋战过,团队合作过,迷茫过、徘徊过……但还始终坚定地往前扑棱着!

8、最后

最后,送给还在生活中使劲扑棱的人:

假如生活暴锤了你,不要悲伤不要着急,一定要坚定不移地向前再轱蛹、轱蛹!

人丑应该多读书,人在迷茫的时候更不要停止学习的脚步!

当你陷入生活的泥潭的时候要努力的寻求变化!

无论任何时候都不要丧失对生活的信息,保持乐观!

附录:更多感悟和思考的文章

一个微信实习生自述:我眼中的微信开发团队

微信程序员创业总结:如何提高Android开发效率

如何做一个合格的 iOS Team Leader

程序员中年危机:拿什么拯救你,我的三十五岁

一个魔都程序员的3年:从程序员到CTO的历练

为什么说即时通讯社交APP创业就是一个坑?

致我们再也回不去的 Github ...

一名90后二流大学程序员的自述:我是如何从“菜鸟”到“辣鸡”的

一个魔都程序员的3年:从程序员到CTO的历练

选择比努力更重要:我是如何从流水线工人到程序员的?

程序员的抉择:必须离开帝都——因为除了工作机会,还有什么值得留恋?

即时通讯创业必读:解密微信的产品定位、创新思维、设计法则等

干了这碗鸡汤:从理发店小弟到阿里P10技术大牛

程序员神级跳槽攻略:什么时候该跳?做什么准备?到哪里找工作?

感悟分享:在腾讯的八年,我的成长之路和职业思考

调皮的程序员:Linux之父雕刻在Linux内核中的故事

老罗最新发布了“子弹短信”这款IM,主打熟人社交能否对标微信?

迷茫中前行:一个专科渣渣菜鸟的编程入门感悟

盘点和反思在微信的阴影下艰难求生的移动端IM应用

QQ现状深度剖析:你还认为QQ已经被微信打败了吗?

机会不给无准备的人:一个Android程序员屡战屡败的悲惨校招经历

盘点和反思在微信的阴影下艰难求生的移动端IM应用

QQ现状深度剖析:你还认为QQ已经被微信打败了吗?

笑中带泪的码农往事:入职三天被开,公司给100块叫我走人,有我惨?

一个野生程序员的真实自述:我是如何从数学专业学渣入坑程序员的

(本文同步发布于:http://www.52im.net/thread-2127-1-1.html

posted @ 2018-12-05 15:04 Jack Jiang 阅读(116) | 评论 (0)编辑 收藏

     摘要: 1、引言对于互联网,域名是访问的第一跳,而这一跳很多时候会“失足”(尤其是移动端网络),导致访问错误内容、失败连接等,让用户在互联网上畅游的爽快瞬间消失。而对于这关键的第一跳,包括鹅厂在内的国内互联网大厂,都在持续深入地研究和思考对策,本文将就鹅厂团队在这一块的技术实践,做一个深度的总结和技术分享,希望给大家带来些许启发。学习交流:- 即时通讯/推送技术开发交流4群:101...  阅读全文

posted @ 2018-12-04 13:36 Jack Jiang 阅读(45) | 评论 (0)编辑 收藏

     摘要: 本文由作者“卫夕”(ID:weixizhibei)原创,作者为资深广告产品经理,致力于剖析互联网广告的基本逻辑、思路及技巧。1、引言坐拥7亿日活的微信极其成功,有人说微信的成功在于赛道的成功,然而即便把微信和国际上其他地区的同类应用WhatsApp、Line等相比,微信所取得的成绩依然鹤立鸡群,不仅因为其庞大的用户量,更因为微信枝繁叶茂的生态体系。产品人张小龙微信教科书式的...  阅读全文

posted @ 2018-12-01 19:06 Jack Jiang 阅读(50) | 评论 (0)编辑 收藏

     摘要: 1、引言随着瓜子二手车相关业务的发展,公司有多个业务线都接入了IM系统,IM系统中的Socket长连接的安全问题变得越来越重要。本次分享正是基于此次解决Socket长连接身份安全认证的实践总结而来,方案可能并不完美,但愿能起到抛砖引玉的作用,希望能给您的IM系统开发带来启发。学习交流:- 即时通讯/推送技术开发交流4群:101279154[推荐]- 移动端IM开发入门文章:《新手入门一篇就够:从零...  阅读全文

posted @ 2018-11-28 12:28 Jack Jiang 阅读(70) | 评论 (0)编辑 收藏

     摘要: 1、点评本文主要分享的是如何从零设计开发一个中大型推送系统,因限于篇幅,文中有些键技术只能一笔带过,建议有这方面兴趣的读者可以深入研究相关知识点,从而形成横向知识体系。本文适合有一定开发、架构经验的后端程序员阅读,文内个别技术点可能并非最佳实践,但至少都是生动的实践分享,至少能起到抛砖引玉的作用。希望即时通讯网本次整理的文章能给予你一些启发。学习交流:- 即时通讯/推送技术开发交流4群:10127...  阅读全文

posted @ 2018-11-27 20:49 Jack Jiang 阅读(66) | 评论 (0)编辑 收藏

     摘要: 本文由“逆流的鱼yuiop”原创分享于“何俊林”公众号,感谢作者的无私分享。1、引言直播行业的竞争越来越激烈,进过2018年这波洗牌后,已经度过了蛮荒暴力期,剩下的都是在不断追求体验。最近正好在做直播首开优化工作,实践中通过多种方案并行,已经能把首开降到500ms以下,借此机会分享出来,希望能对大家有所启发。本文内容的技术前提:1)基于FFmpeg的...  阅读全文

posted @ 2018-11-22 12:48 Jack Jiang 阅读(93) | 评论 (0)编辑 收藏

     摘要: 本文引用了“帅地”发表于公众号苦逼的码农的技术分享。1、引言搞网络通信应用开发的程序员,可能会经常听到外网IP(即互联网IP地址)和内网IP(即局域网IP地址),但他们的区别是什么?又有什么关系呢?另外,内行都知道,提到外网IP和内网IP就不得不提NAT路由转换这种东西,那这双是什么鬼?本文就来简单讲讲这些到底都是怎么回事。另外,以下是与本文内相关知识点有关联的文章,可详细...  阅读全文

posted @ 2018-11-20 12:34 Jack Jiang 阅读(73) | 评论 (0)编辑 收藏

     摘要: 1、前言标题虽然是为了解释有了 IP 地址,为什么还要用 MAC 地址,但是本文的重点在于理解为什么要有 IP 这样的东西。本文对读者的定位是知道 MAC 地址是什么,IP 地址是什么。(本文同步发布于:http://www.52im.net/thread-2067-1-1.html)2、关于作者翟志军,个人博客地址:https://showme.codes/,Github:https://git...  阅读全文

posted @ 2018-11-16 12:32 Jack Jiang 阅读(40) | 评论 (0)编辑 收藏

     摘要: 本文原始内容由作者“阳振坤”整理发布于OceanBase技术公众号。1、引言OceanBase 是蚂蚁金服自研的分布式数据库,在其 9 年的发展历程里,从艰难上线到找不到业务场景濒临解散,最后在双十一的流量考验下浴火重生,成为蚂蚁金服全部核心系统的承载数据库。这一路走来的艰辛和故事,蚂蚁金服高级研究员、OceanBase 团队负责人阳振坤将为你娓娓道来。什么是OceanBa...  阅读全文

posted @ 2018-11-14 12:49 Jack Jiang 阅读(40) | 评论 (0)编辑 收藏

     摘要: 本文由微信开发团队工程是由“oneliang”原创发表于WeMobileDev公众号,内容稍有改动。1、引言Kotlin 是一个用于现代多平台应用的静态编程语言,由 JetBrains 开发(也就是开发了号称Java界最智能的集成开发工具IntelliJ IDEA的公司)。Kotlin可以编译成Java字节码(就像Groovy和Scala一样),也可以编译成JavaScri...  阅读全文

posted @ 2018-11-12 19:03 Jack Jiang 阅读(119) | 评论 (0)编辑 收藏

     摘要: 本文原题“阿里数据库十年变迁,那些你不知道的二三事”,来自阿里巴巴官方技术公号的分享。1、引言第十个双11即将来临之际,阿里技术推出《十年牧码记》系列,邀请参与历年双11备战的核心技术大牛,一起回顾阿里技术的变迁。今天,阿里数据库事业部研究员张瑞,将为你讲述双11数据库技术不为人知的故事。在零点交易数字一次次提升的背后,既是数据库技术的一次次突破,也见证了阿里技术人永不言败...  阅读全文

posted @ 2018-11-06 11:03 Jack Jiang 阅读(78) | 评论 (0)编辑 收藏

     摘要: 1、引言Netty 是一个广受欢迎的异步事件驱动的Java开源网络应用程序框架,用于快速开发可维护的高性能协议服务器和客户端。本文基于 Netty 4.1 展开介绍相关理论模型,使用场景,基本组件、整体架构,知其然且知其所以然,希望给大家在实际开发实践、学习开源项目方面提供参考。本文作者的另两篇《高性能网络编程(五):一文读懂高性能网络编程中的I/O模型》、《高性能网...  阅读全文

posted @ 2018-11-05 13:57 Jack Jiang 阅读(944) | 评论 (0)编辑 收藏

     摘要: 本文来自腾讯前端开发工程师“ wendygogogo”的技术分享,作者自评:“在Web前端摸爬滚打的码农一枚,对技术充满热情的菜鸟,致力为手Q的建设添砖加瓦。”1、GIF格式的历史GIF ( Graphics Interchange Format )原义是“图像互换格式”,是 CompuServe 公司在1987年开发出的图像...  阅读全文

posted @ 2018-10-29 12:34 Jack Jiang 阅读(58) | 评论 (0)编辑 收藏

     摘要: 本文由作者“假不理”发表于“编程无界”公众号,现重新整理发布,感谢作者的精彩分享。1、引言十月,金秋季节,本是丰收之时,却因为陆续有同事离职,心中多少有些悲凉之意,顿然想起从参加工作到现在。至今五年已过,当年青涩懵懂的小年轻,如今出街招摇过市时,被小孩子看到都会喊声大叔。回想这五年,有心酸和无奈、有快乐和期待、也有不断的蜕变和成长。趁着国庆长假,写下...  阅读全文

posted @ 2018-10-26 10:42 Jack Jiang 阅读(276) | 评论 (0)编辑 收藏

本文原作者“虞大胆的叽叽喳喳”,原文链接:jianshu.com/p/8861da5734ba,感谢原作者。

1、引言

很多人一提到 HTTPS,第一反应就是安全,对于普通用户来说这就足够了;

但对于程序员,很有必要了解下 HTTP 到底有什么问题?以及HTTPS 是如何解决这些问题的?其背后的解决思路和方法是什么?

本文只做简单的描述,力求简单明了的阐明主要内容,因为HTTPS 体系非常复杂,这么短的文字是无法做到很详细和精准的分析。想要详细了解HTTPS的方方面面,可以阅读此前即时通讯网整理的《即时通讯安全篇(七):如果这样来理解HTTPS,一篇就够了》一文。

(本文同步发布于:http://www.52im.net/thread-2027-1-1.html

2、HTTPS相关文章

即时通讯安全篇(七):如果这样来理解HTTPS,一篇就够了

一文读懂Https的安全性原理、数字证书、单项认证、双项认证等

HTTPS时代已来,打算更新你的HTTP服务了吗?

苹果即将强制实施 ATS,你的APP准备好切换到HTTPS了吗?

3、对HTTPS性能的理解

HTTP 有典型的几个问题,第一就是性能,HTTP 是基于 TCP 的,所以网络层就不说了(快慢不是 HTTP 的问题)。

比较严重的问题在于 HTTP 头是不能压缩的,每次要传递很大的数据包。另外 HTTP 的请求模型是每个连接只能支持一个请求,所以会显得很慢。

那么 HTTPS 是解决这些问题的吗?

不是,实际上 HTTPS 是在 HTTP 协议上又加了一层,会更慢,相信未来会逐步解决的。同时 HTTPS 用到了很多加密算法,这些算法的执行也是会影响速度的。

为什么说 HTTPS 提升了性能呢?因为只有支持了 HTTPS,才能部署 HTTP/2,而 HTTP/2 协议会提升速度,能够有效减轻客户端和服务器端的压力,让响应更快速。有关HTTP/2详细文章可以看看《从HTTP/0.9到HTTP/2:一文读懂HTTP协议的历史演变和设计思路》、《脑残式网络编程入门(四):快速理解HTTP/2的服务器推送(Server Push)》,这里只要知道一点:HTTP/2 能够加快速度的主要原因在于多路复用,同一个连接能够并行发送和接收多个请求。

4、传统HTTP的安全性问题

当用户在浏览器输入一个网址的时候,在地址栏上看到小锁图标,就会安心,潜意识的认为自己的上网行为是安全的,当然对于小白用户来说可能还不明白,但是未来会慢慢改善的(万事开头难嘛)。

那么 HTTP 到底有什么安全问题呢,看几个例子:

1)由于互联网传输是能够被拦截的,所以假如你的上网方式被别人控制了(没有绝对的安全),那么你的任何行为和信息攻击者都会知道,比如我们连上一个匿名的 WIFI,当你上网的时候,输入的网站密码可能就已经泄漏了;

2)当我们在上一个网站的时候,莫名其妙跳出一个广告(这个广告并不是这个网站的),那是因为访问的页面可能被运营商强制修改了(加入了他自己的内容,比如广告)。

HTTP 最大的问题就在于数据没有加密,以及通信双方没有办法进行身份验证( confidentiality and authentication),由于数据没有加密,那么只要数据包被攻击者劫持,信息就泄漏了。

身份验证的意思就是服务器并不知道连接它的客户端到底是谁,而客户端也不确定他连接的服务器就是他想连接的服务器,双方之间没有办法进行身份确认。

有关HTTP比较好的文章,可以看看:

网络编程懒人入门(七):深入浅出,全面理解HTTP协议

从HTTP/0.9到HTTP/2:一文读懂HTTP协议的历史演变和设计思路

脑残式网络编程入门(三):HTTP协议必知必会的一些知识

5、HTTPS 背后的密码学

为了解决 HTTP 的两个核心问题,HTTPS 出现了,HTTPS 包含了核心的几个部分:TLS 协议、OpenSSL,证书。

什么是 OpenSSL 呢,它实现了世界上非常重要和多的密码算法,而密码学是解决问题最重要的一个环节。

TLS 最重要的是握手的处理方式。证书的体系也很大,但是他们背后都是基于同样的密码学。

1)既然 HTTP 没有数据加密,那么我们就加密下,对称加密算法上场了,这种算法加密和解密要使用同一个密钥,通信双方需要知道这个密钥(或者每次协商一个),实际上这种方法不太可能,这涉及到密钥保密和配送的问题,一旦被攻击者知道了密钥,那么传输的数据等同没有加密。

2)这个时候非对称加密算法上场了,公钥和私钥是分开的,客户端保存公钥,服务器保存私钥(不会公开),这时候好像能够完美解决问题了。

但实际上会存在两个问题,第一就是非对称加密算法运算很慢,第二就是会遇到中间人攻击问题。

先说说中间人攻击的问题,假如使用非对称加密算法,对于客户端来说它拿到的公钥可能并不是真正服务器的公钥,因为客户端上网的时候可能不会仔细分辨某个公钥是和某个公司绑定的,假如错误的拿到攻击者的公钥,那么他发送出去的数据包被劫持后,攻击者用自己的私钥就能反解了。

3)接下来如何解决公钥认证的问题呢?证书出现了,证书是由 CA 机构认证的,客户端都充分信任它,它能够证明你拿到的公钥是特定机构的,然后就能使用非对称加密算法加密了。

证书是怎么加密的呢?实际上也是通过非对称加密算法,但是区别在于证书是用私钥加密,公钥解密。

CA 机构会用自己的私钥加密服务器用户的公钥,而客户端则用 CA 机构的公钥解出服务器的公钥。听上去有点晕,仔细体会下。这方面的知识,可以详细阅读:《即时通讯安全篇(七):如果这样来理解HTTPS,一篇就够了》。

4)上面说了非对称加密算法加密解密非常耗时,对于 HTTP 这样的大数据包,速度就更慢了,这时候可以使用对称加密算法,这个密钥是由客户端和服务器端协商出来,并由服务器的公钥进行加密传递,所以不存在安全问题。

5)另外客户端拿到证书后会验证证书是否正确,它验证的手段就是通过 Hash 摘要算法,CA 机构会将证书信息通过 Hash 算法运算后再用私钥加密,客户端用 CA 的公钥解出后,再计算证书的 Hash 摘要值,两者一致就说明验证身份通过。

6)HTTPS 解决的第三个问题是完整性问题,就是信息有没有被篡改(信息能够被反解),用的是 HMAC 算法,这个算法和 Hash 方法差不多,但是需要传递一个密钥,这个密钥就是客户端和服务器端上面协商出来的。

附录:更多安全方面的文章

即时通讯安全篇(一):正确地理解和使用Android端加密算法

即时通讯安全篇(二):探讨组合加密算法在IM中的应用

即时通讯安全篇(三):常用加解密算法与通讯安全讲解

即时通讯安全篇(四):实例分析Android中密钥硬编码的风险

即时通讯安全篇(五):对称加密技术在Android平台上的应用实践

即时通讯安全篇(六):非对称加密技术的原理与应用实践

传输层安全协议SSL/TLS的Java平台实现简介和Demo演示

理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)

微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解

来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享

简述实时音视频聊天中端到端加密(E2EE)的工作原理

移动端安全通信的利器——端到端加密(E2EE)技术详解

Web端即时通讯安全:跨站点WebSocket劫持漏洞详解(含示例代码)

通俗易懂:一篇掌握即时通讯的消息传输安全原理

IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token

快速读懂量子通信、量子加密技术

即时通讯安全篇(七):如果这样来理解HTTPS原理,一篇就够了

一分钟理解 HTTPS 到底解决了什么问题

>> 更多同类文章 ……

(本文同步发布于:http://www.52im.net/thread-2027-1-1.html

posted @ 2018-10-24 14:05 Jack Jiang 阅读(113) | 评论 (0)编辑 收藏

     摘要: 本文由“声网Agora”的RTC开发者社区整理。1、概述本文将分享新浪微博系统开发工程师陈浩在 RTC 2018 实时互联网大会上的演讲。他分享了新浪微博直播互动答题架构设计的实战经验。其背后的百万高并发实时架构,值得借鉴并用于未来更多场景中。本文正文是对演讲内容的整理,请继续往下阅读。另外,即时通讯网整理的直播答题相关文章有:《近期大热的实时直播答题系统的实现思...  阅读全文

posted @ 2018-10-22 12:43 Jack Jiang 阅读(49) | 评论 (0)编辑 收藏

     摘要: 一、引言要实现一整套能用于大用户量、高并发场景下的IM群聊,技术难度远超IM系统中的其它功能,原因在于:IM群聊消息的实时写扩散特性带来了一系列技术难题。举个例子:如一个2000人群里,一条普通消息的发出问题,将瞬间写扩散为2000条消息的接收问题,如何保证这些消息的及时、有序、高效地送达,涉及到的技术问题点实在太多,更别说个别场景下万人大群里的炸群消息难题了更别说个别场景下万人大群里的炸群消息难...  阅读全文

posted @ 2018-10-17 14:31 Jack Jiang 阅读(224) | 评论 (0)编辑 收藏

本文引用了阿豪的微信公众号文章分享,感谢原作者的分享。

1、前言

随着社会的发展、互联网技术的进步,以前的大型机服务端架构很显然由于高成本、难维护等原因渐渐地变得不再那么主流了,替代它的就是当下最火的互联网分布式架构。

从若干年前大行其道的传统大型机到如今的分布式架构,技术发展已经经历了好几个阶段,我们只有弄明白典型互联网架构在各个阶段的演进,才能更好地理解和体会分布式架构的好处,从而有助于我们序设计适合于自已公司、产品或项目的架构(也包括设计即时通讯网专注的IM和消息推送这类系统,因为技术思路的原理都是一脉相承的)。那么本文我们就来聊聊分布式架构的演进过程,希望能给大家带来眼前一亮的感觉。

点评:即时通讯网作为IM和推送技术研究、学习和分享的社区,整理了大量的跟IM和推广技术有关的基础技术资料(比如网络基础、通信理论、架构基础等),本文内容虽然看起来跟IM和推送技术没有直接的关联性,但因为设计IM和推送系统的技术思路和原理跟典型大型互联网分布式架构都是一脉相承的,因而读懂本文内容对于IM和推送系统的架构设计同样大有裨益。

学习交流:

- 即时通讯开发交流3群:185926912[推荐]

- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM

(本文同步发布于:http://www.52im.net/thread-2007-1-1.html

2、相关文章

如果你已完全掌握本文的相关知识,请移步继续阅读即时通讯网整理的另一篇:《腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面》,该文适合对互联网架构知识有一定了解的程序员阅读和学习,都是不可能多得的技术干货。

3、技术背景说明

我们都知道一个成熟的大型网站的系统架构并非一开始就设计的非常完美,也没有一开始就具备高性能、高并发、高可用、安全性等特性,而是随着用户量的增加、业务功能的扩展逐步演变过来的,慢慢的完善的。 在这个过程中,开发模式、技术架构等都会随着迭代发生非常大的变化。 而针对不同业务特征的系统,各自都会有自己的侧重点,例如像淘宝这类的网站,要解决的重点问题就是海量商品搜索、下单、支付等问题; 像腾讯这类的网站,要解决的是数亿级别用户的实时消息传输;而像百度这类的公司所要解决的又是海量数据的搜索。每一个种类的业务都有自己不同的系统架构。

为了方便展开本文要讲解的内容,我们来简单模拟一个架构演变过程: 我们以 javaweb 为例,来搭建一个简单的电商系统,从这个系统中来看系统的演变过程。要注意的是接下来的演示模型, 关注的是数据量、访问量提升,网站结构的变化, 而不关注具体业务的功能点。其次,这个过程是为了让大家能更好的了解网站演进过程中的一些问题和应对策略。

假如我们要设计的互联网系统需要具备以下功能:

1)用户模块:用户注册和管理;

2)商品模块:商品展示和管理;

3)交易模块:创建交易及支付结算。

请带着上述3个技术点,继续深入阅读本文的正文内容。干货马上开始了。。。

4、架构演进阶段一:单应用架构

如上图所示,这个阶段是网站的初期,也可以认为是互联网发展的早期,系统架构如上图所示。我们经常会在单台服务器上运行我们所有的程序和软件。 把所有软件和应用都部署在一台机器上,这样就完成一个简单系统的搭建,这个阶段的讲究的是效率。效率决定生死。

5、架构演进阶段二:应用服务器和数据库服务器分离

随着网站的上线,访问量逐步上升,服务器的负载慢慢提高,我们应该在服务器还没有超载的时候就做好规划、提升网站的负载能力。假若此时已经没办法在代码层面继续优化提高,那么在单台机器的性能遇到瓶颈的时候,增加机器是一个比较简单好用的方式,投入产出比相当高。这个阶段增加机器的主要目的是将 web 服务器和 数据库服务器拆分开来,这样做的话不仅提高了单机的负载能力,也提高了整个系统的容灾能力。

这个阶段的系统架构如上图所示,应用服务器和数据库服务器完全隔离开来,相互互不影响,大大减少了网站宕机的风险,此阶段我们已经开始关注到应用服务器的管理了。 

6、架构演进阶段三:应用服务器集群

这个阶段,随着访问量的继续不断增加,单台应用服务器已经无法满足我们的需求。 假设我的数据库服务器还没有遇到性能问题,那我们可以通过增加应用服务器的方式来将应用服务器集群化,这样就可以将用户请求分流到各个服务器中,从而达到继续提升系统负载能力的目的。此时各个应用服务器之间没有直接的交互,他们都是依赖数据库各自对外提供服务。

系统架构发展到这个阶段,各种问题也会接踵而至:

1)用户请求交由谁来转发到具体的应用服务器上(谁来负责负载均衡);

2)用户如果每次访问到的服务器不一样,那么如何维护session,达到session共享的目的。

那么此时,系统架构又会变成如下方式:

负载均衡又可以分为软负载和硬负载。软负载我们可以选择Nginx、Apache等,硬负载我们可以选择F5等。而session共享问题我们可以通过配置tomcat的session共享解决。

7、架构演进阶段四:数据库压力变大,数据库读写分离

架构演变到上面的阶段,并不是终点。通过上面的设计,应用层的性能被我们拉上来了, 但数据库的负载也在逐渐增大,那如何去提高数据库层面的性能呢?有了前面的设计思路以后,我们自然也会想到通过增加服务器来提高性能。但假如我们单纯的把数据库一分为二,然后对于数据库的请求,分别负载到两台数据库服务器上,那必定会造成数据库数据不统一的问题。 

所以我们一般先考虑将数据库读写分离,如下图所示。

这个架构设计的变化会带来如下几个问题:

1)主从数据库之间的数据需要同步(可以使用 mysql 自带的 master-slave 方式实现主从复制 );

2)应用中需要根据业务进行对应数据源的选择( 采用第三方数据库中间件,例如 mycat )。

8、架构演进阶段五:使用搜索引擎缓解读库的压力

我们都知道数据库常常对模糊查找效率不是很高,像电商类的网站,搜索是非常核心的功能,即使是做了读写分离,这个问题也不能得到有效解决。那么这个时候我们就需要引入搜索引擎了,使用搜索引擎能够大大提升我们系统的查询速度,但同时也会带来一 些附加的问题,比如维护索引的构建、数据同步到搜索引擎等。

9、架构演进阶段六:引入缓存机制缓解数据库的压力

然后,随着访问量的持续不断增加,逐渐会出现许多用户访问同一内容的情况,那么对于这些热点数据,没必要每次都从数据库重读取,这时我们可以使用到缓存技术,比如 redis、memcache 来作为我们应用层的缓存。

另外在某些场景下,如我们对用户的某些 IP 的访问频率做限制, 那这个放内存中就又不合适,放数据库又太麻烦了,那这个时候可以使用 Nosql 的方式比如 mongDB 来代替传统的关系型数据库。

10、架构演进阶段七:数据库的水平/垂直拆分

我们的网站演进的变化过程,交易、商品、用户的数据都还在同一 个数据库中,尽管采取了增加缓存,读写分离的方式,但是随着数 据库的压力持续增加,数据库的瓶颈仍然是个最大的问题。因此我 们可以考虑对数据的垂直拆分和水平拆分。

垂直拆分:把数据库中不同业务数据拆分到不同的数据库;

水平拆分:把同一个表中的数据拆分到两个甚至更多的数据库中,水平拆分的原因是某些业务数据量已经达到了单个数据库的瓶颈,这时可以采取将表拆分到多个数据库中。

11、架构演进阶段八:应用的拆分

随着业务的发展,业务量越来越大,应用的压力越来越大。工程规模也越来越庞大。这个时候就可以考虑将应用拆分,按照领域模型将我们的用户、商品、交易拆分成多个子系统。

这样拆分以后,可能会有一些相同的代码,比如用户操作,在商品和交易都需要查询,所以会导致每个系统都会有用户查询访问相关操作。这些相同的操作一定是要抽象出来,否则就是一个坑。所以通过走服务化路线的方式来解决。

那么服务拆分以后,各个服务之间如何进行远程通信呢? 通过 RPC 技术,比较典型的有:dubbo、webservice、hessian、http、RMI 等等。前期通过这些技术能够很好的解决各个服务之间通信问题,但是, 互联网的发展是持续的,所以架构的演变和优化也还在持续。

12、本文小结

通过本文,我们通过一个电商的案例,就了解到了分布式架构的演进过程,一环套一环,环环紧密相扣。都是通过业务量和访问量的提升来考虑重构架构设计,以便能够适应当前的环境。不可一蹴而就,也急不来,初创企业必须稳扎稳打,一步一个脚印的走出一条专属自己的路。

本文主要针对的是零基础初学者,如果您想深入了解相关知识,请继续阅读《腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面》。

附录:更多架构方面的技术文章

浅谈IM系统的架构设计

简述移动端IM开发的那些坑:架构设计、通信协议和客户端

一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

一套原创分布式即时通讯(IM)系统理论架构方案

从零到卓越:京东客服即时通讯系统的技术架构演进历程

蘑菇街即时通讯/IM服务器开发之架构选择

腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT

微信后台基于时间序的海量数据冷热分级架构设计实践

微信技术总监谈架构:微信之道——大道至简(演讲全文)

如何解读《微信技术总监谈架构:微信之道——大道至简》

快速裂变:见证微信强大后台架构从0到1的演进历程(一)

17年的实践:腾讯海量产品的技术方法论

移动端IM中大规模群消息的推送如何保证效率、实时性?

现代IM系统中聊天消息的同步和存储方案探讨

IM开发基础知识补课(二):如何设计大量图片文件的服务端存储架构?

IM开发基础知识补课(三):快速理解服务端数据库读写分离原理及实践建议

IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token

WhatsApp技术实践分享:32人工程团队创造的技术神话

微信朋友圈千亿访问量背后的技术挑战和实践总结

王者荣耀2亿用户量的背后:产品定位、技术架构、网络方案等

IM系统的MQ消息中间件选型:Kafka还是RabbitMQ?

腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面

以微博类应用场景为例,总结海量社交系统的架构设计步骤

快速理解高性能HTTP服务端的负载均衡技术原理

子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践

知乎技术分享:从单机到2000万QPS并发的Redis高性能缓存实践之路

IM开发基础知识补课(五):通俗易懂,正确理解并用好MQ消息队列

微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)

微信技术分享:微信的海量IM聊天消息序列号生成实践(容灾方案篇)

新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践

>> 更多同类文章 ……

(本文同步发布于:http://www.52im.net/thread-2007-1-1.html

posted @ 2018-10-15 10:57 Jack Jiang 阅读(84) | 评论 (0)编辑 收藏

     摘要: 1、点评对于IM系统来说,如何做到IM聊天消息离线差异拉取(差异拉取是为了节省流量)、消息多端同步、消息顺序保证等,是典型的IM技术难点。就像即时通讯网整理的以下IM开发干货系列一样:《IM消息送达保证机制实现(一):保证在线实时消息的可靠投递》《IM消息送达保证机制实现(二):保证离线消息的可靠投递》《如何保证IM实时消息的“时序性”与“一致性”?...  阅读全文

posted @ 2018-10-10 15:16 Jack Jiang 阅读(74) | 评论 (0)编辑 收藏

     摘要: 1、引言特别说明:本文内容仅用于即时通讯技术研究和学习之用,请勿用于非法用途。如本文内容有不妥之处,请联系JackJiang进行处理!我司有关部门为了获取黑产群的动态,有同事潜伏在大量的黑产群(QQ群、微信群)中,干起了无间道的工作。随着黑产群数量的激增,同事希望能自动获取黑产群的聊天信息,并交付风控引擎进行风险评估。于是,这个工作就交给我了,是时候表现一波了……针对同事的...  阅读全文

posted @ 2018-10-08 11:33 Jack Jiang 阅读(176) | 评论 (0)编辑 收藏

     摘要: 1、概述本文来自腾讯视频云终端技术总监rexchang(常青)技术分享,内容分别介绍了微信小程序视音视频和WebRTC的技术特征、差异等,并针对两者的技术差异分享和总结了微信小程序视音视频和WebRTC互通的实现思路以及技术方案。希望能带给你启发。学习交流:- 即时通讯开发交流3群:185926912[推荐]- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》(本文同步发布于:ht...  阅读全文

posted @ 2018-09-29 11:05 Jack Jiang 阅读(59) | 评论 (0)编辑 收藏

     摘要: 1、引言消息是互联网信息的一种表现形式,是人利用计算机进行信息传递的有效载体,比如即时通讯网坛友最熟悉的即时通讯消息就是其具体的表现形式之一。消息从发送者到接收者的典型传递方式有两种:1)一种我们可以称为即时消息:即消息从一端发出后(消息发送者)立即就可以达到另一端(消息接收者),这种方式的具体实现就是平时最常见的IM聊天消息;2)另一种称为延迟消息:即消息从某端发出后,首先进入一个容器进行临时存...  阅读全文

posted @ 2018-09-26 14:52 Jack Jiang 阅读(93) | 评论 (0)编辑 收藏

1、MMKV简介

腾讯微信团队于2018年9月底宣布开源 MMKV ,这是基于 mmap 内存映射的 key-value 组件,底层序列化/反序列化使用 protobuf 实现,主打高性能和稳定性。近期也已移植到 Android 平台,一并对外开源。

MMKV 是基于 mmap 内存映射的 key-value 组件,底层序列化/反序列化使用 protobuf 实现,性能高,稳定性强。从 2015 年中至今,在 iOS 微信上使用已有近 3 年,其性能和稳定性经过了时间的验证。近期也已移植到 Android 平台,一并开源。

MMKV最新源码托管地址:https://github.com/Tencent/MMKV

2、MMKV 源起

在微信客户端的日常运营中,时不时就会爆发特殊文字引起系统的 crash(请参见文章:《微信团队分享:iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的?》、《微信团队分享:iOS版微信的高性能通用key-value组件技术实践》),文章里面设计的技术方案是在关键代码前后进行计数器的加减,通过检查计数器的异常,来发现引起闪退的异常文字。在会话列表、会话界面等有大量 cell 的地方,希望新加的计时器不会影响滑动性能;另外这些计数器还要永久存储下来——因为闪退随时可能发生。

这就需要一个性能非常高的通用 key-value 存储组件,我们考察了 SharedPreferences、NSUserDefaults、SQLite 等常见组件,发现都没能满足如此苛刻的性能要求。考虑到这个防 crash 方案最主要的诉求还是实时写入,而 mmap 内存映射文件刚好满足这种需求,我们尝试通过它来实现一套 key-value 组件。

3、MMKV 原理

内存准备:

通过 mmap 内存映射文件,提供一段可供随时写入的内存块,App 只管往里面写数据,由操作系统负责将内存回写到文件,不必担心 crash 导致数据丢失。

数据组织:

数据序列化方面我们选用 protobuf 协议,pb 在性能和空间占用上都有不错的表现。

写入优化:

考虑到主要使用场景是频繁地进行写入更新,我们需要有增量更新的能力。我们考虑将增量 kv 对象序列化后,append 到内存末尾。

空间增长:

使用 append 实现增量更新带来了一个新的问题,就是不断 append 的话,文件大小会增长得不可控。我们需要在性能和空间上做个折中。

更详细的设计原理参考MMKV 原理

4、iOS 指南

安装引入(推荐使用 CocoaPods):

安装CocoaPods

打开命令行,cd到你的项目工程目录, 输入pod repo update让 CocoaPods 感知最新的 MMKV 版本;

打开 Podfile, 添加pod 'MMKV'到你的 app target 里面;

在命令行输入pod install;

用 Xcode 打开由 CocoaPods 自动生成的.xcworkspace文件;

添加头文件#import <MMKV/MMKV.h>,就可以愉快地开始你的 MMKV 之旅了。

更多安装指引参考iOS Setup

快速上手:

MMKV 的使用非常简单,无需任何配置,所有变更立马生效,无需调用synchronize:

MMKV *mmkv = [MMKV defaultMMKV];    [mmkvsetBool:YESforKey:@"bool"];BOOL bValue = [mmkvgetBoolForKey:@"bool"];    [mmkvsetInt32:-1024forKey:@"int32"];int32_t iValue = [mmkvgetInt32ForKey:@"int32"];    [mmkvsetObject:@"hello, mmkv"forKey:@"string"];NSString *str = [mmkvgetObjectOfClass:NSString.classforKey:@"string"];

更详细的使用教程参考iOS Tutorial

性能对比:

循环写入随机的int1w 次,我们有如下性能对比:

更详细的性能对比参考iOS Benchmark

5、Android 指南

安装引入:

推荐使用 Maven:

dependencies{implementation'com.tencent:mmkv:1.0.10'// replace"1.0.10"with any available version}

更多安装指引参考Android Setup

快速上手:

MMKV 的使用非常简单,所有变更立马生效,无需调用sync、apply。 在 App 启动时初始化 MMKV,设定 MMKV 的根目录(files/mmkv/),例如在 MainActivity 里:

protectedvoidonCreate(Bundle savedInstanceState){super.onCreate(savedInstanceState);    String rootDir = MMKV.initialize(this);    System.out.println("mmkv root: "+ rootDir);//……}

MMKV 提供一个全局的实例,可以直接使用:

importcom.tencent.mmkv.MMKV;//……MMKV kv = MMKV.defaultMMKV();kv.encode("bool",true);booleanbValue = kv.decodeBool("bool");kv.encode("int", Integer.MIN_VALUE);intiValue = kv.decodeInt("int");kv.encode("string","Hello from mmkv");String str = kv.decodeString("string");

MMKV 支持多进程访问,更详细的用法参考Android Tutorial

性能对比:

循环写入随机的int1k 次,我们有如下性能对比:

更详细的性能对比参考Android Benchmark

posted @ 2018-09-22 11:20 Jack Jiang 阅读(96) | 评论 (0)编辑 收藏

     摘要: 本文引用了公众号纯洁的微笑作者奎哥的技术文章,感谢原作者的分享。1、前言老于网络编程熟手来说,在测试和部署网络通信应用(比如IM聊天、实时音视频等)时,如果发现网络连接超时,第一时间想到的就是使用Ping命令Ping一下服务器看看通不通。甚至在有些情况下通过图形化的Ping命令工具对目标网络进行长测(比如:《两款增强型Ping工具:持续统计、图形化展式网络状况 [附件下载]》、《网络测试:Andr...  阅读全文

posted @ 2018-09-21 18:12 Jack Jiang 阅读(96) | 评论 (0)编辑 收藏

     摘要: 本文来自知乎官方技术团队的“知乎技术专栏”,感谢原作者陈鹏的无私分享。1、引言知乎存储平台团队基于开源Redis 组件打造的知乎 Redis 平台,经过不断的研发迭代,目前已经形成了一整套完整自动化运维服务体系,提供很多强大的功能。本文作者陈鹏是该系统的负责人,本次文章深入介绍了该系统的方方面面,值得互联网后端程序员仔细研究。(本文同步发布于:http://www.52im...  阅读全文

posted @ 2018-09-18 12:31 Jack Jiang 阅读(68) | 评论 (0)编辑 收藏

     摘要: 1、前言网络通信一直是Android项目里比较重要的一个模块,Android开源项目上出现过很多优秀的网络框架,从一开始只是一些对HttpClient和HttpUrlConnection简易封装使用的工具类,到后来Google开源的比较完善丰富的Volley,再到如今比较流行的Okhttp、Retrofit。要想理解他们之间存在的异同(或者具体点说,要想更深入地掌握Android开发中的网络通信技...  阅读全文

posted @ 2018-09-17 10:44 Jack Jiang 阅读(114) | 评论 (0)编辑 收藏

     摘要: 本文原文内容来自InfoQ的技术分享,本次有修订、勘误和加工,感谢原作者的分享。1、前言自从2018年8月20日子弹短信在锤子发布会露面之后(详见《老罗最新发布了“子弹短信”这款IM,主打熟人社交能否对标微信?》),关于它的讨论不绝于耳,7 天融资 1.5 亿的传闻更是将它推到了风口浪尖(请见《[资讯] “子弹短信”发布一周即融得1.5亿资金》)。&...  阅读全文

posted @ 2018-09-14 13:50 Jack Jiang 阅读(60) | 评论 (0)编辑 收藏

     摘要: 本文来自“人人都是产品经理”公众号作者栗栗粥的原创分享。1、前言移动端的时代里,微信占据了社交领域的半壁江山,不得不让人想起曾经PC时代里的王者“QQ”,微信的爆发和QQ的停滞让很多人认为微信已经彻底将QQ打败,QQ已经不再适合这个时代了。前不久看到一句有意思的分享说:“与其说微信为什么能打败QQ,不如说QQ为什么没有被微信打败。R...  阅读全文

posted @ 2018-09-11 14:58 Jack Jiang 阅读(93) | 评论 (0)编辑 收藏

     摘要: 本文原作者:李越,由银杏财经原创发布,本次内容改动。1、前言上线一周完成1.5亿元融资,上线10天总激活用户数超400万,8月29日单日新增用户超100万,这是子弹短信交出的最新成绩单(详见《[资讯] “子弹短信”发布一周即融得1.5亿资金》)。▲ 老罗的“子弹短信”这个牛逼,又可以吹很久了这样的数据,几乎就要接近移动互联网时代APP最快...  阅读全文

posted @ 2018-09-09 21:02 Jack Jiang 阅读(43) | 评论 (0)编辑 收藏

     摘要: 1、前言随着互联网的发展,面对海量用户高并发业务,传统的阻塞式的服务端架构模式已经无能为力。本文(和下篇《高性能网络编程(六):一文读懂高性能网络编程中的线程模型》)旨在为大家提供有用的高性能网络编程的I/O模型概览以及网络服务进程模型的比较,以揭开设计和实现高性能网络架构的神秘面纱。限于篇幅原因,请将本文与《高性能网络编程(六):一文读懂高性能网络编程中的线程模型》连起来读,这样会让知识更连贯。...  阅读全文

posted @ 2018-09-06 21:09 Jack Jiang 阅读(138) | 评论 (0)编辑 收藏

     摘要: 本文来自公众号“傅老师”(ID:fustory)的原创分享,感谢作者。1、引言如果QQ是一个人,看似风光,其实从出生到成长,过程饱经错荡,堪算坎坷。它的人生历程确实也够励志的了。学习交流:- 即时通讯开发交流3群:185926912 [推荐]- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》(本文同步发布于:http://www.52im.net...  阅读全文

posted @ 2018-09-05 17:07 Jack Jiang 阅读(63) | 评论 (0)编辑 收藏

本文由达达京东到家Java工程师季炳坤原创分享。

1、前言

达达-京东到家作为优秀的即时配送物流平台,实现了多渠道的订单配送,包括外卖平台的餐饮订单、新零售的生鲜订单、知名商户的优质订单等。为了提升平台的用户粘性,我们需要兼顾商户和骑士的各自愿景:商户希望订单能够准时送达,骑士希望可以高效抢单。那么在合适的时候提升订单定制化的曝光率,是及时送物流平台的核心竞争力之一。

本文将描述“达达-京东到家”的订单即时派发系统从无到有的系统演进过程,以及方案设计的关键要点,希望能为大家在解决相关业务场景上提供一个案例参考。

关于“达达-京东到家”:

达达-京东到家,是同城速递信息服务平台和无界零售即时消费平台。达达-京东到家创始人兼首席执行官蒯佳祺;

公司旗下,目前已覆盖全国400 多个主要城市,服务超过120万商家用户和超 5000万个人用户;

2018年8月,达达-京东到家正式宣布完成最新一轮5亿美元融资,投资方分别为沃尔玛和京东。

(本文同步发布于:http://www.52im.net/thread-1928-1-1.html

2、关于作者

季炳坤:“达达-京东到家”Java工程师,负责“达达-京东到家”的订单派发、订单权限、合并订单等相关技术工作的实现。

3、订单即时派发架构的演进

在公司发展的初期,我们的外卖订单从商户发单之后直接出现在抢单池中,3公里之内的骑士能够看到订单,并且从订单卡片中获取配送地址、配送时效等关键信息。这种暴力的显示模式,很容易造成骑士挑选有利于自身的订单进行配送,从而导致部分订单超时未被配送。这样的模式,在一定程度上导致了商户的流失,同时也浪费了骑士的配送时间。

从上面的场景可以看出来,我们系统中缺少一个订单核心调度者。有一种方案是选择区域订单的订单调度员,由调度员根据骑士的接单情况、配送时间、订单挤压等实时情况来进行订单调度。这种模式,看似可行,但是人力成本投入太高,且比较依赖个人的经验总结。

核心问题已经出来了:个人的经验总结会是什么呢?

1) 骑士正在配送的订单的数量,是否已经饱和;

2) 骑士的配送习惯是什么;

3) 某一阶段的订单是否顺路,骑士是否可以一起配送;

4) 骑士到店驻留时间的预估;

5) ...

理清核心问题的答案,我们的系统派单便成为了可能。

基于以上的原理,订单派发模式就可以逐渐从抢单池的订单显示演变成系统派单:

我们将会:

1)记录商户发单行为;

2)骑士配送日志及运行轨迹等信息。

并且经过数据挖掘和数据分析:

1)获取骑士的画像;

2)骑士配送时间的预估;

3)骑士到店驻留时间的预估等基础信息;

4)使用遗传算法规划出最优的配送路径;

5)...

经过上述一系列算法,我们将在骑士池中匹配出最合适的骑士,进而使用长连接(Netty)不间断的通知到骑士。

随着达达业务的不断迭代,订单配送逐渐孵化出基于大商户的驻店模式:基于商户维护一批固定的专属骑士,订单只会在运力不足的时候才会外发到抢单池中,正常情况使用派单模式通知骑士。

4、订单派发模型的方案选型

订单派发可以浅显的认为是一种信息流的推荐。在订单进入抢单池之前,我们会根据每个城市的调度情况,先进行轮询N次的派单。

大概的表现形式如下图:

举例:有笔订单需要进行推送,在推送过程中,我们暂且假设一直没有骑士接单,那么这笔订单会每间隔N秒便会进行一次普通推荐,然后进入抢单池。

从订单派发的流程周期上可以看出来,派发模型充斥着大量的延迟任务,只要能解决订单在什么时候可以进行派发,那么整个系统 50% 的功能点就能迎刃而解。

我们先了解一下经典的延迟方案,请继续往下读。。。

4.1 方案1:数据库轮询

通过一个线程定时的扫描数据库,获取到需要派单的订单信息。

优点:开发简单,结合quartz即可以满足分布式扫描;

缺点:对数据库服务器压力大,不利于项目后续发展。

4.2 方案2:JDK的延迟队列 - DelayQueue

DelayQueue是Delayed元素的一个无界阻塞队列,只有在延迟期满时才能从中提取元素。队列中对象的顺序按到期时间进行排序。

优点:开发简单,效率高,任务触发时间延迟低;

缺点:服务器重启后,数据会丢失,要满足高可用场景,需要hook线程二次开发;宕机的担忧;如果数据量暴增,也会引起OOM的情况产生。

4.3 方案3:时间轮 - TimingWheel

时间轮的结构原理很简单,它是一个存储定时任务的环形队列,底层是由数组实现,而数组中的每个元素都可以存放一个定时任务列表。列表中的每一项都表示一个事件操作单元,当时间指针指向对应的时间格的时候,该列表中的所有任务都会被执行。 时间轮由多个时间格组成,每个时间格代表着当前实践论的跨度,用tickMs代表;时间轮的个数是固定的,用wheelSize代表。

整个时间轮的跨度用interval代表,那么指针转了一圈的时间为:

interval = tickMs * wheelSize

如果tickMs=1ms,wheelSize=20,那么便能计算出此时的时间是以20ms为一转动周期,时间指针(currentTime)指向wheelSize=0的数据槽,此时有5ms延迟的任务插入了wheelSize=5的时间格。随着时间的不断推移,指针currentTime不断向前推进,过了5ms之后,当到达时间格5时,就需要将时间格5所对应的任务做相应的到期操作。

如果此时有个定时为180ms的任务该如何处理?很直观的思路是直接扩充wheelSize?这样会导致wheelSize的扩充会随着业务的发展而不断扩张,这样会使时间轮占用很大的内存空间,导致效率低下,因此便衍生出了层级时间轮的数据结构。

180ms的任务会升级到第二层时间轮中,最终被插入到第二层时间轮中时间格#8所对应的TimerTaskList中。如果此时又有一个定时为600ms的任务,那么显然第二层时间轮也无法满足条件,所以又升级到第三层时间轮中,最终被插入到第三层时间轮中时间格#1的TimerTaskList中。注意到在到期时间在[400ms,800ms)区间的多个任务(比如446ms、455ms以及473ms的定时任务)都会被放入到第三层时间轮的时间格#1中,时间格#1对应的TimerTaskList的超时时间为400ms。

随着时间轮的转动,当TimerTaskList到期时,原本定时为450ms的任务还剩下50ms的时间,还不能执行这个任务的到期操作。便会有个时间轮降级的操作,会将这个剩余时间50ms的定时任务重新提交到下一层级的时间轮中,所以该任务被放到第二层时间轮到期时间为 [40ms,60ms) 的时间格中。再经历了40ms之后,此时这个任务又被触发到,不过还剩余10ms,还是不能立即执行到期操作。所以还要再一次的降级,此任务会被添加到第一层时间轮到期时间为[10ms,11ms)的时间格中,之后再经历10ms后,此任务真正到期,最终执行相应的到期操作。

优点:效率高,可靠性高(Netty,Kafka,Akka均有使用),便于开发;

缺点:数据存储在内存中,需要自己实现持久化的方案来实现高可用。

5、订单派发方案的具体实现

结合了上述的三种方案,最后决定使用redis作为数据存储,使用timingWhell作为时间的推动者。这样便可以将定时任务的存储和时间推动进行解耦,依赖Redis的AOF机制,也不用过于担心订单数据的丢失。

kafka中为了处理成千上万的延时任务选择了多层时间轮的设计,我们从业务角度和开发难度上做了取舍,只选择设计单层的时间轮便可以满足需求。

1)时间格和缓存的映射维护:

假设当前时间currentTime为11:49:50,订单派发时间dispatchTime为11:49:57,那么时间轮的时间格#7中会设置一个哨兵节点(作为是否有数据存储在redis的依据 )用来表示该时间段是否会时间事件触发,同时会将这份数据放入到缓存中(key=dispatchTime+ip), 当7秒过后,触发了该时间段的数据,便会从redis中获取数据,异步执行相应的业务逻辑。最后,防止由于重启等一些操作导致数据的丢失,哨兵节点的维护也会在缓存中维护一份数据,在重启的时候重新读取。

2)缓存的key统一加上IP标识:

由于我们的时间调度器是依附于自身系统的,通过将缓存的key统一加上IP的标识,这样就可以保证各台服务器消费属于自身的数据,从而防止分布式环境下的并发问题,也可以减轻遍历整个列表带来的时间损耗(时间复杂度为O(N))。

3)使用异步线程处理时间格中对应的数据:

使用异步线程,是考虑到如果上一个节点发生异常或者超时等情况,会延误下一秒的操作,如果使用异常可以改善调度的即时性问题。

我们在设计系统的时候,系统的完善度和业务的满足度是互相关联影响的,单从上述的设计看,是会有些问题的,比如使用IP作为缓存的key,如果集群发生变更便会导致数据不会被消费;使用线程池异步处理也有概率导致数据不会被消费。这些不会被消费的数据会进入到抢单池中。从派单场景的需求来看,这些场景是可以被接受的,当然了,我们系统会有脚本来进行定期的筛选,将那些进入抢单池的订单进行再次派单。

* 思考:为什么不使用ScheduledThreadPoolExecutor来定时轮询redis?

原因是即便这样可以完成业务上的需求,获取定时触发的任务,但是带来的空查询不但会拉高服务的CPU,redis的QPS也会被拉高,可能会导致redis的慢查询会显著增多。

6、结语

我们在完成一个功能的时候,往往需要一些可视化的数据来确定业务发展的正确性。因此我们在开发的时候,也相应的记录了一些订单与骑士的交互动作。从每天的报表数据可以看出来,90% 以上的订单是通过派单发出并且被骑士认可接单。

订单派发的模式是提升订单曝光率有效的技术手段,我们一直结合大数据、人工智能等技术手段希望能更好的做好订单派发,能提供更加多元化的功能,将达达打造成更加一流的配送平台。

附录:更多相关技术文章

伪即时通讯:分享滴滴出行iOS客户端的演进过程

iOS的推送服务APNs详解:设计思路、技术原理及缺陷等

信鸽团队原创:一起走过 iOS10 上消息推送(APNS)的坑

Android端消息推送总结:实现原理、心跳保活、遇到的问题等

扫盲贴:认识MQTT通信协议

一个基于MQTT通信协议的完整Android推送Demo

IBM技术经理访谈:MQTT协议的制定历程、发展现状等

求教android消息推送:GCM、XMPP、MQTT三种方案的优劣

移动端实时消息推送技术浅析

扫盲贴:浅谈iOS和Android后台实时消息推送的原理和区别

绝对干货:基于Netty实现海量接入的推送服务技术要点

移动端IM实践:谷歌消息推送服务(GCM)研究(来自微信)

为何微信、QQ这样的IM工具不使用GCM服务推送消息?

极光推送系统大规模高并发架构的技术实践分享

从HTTP到MQTT:一个基于位置服务的APP数据通信实践概述

魅族2500万长连接的实时消息推送架构的技术实践分享

专访魅族架构师:海量长连接的实时消息推送系统的心得体会

深入的聊聊Android消息推送这件小事

基于WebSocket实现Hybrid移动应用的消息推送实践(含代码示例)

一个基于长连接的安全可扩展的订阅/推送服务实现思路

实践分享:如何构建一套高可用的移动端消息推送系统?

Go语言构建千万级在线的高并发消息推送系统实践(来自360公司)

腾讯信鸽技术分享:百亿级实时消息推送的实战经验

百万在线的美拍直播弹幕系统的实时推送技术实践之路

京东京麦商家开放平台的消息推送架构演进之路

了解iOS消息推送一文就够:史上最全iOS Push技术详解

基于APNs最新HTTP/2接口实现iOS的高性能消息推送(服务端篇)

解密“达达-京东到家”的订单即时派发技术原理和实践》

>> 更多同类文章 ……

(本文同步发布于:http://www.52im.net/thread-1928-1-1.html

posted @ 2018-09-04 10:20 Jack Jiang 阅读(100) | 评论 (0)编辑 收藏

     摘要: 本文参考并引用了部分腾讯游戏学院的相关技术文章内容,感谢原作者的分享。1、前言以现在主流的即时通讯应用形态来讲,一个完整的即时通讯IM应用其实是即时通信(英文简写:IM=Instant messaging)和实时通信(英文简写:RTC=Real-time communication)2种技术组合在一起的一整套网络通信系统。之所以以IM这个简写代称整个即时通讯软件,其实是历史原因了(因为早期的诸如I...  阅读全文

posted @ 2018-08-29 18:21 Jack Jiang 阅读(35) | 评论 (0)编辑 收藏

1、引言

2018年8月20日,锤子科技在北京召开了夏季新品发布会。除了新手机,发布会上还正式推出了主打语音功能的即时通讯IM聊天工具:子弹短信。这款工具此前今年早些时候在「鸟巢」发布会上初次亮相,在经历了几个月的测试后,如今终于正式上线了(想要尝鲜的可以去官网下载:https://im.smartisan.com/,细节上坑还比较多,请自行体验)。

▲ 锤子科技2018夏季新品发布会
▲ “子弹短信”的多端效果图

从“子弹短信”官网上的效果图来看,这款IM目前至少支持iOS、Android、Web PC 3个端,还算是比较主流。在IM这片被巨头们早已稳固的红海,已经很久没有出现足够引起关注的产品了,老罗真是勇气可佳。自从2013年阿里的来往和网易的易信发布以来,这个市场鲜有触碰者。

▲ 2013年有两款IM新品问市(本图来自《史上最全即时通讯软件简史(精编大图版)[附件下载]》)

那么,老罗的“子弹短信”到底有什么特色?能否对标熟人社交的标杆产品微信呢?我们继续往下看。。。

(本文同步发布于:http://www.52im.net/thread-1898-1-1.html

2、「语音转文字」是“子弹短信”的核心特色

与其他同类工具最大的一点区别是,子弹短信把「语音转文字」放在了最重要的位置。进入聊天界面,按下蓝色的麦克风发送语音,子弹短信会自动将语音转换成文字。默认设置下,子弹短信会同时发送语音和文字消息,你也可以根据需要进行调整。

这样的好处是发送信息的一方可以根据自己的习惯来输入信息,但接受信息的一方在收到通知时可以直接看到文字,而不用打开应用来查看。相信有不少微信的用户会遇到收到一堆通知显示「语音」的情况,这种问题在子弹短信上就得到了解决。 

当然,要想实现好这一点,「语音转文字」必须要有足够高的成功率。在我们的测试中,子弹短信大部分情况下都能很好地完成转换。虽然偶尔也会出现识别的问题,好在你还可以通过听语音的方式再次确认。

另外,如果你向通讯录里的好友发送子弹短信,但对方当前没有下载子弹短信的话,信息会自动以手机短信的形式发送,这样即便对方不是子弹短信的用户也能收到信息。

3、“子弹短信”的原则:一切都为了「更快一步」

「快如闪电」子弹短信的广告语。为了达成这个目的,子弹短信做了很多工作。首先是全局的悬浮球功能。打开后你可以直接通过按住悬浮球来录入语音,然后选择联系人即可发送。

进入 App 后,点击消息列表的右侧的麦克风按钮可以直接回复消息,消息列表可同时查看多条未读消息,这些功能降低了用户点击进入对话的频率。 

如果你正在使用 Smartisan 手机的话,你还可以配合「闪念胶囊」来直接把胶囊当作文字信息进行发送。

总之,这些设计都是为了能让用户「更快一步」地发送和回复消息。「效率」一直是锤子科技产品的主打特色,而子弹短信在功能上的侧重也应证了这一点。

随着 Android 和 iOS 系统支持锁屏界面通知回复,越来越多的用户开始习惯不进入 App 直接回复消息。如果子弹短信将来能实现直接在锁屏界面录入语音发送,相信回复效率还能再提升一步。

4、「人性化」的小功能

锤子科技的产品从来都不缺乏一些有趣又实用的小功能,子弹短信这次也不例外。例如,你可以将任何信息设置为稍后处理,方便你标记出那些你需要回复和处理的信息。如果你平时习惯在聊天工具里处理工作的话,这样一个随手可用的「暂存箱」是非常有必要的。 

另外子弹短信还支持「引用回复」功能,在多人聊天的情况下很实用。长按某一条消息点击「引用并回复」,你就可以针对这一条消息进行回复,避免意义不明的问题。

还有一个有趣的功能叫「这是谁来着?」。我们有时会遇到因为跟对方不经常联系导致一换头像就不认识了的尴尬。在子弹短信里,点击联系人信息可以看到好友的历史头像。如果你觉得还是记不起来的话,可以点击底部的「这是谁来着?」,应用会显示与该好友第一次的对话记录,帮你回想起来这是谁。

更多子弹短信的功能,可以看看这篇《有点特别的聊天工具——子弹短信》。

5、小结一下

子弹短信是一款追求「快」的IM聊天工具。从语音出发,在功能设计的各个节点上想办法给用户带来「更快一步」的体验,从这个方面来说,它有着自己很鲜明的特色。

不过,在目前这个大环境下,想要找到自己的位置,子弹短信还需要回答一个核心问题:已经有微信这样强大IM,我们为什么还需要另一款聊天工具?

聊天工具的本质是用来连接人的社交关系,而子弹短信的各种功能相比于微信来说更适合于工作场景。如果你觉得微信在工作交流上不够好用,想尝试一下把自己的工作和生活进行区分,并且有能力自己选择工具,或许子弹短信是一个值得一试的选择。

不过,要想跟微信对标,哪有那么容易,你以为微信的成功是个偶然吗?请看看下面的文章:

微信七年回顾:历经多少质疑和差评,才配拥有今天的强大

前创始团队成员分享:盘点微信的前世今生——微信成功的必然和偶然

即时通讯创业必读:解密微信的产品定位、创新思维、设计法则等

好了,即时通讯产品真的没有那么容易成功:《为什么说即时通讯社交APP创业就是一个坑?》。不过,但愿“子弹短信”是个例外。

附录:更多文章

技术往事:微信估值已超5千亿,雷军曾有机会收编张小龙及其Foxmail

QQ和微信凶猛成长的背后:腾讯网络基础架构的这些年

闲话即时通讯:腾讯的成长史本质就是一部QQ成长史

2017微信数据报告:日活跃用户达9亿、日发消息380亿条

腾讯开发微信花了多少钱?技术难度真这么大?难在哪?

技术往事:创业初期的腾讯——16年前的冬天,谁动了马化腾的代码》 

技术往事:史上最全QQ图标变迁过程,追寻IM巨人的演进历史》 

技术往事:“QQ群”和“微信红包”是怎么来的?》 

开发往事:深度讲述2010到2015,微信一路风雨的背后》 

开发往事:微信千年不变的那张闪屏图片的由来》 

开发往事:记录微信3.0版背后的故事(距微信1.0发布9个月时)》 

一个微信实习生自述:我眼中的微信开发团队

首次揭秘:QQ实时视频聊天背后的神秘组织

为什么说即时通讯社交APP创业就是一个坑?

微信七年回顾:历经多少质疑和差评,才配拥有今天的强大

前创始团队成员分享:盘点微信的前世今生——微信成功的必然和偶然

即时通讯创业必读:解密微信的产品定位、创新思维、设计法则等

>> 更多同类文章 ……

(本文同步发布于:http://www.52im.net/thread-1898-1-1.html

posted @ 2018-08-22 19:47 Jack Jiang 阅读(82) | 评论 (0)编辑 收藏

     摘要: 1、前言可能有初学者会问,即时通讯应用的通信安全,不就是对Socket长连接进行SSL/TLS加密这些知识吗,干吗要理解HTTPS协议呢。这其实是个误解:当今主流的移动端IM数据通信,总结下来无外乎就是长连接+短连接的方式,长连接就是众所周之的TCP、UDP、WebSocket(WebSocket的本质还是TCP),而短连接就是HTTP/HTTPS了。即时通讯IM应用中,短连接的安全跟长连接相比,...  阅读全文

posted @ 2018-08-20 18:24 Jack Jiang 阅读(73) | 评论 (0)编辑 收藏

     摘要: 1、前言跨平台一直是老生常谈的话题,cordova、ionic、react-native、weex、kotlin-native、flutter等跨平台框架的百花齐放,颇有一股推倒原生开发者的势头。为什么我们需要跨平台开发? 本质上,跨平台开发是为了增加代码复用,减少开发者对多个平台差异适配的工作量,降低开发成本,提高业务专注的同时,提供比web更好的体验。嗯~通俗了说就是:省钱、偷懒。目...  阅读全文

posted @ 2018-08-13 10:51 Jack Jiang 阅读(213) | 评论 (0)编辑 收藏

     摘要: 本文内容由公众号“格友”原创分享。1、引言(不羁的大神,连竖中指都这么帅)因为LINUX操作系统的流行,Linus 已经成为地球人都知道的名人。虽然大家可能都听过钱钟书先生的名言:“假如你吃个鸡蛋觉得味道不错,又何必认识那个下蛋的母鸡呢?” 但是如果真是遇到一个“特别显赫”的鸡蛋,很多人还是想看看能生出这颗神蛋的母鸡的,或者想...  阅读全文

posted @ 2018-08-09 16:32 Jack Jiang 阅读(116) | 评论 (0)编辑 收藏

     摘要: 1、引言本文来自新浪微博视频转码平台技术负责人李成亚在LiveVideoStackCon 2017上的分享,由LiveVideoStack整理成文。李成亚分享了微博短视频如何提升用户体验、降低成本的思路与实践,包括提升短视频发布速度,降低长视频转码时间,通过新的Codec减少带宽成本等。本文的短视频技术跟IM的单聊、群聊、朋友圈里的小视频是类似的东西,文中针对短视频的相关优化实践可以为您的IM小视...  阅读全文

posted @ 2018-08-06 16:34 Jack Jiang 阅读(41) | 评论 (0)编辑 收藏

     摘要: 1、前言对于广大Android开发者来说,Android O(即Android 8.0)还没玩热,Andriod P(即Andriod 9.0)又要来了。下图上谷歌官方公布的Android P发布路线图:Android P的最后一个开发者预览版(即DP5)已如期发布于2018年7月26日,根据上面这张发布路线图,相信Android P的正式版将很快到来。对于Andriod开发者来说,不管Andri...  阅读全文

posted @ 2018-08-02 15:27 Jack Jiang 阅读(233) | 评论 (0)编辑 收藏

     摘要: 本文内容由“微信多媒体团队”整理发布。1、引言广州TIT创意园,这里是腾讯在广州的研发团队所在地,LiveVideoStack采访了微信多媒体内核中心音视频算法高级工程师梁俊斌(Denny)。从华为2012实验室到腾讯,过去十余年梁俊斌一直专注在音频技术。他告诉LiveVideoStack:音频技术还有许多难点需要解决,而作为技术人也延展到应用场景,关注用户需求。本文整理了...  阅读全文

posted @ 2018-07-31 15:25 Jack Jiang 阅读(76) | 评论 (0)编辑 收藏

     摘要: 1、前言本文要分享的消息推送指的是当iOS端APP被关闭或者处于后台时,还能收到消息/信息/指令的能力。这种在APP处于后台或关闭情况下的消息推送能力,通常在以下场景下非常有用:1)IM即时通讯聊天应用:聊天消息通知、音视频聊天呼叫等,典型代表有:微信、QQ、易信、米聊、钉钉、Whatsup、Line;2)新闻资讯应用:最新资讯通知等,典型代码有:网易新闻客户端、腾讯新闻客户端;3)SNS社交应用...  阅读全文

posted @ 2018-07-30 10:51 Jack Jiang 阅读(354) | 评论 (0)编辑 收藏

     摘要: 1、关于作者余果:腾讯社交用户体验设计部(ISUX)高级UI工程师,前端开发组负责人,熟悉前端开发、iOS开发、PHP开发和Ruby开发等;曾独立开发iOS APP(撸大师)和CMS(33PU);翻译有《众妙之门: 网站重新设计之道》和《响应式Web设计全流程解析》,著有《Web全栈工程师的自我修养》;平时喜欢编程、写作、演讲、摄影和英语等,希望自己能做一个终生学习者。关于腾讯ISUX:腾讯ISU...  阅读全文

posted @ 2018-07-27 12:32 Jack Jiang 阅读(62) | 评论 (0)编辑 收藏

     摘要: 1、引言我们常常会听说,某个互联网应用的服务器端系统多么牛逼,比如QQ、微信、淘宝。那么,一个大型互联网应用的服务器端系统,到底牛逼在什么地方?为什么海量的用户访问,会让一个服务器端系统变得更复杂?本文结合作者多年的互联网系统设计实践经验,从最基本的技术概念开始,带你探寻服务器端系统架构的方方面面。本文适合有过几年工作经验、正处于技术上升期的程序员阅读,内容少有浮夸,多为实践经验总结,希望能为您的...  阅读全文

posted @ 2018-07-25 17:13 Jack Jiang 阅读(127) | 评论 (0)编辑 收藏

     摘要: 1、引言图片通常是移动端应用流量耗费最多的部分,并且占据着重要的视觉空间。以大家最常用的即时通讯IM应用为例,应用中存在大量的图片数据往来(比如图片消息、用户相册、用户头像等等)。合理的图片格式选用和优化不仅能减小图片传递过程中的数据量、提升视觉效果,还能显著降低服务端的带宽、计算资源等基础设施成本,一举多得。本文我们一起全面分析学习目前主流和新兴的几种图片格式的特点、性能、调优等,以及相关开源库...  阅读全文

posted @ 2018-07-23 15:36 Jack Jiang 阅读(58) | 评论 (0)编辑 收藏

     摘要: 1、引言微信小程序自2017年1月9日正式对外公布以来,越来越受到关注和重视,小程序上的各种技术体验也越来越丰富。而音视频作为高速移动网络时代下增长最快的应用形式之一,在微信小程序中也当然不能错过。本文来自腾讯视频云终端技术总监rexchang(常青)的技术分享,讲述的是微信小程序中音视频技术构思、设计和实现等方方面的内容,希望能为你的音视频技术实践带来启发。如果您能微信小程序开发没什么了解,可以...  阅读全文

posted @ 2018-07-21 20:50 Jack Jiang 阅读(69) | 评论 (0)编辑 收藏

     摘要: 本文原作者阮一峰,作者博客:ruanyifeng.com。1、前言新一代HTTP/2 协议的主要目的是为了提高网页性能(有关HTTP/2的介绍,请见《从HTTP/0.9到HTTP/2:一文读懂HTTP协议的历史演变和设计思路》)。HTTP/2以前版的头信息(header)是直接传输文本,现在是压缩后传输。原来是同一个 TCP 连接里面,上一个回应(response)发送完了,服务器才能发送下一个,...  阅读全文

posted @ 2018-07-19 16:18 Jack Jiang 阅读(58) | 评论 (0)编辑 收藏

     摘要: 本文作者:陈裕发, 腾讯系统测试工程师,由腾讯WeTest整理发表。1、引言开发iOS系统中的Push推送,通常有以下3种情况:1)在线Push:比如QQ、微信等IM界面处于前台时,聊天消息和指令都会通过IM自建的网络长连接通道推送过来,这种Push在本文中暂且称为“在线Push”;2)本地Push:这种就是最常见的iOS系统通知(作用相当于传统PC端的提示窗口,在iOS1...  阅读全文

posted @ 2018-07-16 14:45 Jack Jiang 阅读(516) | 评论 (1)编辑 收藏

     摘要: 1、引言每年的3、4月份都是求职高峰时期,目前已进入6、7月份了,你已经成功换工作了吗?这次我们想聊的,就是程序员跳槽这件事儿,我打算从三个方面来说:1)程序员什么时候该跳槽?2)跳槽前你需要做的准备工作?3)到哪里找跳槽机会?学习交流:- 即时通讯开发交流3群:185926912[推荐]- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》(本文同步发布于:http://www.5...  阅读全文

posted @ 2018-07-13 14:13 Jack Jiang 阅读(965) | 评论 (0)编辑 收藏

     摘要: 本文原作者:“竹千代”,原文由“玉刚说”写作平台提供写作赞助,原文版权归“玉刚说”微信公众号所有,即时通讯网收录时有改动。 1、前言无论是即时通讯应用还是传统的信息系统,Http协议都是我们最常打交道的网络应用层协议之一,它的重要性可能不需要再强调(有鉴于此,即时通讯网整理了大量的有关http协议的文章,如有必要可从...  阅读全文

posted @ 2018-07-11 14:49 Jack Jiang 阅读(72) | 评论 (0)编辑 收藏

1、引言

MIT TR 35(MIT Technology Review 35 Innovators Under 35)——“全球 35 位 35 岁以下科技创新青年”榜单,是全球最权威的青年科技创新人才榜单之一。从1999年开始,《麻省理工科技评论》(MIT Technology Review,简称MIT TR)每年会在全球范围内寻觅最有可能改变世界、极具才华和创新精神的年轻技术人才、创新者或企业家。该榜单从影响力、创新力、进取力、未来潜力、沟通力五个维度评估,涵盖 IT(计算机、通信、网络)、生物医药、商业等领域,最终选出35位科技创新精英。

作为全球最权威的青年科技创新人才榜单之一,TR35挖掘的新人大都极具创新性,不少还在后来成为风云人物,包括谷歌的联合创始人拉里•佩奇和谢尔盖•布林、Facebook的创始人马克•扎克伯格、雅虎创始人杨致远、苹果公司的首席设计师乔纳森•艾维等。

美国时间6月27日,《麻省理工科技评论》正式对外发布“2018年度全球35位35岁以下的科技创新青年“全球榜单,其中蚂蚁金服国际事业群技术负责人许寄(花名:红雪)因“他参与创建的支付系统可以让金融服务更普及”而成功入选该榜单。

▲ “MIT TR 35”获奖评语

他高中毕业,没上大学四处打零工,路边修过自行车,也做过理发店小弟。想学自考混文凭,结果连自考的考试都挂掉了。

学历不是你成功的天花板,你的努力才是。

一位非科班出身、自学成才的人是如何从普通的一线程序员成长为带领近千人的蚂蚁金服国际技术团队的技术+业务大拿?下面让我们一起听听许寄(花名:红雪)的故事。

学习交流:

- 即时通讯开发交流3群:185926912[推荐]

- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM

(本文同步发布于:http://www.52im.net/thread-1747-1-1.html

2、“社会人”

▲ 许寄(花名:红雪)

我是个社会人。因为不喜欢那么多的作业那么多的考试,我尝试过离家打零工找刺激,干了些乱七八糟的事情,修自行车、杀鱼、理发……

撞了一头包后,觉得还是要有一技之长,我就去西安读自考打算混个文凭,学的电子商务。结果一个西安交大来的客座老师一上来就说,电子商务这个东西啊,中国二十年之内都没希望。

一屋子学生凉凉。有同学说,实在念不成书,只好回家继承老爸的工厂了。我一听,心更凉了,我可不能回家,回家也没工厂可继承啊。

那时,我开始痴迷电脑,特喜欢泡在电脑城研究各种硬件、板卡、内存条,帮同学组装电脑,学3D建模。我人生第一本认真从头看到尾的书是谭浩强的C语言。

那时候互联网在中国开始起来了,但程序员还远远不是一份好工作,就像《乘风破浪》里,警察询问小马什么职业,小马说编程的,警察说,嗯,那就是无业。

2001年春节快到来时,正经的电子商务学业几乎全荒废了,考试眼看就要挂掉,没脸回家过年,心理压力特别大。活了十几年还找不到人生目标的沮丧感。

那时,有一个同乡邀请我去他们学校玩,在宿舍里,他給我看了他的毕业设计,用VB写了一套图书管理系统。我当时脑袋像是被砸到了一样,当即决定转专业,管他将来能不能找到工作,这至少是我确定想学的。

人生前十几年浑浑噩噩、毫无目标的状态算是告了一个段落。2003年毕业后,我留在西安工作,一个月挣一千多块钱,大部分钱继续花在各种软件培训班上。

那时的学习状态,就像老鼠掉进了米缸,每天一下班就去学习,每天睡不了几个小时,但是不觉得累。

编者语:

很难想象这个带领着近千“学霸+海归”技术人的他,居然自称为“没上过大学的社会人”。曾经拒绝高中繁重的学业和备考,他尝试过离家打零工找刺激,修自行车、杀鱼、理发……很难想象,这些些“乱七八糟”的事情他都曾干过。后来他从痴迷电脑开始,帮同学组装电脑,学3D建模。他人生第一本认真从头看到尾的书是谭浩强的C语言。在这种学霸专属的“MIT TR 35”榜单上,这个自学成才的计算机怪才略显“骨骼清奇”。

3、初入阿里巴巴带给我的“燃烧感 ”

2007年,我接到一封邮件,邀请我去面试一下阿里巴巴。

我当时都分不清淘宝和支付宝。和阿里的面试官聊完,几个感觉印象特别深刻。

首先,他们从头到尾没有问我学历;第二,他们没问我会不会这个,会不会那个,感觉特别被尊重;第三,招聘专场上挂着一句话:If not me, who? If not now, when?

当时立马被这种燃烧感击中,一种找到组织,确认他们就是自己人的感觉。

去杭州报到,第一件事情是办手续,HR要給大家建档,好多人用塑料袋装了一堆毕业证书和等级认证什么的,就我两手空荡荡的,后来发现班上还有一个同学也是两手空空。

我当时暗想,阿里真是不拘一格招人才啊。那位同学花名阿玺,也是个80后,现在是蚂蚁副CTO,阿里巴巴最年轻合伙人。

培训完被师傅领去工位,隔壁就坐着鲁肃(现蚂蚁金服CTO)和老苗(现支付宝事业群总裁)。当时鲁肃正在工位上吭哧吭哧写代码,站起来很客气地跟我握了个手。我当时也搞不清这个人是干嘛的。

我很快发现,在这里,我遇到高手了。

鲁肃和老苗这些技术大神两根烟就抽明白的事情,我可能要花两个礼拜还没搞明白。我不懂就问,跟大家一起通宵,困了和大家一起到楼道抽口烟,边吃行政妹子送来的豆浆油条。

一个很强烈的感觉是,我的人生被这帮像打了鸡血一样的人一头撞开了一扇窗。我爸要是当时看到我像海绵一样的学习状态肯定也会吓一跳,毕竟早已习惯儿子学渣好多年了。

4、入职责阿里巴巴背后的故事

当时HR为了吸引许寄加入支付宝,还给出了三点理由。第一,杭州工作离许寄的安徽老家更近,更方便回家。第二,杭州的物价水平比深圳低。第三,杭州的工作强度肯定没有深圳强。

再后来,许寄就以P5的层级加入了支付宝,那一年他23岁。加入支付宝后,他经历了支付宝核心系统架构的演进过程,参与了几乎所有重大项目的建设,带领团队规划建设了支付宝三代统一支付平台、会计核算平台等,完成了支付平台向高可用、可持续性伸缩的架构转型,支撑了支付业务的高速发展。

现在再提及他加入公司之初的那一段经历,许寄笑称自己当时是受骗了:“说是杭州离家近,但事实上每年回家也就一两次。可能杭州的平均工作强度确实没有深圳高,但这不等于阿里的工作强度不大啊。现在想想自己就是被忽悠过来的。“但是真正加入支付宝之后,大家往往都乐在其中,没有人会去想工作强度这回事。

他也分享说,刚加入公司的那几年是他最纯粹的做技术的时光。彼时支付宝技术团队加起来只有六七十号人,作为一个新人他得以和团队的每个人“拜码头“。入职第一天他的师父就带他见老苗(倪行军,花名苗人凤,现支付宝事业群总裁,大家叫他老苗)、鲁肃(程立,花名鲁肃,现蚂蚁金服CTO兼国际事业群COO,在蚂蚁金服内部被视为技术传说般的存在)。第一次见到鲁肃时鲁肃还在写代码,许寄回忆道:“鲁肃当时还站起来很客气的跟我握个手,当时我还不清楚大家是干什么的。现在新人入职哪有机会能见到传说中的老苗和鲁肃啊。”

5、“被逼着走出舒适区”

2007年加入支付宝是个幸运的时间节点。

那时候,支付宝用户已经过亿,用户数量还在快速飙升。我们做的任何决策,写的每一行代码,会影响到这么多用户,兴奋的同时深感舞台越大,责任也越大。

蚂蚁“既要……又要……还要”的企业文化,是基因决定的。作为一家金融科技公司,它既要互联网的快速交付,又要敏捷迭代的能力,还要给业务足够低的试错成本,同时在技术上不能出错。

作为底层的技术人员,既要负责交付,又要负责线上灭火,还要负责面向未来的技术储备。

我是社招P5入职的公司,这十几年来经历过不断打碎重建的过程。

曾经负责的一个大项目,足足花了两个月时间,自以为代码写得完美得不得了,结果鲁肃用两个小时,删了我三千行代码。心痛得要命,但又心服口服。

后来慢慢发现,在蚂蚁,所有人都会被逼着走出舒适区。因为我们做的事情,在15年前就走进了无人区。脚下是没路的,谁能舒舒服服地在无人区里活下来?

没想更大的挑战还在后面。2012年,我被扔去带国际业务的技术团队,从零开始创业。

过去三年,我们在9个一带一路沿线国家和地区,与当地合作伙伴一起落地了当地版支付宝,成绩听起来是不错,但其实我们每天都在遇山劈山,遇水搭桥。

编者语:

刚到支付宝的时候,许寄正好赶上一代架构到二代架构全面升级的阶段。几年时间内,他从开始的旁观者、学习者,慢慢的到了一个参与者,最终成长为二代三代时候的主导者。许寄表示:在支付宝工作后,整个人的眼界得到了较大的提升,知道了自己所该承担的责任,同时也变得更加自信。他分享道:“什么事情是会让你一直开心愿意做下去?一是有舞台,你愿意去干,有机会让你去干;二是你所从事的工作你确实很喜欢;三是能够收获别人的认可。”而这三点恰巧在支付宝的工作中都一一契合。


6、“技术出海”

东南亚各国合作伙伴的工程师,会轮番到杭州接受我们的技术培训,他们的宗教信仰、生活习惯我们都要照顾。

比如穆斯林同学过来,我们要订好面朝麦加的培训教室,清真食品,以及空出一天五次的礼拜时间。

我们团队不但要英语好,还要能在各种东南亚口音的英语中自由切换。

大家常常是在不同电话会议上,讲完印度英语,到马来西亚英语,到越南英语,到菲律宾英语……有次一个同学中途接了家人打来的电话,立马从印尼英语切换回东北话。

▲ 蚂蚁工程师在菲律宾与当地小伙伴们一起过生日

我们团队的工程师,是base在飞机上的一群人。

我们现在去东南亚,就跟出浙江省一样,每个人的护照都盖满了戳,根本用不到十年就要换。

我们的旅行箱里,必备几样东西:老干妈,转换插头,东南亚各国的电话卡;当地合作伙伴的工牌,每张都会标清楚哪个国家,哪幢楼,哪一层。每天一早醒来,得先定定神,想想今天自己是在新加坡还是越南。

虽然说起来都是泪,但比起成就感来,这些都算不上什么,真的。

东南亚都是现金大国,我们刚去的时候,钱包里鼓鼓囊囊地要装着各个国家的纸币,三年下来,我们的钱包在变薄变轻。

说白了,我们这一生,要找一个能够谋生的工作很容易,想找一家收入高的公司努力努力也能实现,但找到一个可以和一群非凡的人一起改变世界的舞台,真不多。

编者语:

经过五年的时间,由许寄负责的支付宝三代架构步入正轨。2012年5月,许寄几乎是单枪匹马的被“扔”到了国际业务。那个时候还没有蚂蚁国际事业部,他在这里的工作当于从零开始的创业过程,最开始是从集团电商支付业务开始接手,把集团大大小小的业务给承担起来,支持阿里的跨境电商业务。再后来,蚂蚁金服国际事业部建立,隶属于国际事业部的这支技术团队就变成了蚂蚁整个大技术平台的一个二级团队。随着业务发展的逐步壮大,大家意识到国际事业部的这支技术团队的技术体系和蚂蚁大技术平台的其他团队很不一样,它麻雀虽小但是五脏俱全。如今,许寄带领的国际事业群技术团队人数已接近千人,变成了蚂蚁金服国际事业群的专属团队。

在许寄及其团队的努力下,目前蚂蚁金服已经在9个国家和地区找到合作伙伴开发电子钱包,包括印度、泰国、印尼、韩国、马来西亚、菲律宾、巴基斯坦、中国香港和孟加拉。而这9个本地电子钱包中,做的最早目前也最成熟的是印度的Paytm。从2015年初到现在,Paytm用户从2300万上升为2.5亿,跃升为全球第三大电子钱包。印度用户可以用手机线上线下支付、转账、理财等。

▲ 印度Paytm

就在2018年6月5日,全球首个基于区块链的电子钱包跨境汇款服务在香港上线。港版支付宝AlipayHK的用户可以通过区块链技术向菲律宾钱包Gcash汇款。第一笔汇款由在港工作22年的菲律宾人格蕾丝(Grace)完成,耗时仅3秒,而在以前需要10分钟到几天不等,还要去线下网点排队。

▲ 区块链跨境汇款现场

7、一个技术人最简单的情怀

谈及接下来的工作规划,许寄表示将继续奋战在国际一线战场上。许寄及其团队是base在飞机上的一群人。夸张的时候,许寄几乎每天早上醒来都在与东南亚的不同国家进行本地沟通和支持。这个团队每个人的护照都盖满了戳,根本用不到十年就要换。他们的旅行箱里,必备几样东西:老干妈;转换插头,东南亚各国的电话卡;当地合作伙伴的工牌,每张都会标清楚哪个国家,哪幢楼,哪一层;每天一早醒来,先定定神,想想自己是在新加坡还是越南……

▲ 许寄及团队成员的护照,戳已经盖不下了

最后,许寄引用阿里巴巴合伙人王帅的一句话送给现在的年轻人:“对于年轻人来讲,舞台很重要。要是没有这么广阔的舞台,何处安放我们这么不安于平凡的灵魂?”

附录:更多感悟和思考文章

一个微信实习生自述:我眼中的微信开发团队

微信程序员创业总结:如何提高Android开发效率

如何做一个合格的 iOS Team Leader

程序员中年危机:拿什么拯救你,我的三十五岁

一个魔都程序员的3年:从程序员到CTO的历练

为什么说即时通讯社交APP创业就是一个坑?

致我们再也回不去的 Github ...

一名90后二流大学程序员的自述:我是如何从“菜鸟”到“辣鸡”的

一个魔都程序员的3年:从程序员到CTO的历练

选择比努力更重要:我是如何从流水线工人到程序员的?

程序员的抉择:必须离开帝都——因为除了工作机会,还有什么值得留恋?

即时通讯创业必读:解密微信的产品定位、创新思维、设计法则等

干了这碗鸡汤:从理发店小弟到阿里P10技术大牛

(本文同步发布于:http://www.52im.net/thread-1747-1-1.html

posted @ 2018-07-09 11:52 Jack Jiang 阅读(98) | 评论 (0)编辑 收藏

1、引言

本文接上篇《脑残式网络编程入门(一):跟着动画来学TCP三次握手和四次挥手》,继续脑残式的网络编程知识学习 ^_^。

套接字socket是大多数程序员都非常熟悉的概念,它是计算机网络编程的基础,TCP/UDP收发消息都靠它。我们熟悉的web服务器底层依赖它,我们用到的MySQL关系数据库、Redis内存数据库底层依赖它。我们用微信和别人聊天也依赖它,我们玩网络游戏时依赖它,读者们能够阅读这篇文章也是因为有它在背后默默地支持着网络通信。

本篇文章依然尝试使用动画图片的方式,来对这个知识点进行“脑残式”讲解(哈哈),期望读者们可以更加简单、直观地理解Socket通信的数据读写本质。

友情提示:如果您的网速较慢,加载gif动画可能较慢,请耐心等候哦。

学习交流:

- 即时通讯开发交流3群:185926912[推荐]

- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM

(本文同步发布于:http://www.52im.net/thread-1732-1-1.html

2、关于作者

钱文品(老钱):毕业于华中科技大学计算机科学与技术专业,互联网分布式高并发技术十年老兵,目前任掌阅科技资深后端工程师。熟练使用 Java、Python、Golang 等多种计算机语言,开发过游戏,制作过网站,写过消息推送系统和MySQL 中间件,实现过开源的 ORM 框架、Web 框架、RPC 框架等。

作者的Github: https://github.com/pyloque

3、系列文章

本文是系列文章中的第2篇,本系列大纲如下:

脑残式网络编程入门(一):跟着动画来学TCP三次握手和四次挥手

脑残式网络编程入门(二):我们在读写Socket时,究竟在读写什么?》(本文)

4、Socket读写的简单过程理解

当客户端和服务器使用TCP协议进行通信时,客户端封装一个请求对象req,将请求对象req序列化成字节数组,然后通过套接字socket将字节数组发送到服务器,服务器通过套接字socket读取到字节数组,再反序列化成请求对象req,进行处理,处理完毕后,生成一个响应对应res,将响应对象res序列化成字节数组,然后通过套接字将自己数组发送给客户端,客户端通过套接字socket读取到自己数组,再反序列化成响应对象。

通信框架往往可以将序列化的过程隐藏起来,我们所看到的现象就是上图所示,请求对象req和响应对象res在客户端和服务器之间跑来跑去。

也许你觉得这个过程还是挺简单的,很好理解,但是实际上背后发生的一系列事件超出了你们中大多数人的想象。通信的真实过程要比上面的这张图复杂太多。你也许会问,我们需要了解的那么深入么,直接拿来用不就可以了么?

在互联网技术服务行业工作多年的经验告诉我,如果你对底层机制不了解,你就会不明白为什么对套接字socket的读写会出现各种奇奇乖乖的问题,为什么有时会阻塞,有时又不阻塞,有时候还报错,为什么会有粘包半包问题,NIO具体又是什么,它是什么特别新鲜的技术么?对于这些问题的理解都需要你了解底层机制。

5、Socket读写的细节过程分析

为了方便大家对通信底层的理解,我花了些时间做了下面这个动画,它并不能完全覆盖底层细节的全貌,但是对于理解套接字的工作机制已经足够了。请读者仔细观察这个动画,后面的讲解将围绕着这个动画展开。

我们平时用到的套接字其实只是一个引用(一个对象ID),这个套接字对象实际上是放在操作系统内核中。这个套接字对象内部有两个重要的缓冲结构,一个是读缓冲(read buffer),一个是写缓冲(write buffer),它们都是有限大小的数组结构。

当我们对客户端的socket写入字节数组时(序列化后的请求消息对象req),是将字节数组拷贝到内核区套接字对象的write buffer中,内核网络模块会有单独的线程负责不停地将write buffer的数据拷贝到网卡硬件,网卡硬件再将数据送到网线,经过一些列路由器交换机,最终送达服务器的网卡硬件中。

同样,服务器内核的网络模块也会有单独的线程不停地将收到的数据拷贝到套接字的read buffer中等待用户层来读取。最终服务器的用户进程通过socket引用的read方法将read buffer中的数据拷贝到用户程序内存中进行反序列化成请求对象进行处理。然后服务器将处理后的响应对象走一个相反的流程发送给客户端,这里就不再具体描述。

5.1 细节过程:阻塞

我们注意到write buffer空间都是有限的,所以如果应用程序往套接字里写的太快,这个空间是会满的。一旦满了,写操作就会阻塞,直到这个空间有足够的位置腾出来。不过有了NIO(非阻塞IO),写操作也可以不阻塞,能写多少是多少,通过返回值来确定到底写进去多少,那些没有写进去的内容用户程序会缓存起来,后续会继续重试写入。

同样我们也注意到read buffer的内容可能会是空的。这样套接字的读操作(一般是读一个定长的字节数组)也会阻塞,直到read buffer中有了足够的内容(填充满字节数组)才会返回。有了NIO,就可以有多少读多少,无须阻塞了。读不够的,后续会继续尝试读取。

5.2 细节过程:ack

那上面这张图就展现了套接字的全部过程么?显然不是,数据的确认过程(ack)就完全没有展现。比如当写缓冲的内容拷贝到网卡后,是不会立即从写缓冲中将这些拷贝的内容移除的,而要等待对方的ack过来之后才会移除。如果网络状况不好,ack迟迟不过来,写缓冲很快就会满的。

5.3 细节过程:包头

细心的同学可能注意到图中的消息req被拷贝到网卡的时候变成了大写的REQ,这是为什么呢?因为这两个东西已经不是完全一样的了。内核的网络模块会将缓冲区的消息进行分块传输,如果缓冲区的内容太大,是会被拆分成多个独立的小消息包的。并且还要在每个消息包上附加上一些额外的头信息,比如源网卡地址和目标网卡地址、消息的序号等信息,到了接收端需要对这些消息包进行重新排序组装去头后才会扔进读缓冲中。这些复杂的细节过程就非常难以在动画上予以呈现了。

5.4 细节过程:速率

还有个问题那就是如果读缓冲满了怎么办,网卡收到了对方的消息要怎么处理?一般的做法就是丢弃掉不给对方ack,对方如果发现ack迟迟没有来,就会重发消息。那缓冲为什么会满?是因为消息接收方处理的慢而发送方生产的消息太快了,这时候tcp协议就会有个动态窗口调整算法来限制发送方的发送速率,使得收发效率趋于匹配。如果是udp协议的话,消息一丢那就彻底丢了。

网络协议内部实现还有更多复杂的细节有待继续挖掘,留着以后继续分析吧。

附录1:同类文章精选

如果您觉得本系列文章过于基础,您可直接阅读以下系列:

网络编程懒人入门(一):快速理解网络通信协议(上篇)

网络编程懒人入门(二):快速理解网络通信协议(下篇)

网络编程懒人入门(三):快速理解TCP协议一篇就够

网络编程懒人入门(四):快速理解TCP和UDP的差异

网络编程懒人入门(五):快速理解为什么说UDP有时比TCP更有优势

网络编程懒人入门(六):史上最通俗的集线器、交换机、路由器功能原理入门

网络编程懒人入门(七):深入浅出,全面理解HTTP协议

《不为人知的网络编程》系列文章为高阶必读,该系列目录如下:

不为人知的网络编程(一):浅析TCP协议中的疑难杂症(上篇)

不为人知的网络编程(二):浅析TCP协议中的疑难杂症(下篇)

不为人知的网络编程(三):关闭TCP连接时为什么会TIME_WAIT、CLOSE_WAIT

不为人知的网络编程(四):深入研究分析TCP的异常关闭

不为人知的网络编程(五):UDP的连接性和负载均衡

不为人知的网络编程(六):深入地理解UDP协议并用好它

关于移动端网络特性及优化手段的总结性文章请见:

现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障

移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”

移动端IM开发者必读(二):史上最全移动弱网络优化方法总结

附录2:参考资料

TCP/IP详解 - 第11章·UDP:用户数据报协议

TCP/IP详解 - 第17章·TCP:传输控制协议

TCP/IP详解 - 第18章·TCP连接的建立与终止

TCP/IP详解 - 第21章·TCP的超时与重传

通俗易懂-深入理解TCP协议(上):理论基础

通俗易懂-深入理解TCP协议(下):RTT、滑动窗口、拥塞处理

理论经典:TCP协议的3次握手与4次挥手过程详解

理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程

计算机网络通讯协议关系图(中文珍藏版)

高性能网络编程(一):单台服务器并发TCP连接数到底可以有多少

高性能网络编程(二):上一个10年,著名的C10K并发连接问题

高性能网络编程(三):下一个10年,是时候考虑C10M并发问题了

高性能网络编程(四):从C10K到C10M高性能网络应用的理论探索

简述传输层协议TCP和UDP的区别

为什么QQ用的是UDP协议而不是TCP协议?

移动端即时通讯协议选择:UDP还是TCP?

技术往事:改变世界的TCP/IP协议(珍贵多图、手机慎点)

UDP中一个包的大小最大能多大?

Java新一代网络编程模型AIO原理及Linux系统AIO介绍

NIO框架入门(一):服务端基于Netty4的UDP双向通信Demo演示

NIO框架入门(二):服务端基于MINA2的UDP双向通信Demo演示

NIO框架入门(三):iOS与MINA2、Netty4的跨平台UDP双向通信实战

NIO框架入门(四):Android与MINA2、Netty4的跨平台UDP双向通信实战

P2P技术详解(一):NAT详解——详细原理、P2P简介

P2P技术详解(二):P2P中的NAT穿越(打洞)方案详解

P2P技术详解(三):P2P技术之STUN、TURN、ICE详解

通俗易懂:快速理解P2P技术中的NAT穿透原理

>> 更多同类文章 ……

(本文同步发布于:http://www.52im.net/thread-1732-1-1.html

posted @ 2018-07-05 14:19 Jack Jiang 阅读(115) | 评论 (0)编辑 收藏

、引言

网络编程中TCP协议的三次握手和四次挥手的问题,在面试中是最为常见的知识点之一。很多读者都知道“三次”和“四次”,但是如果问深入一点,他们往往都无法作出准确回答。

本篇文章尝试使用动画图片的方式,来对这个知识点进行“脑残式”讲解(哈哈),期望读者们可以更加简单、直观地理解TCP网络通信交互的本质。

另外,社区里的另两篇文章《理论经典:TCP协议的3次握手与4次挥手过程详解》、《理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程》也是不错的入门文章,有兴趣可一并详读之。

友情提示:因本文gif动画较多,如果您的网速较慢,请耐心等候图片加载完成哦。

学习交流:

- 即时通讯开发交流3群:185926912[推荐]

- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM

(本文同步发布于:http://www.52im.net/thread-1729-1-1.html

2、关于作者

钱文品(老钱):毕业于华中科技大学计算机科学与技术专业,互联网分布式高并发技术十年老兵,目前任掌阅科技资深后端工程师。熟练使用 Java、Python、Golang 等多种计算机语言,开发过游戏,制作过网站,写过消息推送系统和MySQL 中间件,实现过开源的 ORM 框架、Web 框架、RPC 框架等。

作者的Github: https://github.com/pyloque

3、系列文章

本文是系列文章中的第1篇,本系列大纲如下:

脑残式网络编程入门(一):跟着动画来学TCP三次握手和四次挥手》(本文)

《脑残式网络编程入门(二):我们在读写Socket时,究竟在读写什么?》

4、TCP 三次握手:“Say hello !”

TCP 三次握手就好比两个人在街上隔着50米看见了对方,但是因为雾霾等原因不能100%确认,所以要通过招手的方式相互确定对方是否认识自己。

张三首先向李四招手(syn),李四看到张三向自己招手后,向对方点了点头挤出了一个微笑(ack)。张三看到李四微笑后确认了李四成功辨认出了自己(进入estalished状态)。

但是李四还有点狐疑,向四周看了一看,有没有可能张三是在看别人呢,他也需要确认一下。所以李四也向张三招了招手(syn),张三看到李四向自己招手后知道对方是在寻求自己的确认,于是也点了点头挤出了微笑(ack),李四看到对方的微笑后确认了张三就是在向自己打招呼(进入established状态)。

于是两人加快步伐,走到了一起,相互拥抱。

我们看到这个过程中一共是四个动作,张三招手--李四点头微笑--李四招手--张三点头微笑。其中李四连续进行了2个动作,先是点头微笑(回复对方),然后再次招手(寻求确认),实际上可以将这两个动作合一,招手的同时点头和微笑(syn+ack)。于是四个动作就简化成了三个动作,张三招手--李四点头微笑并招手--张三点头微笑。这就是三次握手的本质,中间的一次动作是两个动作的合并。

我们看到有两个中间状态,syn_sent和syn_rcvd,这两个状态叫着「半打开」状态,就是向对方招手了,但是还没来得及看到对方的点头微笑。syn_sent是主动打开方的「半打开」状态,syn_rcvd是被动打开方的「半打开」状态。客户端是主动打开方,服务器是被动打开方。

syn_sent: syn package has been sent

syn_rcvd: syn package has been received

5、握手完成:开始TCP 数据传输

TCP 数据传输就是两个人隔空对话,差了一点距离,所以需要对方反复确认听见了自己的话。

张三喊了一句话(data),李四听见了之后要向张三回复自己听见了(ack)。

如果张三喊了一句,半天没听到李四回复,张三就认为自己的话被大风吹走了,李四没听见,所以需要重新喊话,这就是tcp重传。

也有可能是李四听到了张三的话,但是李四向张三的回复被大风吹走了,以至于张三没听见李四的回复。张三并不能判断究竟是自己的话被大风吹走了还是李四的回复被大风吹走了,张三也不用管,重传一下就是。

既然会重传,李四就有可能同一句话听见了两次,这就是「去重」。「重传」和「去重」工作操作系统的网络内核模块都已经帮我们处理好了,用户层是不用关心的。

张三可以向李四喊话,同样李四也可以向张三喊话,因为tcp链接是「双工的」,双方都可以主动发起数据传输。不过无论是哪方喊话,都需要收到对方的确认才能认为对方收到了自己的喊话。

张三可能是个高射炮,一说连说了八句话,这时候李四可以不用一句一句回复,而是连续听了这八句话之后,一起向对方回复说前面你说的八句话我都听见了,这就是批量ack。但是张三也不能一次性说了太多话,李四的脑子短时间可能无法消化太多,两人之间需要有协商好的合适的发送和接受速率,这个就是「TCP窗口大小」。

网络环境的数据交互同人类之间的对话还要复杂一些,它存在数据包乱序的现象。同一个来源发出来的不同数据包在「网际路由」上可能会走过不同的路径,最终达到同一个地方时,顺序就不一样了。操作系统的网络内核模块会负责对数据包进行排序,到用户层时顺序就已经完全一致了。

6、TCP 四次挥手:“Say goodbye!”

TCP断开链接的过程和建立链接的过程比较类似,只不过中间的两部并不总是会合成一步走,所以它分成了4个动作,张三挥手(fin)——李四伤感地微笑(ack)——李四挥手(fin)——张三伤感地微笑(ack)。

之所以中间的两个动作没有合并,是因为tcp存在「半关闭」状态,也就是单向关闭。张三已经挥了手,可是人还没有走,只是不再说话,但是耳朵还是可以继续听,李四呢继续喊话。等待李四累了,也不再说话了,超张三挥了挥手,张三伤感地微笑了一下,才彻底结束了。

上面有一个非常特殊的状态time_wait,它是主动关闭的一方在回复完对方的挥手后进入的一个长期状态,这个状态标准的持续时间是4分钟,4分钟后才会进入到closed状态,释放套接字资源。不过在具体实现上这个时间是可以调整的。

它就好比主动分手方要承担的责任,是你提出的要分手,你得付出代价。这个后果就是持续4分钟的time_wait状态,不能释放套接字资源(端口),就好比守寡期,这段时间内套接字资源(端口)不得回收利用。

它的作用是重传最后一个ack报文,确保对方可以收到。因为如果对方没有收到ack的话,会重传fin报文,处于time_wait状态的套接字会立即向对方重发ack报文。

同时在这段时间内,该链接在对话期间于网际路由上产生的残留报文(因为路径过于崎岖,数据报文走的时间太长,重传的报文都收到了,原始报文还在路上)传过来时,都会被立即丢弃掉。4分钟的时间足以使得这些残留报文彻底消逝。不然当新的端口被重复利用时,这些残留报文可能会干扰新的链接。

4分钟就是2个MSL,每个MSL是2分钟。MSL就是maximium segment lifetime——最长报文寿命。这个时间是由官方RFC协议规定的。至于为什么是2个MSL而不是1个MSL,我还没有看到一个非常满意的解释。

四次挥手也并不总是四次挥手,中间的两个动作有时候是可以合并一起进行的,这个时候就成了三次挥手,主动关闭方就会从fin_wait_1状态直接进入到time_wait状态,跳过了fin_wait_2状态。

7、本文小结

TCP状态转换是一个非常复杂的过程,本文仅对一些简单的基础知识点进行了类比讲解。关于TCP的更多知识还需要读者去搜寻相关技术文章进入深入学习。如果读者对TCP的基础知识掌握得比较牢固,高级的知识理解起来就不会太过于吃力。

附录1:同类文章精选

如果您觉得本系列文章过于基础,您可直接阅读以下系列:

网络编程懒人入门(一):快速理解网络通信协议(上篇)

网络编程懒人入门(二):快速理解网络通信协议(下篇)

网络编程懒人入门(三):快速理解TCP协议一篇就够

网络编程懒人入门(四):快速理解TCP和UDP的差异

网络编程懒人入门(五):快速理解为什么说UDP有时比TCP更有优势

网络编程懒人入门(六):史上最通俗的集线器、交换机、路由器功能原理入门

网络编程懒人入门(七):深入浅出,全面理解HTTP协议

《不为人知的网络编程》系列文章为高阶必读,该系列目录如下:

不为人知的网络编程(一):浅析TCP协议中的疑难杂症(上篇)

不为人知的网络编程(二):浅析TCP协议中的疑难杂症(下篇)

不为人知的网络编程(三):关闭TCP连接时为什么会TIME_WAIT、CLOSE_WAIT

不为人知的网络编程(四):深入研究分析TCP的异常关闭

不为人知的网络编程(五):UDP的连接性和负载均衡

不为人知的网络编程(六):深入地理解UDP协议并用好它

关于移动端网络特性及优化手段的总结性文章请见:

现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障

移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”

移动端IM开发者必读(二):史上最全移动弱网络优化方法总结

附录2:参考资料

TCP/IP详解 - 第11章·UDP:用户数据报协议

TCP/IP详解 - 第17章·TCP:传输控制协议

TCP/IP详解 - 第18章·TCP连接的建立与终止

TCP/IP详解 - 第21章·TCP的超时与重传

通俗易懂-深入理解TCP协议(上):理论基础

通俗易懂-深入理解TCP协议(下):RTT、滑动窗口、拥塞处理

理论经典:TCP协议的3次握手与4次挥手过程详解

理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程

计算机网络通讯协议关系图(中文珍藏版)

高性能网络编程(一):单台服务器并发TCP连接数到底可以有多少

高性能网络编程(二):上一个10年,著名的C10K并发连接问题

高性能网络编程(三):下一个10年,是时候考虑C10M并发问题了

高性能网络编程(四):从C10K到C10M高性能网络应用的理论探索

简述传输层协议TCP和UDP的区别

为什么QQ用的是UDP协议而不是TCP协议?

移动端即时通讯协议选择:UDP还是TCP?

技术往事:改变世界的TCP/IP协议(珍贵多图、手机慎点)

UDP中一个包的大小最大能多大?

Java新一代网络编程模型AIO原理及Linux系统AIO介绍

NIO框架入门(一):服务端基于Netty4的UDP双向通信Demo演示

NIO框架入门(二):服务端基于MINA2的UDP双向通信Demo演示

NIO框架入门(三):iOS与MINA2、Netty4的跨平台UDP双向通信实战

NIO框架入门(四):Android与MINA2、Netty4的跨平台UDP双向通信实战

P2P技术详解(一):NAT详解——详细原理、P2P简介

P2P技术详解(二):P2P中的NAT穿越(打洞)方案详解

P2P技术详解(三):P2P技术之STUN、TURN、ICE详解

通俗易懂:快速理解P2P技术中的NAT穿透原理

>> 更多同类文章 ……

(本文同步发布于:http://www.52im.net/thread-1729-1-1.html

posted @ 2018-07-04 14:49 Jack Jiang 阅读(125) | 评论 (0)编辑 收藏

     摘要: 注:本文原题《微信的操作系统之路》,来自2018年6月23日的创投理想国线下嘉宾陆树燊的分享会总结(原分享四万余字,本文删减至六千字精华),发表于陆树燊的公众号“行者慎思”。1、引言这些年来,中国互联网很少有像微信这样影响巨大的产品。因此,今天我想基于微信发展过程中的关键决策,提供一些思考。我会从四个部分分析它:1)用户在微信发展早期对它的定位:聊天工具;2)本周引发最多讨...  阅读全文

posted @ 2018-07-02 15:28 Jack Jiang 阅读(38) | 评论 (0)编辑 收藏

     摘要: 本文原作者:“水晶虾饺”,原文由“玉刚说”写作平台提供写作赞助,原文版权归“玉刚说”微信公众号所有,即时通讯网收录时有改动。1、引言好多小白初次接触即时通讯(比如:IM或者消息推送应用)时,总是不能理解Web短连接(就是最常见的HTTP通信了)跟长连接(主要指TCP、UDP协议实现的socket通信,当然HTML5里的Webs...  阅读全文

posted @ 2018-06-29 17:19 Jack Jiang 阅读(874) | 评论 (0)编辑 收藏

     摘要: 本文原作者阮一峰,作者博客:ruanyifeng.com。1、引言HTTP 协议是最重要的互联网基础协议之一,它从最初的仅为浏览网页的目的进化到现在,已经是短连接通信的事实工业标准,最新版本 HTTP/2 更是让它再次成为技术热点。作为即时通讯开发者来说,深刻理解HTTP协议有助于在现今复杂移动网络环境下的优化和最佳实践的开展,本文将通俗易懂的地介绍 HTTP 协议的历史演变和设计思路。学习交流:...  阅读全文

posted @ 2018-06-27 15:15 Jack Jiang 阅读(63) | 评论 (0)编辑 收藏

     摘要: 本文由腾讯云技术团队原创,感谢作者的分享。1、前言微信小程序提供了一套在微信上运行小程序的解决方案,有比较完整的框架、组件以及 API,在这个平台上面的想象空间很大。腾讯云研究了一番之后,发现微信支持 WebSocket 还是很值得玩味的。这个特性意味着我们可以做一些实时同步或者协作的小程序。这篇文章分享了一个基于WebSocket长连接的微信小程序——简单的剪刀石头布小游...  阅读全文

posted @ 2018-06-25 15:46 Jack Jiang 阅读(134) | 评论 (0)编辑 收藏

     摘要: 原作者:阮一峰(ruanyifeng.com),现重新整理发布,感谢原作者的无私分享。1、引言今天中午,我突然想搞清楚 Unicode 和 UTF-8 之间的关系,就开始查资料。这个问题比我想象的复杂,午饭后一直看到晚上9点,才算初步搞清楚。下面就是我的总结,主要用来整理自己的思路。我尽量写得通俗易懂,希望能对其他朋友有用。毕竟,字符编码是计算机技术的基石,对于程序员来说尤其重要,字符编码的知识是...  阅读全文

posted @ 2018-06-21 16:32 Jack Jiang 阅读(647) | 评论 (0)编辑 收藏

     摘要: 本文引用了刘欣的文章,感谢原作者的分享。1、引言Http协议在现今主流的IM系统中拥有无可替代的重要性(在IM系统中用HTTP发起的连接被大家简称为http短连接),但Http作为传统互联网信息交换技术,一些典型的概念比如:Session、Token,对于新手程序员来说很陌生。很多文章动辄长篇大论、高屋建瓴地从底层协议再到上层分布式应用式的讲解,根本不适合傻白甜程序员,本文的写作目的是以最白话地方...  阅读全文

posted @ 2018-06-19 11:27 Jack Jiang 阅读(536) | 评论 (0)编辑 收藏

     摘要: 本文引用了自简书作者“涤生_Woo”的文章,内容有删减,感谢原作者的分享。1、前言HTTP(全称超文本传输协议,英文全称HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。对于移动端即时通讯(尤其IM应用)来说,现今主流的数据通信总...  阅读全文

posted @ 2018-06-15 17:46 Jack Jiang 阅读(90) | 评论 (0)编辑 收藏

     摘要: 1、前言在IM这种讲究高并发、高消息吞吐的互联网场景下,MQ消息中间件是个很重要的基础设施,它在IM系统的服务端架构中担当消息中转、消息削峰、消息交换异步化等等角色,当然MQ消息中间件的作用远不止于此,它的价值不仅仅存在于技术上,更重要的是改变了以往同步处理消息的思路(比如进行IM消息历史存储时,传统的信息系统作法可能是收到一条消息就马上同步存入数据库,这种作法在小并发量的情况下可以很好的工作,但...  阅读全文

posted @ 2018-06-12 15:13 Jack Jiang 阅读(722) | 评论 (0)编辑 收藏

     摘要: 1、前言有人说 2017 年是 WebRTC 的转折之年,2018 年将是 WebRTC 的爆发之年,这并非没有根据。就在去年(2017年),WebRTC 1.0 标准草案出炉(实际上WebRTC标准草案的早期版本早在2011年就已经发布,WebRTC并非一夜之间就出现的技术),并将于今年正式发布。与此同时,越来越多的浏览器和厂商都开始对它进行广泛的支持,WebRTC 即将成为互联网的基础设施了,...  阅读全文

posted @ 2018-06-04 12:25 Jack Jiang 阅读(89) | 评论 (0)编辑 收藏

     摘要: 本文原作者: 夏之南,感谢原作者的分享。1、前言不知不觉,微信已经诞生七年了。 从第一版到现在,微信的演变史,很像一部创业史,很好地诠释了创业者能经得起多少质疑和差评,才配拥有多大的成功。编者注:微信作为移动端IM的标杆,无论是产品定义还是技术追求(关于微信团队对技术的极致追求,可以在即时通讯网找到很多微信团队分享的文章,从文字中完全可以理解微信团队的技术追求),都值得广大即时通讯技术开发者学习。...  阅读全文

posted @ 2018-05-30 13:27 Jack Jiang 阅读(42) | 评论 (0)编辑 收藏

     摘要: 本文来自七牛云Android 多媒体开发工程师卢俊的技术分享,即时通讯网有改动。1、前言这是由一篇我的演讲稿整理出来的文章,目标读者是对实时音视频开发感兴趣但是又不知道如何下手的初学者们,希望把我的经验分享出来,对大家有所帮助。学习交流:- 即时通讯开发交流3群:185926912[推荐]- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》(本文同步发布于:http://www.5...  阅读全文

posted @ 2018-05-28 12:16 Jack Jiang 阅读(471) | 评论 (0)编辑 收藏

     摘要: 1、前言IM的群聊消息,究竟存1份(即扩散读方式)还是存多份(即扩散写方式)?上一篇文章《IM群聊消息的已读回执功能该怎么实现?》是说,“很容易想到,是存一份”,被网友们骂了,大家争论的很激烈(见下图)。 网友骂的对,任何技术方案,都不是天才般灵感乍现想到的,一定是一个演进迭代,逐步优化的过程。今天就聊一聊,IM群聊消息,为啥只需要存一份。不过,从公开的技术资料来...  阅读全文

posted @ 2018-05-25 12:25 Jack Jiang 阅读(334) | 评论 (0)编辑 收藏

     摘要: 本文引用了架构师之路公众号作者沈剑的文章,内容有改动,感谢原作者。1、前言我们平时在使用即时通讯应用时候,每当发出一条聊天消息,都希望对方尽快看到,并尽快回复,但对方到底有没有真的看到?我却并不知道。一个残酷的现实是,很多时候对方其实是早就已经看到了这条消息,但出出种种原因(大家都懂的),通常都是默默返回——假装没看见。像微信这样的熟人社交工具,在产品的设计理念上,为了保持...  阅读全文

posted @ 2018-05-23 12:49 Jack Jiang 阅读(517) | 评论 (0)编辑 收藏

     摘要: 本文来自微信技术架构部的原创技术分享。1、前言在上篇《IPv6技术详解:基本概念、应用现状、技术实践(上篇)》,我们讲解了IPV6的基本概念。本篇将继续从以下方面展开对IPV6的讲解:IPv6在Linux操作系统下的实现;IPv6的实验;IPv6的过渡技术介绍;IPv6在Linux平台下socket编程应该注意的问题。如您对IPV6的基本概念尚未了解,请先阅读本文的上篇。学习交流:- 即时通讯开发...  阅读全文

posted @ 2018-05-21 12:06 Jack Jiang 阅读(310) | 评论 (0)编辑 收藏

     摘要: 本文来自微信技术架构部的原创技术分享。1、前言普及IPV6喊了多少年了,连苹果的APP上架App Store也早已强制IPV6的支持,然并卵,因为历史遗留问题,即使在IPV4地址如果饥荒的情况下,所谓的普及还是遥遥无期。但不可否认的是,IPV6肯定是未来趋势,做为网络通信领域的程序员来说,详细学习和了解IPV6是很有必要的,所谓厚积薄发,谁知道哪天IPV6真的普及了呢?那么,我们开始看正文吧。学习...  阅读全文

posted @ 2018-05-18 15:14 Jack Jiang 阅读(329) | 评论 (0)编辑 收藏

     摘要: 本系列文章引用了腾讯技术专家樊华恒《海量之道系列文章之弱联网优化》的部分章节,感谢原作者。1、前言随着移动互联网的高速发展,移动端IM以移动网络作为物理通信载体早已深入人心,这其中的成功者就包括微信、手机QQ、支付宝(从即时通讯产品的角度来看,支付宝已经算的上是半个IM了)等等,也为移动端即时通讯开发者带来了各种可以参考的标杆功能和理念:语音对讲、具有移动端体验特性的图片消息、全时在线的概念、真正...  阅读全文

posted @ 2018-05-11 13:19 Jack Jiang 阅读(432) | 评论 (0)编辑 收藏

     摘要: 本文引用了作者Smily(博客:blog.csdn.net/qq_20521573)的文章内容,感谢无私分享。1、前言目前苹果公司已经强制iOS应用必须使用HTTPS协议开发(详见《苹果即将强制实施 ATS,你的APP准备好切换到HTTPS了吗?》),虽然Google没有强制开发者使用HTTPS,但相信不久的将来Android也会跟随iOS全面转向HTTPS。因此,HTTPS的学习也是相当重要。本...  阅读全文

posted @ 2018-05-07 11:47 Jack Jiang 阅读(580) | 评论 (0)编辑 收藏

Jack Jiang的 Mail: jb2011@163.com, 联系QQ: 413980957, 微信: hellojackjiang