HTTP/2與HTTP/3特性詳解：為你的Nginx/Apache服務器開啟下一代Web協議

更多服務器知識，盡在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）列。如果看到h2或HTTP/2，說明HTTP/2生效；如果看到h3或HTTP/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)

pytest 常見問題解答 (FAQ) 1. 基礎問題 Q1: 如何讓 pytest 發現我的測試文件&#xff1f; 測試文件命名需符合 test_*.py 或 *_test.py 模式測試函數/方法需以 test_ 開頭測試類需以 Test 開頭(且不能有__init__方法) Q2: 如何運行特定測試&#xff1f; pytest path/to/t…
閱讀更多...
【前端】SPA v.s. MPA

【前端】SPA v.s. MPA

鏈接&#xff1a;頁面結構 誤區 頁面結構管理有兩種常見方式&#xff1a;路由形式 和 組件形式。路由形式 對應MPA &#xff0c;組件形式對應SPA ? 誤區 1&#xff1a;路由形式 MPA? 路由是 SPA 和 MPA 共有的概念&#xff0c;區別在于路由映射的對象&#xff1a; MPA 的…
閱讀更多...
Matlab數據類型

Matlab數據類型

本篇介紹我在南農matlab課程上的所學&#xff0c;我對老師ppt上的內容重新進行了整理并且給出代碼案例。主要內容在矩陣。如果真的想學matlab&#xff0c;我不認為有任何文檔能夠超過官方文檔&#xff0c;請移步至官網&#xff0c;本篇說實話只是寫出來給自己和學弟學妹作期末復…
閱讀更多...
代碼隨想錄算法訓練營 Day58 圖論Ⅷ 拓撲排序 Dijkstra

代碼隨想錄算法訓練營 Day58 圖論Ⅷ 拓撲排序 Dijkstra

圖論 題目 117. 軟件構建 拓撲排序&#xff1a;給出一個有向圖&#xff0c;把這個有向圖轉成線性的排序就叫拓撲排序。 當然拓撲排序也要檢測這個有向圖是否有環&#xff0c;即存在循環依賴的情況&#xff0c;因為這種情況是不能做線性排序的。所以拓撲排序也是圖論中判斷有向…
閱讀更多...
vscode中launch.json、tasks.json的作用及實例

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

文章目錄 launch.json是什么作用多環境調試簡單實例進階使用核心配置項解析調試第三方程序 launch.json是什么 顧名思義&#xff1a;它是在.vscode文件夾下的launch.json&#xff0c;所以是vscode啟動調試的配置文件。總結&#xff1a;通過定義調試參數、環境變量和啟動方式&a…
閱讀更多...
NeRF PyTorch 源碼解讀 - 體渲染

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雙端系統開發，解鎖全球流量與變現新大陸

標題：2025海外短劇爆發年：APP+H5雙端系統開發，解鎖全球流量與變現新大陸

描述&#xff1a; 2025年出海新風口&#xff01;深度解析海外短劇系統開發核心&#xff08;APPH5雙端&#xff09;&#xff0c;揭秘高效開發策略與商業化路徑&#xff0c;助您搶占萬億美元市場&#xff01; 全球娛樂消費模式正在劇變。2025年&#xff0c;海外短劇市場已從藍海…
閱讀更多...
React JSX語法介紹（JS XML）（一種JS語法擴展，允許在JS代碼中編寫類似HTML的標記語言）Babel編譯

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詳解

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腳本

我們來學mysql -- “數據備份還原”sh腳本

數據備份&還原 說明執行db_backup_cover.sh腳本 說明 環境準備&#xff1a;來源數據庫(服務器A)&#xff1b;目標數據庫(服務器B)dbInfo.sh腳本記錄基本信息 來源庫、目標庫的ip、port及執行路徑 # MySQL 客戶端和 mysqldump 的路徑 MYSQL_CLIENT"/work/oracle/mysql…
閱讀更多...
【NLP 78、手搓Transformer模型結構】

【NLP 78、手搓Transformer模型結構】

你以為走不出的淤泥&#xff0c;也遲早會云淡風輕 —— 25.5.31 引言 ——《Attention is all you need》 《Attention is all you need》這篇論文可以說是自然語言處理領域的一座里程碑&#xff0c;它提出的 Transformer 結構帶來了一場技術革命。 研究背景與目標 在 Transfo…
閱讀更多...
深入理解CSS常規流布局

深入理解CSS常規流布局

引言 在網頁設計中&#xff0c;理解元素如何排列和相互作用至關重要。CSS提供了三種主要的布局方式&#xff1a;常規流、浮動和定位。本文將重點探討最基礎也是最常用的常規流布局&#xff08;Normal Flow&#xff09;&#xff0c;幫助開發者掌握頁面布局的核心機制。 什么是…
閱讀更多...
樹結構詳細介紹（javascript版）

樹結構詳細介紹（javascript版）

樹結構的基本概念 樹是一種非線性數據結構&#xff0c;由節點和連接節點的邊組成。與線性數據結構&#xff08;如數組、鏈表&#xff09;不同&#xff0c;樹具有層次結構&#xff0c;非常適合表示有層次關系的數據。 樹的基本術語 節點 (Node)&#xff1a; 樹中的基本單元&a…
閱讀更多...
element-plus bug整理

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區別與應用

RabbitMQ與MQTT深度解析&#xff1a;協議、代理、差異與應用場景 I. 引言 消息隊列與物聯網通信的重要性 在現代分布式系統和物聯網&#xff08;IoT&#xff09;生態中&#xff0c;高效、可靠的通信機制是構建穩健、可擴展應用的核心。消息隊列&#xff08;Message Queues&am…
閱讀更多...
零基礎遠程連接課題組Linux服務器，安裝anaconda，配置python環境（換源），在服務器上運行python代碼【3/3 適合小白，步驟詳細！！！】

零基礎遠程連接課題組Linux服務器，安裝anaconda，配置python環境（換源），在服務器上運行python代碼【3/3 適合小白，步驟詳細！！！】

遠程連接服務器 請查閱之前的博客——零基礎遠程連接課題組Linux服務器&#xff0c;安裝anaconda&#xff0c;配置python環境&#xff08;換源&#xff09;&#xff0c;在服務器上運行python代碼【1/3 適合小白&#xff0c;步驟詳細&#xff01;&#xff01;&#xff01;】&am…
閱讀更多...
Redis最佳實踐——安全與穩定性保障之訪問控制詳解

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源碼解析——響應式原理

vue2源碼解析——響應式原理

文章目錄 引言數據劫持收集依賴數組處理渲染watchervue3中的響應式 引言 vue的設計思想是數據雙向綁定、數據與UI自動同步&#xff0c;即數據驅動視圖。 為什么會這樣呢&#xff1f;這就不得不提vue的響應式原理了&#xff0c;在使用vue的過程中&#xff0c;我被vue的響應式設…
閱讀更多...
gcc相關內容

gcc相關內容

gcc 介紹&#xff1a;linux就是由gcc編譯出來的&#xff0c;而且好像之前Linux只支持gcc編譯。gcc全稱為gnu compiler collection&#xff0c;它是gnu項目的一個組成部分。gnu致力于創建一個完全自由的操作系統&#xff0c;我感覺意思就是完全開源的操作系統。gnu有很多組件和…
閱讀更多...
最新文章

Copyright @ 2022~2023