水羊水羊，又水又痒，做一整只高兴的小肥羊~

作者：水羊起源：https://mp.weixin.qq.com/s/-KqKe5-HgqSrQbrj9op7pA

一道面试题

所有的起源，还得先回顾一道经典的面试题，从 URL 输出到页面展示到底产生什么？

置信这是一道BAT罕用的面试题，常常逛掘金的同学肯定看过这个图

按图中的程序合成下来就是

  1. DNS 解析:将域名解析成 IP 地址
  2. TCP 连贯：TCP 三次握手
  3. 发送 HTTP 申请
  4. 服务器解决申请并返回 HTTP 报文
  5. 浏览器解析渲染页面
  6. 断开连接：TCP 四次挥手

另外从图中，咱们也能够发现，数据通信作为信息传递的载体，在整个交互流程中，施展了至关重要的基建作用。

过来的十年

让咱们把时光倒回到10年前，那是2011年的夏天，Facebook横空出世BigPipe技术，风靡了整个前端圈。

人们第一次正式在大型商业web前端我的项目中，基于浏览器协定，开始思考可能的优化伎俩。

基于过后支流的http1.1协定，咱们把眼光投向了Chunked transfer encoding

基于分块输入的能力，咱们能够把传统的数据交互切分成相似放电影一样的帧申请

规范的http1.1申请模型如下图

基于Chunked transfer encoding拆包之后变成

比照两张图，咱们能够欣慰的发现，咱们能够无效利用原来一次URL页面申请的传输TTFB（Time To First Byte）工夫，拆分成屡次C/S之间的交互模型，来无效放慢first Byte到端的工夫，来实现提前渲染

而本来的模型中，在网络传输的时刻，端的计算能力是并行，且闲暇的

（当然在BigPipe技术呈现之前，也有是很多其余老前辈的摸索，比方基于activeX或者flash插件做多帧交互等等，有趣味的同学能够在后续的前端读历史系列文章中一窥到底。）

随着时光飞逝，转瞬到了2019年，这个时候，Web支流的浏览器协定曾经从http1.1降级到了http2.0，比照http1.1次要有了一下几个方面的改变

http1.1http2.0
分块传输Chunked encoding，文本传输帧，二进制压缩
长链接Keep alive，缩小tcp握手耗时，然而还是有线头阻塞（Head of line blocking） 的问题，即一个 TCP 连贯一次只能收回一个申请，所以客户端必须期待收到响应后能力收回另外一个申请，这样耗时的申请如果在后面会 block 前面耗时的申请。在根底上减少了管道复用，即同域名下所有通信都在单个连贯上实现，同个域名只须要占用一个 TCP 连贯，应用一个连贯并行发送多个申请和响应。同时，单个连贯能够承载任意数量的双向数据流，单个连贯上能够并行交织的申请和响应，之间互不烦扰。
http申请头明文，规范，不压缩压缩
浏览器对连接数的限度有，大家常听到的8个，具体应该和app和端有关系因为一个tcp连贯能够用来发多个申请，所以限度只存在于webServer的tps机能
Server Push无有，在接管到申请后，服务端能够发送其余资源推送和端确认，毛病是端无奈被动pull，而server端须要配置或者编程反对(依赖的起源也只能是端发动的申请头信息)，相比socket模型可编程属性会弱很多
缩小原来1.1时代的优化1. Css Sprint（导致没法Cache）
  1. 拆分assert到多域名（心愿并发）
  2. Js CDN Combine | 1. 间接资源和URI对应Cache
  3. 单域名链接即可并发，不再须要拆分
  4. 同理，不再须要Combo，不利于缓存 |

这个网址能够帮咱们直观的比照http2和http1.1的区别https://http2.akamai.com/demo

咱们的指标

往年曾经是2021年了，四周的Web服务器根本都是https2了，看到这里，就有读者会好奇的问题了，难道仅仅从http1降级到2就是咱们心愿的全副了？

答案必定是：No！

这里再回到Web诞生的元年，看看咱们的起源故事

最晚期互联网只有Telnet，过后还是一个CS模型，为了缩小C端的轻便（你得须要一个专门的telnet软件），交互验证的繁琐（各种加密校验），给枯燥的内容加点色调（ASCII字符的打印界面变得更加多媒体和黑白），于是跨零碎的浏览器被开发进去了，为了让浏览器辨认的内容更通用，HTML富文本协定被确认了，BS模型才被正式提出。

到了现在的年代，技术的多样性，性能的瓶颈都被大型在线多人游戏这些场景一遍又一遍的挑战着技术的极限。而咱们的传统Web技术还受制于各种平安/隐衷的困扰，导致很多CS早已成熟的技术，望而不能用。

就比如说对于网络申请的全链路来说，客户端开发的同学就能够有能力拜访到更底层的api，来获取更原始的信息，同时对于底层api的管制权限更大，而传统的浏览器端的同学，就不得不面对一层又一层被包裹的api，忍受着前端就只是立体展现和表单填写这些低性能场景的歧视，而传统的客户端能力才是更丰富多彩的舞台的偏见。

如果以上舆论放在9012年，咱们还能够自嘲一句，可是当初flash已死，fuchsia横空出世，flutter web都曾经能够基于skia来实现对立端能力的明天，咱们为什么不能间接继承CS社区的超能力，间接把失去的二十年一股脑的补回来呢？

就单单从通信层面，从QQ时代就曾经十分成熟的UDP通信技术，无论是传输速度，弱网通信的可靠性，都甩当初传统的TCP一大截的多产品证实的技术，是否就能够复刻在当初的浏览器通信场景上？这就是咱们的指标

Why UDP

让咱们再把时光机切到当年，回顾一下QQ当年为啥要抉择UDP而不是TCP作为通信的次要载体，首先咱们晓得QQ腾飞的那几年刚好是咱们桌面刚起步，大家还是用小猫上网的年代，而后接着就是辉煌的挪动互联网红利10年，无论是晚期的集体家用机还是挪动互联网，离不开的就是带宽窄，网速慢，不稳固，容易丢包和断连。而TCP无奈感知网络中断这些问题。。。这个算是TCP一个容易踩的坑，但这并不能阐明UDP就比TCP好（或者说解释为何要应用UDP）。因为在UDP下面一样须要面对这些问题，而解决这类问题的办法和在TCP下面进行应用层心跳的办法其实没有实质上的区别。

最实质上UDP的劣势还是带宽的利用。以前的网络抖动可能是多方面的，例如延时突发性地暴增、也有可能是因为路由层面的变动忽然导致路由黑洞，还有各种等等等等的问题。TCP因为拥塞管制、保障有序等起因，在这种网络状态上对带宽的利用是非常低的。而且因为网络抖动的起因，应用层心跳超时（个别不依附keepalive）或者应用层被动断掉socket之后TCP须要三次握手能力从新建设链接，一旦呈现频繁的小抖动就会使得带宽利用更低。而期待四次挥手的工夫，也会占用服务器上贵重的资源。总结来说，当网络差到肯定水平了，TCP的劣势反而会成为劣势。

这时候咱们再看看UDP在这种状况下的体现。应用UDP反抗网络抖动，说到底就是在应用层比TCP更快地探测和重传，一旦超过肯定的工夫没有收到回复，客户端能够抉择马上重试或者换一个IP:PORT重试（如果你的服务像QQ一样有多个接入），在服务器端则能够果决地断掉socket。而能够利用UDP的时候，往往是你的应用层协定自身曾经具备了肯定的面向连贯的个性。如果你应用层的协定曾经达到了肯定水平的音讯幂等，客户端能够简直无脑地进行重传，这样就能够尽可能地升高网络抖动的影响，同时也能够尽可能地利用整个带宽。而刚好QQ的协定，就具备相似的特点。简略来说就是咱们能够应用UDP实现一个面向连贯协定，这个协定能够很好地适应过后的网络情况和QQ自身的业务。但凡事都有老本，老本就是你的应用层协定自身须要去实现抵制网络异样带来的问题。例如乱序、例如业务数据的分片和重组、例如网络状态探测等等等等。。。而当初UDP也利用在很多跨运营商、跨地区、跨机房之间的服务调用当中。起因无它，就是网络烂到肯定水平了。

而换做咱们当初传统电商型浏览器利用场景下，咱们对于信息的对等平安加密以及校验要求其实没有那么高，实质上来说，只是简略的拉取服务器信息，并基于表单交互的形式收集用户信息上传至服务器，即便失败了，间接原包重试即可，也没有利用比方断点续传，差分合并等等对于内容解决的高级需要。那么基于TCP协定上的http协定的很多个性，其实在简略场景下其实就是多余的。然而因为设计之初，是为了满足广泛场景下的更宽泛而全面，以及更专业化的需要，所以整个应用层协定是大而全的。对于极致性能的比方数据交互场景，以及国内宽泛的电商，ToB私有化需要来说，哪怕是http2都显得微小且臃肿。

说说鸿蒙

鸿蒙也是最近一年，社区和知乎吵得最炽热的话题了。无论从PPT的前瞻性，还是从这个开源生态的资源搀扶水平，华为的同学都体现出了对于将来从端登程，回端上去的匠人精力。我也有幸从晚期的快利用联盟，到华为的卡片服务，信息流开放平台，再到当初的鸿蒙开发者社区开放平台，始终从头到尾参加过具体的开发工作。其中的艰苦，外人难得其精华，只有经验的人才知其个中滋味。“万物互联”这个概念，说了差不多也有快十年了，只有华为真正意义的实现了，把宽广的浏览器开发者生态，纳入到了鸿蒙小家庭，给了咱们宽广前端开发同学更大的场景，更宽阔的市场，更底层的能力，更亲热设施的体验。

从1997年第一次做集体网页开始，曾想着尝试把操作系统复刻到浏览器上。起初ChromeOS圆了我第一个梦，我就又开始做梦，是否在浏览器上管制空调，电扇，门铃，帮我烧菜，洗衣服做饭。当初这个幻想也实现了，通过鸿蒙，前端开发者能够通过相熟的开发方式以及流程，轻松复刻现有的我的项目能力，以及复用生态，同时基于鸿蒙提供的更底层的分布式计算能力和通信能力，让咱们解脱了传统浏览器的难受，让更多的能力能在实在场景下失去开释。

而且，鸿蒙作为一个华为自我知识产权的零碎，通过之前屡次和他们外围开发组的沟通，不论是对于问题的解决速度，以及业余的态度，对于扩充整个鸿蒙生态圈，和吸引更多优良的前端行业从业人员跑步入场，和口碑相传，都是开释了十分踊跃的信号。

咱们有理由置信，在整个大前端生态下，鸿蒙将来必然会成为特定畛域的攻坚利器，为从端登程，回端上去的现实去画上一段柔美的旋律。

将来已来

回到咱们当初的浏览器，如果咱们能够定制应用层协定，面向更底层传输层，做适合选型，做最精简的内容管制，在配合当初越来越强劲的端计算能力，加上P2P技术劣势，咱们有理由置信，咱们能够把整个链路层在大宗客户的利用场景下，均匀提速2倍以上。

其实鸿蒙ppt也提出了分布式设施互联的概念，只是他把底层p2p技术，数据交互，云计算（端计算），hack到了操作系统层面，当然咱们不须要去做一个分布式操作系统，基于2021年已有的浏览器API，咱们就曾经能够实现同样的能力。

WebSocket协定在2011年由IETF标准化为RFC 6455，后由RFC 7936补充标准。 Web IDL中的WebSocket API由W3C标准化，到当初曾经被各大支流浏览器，包含挪动端内核广泛支持了。

通过WebSocket让古代浏览器能够脱离传统的httpRequest申请，来本人管制通信节奏，建连，传输，重试，断开。第一次让BS开发选手能够选型相似CS曾经罕用的TCP通信。

而有了通信的第一步之后，就要思考对于内容信息的加密和序列化，通过WASM技术，咱们能够复用J2EE社区相干的内容序列化技术，比方protobuf，实现前后端通信同构。

借助以上技术，咱们能够就能够间接基于tcp的websocket间接和后端server通信，摈弃传统的文本传输，间接发送和承受二进制流。如果想提速文本到二进制流的序列化速度，还能够通过WASM来调用C函数来实现减速。

WebRTC是2011年提出的，本意是用在浏览器端，通过提供简略的javascriptAPI就能够达到实时通信（Real-Time Communications (RTC)）能力，也就是P2P，端到端通信。这里的端能够是浏览器到浏览器，也能够是浏览器到后端Server。这里，咱们比拟看重的WebRTC的通信是能够基于UDP的，而咱们的场景，其实并不需要音频或者视频流，咱们须要一个能自定义数据的通信形式，而WebRTC提供的RTCDataChannel恰好满足咱们的需要，一个基于UDP协定的类socket数据通信通道。另外WebRTC是能够实现基于浏览器的伪“万物互联”的，基于万物互联，咱们甚至能够实现p4p(https://en.wikipedia.org/wiki/Proactive_network_provider_participation_for_P2P)的云计算。

然而WebRTC在BS通信时候，有一些繁琐，他本来设计是基于P2P的，所以在建连的时候，须要提供 STUN、ICE 和 TURN 来反对 NAT 穿透。而如果是基于BS模型，这些是能够省略的，不过在github上曾经有很多人阉割了这部分来实现对于基于WebRTC的BS通信，比方netcode.io。

另外谷歌也在踊跃的推广基于QUIC协定的udp通信，他应用WebTransport，也是WebRTC体系下的一套浏览器API，提供低提早，client和server之间双向通信的能力。 外围的能力点包含：

  • WebTransport 提供基于QUIC 和 HTTP3实现的API, 主动取得QUIC和HTTP3自身的个性，比方应用层的拥塞，防止队头阻塞。

<!---->

  • 双向通信的能力，多个传输通道复用一个连贯的能力，可能很好的代替WebSocket。

<!---->

  • 提供发送/承受不牢靠UDP的能力，这个是浏览器始终欠缺的能力。

<!---->

  • 比照WebSocket基于音讯的模型不同，WebTransport是基于流的，在传递音讯的时候须要本人再减少一层数据的封装格局。

另外，在最近的google IO大会上，基于SW+WASM技术提出的WebContainer模型（在浏览器上运行原生的NodeJS利用），让端计算能力再次放大，起到了里程碑式的冲破，对于前端开发人员，能够在本人的浏览器里，间接跑规范的nodejs服务利用。实现真正意义的offline APP，离线浏览。

而配合这一技术的是ServiceWorker技术，是google在2016 年Google I/O 大会提出，于2017年落地的，旨在加强Web 体验，放大Web App 与Native App 的差距，并创立相似的用户体验的技术，最大的特点是能拦挡客户端申请，可编程式的管制输入，模仿文件IO的阻塞，配合WASM能够编译node/deno/go 的模块，让基于浏览器的单端计算能力有更大的设想空间。

最初的最初，再说一个好消息！就在最近，QUIC协定正式成为了官网的IETF RFC。置信不久的未来，浏览器利用开发，能够间接照搬客户端社区多年以来的贵重教训，在数据通信的优化畛域，一路长虹！

将来已来！需要快排期！

参考文献：

https://www.yhspy.com/2017/04...

https://zhuanlan.zhihu.com/p/...

https://segmentfault.com/a/11...

https://www.infoq.com/article...

http://www.alloyteam.com/2017...

https://www.yuque.com/kshare/...

https://zhuanlan.zhihu.com/p/...

The End

如果你感觉这篇文章对你有帮忙，有启发，我想请你帮我2个小忙：
1、点个「赞」，让更多的人也能看到这篇文章内容；
2、关注公众号「豆皮范儿」，公众号后盾回复「加群」 退出咱们一起学习；

关注公众号的福利继续更新，公众号后盾送学习材料：
1、公众号后盾回复「vis」，还能够获取更多可视化收费学习材料。
2、公众号后盾回复「webgl」，还能够获取webgl收费学习材料。
3、公众号后盾回复「算法」，还能够获取算法的学习材料。
4、公众号后盾回复「招聘」，获取各种内推。