Jack Jiang

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

2018年1月18日

     摘要: 本文原作者阮一峰,作者博客: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 阅读(8) | 评论 (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 阅读(150) | 评论 (0)编辑 收藏

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

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

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

posted @ 2018-07-11 14:49 Jack Jiang 阅读(24) | 评论 (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 阅读(26) | 评论 (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 阅读(47) | 评论 (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 阅读(60) | 评论 (0)编辑 收藏

     摘要: 注:本文原题《微信的操作系统之路》,来自2018年6月23日的创投理想国线下嘉宾陆树燊的分享会总结(原分享四万余字,本文删减至六千字精华),发表于陆树燊的公众号“行者慎思”。1、引言这些年来,中国互联网很少有像微信这样影响巨大的产品。因此,今天我想基于微信发展过程中的关键决策,提供一些思考。我会从四个部分分析它:1)用户在微信发展早期对它的定位:聊天工具;2)本周引发最多讨...  阅读全文

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

     摘要: 本文原作者:“水晶虾饺”,原文由“玉刚说”写作平台提供写作赞助,原文版权归“玉刚说”微信公众号所有,即时通讯网收录时有改动。1、引言好多小白初次接触即时通讯(比如:IM或者消息推送应用)时,总是不能理解Web短连接(就是最常见的HTTP通信了)跟长连接(主要指TCP、UDP协议实现的socket通信,当然HTML5里的Webs...  阅读全文

posted @ 2018-06-29 17:19 Jack Jiang 阅读(460) | 评论 (0)编辑 收藏

     摘要: 本文原作者阮一峰,作者博客:ruanyifeng.com。1、引言HTTP 协议是最重要的互联网基础协议之一,它从最初的仅为浏览网页的目的进化到现在,已经是短连接通信的事实工业标准,最新版本 HTTP/2 更是让它再次成为技术热点。作为即时通讯开发者来说,深刻理解HTTP协议有助于在现今复杂移动网络环境下的优化和最佳实践的开展,本文将通俗易懂的地介绍 HTTP 协议的历史演变和设计思路。学习交流:...  阅读全文

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

     摘要: 本文由腾讯云技术团队原创,感谢作者的分享。1、前言微信小程序提供了一套在微信上运行小程序的解决方案,有比较完整的框架、组件以及 API,在这个平台上面的想象空间很大。腾讯云研究了一番之后,发现微信支持 WebSocket 还是很值得玩味的。这个特性意味着我们可以做一些实时同步或者协作的小程序。这篇文章分享了一个基于WebSocket长连接的微信小程序——简单的剪刀石头布小游...  阅读全文

posted @ 2018-06-25 15:46 Jack Jiang 阅读(42) | 评论 (0)编辑 收藏

     摘要: 原作者:阮一峰(ruanyifeng.com),现重新整理发布,感谢原作者的无私分享。1、引言今天中午,我突然想搞清楚 Unicode 和 UTF-8 之间的关系,就开始查资料。这个问题比我想象的复杂,午饭后一直看到晚上9点,才算初步搞清楚。下面就是我的总结,主要用来整理自己的思路。我尽量写得通俗易懂,希望能对其他朋友有用。毕竟,字符编码是计算机技术的基石,对于程序员来说尤其重要,字符编码的知识是...  阅读全文

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

     摘要: 本文引用了刘欣的文章,感谢原作者的分享。1、引言Http协议在现今主流的IM系统中拥有无可替代的重要性(在IM系统中用HTTP发起的连接被大家简称为http短连接),但Http作为传统互联网信息交换技术,一些典型的概念比如:Session、Token,对于新手程序员来说很陌生。很多文章动辄长篇大论、高屋建瓴地从底层协议再到上层分布式应用式的讲解,根本不适合傻白甜程序员,本文的写作目的是以最白话地方...  阅读全文

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

     摘要: 本文引用了自简书作者“涤生_Woo”的文章,内容有删减,感谢原作者的分享。1、前言HTTP(全称超文本传输协议,英文全称HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。对于移动端即时通讯(尤其IM应用)来说,现今主流的数据通信总...  阅读全文

posted @ 2018-06-15 17:46 Jack Jiang 阅读(50) | 评论 (0)编辑 收藏

     摘要: 1、前言在IM这种讲究高并发、高消息吞吐的互联网场景下,MQ消息中间件是个很重要的基础设施,它在IM系统的服务端架构中担当消息中转、消息削峰、消息交换异步化等等角色,当然MQ消息中间件的作用远不止于此,它的价值不仅仅存在于技术上,更重要的是改变了以往同步处理消息的思路(比如进行IM消息历史存储时,传统的信息系统作法可能是收到一条消息就马上同步存入数据库,这种作法在小并发量的情况下可以很好的工作,但...  阅读全文

posted @ 2018-06-12 15:13 Jack Jiang 阅读(493) | 评论 (0)编辑 收藏

     摘要: 1、前言有人说 2017 年是 WebRTC 的转折之年,2018 年将是 WebRTC 的爆发之年,这并非没有根据。就在去年(2017年),WebRTC 1.0 标准草案出炉(实际上WebRTC标准草案的早期版本早在2011年就已经发布,WebRTC并非一夜之间就出现的技术),并将于今年正式发布。与此同时,越来越多的浏览器和厂商都开始对它进行广泛的支持,WebRTC 即将成为互联网的基础设施了,...  阅读全文

posted @ 2018-06-04 12:25 Jack Jiang 阅读(34) | 评论 (0)编辑 收藏

     摘要: 本文原作者: 夏之南,感谢原作者的分享。1、前言不知不觉,微信已经诞生七年了。 从第一版到现在,微信的演变史,很像一部创业史,很好地诠释了创业者能经得起多少质疑和差评,才配拥有多大的成功。编者注:微信作为移动端IM的标杆,无论是产品定义还是技术追求(关于微信团队对技术的极致追求,可以在即时通讯网找到很多微信团队分享的文章,从文字中完全可以理解微信团队的技术追求),都值得广大即时通讯技术开发者学习。...  阅读全文

posted @ 2018-05-30 13:27 Jack Jiang 阅读(26) | 评论 (0)编辑 收藏

     摘要: 本文来自七牛云Android 多媒体开发工程师卢俊的技术分享,即时通讯网有改动。1、前言这是由一篇我的演讲稿整理出来的文章,目标读者是对实时音视频开发感兴趣但是又不知道如何下手的初学者们,希望把我的经验分享出来,对大家有所帮助。学习交流:- 即时通讯开发交流3群:185926912[推荐]- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》(本文同步发布于:http://www.5...  阅读全文

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

     摘要: 1、前言IM的群聊消息,究竟存1份(即扩散读方式)还是存多份(即扩散写方式)?上一篇文章《IM群聊消息的已读回执功能该怎么实现?》是说,“很容易想到,是存一份”,被网友们骂了,大家争论的很激烈(见下图)。 网友骂的对,任何技术方案,都不是天才般灵感乍现想到的,一定是一个演进迭代,逐步优化的过程。今天就聊一聊,IM群聊消息,为啥只需要存一份。不过,从公开的技术资料来...  阅读全文

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

     摘要: 本文引用了架构师之路公众号作者沈剑的文章,内容有改动,感谢原作者。1、前言我们平时在使用即时通讯应用时候,每当发出一条聊天消息,都希望对方尽快看到,并尽快回复,但对方到底有没有真的看到?我却并不知道。一个残酷的现实是,很多时候对方其实是早就已经看到了这条消息,但出出种种原因(大家都懂的),通常都是默默返回——假装没看见。像微信这样的熟人社交工具,在产品的设计理念上,为了保持...  阅读全文

posted @ 2018-05-23 12:49 Jack Jiang 阅读(325) | 评论 (0)编辑 收藏

     摘要: 本文来自微信技术架构部的原创技术分享。1、前言在上篇《IPv6技术详解:基本概念、应用现状、技术实践(上篇)》,我们讲解了IPV6的基本概念。本篇将继续从以下方面展开对IPV6的讲解:IPv6在Linux操作系统下的实现;IPv6的实验;IPv6的过渡技术介绍;IPv6在Linux平台下socket编程应该注意的问题。如您对IPV6的基本概念尚未了解,请先阅读本文的上篇。学习交流:- 即时通讯开发...  阅读全文

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

     摘要: 本文来自微信技术架构部的原创技术分享。1、前言普及IPV6喊了多少年了,连苹果的APP上架App Store也早已强制IPV6的支持,然并卵,因为历史遗留问题,即使在IPV4地址如果饥荒的情况下,所谓的普及还是遥遥无期。但不可否认的是,IPV6肯定是未来趋势,做为网络通信领域的程序员来说,详细学习和了解IPV6是很有必要的,所谓厚积薄发,谁知道哪天IPV6真的普及了呢?那么,我们开始看正文吧。学习...  阅读全文

posted @ 2018-05-18 15:14 Jack Jiang 阅读(273) | 评论 (0)编辑 收藏

     摘要: 本系列文章引用了腾讯技术专家樊华恒《海量之道系列文章之弱联网优化》的部分章节,感谢原作者。1、前言随着移动互联网的高速发展,移动端IM以移动网络作为物理通信载体早已深入人心,这其中的成功者就包括微信、手机QQ、支付宝(从即时通讯产品的角度来看,支付宝已经算的上是半个IM了)等等,也为移动端即时通讯开发者带来了各种可以参考的标杆功能和理念:语音对讲、具有移动端体验特性的图片消息、全时在线的概念、真正...  阅读全文

posted @ 2018-05-11 13:19 Jack Jiang 阅读(338) | 评论 (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 阅读(506) | 评论 (0)编辑 收藏

     摘要: 1、前言微信朋友圈包括图片和视频两套业务架构组成,朋友圈图片的特点是请求量大、消耗计算资源较多,视频则主要消耗带宽。朋友圈的数据是永远存储的,而且随着业务的快速发展,存储容量、带宽和设备的消耗大量增加,尤其重大节日带来的使用量增长,更加剧了消耗,也给运维人员的保障带来了巨大压力。在重在节假日节点,技术保障主要由三方面组成:1)软件保障指通过程序、业务逻辑层面的优化和评估,减轻负载;2)硬件保障主要...  阅读全文

posted @ 2018-05-04 18:14 Jack Jiang 阅读(443) | 评论 (0)编辑 收藏

     摘要: 1、前言2017 年 12 月,微信小程序向开发者开放了实时音视频能力,给业内带来广阔的想象空间。连麦互动视频直播技术在 2016 年直播风口中成为视频直播的标配,然而只有在原生的 APP 上才能保障良好的用户体验。那时候,在微信小程序中无法进行实时音视频互动。微信小程序在去年 12 月宣布开放实时音视频能力,再加上去年 6 月苹果宣布即将支持 WebRTC,业内一下子千树万树梨花开,前途一片光明...  阅读全文

posted @ 2018-05-02 11:10 Jack Jiang 阅读(420) | 评论 (0)编辑 收藏

     摘要: 1、前言每年年初腾讯公司都要制定 SNG 成本优化年度目标,过去三年已经用技术手段为公司节省了超过 10 亿的现金流。产品的架构和容量也越来越健康,继续成本优化变得十分艰难。但我们在迷茫中仍然定下了再优化 3 亿元的目标。很幸运,2017 年我们实现了这个目标,并再次获得公司级奖励,这是非常不容易的。因为“成本与质量”是个平衡木,而 2017 年 SNG 产品面临着激烈的内...  阅读全文

posted @ 2018-04-28 10:51 Jack Jiang 阅读(443) | 评论 (0)编辑 收藏

     摘要: 本文来自微信开发团队WeMobileDev公众号的技术分享。1、前言微信的移动客户端全文搜索中的多音字问题一直是搜索体验的痛点之一。微信客户端全文搜索在上线以后,也经常收到用户关于多音字问题的反馈。所以,微信全文搜索中的多音字搜索成了一个迫切需要解决的问题。本文重点讲述微信安卓客户端在SQLite FTS5的基础上,多音字问题的解决方案。另外:微信团队在另一个文章《微信手机端的本地数据全文检索优化...  阅读全文

posted @ 2018-04-17 16:36 Jack Jiang 阅读(392) | 评论 (0)编辑 收藏

本文作者:丁同舟,来自金蝶随手记技术团队。

1、前言

本文接上篇《金蝶随手记团队分享:还在用JSON? Protobuf让数据传输更省更快(原理篇)》,以iOS端的Objective-C代码为例,向您演示如何使用Protobuf。

学习交流:

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

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

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

2、系列文章

本文是系列文章中的第2篇,总目录如下:

金蝶随手记团队分享:还在用JSON? Protobuf让数据传输更省更快(原理篇)

金蝶随手记团队分享:还在用JSON? Protobuf让数据传输更省更快(实战篇)》(本文)

另外,如果您还打算系统地了解IM的开发知识,可以阅读《新手入门一篇就够:从零开发移动端IM》。

3、参考资料

Protobuf通信协议详解:代码演示、详细原理介绍等

一个基于Protocol Buffer的Java代码演示

如何选择即时通讯应用的数据传输格式

强列建议将Protobuf作为你的即时通讯应用数据传输格式

全方位评测:Protobuf性能到底有没有比JSON快5倍?

移动端IM开发需要面对的技术问题(含通信协议选择)

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

理论联系实际:一套典型的IM通信协议设计详解

详解如何在NodeJS中使用Google的Protobuf

>> 更多同类文章 ……

4、基本介绍

Protocol buffers为 Google 提出的一种跨平台、多语言支持且开源的序列化数据格式。相对于类似的 XML 和 JSON,Protocol buffers 更为小巧、快速和简单。其语法目前分为proto2和proto3两种格式。

目前 Google 官方的 Protobuf最新 release 版本为3.5.1,以下都是基于此版本的环境搭建。

关于 Protocol Buffer 的使用可以查阅官方文档:https://developers.google.com/protocol-buffers/docs/overview

5、准备工作

5.1 环境要求

Objective-C 2.0 Runtime (32bit & 64bit iOS, 64bit OS X)

Xcode 7.0+

注意:

Protobuf 出于性能考虑没有使用 ARC,但在 ARC 下是可以使用的。

5.2 安装

下载 Protobuf 代码包(https://github.com/google/protobuf/releases),这里选择 protobuf-objectivec-3.5.1.tar.gz。

5.3 解压代码包

编译 Protobuf,这里可能需要安装部分工具:

$ brew install autoconf

$ brew install automake

$ brew install libtool

运行下面脚本进行编译:

$ ./autogen.sh

$ ./configure

$ make

$ makeinstall

检查protobuf是否安装成功:

$ protoc --version

如果成功打印版本号则安装成功:

libprotoc 3.5.1

6、在 iOS 中使用 Protobuf

6.1 创建.proto文件

这里使用官方文档上的一份示例数据结构创建Person.proto:

syntax = "proto3";

message Person {

  string name = 1;

  int32 id = 2;

  string email = 3;

  enumPhoneType {

    MOBILE = 0;

    HOME = 1;

    WORK = 2;

  }

  message PhoneNumber {

    string number = 1;

    PhoneType type = 2;

  }

  repeated PhoneNumber phone = 4;

}

使用命令行编译Person.proto为objective-c的文件,编译出来的文件为Person.pbobjc.h和Person.pbobjc.m:

protoc Person.proto --objc_out=./

6.2 引入 Protobuf 运行时资源

Google 官方的文档提供了两种引入方式,但使用第一种的时候编译不能通过,所以这里选择了第二种:

复制protobuf目录下的:objectivec/*.h, objectivec/google/protobuf/*.pbobjc.h, objectivec/google/protobuf/*.pbobjc.m, 以及除去objectivec/GPBProtocolBuffers.m后的objectivec/*.m。

这里直接用命令行操作,首先进入protobuf下objectivec的目录:

$ cdprotobuf-3.5.1/objectivec

然后复制符合规则的文件到指定的工程目录下:

$mkdir~/ProtobufDemo/ProtocolBuffers~/ProtobufDemo/ProtocolBuffers/google~/ProtobufDemo/ProtocolBuffers/google/protobuf

$ cp*.h *.m ~/ProtobufDemo/ProtocolBuffers

$ cpgoogle/protobuf/*.pbobjc.h google/protobuf/*.pbobjc.m ~/ProtobufDemo/ProtocolBuffers/google/protobuf

注意:

上面的命令并没有排除 GPBProtocolBuffers.m 文件,引入时需要手动排除。

现在把ProtocolBuffers目录下所有文件以及上面编译出来的Person.pbobjc.h和Person.pbobjc.m都引入到工程中。

现在工程目录结构大概是长这样:

需要注意,由于protobuf没有使用 ARC,因此需要为所有.m文件加上-fno-objc-arc来关闭 ARC:

注意:

需要注意工程中的 Header Search Paths 要增加 $(PROJECT_DIR)/ProtocolBuffers(具体的路径视情况而定)

6.3 直接引入 ProtocolBuffers 工程

如果觉得手动引入文件的方式过于复杂,可以直接引入ProtocolBuffers工程作为依赖项:

1)进入解压后的protobuf目录下,复制objective目录下的所有文件到ProtobufDemo/ProtocolBuffers目录下;

2)在ProtobufDemo工程中引入ProtocolBuffers_iOS工程:

3)在Build Phases中加入依赖关系并链接库:

4)引入Person.pbobjc.h和Person.pbobjc.m文件并为.m加上-fno-objc-arc;

5)修改工程配置中部分路径为 $(PROJECT_DIR)/ProtocolBuffers。

6.4 运行测试

首先引入头文件:

#import "Person.pbobjc.h"

生成Person对象并进行编码和解码:

Person *p = [[Person alloc] init];

p.id_p = 1;

p.name = @"person1";

p.email = @"123@qq.com";


//encode

NSData*data = [p data];

NSLog(@"Protocol Buffers:\n%@\nData: %@\nData Length: %lu", p, data, data.length);


//decode

Person *newP = [[Person alloc] initWithData:data error:nil];

NSLog(@"Decoded: %@", newP);

运行程序,打印日志如下:

Protocol Buffers:

: {

    name: "person1"

    id: 1

    email: "123@qq.com"

}

Data: <0a077065 72736f6e 3110011a 0a313233 4071712e 636f6d>

Data Length: 23

Decoded: : {

    name: "person1"

    id: 1

    email: "123@qq.com"

}

Coffee time!

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

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

     摘要: 本文作者:丁同舟,转载自“随手记技术团队”微信公众号。1、前言跟移动端IM中追求数据传输效率、网络流量消耗等需求一样,随手记客户端与服务端交互的过程中,对部分数据的传输大小和效率也有较高的要求,普通的数据格式如 JSON 或者 XML 已经不能满足,因此决定采用 Google 推出的 Protocol Buffers 以达到数据高效传输。(本文同步发布于:http://ww...  阅读全文

posted @ 2018-04-02 12:23 Jack Jiang 阅读(473) | 评论 (0)编辑 收藏

     摘要: 1、长连接在iOS开发中的应用常见的短连接应用场景:一般的App的网络请求都是基于Http1.0进行的,使用的是NSURLConnection、NSURLSession或者是AFNetworking,Http1.0链接最显著的特点就是客户端每一次需要主动向服务端发送请求,都需要经历建立链接、发送请求、返回数据、关闭链接这几个阶段,是一种单向请求且无状态的协议。长连接的应用场景:有的时候,我们需要服...  阅读全文

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

     摘要: 1、前言IM App 是我做过 App 类型里复杂度最高的一类,里面可供深究探讨的技术难点非常之多。这篇文章和大家聊下从移动端客户端的角度所关注的IM消息可靠性和送达机制(因为我个人对移动客户端的经验积累的比较丰富嘛)。学习交流:- 即时通讯开发交流群:320837163[推荐]- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》(本文同步发布于:http://www.52im.n...  阅读全文

posted @ 2018-03-19 14:52 Jack Jiang 阅读(366) | 评论 (0)编辑 收藏

     摘要: 编辑文章1、前言从直播在线上抓娃娃,不断变化的是玩法的创新,始终不变的是对超低延迟的苛求。实时架构是超低延迟的基石,如何在信源编码、信道编码和实时传输整个链条来构建实时架构?在实时架构的基础之上,如果通过优化采集、编码、传输、解码和渲染中的关键环节来降低延迟?本文将会介绍即构在这方面的思考与实践。学习交流:- 即时通讯开发交流群:320837163 [推荐]- 移动端IM开发入门文章:《...  阅读全文

posted @ 2018-03-17 10:59 Jack Jiang 阅读(394) | 评论 (0)编辑 收藏

     摘要: 一个典型的IM系统中最为重要也是用户最先接触到的——就是基于Http的SSO单点登陆接口(有的系统里可能并不叫SSO接口,本文讨论的是其广义:即实现身份认证功能的http接口),那么这个SSO接口工作原理是什么?可以怎么来实现?有无最佳实践建议?  阅读全文

posted @ 2018-01-18 14:35 Jack Jiang 阅读(501) | 评论 (0)编辑 收藏

Jack Jiang的 Mail: jb2011@163.com, 联系QQ: 413980957, 微信: hellojackjiang