分布式软件架构——传输链路

这篇具有很好参考价值的文章主要介绍了分布式软件架构——传输链路。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

传输链路

链路指无源的点到点的物理连接。链路是计算机网络中的一个重要概念,它指的是连接两个网络设备的物理或逻辑路径。简单来说,链路就是电信号或数据在网络中传输的路径。在计算机网络中,链路可以分为物理链路和逻辑链路两种。物理链路是指连接两个网络设备的物理媒介,例如网线、光纤等。逻辑链路则是指通过网络协议建立的逻辑连接,例如TCP/IP协议中的连接。

链路是计算机网络中非常重要的概念,它负责连接网络设备并保证数据的可靠传输。

前端优化

以优化链路传输为目的的前端设计原则未来或许不再使用,比如

  1. Minimize HTTP Requests,减少请求数量
    减少请求数量的手段有:
  • a.雪碧图(CSS Sprites)
  • b.CSS、JS文件合并/内联(Concatenation/Inline)
  • c.分段文档(Multipart Document)
  • d.媒体(图片、音频)内联(Data Base64 URI)
  • e.合并Ajax请求(Batch Ajax Request)
  • f. … …
  1. Split Components Across Domains,扩大并发请求数
    现代浏览器(Chrome、Firefox)一般可以为每个域名支持6个(IE为8~13个)并发请求。如果想要更快地加载大量图片或其他资源,就需要进行域名分片(Domain Sharding),将图片同步到不同主机或者同一个主机的不同域名上。
  2. GZip Components,启用压缩传输
    启用压缩传输能够大幅减少需要在网络上传输的内容大小,节省流量。
  3. Avoid Redirects,避免页面重定向
    当页面发生重定向,就会延迟整个文档的传输。
  4. Put Stylesheets at the Top, Put Scripts at the Bottom,按重要性调节资源优先级
    将重要的资源放在HTML的头部,以便优先下载。
  5. … …

连接数优化

HTTP是以TCP为传输层的应用层协议,但HTTP over TCP这种搭配,只能说是TCP目前在互联网的统治地位所造就的结果,而不能说它们两者配合工作就是合适的。

  • 一方面,HTTP传输对象(HTML、JS、CSS、图片等)的主要特征是数量多、时间短、资源小、切换快。
  • 另一方面,TCP协议要求三次握手完成后才能开始数据传输,TCP还有慢启动特性,导致通信建立连接时传输速率最低,后面逐步加速稳定。

由于TCP协议本身是面向长时间、大数据传输来设计的,所以只有在一段较长的时间尺度内,TCP协议才能展现出稳定性和可靠性的优势,不会因为建立连接的成本太高,成为了使用瓶颈。

开发Tricks的使用困境

为缓解HTTP与TCP之间的矛盾,程序猿们一方面致力于减少发出的请求数量,另一方面致力于增加客户端到服务端的连接数量。即前面提到的Minimize HTTP Requests和Split Components Across Domains两条优化措施的根本依据。

HTTP Archive对近2016~2020年数百万个URL地址进行了采样,得出一个结论:页面平均请求没有改变的情况下(桌面端下降3.8%,移动端上升1.4%),TCP连接正在持续且幅度较大地下降(桌面端下降36.4%,移动端下降28.6%),如下图
分布式软件架构——传输链路,分布式

分布式软件架构——传输链路,分布式
开发Tricks可以节省TCP连接外,也会带来不少副作用。比如,

  • CSS Sprites合并多张图片后,只要使用其中一张小图片,也必须加载整个大图片;如果某张小图片需要修改,会导致整个大图的缓存失效;样式、脚本等文件的合并同理;
  • 媒体内嵌时,除了要承受Base64编码导致的传输容量膨胀1/3的代价以外,也会无法有效利用缓存;
  • 合并异步请求后,导致所有请求的返回时间,都要受最慢请求的拖累,页面整体响应速度下降;
  • 图片放到不同子域下面,将会导致更大的DNS解析负担;

连接复用技术的优势和缺陷

HTTP连接复用技术,也即持久连接(Persistent Connection),或者叫连接Keep-Alive机制。它的原理是,让客户端对同一个域名长期持有一个或多个不会用完即断的TCP连接,典型做法是在客户端维护一个FIFO队列,每次取完数据之后的一段时间内,不自动断开连接,以便获取下一个资源时可以直接服用,避免创建TCP连接的成本
但是,连接复用技术最明显的副作用就是“队首阻塞”(Head-of-Line Blocking)问题。

解决方案:HTTP/2的多路复用技术
HTTP/1.x中,HTTP请求就是传输过程中最小粒度的信息单位,难以重组出有效信息;
HTTP/2中,帧(Frame)才是最小粒度的信息单位,它可以用来描述各种数据,比如请求的Headers、Body,或者用来做控制标识(打开流、关闭流)。
其中流(Stream),是一个逻辑上的数据通道概念,每个帧都附带有一个流ID,以标识这个帧数语哪个流。
分布式软件架构——传输链路,分布式
与HTTP/1.x相反,HTTP/2本身反而变得更适合传输小资源,比如传输1000张10K的小图,HTTP/2要比HTTP/1.x快,但传输10张1000K的大图,则应该HTTP/1.x会更快。

传输压缩

HTTP很早就支持了GZip压缩,因为HTTP传输的主要内容,比如HTML、CSS、Script等,主要是本文数据,因此对于文本数据启用压缩的收益是非常高的,传输数据量一般会降至原有的20%左右。而对于不适合压缩的资源,Web服务器则能根据MIME(Multipurpose Internet Mail Extensions)类型,来自动判断是否对响应进行压缩。
几种压缩方式:

  • 静态预压缩(Static Precompression):把静态资源预先压缩为.gz文件的形式存放起来;
  • 即时压缩(On-The-Fly Compression):在内存的数据流中完成;

持久连接机制不再依靠TCP连接是否关闭,来判断资源请求是否结束了。它会重用同一个连接,以便向同一个域名请求多个资源。
这个机制最初(HTTP/1.0)就是根据Content-Length判断传输资源是否已经结束。但启动即时压缩后就无法给出Content-Length。依靠Content-Length来判断传输结束是有缺陷的。HTTP1.1版本修复了缺陷,增加了另一种“分块传输编码”(Chunked Transfer Encoding)的资源结束判断机制,彻底解决了Content-Length与持久连接的冲突问题。

快速UDP网络连接

要想从根本上改进HTTP,就必须直接替换掉HTTP over TCP的根基。使用UDP协议替换TCP传输协议就是一种思路,2013年,Google在它的服务器(Google.com、YouTube.com等)启用了名为快速UDP网络连接(Quick UDP Internet Connections,QUIC)的传输协议。2018年末,IETF正式批准了HTTP over QUIC使用HTTP/3的版本号,确立为最新一代的互联网标准。

QUIC自己实现的好处是能对每个流能做单独的控制,如果其中一个流发生错误,协议栈仍然可以独立地继续为其他流提供服务。
QUIC的另一个设计目标是面向移动设备的专门支持,在移动设备上的主要优势体现在网络切换的响应速度上,QUIC提出了连接标识符的概念,可以唯一标识客户端与服务器端之间的连接,而无需依靠IP地址。文章来源地址https://www.toymoban.com/news/detail-568124.html

到了这里,关于分布式软件架构——传输链路的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 分布式软件架构——服务端缓存的三种属性

    在透明多级分流系统中,我们以流量从客户端中发出开始,以流量到达服务器集群中真正处理业务的节点结束。一起探索了在这个过程中与业务无关的一些通用组件,包括DNS、CDN、客户端缓存,等等。 实际上,服务端缓存也是一种通用的技术组件,它主要用于减少多个客户端

    2024年02月07日
    浏览(35)
  • 【软件开发】大规模分布式系统的容错架构设计

    假设有一个数据库,数据库里有一张特别大的表,里面有几十亿,甚至上百亿的数据。更进一步说,假设这一张表的数据量多达几十个 TB,甚至上百个 TB,那么如果用 MySQL 之类的数据库,单台数据库服务器上的磁盘可能都不够放这一张表的数据! 假如你手头有一个超大的数

    2024年02月04日
    浏览(32)
  • 四大软件架构:掌握单体、分布式、微服务、Serverless 的精髓

    简介: 如果一个软件开发人员,不了解软件架构的演进,会制约技术的选型和开发人员的生存、晋升空间。这里我列举了目前主要的四种软件架构以及他们的优缺点,希望能够帮助软件开发人员拓展知识面。 单体架构比较初级,典型的三级架构,前端(Web/手机端)+中间业务逻

    2024年01月17日
    浏览(36)
  • 分布式系统中的分布式链路追踪与分布式调用链路

    本文分享自天翼云开发者社区《分布式系统中的分布式链路追踪与分布式调用链路》,作者:c****w 在分布式系统中,由于服务间的调用关系复杂,需要实现分布式链路追踪来跟踪请求在各个服务中的调用路径和时间消耗。这对问题排查和性能监控都很重要。 常用的分布式链

    2024年01月19日
    浏览(42)
  • 下一代服务架构:单体架构-->分布式架构-->微服务(DDD)-->软件定义架构(SDF with GraphEngine)

    参考:自己实现一个SQL解析引擎_曾经的学渣的博客-CSDN博客    

    2024年02月12日
    浏览(35)
  • 分布式链路追踪专栏,分布式链路追踪:Skywalking集群管理设计

    SkyWalking 是一个开源 APM 系统,包括针对 Cloud Native 体系结构中的分布式系统的监视,跟踪,诊断功能。核心功能如下: 服务、服务实例、端点指标分析; 根本原因分析,在运行时分析代码; 服务拓扑图分析; 服务,服务实例和端点依赖性分析; 检测到慢速服务和端点; 性

    2024年02月01日
    浏览(64)
  • 深度解析四大主流软件架构模型:单体架构、分布式应用、微服务与Serverless的优缺点及场景应用

    🌷🍁 博主猫头虎 带您 Go to New World.✨🍁 🦄 博客首页——猫头虎的博客🎐 🐳《面试题大全专栏》 文章图文并茂🦕生动形象🦖简单易学!欢迎大家来踩踩~🌺 🌊 《IDEA开发秘籍专栏》学会IDEA常用操作,工作效率翻倍~💐 🌊 《100天精通Golang(基础入门篇)》学会Golang语言

    2024年02月06日
    浏览(36)
  • 分布式链路追踪专栏,Spring Cloud Sleuth:分布式链路追踪之通信模型设计

    Spring Cloud Sleuth  赋予分布式跟踪的  Spring Boot  自动配置的一键解决方案。 Spring Cloud Sleuth  是基于  Brave  的封装,也是很多公司采用开源加自研的最佳解决方案。 那么从作为架构师或者技术专家如何去借鉴优秀框架的设计理念和思想,本次  Chat  将开启作者既分布式链路

    2024年01月19日
    浏览(57)
  • 进阶分布式链路追踪

                            https://item.jd.com/14337086.html​编辑https://item.jd.com/14337086.html “ RocketMQ 消息中间件实战派上下册”是我既“ Spring Cloud Alibaba 微服务架构实战派上下册”之后,又一本历时超过 1 年半的巨无霸技术实战类型的书籍。 为了提高读者阅读本书的体验性,本书

    2024年02月02日
    浏览(37)
  • 分布式链路追踪概述

    随着系统设计变得日趋复杂,越来越多的组件开始走向分布式化,如微服务、分布式数据库、分布式缓存等,使得后台服务构成了一种复杂的分布式网络。往往前端的一个请求需要经过多个微服务、跨越多个数据中心才能最终获取到结果,如下图 并且随着业务的不断扩张,服

    2024年02月13日
    浏览(31)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包