Jack Jiang

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

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

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

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

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

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

posted @ 2018-07-21 20:50 Jack Jiang 阅读(168) | 评论 (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 阅读(141) | 评论 (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 阅读(836) | 评论 (1)编辑 收藏

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

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

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

posted @ 2018-07-11 14:49 Jack Jiang 阅读(173) | 评论 (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 阅读(200) | 评论 (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 阅读(201) | 评论 (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 阅读(228) | 评论 (0)编辑 收藏

仅列出标题
共47页: First 上一页 38 39 40 41 42 43 44 45 46 下一页 Last 
Jack Jiang的 Mail: jb2011@163.com, 联系QQ: 413980957, 微信: hellojackjiang