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

作者：水羊
起源：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 次要有了一下几个方面的改变

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、公众号后盾回复「 招聘」，获取各种内推。