更多服务器知识,尽在hostol.com

嘿,各位站长和服务器管理员朋友们!咱们天天跟网站打交道,都希望自己的网站能像火箭一样快,用户体验“嗖嗖”的。但你知道吗?除了服务器硬件配置、代码优化、CDN加速这些“常规操作”外,你的Web服务器所使用的HTTP协议版本,也对网站的“奔跑速度”起着至关重要的作用!很多服务器可能还在默默地跑着老旧的HTTP/1.1协议,就像开着一辆“老爷车”在信息高速公路上晃悠。是时候给你的“座驾”升级换代了!今天,Hostol就带你一起深入了解下一代Web协议——HTTP/2和更前沿的HTTP/3,看看它们到底有哪些“黑科技”,以及如何在你的Nginx或Apache服务器上开启它们,让你的网站也体验一把“速度与激情”!


回忆“慢时光”:HTTP/1.1的“阿喀琉斯之踵”

在聊HTTP/2和HTTP/3之前,咱们得先简单回顾一下现在仍在广泛使用的HTTP/1.1。它相比更早的HTTP/1.0,引入了持久连接(Persistent Connections / Keep-Alive)、管道化(Pipelining)等改进,功不可没。但廉颇老矣,面对如今内容越来越丰富、交互越来越复杂的网页,HTTP/1.1也显露出了它的“老态龙钟”:

  • 队头阻塞 (Head-of-Line Blocking, HOLB): 这是HTTP/1.1最主要的性能瓶颈。想象一下,你在超市排队结账,前面有个人买了一大车东西,还各种找优惠券、墨迹半天,你就算只买了一瓶水,也得在他后面干等着。HTTP/1.1的请求和响应也是类似的“串行”模式,在一个TCP连接上,必须等前一个请求的响应完全回来后,下一个请求才能发出或被处理。一旦某个请求卡住,后面的所有请求都得“干瞪眼”。
  • TCP连接数限制: 为了缓解队头阻塞,浏览器通常会针对同一个域名同时建立多个TCP连接(一般是6个左右)来并行加载资源。但这又带来了新的问题:每个TCP连接的建立都需要“三次握手”的开销,消耗服务器资源,而且连接数过多本身也会造成网络拥堵。
  • 头部冗余: HTTP请求和响应的头部信息,在同一会话中很多内容是重复的,比如Cookie、User-Agent等,但HTTP/1.1每次都会完整发送,造成不必要的流量浪费。
  • 单向请求: 只能由客户端发起请求,服务器才能响应。服务器不能主动给客户端“推”东西(除非用一些变通的技术如WebSocket或SSE)。

正是因为这些“先天不足”,前端工程师们才发明了各种“奇技淫巧”来优化性能,比如把多个CSS/JS文件合并(减少请求数)、图片精灵(CSS Sprites)、域名分片(Domain Sharding,突破浏览器连接数限制)等等。这些方法虽然有一定效果,但治标不治本,还增加了开发和维护的复杂度。


HTTP/2:Web性能的“第一次大提速”——多车道高速公路时代!

HTTP/2(最早基于Google的SPDY协议)的出现,就是为了从根本上解决HTTP/1.1的这些痛点。它不是对HTTP/1.1的小修小补,而是一次彻底的“革新换代”。你可以把它想象成,咱们把原来拥挤不堪的“国道单行线”(HTTP/1.1)直接升级成了“双向八车道高速公路”!

重要前提:HTTPS是标配! 虽然HTTP/2协议本身不强制加密,但目前几乎所有主流浏览器(Chrome, Firefox, Edge, Safari等)都只支持通过TLS加密(即HTTPS)的HTTP/2连接。所以,想用HTTP/2?先给你的网站上HTTPS吧!这本身也是大势所趋,对安全大有裨益。

HTTP/2的核心“黑科技”:

  1. 二进制分帧层 (Binary Framing Layer): HTTP/1.1是基于文本的,而HTTP/2则引入了一个新的二进制分帧层。所有通信数据都会被分割成更小、更易管理的消息和帧(Frames),并采用二进制格式编码。这就像以前写信是手写(文本),现在是打印标准格式的快递单(二进制帧),解析效率更高,更不容易出错。
  2. 多路复用 (Multiplexing):真正的并行传输! 这是HTTP/2最核心、最具革命性的特性!它允许多个请求和响应(对应不同的“流”Stream)同时在一个TCP连接上并行、交错地进行传输,而不会互相阻塞。想象一下,在HTTP/2这条“多车道高速公路”上,小轿车(小请求)、大卡车(大响应)都可以在各自的车道上同时飞驰,互不干扰。这就从根本上解决了HTTP/1.1的队头阻塞问题(注意,是HTTP应用层面的队头阻塞,TCP层面的队头阻塞后面HTTP/3会解决)。一个域名只需要一个TCP连接就能搞定所有通信,大大减少了连接建立的开销。
  3. 头部压缩 (Header Compression - HPACK):给你的请求“减负” HTTP/2使用HPACK算法来压缩请求和响应的头部信息。它会为通信双方维护一个共享的“头部字典”,对于重复出现的头部字段(比如User-Agent, Accept等),只需要发送一个索引号就行,大大减少了传输数据量,尤其是在移动网络环境下效果显著。这就像咱们聊天,说了很多遍“你好”,后面直接用“1”代替“你好”,对方也能懂。
  4. 服务器推送 (Server Push):我猜到你想要啥!(目前应用有争议) 服务器可以在客户端请求一个HTML页面后,主动将该页面可能会用到的其他资源(比如CSS文件、JS脚本、关键图片)“推送”给客户端,而无需客户端再次发起请求。这就像一个贴心的服务员,在你点完主菜后,主动把餐具和柠檬水给你送上来了。理论上能减少请求往返次数,加快页面加载。但实际应用中,由于缓存处理、CDN兼容性以及推送时机难以把握等问题,Server Push的效果并不总是理想,很多时候甚至可能好心办坏事。目前,这个特性用得相对谨慎,很多场景下大家更倾向于使用<link rel="preload">等方式进行资源预加载。
  5. 请求优先级 (Stream Prioritization):重要的事儿优先办! 客户端可以告知服务器哪些请求的资源更重要(比如页面渲染关键的CSS优先于底部的图片),服务器可以根据这个优先级来更合理地分配资源和发送数据,优化用户感知的加载速度。

HTTP/2对前端优化的影响:

有了HTTP/2,很多以前为了绕过HTTP/1.1限制而采取的前端优化“黑魔法”就不再那么必要,甚至可能适得其反了:

  • 文件合并 (Concatenation): 比如把多个CSS或JS文件合并成一个大文件。在HTTP/2下,由于多路复用,加载多个小文件和加载一个大文件的开销差异不大,反而小文件更容易利用缓存、按需加载。
  • 图片精灵 (CSS Sprites): 将多个小图标合并成一张大图,通过CSS背景定位显示。同样,多路复用使得加载多个小图标的额外开销降低。
  • 域名分片 (Domain Sharding): 将资源分布在多个域名下以突破浏览器对单域名并发连接数的限制。在HTTP/2下,一个连接就足够高效,域名分片反而会增加DNS查询和TCP连接建立的开销。

如何在Nginx/Apache上开启HTTP/2?

Nginx (版本通常需要1.9.5+):

非常简单!只需要在你的HTTPS `server`块的`listen`指令后面加上http2参数即可:

server {listen 443 ssl http2 default_server;# listen [::]:443 ssl http2 default_server; # 如果支持IPv6ssl_certificate /path/to/your/fullchain.pem;ssl_certificate_key /path/to/your/privkey.pem;# ...其他配置...
}

然后重载Nginx配置:sudo systemctl reload nginx

Apache (版本通常需要2.4.17+,并加载mod_http2模块):

首先,确保mod_http2模块已启用:sudo a2enmod http2 (Debian/Ubuntu) 或者检查你的httpd.conf。 然后在你的配置文件(比如httpd.conf或虚拟主机配置文件)中,通过Protocols指令来声明支持的协议顺序:

&lt;IfModule http2_module&gt;Protocols h2 http/1.1# 如果也想在非加密连接上启用HTTP/2 (不推荐,且浏览器通常不支持)# Protocols h2c http/1.1 
&lt;/IfModule&gt;&lt;VirtualHost *:443&gt;ServerName yourdomain.comSSLEngine onSSLCertificateFile /path/to/your/fullchain.pemSSLCertificateKeyFile /path/to/your/privkey.pem# 明确为这个虚拟主机启用HTTP/2Protocols h2 http/1.1# ...其他配置...
&lt;/VirtualHost&gt;

然后重启Apache:sudo systemctl restart apache2 (或 httpd)。


HTTP/3:飞跃到QUIC跑道——彻底告别TCP队头阻塞!

HTTP/2已经很棒了,但它依然是构建在TCP协议之上的。而TCP本身,也存在一个“娘胎里带出来”的队头阻塞问题:如果一个TCP连接中某个数据包丢失了,那么在这个包被重传并成功接收之前,后面所有的数据包(即使它们已经到达了)都得等着,整个TCP连接都会被“卡住”。HTTP/2的多路复用解决了应用层的HOLB,但解决不了TCP传输层的HOLB。这就好比,你的多车道高速公路上,如果路基(TCP)塌了一块,那所有车道都得停下来等修路。

于是,HTTP/3横空出世!它的最大、最根本的改变就是——不再使用TCP作为传输层协议,而是基于一个全新的协议QUIC (Quick UDP Internet Connections)! QUIC本身是运行在UDP之上的。

“啥?UDP?那个不可靠、会丢包的家伙?” 你可能会这么想。别急,QUIC虽然基于UDP的“自由散漫”,但它在UDP之上重新实现了一套可靠传输、拥塞控制、多路复用、甚至加密(集成了TLS 1.3)的机制!你可以把它看作是“站在UDP肩膀上的TCP+TLS+HTTP/2的超级加强版”。

HTTP/3 (通过QUIC)的核心“超能力”:

  1. 彻底消除队头阻塞 (HOLB at Transport Layer): QUIC在单个连接内实现了多个独立的“流”(Streams)。每个HTTP请求/响应都在自己的流里传输。如果某个流中的一个UDP包(承载QUIC包)丢失了,它只会影响到当前这个流的数据重传,其他并行的流完全不受影响,可以继续传输。这就像是从“共享路基的多车道高速公路”升级到了“各自独立的磁悬浮列车轨道”,一条轨道出问题,不影响其他轨道上的列车飞驰!这对网络质量不佳(比如移动网络)的环境下,体验提升巨大。
  2. 更快的连接建立 (0-RTT or 1-RTT Handshake): 传统的TCP连接需要3次握手,HTTPS还需要额外的TLS握手(通常1-2个RTT来回时延)。QUIC在设计之初就集成了TLS 1.3的加密和认证机制,首次连接通常只需要1个RTT,而已建立过连接的客户端再次连接时,甚至可能实现0-RTT(零往返时延)的连接恢复!这就像VIP客户,刷脸就能进门,无需繁琐验证。
  3. 连接迁移 (Connection Migration):网络切换“不掉线” 我们用手机时,经常会从Wi-Fi网络切换到4G/5G蜂窝网络,或者反过来。在TCP下,这种网络(IP地址和端口)的改变通常会导致连接中断,需要重新建立。而QUIC使用一个“连接ID”(Connection ID)来唯一标识一个连接,这个ID不依赖于底层的IP和端口。所以,当你的网络发生切换时,只要连接ID不变,QUIC连接就可以“无缝迁移”,保持应用数据的持续传输。这对移动用户体验改善巨大。
  4. 改进的拥塞控制 (Improved Congestion Control): QUIC的拥塞控制机制是可插拔的,并且在用户空间实现(而不是像TCP那样在内核空间),这使得它可以更快地迭代和部署新的、更先进的拥塞控制算法(比如BBR的变种)。

HTTP/3的挑战与现状:

  • 新技术的普及过程: 虽然主流浏览器(Chrome, Firefox, Edge, Safari)和很多大型网站(如Google, Facebook, Cloudflare)都已经支持HTTP/3,但它的整体普及率仍在逐步提升中。
  • UDP的“待遇问题”: 一些老旧的防火墙、路由器或运营商网络,可能会对UDP流量进行限制甚至直接丢弃(因为历史上UDP常被用于DDoS攻击),这可能导致HTTP/3连接失败,浏览器会回退到HTTP/2或HTTP/1.1。
  • 服务器端支持与配置: Nginx和Apache对HTTP/3的支持也在不断完善中。Nginx的官方主线版本从1.25.0开始正式支持HTTP/3,但可能需要特定的编译选项或依赖。Apache对HTTP/3的支持通常依赖第三方模块如mod_http3 (基于lsquic库)。
  • CPU消耗: 由于QUIC将很多原本在内核中由硬件加速处理的TCP/TLS逻辑放到了用户空间,并且需要处理加密解密,所以CPU消耗可能会比HTTP/2稍高一些,尤其是在高流量下。不过随着软硬件的优化,这个问题也在逐步改善。

如何在Nginx/Apache上开启HTTP/3 (示例性,具体请参考最新官方文档)?

Nginx (例如,版本1.25.0+,并假设已编译QUIC支持):

你需要同时监听TCP(用于HTTP/1.1, HTTP/2)和UDP(用于HTTP/3)端口,并通过Alt-Svc头部告知浏览器HTTP/3的可用性。

server {# HTTP/1.1 and HTTP/2listen 443 ssl http2;listen [::]:443 ssl http2; # IPv6# HTTP/3# 'reuseport' is recommended for multi-worker QUIClisten 443 quic reuseport;listen [::]:443 quic reuseport; # IPv6ssl_certificate /path/to/your/fullchain.pem;ssl_certificate_key /path/to/your/privkey.pem;# (推荐) 开启TLS 1.3的0-RTT数据,对HTTP/3的0-RTT连接建立有益ssl_early_data on; # 添加Alt-Svc头部,宣告HTTP/3服务的存在# "h3"表示HTTP/3在当前监听的QUIC端口上可用# ma=86400 表示这个宣告在24小时内有效add_header Alt-Svc 'h3=":443"; ma=86400';# 如果你的HTTP/3跑在不同端口,比如UDP 4433,那就是 'h3=":4433"; ma=86400'# ...其他server配置...# HTTP/3相关的特定配置 (可能需要,具体看Nginx版本和编译情况)# 예를 들면:# http3 on; # 较新版本可能不需要显式声明# quic_retry on;
}

Apache (通常需要第三方模块如mod_http3):

Apache对HTTP/3的支持通常依赖于像mod_quic (由Apache Software Foundation开发中) 或社区/第三方提供的mod_http3模块。配置方式会因模块而异。你需要先编译和加载相应的模块,然后在配置文件中启用它,并可能需要指定QUIC监听的UDP端口以及证书等。一个高度简化的概念性配置可能类似:

&lt;IfModule http3_module&gt;Protocols h3 h2 http/1.1# 可能还需要指定QUIC监听的UDP端口和相关参数# H3Listen *:443 # 假设模块这样配置UDP监听# H3AltSvcMA 86400# H3EarlyData on
&lt;/IfModule&gt;&lt;VirtualHost *:443&gt;ServerName yourdomain.comSSLEngine on# ...证书配置...# 确保这里也声明了h3 (如果模块允许)Protocols h3 h2 http/1.1# ...其他配置...
&lt;/VirtualHost&gt;

请务必查阅你所用Nginx/Apache版本以及相关HTTP/3模块的最新官方文档以获取准确的配置方法! 因为这块技术发展很快,配置指令和要求也在不断演进。


我该用哪个?HTTP/2还是HTTP/3?

  • HTTP/2: 如果你的网站已经上了HTTPS,那么开启HTTP/2几乎是“零成本高回报”的必选项!它得到了所有现代浏览器和主流Web服务器的良好支持,能实实在在地提升网站性能。
  • HTTP/3: 这是一个更优的选择,尤其能改善移动用户和网络不稳定用户的体验。如果你的服务器软件(Nginx/Apache)和你的运维能力能够支持它(比如处理可能的UDP防火墙问题、关注CPU消耗等),那么大胆启用吧!你可以同时开启HTTP/2和HTTP/3,支持HTTP/3的浏览器会自动尝试使用它,不支持的则会平滑回退到HTTP/2。

如何验证是否成功开启?

  • 浏览器开发者工具: 打开你网站,按F12打开开发者工具,切换到“网络”(Network)标签页,刷新页面,查看请求列表中的“协议”(Protocol)列。如果看到h2HTTP/2,说明HTTP/2生效;如果看到h3HTTP/3,恭喜你,HTTP/3也成功上马了!
  • 在线检测工具: 有很多在线工具可以帮你检测网站是否支持HTTP/2和HTTP/3,比如搜索“HTTP/2 test”或“HTTP/3 check”。


从拥堵的HTTP/1.1单行道,到HTTP/2的多车道高速,再到HTTP/3的QUIC磁悬浮快线,Web协议的每一次进化,都是为了给我们带来更快、更流畅、更安全的上网体验。作为服务器的“掌舵人”,及时了解并应用这些新技术,不仅能让你的用户“爽歪歪”,也能让你的服务器资源得到更高效的利用。还在等什么?赶紧检查一下你的服务器配置,让它也搭上这趟驶向未来的“高速列车”吧!Hostol将与你一同关注Web技术的最新进展,为你的网站加速保驾护航!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:http://www.pswp.cn/pingmian/83148.shtml
繁体地址,请注明出处:http://hk.pswp.cn/pingmian/83148.shtml
英文地址,请注明出处:http://en.pswp.cn/pingmian/83148.shtml

如若内容造成侵权/违法违规/事实不符,请联系英文站点网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

pytest 常见问题解答 (FAQ)

pytest 常见问题解答 (FAQ) 1. 基础问题 Q1: 如何让 pytest 发现我的测试文件&#xff1f; 测试文件命名需符合 test_*.py 或 *_test.py 模式测试函数/方法需以 test_ 开头测试类需以 Test 开头(且不能有__init__方法) Q2: 如何运行特定测试&#xff1f; pytest path/to/t…

【前端】SPA v.s. MPA

链接&#xff1a;页面结构 误区 页面结构管理有两种常见方式&#xff1a;路由形式 和 组件形式。路由形式 对应MPA &#xff0c;组件形式对应SPA ❌ 误区 1&#xff1a;路由形式 MPA❌ 路由是 SPA 和 MPA 共有的概念&#xff0c;区别在于路由映射的对象&#xff1a; MPA 的…

Matlab数据类型

本篇介绍我在南农matlab课程上的所学&#xff0c;我对老师ppt上的内容重新进行了整理并且给出代码案例。主要内容在矩阵。如果真的想学matlab&#xff0c;我不认为有任何文档能够超过官方文档&#xff0c;请移步至官网&#xff0c;本篇说实话只是写出来给自己和学弟学妹作期末复…

代码随想录算法训练营 Day58 图论Ⅷ 拓扑排序 Dijkstra

图论 题目 117. 软件构建 拓扑排序&#xff1a;给出一个有向图&#xff0c;把这个有向图转成线性的排序就叫拓扑排序。 当然拓扑排序也要检测这个有向图是否有环&#xff0c;即存在循环依赖的情况&#xff0c;因为这种情况是不能做线性排序的。所以拓扑排序也是图论中判断有向…

vscode中launch.json、tasks.json的作用及实例

文章目录 launch.json是什么作用多环境调试简单实例进阶使用核心配置项解析调试第三方程序 launch.json是什么 顾名思义&#xff1a;它是在.vscode文件夹下的launch.json&#xff0c;所以是vscode启动调试的配置文件。总结&#xff1a;通过定义调试参数、环境变量和启动方式&a…

NeRF PyTorch 源码解读 - 体渲染

文章目录 1. 体渲染公式推导1.1. T ( t ) T(t) T(t) 的推导1.2. C ( r ) C(r) C(r) 的推导 2. 体渲染公式离散化3. 代码解读 1. 体渲染公式推导 如下图所示&#xff0c;渲染图像上点 P P P 的颜色值 c c c 是累加射线 O P → \overrightarrow{OP} OP 在近平面和远平面范围…

标题:2025海外短剧爆发年:APP+H5双端系统开发,解锁全球流量与变现新大陆

描述&#xff1a; 2025年出海新风口&#xff01;深度解析海外短剧系统开发核心&#xff08;APPH5双端&#xff09;&#xff0c;揭秘高效开发策略与商业化路径&#xff0c;助您抢占万亿美元市场&#xff01; 全球娱乐消费模式正在剧变。2025年&#xff0c;海外短剧市场已从蓝海…

React JSX语法介绍(JS XML)(一种JS语法扩展,允许在JS代码中编写类似HTML的标记语言)Babel编译

在线调试网站&#xff1a;https://zh-hans.react.dev/learn 文章目录 JSX&#xff1a;现代前端开发的声明式语法概述JSX的本质与工作原理什么是JSXJSX转换流程 JSX语法特性表达式嵌入&#xff08;JSX允许在大括号内嵌入任何有效的JavaScript表达式&#xff09;属性传递&#xf…

Unity UI系统中RectTransform详解

一、基础代码示例 public GameObject node; var rect node.GetComponent<RectTransform>();Debug.Log($"anchoredPosition----{rect.anchoredPosition}"); Debug.Log($"offsetMin.x--{rect.offsetMin}"); Debug.Log($"offsetMax.x--{rect.of…

【数据库】并发控制

并发控制 在数据库系统&#xff0c;经常需要多个用户同时使用。同一时间并发的事务可达数百个&#xff0c;这就是并发引入的必要性。 常见的并发系统有三种&#xff1a; 串行事务执行&#xff08;X&#xff09;&#xff0c;每个时刻只有一个事务运行&#xff0c;不能充分利用…

我们来学mysql -- “数据备份还原”sh脚本

数据备份&还原 说明执行db_backup_cover.sh脚本 说明 环境准备&#xff1a;来源数据库(服务器A)&#xff1b;目标数据库(服务器B)dbInfo.sh脚本记录基本信息 来源库、目标库的ip、port及执行路径 # MySQL 客户端和 mysqldump 的路径 MYSQL_CLIENT"/work/oracle/mysql…

【NLP 78、手搓Transformer模型结构】

你以为走不出的淤泥&#xff0c;也迟早会云淡风轻 —— 25.5.31 引言 ——《Attention is all you need》 《Attention is all you need》这篇论文可以说是自然语言处理领域的一座里程碑&#xff0c;它提出的 Transformer 结构带来了一场技术革命。 研究背景与目标 在 Transfo…

深入理解CSS常规流布局

引言 在网页设计中&#xff0c;理解元素如何排列和相互作用至关重要。CSS提供了三种主要的布局方式&#xff1a;常规流、浮动和定位。本文将重点探讨最基础也是最常用的常规流布局&#xff08;Normal Flow&#xff09;&#xff0c;帮助开发者掌握页面布局的核心机制。 什么是…

树结构详细介绍(javascript版)

树结构的基本概念 树是一种非线性数据结构&#xff0c;由节点和连接节点的边组成。与线性数据结构&#xff08;如数组、链表&#xff09;不同&#xff0c;树具有层次结构&#xff0c;非常适合表示有层次关系的数据。 树的基本术语 节点 (Node)&#xff1a; 树中的基本单元&a…

element-plus bug整理

1.el-table嵌入el-image标签预览时&#xff0c;显示错乱 解决&#xff1a;添加preview-teleported属性 <el-table-column label"等级图标" align"center" prop"icon" min-width"80"><template #default"scope"&g…

RabbitMQ和MQTT区别与应用

RabbitMQ与MQTT深度解析&#xff1a;协议、代理、差异与应用场景 I. 引言 消息队列与物联网通信的重要性 在现代分布式系统和物联网&#xff08;IoT&#xff09;生态中&#xff0c;高效、可靠的通信机制是构建稳健、可扩展应用的核心。消息队列&#xff08;Message Queues&am…

零基础远程连接课题组Linux服务器,安装anaconda,配置python环境(换源),在服务器上运行python代码【3/3 适合小白,步骤详细!!!】

远程连接服务器 请查阅之前的博客——零基础远程连接课题组Linux服务器&#xff0c;安装anaconda&#xff0c;配置python环境&#xff08;换源&#xff09;&#xff0c;在服务器上运行python代码【1/3 适合小白&#xff0c;步骤详细&#xff01;&#xff01;&#xff01;】&am…

Redis最佳实践——安全与稳定性保障之访问控制详解

Redis 在电商应用的安全与稳定性保障之访问控制全面详解 一、安全访问控制体系架构 1. 多层级防护体系 #mermaid-svg-jpkDj2nKxCq9AXIW {font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-jpkDj2nKxCq9AXIW .error-ico…

vue2源码解析——响应式原理

文章目录 引言数据劫持收集依赖数组处理渲染watchervue3中的响应式 引言 vue的设计思想是数据双向绑定、数据与UI自动同步&#xff0c;即数据驱动视图。 为什么会这样呢&#xff1f;这就不得不提vue的响应式原理了&#xff0c;在使用vue的过程中&#xff0c;我被vue的响应式设…

gcc相关内容

gcc 介绍&#xff1a;linux就是由gcc编译出来的&#xff0c;而且好像之前Linux只支持gcc编译。gcc全称为gnu compiler collection&#xff0c;它是gnu项目的一个组成部分。gnu致力于创建一个完全自由的操作系统&#xff0c;我感觉意思就是完全开源的操作系统。gnu有很多组件和…